constrained restful environments wg (core) - ietf · constrained restful environments wg (core) ......
TRANSCRIPT
http6lowappnet coreIETF86 2013-03-12-13
Constrained RESTful Environments WG (core)
Chairs Andrew McGregor ltandrewmcgrgmailcomgt Carsten Bormann ltcabotziorggtMailing List coreietforgJabber corejabberietforg
1
http6lowappnet coreIETF86 2013-03-12-13
We assume people have read the drafts
Meetings serve to advance difficult issues by making good use of face-to-face communications
Note Well Be aware of the IPR principles according to RFC 3979 and its updates
uumlBlue sheetsuumlScribe(s)httptoolsietforgwgcoreminutes
2
http6lowappnet coreIETF86 2013-03-12-13
Milestones (from WG charter page)httpdatatrackerietforgwgcorecharter
Document submissions to IESG
Dec 2012 CoAP protocol specification with mapping to HTTP Rest API to IESG Feb 2013 Blockwise transfers in CoAP to IESG Feb 2013 Observing Resources in CoAP to IESG Apr 2013 Group Communication for CoAP to IESG Dec 2099 HOLD (date TBD) Constrained security
bootstrapping specification to IESG
3
0
01
02
03
04
05
06
07
08
09
1
10 20 30 40 50 60 70 80 90 100
Bad
ness
rem
aini
ng
Amount of time spent
asymptotic(x)
You are here
4
0
01
02
03
04
05
06
07
08
09
1
10 20 30 40 50 60 70 80 90 100
Bad
ness
rem
aini
ng
Amount of time spent
asymptotic(x)
You are here
5
Group 1 2nd WGLCcoap-13 coap-14
6
http6lowappnet coreIETF86 2013-03-12-13
draft-ietf-core-coap-14
7
Will be published a couple of hours from nowsect please do read and comment again during IETF last call
Changes from ndash13sect Clarify that payload sniffing is acceptable only if no Content-
Format was suppliedsect Clarify that safe-to-forward options in a 203 Valid response
update the cachesect Clarify URI examples (Appendix B)sect Numerous editorial improvements and clarifications
sect Made Accept option non-repeatable
Repeatable13 Accept13 Opon
bull Problem
bull Soluon13 A13 ldquoJust13 do13 not13 do13 itrdquo13 and13 keep13 it13 generalbull Soluon13 B13 Change13 to13 non-shy‐repeatable
+ Predictable13 behavior13 when13 going13 through13 different13 caches+ Makes13 Accept13 and13 proxies13 easier13 to13 understand+ We13 have13 out-shy‐of-shy‐band13 content13 negoaon13 (ct=ldquoltAgt13 ltBgtrdquo)+ Can13 be13 added13 later13 as13 extension13 if13 really13 needed
GET13 someresAccept13 A13 B13
GET13 someresAccept13 B13 A13
someres13 (A13 B)13 =gt13 ltAgt
someres13 (B13 A)13 =gt13 ltAgt
Proxy
Also13 causesmulple13 observe13 relaonships
Cacheblowup
someresltAgt
Origin13 Server
Group 1a WGLC processingobserve block
9
http6lowappnet coreIETF86 2013-03-12-13
draft-ietf-core-observe-08
10
Changes from ndash07 to ndash08sect Expanded text on transmitting notification while a previous
transmission is pending (242)sect Changed reordering detection to use a fixed time span of 128
seconds instead of EXCHANGE_LIFETIME (276)sect Removed the use of the freshness model to determine if the
client is still on the list of observers
http6lowappnet coreIETF86 2013-03-12-13
draft-ietf-core-block-10
11
Still awaits grand editorial rewritesect right after coap-14 is shipped
http6lowappnet coreIETF86 2013-03-12-13
Tickets
hellip are our way to make the steps forward are at
http toolsietforgwgcore Updates are sent to the mailing list
sect Please review When we close a ticket please review once more
12
Group 2 groupcomm
13
Akbar RahmanEsko Dijk
IETF 86 March 2013httpwwwietforgiddraft-ietf-core-groupcomm-05txt
Group Communication for CoAP
Summary of Changes (14)
n I-D had two updates (Rev 04 amp 05) after IETF-85 (Atlanta) Many of the updates were due to the detailed review by Peter van der Stokn Thank you Peter for your valuable comments
n Changes from ietf-03 to ietf-04 n Section 23 (Potential Solutions for Group Communications) moved to
draft-dijk-core-groupcomm-misc (266)n Added reference to draft-keoh-tls-multicast-security to section 6 (Security
Considerations) n Appendix B (CoAP-Observe Alternative to Group Communications) moved
to draft-dijk-core-groupcomm-misc (267) n Deleted section 8 (Conclusions) as it is redundant (268) n Simplified light switch use case (269) by splitting into basic operations and
additional functions (269)
Summary of Changes (24)
n Changes from ietf-03 to ietf-04 (Continued) n Moved section 37 (CoAP Multicast and HTTP Unicast Interworking) to
draft-dijk-core-groupcomm-misc (270) n Moved section 331 (DNS-SD) and 332 (CoRE Resource Directory) to
draft-dijk-core-groupcomm-miscClarified that DNS based features are optional (272)
n Focus section 35 (Configuring Group Membership) on a single proposed solution
n Scope of section 53 (Use of MLD) widened to multicast destination advertisement methods in general
n Rewrote section 22 (Scope) for improved readibility n Moved use cases that are not adressed to draft-dijk-core-groupcomm-miscn Various editorial updates for improved readibility
Summary of Changes (34)
n Changes from ietf-04 to ietf-05 n Added a new section 39 (Exceptions) that highlights that IP multicast (and
hence group communications) is not always available (187) n Included guidelines on when (not) to use CoAP responses to multicast
requests and when (not) to accept multicast requests (273) n Added guideline on use of core-block for minimizing response size (275)n Restructured section 6 (Security Considerations) to more fully describe
threats and threat mitigation (277) n Clearly indicated that DNS resolution and reverse DNS lookup are optional n Removed confusing text about a single group having multiple IP addresses
If multiple IP addresses are required then multiple groups (with the same members) should be created
n Removed repetitive text about the fact that group communications is not guaranteed
Summary of Changes (44)
n Changes from ietf-04 to ietf-05 (Continued) n Merged previous section 52 (Multicast Routing) into 31 (IP Multicast
Routing Background) and added link to section 52 (Advertising Membership of Multicast Groups)
n Clarified text in section 38 (Congestion Control) regarding precedence of use of IP multicast domains (ie first try to use link-local scope then site-local scope and only use global IP Communication for CoAP multicast as a last resort)
n Extended group resource manipulation guidelines with use of preconfigured portspaths for the multicast group
n Consolidated all text relating to ports in a new section 33 (Port Configuration)
n Clarified that all methods (GETPUTPOST) for configuring group membership in endpoints should be unicast (and not multicast) in section 37 (Configuring Group Membership In Endpoints)
n Various editorial updates for improved readability
Discussion item (11)
n Solution for Configuring Group Membership (no ticket)n Example of (unicast) configuring an endpoint to be part of one multicast
groupReq POST gp (Content-Format applicationjson)
n floor1westbldg6examplecom ip ff154200f7feed3714cb Res 204 Changed
n Where the ldquogprdquo resource has resource type (rt) ldquocoregprdquo which is defined for this purpose
n Question Do we want specify such a solution (or for example leave it completely up to implementation)
Open Issues(15)
n Review Groupcomm requirements language (271)n Decision made to keep requirements language for informational draftn Each use of MAYMUSTSHOULD etc is to be reviewed
Open Issues(25)
n Add section on multicast via Proxy and its limitations (274)n Add a section to explain the issues amp limitations of doing CoAP multicast
requests via a CoAP Proxy n Goal is to warn and guide implementers in this subject n Also such a section would provide a placeholderreminder of the problems
that might be addressed further in the futuren Based on IETF 85 CoRE WG meeting discussion on Multicast CoAP
requests via a Proxy Discussion summary for referencen Aggregation of responses in a proxy is difficult since it doesnt know
when to stop aggregating responses n SIP tried to deal with this problem but didnt solve it n There may be an expectancy of CoAP client to get single response
back from proxy not multiple The client in this case may not even know what it could expect It may not even know the Proxy-URI contains a multicast target
n Presented via-proxy use case exposes gap in the core-coap specification regarding multicast via proxy (Note Expectation is that core-coap wonrsquot address it in the first planned RFC release)
Open Issues(35)
n Issues with twomultiple Resource Directories in use case (280)n Some potential issues with RD came out of review Peter van der Stok and
WG discussion IETF85 n There are two RD servers use case shows that only one is found despite
the fact that site-local multicast is used - should be two RDs found n Proposal simplify use case to a single RD server on the backbone to avoid
such RD-specific issues like synchronization of RD information between servers
Open Issues(45)
n Add single-subnet configuration to use cases (278)n Suggested by review Peter van der Stok and IETF85 WG discussion that
its best to start explaining the simplebasic cases and then gradually build up complexity
n Simplest case not shown yet would be a single subnet network configuration which is currently not present in the I-D only the 2-subnet configuration of Fig 1
n Question Do we need to add such case or doesnt it add muchn (Note that core-coap Figure 22 already shows the simplest case of link-local
multicast)
Open Issues(55)
n Add use case with controller (client) located on the backbone (279)n Suggested by discussion following review Peter van der Stok n Case missing where a controller (client) is located on the backbonen Question Do we need to add such case or does it add much
Group 2a other old friends
25
Angelo Castellani Salvatore Loreto Akbar Rahman Thomas Fossati Esko Dijk
IETF 86 March 2013httpwwwietforgiddraft-castellani-core-http-mapping-07txt
Best Practices for HTTP-CoAP Mapping
Implementation
Summary of Changes (from -06 rev)
n Based on discussion at last IETF-85 (Atlanta)n Clarification of HTTP-CoAP Proxies
n Definitionn Placementn Benefits
n Clarification of HTTP-CoAP URI mapping options
Goals of I-D
n For Reverse HTTP-CoAP Cross Protocol Proxyn Provide more detailed information to proxy designers (beyond
Section 10 of [I-Dietf-core-coap]) to help implement proxies that correctly inter-work with other CoAP and HTTP clientserver implementations that adhere to the specifications
n Define a consistent set of guidelines that a HTTP-to-CoAP proxy implementation MAY adhere to The main reason of adhering to such guidelines is to reduce variation between proxy implementations thereby increasing interoperabilityn As an example use case a proxy conforming to these guidelines made
by vendor A can be easily replaced by a proxy from vendor B that also conforms to the guidelines
I-D Outline
n Guidance on HTTP to CoAP URI mappingn HTTP-CoAP Reverse cross-protocol proxy implementation
n Placementn Response code amp media type translationsn Caching and congestion controln Cache refresh via Observen Use of CoAP blockwise transfern Security translation
n Security Considerationsn Traffic overflown Handling secured exchanges
Definitions (12)
n Cross-Protocol Proxy (or Cross Proxy) is a proxy performing a cross- protocol mapping in the context of this document a HTTP-CoAP (HC) mapping A Cross-Protocol Proxy can behave as a Forward Proxy Reverse Proxy or Interception Proxy n Note In this document we focus on the Reverse Proxy mode of the
Cross-Protocol Proxy
n Forward Proxy a message forwarding agent that is selected by the client usually via local configuration rules to receive requests for some type(s) of absolute URI and to attempt to satisfy those requests via translation to the protocol indicated by the absolute URI The user decides (is willing to) use the proxy as the forwardingdereferencing agent for a predefined subset of the URI space
Definitions (22)
n Reverse Proxy a receiving agent that acts as a layer above some other server(s) and translates the received requests to the underlying servers protocol It behaves as an origin (HTTP) server on its connection towards the (HTTP) client and as a (CoAP) client on its connection towards the (CoAP) origin server The (HTTP) client uses the origin-form [I-Dietf-httpbis-p1-messaging] as a request- target URI
n Reverse and Forward proxies are technically very similar with main differences being that the former appears to a client as an origin server while the latter does not and that clients may be unaware they are communicating with a proxy
Reverse Cross-Protocol Proxy Deployment Scenario
HTTP-CoAP Response Code Mapping
Implementation Experience
n Direct experience from the draft authorsn Squid HTTP-CoAP mapping module
n University of Padovan httptelecomdeiunipditiotn Both Forward and Interception operation supported
n HTTP-CoAP proxy based on EvCoAPn KoanLogic University of Bologna and Salvatore
Loreto (as individual)n httpsgithubcomkoanlogicwebthingstreemasterbridgesw
libevcoapn The document is open to input from other implementations
Next Steps
n Does the WG recommend adoptionn Intended status Informational Best Practicen Purpose Reduce arbitrary variation between proxy
implementations thereby increasing interoperability
Backup
HTTP to CoAP URI Mapping Options (12)
n Embedded Mapping n In an embedded mapping approach the HTTP URI has embedded
inside it the authority and path part of the CoAP URI n Example The CoAP resource nodecoapsomethingnetfoo can
be accessed by an HTTP client by inserting in the request httphc-proxysomethingnetcoapnodecoapsomethingnetfoo The Cross-Protocol Proxy then maps the URI to coapnodecoapsomethingnetfoo
HTTP to CoAP URI Mapping Options (22)
n Homogeneous Mapping n In a homogeneous mapping approach only the scheme portion of the URI
needs to be mapped The rest of the URI (ie authority path etc) remains unchanged
n Example The CoAP resource coapnodecoapsomethingnetfoo can be accessed by an HTTP client by requesting httpnodecoapsomethingnetfoo The Cross-Protocol Proxy receiving the request is responsible to map the URI to coapnodecoapsomethingnetfoo
n Background info n The assumption in this case is that the HTTP client would be able to
successfully resolve nodecoapsomethingnet using DNS infrastructure to return the IP address of the HC proxy Most likely this would be through a two step DNS lookup where the first DNS lookup would resolve somethingnet using public DNS infrastructure
n Then the second DNS lookup on the subdomain coap and the host node would typically be resolved by a DNS server operated by the owner of domain somethingnet So this domain owner can manage its own internal node names and subdomain allocation which would correspond to the CoAP namespace
Group 3 ldquonew workrdquo
39
Transport of CoAP over SMS USSD and GPRSdraft-becker-core-coap-sms-gprs-03
Markus Becker Kepeng LiKoojana Kuladinithi Thomas Poumltsch
CoRE WG IETF-86 Orlando
1 10
ScenariosI In M2M communication IP connectivity is not alwayssupported by the constrained end-points
I Power savingI Coverage (GPRS 3G LTE)
I SMS and USSD based communication is almost alwayssupported
210
Changes from draft-01 to draft-03 (1)
I Added possible CONNONACK interactions Section 5
I Option name changed from Reply-To- to Response-To-Section 16 and Section 101
I Added URI schemeEg coap+tel+15105550101well-knowncore Section 11
I Added possible M2M proxy scenarios Section 14
3 10
Changes from draft-01 to draft-03 (2)
I Added reference to bormann-coap-misc for other SMSencoding Section 71
I Updated requirements on Uri-Host and Uri-Port forcoap+tel Section 10
I Added security considerations Transport and ObjectSecurity Section 15
I Chose CoAP option numbers and updated the optionnumber table to meet draft-ietf-core-coap-10 Table 1
I Added an IANA registration for the URI scheme coap+telSection 162
4 10
Feedback Split coap+tel into coap+smsand coap+ussd
I How else to differ the various transports in the URII Or is the transport to use decided by the implementationI See alsodraft-silverajan-core-coap-alternative-transports-01
5 10
Feedback Response-To-Scheme option
I Should there be a Response-To-Scheme optionadditionally to Response-To-Uri-Host andResponse-To-Uri-Path
I So that a CoAP end-point which receives a request by CoAPover non-IP transport can be instructed to also use thenon-IP transport for the response
I This would imply to add aResponse-To-Telephone-Subscriber and more options forother transports that have other URI schemes than coapand coaps
6 10
Feedback Selection of Transport by Client
I When a server is reachable by various transports howdoes a client decide which transport to use
I Client-side application congurationI Leave it to a proxy which uses cellular network lookupfunctions
7 10
Feedback Potential Threats
I Trigger expensive short messagesI Redirect trac to other addressesI More threats
I Are the security measures in the draft adequateI Whitelisting on serverI Relying on cellular network security (dedicated M2M APNs)I Object security on CoAP payload
8 10
Feedback Message Exchanges
I Figures 11-18 show possible message exchanges whenclient and server have two addresses
I With NON Not using CoAP retransmission capabilityI ACK on different transportI Additional (costly) message on Transport AI Request with Content
I Which ones are allowedI Which ones are meaningful
9 10
Next steps
I Rene Uri schemeI Response-To-Scheme optionI Selection of Message ExchangeI Rene Proxying
10 10
CoAP13 Communicaon13 with13 Alternave13 Transports
Bill Silverajan and Teemu SavolainenCore WG IETF 86 Orlando
031113
Objecves13 (In13 Scope)
bull Unambiguous13 representaon13 of13 transport13 to13 be13 used13 by13 CoAP
bull Details13 how13 the13 transport13 can13 carry13 CoAP13 packet
bull Focus13 is13 on13 what13 CoAP13 communicaons13 requirements13 are
bull Allow13 CoAP13 mechanisms13 to13 exploit13 cross-shy‐layer13 opmisaons
51
031113
Non13 Goals13 (Not13 in13 scope)
bull Applicaon-shy‐level13 QoS13 requirementsbull Real-shy‐me13 constraintsbull Ordering13 reliability13 congeson13 controlbull Applicaon13 and13 network13 adaptaonbull Mobility13 and13 readdressing13 supportbull Network13 protocol13 (eg13 IPsec)13 configuraon
52
031113
Use13 Cases
bull NAT13 and13 Firewall13 traversal13 with13 TCPbull Delay13 Tolerant13 Networkingbull Non-shy‐IP13 Low13 Energy13 Protocols
53
031113
Related13 Work
bull OMA13 Lightweight13 M2M13 Protocolbull CoAP13 over13 SMSGPRSUSSD
54
031113
What13 does13 the13 work13 entail
bull The13 ability13 to13 specify13 end13 point13 idenfiers13 and13 URIs13 to13 reflect13 which13 transport13 CoAP13 can13 use
bull The13 ability13 to13 register13 to13 resource13 directories13 resource13 types13 reflecng13 types13 of13 transport13 available
bull Ability13 for13 mul-shy‐transport13 nodes13 to13 select13 transport13 to13 use13 without13 significant13 alteraon13 to13 CoAP13 packet13 structure
55
031113
Points13 to13 consider
bull Requirements13 for13 transport13 layer13 protocol13 to13 carry13 CoAP13 packets
bull Representaon13 of13 URI13 scheme13 for13 generic13 transport13 protocols
bull Opon13 extensions13 for13 CoAP13 to13 express13 available13 transports
bull Mapping13 and13 message13 sizebull Security13 consideraons
56
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
URI13 =13 scheme13 13 13 authority13 path-shy‐abempty13 [13 query13 ]
bull Within13 the13 scheme13 namebull In13 the13 URI13 pathbull As13 a13 query13 component
57
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
bull Within13 the13 scheme13 namendash coap+tel+15105550101well-shy‐knowncorendash coap+tcpexamplecom5683temperaturendash coap+blel2cap[1234567890AB]4pulse
bull Easy13 URI13 parsing13 for13 transport13 type13 and13 idenfier
bull Each13 new13 scheme13 name13 requires13 IANA13 registraon
58
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
bull In13 the13 URI13 pathndash coaphostexamplecomtransport=tcpwell-shy‐knowncorert=core-shy‐rd
bull Easy13 adopon13 of13 new13 (and13 experimental)13 CoAP13 transports13 without13 IANA13 registraon
bull Caveat13 Uri-shy‐Path13 opon13 is13 a13 Crical13 CoAP13 opon13 see13 secon13 54113 of13 I-shy‐Diep-shy‐core-shy‐coap
59
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
bull As13 a13 URI13 query13 componentndash coaphostexamplecomwell-shy‐knowncorert=core-shy‐rdq=tcp
bull Also13 easy13 to13 adopt13 new13 (and13 experimental)13 CoAP13 transports13 without13 IANA13 registraon
bull Caveat13 Uri-shy‐Query13 opon13 is13 a13 Crical13 CoAP13 opon13 see13 secon13 54113 of13 I-shy‐Diep-shy‐core-shy‐coap
60
031113
URI13 Representaons13 for13 CoAPNon13 standard13 ways
bull Transport13 in13 the13 URI13 authority13 componentndash coaphost[port][transport]13 instead13 of13 coaphost[port]
bull Transport13 as13 a13 service13 URLndash servicecoaptcphostexamplecomwell-shy‐knowncorert=core-shy‐rd
bull Above13 two13 ways13 break13 exisng13 compability13 (although13 both13 are13 based13 on13 valid13 IANA13 URI13 registraons)
61
031113
URI13 Representaons13 for13 CoAPMiscellaneous13 Consideraons
bull Ensure13 that13 transport13 is13 defined13 unambiguously13 (eg13 L2CAP13 used13 by13 both13 BLE13 and13 standard13 Bluetooth13 so13 avoid13 rdquocoap+l2caprdquo13 or13 rdquotransport=l2caprdquo13 or13 rdquoq=l2caprdquondash Can13 be13 done13 as13 WG13 consensusndash Namespace13 approach13 eg13 rdquocoap+blel2caprdquo13 or13 rdquoq=blel2caprdquo
bull Allow13 end-shy‐points13 to13 use13 CoAP13 Resource13 Directory13 to13 register13 alternave13 transports13 and13 idenfiers13 and13 provide13 periodic13 updatesndash Register13 rdquocore-shy‐transportrdquo13 resource13 type
62
031113
Transport13 Consideraons
bull Uniqueness13 of13 end-shy‐point13 idenficaonbull Communicaon13 support13 Unidireconal13 Bidireconal13 1N13 (broadcast13 mulcast13 anycast)13 messaging
bull Binary13 encoding13 Network13 byte13 orderingbull MTU13 correlaon13 with13 CoAP13 PDU13 sizebull Transport13 latency
63
031113
Security13 Consideraons
bull Drar13 does13 not13 introduce13 new13 security13 requirements13 by13 itself
bull There13 may13 be13 privacy13 issues13 if13 nodes13 use13 telephone13 numbers13 or13 MAC13 addresses13 as13 public13 end13 point13 idenfiers
64
Akbar Rahman
IETF 86 March 2013 httpwwwietforgiddraft-rahman-core-sleepy-02txt
Enhanced Sleepy Node Support for CoAP
Introduction
It is expected that in CoAP networks there will be a certain portion of devices that are sleepy and which may occasionally go into a sleep mode (ie go into a low power state to conserve power) and subsequently have reduced CoAP protocol communication ability
This I-D proposes a minimal and efficient mechanism building on the Resource Directory concept (which will be integrated into a CoAP Proxy) to enhance sleepy node support in CoAP networks
Main Question from IETF-85 (Atlanta)
What performance benefit does the proposed Sleepy Node support solution give in a network that already has standard CoAP caching enabled
Sleepy Node Performance Analysis
Experimental Network
1-5 clients
Both Sleepy and Non-
Sleepy servers
Sleepy Node Performance Analysis Network Setup
CoAPSleepyServer(s)
CoAPSleepAwareReverseProxy
CoAP
Client(s)
Request
Response
Sleep9AwareCoREResourceDirectoryCapability
PublishedSleepParameters
Sleep9AwareCoAPStoreandForwardCapability Response
Request
SleepAwareCoAP503ResponseCapability
CoAPCachingCapability
bull Server supports publishing sleep parameters to proxy bull Eg Irsquom going to be asleep for X seconds
bull Proxy supports sleep-awareness capabilities bull Proxy also supports caching capability based off of maxAge bull Protocol flow similar to approach of Figure 1 (Synchronous RD Based Sleep
Tracking) of I-D
Proxy capabilities can be selectively enableddisabled
Proxy ndash Server Interface
Client ndash Proxy Interface
CoAP Sleep-Aware Reverse Proxy Features CoRE Sleep-aware Resource Directory
Support storing published sleep parameters from CoAP servers sleepState (AWAKE ASLEEP) sleepDuration
Sleep-aware CoAP 503 Response Capability If CoAP request to a sleeping server is received proxy returns a
lsquo503 Retry-Afterrsquo response to client 503 contains a timestamp indicating when the sever will wake back up
(timestamp delivered in CoAP maxAge option) Sleep-aware CoAP Store-and-Forward Capability
If CoAP request to a sleeping server is received proxy stores request until server wakes up and then forwards it
Caching capability Cache GET responses from server if maxAge option is present
(this is not a sleep aware feature)
Goals of Performance Analysis
For networks having sleepy servers provide measurements to quantify the impact that CoAP sleep-awareness capabilities can have
See if sleep-awareness capabilities can
provide additional benefits even when CoAP caching is used
Overview of Performance Analysis Performed The analysis was broken up into a set of test scenarios Each test scenario used a different combination of the following
variables Client issued GET requests Server was configured as a sleepy or non-sleepy server Proxy caching of GET responses was enabled or disabled Proxy sleep-aware 503 response capability was enabled or disabled Proxy store-and-forward capability was enabled or disabled maxAge in GET responses ndash Two values were tested 60sec and 5sec of Clients ndash Two values were used ndash 1 client and 5 clients
For comparison purposes the following were held constant across all test scenarios Client issued a fixed number of requests (100) across all test scenarios Client used a delay between each GET request (35sec) to better exercise
proxyrsquos caching and sleep-awareness capabilities For sleepy server test scenarios the server slept 60 sec awake for 3 sec
Format of Results The following results were collected for each
test scenario
Breakdown of the and types of transactions occurring between clientproxyserver
ldquoGETrdquo ndash Test Scenario Results
GET ndash Description of Test Scenarios
TestScenarios-GET
Scenario
CoAPSleepyServerSe7ngs CoAPSleepAwareReverseProxySe7ngs CoAPClientSe7ngs
SleepDuragton(sec)
AwakeDuragton(sec)
maxAge(sec) Caching SleepAwareSAF+
503NumberofClients
NumberofGETs
DelayBetweenClient
Requests(sec)
1a 0 Always 60 Enabled Disabled 1 100 35
1b 60 3 60 Enabled Disabled 1 100 35
1c 60 3 60 Enabled Enabled 1 100 35
2a 0 Always 60 Enabled Disabled 5 100 35
2b 60 3 60 Enabled Disabled 5 100 35
2c 60 3 60 Enabled Enabled 5 100 35
3a 0 Always 5 Enabled Disabled 5 100 35
3b 60 3 5 Enabled Disabled 5 100 35
3c 60 3 5 Enabled Enabled 5 100 35
ldquoGETrdquo ndash Test Scenario 1 Results
maxAge = 60 and 1 Client
GET ndash Scenario 1 ClientProxy Interface Transaction Mix
Scenarios 1a - Non-Sleepy Server Caching Proxy maxAge = 60sec 1b- Sleepy Server Caching Proxy maxAge = 60sec 1c - Sleepy Server Sleep Aware Proxy maxAge = 60sec
Sleep Aware Proxy has better performance for sleepy servers
0
100
200
300
400
500
600
700
1a 1b 1c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
GET ndash Scenario 1 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
Scenarios 1a - Non-Sleepy Server Caching Proxy maxAge = 60sec 1b- Sleepy Server Caching Proxy maxAge = 60sec 1c - Sleepy Server Sleep Aware Proxy maxAge = 60sec
0
100
200
300
400
500
600
700
800
1a 1b 1c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
ldquoGETrdquo ndash Test Scenario 2 Results
maxAge = 60 and 5 Clients
GET ndash Scenario 2 ClientProxy Interface Transaction Mix
Sleep Aware Proxy has slightly better performance for sleepy servers
0
200
400
600
800
1000
1200
1400
2a 2b 2c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
Scenarios 2a - Non-Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2b- Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2c - Sleepy Server Sleep Aware Proxy maxAge = 60sec 5 Clients
See ldquoExperimental Artifactsrdquo Note 1
GET ndash Scenario 2 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has slightly better performance for sleepy servers
0
50
100
150
200
250
300
350
400
2a 2b 2c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
Scenarios 2a - Non-Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2b- Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2c - Sleepy Server Sleep Aware Proxy maxAge = 60sec 5 Clients
See ldquoExperimental Artifactsrdquo Note 2
Experimental Artifacts Note 1
Currently in the experiment the sleep aware proxy checks the cached state of a resource before putting a request into its Store-and-forward queue while a server is sleeping Once in the queue the proxy unconditionally forwards the queued requests to the server once it wakes up This is not the most efficient setup and can easily be improved If the proxy instead checks its cache again before forwarding each queued request it may not need to forward the request to the server For example if there are two queued GET requests in the proxyrsquos queue that address the same resource Only the first request needs to be sent to the server the second request can use the cached response from the first request
Note 2 Currently in the experiment the sleepy server sends a sleepState PUT request to the
proxy each time it goes to sleep This is not the most efficient setup and can easily be improved For example if the server assumes that the proxy can keep track of its ONOFF cycles with its internal timers (eg as per Fig 1 of I-D) then the number of messages from the sleepy server dramatically goes down
ldquoGETrdquo ndash Test Scenario 3 Results
maxAge = 5 and 5 Clients
GET ndash Scenario 3 ClientProxy Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
Scenarios 3a - Non-Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3b- Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3c - Sleepy Server Sleep Aware Proxy maxAge = 5sec 5 Clients
0
500
1000
1500
2000
2500
3000
3500
4000
4500
5000
3a 3b 3c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
GET ndash Scenario 3 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
0
1000
2000
3000
4000
5000
6000
7000
3a 3b 3c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
Scenarios 3a - Non-Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3b- Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3c - Sleepy Server Sleep Aware Proxy maxAge = 5sec 5 Clients
Conclusions
Conclusions These results show that sleep-aware CoAP
proxy features can significantly optimize communication with sleepy servers in most scenarios
These results also show that sleep-
awareness capabilities can provide additional benefits above and beyond CoAP caching in most scenarios
Backup
Current CoAP Support of Sleepy Node (12)
CoAP proxies can use a previously cached response to service a new GET request for a sleepy origin server (as in HTTP) But if no valid cache then proxy has to attempt to
retrieve and may fail if origin server is sleeping [I-Dietf-core-coap]
Clients can discover list of resources from RD (GET rd-lookuphellip) for sleepy servers But attempt to GET resource from sleepy origin server
may fail if origin server is sleeping [IDietf-core-link-format amp IDshelby-core-resource-
directory]
Current CoAP Support of Sleepy Node (22)
Lower layer support for sleepy nodes in most wireless technologies (eg WiFi ZigBee) But limited to MAC packet scheduling for sleepy nodes
and not aware of specific needs of IP applications (like CoAP)
Proposal ndash RD Based Sleep Tracking (14)
The current CoAP approach to support sleepy nodes can be significantly improved by introducing RD based mechanisms for a CoAP client to determine whether A targeted resource is located on a sleepy server A sleepy server is currently in sleep mode or not
There is any associated caching Proxy (possibly the RD itself) for a sleepy server
Proposal ndash RD Based Sleep Tracking (24)
We define the following new RD attributes to characterize the properties of a sleepy node SleepState - Indicates whether the node is currently in
sleep mode or not (ie Sleeping or Awake) SleepDuration - Indicates the maximum duration of time
that the node stays in sleep mode TimeSleeping - Indicates the length of time the node
has been sleeping (ie if Sleep State = Sleeping) NextSleep - Indicates the next time the node will go to
sleep (ie if Sleep State = Awake)
CachingProxy ndash Indicates the caching proxy of the sleepy node (ie the RD itself or another node)
Proposal ndash RD Based Sleep Tracking (34)
These attributes are all server (node) level and are new parameters added to the RD URI Template Variables
Finally we also define a new lookup-type (ss) for the RD lookup interface specified in [I-Dshelby-core-resource-directory] This new lookup-type supports looking up the
ldquoSleepStaterdquo (ss) of a specified end-point
Proposal ndash RD Based Sleep Tracking (44)
The three time based parameters (SleepDuration TimeSleeping NextSleep) can be based on either an absolute network time (for a time synchronized network) or a relative local time (measured at the local node)
Following the approach of [I-Dietf-core-link-format] and [I-Dshelby-core-resource-directory] sleep parameters for sleepy servers can be stored by the server in the RD and accessed by all interested clients
Examples of using these parameters in a synchronous or asynchronous manner are shown in the I-D
http6lowappnet coreIETF86 2013-03-12-13
We assume people have read the drafts
Meetings serve to advance difficult issues by making good use of face-to-face communications
Note Well Be aware of the IPR principles according to RFC 3979 and its updates
uumlBlue sheetsuumlScribe(s)
96
drar-shy‐iep-shy‐core-shy‐coapsubmiqed13 to13 IESG
2013-shy‐03-shy‐13
97
OMA Lightweight M2M Overview(A new standard using lots of IETF specs including DTLS
CoAP Block Observe Resource Directory SenMLhellip)
Zach ShelbyCoRE WG IETF-86 Orlando
OMA Lightweight M2Mbull Open Mobile Alliance is well known for Device Management (DM)bull OMA Lightweight M2M is a new standard from the alliance
ndash Focused on constrained Cellular and sensor network M2M devicesndash Driven by leading operators and vendors
bull Scopendash Interfaces protocol amp security between Device and Serverndash Object and Resource modelndash Bootstrap Device Access Control Connectivity and Firmware Objects
bull Draft Specifications are availablendash httpmemberopenmobileallianceorgftpPublic_documentsDM
LightweightM2MPermanent_documentsOMA-TS-LightweightM2M-V1_0_0-20130301-Dzip
bull Timelinendash Requirements and Architecture completed 3Q2012ndash Spec ready for Consistency Review 2Q2013ndash Candidate Approval expected 3Q2013
2 CoRE WG IETF-86 Orlando
Architecture
3
Scope of LWM2M
CoRE WG IETF-86 Orlando
Object Model
bull A Client has one or more Object Instancesbull An Object is a collection of Resourcesbull A Resource is an atomic piece of information
ndash Read Written or Executed
bull Resources can have multiple instancesbull Objects and Resources are identified by a
16-bit Integer Instances by an 8-bit Integerbull ObjectsResources are accessed with
simple URIs Object IDObject InstanceResource ID
eg 1213
4 CoRE WG IETF-86 Orlando
CoRE WG IETF-86 Orlando
CoRE Resource Directory
draft-shelby-core-resource-directory-05
Z Shelby C Bormann S Krco
Backgroundbull Not a new concept
ndash think web search engine or any link directorybull Defines the interfaces to a Resource Directorybull Based on Web Linking framework and the CoRE Link Formatbull Generic REST design for use over HTTP and CoAPbull Used by OMA Lightweight M2Mbull Has already been deployed
ndash In traffic monitoring systemsndash In street lighting systemsndash For vehicular asset trackingndash By a major Cellular M2M operator
Changes since -04
bull Restricted Update to parameter updatesbull Added pagination support for the Lookup interfacebull Changed rt= to et= for the registration amp update
interfacebull Added group support
Group Management
bull RD now includes group management featuresbull New Group Function Set
ndash Register a groupbull Group name domain multicast address endpoint members
ndash Remove a groupbull Group lookup using the Lookup Function Set
ndash List registered groupsndash Find the members of a groupndash Find groups with certain endpoints or resources
Registering a Group
EP RD
| |
| - POST rd-groupgp=lights ltgtep=node1 --gt |
| |
| |
| lt---- 201 Created Location rd-group12 ---- |
| |
Req POST coaprdexamplecomrd-groupgp=lights
Payload
ltgtep=node1
ltgtep=node2
Res 201 Created
Location rd-group12
Looking up Group Members
Client RD
| |
| ----- GET rd-lookupepgp=lights1 ----------------------gt |
| |
| |
| lt-- 205 Content ltrdgtd=domain1ltrdgtd=domain2 --------- |
| |
Req GET rd-lookupepgp=lights1
Res 205 Content
ltcoaphostportgtep=node1
ltcoaphostportgtep=node2rdquo
Things for the futurebull Support for JSON representation of Web Links
ndash httptoolsietforgiddraft-bormann-core-links-json-02txtbull Registry for RD registration query parameters
ndash Already OMA Lightweight has defined some new onesbull More examples
Group 3 ldquonew workrdquo(continued)
109
drar-shy‐greevenbosch-shy‐core-shy‐profile-shy‐descripon-shy‐01Bert13 GreevenboschJeroen13 Hoebeke
Isam13 IshaqFloris13 Van13 den13 Abeele
Descripon
bull JSON13 format13 for13 signalling13 the13 servers13 capabilies
bull Signalling13 of13 supported13 opons13 media13 types13 and13 block13 sizendash Other13 items13 can13 be13 added
bull Filtering13 on13 specific13 fields13 through13 URI-shy‐Querybull Link13 hqpdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐profile-shy‐descripon
well-shy‐knownprofile
bull To13 acquire13 profile13 data13 of13 resources13 on13 a13 parcular13 service13 the13 well-shy‐knownprofile13 URI-shy‐path13 is13 introduced
bull For13 example13 to13 get13 all13 informaon13 from13 sensors13 served13 by13 wwwexampleorg13 we13 can13 do13 a13 GET13 to13 coapwwwexampleorgwell-shy‐knownprofile
bull Filtering13 on13 parcular13 resources13 is13 done13 through13 URI-shy‐Queries
Format
bull Currently13 the13 following13 fields13 are13 definedndash ldquopathrdquo13 contains13 the13 URI-shy‐path13 associated13 with13 a13 resource
ndash ldquooprdquo13 a13 numerical13 list13 of13 supported13 opon13 numbers
ndash ldquocfrdquo13 a13 numerical13 list13 of13 supported13 content-shy‐format13 numbers
ndash ldquob1srdquo13 ldquob2srdquo13 supported13 block13 sizes13 for13 Block113 and13 Block213 respecvely
Examplebull On13 the13 right13 is13 an13 example13 of13 a13 camera13 sensor13 at13 coapwwwexampleorgcam13 that13 supports13 the13 Uri-shy‐Host13 (3)13 ETag13 (4)13 Uri-shy‐Port13 (7)13 Uri-shy‐Path13 (11)13 Content-shy‐Format13 (12)13 Token13 (19)13 Block213 (23)13 and13 Proxy-shy‐Uri13 (35)13 opons
bull The13 supported13 content13 formats13 are13 textplain13 (0)13 applicaon13 link-shy‐format13 (40)13 and13 applicaonjson13 (50)
bull The13 supported13 Block213 can13 use13 25613 or13 51213 byte13 blocks
Req13 GET13 coapwwwexampleorgwell-shy‐knownprofile13 Res13 20513 Content13 (applicationjson)13 13 13 13 profile13 13 13 13 13 13 13 13 pathcam13 13 13 13 op[3471112192335]13 13 13 13 13 cf[04050]13 13 13 13 13 b2s[45]13 13 13 13
Filtering13 through13 use13 of13 URI-shy‐Query
bull Filtering13 can13 be13 done13 through13 the13 URI-shy‐Querybull Query13 format13 N=V
ndash N13 is13 a13 profile13 fieldndash V13 is13 the13 desired13 value
bull Examplesndash To13 find13 resources13 that13 support13 content13 format13 ldquoapplicaonjsonrdquo
13 GET13 wwwexampleorgwell-shy‐knownprofilecf=50ndash To13 get13 informaon13 about13 the13 camera
13 GET13 wwwexampleorgwell-shy‐knownprofilepath=cam
Open13 issues
bull Which13 other13 profile13 data13 needs13 signallingndash Content-shy‐type13 for13 different13 methods
bull Fix13 the13 order13 in13 which13 the13 profile13 fields13 must13 appearndash Non-shy‐fixed13 order13 easier13 extensible
bull Inheritance13 of13 a13 profile13 descriponbull Extend13 usage13 to13 signal13 the13 client13 profilebull Integraon13 with13 link13 format
Thank13 youQuesons
drar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval-shy‐00
Bert13 Greevenbosch
Descripon
bull The13 ldquoMinimumRequestInterval13 opon13 can13 be13 used13 to13 indicate13 the13 minimum13 me13 between13 two13 requests13 in13 a13 transacon
bull Originally13 intended13 for13 Block13 but13 also13 usable13 for13 other13 transaconsndash Example13 browsing13 a13 server
bull The13 goal13 is13 to13 reduce13 the13 server13 load13 and13 network13 traffic
bull Link13 hqpsdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval
Usage
bull The13 client13 keeps13 the13 server13 informed13 about13 its13 request13 speed13 through13 inclusion13 of13 the13 ldquoMinimumRequestIntervalrdquo13 opon
bull In13 responses13 the13 server13 fixes13 the13 minimum13 request13 interval13 through13 the13 same13 opon
bull The13 client13 obeys13 the13 speed13 indicated13 by13 the13 server
bull The13 client13 can13 send13 slower13 but13 not13 faster
Advantages
bull The13 server13 has13 means13 to13 limit13 the13 amount13 of13 incoming13 traffic
bull The13 server13 can13 prevent13 to13 become13 overloaded13 with13 too13 many13 tasks
bull The13 server13 does13 not13 need13 arficially13 slow13 down13 the13 client13 by13 sending13 late13 ACKsndash No13 need13 to13 keep13 track13 of13 delayed13 ACKsndash The13 server13 can13 perform13 other13 tasks13 instead
bull Reduced13 network13 traffic
Thank13 youQuesons
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-links-json-02txt
123
RFC 6690 (link-format) documents are somewhat foreign to many web app developerssect would prefer to have them in JSON format
There is no standard way to represent link-format documents in applicationssect but everyone knows how to handle JSON
Define a standard JSON translation for link-format
Itrsquos
not
rock
et
scien
ce
ltsensorsgtct=40title=Sensor Index ltsensorstempgtrt=temperature-cif=sensor ltsensorslightgtrt=light-luxif=sensor lthttpwwwexamplecomsensorst123gt anchor=sensorstemprel=describedby lttgtanchor=sensorstemprel=alternate [hrefsensorsct40titleSensor Index hrefsensorstemprttemperature-cifsensor hrefsensorslightrtlight-luxifsensor hrefhttpwwwexamplecomsensorst123 anchorsensorstempreldescribedby hreftanchorsensorstemprelalternate]
124
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-ipsec-for-coap-00txt
IPsec definitions for CoAP Mostly placeholder at this time Who has implementation experience with this
125
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-cross-reverse-convention-00txt
This draft has two lines of payload(based on a WGLC comment by Cullen Jennings)
coap12344567foobara=3
httpwwwproxycomwellknowncore-translate1234_4567foobara=3
Is that a useful convention to have
126
Insert CI slides here
127
128
0
5
10
15
20
25
30
35
40
10 20 30 40 50 60 70
good
put (
pps)
pps
Goodput vs pps (Econotags)
goodput
[Khattak preliminary]
Congestion Control
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-cocoa-00txt
ldquoadvancedrdquo cc (The draft is just a first shot) Others may have better ideas
129
Insert post-WGLC discussion slides here
130
Stop Continue Start
131
An Agile Retrospective
http6lowappnet coreIETF86 2013-03-12-13
Stop
132
Endless new CoAP optionssect instead use RESTful as much as possible
Move general security lifecycle out Looking at theoretical problems
http6lowappnet coreIETF86 2013-03-12-13
Continue
Interops Running code Look at real-world examples and deployments Solve their actual problems
sect Unilateral enhancements eg higher performance congestion control
sect Transports (SMS hellip)sect Make Web linking and Directories more and more usefulsect RESTful Design Paradigms for real-world problems
133
http6lowappnet coreIETF86 2013-03-12-13
Start
Further push into the (browser) web world (HTML5 browser security)
Specific supporting worksect SenMLsect URI work (dev URN hellip)sect Security Processes (next slide)
Spin outsect (We donrsquot really get to decide where this is done)
134
http6lowappnet coreIETF86 2013-03-12-13
Security
Integrate Application Network Group Keyingsect Tunnel-free setup
Donrsquot redo what has been done alreadysect ZigBee IP is finesect But what about other scenarios
Simple REST interfaces for working with keying materials and authorizationsect Start with defining objectives
Object Security for Constrained Nodes135
Re-chartering CoREWhat do we want to do now that wersquore grown up
Zach ShelbyCoRE WG IETF-86 Orlando
What is the scope
bull So we have a protocol and Web Linking what next
bull Keep with what we know besthellip1 Enhancements around CoAP2 New transports for CoAP3 New representations for Web Links4 General application layer solutions
CoRE WG IETF-86 Orlando 2
Enhancements around CoAP
bull Advanced congestion control
CoRE WG IETF-86 Orlando 3
New Transports for CoAP
bull Infrastructure for CoAP over foondash httptoolsietforgiddraft-silverajan-core-
coap-alternative-transports-01txtbull CoAP over SMS
ndash httptoolsietforgiddraft-becker-core-coap-sms-gprs-03txt
ndash OMA Lightweightbull CoAP over TCP
ndash httptoolsietforgiddraft-li-core-coap-payload-length-option-01txt
CoRE WG IETF-86 Orlando 4
New support for Web Links
bull JSON Web Linksndash httptoolsietforgiddraft-bormann-core-links-
json-02txt
2332010 CoRE WG IETF-77 Anaheim 5
General application layer solutions
bull Resource Directoryndash httptoolsietforgiddraft-shelby-core-
resource-directory-05txtndash OMA Lightweight
2332010 CoRE WG IETF-77 Anaheim 6
http6lowappnet coreIETF86 2013-03-12-13
We assume people have read the drafts
Meetings serve to advance difficult issues by making good use of face-to-face communications
Note Well Be aware of the IPR principles according to RFC 3979 and its updates
uumlBlue sheetsuumlScribe(s)httptoolsietforgwgcoreminutes
2
http6lowappnet coreIETF86 2013-03-12-13
Milestones (from WG charter page)httpdatatrackerietforgwgcorecharter
Document submissions to IESG
Dec 2012 CoAP protocol specification with mapping to HTTP Rest API to IESG Feb 2013 Blockwise transfers in CoAP to IESG Feb 2013 Observing Resources in CoAP to IESG Apr 2013 Group Communication for CoAP to IESG Dec 2099 HOLD (date TBD) Constrained security
bootstrapping specification to IESG
3
0
01
02
03
04
05
06
07
08
09
1
10 20 30 40 50 60 70 80 90 100
Bad
ness
rem
aini
ng
Amount of time spent
asymptotic(x)
You are here
4
0
01
02
03
04
05
06
07
08
09
1
10 20 30 40 50 60 70 80 90 100
Bad
ness
rem
aini
ng
Amount of time spent
asymptotic(x)
You are here
5
Group 1 2nd WGLCcoap-13 coap-14
6
http6lowappnet coreIETF86 2013-03-12-13
draft-ietf-core-coap-14
7
Will be published a couple of hours from nowsect please do read and comment again during IETF last call
Changes from ndash13sect Clarify that payload sniffing is acceptable only if no Content-
Format was suppliedsect Clarify that safe-to-forward options in a 203 Valid response
update the cachesect Clarify URI examples (Appendix B)sect Numerous editorial improvements and clarifications
sect Made Accept option non-repeatable
Repeatable13 Accept13 Opon
bull Problem
bull Soluon13 A13 ldquoJust13 do13 not13 do13 itrdquo13 and13 keep13 it13 generalbull Soluon13 B13 Change13 to13 non-shy‐repeatable
+ Predictable13 behavior13 when13 going13 through13 different13 caches+ Makes13 Accept13 and13 proxies13 easier13 to13 understand+ We13 have13 out-shy‐of-shy‐band13 content13 negoaon13 (ct=ldquoltAgt13 ltBgtrdquo)+ Can13 be13 added13 later13 as13 extension13 if13 really13 needed
GET13 someresAccept13 A13 B13
GET13 someresAccept13 B13 A13
someres13 (A13 B)13 =gt13 ltAgt
someres13 (B13 A)13 =gt13 ltAgt
Proxy
Also13 causesmulple13 observe13 relaonships
Cacheblowup
someresltAgt
Origin13 Server
Group 1a WGLC processingobserve block
9
http6lowappnet coreIETF86 2013-03-12-13
draft-ietf-core-observe-08
10
Changes from ndash07 to ndash08sect Expanded text on transmitting notification while a previous
transmission is pending (242)sect Changed reordering detection to use a fixed time span of 128
seconds instead of EXCHANGE_LIFETIME (276)sect Removed the use of the freshness model to determine if the
client is still on the list of observers
http6lowappnet coreIETF86 2013-03-12-13
draft-ietf-core-block-10
11
Still awaits grand editorial rewritesect right after coap-14 is shipped
http6lowappnet coreIETF86 2013-03-12-13
Tickets
hellip are our way to make the steps forward are at
http toolsietforgwgcore Updates are sent to the mailing list
sect Please review When we close a ticket please review once more
12
Group 2 groupcomm
13
Akbar RahmanEsko Dijk
IETF 86 March 2013httpwwwietforgiddraft-ietf-core-groupcomm-05txt
Group Communication for CoAP
Summary of Changes (14)
n I-D had two updates (Rev 04 amp 05) after IETF-85 (Atlanta) Many of the updates were due to the detailed review by Peter van der Stokn Thank you Peter for your valuable comments
n Changes from ietf-03 to ietf-04 n Section 23 (Potential Solutions for Group Communications) moved to
draft-dijk-core-groupcomm-misc (266)n Added reference to draft-keoh-tls-multicast-security to section 6 (Security
Considerations) n Appendix B (CoAP-Observe Alternative to Group Communications) moved
to draft-dijk-core-groupcomm-misc (267) n Deleted section 8 (Conclusions) as it is redundant (268) n Simplified light switch use case (269) by splitting into basic operations and
additional functions (269)
Summary of Changes (24)
n Changes from ietf-03 to ietf-04 (Continued) n Moved section 37 (CoAP Multicast and HTTP Unicast Interworking) to
draft-dijk-core-groupcomm-misc (270) n Moved section 331 (DNS-SD) and 332 (CoRE Resource Directory) to
draft-dijk-core-groupcomm-miscClarified that DNS based features are optional (272)
n Focus section 35 (Configuring Group Membership) on a single proposed solution
n Scope of section 53 (Use of MLD) widened to multicast destination advertisement methods in general
n Rewrote section 22 (Scope) for improved readibility n Moved use cases that are not adressed to draft-dijk-core-groupcomm-miscn Various editorial updates for improved readibility
Summary of Changes (34)
n Changes from ietf-04 to ietf-05 n Added a new section 39 (Exceptions) that highlights that IP multicast (and
hence group communications) is not always available (187) n Included guidelines on when (not) to use CoAP responses to multicast
requests and when (not) to accept multicast requests (273) n Added guideline on use of core-block for minimizing response size (275)n Restructured section 6 (Security Considerations) to more fully describe
threats and threat mitigation (277) n Clearly indicated that DNS resolution and reverse DNS lookup are optional n Removed confusing text about a single group having multiple IP addresses
If multiple IP addresses are required then multiple groups (with the same members) should be created
n Removed repetitive text about the fact that group communications is not guaranteed
Summary of Changes (44)
n Changes from ietf-04 to ietf-05 (Continued) n Merged previous section 52 (Multicast Routing) into 31 (IP Multicast
Routing Background) and added link to section 52 (Advertising Membership of Multicast Groups)
n Clarified text in section 38 (Congestion Control) regarding precedence of use of IP multicast domains (ie first try to use link-local scope then site-local scope and only use global IP Communication for CoAP multicast as a last resort)
n Extended group resource manipulation guidelines with use of preconfigured portspaths for the multicast group
n Consolidated all text relating to ports in a new section 33 (Port Configuration)
n Clarified that all methods (GETPUTPOST) for configuring group membership in endpoints should be unicast (and not multicast) in section 37 (Configuring Group Membership In Endpoints)
n Various editorial updates for improved readability
Discussion item (11)
n Solution for Configuring Group Membership (no ticket)n Example of (unicast) configuring an endpoint to be part of one multicast
groupReq POST gp (Content-Format applicationjson)
n floor1westbldg6examplecom ip ff154200f7feed3714cb Res 204 Changed
n Where the ldquogprdquo resource has resource type (rt) ldquocoregprdquo which is defined for this purpose
n Question Do we want specify such a solution (or for example leave it completely up to implementation)
Open Issues(15)
n Review Groupcomm requirements language (271)n Decision made to keep requirements language for informational draftn Each use of MAYMUSTSHOULD etc is to be reviewed
Open Issues(25)
n Add section on multicast via Proxy and its limitations (274)n Add a section to explain the issues amp limitations of doing CoAP multicast
requests via a CoAP Proxy n Goal is to warn and guide implementers in this subject n Also such a section would provide a placeholderreminder of the problems
that might be addressed further in the futuren Based on IETF 85 CoRE WG meeting discussion on Multicast CoAP
requests via a Proxy Discussion summary for referencen Aggregation of responses in a proxy is difficult since it doesnt know
when to stop aggregating responses n SIP tried to deal with this problem but didnt solve it n There may be an expectancy of CoAP client to get single response
back from proxy not multiple The client in this case may not even know what it could expect It may not even know the Proxy-URI contains a multicast target
n Presented via-proxy use case exposes gap in the core-coap specification regarding multicast via proxy (Note Expectation is that core-coap wonrsquot address it in the first planned RFC release)
Open Issues(35)
n Issues with twomultiple Resource Directories in use case (280)n Some potential issues with RD came out of review Peter van der Stok and
WG discussion IETF85 n There are two RD servers use case shows that only one is found despite
the fact that site-local multicast is used - should be two RDs found n Proposal simplify use case to a single RD server on the backbone to avoid
such RD-specific issues like synchronization of RD information between servers
Open Issues(45)
n Add single-subnet configuration to use cases (278)n Suggested by review Peter van der Stok and IETF85 WG discussion that
its best to start explaining the simplebasic cases and then gradually build up complexity
n Simplest case not shown yet would be a single subnet network configuration which is currently not present in the I-D only the 2-subnet configuration of Fig 1
n Question Do we need to add such case or doesnt it add muchn (Note that core-coap Figure 22 already shows the simplest case of link-local
multicast)
Open Issues(55)
n Add use case with controller (client) located on the backbone (279)n Suggested by discussion following review Peter van der Stok n Case missing where a controller (client) is located on the backbonen Question Do we need to add such case or does it add much
Group 2a other old friends
25
Angelo Castellani Salvatore Loreto Akbar Rahman Thomas Fossati Esko Dijk
IETF 86 March 2013httpwwwietforgiddraft-castellani-core-http-mapping-07txt
Best Practices for HTTP-CoAP Mapping
Implementation
Summary of Changes (from -06 rev)
n Based on discussion at last IETF-85 (Atlanta)n Clarification of HTTP-CoAP Proxies
n Definitionn Placementn Benefits
n Clarification of HTTP-CoAP URI mapping options
Goals of I-D
n For Reverse HTTP-CoAP Cross Protocol Proxyn Provide more detailed information to proxy designers (beyond
Section 10 of [I-Dietf-core-coap]) to help implement proxies that correctly inter-work with other CoAP and HTTP clientserver implementations that adhere to the specifications
n Define a consistent set of guidelines that a HTTP-to-CoAP proxy implementation MAY adhere to The main reason of adhering to such guidelines is to reduce variation between proxy implementations thereby increasing interoperabilityn As an example use case a proxy conforming to these guidelines made
by vendor A can be easily replaced by a proxy from vendor B that also conforms to the guidelines
I-D Outline
n Guidance on HTTP to CoAP URI mappingn HTTP-CoAP Reverse cross-protocol proxy implementation
n Placementn Response code amp media type translationsn Caching and congestion controln Cache refresh via Observen Use of CoAP blockwise transfern Security translation
n Security Considerationsn Traffic overflown Handling secured exchanges
Definitions (12)
n Cross-Protocol Proxy (or Cross Proxy) is a proxy performing a cross- protocol mapping in the context of this document a HTTP-CoAP (HC) mapping A Cross-Protocol Proxy can behave as a Forward Proxy Reverse Proxy or Interception Proxy n Note In this document we focus on the Reverse Proxy mode of the
Cross-Protocol Proxy
n Forward Proxy a message forwarding agent that is selected by the client usually via local configuration rules to receive requests for some type(s) of absolute URI and to attempt to satisfy those requests via translation to the protocol indicated by the absolute URI The user decides (is willing to) use the proxy as the forwardingdereferencing agent for a predefined subset of the URI space
Definitions (22)
n Reverse Proxy a receiving agent that acts as a layer above some other server(s) and translates the received requests to the underlying servers protocol It behaves as an origin (HTTP) server on its connection towards the (HTTP) client and as a (CoAP) client on its connection towards the (CoAP) origin server The (HTTP) client uses the origin-form [I-Dietf-httpbis-p1-messaging] as a request- target URI
n Reverse and Forward proxies are technically very similar with main differences being that the former appears to a client as an origin server while the latter does not and that clients may be unaware they are communicating with a proxy
Reverse Cross-Protocol Proxy Deployment Scenario
HTTP-CoAP Response Code Mapping
Implementation Experience
n Direct experience from the draft authorsn Squid HTTP-CoAP mapping module
n University of Padovan httptelecomdeiunipditiotn Both Forward and Interception operation supported
n HTTP-CoAP proxy based on EvCoAPn KoanLogic University of Bologna and Salvatore
Loreto (as individual)n httpsgithubcomkoanlogicwebthingstreemasterbridgesw
libevcoapn The document is open to input from other implementations
Next Steps
n Does the WG recommend adoptionn Intended status Informational Best Practicen Purpose Reduce arbitrary variation between proxy
implementations thereby increasing interoperability
Backup
HTTP to CoAP URI Mapping Options (12)
n Embedded Mapping n In an embedded mapping approach the HTTP URI has embedded
inside it the authority and path part of the CoAP URI n Example The CoAP resource nodecoapsomethingnetfoo can
be accessed by an HTTP client by inserting in the request httphc-proxysomethingnetcoapnodecoapsomethingnetfoo The Cross-Protocol Proxy then maps the URI to coapnodecoapsomethingnetfoo
HTTP to CoAP URI Mapping Options (22)
n Homogeneous Mapping n In a homogeneous mapping approach only the scheme portion of the URI
needs to be mapped The rest of the URI (ie authority path etc) remains unchanged
n Example The CoAP resource coapnodecoapsomethingnetfoo can be accessed by an HTTP client by requesting httpnodecoapsomethingnetfoo The Cross-Protocol Proxy receiving the request is responsible to map the URI to coapnodecoapsomethingnetfoo
n Background info n The assumption in this case is that the HTTP client would be able to
successfully resolve nodecoapsomethingnet using DNS infrastructure to return the IP address of the HC proxy Most likely this would be through a two step DNS lookup where the first DNS lookup would resolve somethingnet using public DNS infrastructure
n Then the second DNS lookup on the subdomain coap and the host node would typically be resolved by a DNS server operated by the owner of domain somethingnet So this domain owner can manage its own internal node names and subdomain allocation which would correspond to the CoAP namespace
Group 3 ldquonew workrdquo
39
Transport of CoAP over SMS USSD and GPRSdraft-becker-core-coap-sms-gprs-03
Markus Becker Kepeng LiKoojana Kuladinithi Thomas Poumltsch
CoRE WG IETF-86 Orlando
1 10
ScenariosI In M2M communication IP connectivity is not alwayssupported by the constrained end-points
I Power savingI Coverage (GPRS 3G LTE)
I SMS and USSD based communication is almost alwayssupported
210
Changes from draft-01 to draft-03 (1)
I Added possible CONNONACK interactions Section 5
I Option name changed from Reply-To- to Response-To-Section 16 and Section 101
I Added URI schemeEg coap+tel+15105550101well-knowncore Section 11
I Added possible M2M proxy scenarios Section 14
3 10
Changes from draft-01 to draft-03 (2)
I Added reference to bormann-coap-misc for other SMSencoding Section 71
I Updated requirements on Uri-Host and Uri-Port forcoap+tel Section 10
I Added security considerations Transport and ObjectSecurity Section 15
I Chose CoAP option numbers and updated the optionnumber table to meet draft-ietf-core-coap-10 Table 1
I Added an IANA registration for the URI scheme coap+telSection 162
4 10
Feedback Split coap+tel into coap+smsand coap+ussd
I How else to differ the various transports in the URII Or is the transport to use decided by the implementationI See alsodraft-silverajan-core-coap-alternative-transports-01
5 10
Feedback Response-To-Scheme option
I Should there be a Response-To-Scheme optionadditionally to Response-To-Uri-Host andResponse-To-Uri-Path
I So that a CoAP end-point which receives a request by CoAPover non-IP transport can be instructed to also use thenon-IP transport for the response
I This would imply to add aResponse-To-Telephone-Subscriber and more options forother transports that have other URI schemes than coapand coaps
6 10
Feedback Selection of Transport by Client
I When a server is reachable by various transports howdoes a client decide which transport to use
I Client-side application congurationI Leave it to a proxy which uses cellular network lookupfunctions
7 10
Feedback Potential Threats
I Trigger expensive short messagesI Redirect trac to other addressesI More threats
I Are the security measures in the draft adequateI Whitelisting on serverI Relying on cellular network security (dedicated M2M APNs)I Object security on CoAP payload
8 10
Feedback Message Exchanges
I Figures 11-18 show possible message exchanges whenclient and server have two addresses
I With NON Not using CoAP retransmission capabilityI ACK on different transportI Additional (costly) message on Transport AI Request with Content
I Which ones are allowedI Which ones are meaningful
9 10
Next steps
I Rene Uri schemeI Response-To-Scheme optionI Selection of Message ExchangeI Rene Proxying
10 10
CoAP13 Communicaon13 with13 Alternave13 Transports
Bill Silverajan and Teemu SavolainenCore WG IETF 86 Orlando
031113
Objecves13 (In13 Scope)
bull Unambiguous13 representaon13 of13 transport13 to13 be13 used13 by13 CoAP
bull Details13 how13 the13 transport13 can13 carry13 CoAP13 packet
bull Focus13 is13 on13 what13 CoAP13 communicaons13 requirements13 are
bull Allow13 CoAP13 mechanisms13 to13 exploit13 cross-shy‐layer13 opmisaons
51
031113
Non13 Goals13 (Not13 in13 scope)
bull Applicaon-shy‐level13 QoS13 requirementsbull Real-shy‐me13 constraintsbull Ordering13 reliability13 congeson13 controlbull Applicaon13 and13 network13 adaptaonbull Mobility13 and13 readdressing13 supportbull Network13 protocol13 (eg13 IPsec)13 configuraon
52
031113
Use13 Cases
bull NAT13 and13 Firewall13 traversal13 with13 TCPbull Delay13 Tolerant13 Networkingbull Non-shy‐IP13 Low13 Energy13 Protocols
53
031113
Related13 Work
bull OMA13 Lightweight13 M2M13 Protocolbull CoAP13 over13 SMSGPRSUSSD
54
031113
What13 does13 the13 work13 entail
bull The13 ability13 to13 specify13 end13 point13 idenfiers13 and13 URIs13 to13 reflect13 which13 transport13 CoAP13 can13 use
bull The13 ability13 to13 register13 to13 resource13 directories13 resource13 types13 reflecng13 types13 of13 transport13 available
bull Ability13 for13 mul-shy‐transport13 nodes13 to13 select13 transport13 to13 use13 without13 significant13 alteraon13 to13 CoAP13 packet13 structure
55
031113
Points13 to13 consider
bull Requirements13 for13 transport13 layer13 protocol13 to13 carry13 CoAP13 packets
bull Representaon13 of13 URI13 scheme13 for13 generic13 transport13 protocols
bull Opon13 extensions13 for13 CoAP13 to13 express13 available13 transports
bull Mapping13 and13 message13 sizebull Security13 consideraons
56
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
URI13 =13 scheme13 13 13 authority13 path-shy‐abempty13 [13 query13 ]
bull Within13 the13 scheme13 namebull In13 the13 URI13 pathbull As13 a13 query13 component
57
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
bull Within13 the13 scheme13 namendash coap+tel+15105550101well-shy‐knowncorendash coap+tcpexamplecom5683temperaturendash coap+blel2cap[1234567890AB]4pulse
bull Easy13 URI13 parsing13 for13 transport13 type13 and13 idenfier
bull Each13 new13 scheme13 name13 requires13 IANA13 registraon
58
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
bull In13 the13 URI13 pathndash coaphostexamplecomtransport=tcpwell-shy‐knowncorert=core-shy‐rd
bull Easy13 adopon13 of13 new13 (and13 experimental)13 CoAP13 transports13 without13 IANA13 registraon
bull Caveat13 Uri-shy‐Path13 opon13 is13 a13 Crical13 CoAP13 opon13 see13 secon13 54113 of13 I-shy‐Diep-shy‐core-shy‐coap
59
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
bull As13 a13 URI13 query13 componentndash coaphostexamplecomwell-shy‐knowncorert=core-shy‐rdq=tcp
bull Also13 easy13 to13 adopt13 new13 (and13 experimental)13 CoAP13 transports13 without13 IANA13 registraon
bull Caveat13 Uri-shy‐Query13 opon13 is13 a13 Crical13 CoAP13 opon13 see13 secon13 54113 of13 I-shy‐Diep-shy‐core-shy‐coap
60
031113
URI13 Representaons13 for13 CoAPNon13 standard13 ways
bull Transport13 in13 the13 URI13 authority13 componentndash coaphost[port][transport]13 instead13 of13 coaphost[port]
bull Transport13 as13 a13 service13 URLndash servicecoaptcphostexamplecomwell-shy‐knowncorert=core-shy‐rd
bull Above13 two13 ways13 break13 exisng13 compability13 (although13 both13 are13 based13 on13 valid13 IANA13 URI13 registraons)
61
031113
URI13 Representaons13 for13 CoAPMiscellaneous13 Consideraons
bull Ensure13 that13 transport13 is13 defined13 unambiguously13 (eg13 L2CAP13 used13 by13 both13 BLE13 and13 standard13 Bluetooth13 so13 avoid13 rdquocoap+l2caprdquo13 or13 rdquotransport=l2caprdquo13 or13 rdquoq=l2caprdquondash Can13 be13 done13 as13 WG13 consensusndash Namespace13 approach13 eg13 rdquocoap+blel2caprdquo13 or13 rdquoq=blel2caprdquo
bull Allow13 end-shy‐points13 to13 use13 CoAP13 Resource13 Directory13 to13 register13 alternave13 transports13 and13 idenfiers13 and13 provide13 periodic13 updatesndash Register13 rdquocore-shy‐transportrdquo13 resource13 type
62
031113
Transport13 Consideraons
bull Uniqueness13 of13 end-shy‐point13 idenficaonbull Communicaon13 support13 Unidireconal13 Bidireconal13 1N13 (broadcast13 mulcast13 anycast)13 messaging
bull Binary13 encoding13 Network13 byte13 orderingbull MTU13 correlaon13 with13 CoAP13 PDU13 sizebull Transport13 latency
63
031113
Security13 Consideraons
bull Drar13 does13 not13 introduce13 new13 security13 requirements13 by13 itself
bull There13 may13 be13 privacy13 issues13 if13 nodes13 use13 telephone13 numbers13 or13 MAC13 addresses13 as13 public13 end13 point13 idenfiers
64
Akbar Rahman
IETF 86 March 2013 httpwwwietforgiddraft-rahman-core-sleepy-02txt
Enhanced Sleepy Node Support for CoAP
Introduction
It is expected that in CoAP networks there will be a certain portion of devices that are sleepy and which may occasionally go into a sleep mode (ie go into a low power state to conserve power) and subsequently have reduced CoAP protocol communication ability
This I-D proposes a minimal and efficient mechanism building on the Resource Directory concept (which will be integrated into a CoAP Proxy) to enhance sleepy node support in CoAP networks
Main Question from IETF-85 (Atlanta)
What performance benefit does the proposed Sleepy Node support solution give in a network that already has standard CoAP caching enabled
Sleepy Node Performance Analysis
Experimental Network
1-5 clients
Both Sleepy and Non-
Sleepy servers
Sleepy Node Performance Analysis Network Setup
CoAPSleepyServer(s)
CoAPSleepAwareReverseProxy
CoAP
Client(s)
Request
Response
Sleep9AwareCoREResourceDirectoryCapability
PublishedSleepParameters
Sleep9AwareCoAPStoreandForwardCapability Response
Request
SleepAwareCoAP503ResponseCapability
CoAPCachingCapability
bull Server supports publishing sleep parameters to proxy bull Eg Irsquom going to be asleep for X seconds
bull Proxy supports sleep-awareness capabilities bull Proxy also supports caching capability based off of maxAge bull Protocol flow similar to approach of Figure 1 (Synchronous RD Based Sleep
Tracking) of I-D
Proxy capabilities can be selectively enableddisabled
Proxy ndash Server Interface
Client ndash Proxy Interface
CoAP Sleep-Aware Reverse Proxy Features CoRE Sleep-aware Resource Directory
Support storing published sleep parameters from CoAP servers sleepState (AWAKE ASLEEP) sleepDuration
Sleep-aware CoAP 503 Response Capability If CoAP request to a sleeping server is received proxy returns a
lsquo503 Retry-Afterrsquo response to client 503 contains a timestamp indicating when the sever will wake back up
(timestamp delivered in CoAP maxAge option) Sleep-aware CoAP Store-and-Forward Capability
If CoAP request to a sleeping server is received proxy stores request until server wakes up and then forwards it
Caching capability Cache GET responses from server if maxAge option is present
(this is not a sleep aware feature)
Goals of Performance Analysis
For networks having sleepy servers provide measurements to quantify the impact that CoAP sleep-awareness capabilities can have
See if sleep-awareness capabilities can
provide additional benefits even when CoAP caching is used
Overview of Performance Analysis Performed The analysis was broken up into a set of test scenarios Each test scenario used a different combination of the following
variables Client issued GET requests Server was configured as a sleepy or non-sleepy server Proxy caching of GET responses was enabled or disabled Proxy sleep-aware 503 response capability was enabled or disabled Proxy store-and-forward capability was enabled or disabled maxAge in GET responses ndash Two values were tested 60sec and 5sec of Clients ndash Two values were used ndash 1 client and 5 clients
For comparison purposes the following were held constant across all test scenarios Client issued a fixed number of requests (100) across all test scenarios Client used a delay between each GET request (35sec) to better exercise
proxyrsquos caching and sleep-awareness capabilities For sleepy server test scenarios the server slept 60 sec awake for 3 sec
Format of Results The following results were collected for each
test scenario
Breakdown of the and types of transactions occurring between clientproxyserver
ldquoGETrdquo ndash Test Scenario Results
GET ndash Description of Test Scenarios
TestScenarios-GET
Scenario
CoAPSleepyServerSe7ngs CoAPSleepAwareReverseProxySe7ngs CoAPClientSe7ngs
SleepDuragton(sec)
AwakeDuragton(sec)
maxAge(sec) Caching SleepAwareSAF+
503NumberofClients
NumberofGETs
DelayBetweenClient
Requests(sec)
1a 0 Always 60 Enabled Disabled 1 100 35
1b 60 3 60 Enabled Disabled 1 100 35
1c 60 3 60 Enabled Enabled 1 100 35
2a 0 Always 60 Enabled Disabled 5 100 35
2b 60 3 60 Enabled Disabled 5 100 35
2c 60 3 60 Enabled Enabled 5 100 35
3a 0 Always 5 Enabled Disabled 5 100 35
3b 60 3 5 Enabled Disabled 5 100 35
3c 60 3 5 Enabled Enabled 5 100 35
ldquoGETrdquo ndash Test Scenario 1 Results
maxAge = 60 and 1 Client
GET ndash Scenario 1 ClientProxy Interface Transaction Mix
Scenarios 1a - Non-Sleepy Server Caching Proxy maxAge = 60sec 1b- Sleepy Server Caching Proxy maxAge = 60sec 1c - Sleepy Server Sleep Aware Proxy maxAge = 60sec
Sleep Aware Proxy has better performance for sleepy servers
0
100
200
300
400
500
600
700
1a 1b 1c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
GET ndash Scenario 1 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
Scenarios 1a - Non-Sleepy Server Caching Proxy maxAge = 60sec 1b- Sleepy Server Caching Proxy maxAge = 60sec 1c - Sleepy Server Sleep Aware Proxy maxAge = 60sec
0
100
200
300
400
500
600
700
800
1a 1b 1c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
ldquoGETrdquo ndash Test Scenario 2 Results
maxAge = 60 and 5 Clients
GET ndash Scenario 2 ClientProxy Interface Transaction Mix
Sleep Aware Proxy has slightly better performance for sleepy servers
0
200
400
600
800
1000
1200
1400
2a 2b 2c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
Scenarios 2a - Non-Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2b- Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2c - Sleepy Server Sleep Aware Proxy maxAge = 60sec 5 Clients
See ldquoExperimental Artifactsrdquo Note 1
GET ndash Scenario 2 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has slightly better performance for sleepy servers
0
50
100
150
200
250
300
350
400
2a 2b 2c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
Scenarios 2a - Non-Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2b- Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2c - Sleepy Server Sleep Aware Proxy maxAge = 60sec 5 Clients
See ldquoExperimental Artifactsrdquo Note 2
Experimental Artifacts Note 1
Currently in the experiment the sleep aware proxy checks the cached state of a resource before putting a request into its Store-and-forward queue while a server is sleeping Once in the queue the proxy unconditionally forwards the queued requests to the server once it wakes up This is not the most efficient setup and can easily be improved If the proxy instead checks its cache again before forwarding each queued request it may not need to forward the request to the server For example if there are two queued GET requests in the proxyrsquos queue that address the same resource Only the first request needs to be sent to the server the second request can use the cached response from the first request
Note 2 Currently in the experiment the sleepy server sends a sleepState PUT request to the
proxy each time it goes to sleep This is not the most efficient setup and can easily be improved For example if the server assumes that the proxy can keep track of its ONOFF cycles with its internal timers (eg as per Fig 1 of I-D) then the number of messages from the sleepy server dramatically goes down
ldquoGETrdquo ndash Test Scenario 3 Results
maxAge = 5 and 5 Clients
GET ndash Scenario 3 ClientProxy Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
Scenarios 3a - Non-Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3b- Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3c - Sleepy Server Sleep Aware Proxy maxAge = 5sec 5 Clients
0
500
1000
1500
2000
2500
3000
3500
4000
4500
5000
3a 3b 3c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
GET ndash Scenario 3 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
0
1000
2000
3000
4000
5000
6000
7000
3a 3b 3c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
Scenarios 3a - Non-Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3b- Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3c - Sleepy Server Sleep Aware Proxy maxAge = 5sec 5 Clients
Conclusions
Conclusions These results show that sleep-aware CoAP
proxy features can significantly optimize communication with sleepy servers in most scenarios
These results also show that sleep-
awareness capabilities can provide additional benefits above and beyond CoAP caching in most scenarios
Backup
Current CoAP Support of Sleepy Node (12)
CoAP proxies can use a previously cached response to service a new GET request for a sleepy origin server (as in HTTP) But if no valid cache then proxy has to attempt to
retrieve and may fail if origin server is sleeping [I-Dietf-core-coap]
Clients can discover list of resources from RD (GET rd-lookuphellip) for sleepy servers But attempt to GET resource from sleepy origin server
may fail if origin server is sleeping [IDietf-core-link-format amp IDshelby-core-resource-
directory]
Current CoAP Support of Sleepy Node (22)
Lower layer support for sleepy nodes in most wireless technologies (eg WiFi ZigBee) But limited to MAC packet scheduling for sleepy nodes
and not aware of specific needs of IP applications (like CoAP)
Proposal ndash RD Based Sleep Tracking (14)
The current CoAP approach to support sleepy nodes can be significantly improved by introducing RD based mechanisms for a CoAP client to determine whether A targeted resource is located on a sleepy server A sleepy server is currently in sleep mode or not
There is any associated caching Proxy (possibly the RD itself) for a sleepy server
Proposal ndash RD Based Sleep Tracking (24)
We define the following new RD attributes to characterize the properties of a sleepy node SleepState - Indicates whether the node is currently in
sleep mode or not (ie Sleeping or Awake) SleepDuration - Indicates the maximum duration of time
that the node stays in sleep mode TimeSleeping - Indicates the length of time the node
has been sleeping (ie if Sleep State = Sleeping) NextSleep - Indicates the next time the node will go to
sleep (ie if Sleep State = Awake)
CachingProxy ndash Indicates the caching proxy of the sleepy node (ie the RD itself or another node)
Proposal ndash RD Based Sleep Tracking (34)
These attributes are all server (node) level and are new parameters added to the RD URI Template Variables
Finally we also define a new lookup-type (ss) for the RD lookup interface specified in [I-Dshelby-core-resource-directory] This new lookup-type supports looking up the
ldquoSleepStaterdquo (ss) of a specified end-point
Proposal ndash RD Based Sleep Tracking (44)
The three time based parameters (SleepDuration TimeSleeping NextSleep) can be based on either an absolute network time (for a time synchronized network) or a relative local time (measured at the local node)
Following the approach of [I-Dietf-core-link-format] and [I-Dshelby-core-resource-directory] sleep parameters for sleepy servers can be stored by the server in the RD and accessed by all interested clients
Examples of using these parameters in a synchronous or asynchronous manner are shown in the I-D
http6lowappnet coreIETF86 2013-03-12-13
We assume people have read the drafts
Meetings serve to advance difficult issues by making good use of face-to-face communications
Note Well Be aware of the IPR principles according to RFC 3979 and its updates
uumlBlue sheetsuumlScribe(s)
96
drar-shy‐iep-shy‐core-shy‐coapsubmiqed13 to13 IESG
2013-shy‐03-shy‐13
97
OMA Lightweight M2M Overview(A new standard using lots of IETF specs including DTLS
CoAP Block Observe Resource Directory SenMLhellip)
Zach ShelbyCoRE WG IETF-86 Orlando
OMA Lightweight M2Mbull Open Mobile Alliance is well known for Device Management (DM)bull OMA Lightweight M2M is a new standard from the alliance
ndash Focused on constrained Cellular and sensor network M2M devicesndash Driven by leading operators and vendors
bull Scopendash Interfaces protocol amp security between Device and Serverndash Object and Resource modelndash Bootstrap Device Access Control Connectivity and Firmware Objects
bull Draft Specifications are availablendash httpmemberopenmobileallianceorgftpPublic_documentsDM
LightweightM2MPermanent_documentsOMA-TS-LightweightM2M-V1_0_0-20130301-Dzip
bull Timelinendash Requirements and Architecture completed 3Q2012ndash Spec ready for Consistency Review 2Q2013ndash Candidate Approval expected 3Q2013
2 CoRE WG IETF-86 Orlando
Architecture
3
Scope of LWM2M
CoRE WG IETF-86 Orlando
Object Model
bull A Client has one or more Object Instancesbull An Object is a collection of Resourcesbull A Resource is an atomic piece of information
ndash Read Written or Executed
bull Resources can have multiple instancesbull Objects and Resources are identified by a
16-bit Integer Instances by an 8-bit Integerbull ObjectsResources are accessed with
simple URIs Object IDObject InstanceResource ID
eg 1213
4 CoRE WG IETF-86 Orlando
CoRE WG IETF-86 Orlando
CoRE Resource Directory
draft-shelby-core-resource-directory-05
Z Shelby C Bormann S Krco
Backgroundbull Not a new concept
ndash think web search engine or any link directorybull Defines the interfaces to a Resource Directorybull Based on Web Linking framework and the CoRE Link Formatbull Generic REST design for use over HTTP and CoAPbull Used by OMA Lightweight M2Mbull Has already been deployed
ndash In traffic monitoring systemsndash In street lighting systemsndash For vehicular asset trackingndash By a major Cellular M2M operator
Changes since -04
bull Restricted Update to parameter updatesbull Added pagination support for the Lookup interfacebull Changed rt= to et= for the registration amp update
interfacebull Added group support
Group Management
bull RD now includes group management featuresbull New Group Function Set
ndash Register a groupbull Group name domain multicast address endpoint members
ndash Remove a groupbull Group lookup using the Lookup Function Set
ndash List registered groupsndash Find the members of a groupndash Find groups with certain endpoints or resources
Registering a Group
EP RD
| |
| - POST rd-groupgp=lights ltgtep=node1 --gt |
| |
| |
| lt---- 201 Created Location rd-group12 ---- |
| |
Req POST coaprdexamplecomrd-groupgp=lights
Payload
ltgtep=node1
ltgtep=node2
Res 201 Created
Location rd-group12
Looking up Group Members
Client RD
| |
| ----- GET rd-lookupepgp=lights1 ----------------------gt |
| |
| |
| lt-- 205 Content ltrdgtd=domain1ltrdgtd=domain2 --------- |
| |
Req GET rd-lookupepgp=lights1
Res 205 Content
ltcoaphostportgtep=node1
ltcoaphostportgtep=node2rdquo
Things for the futurebull Support for JSON representation of Web Links
ndash httptoolsietforgiddraft-bormann-core-links-json-02txtbull Registry for RD registration query parameters
ndash Already OMA Lightweight has defined some new onesbull More examples
Group 3 ldquonew workrdquo(continued)
109
drar-shy‐greevenbosch-shy‐core-shy‐profile-shy‐descripon-shy‐01Bert13 GreevenboschJeroen13 Hoebeke
Isam13 IshaqFloris13 Van13 den13 Abeele
Descripon
bull JSON13 format13 for13 signalling13 the13 servers13 capabilies
bull Signalling13 of13 supported13 opons13 media13 types13 and13 block13 sizendash Other13 items13 can13 be13 added
bull Filtering13 on13 specific13 fields13 through13 URI-shy‐Querybull Link13 hqpdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐profile-shy‐descripon
well-shy‐knownprofile
bull To13 acquire13 profile13 data13 of13 resources13 on13 a13 parcular13 service13 the13 well-shy‐knownprofile13 URI-shy‐path13 is13 introduced
bull For13 example13 to13 get13 all13 informaon13 from13 sensors13 served13 by13 wwwexampleorg13 we13 can13 do13 a13 GET13 to13 coapwwwexampleorgwell-shy‐knownprofile
bull Filtering13 on13 parcular13 resources13 is13 done13 through13 URI-shy‐Queries
Format
bull Currently13 the13 following13 fields13 are13 definedndash ldquopathrdquo13 contains13 the13 URI-shy‐path13 associated13 with13 a13 resource
ndash ldquooprdquo13 a13 numerical13 list13 of13 supported13 opon13 numbers
ndash ldquocfrdquo13 a13 numerical13 list13 of13 supported13 content-shy‐format13 numbers
ndash ldquob1srdquo13 ldquob2srdquo13 supported13 block13 sizes13 for13 Block113 and13 Block213 respecvely
Examplebull On13 the13 right13 is13 an13 example13 of13 a13 camera13 sensor13 at13 coapwwwexampleorgcam13 that13 supports13 the13 Uri-shy‐Host13 (3)13 ETag13 (4)13 Uri-shy‐Port13 (7)13 Uri-shy‐Path13 (11)13 Content-shy‐Format13 (12)13 Token13 (19)13 Block213 (23)13 and13 Proxy-shy‐Uri13 (35)13 opons
bull The13 supported13 content13 formats13 are13 textplain13 (0)13 applicaon13 link-shy‐format13 (40)13 and13 applicaonjson13 (50)
bull The13 supported13 Block213 can13 use13 25613 or13 51213 byte13 blocks
Req13 GET13 coapwwwexampleorgwell-shy‐knownprofile13 Res13 20513 Content13 (applicationjson)13 13 13 13 profile13 13 13 13 13 13 13 13 pathcam13 13 13 13 op[3471112192335]13 13 13 13 13 cf[04050]13 13 13 13 13 b2s[45]13 13 13 13
Filtering13 through13 use13 of13 URI-shy‐Query
bull Filtering13 can13 be13 done13 through13 the13 URI-shy‐Querybull Query13 format13 N=V
ndash N13 is13 a13 profile13 fieldndash V13 is13 the13 desired13 value
bull Examplesndash To13 find13 resources13 that13 support13 content13 format13 ldquoapplicaonjsonrdquo
13 GET13 wwwexampleorgwell-shy‐knownprofilecf=50ndash To13 get13 informaon13 about13 the13 camera
13 GET13 wwwexampleorgwell-shy‐knownprofilepath=cam
Open13 issues
bull Which13 other13 profile13 data13 needs13 signallingndash Content-shy‐type13 for13 different13 methods
bull Fix13 the13 order13 in13 which13 the13 profile13 fields13 must13 appearndash Non-shy‐fixed13 order13 easier13 extensible
bull Inheritance13 of13 a13 profile13 descriponbull Extend13 usage13 to13 signal13 the13 client13 profilebull Integraon13 with13 link13 format
Thank13 youQuesons
drar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval-shy‐00
Bert13 Greevenbosch
Descripon
bull The13 ldquoMinimumRequestInterval13 opon13 can13 be13 used13 to13 indicate13 the13 minimum13 me13 between13 two13 requests13 in13 a13 transacon
bull Originally13 intended13 for13 Block13 but13 also13 usable13 for13 other13 transaconsndash Example13 browsing13 a13 server
bull The13 goal13 is13 to13 reduce13 the13 server13 load13 and13 network13 traffic
bull Link13 hqpsdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval
Usage
bull The13 client13 keeps13 the13 server13 informed13 about13 its13 request13 speed13 through13 inclusion13 of13 the13 ldquoMinimumRequestIntervalrdquo13 opon
bull In13 responses13 the13 server13 fixes13 the13 minimum13 request13 interval13 through13 the13 same13 opon
bull The13 client13 obeys13 the13 speed13 indicated13 by13 the13 server
bull The13 client13 can13 send13 slower13 but13 not13 faster
Advantages
bull The13 server13 has13 means13 to13 limit13 the13 amount13 of13 incoming13 traffic
bull The13 server13 can13 prevent13 to13 become13 overloaded13 with13 too13 many13 tasks
bull The13 server13 does13 not13 need13 arficially13 slow13 down13 the13 client13 by13 sending13 late13 ACKsndash No13 need13 to13 keep13 track13 of13 delayed13 ACKsndash The13 server13 can13 perform13 other13 tasks13 instead
bull Reduced13 network13 traffic
Thank13 youQuesons
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-links-json-02txt
123
RFC 6690 (link-format) documents are somewhat foreign to many web app developerssect would prefer to have them in JSON format
There is no standard way to represent link-format documents in applicationssect but everyone knows how to handle JSON
Define a standard JSON translation for link-format
Itrsquos
not
rock
et
scien
ce
ltsensorsgtct=40title=Sensor Index ltsensorstempgtrt=temperature-cif=sensor ltsensorslightgtrt=light-luxif=sensor lthttpwwwexamplecomsensorst123gt anchor=sensorstemprel=describedby lttgtanchor=sensorstemprel=alternate [hrefsensorsct40titleSensor Index hrefsensorstemprttemperature-cifsensor hrefsensorslightrtlight-luxifsensor hrefhttpwwwexamplecomsensorst123 anchorsensorstempreldescribedby hreftanchorsensorstemprelalternate]
124
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-ipsec-for-coap-00txt
IPsec definitions for CoAP Mostly placeholder at this time Who has implementation experience with this
125
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-cross-reverse-convention-00txt
This draft has two lines of payload(based on a WGLC comment by Cullen Jennings)
coap12344567foobara=3
httpwwwproxycomwellknowncore-translate1234_4567foobara=3
Is that a useful convention to have
126
Insert CI slides here
127
128
0
5
10
15
20
25
30
35
40
10 20 30 40 50 60 70
good
put (
pps)
pps
Goodput vs pps (Econotags)
goodput
[Khattak preliminary]
Congestion Control
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-cocoa-00txt
ldquoadvancedrdquo cc (The draft is just a first shot) Others may have better ideas
129
Insert post-WGLC discussion slides here
130
Stop Continue Start
131
An Agile Retrospective
http6lowappnet coreIETF86 2013-03-12-13
Stop
132
Endless new CoAP optionssect instead use RESTful as much as possible
Move general security lifecycle out Looking at theoretical problems
http6lowappnet coreIETF86 2013-03-12-13
Continue
Interops Running code Look at real-world examples and deployments Solve their actual problems
sect Unilateral enhancements eg higher performance congestion control
sect Transports (SMS hellip)sect Make Web linking and Directories more and more usefulsect RESTful Design Paradigms for real-world problems
133
http6lowappnet coreIETF86 2013-03-12-13
Start
Further push into the (browser) web world (HTML5 browser security)
Specific supporting worksect SenMLsect URI work (dev URN hellip)sect Security Processes (next slide)
Spin outsect (We donrsquot really get to decide where this is done)
134
http6lowappnet coreIETF86 2013-03-12-13
Security
Integrate Application Network Group Keyingsect Tunnel-free setup
Donrsquot redo what has been done alreadysect ZigBee IP is finesect But what about other scenarios
Simple REST interfaces for working with keying materials and authorizationsect Start with defining objectives
Object Security for Constrained Nodes135
Re-chartering CoREWhat do we want to do now that wersquore grown up
Zach ShelbyCoRE WG IETF-86 Orlando
What is the scope
bull So we have a protocol and Web Linking what next
bull Keep with what we know besthellip1 Enhancements around CoAP2 New transports for CoAP3 New representations for Web Links4 General application layer solutions
CoRE WG IETF-86 Orlando 2
Enhancements around CoAP
bull Advanced congestion control
CoRE WG IETF-86 Orlando 3
New Transports for CoAP
bull Infrastructure for CoAP over foondash httptoolsietforgiddraft-silverajan-core-
coap-alternative-transports-01txtbull CoAP over SMS
ndash httptoolsietforgiddraft-becker-core-coap-sms-gprs-03txt
ndash OMA Lightweightbull CoAP over TCP
ndash httptoolsietforgiddraft-li-core-coap-payload-length-option-01txt
CoRE WG IETF-86 Orlando 4
New support for Web Links
bull JSON Web Linksndash httptoolsietforgiddraft-bormann-core-links-
json-02txt
2332010 CoRE WG IETF-77 Anaheim 5
General application layer solutions
bull Resource Directoryndash httptoolsietforgiddraft-shelby-core-
resource-directory-05txtndash OMA Lightweight
2332010 CoRE WG IETF-77 Anaheim 6
http6lowappnet coreIETF86 2013-03-12-13
Milestones (from WG charter page)httpdatatrackerietforgwgcorecharter
Document submissions to IESG
Dec 2012 CoAP protocol specification with mapping to HTTP Rest API to IESG Feb 2013 Blockwise transfers in CoAP to IESG Feb 2013 Observing Resources in CoAP to IESG Apr 2013 Group Communication for CoAP to IESG Dec 2099 HOLD (date TBD) Constrained security
bootstrapping specification to IESG
3
0
01
02
03
04
05
06
07
08
09
1
10 20 30 40 50 60 70 80 90 100
Bad
ness
rem
aini
ng
Amount of time spent
asymptotic(x)
You are here
4
0
01
02
03
04
05
06
07
08
09
1
10 20 30 40 50 60 70 80 90 100
Bad
ness
rem
aini
ng
Amount of time spent
asymptotic(x)
You are here
5
Group 1 2nd WGLCcoap-13 coap-14
6
http6lowappnet coreIETF86 2013-03-12-13
draft-ietf-core-coap-14
7
Will be published a couple of hours from nowsect please do read and comment again during IETF last call
Changes from ndash13sect Clarify that payload sniffing is acceptable only if no Content-
Format was suppliedsect Clarify that safe-to-forward options in a 203 Valid response
update the cachesect Clarify URI examples (Appendix B)sect Numerous editorial improvements and clarifications
sect Made Accept option non-repeatable
Repeatable13 Accept13 Opon
bull Problem
bull Soluon13 A13 ldquoJust13 do13 not13 do13 itrdquo13 and13 keep13 it13 generalbull Soluon13 B13 Change13 to13 non-shy‐repeatable
+ Predictable13 behavior13 when13 going13 through13 different13 caches+ Makes13 Accept13 and13 proxies13 easier13 to13 understand+ We13 have13 out-shy‐of-shy‐band13 content13 negoaon13 (ct=ldquoltAgt13 ltBgtrdquo)+ Can13 be13 added13 later13 as13 extension13 if13 really13 needed
GET13 someresAccept13 A13 B13
GET13 someresAccept13 B13 A13
someres13 (A13 B)13 =gt13 ltAgt
someres13 (B13 A)13 =gt13 ltAgt
Proxy
Also13 causesmulple13 observe13 relaonships
Cacheblowup
someresltAgt
Origin13 Server
Group 1a WGLC processingobserve block
9
http6lowappnet coreIETF86 2013-03-12-13
draft-ietf-core-observe-08
10
Changes from ndash07 to ndash08sect Expanded text on transmitting notification while a previous
transmission is pending (242)sect Changed reordering detection to use a fixed time span of 128
seconds instead of EXCHANGE_LIFETIME (276)sect Removed the use of the freshness model to determine if the
client is still on the list of observers
http6lowappnet coreIETF86 2013-03-12-13
draft-ietf-core-block-10
11
Still awaits grand editorial rewritesect right after coap-14 is shipped
http6lowappnet coreIETF86 2013-03-12-13
Tickets
hellip are our way to make the steps forward are at
http toolsietforgwgcore Updates are sent to the mailing list
sect Please review When we close a ticket please review once more
12
Group 2 groupcomm
13
Akbar RahmanEsko Dijk
IETF 86 March 2013httpwwwietforgiddraft-ietf-core-groupcomm-05txt
Group Communication for CoAP
Summary of Changes (14)
n I-D had two updates (Rev 04 amp 05) after IETF-85 (Atlanta) Many of the updates were due to the detailed review by Peter van der Stokn Thank you Peter for your valuable comments
n Changes from ietf-03 to ietf-04 n Section 23 (Potential Solutions for Group Communications) moved to
draft-dijk-core-groupcomm-misc (266)n Added reference to draft-keoh-tls-multicast-security to section 6 (Security
Considerations) n Appendix B (CoAP-Observe Alternative to Group Communications) moved
to draft-dijk-core-groupcomm-misc (267) n Deleted section 8 (Conclusions) as it is redundant (268) n Simplified light switch use case (269) by splitting into basic operations and
additional functions (269)
Summary of Changes (24)
n Changes from ietf-03 to ietf-04 (Continued) n Moved section 37 (CoAP Multicast and HTTP Unicast Interworking) to
draft-dijk-core-groupcomm-misc (270) n Moved section 331 (DNS-SD) and 332 (CoRE Resource Directory) to
draft-dijk-core-groupcomm-miscClarified that DNS based features are optional (272)
n Focus section 35 (Configuring Group Membership) on a single proposed solution
n Scope of section 53 (Use of MLD) widened to multicast destination advertisement methods in general
n Rewrote section 22 (Scope) for improved readibility n Moved use cases that are not adressed to draft-dijk-core-groupcomm-miscn Various editorial updates for improved readibility
Summary of Changes (34)
n Changes from ietf-04 to ietf-05 n Added a new section 39 (Exceptions) that highlights that IP multicast (and
hence group communications) is not always available (187) n Included guidelines on when (not) to use CoAP responses to multicast
requests and when (not) to accept multicast requests (273) n Added guideline on use of core-block for minimizing response size (275)n Restructured section 6 (Security Considerations) to more fully describe
threats and threat mitigation (277) n Clearly indicated that DNS resolution and reverse DNS lookup are optional n Removed confusing text about a single group having multiple IP addresses
If multiple IP addresses are required then multiple groups (with the same members) should be created
n Removed repetitive text about the fact that group communications is not guaranteed
Summary of Changes (44)
n Changes from ietf-04 to ietf-05 (Continued) n Merged previous section 52 (Multicast Routing) into 31 (IP Multicast
Routing Background) and added link to section 52 (Advertising Membership of Multicast Groups)
n Clarified text in section 38 (Congestion Control) regarding precedence of use of IP multicast domains (ie first try to use link-local scope then site-local scope and only use global IP Communication for CoAP multicast as a last resort)
n Extended group resource manipulation guidelines with use of preconfigured portspaths for the multicast group
n Consolidated all text relating to ports in a new section 33 (Port Configuration)
n Clarified that all methods (GETPUTPOST) for configuring group membership in endpoints should be unicast (and not multicast) in section 37 (Configuring Group Membership In Endpoints)
n Various editorial updates for improved readability
Discussion item (11)
n Solution for Configuring Group Membership (no ticket)n Example of (unicast) configuring an endpoint to be part of one multicast
groupReq POST gp (Content-Format applicationjson)
n floor1westbldg6examplecom ip ff154200f7feed3714cb Res 204 Changed
n Where the ldquogprdquo resource has resource type (rt) ldquocoregprdquo which is defined for this purpose
n Question Do we want specify such a solution (or for example leave it completely up to implementation)
Open Issues(15)
n Review Groupcomm requirements language (271)n Decision made to keep requirements language for informational draftn Each use of MAYMUSTSHOULD etc is to be reviewed
Open Issues(25)
n Add section on multicast via Proxy and its limitations (274)n Add a section to explain the issues amp limitations of doing CoAP multicast
requests via a CoAP Proxy n Goal is to warn and guide implementers in this subject n Also such a section would provide a placeholderreminder of the problems
that might be addressed further in the futuren Based on IETF 85 CoRE WG meeting discussion on Multicast CoAP
requests via a Proxy Discussion summary for referencen Aggregation of responses in a proxy is difficult since it doesnt know
when to stop aggregating responses n SIP tried to deal with this problem but didnt solve it n There may be an expectancy of CoAP client to get single response
back from proxy not multiple The client in this case may not even know what it could expect It may not even know the Proxy-URI contains a multicast target
n Presented via-proxy use case exposes gap in the core-coap specification regarding multicast via proxy (Note Expectation is that core-coap wonrsquot address it in the first planned RFC release)
Open Issues(35)
n Issues with twomultiple Resource Directories in use case (280)n Some potential issues with RD came out of review Peter van der Stok and
WG discussion IETF85 n There are two RD servers use case shows that only one is found despite
the fact that site-local multicast is used - should be two RDs found n Proposal simplify use case to a single RD server on the backbone to avoid
such RD-specific issues like synchronization of RD information between servers
Open Issues(45)
n Add single-subnet configuration to use cases (278)n Suggested by review Peter van der Stok and IETF85 WG discussion that
its best to start explaining the simplebasic cases and then gradually build up complexity
n Simplest case not shown yet would be a single subnet network configuration which is currently not present in the I-D only the 2-subnet configuration of Fig 1
n Question Do we need to add such case or doesnt it add muchn (Note that core-coap Figure 22 already shows the simplest case of link-local
multicast)
Open Issues(55)
n Add use case with controller (client) located on the backbone (279)n Suggested by discussion following review Peter van der Stok n Case missing where a controller (client) is located on the backbonen Question Do we need to add such case or does it add much
Group 2a other old friends
25
Angelo Castellani Salvatore Loreto Akbar Rahman Thomas Fossati Esko Dijk
IETF 86 March 2013httpwwwietforgiddraft-castellani-core-http-mapping-07txt
Best Practices for HTTP-CoAP Mapping
Implementation
Summary of Changes (from -06 rev)
n Based on discussion at last IETF-85 (Atlanta)n Clarification of HTTP-CoAP Proxies
n Definitionn Placementn Benefits
n Clarification of HTTP-CoAP URI mapping options
Goals of I-D
n For Reverse HTTP-CoAP Cross Protocol Proxyn Provide more detailed information to proxy designers (beyond
Section 10 of [I-Dietf-core-coap]) to help implement proxies that correctly inter-work with other CoAP and HTTP clientserver implementations that adhere to the specifications
n Define a consistent set of guidelines that a HTTP-to-CoAP proxy implementation MAY adhere to The main reason of adhering to such guidelines is to reduce variation between proxy implementations thereby increasing interoperabilityn As an example use case a proxy conforming to these guidelines made
by vendor A can be easily replaced by a proxy from vendor B that also conforms to the guidelines
I-D Outline
n Guidance on HTTP to CoAP URI mappingn HTTP-CoAP Reverse cross-protocol proxy implementation
n Placementn Response code amp media type translationsn Caching and congestion controln Cache refresh via Observen Use of CoAP blockwise transfern Security translation
n Security Considerationsn Traffic overflown Handling secured exchanges
Definitions (12)
n Cross-Protocol Proxy (or Cross Proxy) is a proxy performing a cross- protocol mapping in the context of this document a HTTP-CoAP (HC) mapping A Cross-Protocol Proxy can behave as a Forward Proxy Reverse Proxy or Interception Proxy n Note In this document we focus on the Reverse Proxy mode of the
Cross-Protocol Proxy
n Forward Proxy a message forwarding agent that is selected by the client usually via local configuration rules to receive requests for some type(s) of absolute URI and to attempt to satisfy those requests via translation to the protocol indicated by the absolute URI The user decides (is willing to) use the proxy as the forwardingdereferencing agent for a predefined subset of the URI space
Definitions (22)
n Reverse Proxy a receiving agent that acts as a layer above some other server(s) and translates the received requests to the underlying servers protocol It behaves as an origin (HTTP) server on its connection towards the (HTTP) client and as a (CoAP) client on its connection towards the (CoAP) origin server The (HTTP) client uses the origin-form [I-Dietf-httpbis-p1-messaging] as a request- target URI
n Reverse and Forward proxies are technically very similar with main differences being that the former appears to a client as an origin server while the latter does not and that clients may be unaware they are communicating with a proxy
Reverse Cross-Protocol Proxy Deployment Scenario
HTTP-CoAP Response Code Mapping
Implementation Experience
n Direct experience from the draft authorsn Squid HTTP-CoAP mapping module
n University of Padovan httptelecomdeiunipditiotn Both Forward and Interception operation supported
n HTTP-CoAP proxy based on EvCoAPn KoanLogic University of Bologna and Salvatore
Loreto (as individual)n httpsgithubcomkoanlogicwebthingstreemasterbridgesw
libevcoapn The document is open to input from other implementations
Next Steps
n Does the WG recommend adoptionn Intended status Informational Best Practicen Purpose Reduce arbitrary variation between proxy
implementations thereby increasing interoperability
Backup
HTTP to CoAP URI Mapping Options (12)
n Embedded Mapping n In an embedded mapping approach the HTTP URI has embedded
inside it the authority and path part of the CoAP URI n Example The CoAP resource nodecoapsomethingnetfoo can
be accessed by an HTTP client by inserting in the request httphc-proxysomethingnetcoapnodecoapsomethingnetfoo The Cross-Protocol Proxy then maps the URI to coapnodecoapsomethingnetfoo
HTTP to CoAP URI Mapping Options (22)
n Homogeneous Mapping n In a homogeneous mapping approach only the scheme portion of the URI
needs to be mapped The rest of the URI (ie authority path etc) remains unchanged
n Example The CoAP resource coapnodecoapsomethingnetfoo can be accessed by an HTTP client by requesting httpnodecoapsomethingnetfoo The Cross-Protocol Proxy receiving the request is responsible to map the URI to coapnodecoapsomethingnetfoo
n Background info n The assumption in this case is that the HTTP client would be able to
successfully resolve nodecoapsomethingnet using DNS infrastructure to return the IP address of the HC proxy Most likely this would be through a two step DNS lookup where the first DNS lookup would resolve somethingnet using public DNS infrastructure
n Then the second DNS lookup on the subdomain coap and the host node would typically be resolved by a DNS server operated by the owner of domain somethingnet So this domain owner can manage its own internal node names and subdomain allocation which would correspond to the CoAP namespace
Group 3 ldquonew workrdquo
39
Transport of CoAP over SMS USSD and GPRSdraft-becker-core-coap-sms-gprs-03
Markus Becker Kepeng LiKoojana Kuladinithi Thomas Poumltsch
CoRE WG IETF-86 Orlando
1 10
ScenariosI In M2M communication IP connectivity is not alwayssupported by the constrained end-points
I Power savingI Coverage (GPRS 3G LTE)
I SMS and USSD based communication is almost alwayssupported
210
Changes from draft-01 to draft-03 (1)
I Added possible CONNONACK interactions Section 5
I Option name changed from Reply-To- to Response-To-Section 16 and Section 101
I Added URI schemeEg coap+tel+15105550101well-knowncore Section 11
I Added possible M2M proxy scenarios Section 14
3 10
Changes from draft-01 to draft-03 (2)
I Added reference to bormann-coap-misc for other SMSencoding Section 71
I Updated requirements on Uri-Host and Uri-Port forcoap+tel Section 10
I Added security considerations Transport and ObjectSecurity Section 15
I Chose CoAP option numbers and updated the optionnumber table to meet draft-ietf-core-coap-10 Table 1
I Added an IANA registration for the URI scheme coap+telSection 162
4 10
Feedback Split coap+tel into coap+smsand coap+ussd
I How else to differ the various transports in the URII Or is the transport to use decided by the implementationI See alsodraft-silverajan-core-coap-alternative-transports-01
5 10
Feedback Response-To-Scheme option
I Should there be a Response-To-Scheme optionadditionally to Response-To-Uri-Host andResponse-To-Uri-Path
I So that a CoAP end-point which receives a request by CoAPover non-IP transport can be instructed to also use thenon-IP transport for the response
I This would imply to add aResponse-To-Telephone-Subscriber and more options forother transports that have other URI schemes than coapand coaps
6 10
Feedback Selection of Transport by Client
I When a server is reachable by various transports howdoes a client decide which transport to use
I Client-side application congurationI Leave it to a proxy which uses cellular network lookupfunctions
7 10
Feedback Potential Threats
I Trigger expensive short messagesI Redirect trac to other addressesI More threats
I Are the security measures in the draft adequateI Whitelisting on serverI Relying on cellular network security (dedicated M2M APNs)I Object security on CoAP payload
8 10
Feedback Message Exchanges
I Figures 11-18 show possible message exchanges whenclient and server have two addresses
I With NON Not using CoAP retransmission capabilityI ACK on different transportI Additional (costly) message on Transport AI Request with Content
I Which ones are allowedI Which ones are meaningful
9 10
Next steps
I Rene Uri schemeI Response-To-Scheme optionI Selection of Message ExchangeI Rene Proxying
10 10
CoAP13 Communicaon13 with13 Alternave13 Transports
Bill Silverajan and Teemu SavolainenCore WG IETF 86 Orlando
031113
Objecves13 (In13 Scope)
bull Unambiguous13 representaon13 of13 transport13 to13 be13 used13 by13 CoAP
bull Details13 how13 the13 transport13 can13 carry13 CoAP13 packet
bull Focus13 is13 on13 what13 CoAP13 communicaons13 requirements13 are
bull Allow13 CoAP13 mechanisms13 to13 exploit13 cross-shy‐layer13 opmisaons
51
031113
Non13 Goals13 (Not13 in13 scope)
bull Applicaon-shy‐level13 QoS13 requirementsbull Real-shy‐me13 constraintsbull Ordering13 reliability13 congeson13 controlbull Applicaon13 and13 network13 adaptaonbull Mobility13 and13 readdressing13 supportbull Network13 protocol13 (eg13 IPsec)13 configuraon
52
031113
Use13 Cases
bull NAT13 and13 Firewall13 traversal13 with13 TCPbull Delay13 Tolerant13 Networkingbull Non-shy‐IP13 Low13 Energy13 Protocols
53
031113
Related13 Work
bull OMA13 Lightweight13 M2M13 Protocolbull CoAP13 over13 SMSGPRSUSSD
54
031113
What13 does13 the13 work13 entail
bull The13 ability13 to13 specify13 end13 point13 idenfiers13 and13 URIs13 to13 reflect13 which13 transport13 CoAP13 can13 use
bull The13 ability13 to13 register13 to13 resource13 directories13 resource13 types13 reflecng13 types13 of13 transport13 available
bull Ability13 for13 mul-shy‐transport13 nodes13 to13 select13 transport13 to13 use13 without13 significant13 alteraon13 to13 CoAP13 packet13 structure
55
031113
Points13 to13 consider
bull Requirements13 for13 transport13 layer13 protocol13 to13 carry13 CoAP13 packets
bull Representaon13 of13 URI13 scheme13 for13 generic13 transport13 protocols
bull Opon13 extensions13 for13 CoAP13 to13 express13 available13 transports
bull Mapping13 and13 message13 sizebull Security13 consideraons
56
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
URI13 =13 scheme13 13 13 authority13 path-shy‐abempty13 [13 query13 ]
bull Within13 the13 scheme13 namebull In13 the13 URI13 pathbull As13 a13 query13 component
57
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
bull Within13 the13 scheme13 namendash coap+tel+15105550101well-shy‐knowncorendash coap+tcpexamplecom5683temperaturendash coap+blel2cap[1234567890AB]4pulse
bull Easy13 URI13 parsing13 for13 transport13 type13 and13 idenfier
bull Each13 new13 scheme13 name13 requires13 IANA13 registraon
58
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
bull In13 the13 URI13 pathndash coaphostexamplecomtransport=tcpwell-shy‐knowncorert=core-shy‐rd
bull Easy13 adopon13 of13 new13 (and13 experimental)13 CoAP13 transports13 without13 IANA13 registraon
bull Caveat13 Uri-shy‐Path13 opon13 is13 a13 Crical13 CoAP13 opon13 see13 secon13 54113 of13 I-shy‐Diep-shy‐core-shy‐coap
59
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
bull As13 a13 URI13 query13 componentndash coaphostexamplecomwell-shy‐knowncorert=core-shy‐rdq=tcp
bull Also13 easy13 to13 adopt13 new13 (and13 experimental)13 CoAP13 transports13 without13 IANA13 registraon
bull Caveat13 Uri-shy‐Query13 opon13 is13 a13 Crical13 CoAP13 opon13 see13 secon13 54113 of13 I-shy‐Diep-shy‐core-shy‐coap
60
031113
URI13 Representaons13 for13 CoAPNon13 standard13 ways
bull Transport13 in13 the13 URI13 authority13 componentndash coaphost[port][transport]13 instead13 of13 coaphost[port]
bull Transport13 as13 a13 service13 URLndash servicecoaptcphostexamplecomwell-shy‐knowncorert=core-shy‐rd
bull Above13 two13 ways13 break13 exisng13 compability13 (although13 both13 are13 based13 on13 valid13 IANA13 URI13 registraons)
61
031113
URI13 Representaons13 for13 CoAPMiscellaneous13 Consideraons
bull Ensure13 that13 transport13 is13 defined13 unambiguously13 (eg13 L2CAP13 used13 by13 both13 BLE13 and13 standard13 Bluetooth13 so13 avoid13 rdquocoap+l2caprdquo13 or13 rdquotransport=l2caprdquo13 or13 rdquoq=l2caprdquondash Can13 be13 done13 as13 WG13 consensusndash Namespace13 approach13 eg13 rdquocoap+blel2caprdquo13 or13 rdquoq=blel2caprdquo
bull Allow13 end-shy‐points13 to13 use13 CoAP13 Resource13 Directory13 to13 register13 alternave13 transports13 and13 idenfiers13 and13 provide13 periodic13 updatesndash Register13 rdquocore-shy‐transportrdquo13 resource13 type
62
031113
Transport13 Consideraons
bull Uniqueness13 of13 end-shy‐point13 idenficaonbull Communicaon13 support13 Unidireconal13 Bidireconal13 1N13 (broadcast13 mulcast13 anycast)13 messaging
bull Binary13 encoding13 Network13 byte13 orderingbull MTU13 correlaon13 with13 CoAP13 PDU13 sizebull Transport13 latency
63
031113
Security13 Consideraons
bull Drar13 does13 not13 introduce13 new13 security13 requirements13 by13 itself
bull There13 may13 be13 privacy13 issues13 if13 nodes13 use13 telephone13 numbers13 or13 MAC13 addresses13 as13 public13 end13 point13 idenfiers
64
Akbar Rahman
IETF 86 March 2013 httpwwwietforgiddraft-rahman-core-sleepy-02txt
Enhanced Sleepy Node Support for CoAP
Introduction
It is expected that in CoAP networks there will be a certain portion of devices that are sleepy and which may occasionally go into a sleep mode (ie go into a low power state to conserve power) and subsequently have reduced CoAP protocol communication ability
This I-D proposes a minimal and efficient mechanism building on the Resource Directory concept (which will be integrated into a CoAP Proxy) to enhance sleepy node support in CoAP networks
Main Question from IETF-85 (Atlanta)
What performance benefit does the proposed Sleepy Node support solution give in a network that already has standard CoAP caching enabled
Sleepy Node Performance Analysis
Experimental Network
1-5 clients
Both Sleepy and Non-
Sleepy servers
Sleepy Node Performance Analysis Network Setup
CoAPSleepyServer(s)
CoAPSleepAwareReverseProxy
CoAP
Client(s)
Request
Response
Sleep9AwareCoREResourceDirectoryCapability
PublishedSleepParameters
Sleep9AwareCoAPStoreandForwardCapability Response
Request
SleepAwareCoAP503ResponseCapability
CoAPCachingCapability
bull Server supports publishing sleep parameters to proxy bull Eg Irsquom going to be asleep for X seconds
bull Proxy supports sleep-awareness capabilities bull Proxy also supports caching capability based off of maxAge bull Protocol flow similar to approach of Figure 1 (Synchronous RD Based Sleep
Tracking) of I-D
Proxy capabilities can be selectively enableddisabled
Proxy ndash Server Interface
Client ndash Proxy Interface
CoAP Sleep-Aware Reverse Proxy Features CoRE Sleep-aware Resource Directory
Support storing published sleep parameters from CoAP servers sleepState (AWAKE ASLEEP) sleepDuration
Sleep-aware CoAP 503 Response Capability If CoAP request to a sleeping server is received proxy returns a
lsquo503 Retry-Afterrsquo response to client 503 contains a timestamp indicating when the sever will wake back up
(timestamp delivered in CoAP maxAge option) Sleep-aware CoAP Store-and-Forward Capability
If CoAP request to a sleeping server is received proxy stores request until server wakes up and then forwards it
Caching capability Cache GET responses from server if maxAge option is present
(this is not a sleep aware feature)
Goals of Performance Analysis
For networks having sleepy servers provide measurements to quantify the impact that CoAP sleep-awareness capabilities can have
See if sleep-awareness capabilities can
provide additional benefits even when CoAP caching is used
Overview of Performance Analysis Performed The analysis was broken up into a set of test scenarios Each test scenario used a different combination of the following
variables Client issued GET requests Server was configured as a sleepy or non-sleepy server Proxy caching of GET responses was enabled or disabled Proxy sleep-aware 503 response capability was enabled or disabled Proxy store-and-forward capability was enabled or disabled maxAge in GET responses ndash Two values were tested 60sec and 5sec of Clients ndash Two values were used ndash 1 client and 5 clients
For comparison purposes the following were held constant across all test scenarios Client issued a fixed number of requests (100) across all test scenarios Client used a delay between each GET request (35sec) to better exercise
proxyrsquos caching and sleep-awareness capabilities For sleepy server test scenarios the server slept 60 sec awake for 3 sec
Format of Results The following results were collected for each
test scenario
Breakdown of the and types of transactions occurring between clientproxyserver
ldquoGETrdquo ndash Test Scenario Results
GET ndash Description of Test Scenarios
TestScenarios-GET
Scenario
CoAPSleepyServerSe7ngs CoAPSleepAwareReverseProxySe7ngs CoAPClientSe7ngs
SleepDuragton(sec)
AwakeDuragton(sec)
maxAge(sec) Caching SleepAwareSAF+
503NumberofClients
NumberofGETs
DelayBetweenClient
Requests(sec)
1a 0 Always 60 Enabled Disabled 1 100 35
1b 60 3 60 Enabled Disabled 1 100 35
1c 60 3 60 Enabled Enabled 1 100 35
2a 0 Always 60 Enabled Disabled 5 100 35
2b 60 3 60 Enabled Disabled 5 100 35
2c 60 3 60 Enabled Enabled 5 100 35
3a 0 Always 5 Enabled Disabled 5 100 35
3b 60 3 5 Enabled Disabled 5 100 35
3c 60 3 5 Enabled Enabled 5 100 35
ldquoGETrdquo ndash Test Scenario 1 Results
maxAge = 60 and 1 Client
GET ndash Scenario 1 ClientProxy Interface Transaction Mix
Scenarios 1a - Non-Sleepy Server Caching Proxy maxAge = 60sec 1b- Sleepy Server Caching Proxy maxAge = 60sec 1c - Sleepy Server Sleep Aware Proxy maxAge = 60sec
Sleep Aware Proxy has better performance for sleepy servers
0
100
200
300
400
500
600
700
1a 1b 1c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
GET ndash Scenario 1 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
Scenarios 1a - Non-Sleepy Server Caching Proxy maxAge = 60sec 1b- Sleepy Server Caching Proxy maxAge = 60sec 1c - Sleepy Server Sleep Aware Proxy maxAge = 60sec
0
100
200
300
400
500
600
700
800
1a 1b 1c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
ldquoGETrdquo ndash Test Scenario 2 Results
maxAge = 60 and 5 Clients
GET ndash Scenario 2 ClientProxy Interface Transaction Mix
Sleep Aware Proxy has slightly better performance for sleepy servers
0
200
400
600
800
1000
1200
1400
2a 2b 2c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
Scenarios 2a - Non-Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2b- Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2c - Sleepy Server Sleep Aware Proxy maxAge = 60sec 5 Clients
See ldquoExperimental Artifactsrdquo Note 1
GET ndash Scenario 2 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has slightly better performance for sleepy servers
0
50
100
150
200
250
300
350
400
2a 2b 2c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
Scenarios 2a - Non-Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2b- Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2c - Sleepy Server Sleep Aware Proxy maxAge = 60sec 5 Clients
See ldquoExperimental Artifactsrdquo Note 2
Experimental Artifacts Note 1
Currently in the experiment the sleep aware proxy checks the cached state of a resource before putting a request into its Store-and-forward queue while a server is sleeping Once in the queue the proxy unconditionally forwards the queued requests to the server once it wakes up This is not the most efficient setup and can easily be improved If the proxy instead checks its cache again before forwarding each queued request it may not need to forward the request to the server For example if there are two queued GET requests in the proxyrsquos queue that address the same resource Only the first request needs to be sent to the server the second request can use the cached response from the first request
Note 2 Currently in the experiment the sleepy server sends a sleepState PUT request to the
proxy each time it goes to sleep This is not the most efficient setup and can easily be improved For example if the server assumes that the proxy can keep track of its ONOFF cycles with its internal timers (eg as per Fig 1 of I-D) then the number of messages from the sleepy server dramatically goes down
ldquoGETrdquo ndash Test Scenario 3 Results
maxAge = 5 and 5 Clients
GET ndash Scenario 3 ClientProxy Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
Scenarios 3a - Non-Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3b- Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3c - Sleepy Server Sleep Aware Proxy maxAge = 5sec 5 Clients
0
500
1000
1500
2000
2500
3000
3500
4000
4500
5000
3a 3b 3c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
GET ndash Scenario 3 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
0
1000
2000
3000
4000
5000
6000
7000
3a 3b 3c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
Scenarios 3a - Non-Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3b- Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3c - Sleepy Server Sleep Aware Proxy maxAge = 5sec 5 Clients
Conclusions
Conclusions These results show that sleep-aware CoAP
proxy features can significantly optimize communication with sleepy servers in most scenarios
These results also show that sleep-
awareness capabilities can provide additional benefits above and beyond CoAP caching in most scenarios
Backup
Current CoAP Support of Sleepy Node (12)
CoAP proxies can use a previously cached response to service a new GET request for a sleepy origin server (as in HTTP) But if no valid cache then proxy has to attempt to
retrieve and may fail if origin server is sleeping [I-Dietf-core-coap]
Clients can discover list of resources from RD (GET rd-lookuphellip) for sleepy servers But attempt to GET resource from sleepy origin server
may fail if origin server is sleeping [IDietf-core-link-format amp IDshelby-core-resource-
directory]
Current CoAP Support of Sleepy Node (22)
Lower layer support for sleepy nodes in most wireless technologies (eg WiFi ZigBee) But limited to MAC packet scheduling for sleepy nodes
and not aware of specific needs of IP applications (like CoAP)
Proposal ndash RD Based Sleep Tracking (14)
The current CoAP approach to support sleepy nodes can be significantly improved by introducing RD based mechanisms for a CoAP client to determine whether A targeted resource is located on a sleepy server A sleepy server is currently in sleep mode or not
There is any associated caching Proxy (possibly the RD itself) for a sleepy server
Proposal ndash RD Based Sleep Tracking (24)
We define the following new RD attributes to characterize the properties of a sleepy node SleepState - Indicates whether the node is currently in
sleep mode or not (ie Sleeping or Awake) SleepDuration - Indicates the maximum duration of time
that the node stays in sleep mode TimeSleeping - Indicates the length of time the node
has been sleeping (ie if Sleep State = Sleeping) NextSleep - Indicates the next time the node will go to
sleep (ie if Sleep State = Awake)
CachingProxy ndash Indicates the caching proxy of the sleepy node (ie the RD itself or another node)
Proposal ndash RD Based Sleep Tracking (34)
These attributes are all server (node) level and are new parameters added to the RD URI Template Variables
Finally we also define a new lookup-type (ss) for the RD lookup interface specified in [I-Dshelby-core-resource-directory] This new lookup-type supports looking up the
ldquoSleepStaterdquo (ss) of a specified end-point
Proposal ndash RD Based Sleep Tracking (44)
The three time based parameters (SleepDuration TimeSleeping NextSleep) can be based on either an absolute network time (for a time synchronized network) or a relative local time (measured at the local node)
Following the approach of [I-Dietf-core-link-format] and [I-Dshelby-core-resource-directory] sleep parameters for sleepy servers can be stored by the server in the RD and accessed by all interested clients
Examples of using these parameters in a synchronous or asynchronous manner are shown in the I-D
http6lowappnet coreIETF86 2013-03-12-13
We assume people have read the drafts
Meetings serve to advance difficult issues by making good use of face-to-face communications
Note Well Be aware of the IPR principles according to RFC 3979 and its updates
uumlBlue sheetsuumlScribe(s)
96
drar-shy‐iep-shy‐core-shy‐coapsubmiqed13 to13 IESG
2013-shy‐03-shy‐13
97
OMA Lightweight M2M Overview(A new standard using lots of IETF specs including DTLS
CoAP Block Observe Resource Directory SenMLhellip)
Zach ShelbyCoRE WG IETF-86 Orlando
OMA Lightweight M2Mbull Open Mobile Alliance is well known for Device Management (DM)bull OMA Lightweight M2M is a new standard from the alliance
ndash Focused on constrained Cellular and sensor network M2M devicesndash Driven by leading operators and vendors
bull Scopendash Interfaces protocol amp security between Device and Serverndash Object and Resource modelndash Bootstrap Device Access Control Connectivity and Firmware Objects
bull Draft Specifications are availablendash httpmemberopenmobileallianceorgftpPublic_documentsDM
LightweightM2MPermanent_documentsOMA-TS-LightweightM2M-V1_0_0-20130301-Dzip
bull Timelinendash Requirements and Architecture completed 3Q2012ndash Spec ready for Consistency Review 2Q2013ndash Candidate Approval expected 3Q2013
2 CoRE WG IETF-86 Orlando
Architecture
3
Scope of LWM2M
CoRE WG IETF-86 Orlando
Object Model
bull A Client has one or more Object Instancesbull An Object is a collection of Resourcesbull A Resource is an atomic piece of information
ndash Read Written or Executed
bull Resources can have multiple instancesbull Objects and Resources are identified by a
16-bit Integer Instances by an 8-bit Integerbull ObjectsResources are accessed with
simple URIs Object IDObject InstanceResource ID
eg 1213
4 CoRE WG IETF-86 Orlando
CoRE WG IETF-86 Orlando
CoRE Resource Directory
draft-shelby-core-resource-directory-05
Z Shelby C Bormann S Krco
Backgroundbull Not a new concept
ndash think web search engine or any link directorybull Defines the interfaces to a Resource Directorybull Based on Web Linking framework and the CoRE Link Formatbull Generic REST design for use over HTTP and CoAPbull Used by OMA Lightweight M2Mbull Has already been deployed
ndash In traffic monitoring systemsndash In street lighting systemsndash For vehicular asset trackingndash By a major Cellular M2M operator
Changes since -04
bull Restricted Update to parameter updatesbull Added pagination support for the Lookup interfacebull Changed rt= to et= for the registration amp update
interfacebull Added group support
Group Management
bull RD now includes group management featuresbull New Group Function Set
ndash Register a groupbull Group name domain multicast address endpoint members
ndash Remove a groupbull Group lookup using the Lookup Function Set
ndash List registered groupsndash Find the members of a groupndash Find groups with certain endpoints or resources
Registering a Group
EP RD
| |
| - POST rd-groupgp=lights ltgtep=node1 --gt |
| |
| |
| lt---- 201 Created Location rd-group12 ---- |
| |
Req POST coaprdexamplecomrd-groupgp=lights
Payload
ltgtep=node1
ltgtep=node2
Res 201 Created
Location rd-group12
Looking up Group Members
Client RD
| |
| ----- GET rd-lookupepgp=lights1 ----------------------gt |
| |
| |
| lt-- 205 Content ltrdgtd=domain1ltrdgtd=domain2 --------- |
| |
Req GET rd-lookupepgp=lights1
Res 205 Content
ltcoaphostportgtep=node1
ltcoaphostportgtep=node2rdquo
Things for the futurebull Support for JSON representation of Web Links
ndash httptoolsietforgiddraft-bormann-core-links-json-02txtbull Registry for RD registration query parameters
ndash Already OMA Lightweight has defined some new onesbull More examples
Group 3 ldquonew workrdquo(continued)
109
drar-shy‐greevenbosch-shy‐core-shy‐profile-shy‐descripon-shy‐01Bert13 GreevenboschJeroen13 Hoebeke
Isam13 IshaqFloris13 Van13 den13 Abeele
Descripon
bull JSON13 format13 for13 signalling13 the13 servers13 capabilies
bull Signalling13 of13 supported13 opons13 media13 types13 and13 block13 sizendash Other13 items13 can13 be13 added
bull Filtering13 on13 specific13 fields13 through13 URI-shy‐Querybull Link13 hqpdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐profile-shy‐descripon
well-shy‐knownprofile
bull To13 acquire13 profile13 data13 of13 resources13 on13 a13 parcular13 service13 the13 well-shy‐knownprofile13 URI-shy‐path13 is13 introduced
bull For13 example13 to13 get13 all13 informaon13 from13 sensors13 served13 by13 wwwexampleorg13 we13 can13 do13 a13 GET13 to13 coapwwwexampleorgwell-shy‐knownprofile
bull Filtering13 on13 parcular13 resources13 is13 done13 through13 URI-shy‐Queries
Format
bull Currently13 the13 following13 fields13 are13 definedndash ldquopathrdquo13 contains13 the13 URI-shy‐path13 associated13 with13 a13 resource
ndash ldquooprdquo13 a13 numerical13 list13 of13 supported13 opon13 numbers
ndash ldquocfrdquo13 a13 numerical13 list13 of13 supported13 content-shy‐format13 numbers
ndash ldquob1srdquo13 ldquob2srdquo13 supported13 block13 sizes13 for13 Block113 and13 Block213 respecvely
Examplebull On13 the13 right13 is13 an13 example13 of13 a13 camera13 sensor13 at13 coapwwwexampleorgcam13 that13 supports13 the13 Uri-shy‐Host13 (3)13 ETag13 (4)13 Uri-shy‐Port13 (7)13 Uri-shy‐Path13 (11)13 Content-shy‐Format13 (12)13 Token13 (19)13 Block213 (23)13 and13 Proxy-shy‐Uri13 (35)13 opons
bull The13 supported13 content13 formats13 are13 textplain13 (0)13 applicaon13 link-shy‐format13 (40)13 and13 applicaonjson13 (50)
bull The13 supported13 Block213 can13 use13 25613 or13 51213 byte13 blocks
Req13 GET13 coapwwwexampleorgwell-shy‐knownprofile13 Res13 20513 Content13 (applicationjson)13 13 13 13 profile13 13 13 13 13 13 13 13 pathcam13 13 13 13 op[3471112192335]13 13 13 13 13 cf[04050]13 13 13 13 13 b2s[45]13 13 13 13
Filtering13 through13 use13 of13 URI-shy‐Query
bull Filtering13 can13 be13 done13 through13 the13 URI-shy‐Querybull Query13 format13 N=V
ndash N13 is13 a13 profile13 fieldndash V13 is13 the13 desired13 value
bull Examplesndash To13 find13 resources13 that13 support13 content13 format13 ldquoapplicaonjsonrdquo
13 GET13 wwwexampleorgwell-shy‐knownprofilecf=50ndash To13 get13 informaon13 about13 the13 camera
13 GET13 wwwexampleorgwell-shy‐knownprofilepath=cam
Open13 issues
bull Which13 other13 profile13 data13 needs13 signallingndash Content-shy‐type13 for13 different13 methods
bull Fix13 the13 order13 in13 which13 the13 profile13 fields13 must13 appearndash Non-shy‐fixed13 order13 easier13 extensible
bull Inheritance13 of13 a13 profile13 descriponbull Extend13 usage13 to13 signal13 the13 client13 profilebull Integraon13 with13 link13 format
Thank13 youQuesons
drar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval-shy‐00
Bert13 Greevenbosch
Descripon
bull The13 ldquoMinimumRequestInterval13 opon13 can13 be13 used13 to13 indicate13 the13 minimum13 me13 between13 two13 requests13 in13 a13 transacon
bull Originally13 intended13 for13 Block13 but13 also13 usable13 for13 other13 transaconsndash Example13 browsing13 a13 server
bull The13 goal13 is13 to13 reduce13 the13 server13 load13 and13 network13 traffic
bull Link13 hqpsdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval
Usage
bull The13 client13 keeps13 the13 server13 informed13 about13 its13 request13 speed13 through13 inclusion13 of13 the13 ldquoMinimumRequestIntervalrdquo13 opon
bull In13 responses13 the13 server13 fixes13 the13 minimum13 request13 interval13 through13 the13 same13 opon
bull The13 client13 obeys13 the13 speed13 indicated13 by13 the13 server
bull The13 client13 can13 send13 slower13 but13 not13 faster
Advantages
bull The13 server13 has13 means13 to13 limit13 the13 amount13 of13 incoming13 traffic
bull The13 server13 can13 prevent13 to13 become13 overloaded13 with13 too13 many13 tasks
bull The13 server13 does13 not13 need13 arficially13 slow13 down13 the13 client13 by13 sending13 late13 ACKsndash No13 need13 to13 keep13 track13 of13 delayed13 ACKsndash The13 server13 can13 perform13 other13 tasks13 instead
bull Reduced13 network13 traffic
Thank13 youQuesons
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-links-json-02txt
123
RFC 6690 (link-format) documents are somewhat foreign to many web app developerssect would prefer to have them in JSON format
There is no standard way to represent link-format documents in applicationssect but everyone knows how to handle JSON
Define a standard JSON translation for link-format
Itrsquos
not
rock
et
scien
ce
ltsensorsgtct=40title=Sensor Index ltsensorstempgtrt=temperature-cif=sensor ltsensorslightgtrt=light-luxif=sensor lthttpwwwexamplecomsensorst123gt anchor=sensorstemprel=describedby lttgtanchor=sensorstemprel=alternate [hrefsensorsct40titleSensor Index hrefsensorstemprttemperature-cifsensor hrefsensorslightrtlight-luxifsensor hrefhttpwwwexamplecomsensorst123 anchorsensorstempreldescribedby hreftanchorsensorstemprelalternate]
124
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-ipsec-for-coap-00txt
IPsec definitions for CoAP Mostly placeholder at this time Who has implementation experience with this
125
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-cross-reverse-convention-00txt
This draft has two lines of payload(based on a WGLC comment by Cullen Jennings)
coap12344567foobara=3
httpwwwproxycomwellknowncore-translate1234_4567foobara=3
Is that a useful convention to have
126
Insert CI slides here
127
128
0
5
10
15
20
25
30
35
40
10 20 30 40 50 60 70
good
put (
pps)
pps
Goodput vs pps (Econotags)
goodput
[Khattak preliminary]
Congestion Control
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-cocoa-00txt
ldquoadvancedrdquo cc (The draft is just a first shot) Others may have better ideas
129
Insert post-WGLC discussion slides here
130
Stop Continue Start
131
An Agile Retrospective
http6lowappnet coreIETF86 2013-03-12-13
Stop
132
Endless new CoAP optionssect instead use RESTful as much as possible
Move general security lifecycle out Looking at theoretical problems
http6lowappnet coreIETF86 2013-03-12-13
Continue
Interops Running code Look at real-world examples and deployments Solve their actual problems
sect Unilateral enhancements eg higher performance congestion control
sect Transports (SMS hellip)sect Make Web linking and Directories more and more usefulsect RESTful Design Paradigms for real-world problems
133
http6lowappnet coreIETF86 2013-03-12-13
Start
Further push into the (browser) web world (HTML5 browser security)
Specific supporting worksect SenMLsect URI work (dev URN hellip)sect Security Processes (next slide)
Spin outsect (We donrsquot really get to decide where this is done)
134
http6lowappnet coreIETF86 2013-03-12-13
Security
Integrate Application Network Group Keyingsect Tunnel-free setup
Donrsquot redo what has been done alreadysect ZigBee IP is finesect But what about other scenarios
Simple REST interfaces for working with keying materials and authorizationsect Start with defining objectives
Object Security for Constrained Nodes135
Re-chartering CoREWhat do we want to do now that wersquore grown up
Zach ShelbyCoRE WG IETF-86 Orlando
What is the scope
bull So we have a protocol and Web Linking what next
bull Keep with what we know besthellip1 Enhancements around CoAP2 New transports for CoAP3 New representations for Web Links4 General application layer solutions
CoRE WG IETF-86 Orlando 2
Enhancements around CoAP
bull Advanced congestion control
CoRE WG IETF-86 Orlando 3
New Transports for CoAP
bull Infrastructure for CoAP over foondash httptoolsietforgiddraft-silverajan-core-
coap-alternative-transports-01txtbull CoAP over SMS
ndash httptoolsietforgiddraft-becker-core-coap-sms-gprs-03txt
ndash OMA Lightweightbull CoAP over TCP
ndash httptoolsietforgiddraft-li-core-coap-payload-length-option-01txt
CoRE WG IETF-86 Orlando 4
New support for Web Links
bull JSON Web Linksndash httptoolsietforgiddraft-bormann-core-links-
json-02txt
2332010 CoRE WG IETF-77 Anaheim 5
General application layer solutions
bull Resource Directoryndash httptoolsietforgiddraft-shelby-core-
resource-directory-05txtndash OMA Lightweight
2332010 CoRE WG IETF-77 Anaheim 6
0
01
02
03
04
05
06
07
08
09
1
10 20 30 40 50 60 70 80 90 100
Bad
ness
rem
aini
ng
Amount of time spent
asymptotic(x)
You are here
4
0
01
02
03
04
05
06
07
08
09
1
10 20 30 40 50 60 70 80 90 100
Bad
ness
rem
aini
ng
Amount of time spent
asymptotic(x)
You are here
5
Group 1 2nd WGLCcoap-13 coap-14
6
http6lowappnet coreIETF86 2013-03-12-13
draft-ietf-core-coap-14
7
Will be published a couple of hours from nowsect please do read and comment again during IETF last call
Changes from ndash13sect Clarify that payload sniffing is acceptable only if no Content-
Format was suppliedsect Clarify that safe-to-forward options in a 203 Valid response
update the cachesect Clarify URI examples (Appendix B)sect Numerous editorial improvements and clarifications
sect Made Accept option non-repeatable
Repeatable13 Accept13 Opon
bull Problem
bull Soluon13 A13 ldquoJust13 do13 not13 do13 itrdquo13 and13 keep13 it13 generalbull Soluon13 B13 Change13 to13 non-shy‐repeatable
+ Predictable13 behavior13 when13 going13 through13 different13 caches+ Makes13 Accept13 and13 proxies13 easier13 to13 understand+ We13 have13 out-shy‐of-shy‐band13 content13 negoaon13 (ct=ldquoltAgt13 ltBgtrdquo)+ Can13 be13 added13 later13 as13 extension13 if13 really13 needed
GET13 someresAccept13 A13 B13
GET13 someresAccept13 B13 A13
someres13 (A13 B)13 =gt13 ltAgt
someres13 (B13 A)13 =gt13 ltAgt
Proxy
Also13 causesmulple13 observe13 relaonships
Cacheblowup
someresltAgt
Origin13 Server
Group 1a WGLC processingobserve block
9
http6lowappnet coreIETF86 2013-03-12-13
draft-ietf-core-observe-08
10
Changes from ndash07 to ndash08sect Expanded text on transmitting notification while a previous
transmission is pending (242)sect Changed reordering detection to use a fixed time span of 128
seconds instead of EXCHANGE_LIFETIME (276)sect Removed the use of the freshness model to determine if the
client is still on the list of observers
http6lowappnet coreIETF86 2013-03-12-13
draft-ietf-core-block-10
11
Still awaits grand editorial rewritesect right after coap-14 is shipped
http6lowappnet coreIETF86 2013-03-12-13
Tickets
hellip are our way to make the steps forward are at
http toolsietforgwgcore Updates are sent to the mailing list
sect Please review When we close a ticket please review once more
12
Group 2 groupcomm
13
Akbar RahmanEsko Dijk
IETF 86 March 2013httpwwwietforgiddraft-ietf-core-groupcomm-05txt
Group Communication for CoAP
Summary of Changes (14)
n I-D had two updates (Rev 04 amp 05) after IETF-85 (Atlanta) Many of the updates were due to the detailed review by Peter van der Stokn Thank you Peter for your valuable comments
n Changes from ietf-03 to ietf-04 n Section 23 (Potential Solutions for Group Communications) moved to
draft-dijk-core-groupcomm-misc (266)n Added reference to draft-keoh-tls-multicast-security to section 6 (Security
Considerations) n Appendix B (CoAP-Observe Alternative to Group Communications) moved
to draft-dijk-core-groupcomm-misc (267) n Deleted section 8 (Conclusions) as it is redundant (268) n Simplified light switch use case (269) by splitting into basic operations and
additional functions (269)
Summary of Changes (24)
n Changes from ietf-03 to ietf-04 (Continued) n Moved section 37 (CoAP Multicast and HTTP Unicast Interworking) to
draft-dijk-core-groupcomm-misc (270) n Moved section 331 (DNS-SD) and 332 (CoRE Resource Directory) to
draft-dijk-core-groupcomm-miscClarified that DNS based features are optional (272)
n Focus section 35 (Configuring Group Membership) on a single proposed solution
n Scope of section 53 (Use of MLD) widened to multicast destination advertisement methods in general
n Rewrote section 22 (Scope) for improved readibility n Moved use cases that are not adressed to draft-dijk-core-groupcomm-miscn Various editorial updates for improved readibility
Summary of Changes (34)
n Changes from ietf-04 to ietf-05 n Added a new section 39 (Exceptions) that highlights that IP multicast (and
hence group communications) is not always available (187) n Included guidelines on when (not) to use CoAP responses to multicast
requests and when (not) to accept multicast requests (273) n Added guideline on use of core-block for minimizing response size (275)n Restructured section 6 (Security Considerations) to more fully describe
threats and threat mitigation (277) n Clearly indicated that DNS resolution and reverse DNS lookup are optional n Removed confusing text about a single group having multiple IP addresses
If multiple IP addresses are required then multiple groups (with the same members) should be created
n Removed repetitive text about the fact that group communications is not guaranteed
Summary of Changes (44)
n Changes from ietf-04 to ietf-05 (Continued) n Merged previous section 52 (Multicast Routing) into 31 (IP Multicast
Routing Background) and added link to section 52 (Advertising Membership of Multicast Groups)
n Clarified text in section 38 (Congestion Control) regarding precedence of use of IP multicast domains (ie first try to use link-local scope then site-local scope and only use global IP Communication for CoAP multicast as a last resort)
n Extended group resource manipulation guidelines with use of preconfigured portspaths for the multicast group
n Consolidated all text relating to ports in a new section 33 (Port Configuration)
n Clarified that all methods (GETPUTPOST) for configuring group membership in endpoints should be unicast (and not multicast) in section 37 (Configuring Group Membership In Endpoints)
n Various editorial updates for improved readability
Discussion item (11)
n Solution for Configuring Group Membership (no ticket)n Example of (unicast) configuring an endpoint to be part of one multicast
groupReq POST gp (Content-Format applicationjson)
n floor1westbldg6examplecom ip ff154200f7feed3714cb Res 204 Changed
n Where the ldquogprdquo resource has resource type (rt) ldquocoregprdquo which is defined for this purpose
n Question Do we want specify such a solution (or for example leave it completely up to implementation)
Open Issues(15)
n Review Groupcomm requirements language (271)n Decision made to keep requirements language for informational draftn Each use of MAYMUSTSHOULD etc is to be reviewed
Open Issues(25)
n Add section on multicast via Proxy and its limitations (274)n Add a section to explain the issues amp limitations of doing CoAP multicast
requests via a CoAP Proxy n Goal is to warn and guide implementers in this subject n Also such a section would provide a placeholderreminder of the problems
that might be addressed further in the futuren Based on IETF 85 CoRE WG meeting discussion on Multicast CoAP
requests via a Proxy Discussion summary for referencen Aggregation of responses in a proxy is difficult since it doesnt know
when to stop aggregating responses n SIP tried to deal with this problem but didnt solve it n There may be an expectancy of CoAP client to get single response
back from proxy not multiple The client in this case may not even know what it could expect It may not even know the Proxy-URI contains a multicast target
n Presented via-proxy use case exposes gap in the core-coap specification regarding multicast via proxy (Note Expectation is that core-coap wonrsquot address it in the first planned RFC release)
Open Issues(35)
n Issues with twomultiple Resource Directories in use case (280)n Some potential issues with RD came out of review Peter van der Stok and
WG discussion IETF85 n There are two RD servers use case shows that only one is found despite
the fact that site-local multicast is used - should be two RDs found n Proposal simplify use case to a single RD server on the backbone to avoid
such RD-specific issues like synchronization of RD information between servers
Open Issues(45)
n Add single-subnet configuration to use cases (278)n Suggested by review Peter van der Stok and IETF85 WG discussion that
its best to start explaining the simplebasic cases and then gradually build up complexity
n Simplest case not shown yet would be a single subnet network configuration which is currently not present in the I-D only the 2-subnet configuration of Fig 1
n Question Do we need to add such case or doesnt it add muchn (Note that core-coap Figure 22 already shows the simplest case of link-local
multicast)
Open Issues(55)
n Add use case with controller (client) located on the backbone (279)n Suggested by discussion following review Peter van der Stok n Case missing where a controller (client) is located on the backbonen Question Do we need to add such case or does it add much
Group 2a other old friends
25
Angelo Castellani Salvatore Loreto Akbar Rahman Thomas Fossati Esko Dijk
IETF 86 March 2013httpwwwietforgiddraft-castellani-core-http-mapping-07txt
Best Practices for HTTP-CoAP Mapping
Implementation
Summary of Changes (from -06 rev)
n Based on discussion at last IETF-85 (Atlanta)n Clarification of HTTP-CoAP Proxies
n Definitionn Placementn Benefits
n Clarification of HTTP-CoAP URI mapping options
Goals of I-D
n For Reverse HTTP-CoAP Cross Protocol Proxyn Provide more detailed information to proxy designers (beyond
Section 10 of [I-Dietf-core-coap]) to help implement proxies that correctly inter-work with other CoAP and HTTP clientserver implementations that adhere to the specifications
n Define a consistent set of guidelines that a HTTP-to-CoAP proxy implementation MAY adhere to The main reason of adhering to such guidelines is to reduce variation between proxy implementations thereby increasing interoperabilityn As an example use case a proxy conforming to these guidelines made
by vendor A can be easily replaced by a proxy from vendor B that also conforms to the guidelines
I-D Outline
n Guidance on HTTP to CoAP URI mappingn HTTP-CoAP Reverse cross-protocol proxy implementation
n Placementn Response code amp media type translationsn Caching and congestion controln Cache refresh via Observen Use of CoAP blockwise transfern Security translation
n Security Considerationsn Traffic overflown Handling secured exchanges
Definitions (12)
n Cross-Protocol Proxy (or Cross Proxy) is a proxy performing a cross- protocol mapping in the context of this document a HTTP-CoAP (HC) mapping A Cross-Protocol Proxy can behave as a Forward Proxy Reverse Proxy or Interception Proxy n Note In this document we focus on the Reverse Proxy mode of the
Cross-Protocol Proxy
n Forward Proxy a message forwarding agent that is selected by the client usually via local configuration rules to receive requests for some type(s) of absolute URI and to attempt to satisfy those requests via translation to the protocol indicated by the absolute URI The user decides (is willing to) use the proxy as the forwardingdereferencing agent for a predefined subset of the URI space
Definitions (22)
n Reverse Proxy a receiving agent that acts as a layer above some other server(s) and translates the received requests to the underlying servers protocol It behaves as an origin (HTTP) server on its connection towards the (HTTP) client and as a (CoAP) client on its connection towards the (CoAP) origin server The (HTTP) client uses the origin-form [I-Dietf-httpbis-p1-messaging] as a request- target URI
n Reverse and Forward proxies are technically very similar with main differences being that the former appears to a client as an origin server while the latter does not and that clients may be unaware they are communicating with a proxy
Reverse Cross-Protocol Proxy Deployment Scenario
HTTP-CoAP Response Code Mapping
Implementation Experience
n Direct experience from the draft authorsn Squid HTTP-CoAP mapping module
n University of Padovan httptelecomdeiunipditiotn Both Forward and Interception operation supported
n HTTP-CoAP proxy based on EvCoAPn KoanLogic University of Bologna and Salvatore
Loreto (as individual)n httpsgithubcomkoanlogicwebthingstreemasterbridgesw
libevcoapn The document is open to input from other implementations
Next Steps
n Does the WG recommend adoptionn Intended status Informational Best Practicen Purpose Reduce arbitrary variation between proxy
implementations thereby increasing interoperability
Backup
HTTP to CoAP URI Mapping Options (12)
n Embedded Mapping n In an embedded mapping approach the HTTP URI has embedded
inside it the authority and path part of the CoAP URI n Example The CoAP resource nodecoapsomethingnetfoo can
be accessed by an HTTP client by inserting in the request httphc-proxysomethingnetcoapnodecoapsomethingnetfoo The Cross-Protocol Proxy then maps the URI to coapnodecoapsomethingnetfoo
HTTP to CoAP URI Mapping Options (22)
n Homogeneous Mapping n In a homogeneous mapping approach only the scheme portion of the URI
needs to be mapped The rest of the URI (ie authority path etc) remains unchanged
n Example The CoAP resource coapnodecoapsomethingnetfoo can be accessed by an HTTP client by requesting httpnodecoapsomethingnetfoo The Cross-Protocol Proxy receiving the request is responsible to map the URI to coapnodecoapsomethingnetfoo
n Background info n The assumption in this case is that the HTTP client would be able to
successfully resolve nodecoapsomethingnet using DNS infrastructure to return the IP address of the HC proxy Most likely this would be through a two step DNS lookup where the first DNS lookup would resolve somethingnet using public DNS infrastructure
n Then the second DNS lookup on the subdomain coap and the host node would typically be resolved by a DNS server operated by the owner of domain somethingnet So this domain owner can manage its own internal node names and subdomain allocation which would correspond to the CoAP namespace
Group 3 ldquonew workrdquo
39
Transport of CoAP over SMS USSD and GPRSdraft-becker-core-coap-sms-gprs-03
Markus Becker Kepeng LiKoojana Kuladinithi Thomas Poumltsch
CoRE WG IETF-86 Orlando
1 10
ScenariosI In M2M communication IP connectivity is not alwayssupported by the constrained end-points
I Power savingI Coverage (GPRS 3G LTE)
I SMS and USSD based communication is almost alwayssupported
210
Changes from draft-01 to draft-03 (1)
I Added possible CONNONACK interactions Section 5
I Option name changed from Reply-To- to Response-To-Section 16 and Section 101
I Added URI schemeEg coap+tel+15105550101well-knowncore Section 11
I Added possible M2M proxy scenarios Section 14
3 10
Changes from draft-01 to draft-03 (2)
I Added reference to bormann-coap-misc for other SMSencoding Section 71
I Updated requirements on Uri-Host and Uri-Port forcoap+tel Section 10
I Added security considerations Transport and ObjectSecurity Section 15
I Chose CoAP option numbers and updated the optionnumber table to meet draft-ietf-core-coap-10 Table 1
I Added an IANA registration for the URI scheme coap+telSection 162
4 10
Feedback Split coap+tel into coap+smsand coap+ussd
I How else to differ the various transports in the URII Or is the transport to use decided by the implementationI See alsodraft-silverajan-core-coap-alternative-transports-01
5 10
Feedback Response-To-Scheme option
I Should there be a Response-To-Scheme optionadditionally to Response-To-Uri-Host andResponse-To-Uri-Path
I So that a CoAP end-point which receives a request by CoAPover non-IP transport can be instructed to also use thenon-IP transport for the response
I This would imply to add aResponse-To-Telephone-Subscriber and more options forother transports that have other URI schemes than coapand coaps
6 10
Feedback Selection of Transport by Client
I When a server is reachable by various transports howdoes a client decide which transport to use
I Client-side application congurationI Leave it to a proxy which uses cellular network lookupfunctions
7 10
Feedback Potential Threats
I Trigger expensive short messagesI Redirect trac to other addressesI More threats
I Are the security measures in the draft adequateI Whitelisting on serverI Relying on cellular network security (dedicated M2M APNs)I Object security on CoAP payload
8 10
Feedback Message Exchanges
I Figures 11-18 show possible message exchanges whenclient and server have two addresses
I With NON Not using CoAP retransmission capabilityI ACK on different transportI Additional (costly) message on Transport AI Request with Content
I Which ones are allowedI Which ones are meaningful
9 10
Next steps
I Rene Uri schemeI Response-To-Scheme optionI Selection of Message ExchangeI Rene Proxying
10 10
CoAP13 Communicaon13 with13 Alternave13 Transports
Bill Silverajan and Teemu SavolainenCore WG IETF 86 Orlando
031113
Objecves13 (In13 Scope)
bull Unambiguous13 representaon13 of13 transport13 to13 be13 used13 by13 CoAP
bull Details13 how13 the13 transport13 can13 carry13 CoAP13 packet
bull Focus13 is13 on13 what13 CoAP13 communicaons13 requirements13 are
bull Allow13 CoAP13 mechanisms13 to13 exploit13 cross-shy‐layer13 opmisaons
51
031113
Non13 Goals13 (Not13 in13 scope)
bull Applicaon-shy‐level13 QoS13 requirementsbull Real-shy‐me13 constraintsbull Ordering13 reliability13 congeson13 controlbull Applicaon13 and13 network13 adaptaonbull Mobility13 and13 readdressing13 supportbull Network13 protocol13 (eg13 IPsec)13 configuraon
52
031113
Use13 Cases
bull NAT13 and13 Firewall13 traversal13 with13 TCPbull Delay13 Tolerant13 Networkingbull Non-shy‐IP13 Low13 Energy13 Protocols
53
031113
Related13 Work
bull OMA13 Lightweight13 M2M13 Protocolbull CoAP13 over13 SMSGPRSUSSD
54
031113
What13 does13 the13 work13 entail
bull The13 ability13 to13 specify13 end13 point13 idenfiers13 and13 URIs13 to13 reflect13 which13 transport13 CoAP13 can13 use
bull The13 ability13 to13 register13 to13 resource13 directories13 resource13 types13 reflecng13 types13 of13 transport13 available
bull Ability13 for13 mul-shy‐transport13 nodes13 to13 select13 transport13 to13 use13 without13 significant13 alteraon13 to13 CoAP13 packet13 structure
55
031113
Points13 to13 consider
bull Requirements13 for13 transport13 layer13 protocol13 to13 carry13 CoAP13 packets
bull Representaon13 of13 URI13 scheme13 for13 generic13 transport13 protocols
bull Opon13 extensions13 for13 CoAP13 to13 express13 available13 transports
bull Mapping13 and13 message13 sizebull Security13 consideraons
56
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
URI13 =13 scheme13 13 13 authority13 path-shy‐abempty13 [13 query13 ]
bull Within13 the13 scheme13 namebull In13 the13 URI13 pathbull As13 a13 query13 component
57
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
bull Within13 the13 scheme13 namendash coap+tel+15105550101well-shy‐knowncorendash coap+tcpexamplecom5683temperaturendash coap+blel2cap[1234567890AB]4pulse
bull Easy13 URI13 parsing13 for13 transport13 type13 and13 idenfier
bull Each13 new13 scheme13 name13 requires13 IANA13 registraon
58
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
bull In13 the13 URI13 pathndash coaphostexamplecomtransport=tcpwell-shy‐knowncorert=core-shy‐rd
bull Easy13 adopon13 of13 new13 (and13 experimental)13 CoAP13 transports13 without13 IANA13 registraon
bull Caveat13 Uri-shy‐Path13 opon13 is13 a13 Crical13 CoAP13 opon13 see13 secon13 54113 of13 I-shy‐Diep-shy‐core-shy‐coap
59
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
bull As13 a13 URI13 query13 componentndash coaphostexamplecomwell-shy‐knowncorert=core-shy‐rdq=tcp
bull Also13 easy13 to13 adopt13 new13 (and13 experimental)13 CoAP13 transports13 without13 IANA13 registraon
bull Caveat13 Uri-shy‐Query13 opon13 is13 a13 Crical13 CoAP13 opon13 see13 secon13 54113 of13 I-shy‐Diep-shy‐core-shy‐coap
60
031113
URI13 Representaons13 for13 CoAPNon13 standard13 ways
bull Transport13 in13 the13 URI13 authority13 componentndash coaphost[port][transport]13 instead13 of13 coaphost[port]
bull Transport13 as13 a13 service13 URLndash servicecoaptcphostexamplecomwell-shy‐knowncorert=core-shy‐rd
bull Above13 two13 ways13 break13 exisng13 compability13 (although13 both13 are13 based13 on13 valid13 IANA13 URI13 registraons)
61
031113
URI13 Representaons13 for13 CoAPMiscellaneous13 Consideraons
bull Ensure13 that13 transport13 is13 defined13 unambiguously13 (eg13 L2CAP13 used13 by13 both13 BLE13 and13 standard13 Bluetooth13 so13 avoid13 rdquocoap+l2caprdquo13 or13 rdquotransport=l2caprdquo13 or13 rdquoq=l2caprdquondash Can13 be13 done13 as13 WG13 consensusndash Namespace13 approach13 eg13 rdquocoap+blel2caprdquo13 or13 rdquoq=blel2caprdquo
bull Allow13 end-shy‐points13 to13 use13 CoAP13 Resource13 Directory13 to13 register13 alternave13 transports13 and13 idenfiers13 and13 provide13 periodic13 updatesndash Register13 rdquocore-shy‐transportrdquo13 resource13 type
62
031113
Transport13 Consideraons
bull Uniqueness13 of13 end-shy‐point13 idenficaonbull Communicaon13 support13 Unidireconal13 Bidireconal13 1N13 (broadcast13 mulcast13 anycast)13 messaging
bull Binary13 encoding13 Network13 byte13 orderingbull MTU13 correlaon13 with13 CoAP13 PDU13 sizebull Transport13 latency
63
031113
Security13 Consideraons
bull Drar13 does13 not13 introduce13 new13 security13 requirements13 by13 itself
bull There13 may13 be13 privacy13 issues13 if13 nodes13 use13 telephone13 numbers13 or13 MAC13 addresses13 as13 public13 end13 point13 idenfiers
64
Akbar Rahman
IETF 86 March 2013 httpwwwietforgiddraft-rahman-core-sleepy-02txt
Enhanced Sleepy Node Support for CoAP
Introduction
It is expected that in CoAP networks there will be a certain portion of devices that are sleepy and which may occasionally go into a sleep mode (ie go into a low power state to conserve power) and subsequently have reduced CoAP protocol communication ability
This I-D proposes a minimal and efficient mechanism building on the Resource Directory concept (which will be integrated into a CoAP Proxy) to enhance sleepy node support in CoAP networks
Main Question from IETF-85 (Atlanta)
What performance benefit does the proposed Sleepy Node support solution give in a network that already has standard CoAP caching enabled
Sleepy Node Performance Analysis
Experimental Network
1-5 clients
Both Sleepy and Non-
Sleepy servers
Sleepy Node Performance Analysis Network Setup
CoAPSleepyServer(s)
CoAPSleepAwareReverseProxy
CoAP
Client(s)
Request
Response
Sleep9AwareCoREResourceDirectoryCapability
PublishedSleepParameters
Sleep9AwareCoAPStoreandForwardCapability Response
Request
SleepAwareCoAP503ResponseCapability
CoAPCachingCapability
bull Server supports publishing sleep parameters to proxy bull Eg Irsquom going to be asleep for X seconds
bull Proxy supports sleep-awareness capabilities bull Proxy also supports caching capability based off of maxAge bull Protocol flow similar to approach of Figure 1 (Synchronous RD Based Sleep
Tracking) of I-D
Proxy capabilities can be selectively enableddisabled
Proxy ndash Server Interface
Client ndash Proxy Interface
CoAP Sleep-Aware Reverse Proxy Features CoRE Sleep-aware Resource Directory
Support storing published sleep parameters from CoAP servers sleepState (AWAKE ASLEEP) sleepDuration
Sleep-aware CoAP 503 Response Capability If CoAP request to a sleeping server is received proxy returns a
lsquo503 Retry-Afterrsquo response to client 503 contains a timestamp indicating when the sever will wake back up
(timestamp delivered in CoAP maxAge option) Sleep-aware CoAP Store-and-Forward Capability
If CoAP request to a sleeping server is received proxy stores request until server wakes up and then forwards it
Caching capability Cache GET responses from server if maxAge option is present
(this is not a sleep aware feature)
Goals of Performance Analysis
For networks having sleepy servers provide measurements to quantify the impact that CoAP sleep-awareness capabilities can have
See if sleep-awareness capabilities can
provide additional benefits even when CoAP caching is used
Overview of Performance Analysis Performed The analysis was broken up into a set of test scenarios Each test scenario used a different combination of the following
variables Client issued GET requests Server was configured as a sleepy or non-sleepy server Proxy caching of GET responses was enabled or disabled Proxy sleep-aware 503 response capability was enabled or disabled Proxy store-and-forward capability was enabled or disabled maxAge in GET responses ndash Two values were tested 60sec and 5sec of Clients ndash Two values were used ndash 1 client and 5 clients
For comparison purposes the following were held constant across all test scenarios Client issued a fixed number of requests (100) across all test scenarios Client used a delay between each GET request (35sec) to better exercise
proxyrsquos caching and sleep-awareness capabilities For sleepy server test scenarios the server slept 60 sec awake for 3 sec
Format of Results The following results were collected for each
test scenario
Breakdown of the and types of transactions occurring between clientproxyserver
ldquoGETrdquo ndash Test Scenario Results
GET ndash Description of Test Scenarios
TestScenarios-GET
Scenario
CoAPSleepyServerSe7ngs CoAPSleepAwareReverseProxySe7ngs CoAPClientSe7ngs
SleepDuragton(sec)
AwakeDuragton(sec)
maxAge(sec) Caching SleepAwareSAF+
503NumberofClients
NumberofGETs
DelayBetweenClient
Requests(sec)
1a 0 Always 60 Enabled Disabled 1 100 35
1b 60 3 60 Enabled Disabled 1 100 35
1c 60 3 60 Enabled Enabled 1 100 35
2a 0 Always 60 Enabled Disabled 5 100 35
2b 60 3 60 Enabled Disabled 5 100 35
2c 60 3 60 Enabled Enabled 5 100 35
3a 0 Always 5 Enabled Disabled 5 100 35
3b 60 3 5 Enabled Disabled 5 100 35
3c 60 3 5 Enabled Enabled 5 100 35
ldquoGETrdquo ndash Test Scenario 1 Results
maxAge = 60 and 1 Client
GET ndash Scenario 1 ClientProxy Interface Transaction Mix
Scenarios 1a - Non-Sleepy Server Caching Proxy maxAge = 60sec 1b- Sleepy Server Caching Proxy maxAge = 60sec 1c - Sleepy Server Sleep Aware Proxy maxAge = 60sec
Sleep Aware Proxy has better performance for sleepy servers
0
100
200
300
400
500
600
700
1a 1b 1c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
GET ndash Scenario 1 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
Scenarios 1a - Non-Sleepy Server Caching Proxy maxAge = 60sec 1b- Sleepy Server Caching Proxy maxAge = 60sec 1c - Sleepy Server Sleep Aware Proxy maxAge = 60sec
0
100
200
300
400
500
600
700
800
1a 1b 1c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
ldquoGETrdquo ndash Test Scenario 2 Results
maxAge = 60 and 5 Clients
GET ndash Scenario 2 ClientProxy Interface Transaction Mix
Sleep Aware Proxy has slightly better performance for sleepy servers
0
200
400
600
800
1000
1200
1400
2a 2b 2c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
Scenarios 2a - Non-Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2b- Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2c - Sleepy Server Sleep Aware Proxy maxAge = 60sec 5 Clients
See ldquoExperimental Artifactsrdquo Note 1
GET ndash Scenario 2 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has slightly better performance for sleepy servers
0
50
100
150
200
250
300
350
400
2a 2b 2c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
Scenarios 2a - Non-Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2b- Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2c - Sleepy Server Sleep Aware Proxy maxAge = 60sec 5 Clients
See ldquoExperimental Artifactsrdquo Note 2
Experimental Artifacts Note 1
Currently in the experiment the sleep aware proxy checks the cached state of a resource before putting a request into its Store-and-forward queue while a server is sleeping Once in the queue the proxy unconditionally forwards the queued requests to the server once it wakes up This is not the most efficient setup and can easily be improved If the proxy instead checks its cache again before forwarding each queued request it may not need to forward the request to the server For example if there are two queued GET requests in the proxyrsquos queue that address the same resource Only the first request needs to be sent to the server the second request can use the cached response from the first request
Note 2 Currently in the experiment the sleepy server sends a sleepState PUT request to the
proxy each time it goes to sleep This is not the most efficient setup and can easily be improved For example if the server assumes that the proxy can keep track of its ONOFF cycles with its internal timers (eg as per Fig 1 of I-D) then the number of messages from the sleepy server dramatically goes down
ldquoGETrdquo ndash Test Scenario 3 Results
maxAge = 5 and 5 Clients
GET ndash Scenario 3 ClientProxy Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
Scenarios 3a - Non-Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3b- Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3c - Sleepy Server Sleep Aware Proxy maxAge = 5sec 5 Clients
0
500
1000
1500
2000
2500
3000
3500
4000
4500
5000
3a 3b 3c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
GET ndash Scenario 3 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
0
1000
2000
3000
4000
5000
6000
7000
3a 3b 3c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
Scenarios 3a - Non-Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3b- Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3c - Sleepy Server Sleep Aware Proxy maxAge = 5sec 5 Clients
Conclusions
Conclusions These results show that sleep-aware CoAP
proxy features can significantly optimize communication with sleepy servers in most scenarios
These results also show that sleep-
awareness capabilities can provide additional benefits above and beyond CoAP caching in most scenarios
Backup
Current CoAP Support of Sleepy Node (12)
CoAP proxies can use a previously cached response to service a new GET request for a sleepy origin server (as in HTTP) But if no valid cache then proxy has to attempt to
retrieve and may fail if origin server is sleeping [I-Dietf-core-coap]
Clients can discover list of resources from RD (GET rd-lookuphellip) for sleepy servers But attempt to GET resource from sleepy origin server
may fail if origin server is sleeping [IDietf-core-link-format amp IDshelby-core-resource-
directory]
Current CoAP Support of Sleepy Node (22)
Lower layer support for sleepy nodes in most wireless technologies (eg WiFi ZigBee) But limited to MAC packet scheduling for sleepy nodes
and not aware of specific needs of IP applications (like CoAP)
Proposal ndash RD Based Sleep Tracking (14)
The current CoAP approach to support sleepy nodes can be significantly improved by introducing RD based mechanisms for a CoAP client to determine whether A targeted resource is located on a sleepy server A sleepy server is currently in sleep mode or not
There is any associated caching Proxy (possibly the RD itself) for a sleepy server
Proposal ndash RD Based Sleep Tracking (24)
We define the following new RD attributes to characterize the properties of a sleepy node SleepState - Indicates whether the node is currently in
sleep mode or not (ie Sleeping or Awake) SleepDuration - Indicates the maximum duration of time
that the node stays in sleep mode TimeSleeping - Indicates the length of time the node
has been sleeping (ie if Sleep State = Sleeping) NextSleep - Indicates the next time the node will go to
sleep (ie if Sleep State = Awake)
CachingProxy ndash Indicates the caching proxy of the sleepy node (ie the RD itself or another node)
Proposal ndash RD Based Sleep Tracking (34)
These attributes are all server (node) level and are new parameters added to the RD URI Template Variables
Finally we also define a new lookup-type (ss) for the RD lookup interface specified in [I-Dshelby-core-resource-directory] This new lookup-type supports looking up the
ldquoSleepStaterdquo (ss) of a specified end-point
Proposal ndash RD Based Sleep Tracking (44)
The three time based parameters (SleepDuration TimeSleeping NextSleep) can be based on either an absolute network time (for a time synchronized network) or a relative local time (measured at the local node)
Following the approach of [I-Dietf-core-link-format] and [I-Dshelby-core-resource-directory] sleep parameters for sleepy servers can be stored by the server in the RD and accessed by all interested clients
Examples of using these parameters in a synchronous or asynchronous manner are shown in the I-D
http6lowappnet coreIETF86 2013-03-12-13
We assume people have read the drafts
Meetings serve to advance difficult issues by making good use of face-to-face communications
Note Well Be aware of the IPR principles according to RFC 3979 and its updates
uumlBlue sheetsuumlScribe(s)
96
drar-shy‐iep-shy‐core-shy‐coapsubmiqed13 to13 IESG
2013-shy‐03-shy‐13
97
OMA Lightweight M2M Overview(A new standard using lots of IETF specs including DTLS
CoAP Block Observe Resource Directory SenMLhellip)
Zach ShelbyCoRE WG IETF-86 Orlando
OMA Lightweight M2Mbull Open Mobile Alliance is well known for Device Management (DM)bull OMA Lightweight M2M is a new standard from the alliance
ndash Focused on constrained Cellular and sensor network M2M devicesndash Driven by leading operators and vendors
bull Scopendash Interfaces protocol amp security between Device and Serverndash Object and Resource modelndash Bootstrap Device Access Control Connectivity and Firmware Objects
bull Draft Specifications are availablendash httpmemberopenmobileallianceorgftpPublic_documentsDM
LightweightM2MPermanent_documentsOMA-TS-LightweightM2M-V1_0_0-20130301-Dzip
bull Timelinendash Requirements and Architecture completed 3Q2012ndash Spec ready for Consistency Review 2Q2013ndash Candidate Approval expected 3Q2013
2 CoRE WG IETF-86 Orlando
Architecture
3
Scope of LWM2M
CoRE WG IETF-86 Orlando
Object Model
bull A Client has one or more Object Instancesbull An Object is a collection of Resourcesbull A Resource is an atomic piece of information
ndash Read Written or Executed
bull Resources can have multiple instancesbull Objects and Resources are identified by a
16-bit Integer Instances by an 8-bit Integerbull ObjectsResources are accessed with
simple URIs Object IDObject InstanceResource ID
eg 1213
4 CoRE WG IETF-86 Orlando
CoRE WG IETF-86 Orlando
CoRE Resource Directory
draft-shelby-core-resource-directory-05
Z Shelby C Bormann S Krco
Backgroundbull Not a new concept
ndash think web search engine or any link directorybull Defines the interfaces to a Resource Directorybull Based on Web Linking framework and the CoRE Link Formatbull Generic REST design for use over HTTP and CoAPbull Used by OMA Lightweight M2Mbull Has already been deployed
ndash In traffic monitoring systemsndash In street lighting systemsndash For vehicular asset trackingndash By a major Cellular M2M operator
Changes since -04
bull Restricted Update to parameter updatesbull Added pagination support for the Lookup interfacebull Changed rt= to et= for the registration amp update
interfacebull Added group support
Group Management
bull RD now includes group management featuresbull New Group Function Set
ndash Register a groupbull Group name domain multicast address endpoint members
ndash Remove a groupbull Group lookup using the Lookup Function Set
ndash List registered groupsndash Find the members of a groupndash Find groups with certain endpoints or resources
Registering a Group
EP RD
| |
| - POST rd-groupgp=lights ltgtep=node1 --gt |
| |
| |
| lt---- 201 Created Location rd-group12 ---- |
| |
Req POST coaprdexamplecomrd-groupgp=lights
Payload
ltgtep=node1
ltgtep=node2
Res 201 Created
Location rd-group12
Looking up Group Members
Client RD
| |
| ----- GET rd-lookupepgp=lights1 ----------------------gt |
| |
| |
| lt-- 205 Content ltrdgtd=domain1ltrdgtd=domain2 --------- |
| |
Req GET rd-lookupepgp=lights1
Res 205 Content
ltcoaphostportgtep=node1
ltcoaphostportgtep=node2rdquo
Things for the futurebull Support for JSON representation of Web Links
ndash httptoolsietforgiddraft-bormann-core-links-json-02txtbull Registry for RD registration query parameters
ndash Already OMA Lightweight has defined some new onesbull More examples
Group 3 ldquonew workrdquo(continued)
109
drar-shy‐greevenbosch-shy‐core-shy‐profile-shy‐descripon-shy‐01Bert13 GreevenboschJeroen13 Hoebeke
Isam13 IshaqFloris13 Van13 den13 Abeele
Descripon
bull JSON13 format13 for13 signalling13 the13 servers13 capabilies
bull Signalling13 of13 supported13 opons13 media13 types13 and13 block13 sizendash Other13 items13 can13 be13 added
bull Filtering13 on13 specific13 fields13 through13 URI-shy‐Querybull Link13 hqpdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐profile-shy‐descripon
well-shy‐knownprofile
bull To13 acquire13 profile13 data13 of13 resources13 on13 a13 parcular13 service13 the13 well-shy‐knownprofile13 URI-shy‐path13 is13 introduced
bull For13 example13 to13 get13 all13 informaon13 from13 sensors13 served13 by13 wwwexampleorg13 we13 can13 do13 a13 GET13 to13 coapwwwexampleorgwell-shy‐knownprofile
bull Filtering13 on13 parcular13 resources13 is13 done13 through13 URI-shy‐Queries
Format
bull Currently13 the13 following13 fields13 are13 definedndash ldquopathrdquo13 contains13 the13 URI-shy‐path13 associated13 with13 a13 resource
ndash ldquooprdquo13 a13 numerical13 list13 of13 supported13 opon13 numbers
ndash ldquocfrdquo13 a13 numerical13 list13 of13 supported13 content-shy‐format13 numbers
ndash ldquob1srdquo13 ldquob2srdquo13 supported13 block13 sizes13 for13 Block113 and13 Block213 respecvely
Examplebull On13 the13 right13 is13 an13 example13 of13 a13 camera13 sensor13 at13 coapwwwexampleorgcam13 that13 supports13 the13 Uri-shy‐Host13 (3)13 ETag13 (4)13 Uri-shy‐Port13 (7)13 Uri-shy‐Path13 (11)13 Content-shy‐Format13 (12)13 Token13 (19)13 Block213 (23)13 and13 Proxy-shy‐Uri13 (35)13 opons
bull The13 supported13 content13 formats13 are13 textplain13 (0)13 applicaon13 link-shy‐format13 (40)13 and13 applicaonjson13 (50)
bull The13 supported13 Block213 can13 use13 25613 or13 51213 byte13 blocks
Req13 GET13 coapwwwexampleorgwell-shy‐knownprofile13 Res13 20513 Content13 (applicationjson)13 13 13 13 profile13 13 13 13 13 13 13 13 pathcam13 13 13 13 op[3471112192335]13 13 13 13 13 cf[04050]13 13 13 13 13 b2s[45]13 13 13 13
Filtering13 through13 use13 of13 URI-shy‐Query
bull Filtering13 can13 be13 done13 through13 the13 URI-shy‐Querybull Query13 format13 N=V
ndash N13 is13 a13 profile13 fieldndash V13 is13 the13 desired13 value
bull Examplesndash To13 find13 resources13 that13 support13 content13 format13 ldquoapplicaonjsonrdquo
13 GET13 wwwexampleorgwell-shy‐knownprofilecf=50ndash To13 get13 informaon13 about13 the13 camera
13 GET13 wwwexampleorgwell-shy‐knownprofilepath=cam
Open13 issues
bull Which13 other13 profile13 data13 needs13 signallingndash Content-shy‐type13 for13 different13 methods
bull Fix13 the13 order13 in13 which13 the13 profile13 fields13 must13 appearndash Non-shy‐fixed13 order13 easier13 extensible
bull Inheritance13 of13 a13 profile13 descriponbull Extend13 usage13 to13 signal13 the13 client13 profilebull Integraon13 with13 link13 format
Thank13 youQuesons
drar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval-shy‐00
Bert13 Greevenbosch
Descripon
bull The13 ldquoMinimumRequestInterval13 opon13 can13 be13 used13 to13 indicate13 the13 minimum13 me13 between13 two13 requests13 in13 a13 transacon
bull Originally13 intended13 for13 Block13 but13 also13 usable13 for13 other13 transaconsndash Example13 browsing13 a13 server
bull The13 goal13 is13 to13 reduce13 the13 server13 load13 and13 network13 traffic
bull Link13 hqpsdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval
Usage
bull The13 client13 keeps13 the13 server13 informed13 about13 its13 request13 speed13 through13 inclusion13 of13 the13 ldquoMinimumRequestIntervalrdquo13 opon
bull In13 responses13 the13 server13 fixes13 the13 minimum13 request13 interval13 through13 the13 same13 opon
bull The13 client13 obeys13 the13 speed13 indicated13 by13 the13 server
bull The13 client13 can13 send13 slower13 but13 not13 faster
Advantages
bull The13 server13 has13 means13 to13 limit13 the13 amount13 of13 incoming13 traffic
bull The13 server13 can13 prevent13 to13 become13 overloaded13 with13 too13 many13 tasks
bull The13 server13 does13 not13 need13 arficially13 slow13 down13 the13 client13 by13 sending13 late13 ACKsndash No13 need13 to13 keep13 track13 of13 delayed13 ACKsndash The13 server13 can13 perform13 other13 tasks13 instead
bull Reduced13 network13 traffic
Thank13 youQuesons
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-links-json-02txt
123
RFC 6690 (link-format) documents are somewhat foreign to many web app developerssect would prefer to have them in JSON format
There is no standard way to represent link-format documents in applicationssect but everyone knows how to handle JSON
Define a standard JSON translation for link-format
Itrsquos
not
rock
et
scien
ce
ltsensorsgtct=40title=Sensor Index ltsensorstempgtrt=temperature-cif=sensor ltsensorslightgtrt=light-luxif=sensor lthttpwwwexamplecomsensorst123gt anchor=sensorstemprel=describedby lttgtanchor=sensorstemprel=alternate [hrefsensorsct40titleSensor Index hrefsensorstemprttemperature-cifsensor hrefsensorslightrtlight-luxifsensor hrefhttpwwwexamplecomsensorst123 anchorsensorstempreldescribedby hreftanchorsensorstemprelalternate]
124
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-ipsec-for-coap-00txt
IPsec definitions for CoAP Mostly placeholder at this time Who has implementation experience with this
125
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-cross-reverse-convention-00txt
This draft has two lines of payload(based on a WGLC comment by Cullen Jennings)
coap12344567foobara=3
httpwwwproxycomwellknowncore-translate1234_4567foobara=3
Is that a useful convention to have
126
Insert CI slides here
127
128
0
5
10
15
20
25
30
35
40
10 20 30 40 50 60 70
good
put (
pps)
pps
Goodput vs pps (Econotags)
goodput
[Khattak preliminary]
Congestion Control
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-cocoa-00txt
ldquoadvancedrdquo cc (The draft is just a first shot) Others may have better ideas
129
Insert post-WGLC discussion slides here
130
Stop Continue Start
131
An Agile Retrospective
http6lowappnet coreIETF86 2013-03-12-13
Stop
132
Endless new CoAP optionssect instead use RESTful as much as possible
Move general security lifecycle out Looking at theoretical problems
http6lowappnet coreIETF86 2013-03-12-13
Continue
Interops Running code Look at real-world examples and deployments Solve their actual problems
sect Unilateral enhancements eg higher performance congestion control
sect Transports (SMS hellip)sect Make Web linking and Directories more and more usefulsect RESTful Design Paradigms for real-world problems
133
http6lowappnet coreIETF86 2013-03-12-13
Start
Further push into the (browser) web world (HTML5 browser security)
Specific supporting worksect SenMLsect URI work (dev URN hellip)sect Security Processes (next slide)
Spin outsect (We donrsquot really get to decide where this is done)
134
http6lowappnet coreIETF86 2013-03-12-13
Security
Integrate Application Network Group Keyingsect Tunnel-free setup
Donrsquot redo what has been done alreadysect ZigBee IP is finesect But what about other scenarios
Simple REST interfaces for working with keying materials and authorizationsect Start with defining objectives
Object Security for Constrained Nodes135
Re-chartering CoREWhat do we want to do now that wersquore grown up
Zach ShelbyCoRE WG IETF-86 Orlando
What is the scope
bull So we have a protocol and Web Linking what next
bull Keep with what we know besthellip1 Enhancements around CoAP2 New transports for CoAP3 New representations for Web Links4 General application layer solutions
CoRE WG IETF-86 Orlando 2
Enhancements around CoAP
bull Advanced congestion control
CoRE WG IETF-86 Orlando 3
New Transports for CoAP
bull Infrastructure for CoAP over foondash httptoolsietforgiddraft-silverajan-core-
coap-alternative-transports-01txtbull CoAP over SMS
ndash httptoolsietforgiddraft-becker-core-coap-sms-gprs-03txt
ndash OMA Lightweightbull CoAP over TCP
ndash httptoolsietforgiddraft-li-core-coap-payload-length-option-01txt
CoRE WG IETF-86 Orlando 4
New support for Web Links
bull JSON Web Linksndash httptoolsietforgiddraft-bormann-core-links-
json-02txt
2332010 CoRE WG IETF-77 Anaheim 5
General application layer solutions
bull Resource Directoryndash httptoolsietforgiddraft-shelby-core-
resource-directory-05txtndash OMA Lightweight
2332010 CoRE WG IETF-77 Anaheim 6
0
01
02
03
04
05
06
07
08
09
1
10 20 30 40 50 60 70 80 90 100
Bad
ness
rem
aini
ng
Amount of time spent
asymptotic(x)
You are here
5
Group 1 2nd WGLCcoap-13 coap-14
6
http6lowappnet coreIETF86 2013-03-12-13
draft-ietf-core-coap-14
7
Will be published a couple of hours from nowsect please do read and comment again during IETF last call
Changes from ndash13sect Clarify that payload sniffing is acceptable only if no Content-
Format was suppliedsect Clarify that safe-to-forward options in a 203 Valid response
update the cachesect Clarify URI examples (Appendix B)sect Numerous editorial improvements and clarifications
sect Made Accept option non-repeatable
Repeatable13 Accept13 Opon
bull Problem
bull Soluon13 A13 ldquoJust13 do13 not13 do13 itrdquo13 and13 keep13 it13 generalbull Soluon13 B13 Change13 to13 non-shy‐repeatable
+ Predictable13 behavior13 when13 going13 through13 different13 caches+ Makes13 Accept13 and13 proxies13 easier13 to13 understand+ We13 have13 out-shy‐of-shy‐band13 content13 negoaon13 (ct=ldquoltAgt13 ltBgtrdquo)+ Can13 be13 added13 later13 as13 extension13 if13 really13 needed
GET13 someresAccept13 A13 B13
GET13 someresAccept13 B13 A13
someres13 (A13 B)13 =gt13 ltAgt
someres13 (B13 A)13 =gt13 ltAgt
Proxy
Also13 causesmulple13 observe13 relaonships
Cacheblowup
someresltAgt
Origin13 Server
Group 1a WGLC processingobserve block
9
http6lowappnet coreIETF86 2013-03-12-13
draft-ietf-core-observe-08
10
Changes from ndash07 to ndash08sect Expanded text on transmitting notification while a previous
transmission is pending (242)sect Changed reordering detection to use a fixed time span of 128
seconds instead of EXCHANGE_LIFETIME (276)sect Removed the use of the freshness model to determine if the
client is still on the list of observers
http6lowappnet coreIETF86 2013-03-12-13
draft-ietf-core-block-10
11
Still awaits grand editorial rewritesect right after coap-14 is shipped
http6lowappnet coreIETF86 2013-03-12-13
Tickets
hellip are our way to make the steps forward are at
http toolsietforgwgcore Updates are sent to the mailing list
sect Please review When we close a ticket please review once more
12
Group 2 groupcomm
13
Akbar RahmanEsko Dijk
IETF 86 March 2013httpwwwietforgiddraft-ietf-core-groupcomm-05txt
Group Communication for CoAP
Summary of Changes (14)
n I-D had two updates (Rev 04 amp 05) after IETF-85 (Atlanta) Many of the updates were due to the detailed review by Peter van der Stokn Thank you Peter for your valuable comments
n Changes from ietf-03 to ietf-04 n Section 23 (Potential Solutions for Group Communications) moved to
draft-dijk-core-groupcomm-misc (266)n Added reference to draft-keoh-tls-multicast-security to section 6 (Security
Considerations) n Appendix B (CoAP-Observe Alternative to Group Communications) moved
to draft-dijk-core-groupcomm-misc (267) n Deleted section 8 (Conclusions) as it is redundant (268) n Simplified light switch use case (269) by splitting into basic operations and
additional functions (269)
Summary of Changes (24)
n Changes from ietf-03 to ietf-04 (Continued) n Moved section 37 (CoAP Multicast and HTTP Unicast Interworking) to
draft-dijk-core-groupcomm-misc (270) n Moved section 331 (DNS-SD) and 332 (CoRE Resource Directory) to
draft-dijk-core-groupcomm-miscClarified that DNS based features are optional (272)
n Focus section 35 (Configuring Group Membership) on a single proposed solution
n Scope of section 53 (Use of MLD) widened to multicast destination advertisement methods in general
n Rewrote section 22 (Scope) for improved readibility n Moved use cases that are not adressed to draft-dijk-core-groupcomm-miscn Various editorial updates for improved readibility
Summary of Changes (34)
n Changes from ietf-04 to ietf-05 n Added a new section 39 (Exceptions) that highlights that IP multicast (and
hence group communications) is not always available (187) n Included guidelines on when (not) to use CoAP responses to multicast
requests and when (not) to accept multicast requests (273) n Added guideline on use of core-block for minimizing response size (275)n Restructured section 6 (Security Considerations) to more fully describe
threats and threat mitigation (277) n Clearly indicated that DNS resolution and reverse DNS lookup are optional n Removed confusing text about a single group having multiple IP addresses
If multiple IP addresses are required then multiple groups (with the same members) should be created
n Removed repetitive text about the fact that group communications is not guaranteed
Summary of Changes (44)
n Changes from ietf-04 to ietf-05 (Continued) n Merged previous section 52 (Multicast Routing) into 31 (IP Multicast
Routing Background) and added link to section 52 (Advertising Membership of Multicast Groups)
n Clarified text in section 38 (Congestion Control) regarding precedence of use of IP multicast domains (ie first try to use link-local scope then site-local scope and only use global IP Communication for CoAP multicast as a last resort)
n Extended group resource manipulation guidelines with use of preconfigured portspaths for the multicast group
n Consolidated all text relating to ports in a new section 33 (Port Configuration)
n Clarified that all methods (GETPUTPOST) for configuring group membership in endpoints should be unicast (and not multicast) in section 37 (Configuring Group Membership In Endpoints)
n Various editorial updates for improved readability
Discussion item (11)
n Solution for Configuring Group Membership (no ticket)n Example of (unicast) configuring an endpoint to be part of one multicast
groupReq POST gp (Content-Format applicationjson)
n floor1westbldg6examplecom ip ff154200f7feed3714cb Res 204 Changed
n Where the ldquogprdquo resource has resource type (rt) ldquocoregprdquo which is defined for this purpose
n Question Do we want specify such a solution (or for example leave it completely up to implementation)
Open Issues(15)
n Review Groupcomm requirements language (271)n Decision made to keep requirements language for informational draftn Each use of MAYMUSTSHOULD etc is to be reviewed
Open Issues(25)
n Add section on multicast via Proxy and its limitations (274)n Add a section to explain the issues amp limitations of doing CoAP multicast
requests via a CoAP Proxy n Goal is to warn and guide implementers in this subject n Also such a section would provide a placeholderreminder of the problems
that might be addressed further in the futuren Based on IETF 85 CoRE WG meeting discussion on Multicast CoAP
requests via a Proxy Discussion summary for referencen Aggregation of responses in a proxy is difficult since it doesnt know
when to stop aggregating responses n SIP tried to deal with this problem but didnt solve it n There may be an expectancy of CoAP client to get single response
back from proxy not multiple The client in this case may not even know what it could expect It may not even know the Proxy-URI contains a multicast target
n Presented via-proxy use case exposes gap in the core-coap specification regarding multicast via proxy (Note Expectation is that core-coap wonrsquot address it in the first planned RFC release)
Open Issues(35)
n Issues with twomultiple Resource Directories in use case (280)n Some potential issues with RD came out of review Peter van der Stok and
WG discussion IETF85 n There are two RD servers use case shows that only one is found despite
the fact that site-local multicast is used - should be two RDs found n Proposal simplify use case to a single RD server on the backbone to avoid
such RD-specific issues like synchronization of RD information between servers
Open Issues(45)
n Add single-subnet configuration to use cases (278)n Suggested by review Peter van der Stok and IETF85 WG discussion that
its best to start explaining the simplebasic cases and then gradually build up complexity
n Simplest case not shown yet would be a single subnet network configuration which is currently not present in the I-D only the 2-subnet configuration of Fig 1
n Question Do we need to add such case or doesnt it add muchn (Note that core-coap Figure 22 already shows the simplest case of link-local
multicast)
Open Issues(55)
n Add use case with controller (client) located on the backbone (279)n Suggested by discussion following review Peter van der Stok n Case missing where a controller (client) is located on the backbonen Question Do we need to add such case or does it add much
Group 2a other old friends
25
Angelo Castellani Salvatore Loreto Akbar Rahman Thomas Fossati Esko Dijk
IETF 86 March 2013httpwwwietforgiddraft-castellani-core-http-mapping-07txt
Best Practices for HTTP-CoAP Mapping
Implementation
Summary of Changes (from -06 rev)
n Based on discussion at last IETF-85 (Atlanta)n Clarification of HTTP-CoAP Proxies
n Definitionn Placementn Benefits
n Clarification of HTTP-CoAP URI mapping options
Goals of I-D
n For Reverse HTTP-CoAP Cross Protocol Proxyn Provide more detailed information to proxy designers (beyond
Section 10 of [I-Dietf-core-coap]) to help implement proxies that correctly inter-work with other CoAP and HTTP clientserver implementations that adhere to the specifications
n Define a consistent set of guidelines that a HTTP-to-CoAP proxy implementation MAY adhere to The main reason of adhering to such guidelines is to reduce variation between proxy implementations thereby increasing interoperabilityn As an example use case a proxy conforming to these guidelines made
by vendor A can be easily replaced by a proxy from vendor B that also conforms to the guidelines
I-D Outline
n Guidance on HTTP to CoAP URI mappingn HTTP-CoAP Reverse cross-protocol proxy implementation
n Placementn Response code amp media type translationsn Caching and congestion controln Cache refresh via Observen Use of CoAP blockwise transfern Security translation
n Security Considerationsn Traffic overflown Handling secured exchanges
Definitions (12)
n Cross-Protocol Proxy (or Cross Proxy) is a proxy performing a cross- protocol mapping in the context of this document a HTTP-CoAP (HC) mapping A Cross-Protocol Proxy can behave as a Forward Proxy Reverse Proxy or Interception Proxy n Note In this document we focus on the Reverse Proxy mode of the
Cross-Protocol Proxy
n Forward Proxy a message forwarding agent that is selected by the client usually via local configuration rules to receive requests for some type(s) of absolute URI and to attempt to satisfy those requests via translation to the protocol indicated by the absolute URI The user decides (is willing to) use the proxy as the forwardingdereferencing agent for a predefined subset of the URI space
Definitions (22)
n Reverse Proxy a receiving agent that acts as a layer above some other server(s) and translates the received requests to the underlying servers protocol It behaves as an origin (HTTP) server on its connection towards the (HTTP) client and as a (CoAP) client on its connection towards the (CoAP) origin server The (HTTP) client uses the origin-form [I-Dietf-httpbis-p1-messaging] as a request- target URI
n Reverse and Forward proxies are technically very similar with main differences being that the former appears to a client as an origin server while the latter does not and that clients may be unaware they are communicating with a proxy
Reverse Cross-Protocol Proxy Deployment Scenario
HTTP-CoAP Response Code Mapping
Implementation Experience
n Direct experience from the draft authorsn Squid HTTP-CoAP mapping module
n University of Padovan httptelecomdeiunipditiotn Both Forward and Interception operation supported
n HTTP-CoAP proxy based on EvCoAPn KoanLogic University of Bologna and Salvatore
Loreto (as individual)n httpsgithubcomkoanlogicwebthingstreemasterbridgesw
libevcoapn The document is open to input from other implementations
Next Steps
n Does the WG recommend adoptionn Intended status Informational Best Practicen Purpose Reduce arbitrary variation between proxy
implementations thereby increasing interoperability
Backup
HTTP to CoAP URI Mapping Options (12)
n Embedded Mapping n In an embedded mapping approach the HTTP URI has embedded
inside it the authority and path part of the CoAP URI n Example The CoAP resource nodecoapsomethingnetfoo can
be accessed by an HTTP client by inserting in the request httphc-proxysomethingnetcoapnodecoapsomethingnetfoo The Cross-Protocol Proxy then maps the URI to coapnodecoapsomethingnetfoo
HTTP to CoAP URI Mapping Options (22)
n Homogeneous Mapping n In a homogeneous mapping approach only the scheme portion of the URI
needs to be mapped The rest of the URI (ie authority path etc) remains unchanged
n Example The CoAP resource coapnodecoapsomethingnetfoo can be accessed by an HTTP client by requesting httpnodecoapsomethingnetfoo The Cross-Protocol Proxy receiving the request is responsible to map the URI to coapnodecoapsomethingnetfoo
n Background info n The assumption in this case is that the HTTP client would be able to
successfully resolve nodecoapsomethingnet using DNS infrastructure to return the IP address of the HC proxy Most likely this would be through a two step DNS lookup where the first DNS lookup would resolve somethingnet using public DNS infrastructure
n Then the second DNS lookup on the subdomain coap and the host node would typically be resolved by a DNS server operated by the owner of domain somethingnet So this domain owner can manage its own internal node names and subdomain allocation which would correspond to the CoAP namespace
Group 3 ldquonew workrdquo
39
Transport of CoAP over SMS USSD and GPRSdraft-becker-core-coap-sms-gprs-03
Markus Becker Kepeng LiKoojana Kuladinithi Thomas Poumltsch
CoRE WG IETF-86 Orlando
1 10
ScenariosI In M2M communication IP connectivity is not alwayssupported by the constrained end-points
I Power savingI Coverage (GPRS 3G LTE)
I SMS and USSD based communication is almost alwayssupported
210
Changes from draft-01 to draft-03 (1)
I Added possible CONNONACK interactions Section 5
I Option name changed from Reply-To- to Response-To-Section 16 and Section 101
I Added URI schemeEg coap+tel+15105550101well-knowncore Section 11
I Added possible M2M proxy scenarios Section 14
3 10
Changes from draft-01 to draft-03 (2)
I Added reference to bormann-coap-misc for other SMSencoding Section 71
I Updated requirements on Uri-Host and Uri-Port forcoap+tel Section 10
I Added security considerations Transport and ObjectSecurity Section 15
I Chose CoAP option numbers and updated the optionnumber table to meet draft-ietf-core-coap-10 Table 1
I Added an IANA registration for the URI scheme coap+telSection 162
4 10
Feedback Split coap+tel into coap+smsand coap+ussd
I How else to differ the various transports in the URII Or is the transport to use decided by the implementationI See alsodraft-silverajan-core-coap-alternative-transports-01
5 10
Feedback Response-To-Scheme option
I Should there be a Response-To-Scheme optionadditionally to Response-To-Uri-Host andResponse-To-Uri-Path
I So that a CoAP end-point which receives a request by CoAPover non-IP transport can be instructed to also use thenon-IP transport for the response
I This would imply to add aResponse-To-Telephone-Subscriber and more options forother transports that have other URI schemes than coapand coaps
6 10
Feedback Selection of Transport by Client
I When a server is reachable by various transports howdoes a client decide which transport to use
I Client-side application congurationI Leave it to a proxy which uses cellular network lookupfunctions
7 10
Feedback Potential Threats
I Trigger expensive short messagesI Redirect trac to other addressesI More threats
I Are the security measures in the draft adequateI Whitelisting on serverI Relying on cellular network security (dedicated M2M APNs)I Object security on CoAP payload
8 10
Feedback Message Exchanges
I Figures 11-18 show possible message exchanges whenclient and server have two addresses
I With NON Not using CoAP retransmission capabilityI ACK on different transportI Additional (costly) message on Transport AI Request with Content
I Which ones are allowedI Which ones are meaningful
9 10
Next steps
I Rene Uri schemeI Response-To-Scheme optionI Selection of Message ExchangeI Rene Proxying
10 10
CoAP13 Communicaon13 with13 Alternave13 Transports
Bill Silverajan and Teemu SavolainenCore WG IETF 86 Orlando
031113
Objecves13 (In13 Scope)
bull Unambiguous13 representaon13 of13 transport13 to13 be13 used13 by13 CoAP
bull Details13 how13 the13 transport13 can13 carry13 CoAP13 packet
bull Focus13 is13 on13 what13 CoAP13 communicaons13 requirements13 are
bull Allow13 CoAP13 mechanisms13 to13 exploit13 cross-shy‐layer13 opmisaons
51
031113
Non13 Goals13 (Not13 in13 scope)
bull Applicaon-shy‐level13 QoS13 requirementsbull Real-shy‐me13 constraintsbull Ordering13 reliability13 congeson13 controlbull Applicaon13 and13 network13 adaptaonbull Mobility13 and13 readdressing13 supportbull Network13 protocol13 (eg13 IPsec)13 configuraon
52
031113
Use13 Cases
bull NAT13 and13 Firewall13 traversal13 with13 TCPbull Delay13 Tolerant13 Networkingbull Non-shy‐IP13 Low13 Energy13 Protocols
53
031113
Related13 Work
bull OMA13 Lightweight13 M2M13 Protocolbull CoAP13 over13 SMSGPRSUSSD
54
031113
What13 does13 the13 work13 entail
bull The13 ability13 to13 specify13 end13 point13 idenfiers13 and13 URIs13 to13 reflect13 which13 transport13 CoAP13 can13 use
bull The13 ability13 to13 register13 to13 resource13 directories13 resource13 types13 reflecng13 types13 of13 transport13 available
bull Ability13 for13 mul-shy‐transport13 nodes13 to13 select13 transport13 to13 use13 without13 significant13 alteraon13 to13 CoAP13 packet13 structure
55
031113
Points13 to13 consider
bull Requirements13 for13 transport13 layer13 protocol13 to13 carry13 CoAP13 packets
bull Representaon13 of13 URI13 scheme13 for13 generic13 transport13 protocols
bull Opon13 extensions13 for13 CoAP13 to13 express13 available13 transports
bull Mapping13 and13 message13 sizebull Security13 consideraons
56
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
URI13 =13 scheme13 13 13 authority13 path-shy‐abempty13 [13 query13 ]
bull Within13 the13 scheme13 namebull In13 the13 URI13 pathbull As13 a13 query13 component
57
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
bull Within13 the13 scheme13 namendash coap+tel+15105550101well-shy‐knowncorendash coap+tcpexamplecom5683temperaturendash coap+blel2cap[1234567890AB]4pulse
bull Easy13 URI13 parsing13 for13 transport13 type13 and13 idenfier
bull Each13 new13 scheme13 name13 requires13 IANA13 registraon
58
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
bull In13 the13 URI13 pathndash coaphostexamplecomtransport=tcpwell-shy‐knowncorert=core-shy‐rd
bull Easy13 adopon13 of13 new13 (and13 experimental)13 CoAP13 transports13 without13 IANA13 registraon
bull Caveat13 Uri-shy‐Path13 opon13 is13 a13 Crical13 CoAP13 opon13 see13 secon13 54113 of13 I-shy‐Diep-shy‐core-shy‐coap
59
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
bull As13 a13 URI13 query13 componentndash coaphostexamplecomwell-shy‐knowncorert=core-shy‐rdq=tcp
bull Also13 easy13 to13 adopt13 new13 (and13 experimental)13 CoAP13 transports13 without13 IANA13 registraon
bull Caveat13 Uri-shy‐Query13 opon13 is13 a13 Crical13 CoAP13 opon13 see13 secon13 54113 of13 I-shy‐Diep-shy‐core-shy‐coap
60
031113
URI13 Representaons13 for13 CoAPNon13 standard13 ways
bull Transport13 in13 the13 URI13 authority13 componentndash coaphost[port][transport]13 instead13 of13 coaphost[port]
bull Transport13 as13 a13 service13 URLndash servicecoaptcphostexamplecomwell-shy‐knowncorert=core-shy‐rd
bull Above13 two13 ways13 break13 exisng13 compability13 (although13 both13 are13 based13 on13 valid13 IANA13 URI13 registraons)
61
031113
URI13 Representaons13 for13 CoAPMiscellaneous13 Consideraons
bull Ensure13 that13 transport13 is13 defined13 unambiguously13 (eg13 L2CAP13 used13 by13 both13 BLE13 and13 standard13 Bluetooth13 so13 avoid13 rdquocoap+l2caprdquo13 or13 rdquotransport=l2caprdquo13 or13 rdquoq=l2caprdquondash Can13 be13 done13 as13 WG13 consensusndash Namespace13 approach13 eg13 rdquocoap+blel2caprdquo13 or13 rdquoq=blel2caprdquo
bull Allow13 end-shy‐points13 to13 use13 CoAP13 Resource13 Directory13 to13 register13 alternave13 transports13 and13 idenfiers13 and13 provide13 periodic13 updatesndash Register13 rdquocore-shy‐transportrdquo13 resource13 type
62
031113
Transport13 Consideraons
bull Uniqueness13 of13 end-shy‐point13 idenficaonbull Communicaon13 support13 Unidireconal13 Bidireconal13 1N13 (broadcast13 mulcast13 anycast)13 messaging
bull Binary13 encoding13 Network13 byte13 orderingbull MTU13 correlaon13 with13 CoAP13 PDU13 sizebull Transport13 latency
63
031113
Security13 Consideraons
bull Drar13 does13 not13 introduce13 new13 security13 requirements13 by13 itself
bull There13 may13 be13 privacy13 issues13 if13 nodes13 use13 telephone13 numbers13 or13 MAC13 addresses13 as13 public13 end13 point13 idenfiers
64
Akbar Rahman
IETF 86 March 2013 httpwwwietforgiddraft-rahman-core-sleepy-02txt
Enhanced Sleepy Node Support for CoAP
Introduction
It is expected that in CoAP networks there will be a certain portion of devices that are sleepy and which may occasionally go into a sleep mode (ie go into a low power state to conserve power) and subsequently have reduced CoAP protocol communication ability
This I-D proposes a minimal and efficient mechanism building on the Resource Directory concept (which will be integrated into a CoAP Proxy) to enhance sleepy node support in CoAP networks
Main Question from IETF-85 (Atlanta)
What performance benefit does the proposed Sleepy Node support solution give in a network that already has standard CoAP caching enabled
Sleepy Node Performance Analysis
Experimental Network
1-5 clients
Both Sleepy and Non-
Sleepy servers
Sleepy Node Performance Analysis Network Setup
CoAPSleepyServer(s)
CoAPSleepAwareReverseProxy
CoAP
Client(s)
Request
Response
Sleep9AwareCoREResourceDirectoryCapability
PublishedSleepParameters
Sleep9AwareCoAPStoreandForwardCapability Response
Request
SleepAwareCoAP503ResponseCapability
CoAPCachingCapability
bull Server supports publishing sleep parameters to proxy bull Eg Irsquom going to be asleep for X seconds
bull Proxy supports sleep-awareness capabilities bull Proxy also supports caching capability based off of maxAge bull Protocol flow similar to approach of Figure 1 (Synchronous RD Based Sleep
Tracking) of I-D
Proxy capabilities can be selectively enableddisabled
Proxy ndash Server Interface
Client ndash Proxy Interface
CoAP Sleep-Aware Reverse Proxy Features CoRE Sleep-aware Resource Directory
Support storing published sleep parameters from CoAP servers sleepState (AWAKE ASLEEP) sleepDuration
Sleep-aware CoAP 503 Response Capability If CoAP request to a sleeping server is received proxy returns a
lsquo503 Retry-Afterrsquo response to client 503 contains a timestamp indicating when the sever will wake back up
(timestamp delivered in CoAP maxAge option) Sleep-aware CoAP Store-and-Forward Capability
If CoAP request to a sleeping server is received proxy stores request until server wakes up and then forwards it
Caching capability Cache GET responses from server if maxAge option is present
(this is not a sleep aware feature)
Goals of Performance Analysis
For networks having sleepy servers provide measurements to quantify the impact that CoAP sleep-awareness capabilities can have
See if sleep-awareness capabilities can
provide additional benefits even when CoAP caching is used
Overview of Performance Analysis Performed The analysis was broken up into a set of test scenarios Each test scenario used a different combination of the following
variables Client issued GET requests Server was configured as a sleepy or non-sleepy server Proxy caching of GET responses was enabled or disabled Proxy sleep-aware 503 response capability was enabled or disabled Proxy store-and-forward capability was enabled or disabled maxAge in GET responses ndash Two values were tested 60sec and 5sec of Clients ndash Two values were used ndash 1 client and 5 clients
For comparison purposes the following were held constant across all test scenarios Client issued a fixed number of requests (100) across all test scenarios Client used a delay between each GET request (35sec) to better exercise
proxyrsquos caching and sleep-awareness capabilities For sleepy server test scenarios the server slept 60 sec awake for 3 sec
Format of Results The following results were collected for each
test scenario
Breakdown of the and types of transactions occurring between clientproxyserver
ldquoGETrdquo ndash Test Scenario Results
GET ndash Description of Test Scenarios
TestScenarios-GET
Scenario
CoAPSleepyServerSe7ngs CoAPSleepAwareReverseProxySe7ngs CoAPClientSe7ngs
SleepDuragton(sec)
AwakeDuragton(sec)
maxAge(sec) Caching SleepAwareSAF+
503NumberofClients
NumberofGETs
DelayBetweenClient
Requests(sec)
1a 0 Always 60 Enabled Disabled 1 100 35
1b 60 3 60 Enabled Disabled 1 100 35
1c 60 3 60 Enabled Enabled 1 100 35
2a 0 Always 60 Enabled Disabled 5 100 35
2b 60 3 60 Enabled Disabled 5 100 35
2c 60 3 60 Enabled Enabled 5 100 35
3a 0 Always 5 Enabled Disabled 5 100 35
3b 60 3 5 Enabled Disabled 5 100 35
3c 60 3 5 Enabled Enabled 5 100 35
ldquoGETrdquo ndash Test Scenario 1 Results
maxAge = 60 and 1 Client
GET ndash Scenario 1 ClientProxy Interface Transaction Mix
Scenarios 1a - Non-Sleepy Server Caching Proxy maxAge = 60sec 1b- Sleepy Server Caching Proxy maxAge = 60sec 1c - Sleepy Server Sleep Aware Proxy maxAge = 60sec
Sleep Aware Proxy has better performance for sleepy servers
0
100
200
300
400
500
600
700
1a 1b 1c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
GET ndash Scenario 1 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
Scenarios 1a - Non-Sleepy Server Caching Proxy maxAge = 60sec 1b- Sleepy Server Caching Proxy maxAge = 60sec 1c - Sleepy Server Sleep Aware Proxy maxAge = 60sec
0
100
200
300
400
500
600
700
800
1a 1b 1c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
ldquoGETrdquo ndash Test Scenario 2 Results
maxAge = 60 and 5 Clients
GET ndash Scenario 2 ClientProxy Interface Transaction Mix
Sleep Aware Proxy has slightly better performance for sleepy servers
0
200
400
600
800
1000
1200
1400
2a 2b 2c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
Scenarios 2a - Non-Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2b- Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2c - Sleepy Server Sleep Aware Proxy maxAge = 60sec 5 Clients
See ldquoExperimental Artifactsrdquo Note 1
GET ndash Scenario 2 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has slightly better performance for sleepy servers
0
50
100
150
200
250
300
350
400
2a 2b 2c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
Scenarios 2a - Non-Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2b- Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2c - Sleepy Server Sleep Aware Proxy maxAge = 60sec 5 Clients
See ldquoExperimental Artifactsrdquo Note 2
Experimental Artifacts Note 1
Currently in the experiment the sleep aware proxy checks the cached state of a resource before putting a request into its Store-and-forward queue while a server is sleeping Once in the queue the proxy unconditionally forwards the queued requests to the server once it wakes up This is not the most efficient setup and can easily be improved If the proxy instead checks its cache again before forwarding each queued request it may not need to forward the request to the server For example if there are two queued GET requests in the proxyrsquos queue that address the same resource Only the first request needs to be sent to the server the second request can use the cached response from the first request
Note 2 Currently in the experiment the sleepy server sends a sleepState PUT request to the
proxy each time it goes to sleep This is not the most efficient setup and can easily be improved For example if the server assumes that the proxy can keep track of its ONOFF cycles with its internal timers (eg as per Fig 1 of I-D) then the number of messages from the sleepy server dramatically goes down
ldquoGETrdquo ndash Test Scenario 3 Results
maxAge = 5 and 5 Clients
GET ndash Scenario 3 ClientProxy Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
Scenarios 3a - Non-Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3b- Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3c - Sleepy Server Sleep Aware Proxy maxAge = 5sec 5 Clients
0
500
1000
1500
2000
2500
3000
3500
4000
4500
5000
3a 3b 3c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
GET ndash Scenario 3 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
0
1000
2000
3000
4000
5000
6000
7000
3a 3b 3c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
Scenarios 3a - Non-Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3b- Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3c - Sleepy Server Sleep Aware Proxy maxAge = 5sec 5 Clients
Conclusions
Conclusions These results show that sleep-aware CoAP
proxy features can significantly optimize communication with sleepy servers in most scenarios
These results also show that sleep-
awareness capabilities can provide additional benefits above and beyond CoAP caching in most scenarios
Backup
Current CoAP Support of Sleepy Node (12)
CoAP proxies can use a previously cached response to service a new GET request for a sleepy origin server (as in HTTP) But if no valid cache then proxy has to attempt to
retrieve and may fail if origin server is sleeping [I-Dietf-core-coap]
Clients can discover list of resources from RD (GET rd-lookuphellip) for sleepy servers But attempt to GET resource from sleepy origin server
may fail if origin server is sleeping [IDietf-core-link-format amp IDshelby-core-resource-
directory]
Current CoAP Support of Sleepy Node (22)
Lower layer support for sleepy nodes in most wireless technologies (eg WiFi ZigBee) But limited to MAC packet scheduling for sleepy nodes
and not aware of specific needs of IP applications (like CoAP)
Proposal ndash RD Based Sleep Tracking (14)
The current CoAP approach to support sleepy nodes can be significantly improved by introducing RD based mechanisms for a CoAP client to determine whether A targeted resource is located on a sleepy server A sleepy server is currently in sleep mode or not
There is any associated caching Proxy (possibly the RD itself) for a sleepy server
Proposal ndash RD Based Sleep Tracking (24)
We define the following new RD attributes to characterize the properties of a sleepy node SleepState - Indicates whether the node is currently in
sleep mode or not (ie Sleeping or Awake) SleepDuration - Indicates the maximum duration of time
that the node stays in sleep mode TimeSleeping - Indicates the length of time the node
has been sleeping (ie if Sleep State = Sleeping) NextSleep - Indicates the next time the node will go to
sleep (ie if Sleep State = Awake)
CachingProxy ndash Indicates the caching proxy of the sleepy node (ie the RD itself or another node)
Proposal ndash RD Based Sleep Tracking (34)
These attributes are all server (node) level and are new parameters added to the RD URI Template Variables
Finally we also define a new lookup-type (ss) for the RD lookup interface specified in [I-Dshelby-core-resource-directory] This new lookup-type supports looking up the
ldquoSleepStaterdquo (ss) of a specified end-point
Proposal ndash RD Based Sleep Tracking (44)
The three time based parameters (SleepDuration TimeSleeping NextSleep) can be based on either an absolute network time (for a time synchronized network) or a relative local time (measured at the local node)
Following the approach of [I-Dietf-core-link-format] and [I-Dshelby-core-resource-directory] sleep parameters for sleepy servers can be stored by the server in the RD and accessed by all interested clients
Examples of using these parameters in a synchronous or asynchronous manner are shown in the I-D
http6lowappnet coreIETF86 2013-03-12-13
We assume people have read the drafts
Meetings serve to advance difficult issues by making good use of face-to-face communications
Note Well Be aware of the IPR principles according to RFC 3979 and its updates
uumlBlue sheetsuumlScribe(s)
96
drar-shy‐iep-shy‐core-shy‐coapsubmiqed13 to13 IESG
2013-shy‐03-shy‐13
97
OMA Lightweight M2M Overview(A new standard using lots of IETF specs including DTLS
CoAP Block Observe Resource Directory SenMLhellip)
Zach ShelbyCoRE WG IETF-86 Orlando
OMA Lightweight M2Mbull Open Mobile Alliance is well known for Device Management (DM)bull OMA Lightweight M2M is a new standard from the alliance
ndash Focused on constrained Cellular and sensor network M2M devicesndash Driven by leading operators and vendors
bull Scopendash Interfaces protocol amp security between Device and Serverndash Object and Resource modelndash Bootstrap Device Access Control Connectivity and Firmware Objects
bull Draft Specifications are availablendash httpmemberopenmobileallianceorgftpPublic_documentsDM
LightweightM2MPermanent_documentsOMA-TS-LightweightM2M-V1_0_0-20130301-Dzip
bull Timelinendash Requirements and Architecture completed 3Q2012ndash Spec ready for Consistency Review 2Q2013ndash Candidate Approval expected 3Q2013
2 CoRE WG IETF-86 Orlando
Architecture
3
Scope of LWM2M
CoRE WG IETF-86 Orlando
Object Model
bull A Client has one or more Object Instancesbull An Object is a collection of Resourcesbull A Resource is an atomic piece of information
ndash Read Written or Executed
bull Resources can have multiple instancesbull Objects and Resources are identified by a
16-bit Integer Instances by an 8-bit Integerbull ObjectsResources are accessed with
simple URIs Object IDObject InstanceResource ID
eg 1213
4 CoRE WG IETF-86 Orlando
CoRE WG IETF-86 Orlando
CoRE Resource Directory
draft-shelby-core-resource-directory-05
Z Shelby C Bormann S Krco
Backgroundbull Not a new concept
ndash think web search engine or any link directorybull Defines the interfaces to a Resource Directorybull Based on Web Linking framework and the CoRE Link Formatbull Generic REST design for use over HTTP and CoAPbull Used by OMA Lightweight M2Mbull Has already been deployed
ndash In traffic monitoring systemsndash In street lighting systemsndash For vehicular asset trackingndash By a major Cellular M2M operator
Changes since -04
bull Restricted Update to parameter updatesbull Added pagination support for the Lookup interfacebull Changed rt= to et= for the registration amp update
interfacebull Added group support
Group Management
bull RD now includes group management featuresbull New Group Function Set
ndash Register a groupbull Group name domain multicast address endpoint members
ndash Remove a groupbull Group lookup using the Lookup Function Set
ndash List registered groupsndash Find the members of a groupndash Find groups with certain endpoints or resources
Registering a Group
EP RD
| |
| - POST rd-groupgp=lights ltgtep=node1 --gt |
| |
| |
| lt---- 201 Created Location rd-group12 ---- |
| |
Req POST coaprdexamplecomrd-groupgp=lights
Payload
ltgtep=node1
ltgtep=node2
Res 201 Created
Location rd-group12
Looking up Group Members
Client RD
| |
| ----- GET rd-lookupepgp=lights1 ----------------------gt |
| |
| |
| lt-- 205 Content ltrdgtd=domain1ltrdgtd=domain2 --------- |
| |
Req GET rd-lookupepgp=lights1
Res 205 Content
ltcoaphostportgtep=node1
ltcoaphostportgtep=node2rdquo
Things for the futurebull Support for JSON representation of Web Links
ndash httptoolsietforgiddraft-bormann-core-links-json-02txtbull Registry for RD registration query parameters
ndash Already OMA Lightweight has defined some new onesbull More examples
Group 3 ldquonew workrdquo(continued)
109
drar-shy‐greevenbosch-shy‐core-shy‐profile-shy‐descripon-shy‐01Bert13 GreevenboschJeroen13 Hoebeke
Isam13 IshaqFloris13 Van13 den13 Abeele
Descripon
bull JSON13 format13 for13 signalling13 the13 servers13 capabilies
bull Signalling13 of13 supported13 opons13 media13 types13 and13 block13 sizendash Other13 items13 can13 be13 added
bull Filtering13 on13 specific13 fields13 through13 URI-shy‐Querybull Link13 hqpdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐profile-shy‐descripon
well-shy‐knownprofile
bull To13 acquire13 profile13 data13 of13 resources13 on13 a13 parcular13 service13 the13 well-shy‐knownprofile13 URI-shy‐path13 is13 introduced
bull For13 example13 to13 get13 all13 informaon13 from13 sensors13 served13 by13 wwwexampleorg13 we13 can13 do13 a13 GET13 to13 coapwwwexampleorgwell-shy‐knownprofile
bull Filtering13 on13 parcular13 resources13 is13 done13 through13 URI-shy‐Queries
Format
bull Currently13 the13 following13 fields13 are13 definedndash ldquopathrdquo13 contains13 the13 URI-shy‐path13 associated13 with13 a13 resource
ndash ldquooprdquo13 a13 numerical13 list13 of13 supported13 opon13 numbers
ndash ldquocfrdquo13 a13 numerical13 list13 of13 supported13 content-shy‐format13 numbers
ndash ldquob1srdquo13 ldquob2srdquo13 supported13 block13 sizes13 for13 Block113 and13 Block213 respecvely
Examplebull On13 the13 right13 is13 an13 example13 of13 a13 camera13 sensor13 at13 coapwwwexampleorgcam13 that13 supports13 the13 Uri-shy‐Host13 (3)13 ETag13 (4)13 Uri-shy‐Port13 (7)13 Uri-shy‐Path13 (11)13 Content-shy‐Format13 (12)13 Token13 (19)13 Block213 (23)13 and13 Proxy-shy‐Uri13 (35)13 opons
bull The13 supported13 content13 formats13 are13 textplain13 (0)13 applicaon13 link-shy‐format13 (40)13 and13 applicaonjson13 (50)
bull The13 supported13 Block213 can13 use13 25613 or13 51213 byte13 blocks
Req13 GET13 coapwwwexampleorgwell-shy‐knownprofile13 Res13 20513 Content13 (applicationjson)13 13 13 13 profile13 13 13 13 13 13 13 13 pathcam13 13 13 13 op[3471112192335]13 13 13 13 13 cf[04050]13 13 13 13 13 b2s[45]13 13 13 13
Filtering13 through13 use13 of13 URI-shy‐Query
bull Filtering13 can13 be13 done13 through13 the13 URI-shy‐Querybull Query13 format13 N=V
ndash N13 is13 a13 profile13 fieldndash V13 is13 the13 desired13 value
bull Examplesndash To13 find13 resources13 that13 support13 content13 format13 ldquoapplicaonjsonrdquo
13 GET13 wwwexampleorgwell-shy‐knownprofilecf=50ndash To13 get13 informaon13 about13 the13 camera
13 GET13 wwwexampleorgwell-shy‐knownprofilepath=cam
Open13 issues
bull Which13 other13 profile13 data13 needs13 signallingndash Content-shy‐type13 for13 different13 methods
bull Fix13 the13 order13 in13 which13 the13 profile13 fields13 must13 appearndash Non-shy‐fixed13 order13 easier13 extensible
bull Inheritance13 of13 a13 profile13 descriponbull Extend13 usage13 to13 signal13 the13 client13 profilebull Integraon13 with13 link13 format
Thank13 youQuesons
drar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval-shy‐00
Bert13 Greevenbosch
Descripon
bull The13 ldquoMinimumRequestInterval13 opon13 can13 be13 used13 to13 indicate13 the13 minimum13 me13 between13 two13 requests13 in13 a13 transacon
bull Originally13 intended13 for13 Block13 but13 also13 usable13 for13 other13 transaconsndash Example13 browsing13 a13 server
bull The13 goal13 is13 to13 reduce13 the13 server13 load13 and13 network13 traffic
bull Link13 hqpsdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval
Usage
bull The13 client13 keeps13 the13 server13 informed13 about13 its13 request13 speed13 through13 inclusion13 of13 the13 ldquoMinimumRequestIntervalrdquo13 opon
bull In13 responses13 the13 server13 fixes13 the13 minimum13 request13 interval13 through13 the13 same13 opon
bull The13 client13 obeys13 the13 speed13 indicated13 by13 the13 server
bull The13 client13 can13 send13 slower13 but13 not13 faster
Advantages
bull The13 server13 has13 means13 to13 limit13 the13 amount13 of13 incoming13 traffic
bull The13 server13 can13 prevent13 to13 become13 overloaded13 with13 too13 many13 tasks
bull The13 server13 does13 not13 need13 arficially13 slow13 down13 the13 client13 by13 sending13 late13 ACKsndash No13 need13 to13 keep13 track13 of13 delayed13 ACKsndash The13 server13 can13 perform13 other13 tasks13 instead
bull Reduced13 network13 traffic
Thank13 youQuesons
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-links-json-02txt
123
RFC 6690 (link-format) documents are somewhat foreign to many web app developerssect would prefer to have them in JSON format
There is no standard way to represent link-format documents in applicationssect but everyone knows how to handle JSON
Define a standard JSON translation for link-format
Itrsquos
not
rock
et
scien
ce
ltsensorsgtct=40title=Sensor Index ltsensorstempgtrt=temperature-cif=sensor ltsensorslightgtrt=light-luxif=sensor lthttpwwwexamplecomsensorst123gt anchor=sensorstemprel=describedby lttgtanchor=sensorstemprel=alternate [hrefsensorsct40titleSensor Index hrefsensorstemprttemperature-cifsensor hrefsensorslightrtlight-luxifsensor hrefhttpwwwexamplecomsensorst123 anchorsensorstempreldescribedby hreftanchorsensorstemprelalternate]
124
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-ipsec-for-coap-00txt
IPsec definitions for CoAP Mostly placeholder at this time Who has implementation experience with this
125
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-cross-reverse-convention-00txt
This draft has two lines of payload(based on a WGLC comment by Cullen Jennings)
coap12344567foobara=3
httpwwwproxycomwellknowncore-translate1234_4567foobara=3
Is that a useful convention to have
126
Insert CI slides here
127
128
0
5
10
15
20
25
30
35
40
10 20 30 40 50 60 70
good
put (
pps)
pps
Goodput vs pps (Econotags)
goodput
[Khattak preliminary]
Congestion Control
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-cocoa-00txt
ldquoadvancedrdquo cc (The draft is just a first shot) Others may have better ideas
129
Insert post-WGLC discussion slides here
130
Stop Continue Start
131
An Agile Retrospective
http6lowappnet coreIETF86 2013-03-12-13
Stop
132
Endless new CoAP optionssect instead use RESTful as much as possible
Move general security lifecycle out Looking at theoretical problems
http6lowappnet coreIETF86 2013-03-12-13
Continue
Interops Running code Look at real-world examples and deployments Solve their actual problems
sect Unilateral enhancements eg higher performance congestion control
sect Transports (SMS hellip)sect Make Web linking and Directories more and more usefulsect RESTful Design Paradigms for real-world problems
133
http6lowappnet coreIETF86 2013-03-12-13
Start
Further push into the (browser) web world (HTML5 browser security)
Specific supporting worksect SenMLsect URI work (dev URN hellip)sect Security Processes (next slide)
Spin outsect (We donrsquot really get to decide where this is done)
134
http6lowappnet coreIETF86 2013-03-12-13
Security
Integrate Application Network Group Keyingsect Tunnel-free setup
Donrsquot redo what has been done alreadysect ZigBee IP is finesect But what about other scenarios
Simple REST interfaces for working with keying materials and authorizationsect Start with defining objectives
Object Security for Constrained Nodes135
Re-chartering CoREWhat do we want to do now that wersquore grown up
Zach ShelbyCoRE WG IETF-86 Orlando
What is the scope
bull So we have a protocol and Web Linking what next
bull Keep with what we know besthellip1 Enhancements around CoAP2 New transports for CoAP3 New representations for Web Links4 General application layer solutions
CoRE WG IETF-86 Orlando 2
Enhancements around CoAP
bull Advanced congestion control
CoRE WG IETF-86 Orlando 3
New Transports for CoAP
bull Infrastructure for CoAP over foondash httptoolsietforgiddraft-silverajan-core-
coap-alternative-transports-01txtbull CoAP over SMS
ndash httptoolsietforgiddraft-becker-core-coap-sms-gprs-03txt
ndash OMA Lightweightbull CoAP over TCP
ndash httptoolsietforgiddraft-li-core-coap-payload-length-option-01txt
CoRE WG IETF-86 Orlando 4
New support for Web Links
bull JSON Web Linksndash httptoolsietforgiddraft-bormann-core-links-
json-02txt
2332010 CoRE WG IETF-77 Anaheim 5
General application layer solutions
bull Resource Directoryndash httptoolsietforgiddraft-shelby-core-
resource-directory-05txtndash OMA Lightweight
2332010 CoRE WG IETF-77 Anaheim 6
Group 1 2nd WGLCcoap-13 coap-14
6
http6lowappnet coreIETF86 2013-03-12-13
draft-ietf-core-coap-14
7
Will be published a couple of hours from nowsect please do read and comment again during IETF last call
Changes from ndash13sect Clarify that payload sniffing is acceptable only if no Content-
Format was suppliedsect Clarify that safe-to-forward options in a 203 Valid response
update the cachesect Clarify URI examples (Appendix B)sect Numerous editorial improvements and clarifications
sect Made Accept option non-repeatable
Repeatable13 Accept13 Opon
bull Problem
bull Soluon13 A13 ldquoJust13 do13 not13 do13 itrdquo13 and13 keep13 it13 generalbull Soluon13 B13 Change13 to13 non-shy‐repeatable
+ Predictable13 behavior13 when13 going13 through13 different13 caches+ Makes13 Accept13 and13 proxies13 easier13 to13 understand+ We13 have13 out-shy‐of-shy‐band13 content13 negoaon13 (ct=ldquoltAgt13 ltBgtrdquo)+ Can13 be13 added13 later13 as13 extension13 if13 really13 needed
GET13 someresAccept13 A13 B13
GET13 someresAccept13 B13 A13
someres13 (A13 B)13 =gt13 ltAgt
someres13 (B13 A)13 =gt13 ltAgt
Proxy
Also13 causesmulple13 observe13 relaonships
Cacheblowup
someresltAgt
Origin13 Server
Group 1a WGLC processingobserve block
9
http6lowappnet coreIETF86 2013-03-12-13
draft-ietf-core-observe-08
10
Changes from ndash07 to ndash08sect Expanded text on transmitting notification while a previous
transmission is pending (242)sect Changed reordering detection to use a fixed time span of 128
seconds instead of EXCHANGE_LIFETIME (276)sect Removed the use of the freshness model to determine if the
client is still on the list of observers
http6lowappnet coreIETF86 2013-03-12-13
draft-ietf-core-block-10
11
Still awaits grand editorial rewritesect right after coap-14 is shipped
http6lowappnet coreIETF86 2013-03-12-13
Tickets
hellip are our way to make the steps forward are at
http toolsietforgwgcore Updates are sent to the mailing list
sect Please review When we close a ticket please review once more
12
Group 2 groupcomm
13
Akbar RahmanEsko Dijk
IETF 86 March 2013httpwwwietforgiddraft-ietf-core-groupcomm-05txt
Group Communication for CoAP
Summary of Changes (14)
n I-D had two updates (Rev 04 amp 05) after IETF-85 (Atlanta) Many of the updates were due to the detailed review by Peter van der Stokn Thank you Peter for your valuable comments
n Changes from ietf-03 to ietf-04 n Section 23 (Potential Solutions for Group Communications) moved to
draft-dijk-core-groupcomm-misc (266)n Added reference to draft-keoh-tls-multicast-security to section 6 (Security
Considerations) n Appendix B (CoAP-Observe Alternative to Group Communications) moved
to draft-dijk-core-groupcomm-misc (267) n Deleted section 8 (Conclusions) as it is redundant (268) n Simplified light switch use case (269) by splitting into basic operations and
additional functions (269)
Summary of Changes (24)
n Changes from ietf-03 to ietf-04 (Continued) n Moved section 37 (CoAP Multicast and HTTP Unicast Interworking) to
draft-dijk-core-groupcomm-misc (270) n Moved section 331 (DNS-SD) and 332 (CoRE Resource Directory) to
draft-dijk-core-groupcomm-miscClarified that DNS based features are optional (272)
n Focus section 35 (Configuring Group Membership) on a single proposed solution
n Scope of section 53 (Use of MLD) widened to multicast destination advertisement methods in general
n Rewrote section 22 (Scope) for improved readibility n Moved use cases that are not adressed to draft-dijk-core-groupcomm-miscn Various editorial updates for improved readibility
Summary of Changes (34)
n Changes from ietf-04 to ietf-05 n Added a new section 39 (Exceptions) that highlights that IP multicast (and
hence group communications) is not always available (187) n Included guidelines on when (not) to use CoAP responses to multicast
requests and when (not) to accept multicast requests (273) n Added guideline on use of core-block for minimizing response size (275)n Restructured section 6 (Security Considerations) to more fully describe
threats and threat mitigation (277) n Clearly indicated that DNS resolution and reverse DNS lookup are optional n Removed confusing text about a single group having multiple IP addresses
If multiple IP addresses are required then multiple groups (with the same members) should be created
n Removed repetitive text about the fact that group communications is not guaranteed
Summary of Changes (44)
n Changes from ietf-04 to ietf-05 (Continued) n Merged previous section 52 (Multicast Routing) into 31 (IP Multicast
Routing Background) and added link to section 52 (Advertising Membership of Multicast Groups)
n Clarified text in section 38 (Congestion Control) regarding precedence of use of IP multicast domains (ie first try to use link-local scope then site-local scope and only use global IP Communication for CoAP multicast as a last resort)
n Extended group resource manipulation guidelines with use of preconfigured portspaths for the multicast group
n Consolidated all text relating to ports in a new section 33 (Port Configuration)
n Clarified that all methods (GETPUTPOST) for configuring group membership in endpoints should be unicast (and not multicast) in section 37 (Configuring Group Membership In Endpoints)
n Various editorial updates for improved readability
Discussion item (11)
n Solution for Configuring Group Membership (no ticket)n Example of (unicast) configuring an endpoint to be part of one multicast
groupReq POST gp (Content-Format applicationjson)
n floor1westbldg6examplecom ip ff154200f7feed3714cb Res 204 Changed
n Where the ldquogprdquo resource has resource type (rt) ldquocoregprdquo which is defined for this purpose
n Question Do we want specify such a solution (or for example leave it completely up to implementation)
Open Issues(15)
n Review Groupcomm requirements language (271)n Decision made to keep requirements language for informational draftn Each use of MAYMUSTSHOULD etc is to be reviewed
Open Issues(25)
n Add section on multicast via Proxy and its limitations (274)n Add a section to explain the issues amp limitations of doing CoAP multicast
requests via a CoAP Proxy n Goal is to warn and guide implementers in this subject n Also such a section would provide a placeholderreminder of the problems
that might be addressed further in the futuren Based on IETF 85 CoRE WG meeting discussion on Multicast CoAP
requests via a Proxy Discussion summary for referencen Aggregation of responses in a proxy is difficult since it doesnt know
when to stop aggregating responses n SIP tried to deal with this problem but didnt solve it n There may be an expectancy of CoAP client to get single response
back from proxy not multiple The client in this case may not even know what it could expect It may not even know the Proxy-URI contains a multicast target
n Presented via-proxy use case exposes gap in the core-coap specification regarding multicast via proxy (Note Expectation is that core-coap wonrsquot address it in the first planned RFC release)
Open Issues(35)
n Issues with twomultiple Resource Directories in use case (280)n Some potential issues with RD came out of review Peter van der Stok and
WG discussion IETF85 n There are two RD servers use case shows that only one is found despite
the fact that site-local multicast is used - should be two RDs found n Proposal simplify use case to a single RD server on the backbone to avoid
such RD-specific issues like synchronization of RD information between servers
Open Issues(45)
n Add single-subnet configuration to use cases (278)n Suggested by review Peter van der Stok and IETF85 WG discussion that
its best to start explaining the simplebasic cases and then gradually build up complexity
n Simplest case not shown yet would be a single subnet network configuration which is currently not present in the I-D only the 2-subnet configuration of Fig 1
n Question Do we need to add such case or doesnt it add muchn (Note that core-coap Figure 22 already shows the simplest case of link-local
multicast)
Open Issues(55)
n Add use case with controller (client) located on the backbone (279)n Suggested by discussion following review Peter van der Stok n Case missing where a controller (client) is located on the backbonen Question Do we need to add such case or does it add much
Group 2a other old friends
25
Angelo Castellani Salvatore Loreto Akbar Rahman Thomas Fossati Esko Dijk
IETF 86 March 2013httpwwwietforgiddraft-castellani-core-http-mapping-07txt
Best Practices for HTTP-CoAP Mapping
Implementation
Summary of Changes (from -06 rev)
n Based on discussion at last IETF-85 (Atlanta)n Clarification of HTTP-CoAP Proxies
n Definitionn Placementn Benefits
n Clarification of HTTP-CoAP URI mapping options
Goals of I-D
n For Reverse HTTP-CoAP Cross Protocol Proxyn Provide more detailed information to proxy designers (beyond
Section 10 of [I-Dietf-core-coap]) to help implement proxies that correctly inter-work with other CoAP and HTTP clientserver implementations that adhere to the specifications
n Define a consistent set of guidelines that a HTTP-to-CoAP proxy implementation MAY adhere to The main reason of adhering to such guidelines is to reduce variation between proxy implementations thereby increasing interoperabilityn As an example use case a proxy conforming to these guidelines made
by vendor A can be easily replaced by a proxy from vendor B that also conforms to the guidelines
I-D Outline
n Guidance on HTTP to CoAP URI mappingn HTTP-CoAP Reverse cross-protocol proxy implementation
n Placementn Response code amp media type translationsn Caching and congestion controln Cache refresh via Observen Use of CoAP blockwise transfern Security translation
n Security Considerationsn Traffic overflown Handling secured exchanges
Definitions (12)
n Cross-Protocol Proxy (or Cross Proxy) is a proxy performing a cross- protocol mapping in the context of this document a HTTP-CoAP (HC) mapping A Cross-Protocol Proxy can behave as a Forward Proxy Reverse Proxy or Interception Proxy n Note In this document we focus on the Reverse Proxy mode of the
Cross-Protocol Proxy
n Forward Proxy a message forwarding agent that is selected by the client usually via local configuration rules to receive requests for some type(s) of absolute URI and to attempt to satisfy those requests via translation to the protocol indicated by the absolute URI The user decides (is willing to) use the proxy as the forwardingdereferencing agent for a predefined subset of the URI space
Definitions (22)
n Reverse Proxy a receiving agent that acts as a layer above some other server(s) and translates the received requests to the underlying servers protocol It behaves as an origin (HTTP) server on its connection towards the (HTTP) client and as a (CoAP) client on its connection towards the (CoAP) origin server The (HTTP) client uses the origin-form [I-Dietf-httpbis-p1-messaging] as a request- target URI
n Reverse and Forward proxies are technically very similar with main differences being that the former appears to a client as an origin server while the latter does not and that clients may be unaware they are communicating with a proxy
Reverse Cross-Protocol Proxy Deployment Scenario
HTTP-CoAP Response Code Mapping
Implementation Experience
n Direct experience from the draft authorsn Squid HTTP-CoAP mapping module
n University of Padovan httptelecomdeiunipditiotn Both Forward and Interception operation supported
n HTTP-CoAP proxy based on EvCoAPn KoanLogic University of Bologna and Salvatore
Loreto (as individual)n httpsgithubcomkoanlogicwebthingstreemasterbridgesw
libevcoapn The document is open to input from other implementations
Next Steps
n Does the WG recommend adoptionn Intended status Informational Best Practicen Purpose Reduce arbitrary variation between proxy
implementations thereby increasing interoperability
Backup
HTTP to CoAP URI Mapping Options (12)
n Embedded Mapping n In an embedded mapping approach the HTTP URI has embedded
inside it the authority and path part of the CoAP URI n Example The CoAP resource nodecoapsomethingnetfoo can
be accessed by an HTTP client by inserting in the request httphc-proxysomethingnetcoapnodecoapsomethingnetfoo The Cross-Protocol Proxy then maps the URI to coapnodecoapsomethingnetfoo
HTTP to CoAP URI Mapping Options (22)
n Homogeneous Mapping n In a homogeneous mapping approach only the scheme portion of the URI
needs to be mapped The rest of the URI (ie authority path etc) remains unchanged
n Example The CoAP resource coapnodecoapsomethingnetfoo can be accessed by an HTTP client by requesting httpnodecoapsomethingnetfoo The Cross-Protocol Proxy receiving the request is responsible to map the URI to coapnodecoapsomethingnetfoo
n Background info n The assumption in this case is that the HTTP client would be able to
successfully resolve nodecoapsomethingnet using DNS infrastructure to return the IP address of the HC proxy Most likely this would be through a two step DNS lookup where the first DNS lookup would resolve somethingnet using public DNS infrastructure
n Then the second DNS lookup on the subdomain coap and the host node would typically be resolved by a DNS server operated by the owner of domain somethingnet So this domain owner can manage its own internal node names and subdomain allocation which would correspond to the CoAP namespace
Group 3 ldquonew workrdquo
39
Transport of CoAP over SMS USSD and GPRSdraft-becker-core-coap-sms-gprs-03
Markus Becker Kepeng LiKoojana Kuladinithi Thomas Poumltsch
CoRE WG IETF-86 Orlando
1 10
ScenariosI In M2M communication IP connectivity is not alwayssupported by the constrained end-points
I Power savingI Coverage (GPRS 3G LTE)
I SMS and USSD based communication is almost alwayssupported
210
Changes from draft-01 to draft-03 (1)
I Added possible CONNONACK interactions Section 5
I Option name changed from Reply-To- to Response-To-Section 16 and Section 101
I Added URI schemeEg coap+tel+15105550101well-knowncore Section 11
I Added possible M2M proxy scenarios Section 14
3 10
Changes from draft-01 to draft-03 (2)
I Added reference to bormann-coap-misc for other SMSencoding Section 71
I Updated requirements on Uri-Host and Uri-Port forcoap+tel Section 10
I Added security considerations Transport and ObjectSecurity Section 15
I Chose CoAP option numbers and updated the optionnumber table to meet draft-ietf-core-coap-10 Table 1
I Added an IANA registration for the URI scheme coap+telSection 162
4 10
Feedback Split coap+tel into coap+smsand coap+ussd
I How else to differ the various transports in the URII Or is the transport to use decided by the implementationI See alsodraft-silverajan-core-coap-alternative-transports-01
5 10
Feedback Response-To-Scheme option
I Should there be a Response-To-Scheme optionadditionally to Response-To-Uri-Host andResponse-To-Uri-Path
I So that a CoAP end-point which receives a request by CoAPover non-IP transport can be instructed to also use thenon-IP transport for the response
I This would imply to add aResponse-To-Telephone-Subscriber and more options forother transports that have other URI schemes than coapand coaps
6 10
Feedback Selection of Transport by Client
I When a server is reachable by various transports howdoes a client decide which transport to use
I Client-side application congurationI Leave it to a proxy which uses cellular network lookupfunctions
7 10
Feedback Potential Threats
I Trigger expensive short messagesI Redirect trac to other addressesI More threats
I Are the security measures in the draft adequateI Whitelisting on serverI Relying on cellular network security (dedicated M2M APNs)I Object security on CoAP payload
8 10
Feedback Message Exchanges
I Figures 11-18 show possible message exchanges whenclient and server have two addresses
I With NON Not using CoAP retransmission capabilityI ACK on different transportI Additional (costly) message on Transport AI Request with Content
I Which ones are allowedI Which ones are meaningful
9 10
Next steps
I Rene Uri schemeI Response-To-Scheme optionI Selection of Message ExchangeI Rene Proxying
10 10
CoAP13 Communicaon13 with13 Alternave13 Transports
Bill Silverajan and Teemu SavolainenCore WG IETF 86 Orlando
031113
Objecves13 (In13 Scope)
bull Unambiguous13 representaon13 of13 transport13 to13 be13 used13 by13 CoAP
bull Details13 how13 the13 transport13 can13 carry13 CoAP13 packet
bull Focus13 is13 on13 what13 CoAP13 communicaons13 requirements13 are
bull Allow13 CoAP13 mechanisms13 to13 exploit13 cross-shy‐layer13 opmisaons
51
031113
Non13 Goals13 (Not13 in13 scope)
bull Applicaon-shy‐level13 QoS13 requirementsbull Real-shy‐me13 constraintsbull Ordering13 reliability13 congeson13 controlbull Applicaon13 and13 network13 adaptaonbull Mobility13 and13 readdressing13 supportbull Network13 protocol13 (eg13 IPsec)13 configuraon
52
031113
Use13 Cases
bull NAT13 and13 Firewall13 traversal13 with13 TCPbull Delay13 Tolerant13 Networkingbull Non-shy‐IP13 Low13 Energy13 Protocols
53
031113
Related13 Work
bull OMA13 Lightweight13 M2M13 Protocolbull CoAP13 over13 SMSGPRSUSSD
54
031113
What13 does13 the13 work13 entail
bull The13 ability13 to13 specify13 end13 point13 idenfiers13 and13 URIs13 to13 reflect13 which13 transport13 CoAP13 can13 use
bull The13 ability13 to13 register13 to13 resource13 directories13 resource13 types13 reflecng13 types13 of13 transport13 available
bull Ability13 for13 mul-shy‐transport13 nodes13 to13 select13 transport13 to13 use13 without13 significant13 alteraon13 to13 CoAP13 packet13 structure
55
031113
Points13 to13 consider
bull Requirements13 for13 transport13 layer13 protocol13 to13 carry13 CoAP13 packets
bull Representaon13 of13 URI13 scheme13 for13 generic13 transport13 protocols
bull Opon13 extensions13 for13 CoAP13 to13 express13 available13 transports
bull Mapping13 and13 message13 sizebull Security13 consideraons
56
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
URI13 =13 scheme13 13 13 authority13 path-shy‐abempty13 [13 query13 ]
bull Within13 the13 scheme13 namebull In13 the13 URI13 pathbull As13 a13 query13 component
57
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
bull Within13 the13 scheme13 namendash coap+tel+15105550101well-shy‐knowncorendash coap+tcpexamplecom5683temperaturendash coap+blel2cap[1234567890AB]4pulse
bull Easy13 URI13 parsing13 for13 transport13 type13 and13 idenfier
bull Each13 new13 scheme13 name13 requires13 IANA13 registraon
58
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
bull In13 the13 URI13 pathndash coaphostexamplecomtransport=tcpwell-shy‐knowncorert=core-shy‐rd
bull Easy13 adopon13 of13 new13 (and13 experimental)13 CoAP13 transports13 without13 IANA13 registraon
bull Caveat13 Uri-shy‐Path13 opon13 is13 a13 Crical13 CoAP13 opon13 see13 secon13 54113 of13 I-shy‐Diep-shy‐core-shy‐coap
59
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
bull As13 a13 URI13 query13 componentndash coaphostexamplecomwell-shy‐knowncorert=core-shy‐rdq=tcp
bull Also13 easy13 to13 adopt13 new13 (and13 experimental)13 CoAP13 transports13 without13 IANA13 registraon
bull Caveat13 Uri-shy‐Query13 opon13 is13 a13 Crical13 CoAP13 opon13 see13 secon13 54113 of13 I-shy‐Diep-shy‐core-shy‐coap
60
031113
URI13 Representaons13 for13 CoAPNon13 standard13 ways
bull Transport13 in13 the13 URI13 authority13 componentndash coaphost[port][transport]13 instead13 of13 coaphost[port]
bull Transport13 as13 a13 service13 URLndash servicecoaptcphostexamplecomwell-shy‐knowncorert=core-shy‐rd
bull Above13 two13 ways13 break13 exisng13 compability13 (although13 both13 are13 based13 on13 valid13 IANA13 URI13 registraons)
61
031113
URI13 Representaons13 for13 CoAPMiscellaneous13 Consideraons
bull Ensure13 that13 transport13 is13 defined13 unambiguously13 (eg13 L2CAP13 used13 by13 both13 BLE13 and13 standard13 Bluetooth13 so13 avoid13 rdquocoap+l2caprdquo13 or13 rdquotransport=l2caprdquo13 or13 rdquoq=l2caprdquondash Can13 be13 done13 as13 WG13 consensusndash Namespace13 approach13 eg13 rdquocoap+blel2caprdquo13 or13 rdquoq=blel2caprdquo
bull Allow13 end-shy‐points13 to13 use13 CoAP13 Resource13 Directory13 to13 register13 alternave13 transports13 and13 idenfiers13 and13 provide13 periodic13 updatesndash Register13 rdquocore-shy‐transportrdquo13 resource13 type
62
031113
Transport13 Consideraons
bull Uniqueness13 of13 end-shy‐point13 idenficaonbull Communicaon13 support13 Unidireconal13 Bidireconal13 1N13 (broadcast13 mulcast13 anycast)13 messaging
bull Binary13 encoding13 Network13 byte13 orderingbull MTU13 correlaon13 with13 CoAP13 PDU13 sizebull Transport13 latency
63
031113
Security13 Consideraons
bull Drar13 does13 not13 introduce13 new13 security13 requirements13 by13 itself
bull There13 may13 be13 privacy13 issues13 if13 nodes13 use13 telephone13 numbers13 or13 MAC13 addresses13 as13 public13 end13 point13 idenfiers
64
Akbar Rahman
IETF 86 March 2013 httpwwwietforgiddraft-rahman-core-sleepy-02txt
Enhanced Sleepy Node Support for CoAP
Introduction
It is expected that in CoAP networks there will be a certain portion of devices that are sleepy and which may occasionally go into a sleep mode (ie go into a low power state to conserve power) and subsequently have reduced CoAP protocol communication ability
This I-D proposes a minimal and efficient mechanism building on the Resource Directory concept (which will be integrated into a CoAP Proxy) to enhance sleepy node support in CoAP networks
Main Question from IETF-85 (Atlanta)
What performance benefit does the proposed Sleepy Node support solution give in a network that already has standard CoAP caching enabled
Sleepy Node Performance Analysis
Experimental Network
1-5 clients
Both Sleepy and Non-
Sleepy servers
Sleepy Node Performance Analysis Network Setup
CoAPSleepyServer(s)
CoAPSleepAwareReverseProxy
CoAP
Client(s)
Request
Response
Sleep9AwareCoREResourceDirectoryCapability
PublishedSleepParameters
Sleep9AwareCoAPStoreandForwardCapability Response
Request
SleepAwareCoAP503ResponseCapability
CoAPCachingCapability
bull Server supports publishing sleep parameters to proxy bull Eg Irsquom going to be asleep for X seconds
bull Proxy supports sleep-awareness capabilities bull Proxy also supports caching capability based off of maxAge bull Protocol flow similar to approach of Figure 1 (Synchronous RD Based Sleep
Tracking) of I-D
Proxy capabilities can be selectively enableddisabled
Proxy ndash Server Interface
Client ndash Proxy Interface
CoAP Sleep-Aware Reverse Proxy Features CoRE Sleep-aware Resource Directory
Support storing published sleep parameters from CoAP servers sleepState (AWAKE ASLEEP) sleepDuration
Sleep-aware CoAP 503 Response Capability If CoAP request to a sleeping server is received proxy returns a
lsquo503 Retry-Afterrsquo response to client 503 contains a timestamp indicating when the sever will wake back up
(timestamp delivered in CoAP maxAge option) Sleep-aware CoAP Store-and-Forward Capability
If CoAP request to a sleeping server is received proxy stores request until server wakes up and then forwards it
Caching capability Cache GET responses from server if maxAge option is present
(this is not a sleep aware feature)
Goals of Performance Analysis
For networks having sleepy servers provide measurements to quantify the impact that CoAP sleep-awareness capabilities can have
See if sleep-awareness capabilities can
provide additional benefits even when CoAP caching is used
Overview of Performance Analysis Performed The analysis was broken up into a set of test scenarios Each test scenario used a different combination of the following
variables Client issued GET requests Server was configured as a sleepy or non-sleepy server Proxy caching of GET responses was enabled or disabled Proxy sleep-aware 503 response capability was enabled or disabled Proxy store-and-forward capability was enabled or disabled maxAge in GET responses ndash Two values were tested 60sec and 5sec of Clients ndash Two values were used ndash 1 client and 5 clients
For comparison purposes the following were held constant across all test scenarios Client issued a fixed number of requests (100) across all test scenarios Client used a delay between each GET request (35sec) to better exercise
proxyrsquos caching and sleep-awareness capabilities For sleepy server test scenarios the server slept 60 sec awake for 3 sec
Format of Results The following results were collected for each
test scenario
Breakdown of the and types of transactions occurring between clientproxyserver
ldquoGETrdquo ndash Test Scenario Results
GET ndash Description of Test Scenarios
TestScenarios-GET
Scenario
CoAPSleepyServerSe7ngs CoAPSleepAwareReverseProxySe7ngs CoAPClientSe7ngs
SleepDuragton(sec)
AwakeDuragton(sec)
maxAge(sec) Caching SleepAwareSAF+
503NumberofClients
NumberofGETs
DelayBetweenClient
Requests(sec)
1a 0 Always 60 Enabled Disabled 1 100 35
1b 60 3 60 Enabled Disabled 1 100 35
1c 60 3 60 Enabled Enabled 1 100 35
2a 0 Always 60 Enabled Disabled 5 100 35
2b 60 3 60 Enabled Disabled 5 100 35
2c 60 3 60 Enabled Enabled 5 100 35
3a 0 Always 5 Enabled Disabled 5 100 35
3b 60 3 5 Enabled Disabled 5 100 35
3c 60 3 5 Enabled Enabled 5 100 35
ldquoGETrdquo ndash Test Scenario 1 Results
maxAge = 60 and 1 Client
GET ndash Scenario 1 ClientProxy Interface Transaction Mix
Scenarios 1a - Non-Sleepy Server Caching Proxy maxAge = 60sec 1b- Sleepy Server Caching Proxy maxAge = 60sec 1c - Sleepy Server Sleep Aware Proxy maxAge = 60sec
Sleep Aware Proxy has better performance for sleepy servers
0
100
200
300
400
500
600
700
1a 1b 1c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
GET ndash Scenario 1 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
Scenarios 1a - Non-Sleepy Server Caching Proxy maxAge = 60sec 1b- Sleepy Server Caching Proxy maxAge = 60sec 1c - Sleepy Server Sleep Aware Proxy maxAge = 60sec
0
100
200
300
400
500
600
700
800
1a 1b 1c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
ldquoGETrdquo ndash Test Scenario 2 Results
maxAge = 60 and 5 Clients
GET ndash Scenario 2 ClientProxy Interface Transaction Mix
Sleep Aware Proxy has slightly better performance for sleepy servers
0
200
400
600
800
1000
1200
1400
2a 2b 2c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
Scenarios 2a - Non-Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2b- Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2c - Sleepy Server Sleep Aware Proxy maxAge = 60sec 5 Clients
See ldquoExperimental Artifactsrdquo Note 1
GET ndash Scenario 2 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has slightly better performance for sleepy servers
0
50
100
150
200
250
300
350
400
2a 2b 2c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
Scenarios 2a - Non-Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2b- Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2c - Sleepy Server Sleep Aware Proxy maxAge = 60sec 5 Clients
See ldquoExperimental Artifactsrdquo Note 2
Experimental Artifacts Note 1
Currently in the experiment the sleep aware proxy checks the cached state of a resource before putting a request into its Store-and-forward queue while a server is sleeping Once in the queue the proxy unconditionally forwards the queued requests to the server once it wakes up This is not the most efficient setup and can easily be improved If the proxy instead checks its cache again before forwarding each queued request it may not need to forward the request to the server For example if there are two queued GET requests in the proxyrsquos queue that address the same resource Only the first request needs to be sent to the server the second request can use the cached response from the first request
Note 2 Currently in the experiment the sleepy server sends a sleepState PUT request to the
proxy each time it goes to sleep This is not the most efficient setup and can easily be improved For example if the server assumes that the proxy can keep track of its ONOFF cycles with its internal timers (eg as per Fig 1 of I-D) then the number of messages from the sleepy server dramatically goes down
ldquoGETrdquo ndash Test Scenario 3 Results
maxAge = 5 and 5 Clients
GET ndash Scenario 3 ClientProxy Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
Scenarios 3a - Non-Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3b- Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3c - Sleepy Server Sleep Aware Proxy maxAge = 5sec 5 Clients
0
500
1000
1500
2000
2500
3000
3500
4000
4500
5000
3a 3b 3c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
GET ndash Scenario 3 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
0
1000
2000
3000
4000
5000
6000
7000
3a 3b 3c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
Scenarios 3a - Non-Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3b- Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3c - Sleepy Server Sleep Aware Proxy maxAge = 5sec 5 Clients
Conclusions
Conclusions These results show that sleep-aware CoAP
proxy features can significantly optimize communication with sleepy servers in most scenarios
These results also show that sleep-
awareness capabilities can provide additional benefits above and beyond CoAP caching in most scenarios
Backup
Current CoAP Support of Sleepy Node (12)
CoAP proxies can use a previously cached response to service a new GET request for a sleepy origin server (as in HTTP) But if no valid cache then proxy has to attempt to
retrieve and may fail if origin server is sleeping [I-Dietf-core-coap]
Clients can discover list of resources from RD (GET rd-lookuphellip) for sleepy servers But attempt to GET resource from sleepy origin server
may fail if origin server is sleeping [IDietf-core-link-format amp IDshelby-core-resource-
directory]
Current CoAP Support of Sleepy Node (22)
Lower layer support for sleepy nodes in most wireless technologies (eg WiFi ZigBee) But limited to MAC packet scheduling for sleepy nodes
and not aware of specific needs of IP applications (like CoAP)
Proposal ndash RD Based Sleep Tracking (14)
The current CoAP approach to support sleepy nodes can be significantly improved by introducing RD based mechanisms for a CoAP client to determine whether A targeted resource is located on a sleepy server A sleepy server is currently in sleep mode or not
There is any associated caching Proxy (possibly the RD itself) for a sleepy server
Proposal ndash RD Based Sleep Tracking (24)
We define the following new RD attributes to characterize the properties of a sleepy node SleepState - Indicates whether the node is currently in
sleep mode or not (ie Sleeping or Awake) SleepDuration - Indicates the maximum duration of time
that the node stays in sleep mode TimeSleeping - Indicates the length of time the node
has been sleeping (ie if Sleep State = Sleeping) NextSleep - Indicates the next time the node will go to
sleep (ie if Sleep State = Awake)
CachingProxy ndash Indicates the caching proxy of the sleepy node (ie the RD itself or another node)
Proposal ndash RD Based Sleep Tracking (34)
These attributes are all server (node) level and are new parameters added to the RD URI Template Variables
Finally we also define a new lookup-type (ss) for the RD lookup interface specified in [I-Dshelby-core-resource-directory] This new lookup-type supports looking up the
ldquoSleepStaterdquo (ss) of a specified end-point
Proposal ndash RD Based Sleep Tracking (44)
The three time based parameters (SleepDuration TimeSleeping NextSleep) can be based on either an absolute network time (for a time synchronized network) or a relative local time (measured at the local node)
Following the approach of [I-Dietf-core-link-format] and [I-Dshelby-core-resource-directory] sleep parameters for sleepy servers can be stored by the server in the RD and accessed by all interested clients
Examples of using these parameters in a synchronous or asynchronous manner are shown in the I-D
http6lowappnet coreIETF86 2013-03-12-13
We assume people have read the drafts
Meetings serve to advance difficult issues by making good use of face-to-face communications
Note Well Be aware of the IPR principles according to RFC 3979 and its updates
uumlBlue sheetsuumlScribe(s)
96
drar-shy‐iep-shy‐core-shy‐coapsubmiqed13 to13 IESG
2013-shy‐03-shy‐13
97
OMA Lightweight M2M Overview(A new standard using lots of IETF specs including DTLS
CoAP Block Observe Resource Directory SenMLhellip)
Zach ShelbyCoRE WG IETF-86 Orlando
OMA Lightweight M2Mbull Open Mobile Alliance is well known for Device Management (DM)bull OMA Lightweight M2M is a new standard from the alliance
ndash Focused on constrained Cellular and sensor network M2M devicesndash Driven by leading operators and vendors
bull Scopendash Interfaces protocol amp security between Device and Serverndash Object and Resource modelndash Bootstrap Device Access Control Connectivity and Firmware Objects
bull Draft Specifications are availablendash httpmemberopenmobileallianceorgftpPublic_documentsDM
LightweightM2MPermanent_documentsOMA-TS-LightweightM2M-V1_0_0-20130301-Dzip
bull Timelinendash Requirements and Architecture completed 3Q2012ndash Spec ready for Consistency Review 2Q2013ndash Candidate Approval expected 3Q2013
2 CoRE WG IETF-86 Orlando
Architecture
3
Scope of LWM2M
CoRE WG IETF-86 Orlando
Object Model
bull A Client has one or more Object Instancesbull An Object is a collection of Resourcesbull A Resource is an atomic piece of information
ndash Read Written or Executed
bull Resources can have multiple instancesbull Objects and Resources are identified by a
16-bit Integer Instances by an 8-bit Integerbull ObjectsResources are accessed with
simple URIs Object IDObject InstanceResource ID
eg 1213
4 CoRE WG IETF-86 Orlando
CoRE WG IETF-86 Orlando
CoRE Resource Directory
draft-shelby-core-resource-directory-05
Z Shelby C Bormann S Krco
Backgroundbull Not a new concept
ndash think web search engine or any link directorybull Defines the interfaces to a Resource Directorybull Based on Web Linking framework and the CoRE Link Formatbull Generic REST design for use over HTTP and CoAPbull Used by OMA Lightweight M2Mbull Has already been deployed
ndash In traffic monitoring systemsndash In street lighting systemsndash For vehicular asset trackingndash By a major Cellular M2M operator
Changes since -04
bull Restricted Update to parameter updatesbull Added pagination support for the Lookup interfacebull Changed rt= to et= for the registration amp update
interfacebull Added group support
Group Management
bull RD now includes group management featuresbull New Group Function Set
ndash Register a groupbull Group name domain multicast address endpoint members
ndash Remove a groupbull Group lookup using the Lookup Function Set
ndash List registered groupsndash Find the members of a groupndash Find groups with certain endpoints or resources
Registering a Group
EP RD
| |
| - POST rd-groupgp=lights ltgtep=node1 --gt |
| |
| |
| lt---- 201 Created Location rd-group12 ---- |
| |
Req POST coaprdexamplecomrd-groupgp=lights
Payload
ltgtep=node1
ltgtep=node2
Res 201 Created
Location rd-group12
Looking up Group Members
Client RD
| |
| ----- GET rd-lookupepgp=lights1 ----------------------gt |
| |
| |
| lt-- 205 Content ltrdgtd=domain1ltrdgtd=domain2 --------- |
| |
Req GET rd-lookupepgp=lights1
Res 205 Content
ltcoaphostportgtep=node1
ltcoaphostportgtep=node2rdquo
Things for the futurebull Support for JSON representation of Web Links
ndash httptoolsietforgiddraft-bormann-core-links-json-02txtbull Registry for RD registration query parameters
ndash Already OMA Lightweight has defined some new onesbull More examples
Group 3 ldquonew workrdquo(continued)
109
drar-shy‐greevenbosch-shy‐core-shy‐profile-shy‐descripon-shy‐01Bert13 GreevenboschJeroen13 Hoebeke
Isam13 IshaqFloris13 Van13 den13 Abeele
Descripon
bull JSON13 format13 for13 signalling13 the13 servers13 capabilies
bull Signalling13 of13 supported13 opons13 media13 types13 and13 block13 sizendash Other13 items13 can13 be13 added
bull Filtering13 on13 specific13 fields13 through13 URI-shy‐Querybull Link13 hqpdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐profile-shy‐descripon
well-shy‐knownprofile
bull To13 acquire13 profile13 data13 of13 resources13 on13 a13 parcular13 service13 the13 well-shy‐knownprofile13 URI-shy‐path13 is13 introduced
bull For13 example13 to13 get13 all13 informaon13 from13 sensors13 served13 by13 wwwexampleorg13 we13 can13 do13 a13 GET13 to13 coapwwwexampleorgwell-shy‐knownprofile
bull Filtering13 on13 parcular13 resources13 is13 done13 through13 URI-shy‐Queries
Format
bull Currently13 the13 following13 fields13 are13 definedndash ldquopathrdquo13 contains13 the13 URI-shy‐path13 associated13 with13 a13 resource
ndash ldquooprdquo13 a13 numerical13 list13 of13 supported13 opon13 numbers
ndash ldquocfrdquo13 a13 numerical13 list13 of13 supported13 content-shy‐format13 numbers
ndash ldquob1srdquo13 ldquob2srdquo13 supported13 block13 sizes13 for13 Block113 and13 Block213 respecvely
Examplebull On13 the13 right13 is13 an13 example13 of13 a13 camera13 sensor13 at13 coapwwwexampleorgcam13 that13 supports13 the13 Uri-shy‐Host13 (3)13 ETag13 (4)13 Uri-shy‐Port13 (7)13 Uri-shy‐Path13 (11)13 Content-shy‐Format13 (12)13 Token13 (19)13 Block213 (23)13 and13 Proxy-shy‐Uri13 (35)13 opons
bull The13 supported13 content13 formats13 are13 textplain13 (0)13 applicaon13 link-shy‐format13 (40)13 and13 applicaonjson13 (50)
bull The13 supported13 Block213 can13 use13 25613 or13 51213 byte13 blocks
Req13 GET13 coapwwwexampleorgwell-shy‐knownprofile13 Res13 20513 Content13 (applicationjson)13 13 13 13 profile13 13 13 13 13 13 13 13 pathcam13 13 13 13 op[3471112192335]13 13 13 13 13 cf[04050]13 13 13 13 13 b2s[45]13 13 13 13
Filtering13 through13 use13 of13 URI-shy‐Query
bull Filtering13 can13 be13 done13 through13 the13 URI-shy‐Querybull Query13 format13 N=V
ndash N13 is13 a13 profile13 fieldndash V13 is13 the13 desired13 value
bull Examplesndash To13 find13 resources13 that13 support13 content13 format13 ldquoapplicaonjsonrdquo
13 GET13 wwwexampleorgwell-shy‐knownprofilecf=50ndash To13 get13 informaon13 about13 the13 camera
13 GET13 wwwexampleorgwell-shy‐knownprofilepath=cam
Open13 issues
bull Which13 other13 profile13 data13 needs13 signallingndash Content-shy‐type13 for13 different13 methods
bull Fix13 the13 order13 in13 which13 the13 profile13 fields13 must13 appearndash Non-shy‐fixed13 order13 easier13 extensible
bull Inheritance13 of13 a13 profile13 descriponbull Extend13 usage13 to13 signal13 the13 client13 profilebull Integraon13 with13 link13 format
Thank13 youQuesons
drar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval-shy‐00
Bert13 Greevenbosch
Descripon
bull The13 ldquoMinimumRequestInterval13 opon13 can13 be13 used13 to13 indicate13 the13 minimum13 me13 between13 two13 requests13 in13 a13 transacon
bull Originally13 intended13 for13 Block13 but13 also13 usable13 for13 other13 transaconsndash Example13 browsing13 a13 server
bull The13 goal13 is13 to13 reduce13 the13 server13 load13 and13 network13 traffic
bull Link13 hqpsdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval
Usage
bull The13 client13 keeps13 the13 server13 informed13 about13 its13 request13 speed13 through13 inclusion13 of13 the13 ldquoMinimumRequestIntervalrdquo13 opon
bull In13 responses13 the13 server13 fixes13 the13 minimum13 request13 interval13 through13 the13 same13 opon
bull The13 client13 obeys13 the13 speed13 indicated13 by13 the13 server
bull The13 client13 can13 send13 slower13 but13 not13 faster
Advantages
bull The13 server13 has13 means13 to13 limit13 the13 amount13 of13 incoming13 traffic
bull The13 server13 can13 prevent13 to13 become13 overloaded13 with13 too13 many13 tasks
bull The13 server13 does13 not13 need13 arficially13 slow13 down13 the13 client13 by13 sending13 late13 ACKsndash No13 need13 to13 keep13 track13 of13 delayed13 ACKsndash The13 server13 can13 perform13 other13 tasks13 instead
bull Reduced13 network13 traffic
Thank13 youQuesons
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-links-json-02txt
123
RFC 6690 (link-format) documents are somewhat foreign to many web app developerssect would prefer to have them in JSON format
There is no standard way to represent link-format documents in applicationssect but everyone knows how to handle JSON
Define a standard JSON translation for link-format
Itrsquos
not
rock
et
scien
ce
ltsensorsgtct=40title=Sensor Index ltsensorstempgtrt=temperature-cif=sensor ltsensorslightgtrt=light-luxif=sensor lthttpwwwexamplecomsensorst123gt anchor=sensorstemprel=describedby lttgtanchor=sensorstemprel=alternate [hrefsensorsct40titleSensor Index hrefsensorstemprttemperature-cifsensor hrefsensorslightrtlight-luxifsensor hrefhttpwwwexamplecomsensorst123 anchorsensorstempreldescribedby hreftanchorsensorstemprelalternate]
124
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-ipsec-for-coap-00txt
IPsec definitions for CoAP Mostly placeholder at this time Who has implementation experience with this
125
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-cross-reverse-convention-00txt
This draft has two lines of payload(based on a WGLC comment by Cullen Jennings)
coap12344567foobara=3
httpwwwproxycomwellknowncore-translate1234_4567foobara=3
Is that a useful convention to have
126
Insert CI slides here
127
128
0
5
10
15
20
25
30
35
40
10 20 30 40 50 60 70
good
put (
pps)
pps
Goodput vs pps (Econotags)
goodput
[Khattak preliminary]
Congestion Control
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-cocoa-00txt
ldquoadvancedrdquo cc (The draft is just a first shot) Others may have better ideas
129
Insert post-WGLC discussion slides here
130
Stop Continue Start
131
An Agile Retrospective
http6lowappnet coreIETF86 2013-03-12-13
Stop
132
Endless new CoAP optionssect instead use RESTful as much as possible
Move general security lifecycle out Looking at theoretical problems
http6lowappnet coreIETF86 2013-03-12-13
Continue
Interops Running code Look at real-world examples and deployments Solve their actual problems
sect Unilateral enhancements eg higher performance congestion control
sect Transports (SMS hellip)sect Make Web linking and Directories more and more usefulsect RESTful Design Paradigms for real-world problems
133
http6lowappnet coreIETF86 2013-03-12-13
Start
Further push into the (browser) web world (HTML5 browser security)
Specific supporting worksect SenMLsect URI work (dev URN hellip)sect Security Processes (next slide)
Spin outsect (We donrsquot really get to decide where this is done)
134
http6lowappnet coreIETF86 2013-03-12-13
Security
Integrate Application Network Group Keyingsect Tunnel-free setup
Donrsquot redo what has been done alreadysect ZigBee IP is finesect But what about other scenarios
Simple REST interfaces for working with keying materials and authorizationsect Start with defining objectives
Object Security for Constrained Nodes135
Re-chartering CoREWhat do we want to do now that wersquore grown up
Zach ShelbyCoRE WG IETF-86 Orlando
What is the scope
bull So we have a protocol and Web Linking what next
bull Keep with what we know besthellip1 Enhancements around CoAP2 New transports for CoAP3 New representations for Web Links4 General application layer solutions
CoRE WG IETF-86 Orlando 2
Enhancements around CoAP
bull Advanced congestion control
CoRE WG IETF-86 Orlando 3
New Transports for CoAP
bull Infrastructure for CoAP over foondash httptoolsietforgiddraft-silverajan-core-
coap-alternative-transports-01txtbull CoAP over SMS
ndash httptoolsietforgiddraft-becker-core-coap-sms-gprs-03txt
ndash OMA Lightweightbull CoAP over TCP
ndash httptoolsietforgiddraft-li-core-coap-payload-length-option-01txt
CoRE WG IETF-86 Orlando 4
New support for Web Links
bull JSON Web Linksndash httptoolsietforgiddraft-bormann-core-links-
json-02txt
2332010 CoRE WG IETF-77 Anaheim 5
General application layer solutions
bull Resource Directoryndash httptoolsietforgiddraft-shelby-core-
resource-directory-05txtndash OMA Lightweight
2332010 CoRE WG IETF-77 Anaheim 6
http6lowappnet coreIETF86 2013-03-12-13
draft-ietf-core-coap-14
7
Will be published a couple of hours from nowsect please do read and comment again during IETF last call
Changes from ndash13sect Clarify that payload sniffing is acceptable only if no Content-
Format was suppliedsect Clarify that safe-to-forward options in a 203 Valid response
update the cachesect Clarify URI examples (Appendix B)sect Numerous editorial improvements and clarifications
sect Made Accept option non-repeatable
Repeatable13 Accept13 Opon
bull Problem
bull Soluon13 A13 ldquoJust13 do13 not13 do13 itrdquo13 and13 keep13 it13 generalbull Soluon13 B13 Change13 to13 non-shy‐repeatable
+ Predictable13 behavior13 when13 going13 through13 different13 caches+ Makes13 Accept13 and13 proxies13 easier13 to13 understand+ We13 have13 out-shy‐of-shy‐band13 content13 negoaon13 (ct=ldquoltAgt13 ltBgtrdquo)+ Can13 be13 added13 later13 as13 extension13 if13 really13 needed
GET13 someresAccept13 A13 B13
GET13 someresAccept13 B13 A13
someres13 (A13 B)13 =gt13 ltAgt
someres13 (B13 A)13 =gt13 ltAgt
Proxy
Also13 causesmulple13 observe13 relaonships
Cacheblowup
someresltAgt
Origin13 Server
Group 1a WGLC processingobserve block
9
http6lowappnet coreIETF86 2013-03-12-13
draft-ietf-core-observe-08
10
Changes from ndash07 to ndash08sect Expanded text on transmitting notification while a previous
transmission is pending (242)sect Changed reordering detection to use a fixed time span of 128
seconds instead of EXCHANGE_LIFETIME (276)sect Removed the use of the freshness model to determine if the
client is still on the list of observers
http6lowappnet coreIETF86 2013-03-12-13
draft-ietf-core-block-10
11
Still awaits grand editorial rewritesect right after coap-14 is shipped
http6lowappnet coreIETF86 2013-03-12-13
Tickets
hellip are our way to make the steps forward are at
http toolsietforgwgcore Updates are sent to the mailing list
sect Please review When we close a ticket please review once more
12
Group 2 groupcomm
13
Akbar RahmanEsko Dijk
IETF 86 March 2013httpwwwietforgiddraft-ietf-core-groupcomm-05txt
Group Communication for CoAP
Summary of Changes (14)
n I-D had two updates (Rev 04 amp 05) after IETF-85 (Atlanta) Many of the updates were due to the detailed review by Peter van der Stokn Thank you Peter for your valuable comments
n Changes from ietf-03 to ietf-04 n Section 23 (Potential Solutions for Group Communications) moved to
draft-dijk-core-groupcomm-misc (266)n Added reference to draft-keoh-tls-multicast-security to section 6 (Security
Considerations) n Appendix B (CoAP-Observe Alternative to Group Communications) moved
to draft-dijk-core-groupcomm-misc (267) n Deleted section 8 (Conclusions) as it is redundant (268) n Simplified light switch use case (269) by splitting into basic operations and
additional functions (269)
Summary of Changes (24)
n Changes from ietf-03 to ietf-04 (Continued) n Moved section 37 (CoAP Multicast and HTTP Unicast Interworking) to
draft-dijk-core-groupcomm-misc (270) n Moved section 331 (DNS-SD) and 332 (CoRE Resource Directory) to
draft-dijk-core-groupcomm-miscClarified that DNS based features are optional (272)
n Focus section 35 (Configuring Group Membership) on a single proposed solution
n Scope of section 53 (Use of MLD) widened to multicast destination advertisement methods in general
n Rewrote section 22 (Scope) for improved readibility n Moved use cases that are not adressed to draft-dijk-core-groupcomm-miscn Various editorial updates for improved readibility
Summary of Changes (34)
n Changes from ietf-04 to ietf-05 n Added a new section 39 (Exceptions) that highlights that IP multicast (and
hence group communications) is not always available (187) n Included guidelines on when (not) to use CoAP responses to multicast
requests and when (not) to accept multicast requests (273) n Added guideline on use of core-block for minimizing response size (275)n Restructured section 6 (Security Considerations) to more fully describe
threats and threat mitigation (277) n Clearly indicated that DNS resolution and reverse DNS lookup are optional n Removed confusing text about a single group having multiple IP addresses
If multiple IP addresses are required then multiple groups (with the same members) should be created
n Removed repetitive text about the fact that group communications is not guaranteed
Summary of Changes (44)
n Changes from ietf-04 to ietf-05 (Continued) n Merged previous section 52 (Multicast Routing) into 31 (IP Multicast
Routing Background) and added link to section 52 (Advertising Membership of Multicast Groups)
n Clarified text in section 38 (Congestion Control) regarding precedence of use of IP multicast domains (ie first try to use link-local scope then site-local scope and only use global IP Communication for CoAP multicast as a last resort)
n Extended group resource manipulation guidelines with use of preconfigured portspaths for the multicast group
n Consolidated all text relating to ports in a new section 33 (Port Configuration)
n Clarified that all methods (GETPUTPOST) for configuring group membership in endpoints should be unicast (and not multicast) in section 37 (Configuring Group Membership In Endpoints)
n Various editorial updates for improved readability
Discussion item (11)
n Solution for Configuring Group Membership (no ticket)n Example of (unicast) configuring an endpoint to be part of one multicast
groupReq POST gp (Content-Format applicationjson)
n floor1westbldg6examplecom ip ff154200f7feed3714cb Res 204 Changed
n Where the ldquogprdquo resource has resource type (rt) ldquocoregprdquo which is defined for this purpose
n Question Do we want specify such a solution (or for example leave it completely up to implementation)
Open Issues(15)
n Review Groupcomm requirements language (271)n Decision made to keep requirements language for informational draftn Each use of MAYMUSTSHOULD etc is to be reviewed
Open Issues(25)
n Add section on multicast via Proxy and its limitations (274)n Add a section to explain the issues amp limitations of doing CoAP multicast
requests via a CoAP Proxy n Goal is to warn and guide implementers in this subject n Also such a section would provide a placeholderreminder of the problems
that might be addressed further in the futuren Based on IETF 85 CoRE WG meeting discussion on Multicast CoAP
requests via a Proxy Discussion summary for referencen Aggregation of responses in a proxy is difficult since it doesnt know
when to stop aggregating responses n SIP tried to deal with this problem but didnt solve it n There may be an expectancy of CoAP client to get single response
back from proxy not multiple The client in this case may not even know what it could expect It may not even know the Proxy-URI contains a multicast target
n Presented via-proxy use case exposes gap in the core-coap specification regarding multicast via proxy (Note Expectation is that core-coap wonrsquot address it in the first planned RFC release)
Open Issues(35)
n Issues with twomultiple Resource Directories in use case (280)n Some potential issues with RD came out of review Peter van der Stok and
WG discussion IETF85 n There are two RD servers use case shows that only one is found despite
the fact that site-local multicast is used - should be two RDs found n Proposal simplify use case to a single RD server on the backbone to avoid
such RD-specific issues like synchronization of RD information between servers
Open Issues(45)
n Add single-subnet configuration to use cases (278)n Suggested by review Peter van der Stok and IETF85 WG discussion that
its best to start explaining the simplebasic cases and then gradually build up complexity
n Simplest case not shown yet would be a single subnet network configuration which is currently not present in the I-D only the 2-subnet configuration of Fig 1
n Question Do we need to add such case or doesnt it add muchn (Note that core-coap Figure 22 already shows the simplest case of link-local
multicast)
Open Issues(55)
n Add use case with controller (client) located on the backbone (279)n Suggested by discussion following review Peter van der Stok n Case missing where a controller (client) is located on the backbonen Question Do we need to add such case or does it add much
Group 2a other old friends
25
Angelo Castellani Salvatore Loreto Akbar Rahman Thomas Fossati Esko Dijk
IETF 86 March 2013httpwwwietforgiddraft-castellani-core-http-mapping-07txt
Best Practices for HTTP-CoAP Mapping
Implementation
Summary of Changes (from -06 rev)
n Based on discussion at last IETF-85 (Atlanta)n Clarification of HTTP-CoAP Proxies
n Definitionn Placementn Benefits
n Clarification of HTTP-CoAP URI mapping options
Goals of I-D
n For Reverse HTTP-CoAP Cross Protocol Proxyn Provide more detailed information to proxy designers (beyond
Section 10 of [I-Dietf-core-coap]) to help implement proxies that correctly inter-work with other CoAP and HTTP clientserver implementations that adhere to the specifications
n Define a consistent set of guidelines that a HTTP-to-CoAP proxy implementation MAY adhere to The main reason of adhering to such guidelines is to reduce variation between proxy implementations thereby increasing interoperabilityn As an example use case a proxy conforming to these guidelines made
by vendor A can be easily replaced by a proxy from vendor B that also conforms to the guidelines
I-D Outline
n Guidance on HTTP to CoAP URI mappingn HTTP-CoAP Reverse cross-protocol proxy implementation
n Placementn Response code amp media type translationsn Caching and congestion controln Cache refresh via Observen Use of CoAP blockwise transfern Security translation
n Security Considerationsn Traffic overflown Handling secured exchanges
Definitions (12)
n Cross-Protocol Proxy (or Cross Proxy) is a proxy performing a cross- protocol mapping in the context of this document a HTTP-CoAP (HC) mapping A Cross-Protocol Proxy can behave as a Forward Proxy Reverse Proxy or Interception Proxy n Note In this document we focus on the Reverse Proxy mode of the
Cross-Protocol Proxy
n Forward Proxy a message forwarding agent that is selected by the client usually via local configuration rules to receive requests for some type(s) of absolute URI and to attempt to satisfy those requests via translation to the protocol indicated by the absolute URI The user decides (is willing to) use the proxy as the forwardingdereferencing agent for a predefined subset of the URI space
Definitions (22)
n Reverse Proxy a receiving agent that acts as a layer above some other server(s) and translates the received requests to the underlying servers protocol It behaves as an origin (HTTP) server on its connection towards the (HTTP) client and as a (CoAP) client on its connection towards the (CoAP) origin server The (HTTP) client uses the origin-form [I-Dietf-httpbis-p1-messaging] as a request- target URI
n Reverse and Forward proxies are technically very similar with main differences being that the former appears to a client as an origin server while the latter does not and that clients may be unaware they are communicating with a proxy
Reverse Cross-Protocol Proxy Deployment Scenario
HTTP-CoAP Response Code Mapping
Implementation Experience
n Direct experience from the draft authorsn Squid HTTP-CoAP mapping module
n University of Padovan httptelecomdeiunipditiotn Both Forward and Interception operation supported
n HTTP-CoAP proxy based on EvCoAPn KoanLogic University of Bologna and Salvatore
Loreto (as individual)n httpsgithubcomkoanlogicwebthingstreemasterbridgesw
libevcoapn The document is open to input from other implementations
Next Steps
n Does the WG recommend adoptionn Intended status Informational Best Practicen Purpose Reduce arbitrary variation between proxy
implementations thereby increasing interoperability
Backup
HTTP to CoAP URI Mapping Options (12)
n Embedded Mapping n In an embedded mapping approach the HTTP URI has embedded
inside it the authority and path part of the CoAP URI n Example The CoAP resource nodecoapsomethingnetfoo can
be accessed by an HTTP client by inserting in the request httphc-proxysomethingnetcoapnodecoapsomethingnetfoo The Cross-Protocol Proxy then maps the URI to coapnodecoapsomethingnetfoo
HTTP to CoAP URI Mapping Options (22)
n Homogeneous Mapping n In a homogeneous mapping approach only the scheme portion of the URI
needs to be mapped The rest of the URI (ie authority path etc) remains unchanged
n Example The CoAP resource coapnodecoapsomethingnetfoo can be accessed by an HTTP client by requesting httpnodecoapsomethingnetfoo The Cross-Protocol Proxy receiving the request is responsible to map the URI to coapnodecoapsomethingnetfoo
n Background info n The assumption in this case is that the HTTP client would be able to
successfully resolve nodecoapsomethingnet using DNS infrastructure to return the IP address of the HC proxy Most likely this would be through a two step DNS lookup where the first DNS lookup would resolve somethingnet using public DNS infrastructure
n Then the second DNS lookup on the subdomain coap and the host node would typically be resolved by a DNS server operated by the owner of domain somethingnet So this domain owner can manage its own internal node names and subdomain allocation which would correspond to the CoAP namespace
Group 3 ldquonew workrdquo
39
Transport of CoAP over SMS USSD and GPRSdraft-becker-core-coap-sms-gprs-03
Markus Becker Kepeng LiKoojana Kuladinithi Thomas Poumltsch
CoRE WG IETF-86 Orlando
1 10
ScenariosI In M2M communication IP connectivity is not alwayssupported by the constrained end-points
I Power savingI Coverage (GPRS 3G LTE)
I SMS and USSD based communication is almost alwayssupported
210
Changes from draft-01 to draft-03 (1)
I Added possible CONNONACK interactions Section 5
I Option name changed from Reply-To- to Response-To-Section 16 and Section 101
I Added URI schemeEg coap+tel+15105550101well-knowncore Section 11
I Added possible M2M proxy scenarios Section 14
3 10
Changes from draft-01 to draft-03 (2)
I Added reference to bormann-coap-misc for other SMSencoding Section 71
I Updated requirements on Uri-Host and Uri-Port forcoap+tel Section 10
I Added security considerations Transport and ObjectSecurity Section 15
I Chose CoAP option numbers and updated the optionnumber table to meet draft-ietf-core-coap-10 Table 1
I Added an IANA registration for the URI scheme coap+telSection 162
4 10
Feedback Split coap+tel into coap+smsand coap+ussd
I How else to differ the various transports in the URII Or is the transport to use decided by the implementationI See alsodraft-silverajan-core-coap-alternative-transports-01
5 10
Feedback Response-To-Scheme option
I Should there be a Response-To-Scheme optionadditionally to Response-To-Uri-Host andResponse-To-Uri-Path
I So that a CoAP end-point which receives a request by CoAPover non-IP transport can be instructed to also use thenon-IP transport for the response
I This would imply to add aResponse-To-Telephone-Subscriber and more options forother transports that have other URI schemes than coapand coaps
6 10
Feedback Selection of Transport by Client
I When a server is reachable by various transports howdoes a client decide which transport to use
I Client-side application congurationI Leave it to a proxy which uses cellular network lookupfunctions
7 10
Feedback Potential Threats
I Trigger expensive short messagesI Redirect trac to other addressesI More threats
I Are the security measures in the draft adequateI Whitelisting on serverI Relying on cellular network security (dedicated M2M APNs)I Object security on CoAP payload
8 10
Feedback Message Exchanges
I Figures 11-18 show possible message exchanges whenclient and server have two addresses
I With NON Not using CoAP retransmission capabilityI ACK on different transportI Additional (costly) message on Transport AI Request with Content
I Which ones are allowedI Which ones are meaningful
9 10
Next steps
I Rene Uri schemeI Response-To-Scheme optionI Selection of Message ExchangeI Rene Proxying
10 10
CoAP13 Communicaon13 with13 Alternave13 Transports
Bill Silverajan and Teemu SavolainenCore WG IETF 86 Orlando
031113
Objecves13 (In13 Scope)
bull Unambiguous13 representaon13 of13 transport13 to13 be13 used13 by13 CoAP
bull Details13 how13 the13 transport13 can13 carry13 CoAP13 packet
bull Focus13 is13 on13 what13 CoAP13 communicaons13 requirements13 are
bull Allow13 CoAP13 mechanisms13 to13 exploit13 cross-shy‐layer13 opmisaons
51
031113
Non13 Goals13 (Not13 in13 scope)
bull Applicaon-shy‐level13 QoS13 requirementsbull Real-shy‐me13 constraintsbull Ordering13 reliability13 congeson13 controlbull Applicaon13 and13 network13 adaptaonbull Mobility13 and13 readdressing13 supportbull Network13 protocol13 (eg13 IPsec)13 configuraon
52
031113
Use13 Cases
bull NAT13 and13 Firewall13 traversal13 with13 TCPbull Delay13 Tolerant13 Networkingbull Non-shy‐IP13 Low13 Energy13 Protocols
53
031113
Related13 Work
bull OMA13 Lightweight13 M2M13 Protocolbull CoAP13 over13 SMSGPRSUSSD
54
031113
What13 does13 the13 work13 entail
bull The13 ability13 to13 specify13 end13 point13 idenfiers13 and13 URIs13 to13 reflect13 which13 transport13 CoAP13 can13 use
bull The13 ability13 to13 register13 to13 resource13 directories13 resource13 types13 reflecng13 types13 of13 transport13 available
bull Ability13 for13 mul-shy‐transport13 nodes13 to13 select13 transport13 to13 use13 without13 significant13 alteraon13 to13 CoAP13 packet13 structure
55
031113
Points13 to13 consider
bull Requirements13 for13 transport13 layer13 protocol13 to13 carry13 CoAP13 packets
bull Representaon13 of13 URI13 scheme13 for13 generic13 transport13 protocols
bull Opon13 extensions13 for13 CoAP13 to13 express13 available13 transports
bull Mapping13 and13 message13 sizebull Security13 consideraons
56
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
URI13 =13 scheme13 13 13 authority13 path-shy‐abempty13 [13 query13 ]
bull Within13 the13 scheme13 namebull In13 the13 URI13 pathbull As13 a13 query13 component
57
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
bull Within13 the13 scheme13 namendash coap+tel+15105550101well-shy‐knowncorendash coap+tcpexamplecom5683temperaturendash coap+blel2cap[1234567890AB]4pulse
bull Easy13 URI13 parsing13 for13 transport13 type13 and13 idenfier
bull Each13 new13 scheme13 name13 requires13 IANA13 registraon
58
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
bull In13 the13 URI13 pathndash coaphostexamplecomtransport=tcpwell-shy‐knowncorert=core-shy‐rd
bull Easy13 adopon13 of13 new13 (and13 experimental)13 CoAP13 transports13 without13 IANA13 registraon
bull Caveat13 Uri-shy‐Path13 opon13 is13 a13 Crical13 CoAP13 opon13 see13 secon13 54113 of13 I-shy‐Diep-shy‐core-shy‐coap
59
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
bull As13 a13 URI13 query13 componentndash coaphostexamplecomwell-shy‐knowncorert=core-shy‐rdq=tcp
bull Also13 easy13 to13 adopt13 new13 (and13 experimental)13 CoAP13 transports13 without13 IANA13 registraon
bull Caveat13 Uri-shy‐Query13 opon13 is13 a13 Crical13 CoAP13 opon13 see13 secon13 54113 of13 I-shy‐Diep-shy‐core-shy‐coap
60
031113
URI13 Representaons13 for13 CoAPNon13 standard13 ways
bull Transport13 in13 the13 URI13 authority13 componentndash coaphost[port][transport]13 instead13 of13 coaphost[port]
bull Transport13 as13 a13 service13 URLndash servicecoaptcphostexamplecomwell-shy‐knowncorert=core-shy‐rd
bull Above13 two13 ways13 break13 exisng13 compability13 (although13 both13 are13 based13 on13 valid13 IANA13 URI13 registraons)
61
031113
URI13 Representaons13 for13 CoAPMiscellaneous13 Consideraons
bull Ensure13 that13 transport13 is13 defined13 unambiguously13 (eg13 L2CAP13 used13 by13 both13 BLE13 and13 standard13 Bluetooth13 so13 avoid13 rdquocoap+l2caprdquo13 or13 rdquotransport=l2caprdquo13 or13 rdquoq=l2caprdquondash Can13 be13 done13 as13 WG13 consensusndash Namespace13 approach13 eg13 rdquocoap+blel2caprdquo13 or13 rdquoq=blel2caprdquo
bull Allow13 end-shy‐points13 to13 use13 CoAP13 Resource13 Directory13 to13 register13 alternave13 transports13 and13 idenfiers13 and13 provide13 periodic13 updatesndash Register13 rdquocore-shy‐transportrdquo13 resource13 type
62
031113
Transport13 Consideraons
bull Uniqueness13 of13 end-shy‐point13 idenficaonbull Communicaon13 support13 Unidireconal13 Bidireconal13 1N13 (broadcast13 mulcast13 anycast)13 messaging
bull Binary13 encoding13 Network13 byte13 orderingbull MTU13 correlaon13 with13 CoAP13 PDU13 sizebull Transport13 latency
63
031113
Security13 Consideraons
bull Drar13 does13 not13 introduce13 new13 security13 requirements13 by13 itself
bull There13 may13 be13 privacy13 issues13 if13 nodes13 use13 telephone13 numbers13 or13 MAC13 addresses13 as13 public13 end13 point13 idenfiers
64
Akbar Rahman
IETF 86 March 2013 httpwwwietforgiddraft-rahman-core-sleepy-02txt
Enhanced Sleepy Node Support for CoAP
Introduction
It is expected that in CoAP networks there will be a certain portion of devices that are sleepy and which may occasionally go into a sleep mode (ie go into a low power state to conserve power) and subsequently have reduced CoAP protocol communication ability
This I-D proposes a minimal and efficient mechanism building on the Resource Directory concept (which will be integrated into a CoAP Proxy) to enhance sleepy node support in CoAP networks
Main Question from IETF-85 (Atlanta)
What performance benefit does the proposed Sleepy Node support solution give in a network that already has standard CoAP caching enabled
Sleepy Node Performance Analysis
Experimental Network
1-5 clients
Both Sleepy and Non-
Sleepy servers
Sleepy Node Performance Analysis Network Setup
CoAPSleepyServer(s)
CoAPSleepAwareReverseProxy
CoAP
Client(s)
Request
Response
Sleep9AwareCoREResourceDirectoryCapability
PublishedSleepParameters
Sleep9AwareCoAPStoreandForwardCapability Response
Request
SleepAwareCoAP503ResponseCapability
CoAPCachingCapability
bull Server supports publishing sleep parameters to proxy bull Eg Irsquom going to be asleep for X seconds
bull Proxy supports sleep-awareness capabilities bull Proxy also supports caching capability based off of maxAge bull Protocol flow similar to approach of Figure 1 (Synchronous RD Based Sleep
Tracking) of I-D
Proxy capabilities can be selectively enableddisabled
Proxy ndash Server Interface
Client ndash Proxy Interface
CoAP Sleep-Aware Reverse Proxy Features CoRE Sleep-aware Resource Directory
Support storing published sleep parameters from CoAP servers sleepState (AWAKE ASLEEP) sleepDuration
Sleep-aware CoAP 503 Response Capability If CoAP request to a sleeping server is received proxy returns a
lsquo503 Retry-Afterrsquo response to client 503 contains a timestamp indicating when the sever will wake back up
(timestamp delivered in CoAP maxAge option) Sleep-aware CoAP Store-and-Forward Capability
If CoAP request to a sleeping server is received proxy stores request until server wakes up and then forwards it
Caching capability Cache GET responses from server if maxAge option is present
(this is not a sleep aware feature)
Goals of Performance Analysis
For networks having sleepy servers provide measurements to quantify the impact that CoAP sleep-awareness capabilities can have
See if sleep-awareness capabilities can
provide additional benefits even when CoAP caching is used
Overview of Performance Analysis Performed The analysis was broken up into a set of test scenarios Each test scenario used a different combination of the following
variables Client issued GET requests Server was configured as a sleepy or non-sleepy server Proxy caching of GET responses was enabled or disabled Proxy sleep-aware 503 response capability was enabled or disabled Proxy store-and-forward capability was enabled or disabled maxAge in GET responses ndash Two values were tested 60sec and 5sec of Clients ndash Two values were used ndash 1 client and 5 clients
For comparison purposes the following were held constant across all test scenarios Client issued a fixed number of requests (100) across all test scenarios Client used a delay between each GET request (35sec) to better exercise
proxyrsquos caching and sleep-awareness capabilities For sleepy server test scenarios the server slept 60 sec awake for 3 sec
Format of Results The following results were collected for each
test scenario
Breakdown of the and types of transactions occurring between clientproxyserver
ldquoGETrdquo ndash Test Scenario Results
GET ndash Description of Test Scenarios
TestScenarios-GET
Scenario
CoAPSleepyServerSe7ngs CoAPSleepAwareReverseProxySe7ngs CoAPClientSe7ngs
SleepDuragton(sec)
AwakeDuragton(sec)
maxAge(sec) Caching SleepAwareSAF+
503NumberofClients
NumberofGETs
DelayBetweenClient
Requests(sec)
1a 0 Always 60 Enabled Disabled 1 100 35
1b 60 3 60 Enabled Disabled 1 100 35
1c 60 3 60 Enabled Enabled 1 100 35
2a 0 Always 60 Enabled Disabled 5 100 35
2b 60 3 60 Enabled Disabled 5 100 35
2c 60 3 60 Enabled Enabled 5 100 35
3a 0 Always 5 Enabled Disabled 5 100 35
3b 60 3 5 Enabled Disabled 5 100 35
3c 60 3 5 Enabled Enabled 5 100 35
ldquoGETrdquo ndash Test Scenario 1 Results
maxAge = 60 and 1 Client
GET ndash Scenario 1 ClientProxy Interface Transaction Mix
Scenarios 1a - Non-Sleepy Server Caching Proxy maxAge = 60sec 1b- Sleepy Server Caching Proxy maxAge = 60sec 1c - Sleepy Server Sleep Aware Proxy maxAge = 60sec
Sleep Aware Proxy has better performance for sleepy servers
0
100
200
300
400
500
600
700
1a 1b 1c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
GET ndash Scenario 1 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
Scenarios 1a - Non-Sleepy Server Caching Proxy maxAge = 60sec 1b- Sleepy Server Caching Proxy maxAge = 60sec 1c - Sleepy Server Sleep Aware Proxy maxAge = 60sec
0
100
200
300
400
500
600
700
800
1a 1b 1c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
ldquoGETrdquo ndash Test Scenario 2 Results
maxAge = 60 and 5 Clients
GET ndash Scenario 2 ClientProxy Interface Transaction Mix
Sleep Aware Proxy has slightly better performance for sleepy servers
0
200
400
600
800
1000
1200
1400
2a 2b 2c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
Scenarios 2a - Non-Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2b- Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2c - Sleepy Server Sleep Aware Proxy maxAge = 60sec 5 Clients
See ldquoExperimental Artifactsrdquo Note 1
GET ndash Scenario 2 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has slightly better performance for sleepy servers
0
50
100
150
200
250
300
350
400
2a 2b 2c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
Scenarios 2a - Non-Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2b- Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2c - Sleepy Server Sleep Aware Proxy maxAge = 60sec 5 Clients
See ldquoExperimental Artifactsrdquo Note 2
Experimental Artifacts Note 1
Currently in the experiment the sleep aware proxy checks the cached state of a resource before putting a request into its Store-and-forward queue while a server is sleeping Once in the queue the proxy unconditionally forwards the queued requests to the server once it wakes up This is not the most efficient setup and can easily be improved If the proxy instead checks its cache again before forwarding each queued request it may not need to forward the request to the server For example if there are two queued GET requests in the proxyrsquos queue that address the same resource Only the first request needs to be sent to the server the second request can use the cached response from the first request
Note 2 Currently in the experiment the sleepy server sends a sleepState PUT request to the
proxy each time it goes to sleep This is not the most efficient setup and can easily be improved For example if the server assumes that the proxy can keep track of its ONOFF cycles with its internal timers (eg as per Fig 1 of I-D) then the number of messages from the sleepy server dramatically goes down
ldquoGETrdquo ndash Test Scenario 3 Results
maxAge = 5 and 5 Clients
GET ndash Scenario 3 ClientProxy Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
Scenarios 3a - Non-Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3b- Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3c - Sleepy Server Sleep Aware Proxy maxAge = 5sec 5 Clients
0
500
1000
1500
2000
2500
3000
3500
4000
4500
5000
3a 3b 3c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
GET ndash Scenario 3 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
0
1000
2000
3000
4000
5000
6000
7000
3a 3b 3c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
Scenarios 3a - Non-Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3b- Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3c - Sleepy Server Sleep Aware Proxy maxAge = 5sec 5 Clients
Conclusions
Conclusions These results show that sleep-aware CoAP
proxy features can significantly optimize communication with sleepy servers in most scenarios
These results also show that sleep-
awareness capabilities can provide additional benefits above and beyond CoAP caching in most scenarios
Backup
Current CoAP Support of Sleepy Node (12)
CoAP proxies can use a previously cached response to service a new GET request for a sleepy origin server (as in HTTP) But if no valid cache then proxy has to attempt to
retrieve and may fail if origin server is sleeping [I-Dietf-core-coap]
Clients can discover list of resources from RD (GET rd-lookuphellip) for sleepy servers But attempt to GET resource from sleepy origin server
may fail if origin server is sleeping [IDietf-core-link-format amp IDshelby-core-resource-
directory]
Current CoAP Support of Sleepy Node (22)
Lower layer support for sleepy nodes in most wireless technologies (eg WiFi ZigBee) But limited to MAC packet scheduling for sleepy nodes
and not aware of specific needs of IP applications (like CoAP)
Proposal ndash RD Based Sleep Tracking (14)
The current CoAP approach to support sleepy nodes can be significantly improved by introducing RD based mechanisms for a CoAP client to determine whether A targeted resource is located on a sleepy server A sleepy server is currently in sleep mode or not
There is any associated caching Proxy (possibly the RD itself) for a sleepy server
Proposal ndash RD Based Sleep Tracking (24)
We define the following new RD attributes to characterize the properties of a sleepy node SleepState - Indicates whether the node is currently in
sleep mode or not (ie Sleeping or Awake) SleepDuration - Indicates the maximum duration of time
that the node stays in sleep mode TimeSleeping - Indicates the length of time the node
has been sleeping (ie if Sleep State = Sleeping) NextSleep - Indicates the next time the node will go to
sleep (ie if Sleep State = Awake)
CachingProxy ndash Indicates the caching proxy of the sleepy node (ie the RD itself or another node)
Proposal ndash RD Based Sleep Tracking (34)
These attributes are all server (node) level and are new parameters added to the RD URI Template Variables
Finally we also define a new lookup-type (ss) for the RD lookup interface specified in [I-Dshelby-core-resource-directory] This new lookup-type supports looking up the
ldquoSleepStaterdquo (ss) of a specified end-point
Proposal ndash RD Based Sleep Tracking (44)
The three time based parameters (SleepDuration TimeSleeping NextSleep) can be based on either an absolute network time (for a time synchronized network) or a relative local time (measured at the local node)
Following the approach of [I-Dietf-core-link-format] and [I-Dshelby-core-resource-directory] sleep parameters for sleepy servers can be stored by the server in the RD and accessed by all interested clients
Examples of using these parameters in a synchronous or asynchronous manner are shown in the I-D
http6lowappnet coreIETF86 2013-03-12-13
We assume people have read the drafts
Meetings serve to advance difficult issues by making good use of face-to-face communications
Note Well Be aware of the IPR principles according to RFC 3979 and its updates
uumlBlue sheetsuumlScribe(s)
96
drar-shy‐iep-shy‐core-shy‐coapsubmiqed13 to13 IESG
2013-shy‐03-shy‐13
97
OMA Lightweight M2M Overview(A new standard using lots of IETF specs including DTLS
CoAP Block Observe Resource Directory SenMLhellip)
Zach ShelbyCoRE WG IETF-86 Orlando
OMA Lightweight M2Mbull Open Mobile Alliance is well known for Device Management (DM)bull OMA Lightweight M2M is a new standard from the alliance
ndash Focused on constrained Cellular and sensor network M2M devicesndash Driven by leading operators and vendors
bull Scopendash Interfaces protocol amp security between Device and Serverndash Object and Resource modelndash Bootstrap Device Access Control Connectivity and Firmware Objects
bull Draft Specifications are availablendash httpmemberopenmobileallianceorgftpPublic_documentsDM
LightweightM2MPermanent_documentsOMA-TS-LightweightM2M-V1_0_0-20130301-Dzip
bull Timelinendash Requirements and Architecture completed 3Q2012ndash Spec ready for Consistency Review 2Q2013ndash Candidate Approval expected 3Q2013
2 CoRE WG IETF-86 Orlando
Architecture
3
Scope of LWM2M
CoRE WG IETF-86 Orlando
Object Model
bull A Client has one or more Object Instancesbull An Object is a collection of Resourcesbull A Resource is an atomic piece of information
ndash Read Written or Executed
bull Resources can have multiple instancesbull Objects and Resources are identified by a
16-bit Integer Instances by an 8-bit Integerbull ObjectsResources are accessed with
simple URIs Object IDObject InstanceResource ID
eg 1213
4 CoRE WG IETF-86 Orlando
CoRE WG IETF-86 Orlando
CoRE Resource Directory
draft-shelby-core-resource-directory-05
Z Shelby C Bormann S Krco
Backgroundbull Not a new concept
ndash think web search engine or any link directorybull Defines the interfaces to a Resource Directorybull Based on Web Linking framework and the CoRE Link Formatbull Generic REST design for use over HTTP and CoAPbull Used by OMA Lightweight M2Mbull Has already been deployed
ndash In traffic monitoring systemsndash In street lighting systemsndash For vehicular asset trackingndash By a major Cellular M2M operator
Changes since -04
bull Restricted Update to parameter updatesbull Added pagination support for the Lookup interfacebull Changed rt= to et= for the registration amp update
interfacebull Added group support
Group Management
bull RD now includes group management featuresbull New Group Function Set
ndash Register a groupbull Group name domain multicast address endpoint members
ndash Remove a groupbull Group lookup using the Lookup Function Set
ndash List registered groupsndash Find the members of a groupndash Find groups with certain endpoints or resources
Registering a Group
EP RD
| |
| - POST rd-groupgp=lights ltgtep=node1 --gt |
| |
| |
| lt---- 201 Created Location rd-group12 ---- |
| |
Req POST coaprdexamplecomrd-groupgp=lights
Payload
ltgtep=node1
ltgtep=node2
Res 201 Created
Location rd-group12
Looking up Group Members
Client RD
| |
| ----- GET rd-lookupepgp=lights1 ----------------------gt |
| |
| |
| lt-- 205 Content ltrdgtd=domain1ltrdgtd=domain2 --------- |
| |
Req GET rd-lookupepgp=lights1
Res 205 Content
ltcoaphostportgtep=node1
ltcoaphostportgtep=node2rdquo
Things for the futurebull Support for JSON representation of Web Links
ndash httptoolsietforgiddraft-bormann-core-links-json-02txtbull Registry for RD registration query parameters
ndash Already OMA Lightweight has defined some new onesbull More examples
Group 3 ldquonew workrdquo(continued)
109
drar-shy‐greevenbosch-shy‐core-shy‐profile-shy‐descripon-shy‐01Bert13 GreevenboschJeroen13 Hoebeke
Isam13 IshaqFloris13 Van13 den13 Abeele
Descripon
bull JSON13 format13 for13 signalling13 the13 servers13 capabilies
bull Signalling13 of13 supported13 opons13 media13 types13 and13 block13 sizendash Other13 items13 can13 be13 added
bull Filtering13 on13 specific13 fields13 through13 URI-shy‐Querybull Link13 hqpdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐profile-shy‐descripon
well-shy‐knownprofile
bull To13 acquire13 profile13 data13 of13 resources13 on13 a13 parcular13 service13 the13 well-shy‐knownprofile13 URI-shy‐path13 is13 introduced
bull For13 example13 to13 get13 all13 informaon13 from13 sensors13 served13 by13 wwwexampleorg13 we13 can13 do13 a13 GET13 to13 coapwwwexampleorgwell-shy‐knownprofile
bull Filtering13 on13 parcular13 resources13 is13 done13 through13 URI-shy‐Queries
Format
bull Currently13 the13 following13 fields13 are13 definedndash ldquopathrdquo13 contains13 the13 URI-shy‐path13 associated13 with13 a13 resource
ndash ldquooprdquo13 a13 numerical13 list13 of13 supported13 opon13 numbers
ndash ldquocfrdquo13 a13 numerical13 list13 of13 supported13 content-shy‐format13 numbers
ndash ldquob1srdquo13 ldquob2srdquo13 supported13 block13 sizes13 for13 Block113 and13 Block213 respecvely
Examplebull On13 the13 right13 is13 an13 example13 of13 a13 camera13 sensor13 at13 coapwwwexampleorgcam13 that13 supports13 the13 Uri-shy‐Host13 (3)13 ETag13 (4)13 Uri-shy‐Port13 (7)13 Uri-shy‐Path13 (11)13 Content-shy‐Format13 (12)13 Token13 (19)13 Block213 (23)13 and13 Proxy-shy‐Uri13 (35)13 opons
bull The13 supported13 content13 formats13 are13 textplain13 (0)13 applicaon13 link-shy‐format13 (40)13 and13 applicaonjson13 (50)
bull The13 supported13 Block213 can13 use13 25613 or13 51213 byte13 blocks
Req13 GET13 coapwwwexampleorgwell-shy‐knownprofile13 Res13 20513 Content13 (applicationjson)13 13 13 13 profile13 13 13 13 13 13 13 13 pathcam13 13 13 13 op[3471112192335]13 13 13 13 13 cf[04050]13 13 13 13 13 b2s[45]13 13 13 13
Filtering13 through13 use13 of13 URI-shy‐Query
bull Filtering13 can13 be13 done13 through13 the13 URI-shy‐Querybull Query13 format13 N=V
ndash N13 is13 a13 profile13 fieldndash V13 is13 the13 desired13 value
bull Examplesndash To13 find13 resources13 that13 support13 content13 format13 ldquoapplicaonjsonrdquo
13 GET13 wwwexampleorgwell-shy‐knownprofilecf=50ndash To13 get13 informaon13 about13 the13 camera
13 GET13 wwwexampleorgwell-shy‐knownprofilepath=cam
Open13 issues
bull Which13 other13 profile13 data13 needs13 signallingndash Content-shy‐type13 for13 different13 methods
bull Fix13 the13 order13 in13 which13 the13 profile13 fields13 must13 appearndash Non-shy‐fixed13 order13 easier13 extensible
bull Inheritance13 of13 a13 profile13 descriponbull Extend13 usage13 to13 signal13 the13 client13 profilebull Integraon13 with13 link13 format
Thank13 youQuesons
drar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval-shy‐00
Bert13 Greevenbosch
Descripon
bull The13 ldquoMinimumRequestInterval13 opon13 can13 be13 used13 to13 indicate13 the13 minimum13 me13 between13 two13 requests13 in13 a13 transacon
bull Originally13 intended13 for13 Block13 but13 also13 usable13 for13 other13 transaconsndash Example13 browsing13 a13 server
bull The13 goal13 is13 to13 reduce13 the13 server13 load13 and13 network13 traffic
bull Link13 hqpsdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval
Usage
bull The13 client13 keeps13 the13 server13 informed13 about13 its13 request13 speed13 through13 inclusion13 of13 the13 ldquoMinimumRequestIntervalrdquo13 opon
bull In13 responses13 the13 server13 fixes13 the13 minimum13 request13 interval13 through13 the13 same13 opon
bull The13 client13 obeys13 the13 speed13 indicated13 by13 the13 server
bull The13 client13 can13 send13 slower13 but13 not13 faster
Advantages
bull The13 server13 has13 means13 to13 limit13 the13 amount13 of13 incoming13 traffic
bull The13 server13 can13 prevent13 to13 become13 overloaded13 with13 too13 many13 tasks
bull The13 server13 does13 not13 need13 arficially13 slow13 down13 the13 client13 by13 sending13 late13 ACKsndash No13 need13 to13 keep13 track13 of13 delayed13 ACKsndash The13 server13 can13 perform13 other13 tasks13 instead
bull Reduced13 network13 traffic
Thank13 youQuesons
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-links-json-02txt
123
RFC 6690 (link-format) documents are somewhat foreign to many web app developerssect would prefer to have them in JSON format
There is no standard way to represent link-format documents in applicationssect but everyone knows how to handle JSON
Define a standard JSON translation for link-format
Itrsquos
not
rock
et
scien
ce
ltsensorsgtct=40title=Sensor Index ltsensorstempgtrt=temperature-cif=sensor ltsensorslightgtrt=light-luxif=sensor lthttpwwwexamplecomsensorst123gt anchor=sensorstemprel=describedby lttgtanchor=sensorstemprel=alternate [hrefsensorsct40titleSensor Index hrefsensorstemprttemperature-cifsensor hrefsensorslightrtlight-luxifsensor hrefhttpwwwexamplecomsensorst123 anchorsensorstempreldescribedby hreftanchorsensorstemprelalternate]
124
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-ipsec-for-coap-00txt
IPsec definitions for CoAP Mostly placeholder at this time Who has implementation experience with this
125
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-cross-reverse-convention-00txt
This draft has two lines of payload(based on a WGLC comment by Cullen Jennings)
coap12344567foobara=3
httpwwwproxycomwellknowncore-translate1234_4567foobara=3
Is that a useful convention to have
126
Insert CI slides here
127
128
0
5
10
15
20
25
30
35
40
10 20 30 40 50 60 70
good
put (
pps)
pps
Goodput vs pps (Econotags)
goodput
[Khattak preliminary]
Congestion Control
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-cocoa-00txt
ldquoadvancedrdquo cc (The draft is just a first shot) Others may have better ideas
129
Insert post-WGLC discussion slides here
130
Stop Continue Start
131
An Agile Retrospective
http6lowappnet coreIETF86 2013-03-12-13
Stop
132
Endless new CoAP optionssect instead use RESTful as much as possible
Move general security lifecycle out Looking at theoretical problems
http6lowappnet coreIETF86 2013-03-12-13
Continue
Interops Running code Look at real-world examples and deployments Solve their actual problems
sect Unilateral enhancements eg higher performance congestion control
sect Transports (SMS hellip)sect Make Web linking and Directories more and more usefulsect RESTful Design Paradigms for real-world problems
133
http6lowappnet coreIETF86 2013-03-12-13
Start
Further push into the (browser) web world (HTML5 browser security)
Specific supporting worksect SenMLsect URI work (dev URN hellip)sect Security Processes (next slide)
Spin outsect (We donrsquot really get to decide where this is done)
134
http6lowappnet coreIETF86 2013-03-12-13
Security
Integrate Application Network Group Keyingsect Tunnel-free setup
Donrsquot redo what has been done alreadysect ZigBee IP is finesect But what about other scenarios
Simple REST interfaces for working with keying materials and authorizationsect Start with defining objectives
Object Security for Constrained Nodes135
Re-chartering CoREWhat do we want to do now that wersquore grown up
Zach ShelbyCoRE WG IETF-86 Orlando
What is the scope
bull So we have a protocol and Web Linking what next
bull Keep with what we know besthellip1 Enhancements around CoAP2 New transports for CoAP3 New representations for Web Links4 General application layer solutions
CoRE WG IETF-86 Orlando 2
Enhancements around CoAP
bull Advanced congestion control
CoRE WG IETF-86 Orlando 3
New Transports for CoAP
bull Infrastructure for CoAP over foondash httptoolsietforgiddraft-silverajan-core-
coap-alternative-transports-01txtbull CoAP over SMS
ndash httptoolsietforgiddraft-becker-core-coap-sms-gprs-03txt
ndash OMA Lightweightbull CoAP over TCP
ndash httptoolsietforgiddraft-li-core-coap-payload-length-option-01txt
CoRE WG IETF-86 Orlando 4
New support for Web Links
bull JSON Web Linksndash httptoolsietforgiddraft-bormann-core-links-
json-02txt
2332010 CoRE WG IETF-77 Anaheim 5
General application layer solutions
bull Resource Directoryndash httptoolsietforgiddraft-shelby-core-
resource-directory-05txtndash OMA Lightweight
2332010 CoRE WG IETF-77 Anaheim 6
Repeatable13 Accept13 Opon
bull Problem
bull Soluon13 A13 ldquoJust13 do13 not13 do13 itrdquo13 and13 keep13 it13 generalbull Soluon13 B13 Change13 to13 non-shy‐repeatable
+ Predictable13 behavior13 when13 going13 through13 different13 caches+ Makes13 Accept13 and13 proxies13 easier13 to13 understand+ We13 have13 out-shy‐of-shy‐band13 content13 negoaon13 (ct=ldquoltAgt13 ltBgtrdquo)+ Can13 be13 added13 later13 as13 extension13 if13 really13 needed
GET13 someresAccept13 A13 B13
GET13 someresAccept13 B13 A13
someres13 (A13 B)13 =gt13 ltAgt
someres13 (B13 A)13 =gt13 ltAgt
Proxy
Also13 causesmulple13 observe13 relaonships
Cacheblowup
someresltAgt
Origin13 Server
Group 1a WGLC processingobserve block
9
http6lowappnet coreIETF86 2013-03-12-13
draft-ietf-core-observe-08
10
Changes from ndash07 to ndash08sect Expanded text on transmitting notification while a previous
transmission is pending (242)sect Changed reordering detection to use a fixed time span of 128
seconds instead of EXCHANGE_LIFETIME (276)sect Removed the use of the freshness model to determine if the
client is still on the list of observers
http6lowappnet coreIETF86 2013-03-12-13
draft-ietf-core-block-10
11
Still awaits grand editorial rewritesect right after coap-14 is shipped
http6lowappnet coreIETF86 2013-03-12-13
Tickets
hellip are our way to make the steps forward are at
http toolsietforgwgcore Updates are sent to the mailing list
sect Please review When we close a ticket please review once more
12
Group 2 groupcomm
13
Akbar RahmanEsko Dijk
IETF 86 March 2013httpwwwietforgiddraft-ietf-core-groupcomm-05txt
Group Communication for CoAP
Summary of Changes (14)
n I-D had two updates (Rev 04 amp 05) after IETF-85 (Atlanta) Many of the updates were due to the detailed review by Peter van der Stokn Thank you Peter for your valuable comments
n Changes from ietf-03 to ietf-04 n Section 23 (Potential Solutions for Group Communications) moved to
draft-dijk-core-groupcomm-misc (266)n Added reference to draft-keoh-tls-multicast-security to section 6 (Security
Considerations) n Appendix B (CoAP-Observe Alternative to Group Communications) moved
to draft-dijk-core-groupcomm-misc (267) n Deleted section 8 (Conclusions) as it is redundant (268) n Simplified light switch use case (269) by splitting into basic operations and
additional functions (269)
Summary of Changes (24)
n Changes from ietf-03 to ietf-04 (Continued) n Moved section 37 (CoAP Multicast and HTTP Unicast Interworking) to
draft-dijk-core-groupcomm-misc (270) n Moved section 331 (DNS-SD) and 332 (CoRE Resource Directory) to
draft-dijk-core-groupcomm-miscClarified that DNS based features are optional (272)
n Focus section 35 (Configuring Group Membership) on a single proposed solution
n Scope of section 53 (Use of MLD) widened to multicast destination advertisement methods in general
n Rewrote section 22 (Scope) for improved readibility n Moved use cases that are not adressed to draft-dijk-core-groupcomm-miscn Various editorial updates for improved readibility
Summary of Changes (34)
n Changes from ietf-04 to ietf-05 n Added a new section 39 (Exceptions) that highlights that IP multicast (and
hence group communications) is not always available (187) n Included guidelines on when (not) to use CoAP responses to multicast
requests and when (not) to accept multicast requests (273) n Added guideline on use of core-block for minimizing response size (275)n Restructured section 6 (Security Considerations) to more fully describe
threats and threat mitigation (277) n Clearly indicated that DNS resolution and reverse DNS lookup are optional n Removed confusing text about a single group having multiple IP addresses
If multiple IP addresses are required then multiple groups (with the same members) should be created
n Removed repetitive text about the fact that group communications is not guaranteed
Summary of Changes (44)
n Changes from ietf-04 to ietf-05 (Continued) n Merged previous section 52 (Multicast Routing) into 31 (IP Multicast
Routing Background) and added link to section 52 (Advertising Membership of Multicast Groups)
n Clarified text in section 38 (Congestion Control) regarding precedence of use of IP multicast domains (ie first try to use link-local scope then site-local scope and only use global IP Communication for CoAP multicast as a last resort)
n Extended group resource manipulation guidelines with use of preconfigured portspaths for the multicast group
n Consolidated all text relating to ports in a new section 33 (Port Configuration)
n Clarified that all methods (GETPUTPOST) for configuring group membership in endpoints should be unicast (and not multicast) in section 37 (Configuring Group Membership In Endpoints)
n Various editorial updates for improved readability
Discussion item (11)
n Solution for Configuring Group Membership (no ticket)n Example of (unicast) configuring an endpoint to be part of one multicast
groupReq POST gp (Content-Format applicationjson)
n floor1westbldg6examplecom ip ff154200f7feed3714cb Res 204 Changed
n Where the ldquogprdquo resource has resource type (rt) ldquocoregprdquo which is defined for this purpose
n Question Do we want specify such a solution (or for example leave it completely up to implementation)
Open Issues(15)
n Review Groupcomm requirements language (271)n Decision made to keep requirements language for informational draftn Each use of MAYMUSTSHOULD etc is to be reviewed
Open Issues(25)
n Add section on multicast via Proxy and its limitations (274)n Add a section to explain the issues amp limitations of doing CoAP multicast
requests via a CoAP Proxy n Goal is to warn and guide implementers in this subject n Also such a section would provide a placeholderreminder of the problems
that might be addressed further in the futuren Based on IETF 85 CoRE WG meeting discussion on Multicast CoAP
requests via a Proxy Discussion summary for referencen Aggregation of responses in a proxy is difficult since it doesnt know
when to stop aggregating responses n SIP tried to deal with this problem but didnt solve it n There may be an expectancy of CoAP client to get single response
back from proxy not multiple The client in this case may not even know what it could expect It may not even know the Proxy-URI contains a multicast target
n Presented via-proxy use case exposes gap in the core-coap specification regarding multicast via proxy (Note Expectation is that core-coap wonrsquot address it in the first planned RFC release)
Open Issues(35)
n Issues with twomultiple Resource Directories in use case (280)n Some potential issues with RD came out of review Peter van der Stok and
WG discussion IETF85 n There are two RD servers use case shows that only one is found despite
the fact that site-local multicast is used - should be two RDs found n Proposal simplify use case to a single RD server on the backbone to avoid
such RD-specific issues like synchronization of RD information between servers
Open Issues(45)
n Add single-subnet configuration to use cases (278)n Suggested by review Peter van der Stok and IETF85 WG discussion that
its best to start explaining the simplebasic cases and then gradually build up complexity
n Simplest case not shown yet would be a single subnet network configuration which is currently not present in the I-D only the 2-subnet configuration of Fig 1
n Question Do we need to add such case or doesnt it add muchn (Note that core-coap Figure 22 already shows the simplest case of link-local
multicast)
Open Issues(55)
n Add use case with controller (client) located on the backbone (279)n Suggested by discussion following review Peter van der Stok n Case missing where a controller (client) is located on the backbonen Question Do we need to add such case or does it add much
Group 2a other old friends
25
Angelo Castellani Salvatore Loreto Akbar Rahman Thomas Fossati Esko Dijk
IETF 86 March 2013httpwwwietforgiddraft-castellani-core-http-mapping-07txt
Best Practices for HTTP-CoAP Mapping
Implementation
Summary of Changes (from -06 rev)
n Based on discussion at last IETF-85 (Atlanta)n Clarification of HTTP-CoAP Proxies
n Definitionn Placementn Benefits
n Clarification of HTTP-CoAP URI mapping options
Goals of I-D
n For Reverse HTTP-CoAP Cross Protocol Proxyn Provide more detailed information to proxy designers (beyond
Section 10 of [I-Dietf-core-coap]) to help implement proxies that correctly inter-work with other CoAP and HTTP clientserver implementations that adhere to the specifications
n Define a consistent set of guidelines that a HTTP-to-CoAP proxy implementation MAY adhere to The main reason of adhering to such guidelines is to reduce variation between proxy implementations thereby increasing interoperabilityn As an example use case a proxy conforming to these guidelines made
by vendor A can be easily replaced by a proxy from vendor B that also conforms to the guidelines
I-D Outline
n Guidance on HTTP to CoAP URI mappingn HTTP-CoAP Reverse cross-protocol proxy implementation
n Placementn Response code amp media type translationsn Caching and congestion controln Cache refresh via Observen Use of CoAP blockwise transfern Security translation
n Security Considerationsn Traffic overflown Handling secured exchanges
Definitions (12)
n Cross-Protocol Proxy (or Cross Proxy) is a proxy performing a cross- protocol mapping in the context of this document a HTTP-CoAP (HC) mapping A Cross-Protocol Proxy can behave as a Forward Proxy Reverse Proxy or Interception Proxy n Note In this document we focus on the Reverse Proxy mode of the
Cross-Protocol Proxy
n Forward Proxy a message forwarding agent that is selected by the client usually via local configuration rules to receive requests for some type(s) of absolute URI and to attempt to satisfy those requests via translation to the protocol indicated by the absolute URI The user decides (is willing to) use the proxy as the forwardingdereferencing agent for a predefined subset of the URI space
Definitions (22)
n Reverse Proxy a receiving agent that acts as a layer above some other server(s) and translates the received requests to the underlying servers protocol It behaves as an origin (HTTP) server on its connection towards the (HTTP) client and as a (CoAP) client on its connection towards the (CoAP) origin server The (HTTP) client uses the origin-form [I-Dietf-httpbis-p1-messaging] as a request- target URI
n Reverse and Forward proxies are technically very similar with main differences being that the former appears to a client as an origin server while the latter does not and that clients may be unaware they are communicating with a proxy
Reverse Cross-Protocol Proxy Deployment Scenario
HTTP-CoAP Response Code Mapping
Implementation Experience
n Direct experience from the draft authorsn Squid HTTP-CoAP mapping module
n University of Padovan httptelecomdeiunipditiotn Both Forward and Interception operation supported
n HTTP-CoAP proxy based on EvCoAPn KoanLogic University of Bologna and Salvatore
Loreto (as individual)n httpsgithubcomkoanlogicwebthingstreemasterbridgesw
libevcoapn The document is open to input from other implementations
Next Steps
n Does the WG recommend adoptionn Intended status Informational Best Practicen Purpose Reduce arbitrary variation between proxy
implementations thereby increasing interoperability
Backup
HTTP to CoAP URI Mapping Options (12)
n Embedded Mapping n In an embedded mapping approach the HTTP URI has embedded
inside it the authority and path part of the CoAP URI n Example The CoAP resource nodecoapsomethingnetfoo can
be accessed by an HTTP client by inserting in the request httphc-proxysomethingnetcoapnodecoapsomethingnetfoo The Cross-Protocol Proxy then maps the URI to coapnodecoapsomethingnetfoo
HTTP to CoAP URI Mapping Options (22)
n Homogeneous Mapping n In a homogeneous mapping approach only the scheme portion of the URI
needs to be mapped The rest of the URI (ie authority path etc) remains unchanged
n Example The CoAP resource coapnodecoapsomethingnetfoo can be accessed by an HTTP client by requesting httpnodecoapsomethingnetfoo The Cross-Protocol Proxy receiving the request is responsible to map the URI to coapnodecoapsomethingnetfoo
n Background info n The assumption in this case is that the HTTP client would be able to
successfully resolve nodecoapsomethingnet using DNS infrastructure to return the IP address of the HC proxy Most likely this would be through a two step DNS lookup where the first DNS lookup would resolve somethingnet using public DNS infrastructure
n Then the second DNS lookup on the subdomain coap and the host node would typically be resolved by a DNS server operated by the owner of domain somethingnet So this domain owner can manage its own internal node names and subdomain allocation which would correspond to the CoAP namespace
Group 3 ldquonew workrdquo
39
Transport of CoAP over SMS USSD and GPRSdraft-becker-core-coap-sms-gprs-03
Markus Becker Kepeng LiKoojana Kuladinithi Thomas Poumltsch
CoRE WG IETF-86 Orlando
1 10
ScenariosI In M2M communication IP connectivity is not alwayssupported by the constrained end-points
I Power savingI Coverage (GPRS 3G LTE)
I SMS and USSD based communication is almost alwayssupported
210
Changes from draft-01 to draft-03 (1)
I Added possible CONNONACK interactions Section 5
I Option name changed from Reply-To- to Response-To-Section 16 and Section 101
I Added URI schemeEg coap+tel+15105550101well-knowncore Section 11
I Added possible M2M proxy scenarios Section 14
3 10
Changes from draft-01 to draft-03 (2)
I Added reference to bormann-coap-misc for other SMSencoding Section 71
I Updated requirements on Uri-Host and Uri-Port forcoap+tel Section 10
I Added security considerations Transport and ObjectSecurity Section 15
I Chose CoAP option numbers and updated the optionnumber table to meet draft-ietf-core-coap-10 Table 1
I Added an IANA registration for the URI scheme coap+telSection 162
4 10
Feedback Split coap+tel into coap+smsand coap+ussd
I How else to differ the various transports in the URII Or is the transport to use decided by the implementationI See alsodraft-silverajan-core-coap-alternative-transports-01
5 10
Feedback Response-To-Scheme option
I Should there be a Response-To-Scheme optionadditionally to Response-To-Uri-Host andResponse-To-Uri-Path
I So that a CoAP end-point which receives a request by CoAPover non-IP transport can be instructed to also use thenon-IP transport for the response
I This would imply to add aResponse-To-Telephone-Subscriber and more options forother transports that have other URI schemes than coapand coaps
6 10
Feedback Selection of Transport by Client
I When a server is reachable by various transports howdoes a client decide which transport to use
I Client-side application congurationI Leave it to a proxy which uses cellular network lookupfunctions
7 10
Feedback Potential Threats
I Trigger expensive short messagesI Redirect trac to other addressesI More threats
I Are the security measures in the draft adequateI Whitelisting on serverI Relying on cellular network security (dedicated M2M APNs)I Object security on CoAP payload
8 10
Feedback Message Exchanges
I Figures 11-18 show possible message exchanges whenclient and server have two addresses
I With NON Not using CoAP retransmission capabilityI ACK on different transportI Additional (costly) message on Transport AI Request with Content
I Which ones are allowedI Which ones are meaningful
9 10
Next steps
I Rene Uri schemeI Response-To-Scheme optionI Selection of Message ExchangeI Rene Proxying
10 10
CoAP13 Communicaon13 with13 Alternave13 Transports
Bill Silverajan and Teemu SavolainenCore WG IETF 86 Orlando
031113
Objecves13 (In13 Scope)
bull Unambiguous13 representaon13 of13 transport13 to13 be13 used13 by13 CoAP
bull Details13 how13 the13 transport13 can13 carry13 CoAP13 packet
bull Focus13 is13 on13 what13 CoAP13 communicaons13 requirements13 are
bull Allow13 CoAP13 mechanisms13 to13 exploit13 cross-shy‐layer13 opmisaons
51
031113
Non13 Goals13 (Not13 in13 scope)
bull Applicaon-shy‐level13 QoS13 requirementsbull Real-shy‐me13 constraintsbull Ordering13 reliability13 congeson13 controlbull Applicaon13 and13 network13 adaptaonbull Mobility13 and13 readdressing13 supportbull Network13 protocol13 (eg13 IPsec)13 configuraon
52
031113
Use13 Cases
bull NAT13 and13 Firewall13 traversal13 with13 TCPbull Delay13 Tolerant13 Networkingbull Non-shy‐IP13 Low13 Energy13 Protocols
53
031113
Related13 Work
bull OMA13 Lightweight13 M2M13 Protocolbull CoAP13 over13 SMSGPRSUSSD
54
031113
What13 does13 the13 work13 entail
bull The13 ability13 to13 specify13 end13 point13 idenfiers13 and13 URIs13 to13 reflect13 which13 transport13 CoAP13 can13 use
bull The13 ability13 to13 register13 to13 resource13 directories13 resource13 types13 reflecng13 types13 of13 transport13 available
bull Ability13 for13 mul-shy‐transport13 nodes13 to13 select13 transport13 to13 use13 without13 significant13 alteraon13 to13 CoAP13 packet13 structure
55
031113
Points13 to13 consider
bull Requirements13 for13 transport13 layer13 protocol13 to13 carry13 CoAP13 packets
bull Representaon13 of13 URI13 scheme13 for13 generic13 transport13 protocols
bull Opon13 extensions13 for13 CoAP13 to13 express13 available13 transports
bull Mapping13 and13 message13 sizebull Security13 consideraons
56
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
URI13 =13 scheme13 13 13 authority13 path-shy‐abempty13 [13 query13 ]
bull Within13 the13 scheme13 namebull In13 the13 URI13 pathbull As13 a13 query13 component
57
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
bull Within13 the13 scheme13 namendash coap+tel+15105550101well-shy‐knowncorendash coap+tcpexamplecom5683temperaturendash coap+blel2cap[1234567890AB]4pulse
bull Easy13 URI13 parsing13 for13 transport13 type13 and13 idenfier
bull Each13 new13 scheme13 name13 requires13 IANA13 registraon
58
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
bull In13 the13 URI13 pathndash coaphostexamplecomtransport=tcpwell-shy‐knowncorert=core-shy‐rd
bull Easy13 adopon13 of13 new13 (and13 experimental)13 CoAP13 transports13 without13 IANA13 registraon
bull Caveat13 Uri-shy‐Path13 opon13 is13 a13 Crical13 CoAP13 opon13 see13 secon13 54113 of13 I-shy‐Diep-shy‐core-shy‐coap
59
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
bull As13 a13 URI13 query13 componentndash coaphostexamplecomwell-shy‐knowncorert=core-shy‐rdq=tcp
bull Also13 easy13 to13 adopt13 new13 (and13 experimental)13 CoAP13 transports13 without13 IANA13 registraon
bull Caveat13 Uri-shy‐Query13 opon13 is13 a13 Crical13 CoAP13 opon13 see13 secon13 54113 of13 I-shy‐Diep-shy‐core-shy‐coap
60
031113
URI13 Representaons13 for13 CoAPNon13 standard13 ways
bull Transport13 in13 the13 URI13 authority13 componentndash coaphost[port][transport]13 instead13 of13 coaphost[port]
bull Transport13 as13 a13 service13 URLndash servicecoaptcphostexamplecomwell-shy‐knowncorert=core-shy‐rd
bull Above13 two13 ways13 break13 exisng13 compability13 (although13 both13 are13 based13 on13 valid13 IANA13 URI13 registraons)
61
031113
URI13 Representaons13 for13 CoAPMiscellaneous13 Consideraons
bull Ensure13 that13 transport13 is13 defined13 unambiguously13 (eg13 L2CAP13 used13 by13 both13 BLE13 and13 standard13 Bluetooth13 so13 avoid13 rdquocoap+l2caprdquo13 or13 rdquotransport=l2caprdquo13 or13 rdquoq=l2caprdquondash Can13 be13 done13 as13 WG13 consensusndash Namespace13 approach13 eg13 rdquocoap+blel2caprdquo13 or13 rdquoq=blel2caprdquo
bull Allow13 end-shy‐points13 to13 use13 CoAP13 Resource13 Directory13 to13 register13 alternave13 transports13 and13 idenfiers13 and13 provide13 periodic13 updatesndash Register13 rdquocore-shy‐transportrdquo13 resource13 type
62
031113
Transport13 Consideraons
bull Uniqueness13 of13 end-shy‐point13 idenficaonbull Communicaon13 support13 Unidireconal13 Bidireconal13 1N13 (broadcast13 mulcast13 anycast)13 messaging
bull Binary13 encoding13 Network13 byte13 orderingbull MTU13 correlaon13 with13 CoAP13 PDU13 sizebull Transport13 latency
63
031113
Security13 Consideraons
bull Drar13 does13 not13 introduce13 new13 security13 requirements13 by13 itself
bull There13 may13 be13 privacy13 issues13 if13 nodes13 use13 telephone13 numbers13 or13 MAC13 addresses13 as13 public13 end13 point13 idenfiers
64
Akbar Rahman
IETF 86 March 2013 httpwwwietforgiddraft-rahman-core-sleepy-02txt
Enhanced Sleepy Node Support for CoAP
Introduction
It is expected that in CoAP networks there will be a certain portion of devices that are sleepy and which may occasionally go into a sleep mode (ie go into a low power state to conserve power) and subsequently have reduced CoAP protocol communication ability
This I-D proposes a minimal and efficient mechanism building on the Resource Directory concept (which will be integrated into a CoAP Proxy) to enhance sleepy node support in CoAP networks
Main Question from IETF-85 (Atlanta)
What performance benefit does the proposed Sleepy Node support solution give in a network that already has standard CoAP caching enabled
Sleepy Node Performance Analysis
Experimental Network
1-5 clients
Both Sleepy and Non-
Sleepy servers
Sleepy Node Performance Analysis Network Setup
CoAPSleepyServer(s)
CoAPSleepAwareReverseProxy
CoAP
Client(s)
Request
Response
Sleep9AwareCoREResourceDirectoryCapability
PublishedSleepParameters
Sleep9AwareCoAPStoreandForwardCapability Response
Request
SleepAwareCoAP503ResponseCapability
CoAPCachingCapability
bull Server supports publishing sleep parameters to proxy bull Eg Irsquom going to be asleep for X seconds
bull Proxy supports sleep-awareness capabilities bull Proxy also supports caching capability based off of maxAge bull Protocol flow similar to approach of Figure 1 (Synchronous RD Based Sleep
Tracking) of I-D
Proxy capabilities can be selectively enableddisabled
Proxy ndash Server Interface
Client ndash Proxy Interface
CoAP Sleep-Aware Reverse Proxy Features CoRE Sleep-aware Resource Directory
Support storing published sleep parameters from CoAP servers sleepState (AWAKE ASLEEP) sleepDuration
Sleep-aware CoAP 503 Response Capability If CoAP request to a sleeping server is received proxy returns a
lsquo503 Retry-Afterrsquo response to client 503 contains a timestamp indicating when the sever will wake back up
(timestamp delivered in CoAP maxAge option) Sleep-aware CoAP Store-and-Forward Capability
If CoAP request to a sleeping server is received proxy stores request until server wakes up and then forwards it
Caching capability Cache GET responses from server if maxAge option is present
(this is not a sleep aware feature)
Goals of Performance Analysis
For networks having sleepy servers provide measurements to quantify the impact that CoAP sleep-awareness capabilities can have
See if sleep-awareness capabilities can
provide additional benefits even when CoAP caching is used
Overview of Performance Analysis Performed The analysis was broken up into a set of test scenarios Each test scenario used a different combination of the following
variables Client issued GET requests Server was configured as a sleepy or non-sleepy server Proxy caching of GET responses was enabled or disabled Proxy sleep-aware 503 response capability was enabled or disabled Proxy store-and-forward capability was enabled or disabled maxAge in GET responses ndash Two values were tested 60sec and 5sec of Clients ndash Two values were used ndash 1 client and 5 clients
For comparison purposes the following were held constant across all test scenarios Client issued a fixed number of requests (100) across all test scenarios Client used a delay between each GET request (35sec) to better exercise
proxyrsquos caching and sleep-awareness capabilities For sleepy server test scenarios the server slept 60 sec awake for 3 sec
Format of Results The following results were collected for each
test scenario
Breakdown of the and types of transactions occurring between clientproxyserver
ldquoGETrdquo ndash Test Scenario Results
GET ndash Description of Test Scenarios
TestScenarios-GET
Scenario
CoAPSleepyServerSe7ngs CoAPSleepAwareReverseProxySe7ngs CoAPClientSe7ngs
SleepDuragton(sec)
AwakeDuragton(sec)
maxAge(sec) Caching SleepAwareSAF+
503NumberofClients
NumberofGETs
DelayBetweenClient
Requests(sec)
1a 0 Always 60 Enabled Disabled 1 100 35
1b 60 3 60 Enabled Disabled 1 100 35
1c 60 3 60 Enabled Enabled 1 100 35
2a 0 Always 60 Enabled Disabled 5 100 35
2b 60 3 60 Enabled Disabled 5 100 35
2c 60 3 60 Enabled Enabled 5 100 35
3a 0 Always 5 Enabled Disabled 5 100 35
3b 60 3 5 Enabled Disabled 5 100 35
3c 60 3 5 Enabled Enabled 5 100 35
ldquoGETrdquo ndash Test Scenario 1 Results
maxAge = 60 and 1 Client
GET ndash Scenario 1 ClientProxy Interface Transaction Mix
Scenarios 1a - Non-Sleepy Server Caching Proxy maxAge = 60sec 1b- Sleepy Server Caching Proxy maxAge = 60sec 1c - Sleepy Server Sleep Aware Proxy maxAge = 60sec
Sleep Aware Proxy has better performance for sleepy servers
0
100
200
300
400
500
600
700
1a 1b 1c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
GET ndash Scenario 1 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
Scenarios 1a - Non-Sleepy Server Caching Proxy maxAge = 60sec 1b- Sleepy Server Caching Proxy maxAge = 60sec 1c - Sleepy Server Sleep Aware Proxy maxAge = 60sec
0
100
200
300
400
500
600
700
800
1a 1b 1c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
ldquoGETrdquo ndash Test Scenario 2 Results
maxAge = 60 and 5 Clients
GET ndash Scenario 2 ClientProxy Interface Transaction Mix
Sleep Aware Proxy has slightly better performance for sleepy servers
0
200
400
600
800
1000
1200
1400
2a 2b 2c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
Scenarios 2a - Non-Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2b- Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2c - Sleepy Server Sleep Aware Proxy maxAge = 60sec 5 Clients
See ldquoExperimental Artifactsrdquo Note 1
GET ndash Scenario 2 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has slightly better performance for sleepy servers
0
50
100
150
200
250
300
350
400
2a 2b 2c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
Scenarios 2a - Non-Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2b- Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2c - Sleepy Server Sleep Aware Proxy maxAge = 60sec 5 Clients
See ldquoExperimental Artifactsrdquo Note 2
Experimental Artifacts Note 1
Currently in the experiment the sleep aware proxy checks the cached state of a resource before putting a request into its Store-and-forward queue while a server is sleeping Once in the queue the proxy unconditionally forwards the queued requests to the server once it wakes up This is not the most efficient setup and can easily be improved If the proxy instead checks its cache again before forwarding each queued request it may not need to forward the request to the server For example if there are two queued GET requests in the proxyrsquos queue that address the same resource Only the first request needs to be sent to the server the second request can use the cached response from the first request
Note 2 Currently in the experiment the sleepy server sends a sleepState PUT request to the
proxy each time it goes to sleep This is not the most efficient setup and can easily be improved For example if the server assumes that the proxy can keep track of its ONOFF cycles with its internal timers (eg as per Fig 1 of I-D) then the number of messages from the sleepy server dramatically goes down
ldquoGETrdquo ndash Test Scenario 3 Results
maxAge = 5 and 5 Clients
GET ndash Scenario 3 ClientProxy Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
Scenarios 3a - Non-Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3b- Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3c - Sleepy Server Sleep Aware Proxy maxAge = 5sec 5 Clients
0
500
1000
1500
2000
2500
3000
3500
4000
4500
5000
3a 3b 3c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
GET ndash Scenario 3 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
0
1000
2000
3000
4000
5000
6000
7000
3a 3b 3c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
Scenarios 3a - Non-Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3b- Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3c - Sleepy Server Sleep Aware Proxy maxAge = 5sec 5 Clients
Conclusions
Conclusions These results show that sleep-aware CoAP
proxy features can significantly optimize communication with sleepy servers in most scenarios
These results also show that sleep-
awareness capabilities can provide additional benefits above and beyond CoAP caching in most scenarios
Backup
Current CoAP Support of Sleepy Node (12)
CoAP proxies can use a previously cached response to service a new GET request for a sleepy origin server (as in HTTP) But if no valid cache then proxy has to attempt to
retrieve and may fail if origin server is sleeping [I-Dietf-core-coap]
Clients can discover list of resources from RD (GET rd-lookuphellip) for sleepy servers But attempt to GET resource from sleepy origin server
may fail if origin server is sleeping [IDietf-core-link-format amp IDshelby-core-resource-
directory]
Current CoAP Support of Sleepy Node (22)
Lower layer support for sleepy nodes in most wireless technologies (eg WiFi ZigBee) But limited to MAC packet scheduling for sleepy nodes
and not aware of specific needs of IP applications (like CoAP)
Proposal ndash RD Based Sleep Tracking (14)
The current CoAP approach to support sleepy nodes can be significantly improved by introducing RD based mechanisms for a CoAP client to determine whether A targeted resource is located on a sleepy server A sleepy server is currently in sleep mode or not
There is any associated caching Proxy (possibly the RD itself) for a sleepy server
Proposal ndash RD Based Sleep Tracking (24)
We define the following new RD attributes to characterize the properties of a sleepy node SleepState - Indicates whether the node is currently in
sleep mode or not (ie Sleeping or Awake) SleepDuration - Indicates the maximum duration of time
that the node stays in sleep mode TimeSleeping - Indicates the length of time the node
has been sleeping (ie if Sleep State = Sleeping) NextSleep - Indicates the next time the node will go to
sleep (ie if Sleep State = Awake)
CachingProxy ndash Indicates the caching proxy of the sleepy node (ie the RD itself or another node)
Proposal ndash RD Based Sleep Tracking (34)
These attributes are all server (node) level and are new parameters added to the RD URI Template Variables
Finally we also define a new lookup-type (ss) for the RD lookup interface specified in [I-Dshelby-core-resource-directory] This new lookup-type supports looking up the
ldquoSleepStaterdquo (ss) of a specified end-point
Proposal ndash RD Based Sleep Tracking (44)
The three time based parameters (SleepDuration TimeSleeping NextSleep) can be based on either an absolute network time (for a time synchronized network) or a relative local time (measured at the local node)
Following the approach of [I-Dietf-core-link-format] and [I-Dshelby-core-resource-directory] sleep parameters for sleepy servers can be stored by the server in the RD and accessed by all interested clients
Examples of using these parameters in a synchronous or asynchronous manner are shown in the I-D
http6lowappnet coreIETF86 2013-03-12-13
We assume people have read the drafts
Meetings serve to advance difficult issues by making good use of face-to-face communications
Note Well Be aware of the IPR principles according to RFC 3979 and its updates
uumlBlue sheetsuumlScribe(s)
96
drar-shy‐iep-shy‐core-shy‐coapsubmiqed13 to13 IESG
2013-shy‐03-shy‐13
97
OMA Lightweight M2M Overview(A new standard using lots of IETF specs including DTLS
CoAP Block Observe Resource Directory SenMLhellip)
Zach ShelbyCoRE WG IETF-86 Orlando
OMA Lightweight M2Mbull Open Mobile Alliance is well known for Device Management (DM)bull OMA Lightweight M2M is a new standard from the alliance
ndash Focused on constrained Cellular and sensor network M2M devicesndash Driven by leading operators and vendors
bull Scopendash Interfaces protocol amp security between Device and Serverndash Object and Resource modelndash Bootstrap Device Access Control Connectivity and Firmware Objects
bull Draft Specifications are availablendash httpmemberopenmobileallianceorgftpPublic_documentsDM
LightweightM2MPermanent_documentsOMA-TS-LightweightM2M-V1_0_0-20130301-Dzip
bull Timelinendash Requirements and Architecture completed 3Q2012ndash Spec ready for Consistency Review 2Q2013ndash Candidate Approval expected 3Q2013
2 CoRE WG IETF-86 Orlando
Architecture
3
Scope of LWM2M
CoRE WG IETF-86 Orlando
Object Model
bull A Client has one or more Object Instancesbull An Object is a collection of Resourcesbull A Resource is an atomic piece of information
ndash Read Written or Executed
bull Resources can have multiple instancesbull Objects and Resources are identified by a
16-bit Integer Instances by an 8-bit Integerbull ObjectsResources are accessed with
simple URIs Object IDObject InstanceResource ID
eg 1213
4 CoRE WG IETF-86 Orlando
CoRE WG IETF-86 Orlando
CoRE Resource Directory
draft-shelby-core-resource-directory-05
Z Shelby C Bormann S Krco
Backgroundbull Not a new concept
ndash think web search engine or any link directorybull Defines the interfaces to a Resource Directorybull Based on Web Linking framework and the CoRE Link Formatbull Generic REST design for use over HTTP and CoAPbull Used by OMA Lightweight M2Mbull Has already been deployed
ndash In traffic monitoring systemsndash In street lighting systemsndash For vehicular asset trackingndash By a major Cellular M2M operator
Changes since -04
bull Restricted Update to parameter updatesbull Added pagination support for the Lookup interfacebull Changed rt= to et= for the registration amp update
interfacebull Added group support
Group Management
bull RD now includes group management featuresbull New Group Function Set
ndash Register a groupbull Group name domain multicast address endpoint members
ndash Remove a groupbull Group lookup using the Lookup Function Set
ndash List registered groupsndash Find the members of a groupndash Find groups with certain endpoints or resources
Registering a Group
EP RD
| |
| - POST rd-groupgp=lights ltgtep=node1 --gt |
| |
| |
| lt---- 201 Created Location rd-group12 ---- |
| |
Req POST coaprdexamplecomrd-groupgp=lights
Payload
ltgtep=node1
ltgtep=node2
Res 201 Created
Location rd-group12
Looking up Group Members
Client RD
| |
| ----- GET rd-lookupepgp=lights1 ----------------------gt |
| |
| |
| lt-- 205 Content ltrdgtd=domain1ltrdgtd=domain2 --------- |
| |
Req GET rd-lookupepgp=lights1
Res 205 Content
ltcoaphostportgtep=node1
ltcoaphostportgtep=node2rdquo
Things for the futurebull Support for JSON representation of Web Links
ndash httptoolsietforgiddraft-bormann-core-links-json-02txtbull Registry for RD registration query parameters
ndash Already OMA Lightweight has defined some new onesbull More examples
Group 3 ldquonew workrdquo(continued)
109
drar-shy‐greevenbosch-shy‐core-shy‐profile-shy‐descripon-shy‐01Bert13 GreevenboschJeroen13 Hoebeke
Isam13 IshaqFloris13 Van13 den13 Abeele
Descripon
bull JSON13 format13 for13 signalling13 the13 servers13 capabilies
bull Signalling13 of13 supported13 opons13 media13 types13 and13 block13 sizendash Other13 items13 can13 be13 added
bull Filtering13 on13 specific13 fields13 through13 URI-shy‐Querybull Link13 hqpdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐profile-shy‐descripon
well-shy‐knownprofile
bull To13 acquire13 profile13 data13 of13 resources13 on13 a13 parcular13 service13 the13 well-shy‐knownprofile13 URI-shy‐path13 is13 introduced
bull For13 example13 to13 get13 all13 informaon13 from13 sensors13 served13 by13 wwwexampleorg13 we13 can13 do13 a13 GET13 to13 coapwwwexampleorgwell-shy‐knownprofile
bull Filtering13 on13 parcular13 resources13 is13 done13 through13 URI-shy‐Queries
Format
bull Currently13 the13 following13 fields13 are13 definedndash ldquopathrdquo13 contains13 the13 URI-shy‐path13 associated13 with13 a13 resource
ndash ldquooprdquo13 a13 numerical13 list13 of13 supported13 opon13 numbers
ndash ldquocfrdquo13 a13 numerical13 list13 of13 supported13 content-shy‐format13 numbers
ndash ldquob1srdquo13 ldquob2srdquo13 supported13 block13 sizes13 for13 Block113 and13 Block213 respecvely
Examplebull On13 the13 right13 is13 an13 example13 of13 a13 camera13 sensor13 at13 coapwwwexampleorgcam13 that13 supports13 the13 Uri-shy‐Host13 (3)13 ETag13 (4)13 Uri-shy‐Port13 (7)13 Uri-shy‐Path13 (11)13 Content-shy‐Format13 (12)13 Token13 (19)13 Block213 (23)13 and13 Proxy-shy‐Uri13 (35)13 opons
bull The13 supported13 content13 formats13 are13 textplain13 (0)13 applicaon13 link-shy‐format13 (40)13 and13 applicaonjson13 (50)
bull The13 supported13 Block213 can13 use13 25613 or13 51213 byte13 blocks
Req13 GET13 coapwwwexampleorgwell-shy‐knownprofile13 Res13 20513 Content13 (applicationjson)13 13 13 13 profile13 13 13 13 13 13 13 13 pathcam13 13 13 13 op[3471112192335]13 13 13 13 13 cf[04050]13 13 13 13 13 b2s[45]13 13 13 13
Filtering13 through13 use13 of13 URI-shy‐Query
bull Filtering13 can13 be13 done13 through13 the13 URI-shy‐Querybull Query13 format13 N=V
ndash N13 is13 a13 profile13 fieldndash V13 is13 the13 desired13 value
bull Examplesndash To13 find13 resources13 that13 support13 content13 format13 ldquoapplicaonjsonrdquo
13 GET13 wwwexampleorgwell-shy‐knownprofilecf=50ndash To13 get13 informaon13 about13 the13 camera
13 GET13 wwwexampleorgwell-shy‐knownprofilepath=cam
Open13 issues
bull Which13 other13 profile13 data13 needs13 signallingndash Content-shy‐type13 for13 different13 methods
bull Fix13 the13 order13 in13 which13 the13 profile13 fields13 must13 appearndash Non-shy‐fixed13 order13 easier13 extensible
bull Inheritance13 of13 a13 profile13 descriponbull Extend13 usage13 to13 signal13 the13 client13 profilebull Integraon13 with13 link13 format
Thank13 youQuesons
drar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval-shy‐00
Bert13 Greevenbosch
Descripon
bull The13 ldquoMinimumRequestInterval13 opon13 can13 be13 used13 to13 indicate13 the13 minimum13 me13 between13 two13 requests13 in13 a13 transacon
bull Originally13 intended13 for13 Block13 but13 also13 usable13 for13 other13 transaconsndash Example13 browsing13 a13 server
bull The13 goal13 is13 to13 reduce13 the13 server13 load13 and13 network13 traffic
bull Link13 hqpsdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval
Usage
bull The13 client13 keeps13 the13 server13 informed13 about13 its13 request13 speed13 through13 inclusion13 of13 the13 ldquoMinimumRequestIntervalrdquo13 opon
bull In13 responses13 the13 server13 fixes13 the13 minimum13 request13 interval13 through13 the13 same13 opon
bull The13 client13 obeys13 the13 speed13 indicated13 by13 the13 server
bull The13 client13 can13 send13 slower13 but13 not13 faster
Advantages
bull The13 server13 has13 means13 to13 limit13 the13 amount13 of13 incoming13 traffic
bull The13 server13 can13 prevent13 to13 become13 overloaded13 with13 too13 many13 tasks
bull The13 server13 does13 not13 need13 arficially13 slow13 down13 the13 client13 by13 sending13 late13 ACKsndash No13 need13 to13 keep13 track13 of13 delayed13 ACKsndash The13 server13 can13 perform13 other13 tasks13 instead
bull Reduced13 network13 traffic
Thank13 youQuesons
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-links-json-02txt
123
RFC 6690 (link-format) documents are somewhat foreign to many web app developerssect would prefer to have them in JSON format
There is no standard way to represent link-format documents in applicationssect but everyone knows how to handle JSON
Define a standard JSON translation for link-format
Itrsquos
not
rock
et
scien
ce
ltsensorsgtct=40title=Sensor Index ltsensorstempgtrt=temperature-cif=sensor ltsensorslightgtrt=light-luxif=sensor lthttpwwwexamplecomsensorst123gt anchor=sensorstemprel=describedby lttgtanchor=sensorstemprel=alternate [hrefsensorsct40titleSensor Index hrefsensorstemprttemperature-cifsensor hrefsensorslightrtlight-luxifsensor hrefhttpwwwexamplecomsensorst123 anchorsensorstempreldescribedby hreftanchorsensorstemprelalternate]
124
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-ipsec-for-coap-00txt
IPsec definitions for CoAP Mostly placeholder at this time Who has implementation experience with this
125
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-cross-reverse-convention-00txt
This draft has two lines of payload(based on a WGLC comment by Cullen Jennings)
coap12344567foobara=3
httpwwwproxycomwellknowncore-translate1234_4567foobara=3
Is that a useful convention to have
126
Insert CI slides here
127
128
0
5
10
15
20
25
30
35
40
10 20 30 40 50 60 70
good
put (
pps)
pps
Goodput vs pps (Econotags)
goodput
[Khattak preliminary]
Congestion Control
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-cocoa-00txt
ldquoadvancedrdquo cc (The draft is just a first shot) Others may have better ideas
129
Insert post-WGLC discussion slides here
130
Stop Continue Start
131
An Agile Retrospective
http6lowappnet coreIETF86 2013-03-12-13
Stop
132
Endless new CoAP optionssect instead use RESTful as much as possible
Move general security lifecycle out Looking at theoretical problems
http6lowappnet coreIETF86 2013-03-12-13
Continue
Interops Running code Look at real-world examples and deployments Solve their actual problems
sect Unilateral enhancements eg higher performance congestion control
sect Transports (SMS hellip)sect Make Web linking and Directories more and more usefulsect RESTful Design Paradigms for real-world problems
133
http6lowappnet coreIETF86 2013-03-12-13
Start
Further push into the (browser) web world (HTML5 browser security)
Specific supporting worksect SenMLsect URI work (dev URN hellip)sect Security Processes (next slide)
Spin outsect (We donrsquot really get to decide where this is done)
134
http6lowappnet coreIETF86 2013-03-12-13
Security
Integrate Application Network Group Keyingsect Tunnel-free setup
Donrsquot redo what has been done alreadysect ZigBee IP is finesect But what about other scenarios
Simple REST interfaces for working with keying materials and authorizationsect Start with defining objectives
Object Security for Constrained Nodes135
Re-chartering CoREWhat do we want to do now that wersquore grown up
Zach ShelbyCoRE WG IETF-86 Orlando
What is the scope
bull So we have a protocol and Web Linking what next
bull Keep with what we know besthellip1 Enhancements around CoAP2 New transports for CoAP3 New representations for Web Links4 General application layer solutions
CoRE WG IETF-86 Orlando 2
Enhancements around CoAP
bull Advanced congestion control
CoRE WG IETF-86 Orlando 3
New Transports for CoAP
bull Infrastructure for CoAP over foondash httptoolsietforgiddraft-silverajan-core-
coap-alternative-transports-01txtbull CoAP over SMS
ndash httptoolsietforgiddraft-becker-core-coap-sms-gprs-03txt
ndash OMA Lightweightbull CoAP over TCP
ndash httptoolsietforgiddraft-li-core-coap-payload-length-option-01txt
CoRE WG IETF-86 Orlando 4
New support for Web Links
bull JSON Web Linksndash httptoolsietforgiddraft-bormann-core-links-
json-02txt
2332010 CoRE WG IETF-77 Anaheim 5
General application layer solutions
bull Resource Directoryndash httptoolsietforgiddraft-shelby-core-
resource-directory-05txtndash OMA Lightweight
2332010 CoRE WG IETF-77 Anaheim 6
Group 1a WGLC processingobserve block
9
http6lowappnet coreIETF86 2013-03-12-13
draft-ietf-core-observe-08
10
Changes from ndash07 to ndash08sect Expanded text on transmitting notification while a previous
transmission is pending (242)sect Changed reordering detection to use a fixed time span of 128
seconds instead of EXCHANGE_LIFETIME (276)sect Removed the use of the freshness model to determine if the
client is still on the list of observers
http6lowappnet coreIETF86 2013-03-12-13
draft-ietf-core-block-10
11
Still awaits grand editorial rewritesect right after coap-14 is shipped
http6lowappnet coreIETF86 2013-03-12-13
Tickets
hellip are our way to make the steps forward are at
http toolsietforgwgcore Updates are sent to the mailing list
sect Please review When we close a ticket please review once more
12
Group 2 groupcomm
13
Akbar RahmanEsko Dijk
IETF 86 March 2013httpwwwietforgiddraft-ietf-core-groupcomm-05txt
Group Communication for CoAP
Summary of Changes (14)
n I-D had two updates (Rev 04 amp 05) after IETF-85 (Atlanta) Many of the updates were due to the detailed review by Peter van der Stokn Thank you Peter for your valuable comments
n Changes from ietf-03 to ietf-04 n Section 23 (Potential Solutions for Group Communications) moved to
draft-dijk-core-groupcomm-misc (266)n Added reference to draft-keoh-tls-multicast-security to section 6 (Security
Considerations) n Appendix B (CoAP-Observe Alternative to Group Communications) moved
to draft-dijk-core-groupcomm-misc (267) n Deleted section 8 (Conclusions) as it is redundant (268) n Simplified light switch use case (269) by splitting into basic operations and
additional functions (269)
Summary of Changes (24)
n Changes from ietf-03 to ietf-04 (Continued) n Moved section 37 (CoAP Multicast and HTTP Unicast Interworking) to
draft-dijk-core-groupcomm-misc (270) n Moved section 331 (DNS-SD) and 332 (CoRE Resource Directory) to
draft-dijk-core-groupcomm-miscClarified that DNS based features are optional (272)
n Focus section 35 (Configuring Group Membership) on a single proposed solution
n Scope of section 53 (Use of MLD) widened to multicast destination advertisement methods in general
n Rewrote section 22 (Scope) for improved readibility n Moved use cases that are not adressed to draft-dijk-core-groupcomm-miscn Various editorial updates for improved readibility
Summary of Changes (34)
n Changes from ietf-04 to ietf-05 n Added a new section 39 (Exceptions) that highlights that IP multicast (and
hence group communications) is not always available (187) n Included guidelines on when (not) to use CoAP responses to multicast
requests and when (not) to accept multicast requests (273) n Added guideline on use of core-block for minimizing response size (275)n Restructured section 6 (Security Considerations) to more fully describe
threats and threat mitigation (277) n Clearly indicated that DNS resolution and reverse DNS lookup are optional n Removed confusing text about a single group having multiple IP addresses
If multiple IP addresses are required then multiple groups (with the same members) should be created
n Removed repetitive text about the fact that group communications is not guaranteed
Summary of Changes (44)
n Changes from ietf-04 to ietf-05 (Continued) n Merged previous section 52 (Multicast Routing) into 31 (IP Multicast
Routing Background) and added link to section 52 (Advertising Membership of Multicast Groups)
n Clarified text in section 38 (Congestion Control) regarding precedence of use of IP multicast domains (ie first try to use link-local scope then site-local scope and only use global IP Communication for CoAP multicast as a last resort)
n Extended group resource manipulation guidelines with use of preconfigured portspaths for the multicast group
n Consolidated all text relating to ports in a new section 33 (Port Configuration)
n Clarified that all methods (GETPUTPOST) for configuring group membership in endpoints should be unicast (and not multicast) in section 37 (Configuring Group Membership In Endpoints)
n Various editorial updates for improved readability
Discussion item (11)
n Solution for Configuring Group Membership (no ticket)n Example of (unicast) configuring an endpoint to be part of one multicast
groupReq POST gp (Content-Format applicationjson)
n floor1westbldg6examplecom ip ff154200f7feed3714cb Res 204 Changed
n Where the ldquogprdquo resource has resource type (rt) ldquocoregprdquo which is defined for this purpose
n Question Do we want specify such a solution (or for example leave it completely up to implementation)
Open Issues(15)
n Review Groupcomm requirements language (271)n Decision made to keep requirements language for informational draftn Each use of MAYMUSTSHOULD etc is to be reviewed
Open Issues(25)
n Add section on multicast via Proxy and its limitations (274)n Add a section to explain the issues amp limitations of doing CoAP multicast
requests via a CoAP Proxy n Goal is to warn and guide implementers in this subject n Also such a section would provide a placeholderreminder of the problems
that might be addressed further in the futuren Based on IETF 85 CoRE WG meeting discussion on Multicast CoAP
requests via a Proxy Discussion summary for referencen Aggregation of responses in a proxy is difficult since it doesnt know
when to stop aggregating responses n SIP tried to deal with this problem but didnt solve it n There may be an expectancy of CoAP client to get single response
back from proxy not multiple The client in this case may not even know what it could expect It may not even know the Proxy-URI contains a multicast target
n Presented via-proxy use case exposes gap in the core-coap specification regarding multicast via proxy (Note Expectation is that core-coap wonrsquot address it in the first planned RFC release)
Open Issues(35)
n Issues with twomultiple Resource Directories in use case (280)n Some potential issues with RD came out of review Peter van der Stok and
WG discussion IETF85 n There are two RD servers use case shows that only one is found despite
the fact that site-local multicast is used - should be two RDs found n Proposal simplify use case to a single RD server on the backbone to avoid
such RD-specific issues like synchronization of RD information between servers
Open Issues(45)
n Add single-subnet configuration to use cases (278)n Suggested by review Peter van der Stok and IETF85 WG discussion that
its best to start explaining the simplebasic cases and then gradually build up complexity
n Simplest case not shown yet would be a single subnet network configuration which is currently not present in the I-D only the 2-subnet configuration of Fig 1
n Question Do we need to add such case or doesnt it add muchn (Note that core-coap Figure 22 already shows the simplest case of link-local
multicast)
Open Issues(55)
n Add use case with controller (client) located on the backbone (279)n Suggested by discussion following review Peter van der Stok n Case missing where a controller (client) is located on the backbonen Question Do we need to add such case or does it add much
Group 2a other old friends
25
Angelo Castellani Salvatore Loreto Akbar Rahman Thomas Fossati Esko Dijk
IETF 86 March 2013httpwwwietforgiddraft-castellani-core-http-mapping-07txt
Best Practices for HTTP-CoAP Mapping
Implementation
Summary of Changes (from -06 rev)
n Based on discussion at last IETF-85 (Atlanta)n Clarification of HTTP-CoAP Proxies
n Definitionn Placementn Benefits
n Clarification of HTTP-CoAP URI mapping options
Goals of I-D
n For Reverse HTTP-CoAP Cross Protocol Proxyn Provide more detailed information to proxy designers (beyond
Section 10 of [I-Dietf-core-coap]) to help implement proxies that correctly inter-work with other CoAP and HTTP clientserver implementations that adhere to the specifications
n Define a consistent set of guidelines that a HTTP-to-CoAP proxy implementation MAY adhere to The main reason of adhering to such guidelines is to reduce variation between proxy implementations thereby increasing interoperabilityn As an example use case a proxy conforming to these guidelines made
by vendor A can be easily replaced by a proxy from vendor B that also conforms to the guidelines
I-D Outline
n Guidance on HTTP to CoAP URI mappingn HTTP-CoAP Reverse cross-protocol proxy implementation
n Placementn Response code amp media type translationsn Caching and congestion controln Cache refresh via Observen Use of CoAP blockwise transfern Security translation
n Security Considerationsn Traffic overflown Handling secured exchanges
Definitions (12)
n Cross-Protocol Proxy (or Cross Proxy) is a proxy performing a cross- protocol mapping in the context of this document a HTTP-CoAP (HC) mapping A Cross-Protocol Proxy can behave as a Forward Proxy Reverse Proxy or Interception Proxy n Note In this document we focus on the Reverse Proxy mode of the
Cross-Protocol Proxy
n Forward Proxy a message forwarding agent that is selected by the client usually via local configuration rules to receive requests for some type(s) of absolute URI and to attempt to satisfy those requests via translation to the protocol indicated by the absolute URI The user decides (is willing to) use the proxy as the forwardingdereferencing agent for a predefined subset of the URI space
Definitions (22)
n Reverse Proxy a receiving agent that acts as a layer above some other server(s) and translates the received requests to the underlying servers protocol It behaves as an origin (HTTP) server on its connection towards the (HTTP) client and as a (CoAP) client on its connection towards the (CoAP) origin server The (HTTP) client uses the origin-form [I-Dietf-httpbis-p1-messaging] as a request- target URI
n Reverse and Forward proxies are technically very similar with main differences being that the former appears to a client as an origin server while the latter does not and that clients may be unaware they are communicating with a proxy
Reverse Cross-Protocol Proxy Deployment Scenario
HTTP-CoAP Response Code Mapping
Implementation Experience
n Direct experience from the draft authorsn Squid HTTP-CoAP mapping module
n University of Padovan httptelecomdeiunipditiotn Both Forward and Interception operation supported
n HTTP-CoAP proxy based on EvCoAPn KoanLogic University of Bologna and Salvatore
Loreto (as individual)n httpsgithubcomkoanlogicwebthingstreemasterbridgesw
libevcoapn The document is open to input from other implementations
Next Steps
n Does the WG recommend adoptionn Intended status Informational Best Practicen Purpose Reduce arbitrary variation between proxy
implementations thereby increasing interoperability
Backup
HTTP to CoAP URI Mapping Options (12)
n Embedded Mapping n In an embedded mapping approach the HTTP URI has embedded
inside it the authority and path part of the CoAP URI n Example The CoAP resource nodecoapsomethingnetfoo can
be accessed by an HTTP client by inserting in the request httphc-proxysomethingnetcoapnodecoapsomethingnetfoo The Cross-Protocol Proxy then maps the URI to coapnodecoapsomethingnetfoo
HTTP to CoAP URI Mapping Options (22)
n Homogeneous Mapping n In a homogeneous mapping approach only the scheme portion of the URI
needs to be mapped The rest of the URI (ie authority path etc) remains unchanged
n Example The CoAP resource coapnodecoapsomethingnetfoo can be accessed by an HTTP client by requesting httpnodecoapsomethingnetfoo The Cross-Protocol Proxy receiving the request is responsible to map the URI to coapnodecoapsomethingnetfoo
n Background info n The assumption in this case is that the HTTP client would be able to
successfully resolve nodecoapsomethingnet using DNS infrastructure to return the IP address of the HC proxy Most likely this would be through a two step DNS lookup where the first DNS lookup would resolve somethingnet using public DNS infrastructure
n Then the second DNS lookup on the subdomain coap and the host node would typically be resolved by a DNS server operated by the owner of domain somethingnet So this domain owner can manage its own internal node names and subdomain allocation which would correspond to the CoAP namespace
Group 3 ldquonew workrdquo
39
Transport of CoAP over SMS USSD and GPRSdraft-becker-core-coap-sms-gprs-03
Markus Becker Kepeng LiKoojana Kuladinithi Thomas Poumltsch
CoRE WG IETF-86 Orlando
1 10
ScenariosI In M2M communication IP connectivity is not alwayssupported by the constrained end-points
I Power savingI Coverage (GPRS 3G LTE)
I SMS and USSD based communication is almost alwayssupported
210
Changes from draft-01 to draft-03 (1)
I Added possible CONNONACK interactions Section 5
I Option name changed from Reply-To- to Response-To-Section 16 and Section 101
I Added URI schemeEg coap+tel+15105550101well-knowncore Section 11
I Added possible M2M proxy scenarios Section 14
3 10
Changes from draft-01 to draft-03 (2)
I Added reference to bormann-coap-misc for other SMSencoding Section 71
I Updated requirements on Uri-Host and Uri-Port forcoap+tel Section 10
I Added security considerations Transport and ObjectSecurity Section 15
I Chose CoAP option numbers and updated the optionnumber table to meet draft-ietf-core-coap-10 Table 1
I Added an IANA registration for the URI scheme coap+telSection 162
4 10
Feedback Split coap+tel into coap+smsand coap+ussd
I How else to differ the various transports in the URII Or is the transport to use decided by the implementationI See alsodraft-silverajan-core-coap-alternative-transports-01
5 10
Feedback Response-To-Scheme option
I Should there be a Response-To-Scheme optionadditionally to Response-To-Uri-Host andResponse-To-Uri-Path
I So that a CoAP end-point which receives a request by CoAPover non-IP transport can be instructed to also use thenon-IP transport for the response
I This would imply to add aResponse-To-Telephone-Subscriber and more options forother transports that have other URI schemes than coapand coaps
6 10
Feedback Selection of Transport by Client
I When a server is reachable by various transports howdoes a client decide which transport to use
I Client-side application congurationI Leave it to a proxy which uses cellular network lookupfunctions
7 10
Feedback Potential Threats
I Trigger expensive short messagesI Redirect trac to other addressesI More threats
I Are the security measures in the draft adequateI Whitelisting on serverI Relying on cellular network security (dedicated M2M APNs)I Object security on CoAP payload
8 10
Feedback Message Exchanges
I Figures 11-18 show possible message exchanges whenclient and server have two addresses
I With NON Not using CoAP retransmission capabilityI ACK on different transportI Additional (costly) message on Transport AI Request with Content
I Which ones are allowedI Which ones are meaningful
9 10
Next steps
I Rene Uri schemeI Response-To-Scheme optionI Selection of Message ExchangeI Rene Proxying
10 10
CoAP13 Communicaon13 with13 Alternave13 Transports
Bill Silverajan and Teemu SavolainenCore WG IETF 86 Orlando
031113
Objecves13 (In13 Scope)
bull Unambiguous13 representaon13 of13 transport13 to13 be13 used13 by13 CoAP
bull Details13 how13 the13 transport13 can13 carry13 CoAP13 packet
bull Focus13 is13 on13 what13 CoAP13 communicaons13 requirements13 are
bull Allow13 CoAP13 mechanisms13 to13 exploit13 cross-shy‐layer13 opmisaons
51
031113
Non13 Goals13 (Not13 in13 scope)
bull Applicaon-shy‐level13 QoS13 requirementsbull Real-shy‐me13 constraintsbull Ordering13 reliability13 congeson13 controlbull Applicaon13 and13 network13 adaptaonbull Mobility13 and13 readdressing13 supportbull Network13 protocol13 (eg13 IPsec)13 configuraon
52
031113
Use13 Cases
bull NAT13 and13 Firewall13 traversal13 with13 TCPbull Delay13 Tolerant13 Networkingbull Non-shy‐IP13 Low13 Energy13 Protocols
53
031113
Related13 Work
bull OMA13 Lightweight13 M2M13 Protocolbull CoAP13 over13 SMSGPRSUSSD
54
031113
What13 does13 the13 work13 entail
bull The13 ability13 to13 specify13 end13 point13 idenfiers13 and13 URIs13 to13 reflect13 which13 transport13 CoAP13 can13 use
bull The13 ability13 to13 register13 to13 resource13 directories13 resource13 types13 reflecng13 types13 of13 transport13 available
bull Ability13 for13 mul-shy‐transport13 nodes13 to13 select13 transport13 to13 use13 without13 significant13 alteraon13 to13 CoAP13 packet13 structure
55
031113
Points13 to13 consider
bull Requirements13 for13 transport13 layer13 protocol13 to13 carry13 CoAP13 packets
bull Representaon13 of13 URI13 scheme13 for13 generic13 transport13 protocols
bull Opon13 extensions13 for13 CoAP13 to13 express13 available13 transports
bull Mapping13 and13 message13 sizebull Security13 consideraons
56
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
URI13 =13 scheme13 13 13 authority13 path-shy‐abempty13 [13 query13 ]
bull Within13 the13 scheme13 namebull In13 the13 URI13 pathbull As13 a13 query13 component
57
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
bull Within13 the13 scheme13 namendash coap+tel+15105550101well-shy‐knowncorendash coap+tcpexamplecom5683temperaturendash coap+blel2cap[1234567890AB]4pulse
bull Easy13 URI13 parsing13 for13 transport13 type13 and13 idenfier
bull Each13 new13 scheme13 name13 requires13 IANA13 registraon
58
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
bull In13 the13 URI13 pathndash coaphostexamplecomtransport=tcpwell-shy‐knowncorert=core-shy‐rd
bull Easy13 adopon13 of13 new13 (and13 experimental)13 CoAP13 transports13 without13 IANA13 registraon
bull Caveat13 Uri-shy‐Path13 opon13 is13 a13 Crical13 CoAP13 opon13 see13 secon13 54113 of13 I-shy‐Diep-shy‐core-shy‐coap
59
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
bull As13 a13 URI13 query13 componentndash coaphostexamplecomwell-shy‐knowncorert=core-shy‐rdq=tcp
bull Also13 easy13 to13 adopt13 new13 (and13 experimental)13 CoAP13 transports13 without13 IANA13 registraon
bull Caveat13 Uri-shy‐Query13 opon13 is13 a13 Crical13 CoAP13 opon13 see13 secon13 54113 of13 I-shy‐Diep-shy‐core-shy‐coap
60
031113
URI13 Representaons13 for13 CoAPNon13 standard13 ways
bull Transport13 in13 the13 URI13 authority13 componentndash coaphost[port][transport]13 instead13 of13 coaphost[port]
bull Transport13 as13 a13 service13 URLndash servicecoaptcphostexamplecomwell-shy‐knowncorert=core-shy‐rd
bull Above13 two13 ways13 break13 exisng13 compability13 (although13 both13 are13 based13 on13 valid13 IANA13 URI13 registraons)
61
031113
URI13 Representaons13 for13 CoAPMiscellaneous13 Consideraons
bull Ensure13 that13 transport13 is13 defined13 unambiguously13 (eg13 L2CAP13 used13 by13 both13 BLE13 and13 standard13 Bluetooth13 so13 avoid13 rdquocoap+l2caprdquo13 or13 rdquotransport=l2caprdquo13 or13 rdquoq=l2caprdquondash Can13 be13 done13 as13 WG13 consensusndash Namespace13 approach13 eg13 rdquocoap+blel2caprdquo13 or13 rdquoq=blel2caprdquo
bull Allow13 end-shy‐points13 to13 use13 CoAP13 Resource13 Directory13 to13 register13 alternave13 transports13 and13 idenfiers13 and13 provide13 periodic13 updatesndash Register13 rdquocore-shy‐transportrdquo13 resource13 type
62
031113
Transport13 Consideraons
bull Uniqueness13 of13 end-shy‐point13 idenficaonbull Communicaon13 support13 Unidireconal13 Bidireconal13 1N13 (broadcast13 mulcast13 anycast)13 messaging
bull Binary13 encoding13 Network13 byte13 orderingbull MTU13 correlaon13 with13 CoAP13 PDU13 sizebull Transport13 latency
63
031113
Security13 Consideraons
bull Drar13 does13 not13 introduce13 new13 security13 requirements13 by13 itself
bull There13 may13 be13 privacy13 issues13 if13 nodes13 use13 telephone13 numbers13 or13 MAC13 addresses13 as13 public13 end13 point13 idenfiers
64
Akbar Rahman
IETF 86 March 2013 httpwwwietforgiddraft-rahman-core-sleepy-02txt
Enhanced Sleepy Node Support for CoAP
Introduction
It is expected that in CoAP networks there will be a certain portion of devices that are sleepy and which may occasionally go into a sleep mode (ie go into a low power state to conserve power) and subsequently have reduced CoAP protocol communication ability
This I-D proposes a minimal and efficient mechanism building on the Resource Directory concept (which will be integrated into a CoAP Proxy) to enhance sleepy node support in CoAP networks
Main Question from IETF-85 (Atlanta)
What performance benefit does the proposed Sleepy Node support solution give in a network that already has standard CoAP caching enabled
Sleepy Node Performance Analysis
Experimental Network
1-5 clients
Both Sleepy and Non-
Sleepy servers
Sleepy Node Performance Analysis Network Setup
CoAPSleepyServer(s)
CoAPSleepAwareReverseProxy
CoAP
Client(s)
Request
Response
Sleep9AwareCoREResourceDirectoryCapability
PublishedSleepParameters
Sleep9AwareCoAPStoreandForwardCapability Response
Request
SleepAwareCoAP503ResponseCapability
CoAPCachingCapability
bull Server supports publishing sleep parameters to proxy bull Eg Irsquom going to be asleep for X seconds
bull Proxy supports sleep-awareness capabilities bull Proxy also supports caching capability based off of maxAge bull Protocol flow similar to approach of Figure 1 (Synchronous RD Based Sleep
Tracking) of I-D
Proxy capabilities can be selectively enableddisabled
Proxy ndash Server Interface
Client ndash Proxy Interface
CoAP Sleep-Aware Reverse Proxy Features CoRE Sleep-aware Resource Directory
Support storing published sleep parameters from CoAP servers sleepState (AWAKE ASLEEP) sleepDuration
Sleep-aware CoAP 503 Response Capability If CoAP request to a sleeping server is received proxy returns a
lsquo503 Retry-Afterrsquo response to client 503 contains a timestamp indicating when the sever will wake back up
(timestamp delivered in CoAP maxAge option) Sleep-aware CoAP Store-and-Forward Capability
If CoAP request to a sleeping server is received proxy stores request until server wakes up and then forwards it
Caching capability Cache GET responses from server if maxAge option is present
(this is not a sleep aware feature)
Goals of Performance Analysis
For networks having sleepy servers provide measurements to quantify the impact that CoAP sleep-awareness capabilities can have
See if sleep-awareness capabilities can
provide additional benefits even when CoAP caching is used
Overview of Performance Analysis Performed The analysis was broken up into a set of test scenarios Each test scenario used a different combination of the following
variables Client issued GET requests Server was configured as a sleepy or non-sleepy server Proxy caching of GET responses was enabled or disabled Proxy sleep-aware 503 response capability was enabled or disabled Proxy store-and-forward capability was enabled or disabled maxAge in GET responses ndash Two values were tested 60sec and 5sec of Clients ndash Two values were used ndash 1 client and 5 clients
For comparison purposes the following were held constant across all test scenarios Client issued a fixed number of requests (100) across all test scenarios Client used a delay between each GET request (35sec) to better exercise
proxyrsquos caching and sleep-awareness capabilities For sleepy server test scenarios the server slept 60 sec awake for 3 sec
Format of Results The following results were collected for each
test scenario
Breakdown of the and types of transactions occurring between clientproxyserver
ldquoGETrdquo ndash Test Scenario Results
GET ndash Description of Test Scenarios
TestScenarios-GET
Scenario
CoAPSleepyServerSe7ngs CoAPSleepAwareReverseProxySe7ngs CoAPClientSe7ngs
SleepDuragton(sec)
AwakeDuragton(sec)
maxAge(sec) Caching SleepAwareSAF+
503NumberofClients
NumberofGETs
DelayBetweenClient
Requests(sec)
1a 0 Always 60 Enabled Disabled 1 100 35
1b 60 3 60 Enabled Disabled 1 100 35
1c 60 3 60 Enabled Enabled 1 100 35
2a 0 Always 60 Enabled Disabled 5 100 35
2b 60 3 60 Enabled Disabled 5 100 35
2c 60 3 60 Enabled Enabled 5 100 35
3a 0 Always 5 Enabled Disabled 5 100 35
3b 60 3 5 Enabled Disabled 5 100 35
3c 60 3 5 Enabled Enabled 5 100 35
ldquoGETrdquo ndash Test Scenario 1 Results
maxAge = 60 and 1 Client
GET ndash Scenario 1 ClientProxy Interface Transaction Mix
Scenarios 1a - Non-Sleepy Server Caching Proxy maxAge = 60sec 1b- Sleepy Server Caching Proxy maxAge = 60sec 1c - Sleepy Server Sleep Aware Proxy maxAge = 60sec
Sleep Aware Proxy has better performance for sleepy servers
0
100
200
300
400
500
600
700
1a 1b 1c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
GET ndash Scenario 1 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
Scenarios 1a - Non-Sleepy Server Caching Proxy maxAge = 60sec 1b- Sleepy Server Caching Proxy maxAge = 60sec 1c - Sleepy Server Sleep Aware Proxy maxAge = 60sec
0
100
200
300
400
500
600
700
800
1a 1b 1c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
ldquoGETrdquo ndash Test Scenario 2 Results
maxAge = 60 and 5 Clients
GET ndash Scenario 2 ClientProxy Interface Transaction Mix
Sleep Aware Proxy has slightly better performance for sleepy servers
0
200
400
600
800
1000
1200
1400
2a 2b 2c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
Scenarios 2a - Non-Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2b- Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2c - Sleepy Server Sleep Aware Proxy maxAge = 60sec 5 Clients
See ldquoExperimental Artifactsrdquo Note 1
GET ndash Scenario 2 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has slightly better performance for sleepy servers
0
50
100
150
200
250
300
350
400
2a 2b 2c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
Scenarios 2a - Non-Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2b- Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2c - Sleepy Server Sleep Aware Proxy maxAge = 60sec 5 Clients
See ldquoExperimental Artifactsrdquo Note 2
Experimental Artifacts Note 1
Currently in the experiment the sleep aware proxy checks the cached state of a resource before putting a request into its Store-and-forward queue while a server is sleeping Once in the queue the proxy unconditionally forwards the queued requests to the server once it wakes up This is not the most efficient setup and can easily be improved If the proxy instead checks its cache again before forwarding each queued request it may not need to forward the request to the server For example if there are two queued GET requests in the proxyrsquos queue that address the same resource Only the first request needs to be sent to the server the second request can use the cached response from the first request
Note 2 Currently in the experiment the sleepy server sends a sleepState PUT request to the
proxy each time it goes to sleep This is not the most efficient setup and can easily be improved For example if the server assumes that the proxy can keep track of its ONOFF cycles with its internal timers (eg as per Fig 1 of I-D) then the number of messages from the sleepy server dramatically goes down
ldquoGETrdquo ndash Test Scenario 3 Results
maxAge = 5 and 5 Clients
GET ndash Scenario 3 ClientProxy Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
Scenarios 3a - Non-Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3b- Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3c - Sleepy Server Sleep Aware Proxy maxAge = 5sec 5 Clients
0
500
1000
1500
2000
2500
3000
3500
4000
4500
5000
3a 3b 3c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
GET ndash Scenario 3 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
0
1000
2000
3000
4000
5000
6000
7000
3a 3b 3c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
Scenarios 3a - Non-Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3b- Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3c - Sleepy Server Sleep Aware Proxy maxAge = 5sec 5 Clients
Conclusions
Conclusions These results show that sleep-aware CoAP
proxy features can significantly optimize communication with sleepy servers in most scenarios
These results also show that sleep-
awareness capabilities can provide additional benefits above and beyond CoAP caching in most scenarios
Backup
Current CoAP Support of Sleepy Node (12)
CoAP proxies can use a previously cached response to service a new GET request for a sleepy origin server (as in HTTP) But if no valid cache then proxy has to attempt to
retrieve and may fail if origin server is sleeping [I-Dietf-core-coap]
Clients can discover list of resources from RD (GET rd-lookuphellip) for sleepy servers But attempt to GET resource from sleepy origin server
may fail if origin server is sleeping [IDietf-core-link-format amp IDshelby-core-resource-
directory]
Current CoAP Support of Sleepy Node (22)
Lower layer support for sleepy nodes in most wireless technologies (eg WiFi ZigBee) But limited to MAC packet scheduling for sleepy nodes
and not aware of specific needs of IP applications (like CoAP)
Proposal ndash RD Based Sleep Tracking (14)
The current CoAP approach to support sleepy nodes can be significantly improved by introducing RD based mechanisms for a CoAP client to determine whether A targeted resource is located on a sleepy server A sleepy server is currently in sleep mode or not
There is any associated caching Proxy (possibly the RD itself) for a sleepy server
Proposal ndash RD Based Sleep Tracking (24)
We define the following new RD attributes to characterize the properties of a sleepy node SleepState - Indicates whether the node is currently in
sleep mode or not (ie Sleeping or Awake) SleepDuration - Indicates the maximum duration of time
that the node stays in sleep mode TimeSleeping - Indicates the length of time the node
has been sleeping (ie if Sleep State = Sleeping) NextSleep - Indicates the next time the node will go to
sleep (ie if Sleep State = Awake)
CachingProxy ndash Indicates the caching proxy of the sleepy node (ie the RD itself or another node)
Proposal ndash RD Based Sleep Tracking (34)
These attributes are all server (node) level and are new parameters added to the RD URI Template Variables
Finally we also define a new lookup-type (ss) for the RD lookup interface specified in [I-Dshelby-core-resource-directory] This new lookup-type supports looking up the
ldquoSleepStaterdquo (ss) of a specified end-point
Proposal ndash RD Based Sleep Tracking (44)
The three time based parameters (SleepDuration TimeSleeping NextSleep) can be based on either an absolute network time (for a time synchronized network) or a relative local time (measured at the local node)
Following the approach of [I-Dietf-core-link-format] and [I-Dshelby-core-resource-directory] sleep parameters for sleepy servers can be stored by the server in the RD and accessed by all interested clients
Examples of using these parameters in a synchronous or asynchronous manner are shown in the I-D
http6lowappnet coreIETF86 2013-03-12-13
We assume people have read the drafts
Meetings serve to advance difficult issues by making good use of face-to-face communications
Note Well Be aware of the IPR principles according to RFC 3979 and its updates
uumlBlue sheetsuumlScribe(s)
96
drar-shy‐iep-shy‐core-shy‐coapsubmiqed13 to13 IESG
2013-shy‐03-shy‐13
97
OMA Lightweight M2M Overview(A new standard using lots of IETF specs including DTLS
CoAP Block Observe Resource Directory SenMLhellip)
Zach ShelbyCoRE WG IETF-86 Orlando
OMA Lightweight M2Mbull Open Mobile Alliance is well known for Device Management (DM)bull OMA Lightweight M2M is a new standard from the alliance
ndash Focused on constrained Cellular and sensor network M2M devicesndash Driven by leading operators and vendors
bull Scopendash Interfaces protocol amp security between Device and Serverndash Object and Resource modelndash Bootstrap Device Access Control Connectivity and Firmware Objects
bull Draft Specifications are availablendash httpmemberopenmobileallianceorgftpPublic_documentsDM
LightweightM2MPermanent_documentsOMA-TS-LightweightM2M-V1_0_0-20130301-Dzip
bull Timelinendash Requirements and Architecture completed 3Q2012ndash Spec ready for Consistency Review 2Q2013ndash Candidate Approval expected 3Q2013
2 CoRE WG IETF-86 Orlando
Architecture
3
Scope of LWM2M
CoRE WG IETF-86 Orlando
Object Model
bull A Client has one or more Object Instancesbull An Object is a collection of Resourcesbull A Resource is an atomic piece of information
ndash Read Written or Executed
bull Resources can have multiple instancesbull Objects and Resources are identified by a
16-bit Integer Instances by an 8-bit Integerbull ObjectsResources are accessed with
simple URIs Object IDObject InstanceResource ID
eg 1213
4 CoRE WG IETF-86 Orlando
CoRE WG IETF-86 Orlando
CoRE Resource Directory
draft-shelby-core-resource-directory-05
Z Shelby C Bormann S Krco
Backgroundbull Not a new concept
ndash think web search engine or any link directorybull Defines the interfaces to a Resource Directorybull Based on Web Linking framework and the CoRE Link Formatbull Generic REST design for use over HTTP and CoAPbull Used by OMA Lightweight M2Mbull Has already been deployed
ndash In traffic monitoring systemsndash In street lighting systemsndash For vehicular asset trackingndash By a major Cellular M2M operator
Changes since -04
bull Restricted Update to parameter updatesbull Added pagination support for the Lookup interfacebull Changed rt= to et= for the registration amp update
interfacebull Added group support
Group Management
bull RD now includes group management featuresbull New Group Function Set
ndash Register a groupbull Group name domain multicast address endpoint members
ndash Remove a groupbull Group lookup using the Lookup Function Set
ndash List registered groupsndash Find the members of a groupndash Find groups with certain endpoints or resources
Registering a Group
EP RD
| |
| - POST rd-groupgp=lights ltgtep=node1 --gt |
| |
| |
| lt---- 201 Created Location rd-group12 ---- |
| |
Req POST coaprdexamplecomrd-groupgp=lights
Payload
ltgtep=node1
ltgtep=node2
Res 201 Created
Location rd-group12
Looking up Group Members
Client RD
| |
| ----- GET rd-lookupepgp=lights1 ----------------------gt |
| |
| |
| lt-- 205 Content ltrdgtd=domain1ltrdgtd=domain2 --------- |
| |
Req GET rd-lookupepgp=lights1
Res 205 Content
ltcoaphostportgtep=node1
ltcoaphostportgtep=node2rdquo
Things for the futurebull Support for JSON representation of Web Links
ndash httptoolsietforgiddraft-bormann-core-links-json-02txtbull Registry for RD registration query parameters
ndash Already OMA Lightweight has defined some new onesbull More examples
Group 3 ldquonew workrdquo(continued)
109
drar-shy‐greevenbosch-shy‐core-shy‐profile-shy‐descripon-shy‐01Bert13 GreevenboschJeroen13 Hoebeke
Isam13 IshaqFloris13 Van13 den13 Abeele
Descripon
bull JSON13 format13 for13 signalling13 the13 servers13 capabilies
bull Signalling13 of13 supported13 opons13 media13 types13 and13 block13 sizendash Other13 items13 can13 be13 added
bull Filtering13 on13 specific13 fields13 through13 URI-shy‐Querybull Link13 hqpdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐profile-shy‐descripon
well-shy‐knownprofile
bull To13 acquire13 profile13 data13 of13 resources13 on13 a13 parcular13 service13 the13 well-shy‐knownprofile13 URI-shy‐path13 is13 introduced
bull For13 example13 to13 get13 all13 informaon13 from13 sensors13 served13 by13 wwwexampleorg13 we13 can13 do13 a13 GET13 to13 coapwwwexampleorgwell-shy‐knownprofile
bull Filtering13 on13 parcular13 resources13 is13 done13 through13 URI-shy‐Queries
Format
bull Currently13 the13 following13 fields13 are13 definedndash ldquopathrdquo13 contains13 the13 URI-shy‐path13 associated13 with13 a13 resource
ndash ldquooprdquo13 a13 numerical13 list13 of13 supported13 opon13 numbers
ndash ldquocfrdquo13 a13 numerical13 list13 of13 supported13 content-shy‐format13 numbers
ndash ldquob1srdquo13 ldquob2srdquo13 supported13 block13 sizes13 for13 Block113 and13 Block213 respecvely
Examplebull On13 the13 right13 is13 an13 example13 of13 a13 camera13 sensor13 at13 coapwwwexampleorgcam13 that13 supports13 the13 Uri-shy‐Host13 (3)13 ETag13 (4)13 Uri-shy‐Port13 (7)13 Uri-shy‐Path13 (11)13 Content-shy‐Format13 (12)13 Token13 (19)13 Block213 (23)13 and13 Proxy-shy‐Uri13 (35)13 opons
bull The13 supported13 content13 formats13 are13 textplain13 (0)13 applicaon13 link-shy‐format13 (40)13 and13 applicaonjson13 (50)
bull The13 supported13 Block213 can13 use13 25613 or13 51213 byte13 blocks
Req13 GET13 coapwwwexampleorgwell-shy‐knownprofile13 Res13 20513 Content13 (applicationjson)13 13 13 13 profile13 13 13 13 13 13 13 13 pathcam13 13 13 13 op[3471112192335]13 13 13 13 13 cf[04050]13 13 13 13 13 b2s[45]13 13 13 13
Filtering13 through13 use13 of13 URI-shy‐Query
bull Filtering13 can13 be13 done13 through13 the13 URI-shy‐Querybull Query13 format13 N=V
ndash N13 is13 a13 profile13 fieldndash V13 is13 the13 desired13 value
bull Examplesndash To13 find13 resources13 that13 support13 content13 format13 ldquoapplicaonjsonrdquo
13 GET13 wwwexampleorgwell-shy‐knownprofilecf=50ndash To13 get13 informaon13 about13 the13 camera
13 GET13 wwwexampleorgwell-shy‐knownprofilepath=cam
Open13 issues
bull Which13 other13 profile13 data13 needs13 signallingndash Content-shy‐type13 for13 different13 methods
bull Fix13 the13 order13 in13 which13 the13 profile13 fields13 must13 appearndash Non-shy‐fixed13 order13 easier13 extensible
bull Inheritance13 of13 a13 profile13 descriponbull Extend13 usage13 to13 signal13 the13 client13 profilebull Integraon13 with13 link13 format
Thank13 youQuesons
drar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval-shy‐00
Bert13 Greevenbosch
Descripon
bull The13 ldquoMinimumRequestInterval13 opon13 can13 be13 used13 to13 indicate13 the13 minimum13 me13 between13 two13 requests13 in13 a13 transacon
bull Originally13 intended13 for13 Block13 but13 also13 usable13 for13 other13 transaconsndash Example13 browsing13 a13 server
bull The13 goal13 is13 to13 reduce13 the13 server13 load13 and13 network13 traffic
bull Link13 hqpsdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval
Usage
bull The13 client13 keeps13 the13 server13 informed13 about13 its13 request13 speed13 through13 inclusion13 of13 the13 ldquoMinimumRequestIntervalrdquo13 opon
bull In13 responses13 the13 server13 fixes13 the13 minimum13 request13 interval13 through13 the13 same13 opon
bull The13 client13 obeys13 the13 speed13 indicated13 by13 the13 server
bull The13 client13 can13 send13 slower13 but13 not13 faster
Advantages
bull The13 server13 has13 means13 to13 limit13 the13 amount13 of13 incoming13 traffic
bull The13 server13 can13 prevent13 to13 become13 overloaded13 with13 too13 many13 tasks
bull The13 server13 does13 not13 need13 arficially13 slow13 down13 the13 client13 by13 sending13 late13 ACKsndash No13 need13 to13 keep13 track13 of13 delayed13 ACKsndash The13 server13 can13 perform13 other13 tasks13 instead
bull Reduced13 network13 traffic
Thank13 youQuesons
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-links-json-02txt
123
RFC 6690 (link-format) documents are somewhat foreign to many web app developerssect would prefer to have them in JSON format
There is no standard way to represent link-format documents in applicationssect but everyone knows how to handle JSON
Define a standard JSON translation for link-format
Itrsquos
not
rock
et
scien
ce
ltsensorsgtct=40title=Sensor Index ltsensorstempgtrt=temperature-cif=sensor ltsensorslightgtrt=light-luxif=sensor lthttpwwwexamplecomsensorst123gt anchor=sensorstemprel=describedby lttgtanchor=sensorstemprel=alternate [hrefsensorsct40titleSensor Index hrefsensorstemprttemperature-cifsensor hrefsensorslightrtlight-luxifsensor hrefhttpwwwexamplecomsensorst123 anchorsensorstempreldescribedby hreftanchorsensorstemprelalternate]
124
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-ipsec-for-coap-00txt
IPsec definitions for CoAP Mostly placeholder at this time Who has implementation experience with this
125
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-cross-reverse-convention-00txt
This draft has two lines of payload(based on a WGLC comment by Cullen Jennings)
coap12344567foobara=3
httpwwwproxycomwellknowncore-translate1234_4567foobara=3
Is that a useful convention to have
126
Insert CI slides here
127
128
0
5
10
15
20
25
30
35
40
10 20 30 40 50 60 70
good
put (
pps)
pps
Goodput vs pps (Econotags)
goodput
[Khattak preliminary]
Congestion Control
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-cocoa-00txt
ldquoadvancedrdquo cc (The draft is just a first shot) Others may have better ideas
129
Insert post-WGLC discussion slides here
130
Stop Continue Start
131
An Agile Retrospective
http6lowappnet coreIETF86 2013-03-12-13
Stop
132
Endless new CoAP optionssect instead use RESTful as much as possible
Move general security lifecycle out Looking at theoretical problems
http6lowappnet coreIETF86 2013-03-12-13
Continue
Interops Running code Look at real-world examples and deployments Solve their actual problems
sect Unilateral enhancements eg higher performance congestion control
sect Transports (SMS hellip)sect Make Web linking and Directories more and more usefulsect RESTful Design Paradigms for real-world problems
133
http6lowappnet coreIETF86 2013-03-12-13
Start
Further push into the (browser) web world (HTML5 browser security)
Specific supporting worksect SenMLsect URI work (dev URN hellip)sect Security Processes (next slide)
Spin outsect (We donrsquot really get to decide where this is done)
134
http6lowappnet coreIETF86 2013-03-12-13
Security
Integrate Application Network Group Keyingsect Tunnel-free setup
Donrsquot redo what has been done alreadysect ZigBee IP is finesect But what about other scenarios
Simple REST interfaces for working with keying materials and authorizationsect Start with defining objectives
Object Security for Constrained Nodes135
Re-chartering CoREWhat do we want to do now that wersquore grown up
Zach ShelbyCoRE WG IETF-86 Orlando
What is the scope
bull So we have a protocol and Web Linking what next
bull Keep with what we know besthellip1 Enhancements around CoAP2 New transports for CoAP3 New representations for Web Links4 General application layer solutions
CoRE WG IETF-86 Orlando 2
Enhancements around CoAP
bull Advanced congestion control
CoRE WG IETF-86 Orlando 3
New Transports for CoAP
bull Infrastructure for CoAP over foondash httptoolsietforgiddraft-silverajan-core-
coap-alternative-transports-01txtbull CoAP over SMS
ndash httptoolsietforgiddraft-becker-core-coap-sms-gprs-03txt
ndash OMA Lightweightbull CoAP over TCP
ndash httptoolsietforgiddraft-li-core-coap-payload-length-option-01txt
CoRE WG IETF-86 Orlando 4
New support for Web Links
bull JSON Web Linksndash httptoolsietforgiddraft-bormann-core-links-
json-02txt
2332010 CoRE WG IETF-77 Anaheim 5
General application layer solutions
bull Resource Directoryndash httptoolsietforgiddraft-shelby-core-
resource-directory-05txtndash OMA Lightweight
2332010 CoRE WG IETF-77 Anaheim 6
http6lowappnet coreIETF86 2013-03-12-13
draft-ietf-core-observe-08
10
Changes from ndash07 to ndash08sect Expanded text on transmitting notification while a previous
transmission is pending (242)sect Changed reordering detection to use a fixed time span of 128
seconds instead of EXCHANGE_LIFETIME (276)sect Removed the use of the freshness model to determine if the
client is still on the list of observers
http6lowappnet coreIETF86 2013-03-12-13
draft-ietf-core-block-10
11
Still awaits grand editorial rewritesect right after coap-14 is shipped
http6lowappnet coreIETF86 2013-03-12-13
Tickets
hellip are our way to make the steps forward are at
http toolsietforgwgcore Updates are sent to the mailing list
sect Please review When we close a ticket please review once more
12
Group 2 groupcomm
13
Akbar RahmanEsko Dijk
IETF 86 March 2013httpwwwietforgiddraft-ietf-core-groupcomm-05txt
Group Communication for CoAP
Summary of Changes (14)
n I-D had two updates (Rev 04 amp 05) after IETF-85 (Atlanta) Many of the updates were due to the detailed review by Peter van der Stokn Thank you Peter for your valuable comments
n Changes from ietf-03 to ietf-04 n Section 23 (Potential Solutions for Group Communications) moved to
draft-dijk-core-groupcomm-misc (266)n Added reference to draft-keoh-tls-multicast-security to section 6 (Security
Considerations) n Appendix B (CoAP-Observe Alternative to Group Communications) moved
to draft-dijk-core-groupcomm-misc (267) n Deleted section 8 (Conclusions) as it is redundant (268) n Simplified light switch use case (269) by splitting into basic operations and
additional functions (269)
Summary of Changes (24)
n Changes from ietf-03 to ietf-04 (Continued) n Moved section 37 (CoAP Multicast and HTTP Unicast Interworking) to
draft-dijk-core-groupcomm-misc (270) n Moved section 331 (DNS-SD) and 332 (CoRE Resource Directory) to
draft-dijk-core-groupcomm-miscClarified that DNS based features are optional (272)
n Focus section 35 (Configuring Group Membership) on a single proposed solution
n Scope of section 53 (Use of MLD) widened to multicast destination advertisement methods in general
n Rewrote section 22 (Scope) for improved readibility n Moved use cases that are not adressed to draft-dijk-core-groupcomm-miscn Various editorial updates for improved readibility
Summary of Changes (34)
n Changes from ietf-04 to ietf-05 n Added a new section 39 (Exceptions) that highlights that IP multicast (and
hence group communications) is not always available (187) n Included guidelines on when (not) to use CoAP responses to multicast
requests and when (not) to accept multicast requests (273) n Added guideline on use of core-block for minimizing response size (275)n Restructured section 6 (Security Considerations) to more fully describe
threats and threat mitigation (277) n Clearly indicated that DNS resolution and reverse DNS lookup are optional n Removed confusing text about a single group having multiple IP addresses
If multiple IP addresses are required then multiple groups (with the same members) should be created
n Removed repetitive text about the fact that group communications is not guaranteed
Summary of Changes (44)
n Changes from ietf-04 to ietf-05 (Continued) n Merged previous section 52 (Multicast Routing) into 31 (IP Multicast
Routing Background) and added link to section 52 (Advertising Membership of Multicast Groups)
n Clarified text in section 38 (Congestion Control) regarding precedence of use of IP multicast domains (ie first try to use link-local scope then site-local scope and only use global IP Communication for CoAP multicast as a last resort)
n Extended group resource manipulation guidelines with use of preconfigured portspaths for the multicast group
n Consolidated all text relating to ports in a new section 33 (Port Configuration)
n Clarified that all methods (GETPUTPOST) for configuring group membership in endpoints should be unicast (and not multicast) in section 37 (Configuring Group Membership In Endpoints)
n Various editorial updates for improved readability
Discussion item (11)
n Solution for Configuring Group Membership (no ticket)n Example of (unicast) configuring an endpoint to be part of one multicast
groupReq POST gp (Content-Format applicationjson)
n floor1westbldg6examplecom ip ff154200f7feed3714cb Res 204 Changed
n Where the ldquogprdquo resource has resource type (rt) ldquocoregprdquo which is defined for this purpose
n Question Do we want specify such a solution (or for example leave it completely up to implementation)
Open Issues(15)
n Review Groupcomm requirements language (271)n Decision made to keep requirements language for informational draftn Each use of MAYMUSTSHOULD etc is to be reviewed
Open Issues(25)
n Add section on multicast via Proxy and its limitations (274)n Add a section to explain the issues amp limitations of doing CoAP multicast
requests via a CoAP Proxy n Goal is to warn and guide implementers in this subject n Also such a section would provide a placeholderreminder of the problems
that might be addressed further in the futuren Based on IETF 85 CoRE WG meeting discussion on Multicast CoAP
requests via a Proxy Discussion summary for referencen Aggregation of responses in a proxy is difficult since it doesnt know
when to stop aggregating responses n SIP tried to deal with this problem but didnt solve it n There may be an expectancy of CoAP client to get single response
back from proxy not multiple The client in this case may not even know what it could expect It may not even know the Proxy-URI contains a multicast target
n Presented via-proxy use case exposes gap in the core-coap specification regarding multicast via proxy (Note Expectation is that core-coap wonrsquot address it in the first planned RFC release)
Open Issues(35)
n Issues with twomultiple Resource Directories in use case (280)n Some potential issues with RD came out of review Peter van der Stok and
WG discussion IETF85 n There are two RD servers use case shows that only one is found despite
the fact that site-local multicast is used - should be two RDs found n Proposal simplify use case to a single RD server on the backbone to avoid
such RD-specific issues like synchronization of RD information between servers
Open Issues(45)
n Add single-subnet configuration to use cases (278)n Suggested by review Peter van der Stok and IETF85 WG discussion that
its best to start explaining the simplebasic cases and then gradually build up complexity
n Simplest case not shown yet would be a single subnet network configuration which is currently not present in the I-D only the 2-subnet configuration of Fig 1
n Question Do we need to add such case or doesnt it add muchn (Note that core-coap Figure 22 already shows the simplest case of link-local
multicast)
Open Issues(55)
n Add use case with controller (client) located on the backbone (279)n Suggested by discussion following review Peter van der Stok n Case missing where a controller (client) is located on the backbonen Question Do we need to add such case or does it add much
Group 2a other old friends
25
Angelo Castellani Salvatore Loreto Akbar Rahman Thomas Fossati Esko Dijk
IETF 86 March 2013httpwwwietforgiddraft-castellani-core-http-mapping-07txt
Best Practices for HTTP-CoAP Mapping
Implementation
Summary of Changes (from -06 rev)
n Based on discussion at last IETF-85 (Atlanta)n Clarification of HTTP-CoAP Proxies
n Definitionn Placementn Benefits
n Clarification of HTTP-CoAP URI mapping options
Goals of I-D
n For Reverse HTTP-CoAP Cross Protocol Proxyn Provide more detailed information to proxy designers (beyond
Section 10 of [I-Dietf-core-coap]) to help implement proxies that correctly inter-work with other CoAP and HTTP clientserver implementations that adhere to the specifications
n Define a consistent set of guidelines that a HTTP-to-CoAP proxy implementation MAY adhere to The main reason of adhering to such guidelines is to reduce variation between proxy implementations thereby increasing interoperabilityn As an example use case a proxy conforming to these guidelines made
by vendor A can be easily replaced by a proxy from vendor B that also conforms to the guidelines
I-D Outline
n Guidance on HTTP to CoAP URI mappingn HTTP-CoAP Reverse cross-protocol proxy implementation
n Placementn Response code amp media type translationsn Caching and congestion controln Cache refresh via Observen Use of CoAP blockwise transfern Security translation
n Security Considerationsn Traffic overflown Handling secured exchanges
Definitions (12)
n Cross-Protocol Proxy (or Cross Proxy) is a proxy performing a cross- protocol mapping in the context of this document a HTTP-CoAP (HC) mapping A Cross-Protocol Proxy can behave as a Forward Proxy Reverse Proxy or Interception Proxy n Note In this document we focus on the Reverse Proxy mode of the
Cross-Protocol Proxy
n Forward Proxy a message forwarding agent that is selected by the client usually via local configuration rules to receive requests for some type(s) of absolute URI and to attempt to satisfy those requests via translation to the protocol indicated by the absolute URI The user decides (is willing to) use the proxy as the forwardingdereferencing agent for a predefined subset of the URI space
Definitions (22)
n Reverse Proxy a receiving agent that acts as a layer above some other server(s) and translates the received requests to the underlying servers protocol It behaves as an origin (HTTP) server on its connection towards the (HTTP) client and as a (CoAP) client on its connection towards the (CoAP) origin server The (HTTP) client uses the origin-form [I-Dietf-httpbis-p1-messaging] as a request- target URI
n Reverse and Forward proxies are technically very similar with main differences being that the former appears to a client as an origin server while the latter does not and that clients may be unaware they are communicating with a proxy
Reverse Cross-Protocol Proxy Deployment Scenario
HTTP-CoAP Response Code Mapping
Implementation Experience
n Direct experience from the draft authorsn Squid HTTP-CoAP mapping module
n University of Padovan httptelecomdeiunipditiotn Both Forward and Interception operation supported
n HTTP-CoAP proxy based on EvCoAPn KoanLogic University of Bologna and Salvatore
Loreto (as individual)n httpsgithubcomkoanlogicwebthingstreemasterbridgesw
libevcoapn The document is open to input from other implementations
Next Steps
n Does the WG recommend adoptionn Intended status Informational Best Practicen Purpose Reduce arbitrary variation between proxy
implementations thereby increasing interoperability
Backup
HTTP to CoAP URI Mapping Options (12)
n Embedded Mapping n In an embedded mapping approach the HTTP URI has embedded
inside it the authority and path part of the CoAP URI n Example The CoAP resource nodecoapsomethingnetfoo can
be accessed by an HTTP client by inserting in the request httphc-proxysomethingnetcoapnodecoapsomethingnetfoo The Cross-Protocol Proxy then maps the URI to coapnodecoapsomethingnetfoo
HTTP to CoAP URI Mapping Options (22)
n Homogeneous Mapping n In a homogeneous mapping approach only the scheme portion of the URI
needs to be mapped The rest of the URI (ie authority path etc) remains unchanged
n Example The CoAP resource coapnodecoapsomethingnetfoo can be accessed by an HTTP client by requesting httpnodecoapsomethingnetfoo The Cross-Protocol Proxy receiving the request is responsible to map the URI to coapnodecoapsomethingnetfoo
n Background info n The assumption in this case is that the HTTP client would be able to
successfully resolve nodecoapsomethingnet using DNS infrastructure to return the IP address of the HC proxy Most likely this would be through a two step DNS lookup where the first DNS lookup would resolve somethingnet using public DNS infrastructure
n Then the second DNS lookup on the subdomain coap and the host node would typically be resolved by a DNS server operated by the owner of domain somethingnet So this domain owner can manage its own internal node names and subdomain allocation which would correspond to the CoAP namespace
Group 3 ldquonew workrdquo
39
Transport of CoAP over SMS USSD and GPRSdraft-becker-core-coap-sms-gprs-03
Markus Becker Kepeng LiKoojana Kuladinithi Thomas Poumltsch
CoRE WG IETF-86 Orlando
1 10
ScenariosI In M2M communication IP connectivity is not alwayssupported by the constrained end-points
I Power savingI Coverage (GPRS 3G LTE)
I SMS and USSD based communication is almost alwayssupported
210
Changes from draft-01 to draft-03 (1)
I Added possible CONNONACK interactions Section 5
I Option name changed from Reply-To- to Response-To-Section 16 and Section 101
I Added URI schemeEg coap+tel+15105550101well-knowncore Section 11
I Added possible M2M proxy scenarios Section 14
3 10
Changes from draft-01 to draft-03 (2)
I Added reference to bormann-coap-misc for other SMSencoding Section 71
I Updated requirements on Uri-Host and Uri-Port forcoap+tel Section 10
I Added security considerations Transport and ObjectSecurity Section 15
I Chose CoAP option numbers and updated the optionnumber table to meet draft-ietf-core-coap-10 Table 1
I Added an IANA registration for the URI scheme coap+telSection 162
4 10
Feedback Split coap+tel into coap+smsand coap+ussd
I How else to differ the various transports in the URII Or is the transport to use decided by the implementationI See alsodraft-silverajan-core-coap-alternative-transports-01
5 10
Feedback Response-To-Scheme option
I Should there be a Response-To-Scheme optionadditionally to Response-To-Uri-Host andResponse-To-Uri-Path
I So that a CoAP end-point which receives a request by CoAPover non-IP transport can be instructed to also use thenon-IP transport for the response
I This would imply to add aResponse-To-Telephone-Subscriber and more options forother transports that have other URI schemes than coapand coaps
6 10
Feedback Selection of Transport by Client
I When a server is reachable by various transports howdoes a client decide which transport to use
I Client-side application congurationI Leave it to a proxy which uses cellular network lookupfunctions
7 10
Feedback Potential Threats
I Trigger expensive short messagesI Redirect trac to other addressesI More threats
I Are the security measures in the draft adequateI Whitelisting on serverI Relying on cellular network security (dedicated M2M APNs)I Object security on CoAP payload
8 10
Feedback Message Exchanges
I Figures 11-18 show possible message exchanges whenclient and server have two addresses
I With NON Not using CoAP retransmission capabilityI ACK on different transportI Additional (costly) message on Transport AI Request with Content
I Which ones are allowedI Which ones are meaningful
9 10
Next steps
I Rene Uri schemeI Response-To-Scheme optionI Selection of Message ExchangeI Rene Proxying
10 10
CoAP13 Communicaon13 with13 Alternave13 Transports
Bill Silverajan and Teemu SavolainenCore WG IETF 86 Orlando
031113
Objecves13 (In13 Scope)
bull Unambiguous13 representaon13 of13 transport13 to13 be13 used13 by13 CoAP
bull Details13 how13 the13 transport13 can13 carry13 CoAP13 packet
bull Focus13 is13 on13 what13 CoAP13 communicaons13 requirements13 are
bull Allow13 CoAP13 mechanisms13 to13 exploit13 cross-shy‐layer13 opmisaons
51
031113
Non13 Goals13 (Not13 in13 scope)
bull Applicaon-shy‐level13 QoS13 requirementsbull Real-shy‐me13 constraintsbull Ordering13 reliability13 congeson13 controlbull Applicaon13 and13 network13 adaptaonbull Mobility13 and13 readdressing13 supportbull Network13 protocol13 (eg13 IPsec)13 configuraon
52
031113
Use13 Cases
bull NAT13 and13 Firewall13 traversal13 with13 TCPbull Delay13 Tolerant13 Networkingbull Non-shy‐IP13 Low13 Energy13 Protocols
53
031113
Related13 Work
bull OMA13 Lightweight13 M2M13 Protocolbull CoAP13 over13 SMSGPRSUSSD
54
031113
What13 does13 the13 work13 entail
bull The13 ability13 to13 specify13 end13 point13 idenfiers13 and13 URIs13 to13 reflect13 which13 transport13 CoAP13 can13 use
bull The13 ability13 to13 register13 to13 resource13 directories13 resource13 types13 reflecng13 types13 of13 transport13 available
bull Ability13 for13 mul-shy‐transport13 nodes13 to13 select13 transport13 to13 use13 without13 significant13 alteraon13 to13 CoAP13 packet13 structure
55
031113
Points13 to13 consider
bull Requirements13 for13 transport13 layer13 protocol13 to13 carry13 CoAP13 packets
bull Representaon13 of13 URI13 scheme13 for13 generic13 transport13 protocols
bull Opon13 extensions13 for13 CoAP13 to13 express13 available13 transports
bull Mapping13 and13 message13 sizebull Security13 consideraons
56
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
URI13 =13 scheme13 13 13 authority13 path-shy‐abempty13 [13 query13 ]
bull Within13 the13 scheme13 namebull In13 the13 URI13 pathbull As13 a13 query13 component
57
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
bull Within13 the13 scheme13 namendash coap+tel+15105550101well-shy‐knowncorendash coap+tcpexamplecom5683temperaturendash coap+blel2cap[1234567890AB]4pulse
bull Easy13 URI13 parsing13 for13 transport13 type13 and13 idenfier
bull Each13 new13 scheme13 name13 requires13 IANA13 registraon
58
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
bull In13 the13 URI13 pathndash coaphostexamplecomtransport=tcpwell-shy‐knowncorert=core-shy‐rd
bull Easy13 adopon13 of13 new13 (and13 experimental)13 CoAP13 transports13 without13 IANA13 registraon
bull Caveat13 Uri-shy‐Path13 opon13 is13 a13 Crical13 CoAP13 opon13 see13 secon13 54113 of13 I-shy‐Diep-shy‐core-shy‐coap
59
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
bull As13 a13 URI13 query13 componentndash coaphostexamplecomwell-shy‐knowncorert=core-shy‐rdq=tcp
bull Also13 easy13 to13 adopt13 new13 (and13 experimental)13 CoAP13 transports13 without13 IANA13 registraon
bull Caveat13 Uri-shy‐Query13 opon13 is13 a13 Crical13 CoAP13 opon13 see13 secon13 54113 of13 I-shy‐Diep-shy‐core-shy‐coap
60
031113
URI13 Representaons13 for13 CoAPNon13 standard13 ways
bull Transport13 in13 the13 URI13 authority13 componentndash coaphost[port][transport]13 instead13 of13 coaphost[port]
bull Transport13 as13 a13 service13 URLndash servicecoaptcphostexamplecomwell-shy‐knowncorert=core-shy‐rd
bull Above13 two13 ways13 break13 exisng13 compability13 (although13 both13 are13 based13 on13 valid13 IANA13 URI13 registraons)
61
031113
URI13 Representaons13 for13 CoAPMiscellaneous13 Consideraons
bull Ensure13 that13 transport13 is13 defined13 unambiguously13 (eg13 L2CAP13 used13 by13 both13 BLE13 and13 standard13 Bluetooth13 so13 avoid13 rdquocoap+l2caprdquo13 or13 rdquotransport=l2caprdquo13 or13 rdquoq=l2caprdquondash Can13 be13 done13 as13 WG13 consensusndash Namespace13 approach13 eg13 rdquocoap+blel2caprdquo13 or13 rdquoq=blel2caprdquo
bull Allow13 end-shy‐points13 to13 use13 CoAP13 Resource13 Directory13 to13 register13 alternave13 transports13 and13 idenfiers13 and13 provide13 periodic13 updatesndash Register13 rdquocore-shy‐transportrdquo13 resource13 type
62
031113
Transport13 Consideraons
bull Uniqueness13 of13 end-shy‐point13 idenficaonbull Communicaon13 support13 Unidireconal13 Bidireconal13 1N13 (broadcast13 mulcast13 anycast)13 messaging
bull Binary13 encoding13 Network13 byte13 orderingbull MTU13 correlaon13 with13 CoAP13 PDU13 sizebull Transport13 latency
63
031113
Security13 Consideraons
bull Drar13 does13 not13 introduce13 new13 security13 requirements13 by13 itself
bull There13 may13 be13 privacy13 issues13 if13 nodes13 use13 telephone13 numbers13 or13 MAC13 addresses13 as13 public13 end13 point13 idenfiers
64
Akbar Rahman
IETF 86 March 2013 httpwwwietforgiddraft-rahman-core-sleepy-02txt
Enhanced Sleepy Node Support for CoAP
Introduction
It is expected that in CoAP networks there will be a certain portion of devices that are sleepy and which may occasionally go into a sleep mode (ie go into a low power state to conserve power) and subsequently have reduced CoAP protocol communication ability
This I-D proposes a minimal and efficient mechanism building on the Resource Directory concept (which will be integrated into a CoAP Proxy) to enhance sleepy node support in CoAP networks
Main Question from IETF-85 (Atlanta)
What performance benefit does the proposed Sleepy Node support solution give in a network that already has standard CoAP caching enabled
Sleepy Node Performance Analysis
Experimental Network
1-5 clients
Both Sleepy and Non-
Sleepy servers
Sleepy Node Performance Analysis Network Setup
CoAPSleepyServer(s)
CoAPSleepAwareReverseProxy
CoAP
Client(s)
Request
Response
Sleep9AwareCoREResourceDirectoryCapability
PublishedSleepParameters
Sleep9AwareCoAPStoreandForwardCapability Response
Request
SleepAwareCoAP503ResponseCapability
CoAPCachingCapability
bull Server supports publishing sleep parameters to proxy bull Eg Irsquom going to be asleep for X seconds
bull Proxy supports sleep-awareness capabilities bull Proxy also supports caching capability based off of maxAge bull Protocol flow similar to approach of Figure 1 (Synchronous RD Based Sleep
Tracking) of I-D
Proxy capabilities can be selectively enableddisabled
Proxy ndash Server Interface
Client ndash Proxy Interface
CoAP Sleep-Aware Reverse Proxy Features CoRE Sleep-aware Resource Directory
Support storing published sleep parameters from CoAP servers sleepState (AWAKE ASLEEP) sleepDuration
Sleep-aware CoAP 503 Response Capability If CoAP request to a sleeping server is received proxy returns a
lsquo503 Retry-Afterrsquo response to client 503 contains a timestamp indicating when the sever will wake back up
(timestamp delivered in CoAP maxAge option) Sleep-aware CoAP Store-and-Forward Capability
If CoAP request to a sleeping server is received proxy stores request until server wakes up and then forwards it
Caching capability Cache GET responses from server if maxAge option is present
(this is not a sleep aware feature)
Goals of Performance Analysis
For networks having sleepy servers provide measurements to quantify the impact that CoAP sleep-awareness capabilities can have
See if sleep-awareness capabilities can
provide additional benefits even when CoAP caching is used
Overview of Performance Analysis Performed The analysis was broken up into a set of test scenarios Each test scenario used a different combination of the following
variables Client issued GET requests Server was configured as a sleepy or non-sleepy server Proxy caching of GET responses was enabled or disabled Proxy sleep-aware 503 response capability was enabled or disabled Proxy store-and-forward capability was enabled or disabled maxAge in GET responses ndash Two values were tested 60sec and 5sec of Clients ndash Two values were used ndash 1 client and 5 clients
For comparison purposes the following were held constant across all test scenarios Client issued a fixed number of requests (100) across all test scenarios Client used a delay between each GET request (35sec) to better exercise
proxyrsquos caching and sleep-awareness capabilities For sleepy server test scenarios the server slept 60 sec awake for 3 sec
Format of Results The following results were collected for each
test scenario
Breakdown of the and types of transactions occurring between clientproxyserver
ldquoGETrdquo ndash Test Scenario Results
GET ndash Description of Test Scenarios
TestScenarios-GET
Scenario
CoAPSleepyServerSe7ngs CoAPSleepAwareReverseProxySe7ngs CoAPClientSe7ngs
SleepDuragton(sec)
AwakeDuragton(sec)
maxAge(sec) Caching SleepAwareSAF+
503NumberofClients
NumberofGETs
DelayBetweenClient
Requests(sec)
1a 0 Always 60 Enabled Disabled 1 100 35
1b 60 3 60 Enabled Disabled 1 100 35
1c 60 3 60 Enabled Enabled 1 100 35
2a 0 Always 60 Enabled Disabled 5 100 35
2b 60 3 60 Enabled Disabled 5 100 35
2c 60 3 60 Enabled Enabled 5 100 35
3a 0 Always 5 Enabled Disabled 5 100 35
3b 60 3 5 Enabled Disabled 5 100 35
3c 60 3 5 Enabled Enabled 5 100 35
ldquoGETrdquo ndash Test Scenario 1 Results
maxAge = 60 and 1 Client
GET ndash Scenario 1 ClientProxy Interface Transaction Mix
Scenarios 1a - Non-Sleepy Server Caching Proxy maxAge = 60sec 1b- Sleepy Server Caching Proxy maxAge = 60sec 1c - Sleepy Server Sleep Aware Proxy maxAge = 60sec
Sleep Aware Proxy has better performance for sleepy servers
0
100
200
300
400
500
600
700
1a 1b 1c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
GET ndash Scenario 1 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
Scenarios 1a - Non-Sleepy Server Caching Proxy maxAge = 60sec 1b- Sleepy Server Caching Proxy maxAge = 60sec 1c - Sleepy Server Sleep Aware Proxy maxAge = 60sec
0
100
200
300
400
500
600
700
800
1a 1b 1c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
ldquoGETrdquo ndash Test Scenario 2 Results
maxAge = 60 and 5 Clients
GET ndash Scenario 2 ClientProxy Interface Transaction Mix
Sleep Aware Proxy has slightly better performance for sleepy servers
0
200
400
600
800
1000
1200
1400
2a 2b 2c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
Scenarios 2a - Non-Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2b- Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2c - Sleepy Server Sleep Aware Proxy maxAge = 60sec 5 Clients
See ldquoExperimental Artifactsrdquo Note 1
GET ndash Scenario 2 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has slightly better performance for sleepy servers
0
50
100
150
200
250
300
350
400
2a 2b 2c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
Scenarios 2a - Non-Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2b- Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2c - Sleepy Server Sleep Aware Proxy maxAge = 60sec 5 Clients
See ldquoExperimental Artifactsrdquo Note 2
Experimental Artifacts Note 1
Currently in the experiment the sleep aware proxy checks the cached state of a resource before putting a request into its Store-and-forward queue while a server is sleeping Once in the queue the proxy unconditionally forwards the queued requests to the server once it wakes up This is not the most efficient setup and can easily be improved If the proxy instead checks its cache again before forwarding each queued request it may not need to forward the request to the server For example if there are two queued GET requests in the proxyrsquos queue that address the same resource Only the first request needs to be sent to the server the second request can use the cached response from the first request
Note 2 Currently in the experiment the sleepy server sends a sleepState PUT request to the
proxy each time it goes to sleep This is not the most efficient setup and can easily be improved For example if the server assumes that the proxy can keep track of its ONOFF cycles with its internal timers (eg as per Fig 1 of I-D) then the number of messages from the sleepy server dramatically goes down
ldquoGETrdquo ndash Test Scenario 3 Results
maxAge = 5 and 5 Clients
GET ndash Scenario 3 ClientProxy Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
Scenarios 3a - Non-Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3b- Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3c - Sleepy Server Sleep Aware Proxy maxAge = 5sec 5 Clients
0
500
1000
1500
2000
2500
3000
3500
4000
4500
5000
3a 3b 3c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
GET ndash Scenario 3 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
0
1000
2000
3000
4000
5000
6000
7000
3a 3b 3c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
Scenarios 3a - Non-Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3b- Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3c - Sleepy Server Sleep Aware Proxy maxAge = 5sec 5 Clients
Conclusions
Conclusions These results show that sleep-aware CoAP
proxy features can significantly optimize communication with sleepy servers in most scenarios
These results also show that sleep-
awareness capabilities can provide additional benefits above and beyond CoAP caching in most scenarios
Backup
Current CoAP Support of Sleepy Node (12)
CoAP proxies can use a previously cached response to service a new GET request for a sleepy origin server (as in HTTP) But if no valid cache then proxy has to attempt to
retrieve and may fail if origin server is sleeping [I-Dietf-core-coap]
Clients can discover list of resources from RD (GET rd-lookuphellip) for sleepy servers But attempt to GET resource from sleepy origin server
may fail if origin server is sleeping [IDietf-core-link-format amp IDshelby-core-resource-
directory]
Current CoAP Support of Sleepy Node (22)
Lower layer support for sleepy nodes in most wireless technologies (eg WiFi ZigBee) But limited to MAC packet scheduling for sleepy nodes
and not aware of specific needs of IP applications (like CoAP)
Proposal ndash RD Based Sleep Tracking (14)
The current CoAP approach to support sleepy nodes can be significantly improved by introducing RD based mechanisms for a CoAP client to determine whether A targeted resource is located on a sleepy server A sleepy server is currently in sleep mode or not
There is any associated caching Proxy (possibly the RD itself) for a sleepy server
Proposal ndash RD Based Sleep Tracking (24)
We define the following new RD attributes to characterize the properties of a sleepy node SleepState - Indicates whether the node is currently in
sleep mode or not (ie Sleeping or Awake) SleepDuration - Indicates the maximum duration of time
that the node stays in sleep mode TimeSleeping - Indicates the length of time the node
has been sleeping (ie if Sleep State = Sleeping) NextSleep - Indicates the next time the node will go to
sleep (ie if Sleep State = Awake)
CachingProxy ndash Indicates the caching proxy of the sleepy node (ie the RD itself or another node)
Proposal ndash RD Based Sleep Tracking (34)
These attributes are all server (node) level and are new parameters added to the RD URI Template Variables
Finally we also define a new lookup-type (ss) for the RD lookup interface specified in [I-Dshelby-core-resource-directory] This new lookup-type supports looking up the
ldquoSleepStaterdquo (ss) of a specified end-point
Proposal ndash RD Based Sleep Tracking (44)
The three time based parameters (SleepDuration TimeSleeping NextSleep) can be based on either an absolute network time (for a time synchronized network) or a relative local time (measured at the local node)
Following the approach of [I-Dietf-core-link-format] and [I-Dshelby-core-resource-directory] sleep parameters for sleepy servers can be stored by the server in the RD and accessed by all interested clients
Examples of using these parameters in a synchronous or asynchronous manner are shown in the I-D
http6lowappnet coreIETF86 2013-03-12-13
We assume people have read the drafts
Meetings serve to advance difficult issues by making good use of face-to-face communications
Note Well Be aware of the IPR principles according to RFC 3979 and its updates
uumlBlue sheetsuumlScribe(s)
96
drar-shy‐iep-shy‐core-shy‐coapsubmiqed13 to13 IESG
2013-shy‐03-shy‐13
97
OMA Lightweight M2M Overview(A new standard using lots of IETF specs including DTLS
CoAP Block Observe Resource Directory SenMLhellip)
Zach ShelbyCoRE WG IETF-86 Orlando
OMA Lightweight M2Mbull Open Mobile Alliance is well known for Device Management (DM)bull OMA Lightweight M2M is a new standard from the alliance
ndash Focused on constrained Cellular and sensor network M2M devicesndash Driven by leading operators and vendors
bull Scopendash Interfaces protocol amp security between Device and Serverndash Object and Resource modelndash Bootstrap Device Access Control Connectivity and Firmware Objects
bull Draft Specifications are availablendash httpmemberopenmobileallianceorgftpPublic_documentsDM
LightweightM2MPermanent_documentsOMA-TS-LightweightM2M-V1_0_0-20130301-Dzip
bull Timelinendash Requirements and Architecture completed 3Q2012ndash Spec ready for Consistency Review 2Q2013ndash Candidate Approval expected 3Q2013
2 CoRE WG IETF-86 Orlando
Architecture
3
Scope of LWM2M
CoRE WG IETF-86 Orlando
Object Model
bull A Client has one or more Object Instancesbull An Object is a collection of Resourcesbull A Resource is an atomic piece of information
ndash Read Written or Executed
bull Resources can have multiple instancesbull Objects and Resources are identified by a
16-bit Integer Instances by an 8-bit Integerbull ObjectsResources are accessed with
simple URIs Object IDObject InstanceResource ID
eg 1213
4 CoRE WG IETF-86 Orlando
CoRE WG IETF-86 Orlando
CoRE Resource Directory
draft-shelby-core-resource-directory-05
Z Shelby C Bormann S Krco
Backgroundbull Not a new concept
ndash think web search engine or any link directorybull Defines the interfaces to a Resource Directorybull Based on Web Linking framework and the CoRE Link Formatbull Generic REST design for use over HTTP and CoAPbull Used by OMA Lightweight M2Mbull Has already been deployed
ndash In traffic monitoring systemsndash In street lighting systemsndash For vehicular asset trackingndash By a major Cellular M2M operator
Changes since -04
bull Restricted Update to parameter updatesbull Added pagination support for the Lookup interfacebull Changed rt= to et= for the registration amp update
interfacebull Added group support
Group Management
bull RD now includes group management featuresbull New Group Function Set
ndash Register a groupbull Group name domain multicast address endpoint members
ndash Remove a groupbull Group lookup using the Lookup Function Set
ndash List registered groupsndash Find the members of a groupndash Find groups with certain endpoints or resources
Registering a Group
EP RD
| |
| - POST rd-groupgp=lights ltgtep=node1 --gt |
| |
| |
| lt---- 201 Created Location rd-group12 ---- |
| |
Req POST coaprdexamplecomrd-groupgp=lights
Payload
ltgtep=node1
ltgtep=node2
Res 201 Created
Location rd-group12
Looking up Group Members
Client RD
| |
| ----- GET rd-lookupepgp=lights1 ----------------------gt |
| |
| |
| lt-- 205 Content ltrdgtd=domain1ltrdgtd=domain2 --------- |
| |
Req GET rd-lookupepgp=lights1
Res 205 Content
ltcoaphostportgtep=node1
ltcoaphostportgtep=node2rdquo
Things for the futurebull Support for JSON representation of Web Links
ndash httptoolsietforgiddraft-bormann-core-links-json-02txtbull Registry for RD registration query parameters
ndash Already OMA Lightweight has defined some new onesbull More examples
Group 3 ldquonew workrdquo(continued)
109
drar-shy‐greevenbosch-shy‐core-shy‐profile-shy‐descripon-shy‐01Bert13 GreevenboschJeroen13 Hoebeke
Isam13 IshaqFloris13 Van13 den13 Abeele
Descripon
bull JSON13 format13 for13 signalling13 the13 servers13 capabilies
bull Signalling13 of13 supported13 opons13 media13 types13 and13 block13 sizendash Other13 items13 can13 be13 added
bull Filtering13 on13 specific13 fields13 through13 URI-shy‐Querybull Link13 hqpdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐profile-shy‐descripon
well-shy‐knownprofile
bull To13 acquire13 profile13 data13 of13 resources13 on13 a13 parcular13 service13 the13 well-shy‐knownprofile13 URI-shy‐path13 is13 introduced
bull For13 example13 to13 get13 all13 informaon13 from13 sensors13 served13 by13 wwwexampleorg13 we13 can13 do13 a13 GET13 to13 coapwwwexampleorgwell-shy‐knownprofile
bull Filtering13 on13 parcular13 resources13 is13 done13 through13 URI-shy‐Queries
Format
bull Currently13 the13 following13 fields13 are13 definedndash ldquopathrdquo13 contains13 the13 URI-shy‐path13 associated13 with13 a13 resource
ndash ldquooprdquo13 a13 numerical13 list13 of13 supported13 opon13 numbers
ndash ldquocfrdquo13 a13 numerical13 list13 of13 supported13 content-shy‐format13 numbers
ndash ldquob1srdquo13 ldquob2srdquo13 supported13 block13 sizes13 for13 Block113 and13 Block213 respecvely
Examplebull On13 the13 right13 is13 an13 example13 of13 a13 camera13 sensor13 at13 coapwwwexampleorgcam13 that13 supports13 the13 Uri-shy‐Host13 (3)13 ETag13 (4)13 Uri-shy‐Port13 (7)13 Uri-shy‐Path13 (11)13 Content-shy‐Format13 (12)13 Token13 (19)13 Block213 (23)13 and13 Proxy-shy‐Uri13 (35)13 opons
bull The13 supported13 content13 formats13 are13 textplain13 (0)13 applicaon13 link-shy‐format13 (40)13 and13 applicaonjson13 (50)
bull The13 supported13 Block213 can13 use13 25613 or13 51213 byte13 blocks
Req13 GET13 coapwwwexampleorgwell-shy‐knownprofile13 Res13 20513 Content13 (applicationjson)13 13 13 13 profile13 13 13 13 13 13 13 13 pathcam13 13 13 13 op[3471112192335]13 13 13 13 13 cf[04050]13 13 13 13 13 b2s[45]13 13 13 13
Filtering13 through13 use13 of13 URI-shy‐Query
bull Filtering13 can13 be13 done13 through13 the13 URI-shy‐Querybull Query13 format13 N=V
ndash N13 is13 a13 profile13 fieldndash V13 is13 the13 desired13 value
bull Examplesndash To13 find13 resources13 that13 support13 content13 format13 ldquoapplicaonjsonrdquo
13 GET13 wwwexampleorgwell-shy‐knownprofilecf=50ndash To13 get13 informaon13 about13 the13 camera
13 GET13 wwwexampleorgwell-shy‐knownprofilepath=cam
Open13 issues
bull Which13 other13 profile13 data13 needs13 signallingndash Content-shy‐type13 for13 different13 methods
bull Fix13 the13 order13 in13 which13 the13 profile13 fields13 must13 appearndash Non-shy‐fixed13 order13 easier13 extensible
bull Inheritance13 of13 a13 profile13 descriponbull Extend13 usage13 to13 signal13 the13 client13 profilebull Integraon13 with13 link13 format
Thank13 youQuesons
drar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval-shy‐00
Bert13 Greevenbosch
Descripon
bull The13 ldquoMinimumRequestInterval13 opon13 can13 be13 used13 to13 indicate13 the13 minimum13 me13 between13 two13 requests13 in13 a13 transacon
bull Originally13 intended13 for13 Block13 but13 also13 usable13 for13 other13 transaconsndash Example13 browsing13 a13 server
bull The13 goal13 is13 to13 reduce13 the13 server13 load13 and13 network13 traffic
bull Link13 hqpsdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval
Usage
bull The13 client13 keeps13 the13 server13 informed13 about13 its13 request13 speed13 through13 inclusion13 of13 the13 ldquoMinimumRequestIntervalrdquo13 opon
bull In13 responses13 the13 server13 fixes13 the13 minimum13 request13 interval13 through13 the13 same13 opon
bull The13 client13 obeys13 the13 speed13 indicated13 by13 the13 server
bull The13 client13 can13 send13 slower13 but13 not13 faster
Advantages
bull The13 server13 has13 means13 to13 limit13 the13 amount13 of13 incoming13 traffic
bull The13 server13 can13 prevent13 to13 become13 overloaded13 with13 too13 many13 tasks
bull The13 server13 does13 not13 need13 arficially13 slow13 down13 the13 client13 by13 sending13 late13 ACKsndash No13 need13 to13 keep13 track13 of13 delayed13 ACKsndash The13 server13 can13 perform13 other13 tasks13 instead
bull Reduced13 network13 traffic
Thank13 youQuesons
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-links-json-02txt
123
RFC 6690 (link-format) documents are somewhat foreign to many web app developerssect would prefer to have them in JSON format
There is no standard way to represent link-format documents in applicationssect but everyone knows how to handle JSON
Define a standard JSON translation for link-format
Itrsquos
not
rock
et
scien
ce
ltsensorsgtct=40title=Sensor Index ltsensorstempgtrt=temperature-cif=sensor ltsensorslightgtrt=light-luxif=sensor lthttpwwwexamplecomsensorst123gt anchor=sensorstemprel=describedby lttgtanchor=sensorstemprel=alternate [hrefsensorsct40titleSensor Index hrefsensorstemprttemperature-cifsensor hrefsensorslightrtlight-luxifsensor hrefhttpwwwexamplecomsensorst123 anchorsensorstempreldescribedby hreftanchorsensorstemprelalternate]
124
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-ipsec-for-coap-00txt
IPsec definitions for CoAP Mostly placeholder at this time Who has implementation experience with this
125
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-cross-reverse-convention-00txt
This draft has two lines of payload(based on a WGLC comment by Cullen Jennings)
coap12344567foobara=3
httpwwwproxycomwellknowncore-translate1234_4567foobara=3
Is that a useful convention to have
126
Insert CI slides here
127
128
0
5
10
15
20
25
30
35
40
10 20 30 40 50 60 70
good
put (
pps)
pps
Goodput vs pps (Econotags)
goodput
[Khattak preliminary]
Congestion Control
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-cocoa-00txt
ldquoadvancedrdquo cc (The draft is just a first shot) Others may have better ideas
129
Insert post-WGLC discussion slides here
130
Stop Continue Start
131
An Agile Retrospective
http6lowappnet coreIETF86 2013-03-12-13
Stop
132
Endless new CoAP optionssect instead use RESTful as much as possible
Move general security lifecycle out Looking at theoretical problems
http6lowappnet coreIETF86 2013-03-12-13
Continue
Interops Running code Look at real-world examples and deployments Solve their actual problems
sect Unilateral enhancements eg higher performance congestion control
sect Transports (SMS hellip)sect Make Web linking and Directories more and more usefulsect RESTful Design Paradigms for real-world problems
133
http6lowappnet coreIETF86 2013-03-12-13
Start
Further push into the (browser) web world (HTML5 browser security)
Specific supporting worksect SenMLsect URI work (dev URN hellip)sect Security Processes (next slide)
Spin outsect (We donrsquot really get to decide where this is done)
134
http6lowappnet coreIETF86 2013-03-12-13
Security
Integrate Application Network Group Keyingsect Tunnel-free setup
Donrsquot redo what has been done alreadysect ZigBee IP is finesect But what about other scenarios
Simple REST interfaces for working with keying materials and authorizationsect Start with defining objectives
Object Security for Constrained Nodes135
Re-chartering CoREWhat do we want to do now that wersquore grown up
Zach ShelbyCoRE WG IETF-86 Orlando
What is the scope
bull So we have a protocol and Web Linking what next
bull Keep with what we know besthellip1 Enhancements around CoAP2 New transports for CoAP3 New representations for Web Links4 General application layer solutions
CoRE WG IETF-86 Orlando 2
Enhancements around CoAP
bull Advanced congestion control
CoRE WG IETF-86 Orlando 3
New Transports for CoAP
bull Infrastructure for CoAP over foondash httptoolsietforgiddraft-silverajan-core-
coap-alternative-transports-01txtbull CoAP over SMS
ndash httptoolsietforgiddraft-becker-core-coap-sms-gprs-03txt
ndash OMA Lightweightbull CoAP over TCP
ndash httptoolsietforgiddraft-li-core-coap-payload-length-option-01txt
CoRE WG IETF-86 Orlando 4
New support for Web Links
bull JSON Web Linksndash httptoolsietforgiddraft-bormann-core-links-
json-02txt
2332010 CoRE WG IETF-77 Anaheim 5
General application layer solutions
bull Resource Directoryndash httptoolsietforgiddraft-shelby-core-
resource-directory-05txtndash OMA Lightweight
2332010 CoRE WG IETF-77 Anaheim 6
http6lowappnet coreIETF86 2013-03-12-13
draft-ietf-core-block-10
11
Still awaits grand editorial rewritesect right after coap-14 is shipped
http6lowappnet coreIETF86 2013-03-12-13
Tickets
hellip are our way to make the steps forward are at
http toolsietforgwgcore Updates are sent to the mailing list
sect Please review When we close a ticket please review once more
12
Group 2 groupcomm
13
Akbar RahmanEsko Dijk
IETF 86 March 2013httpwwwietforgiddraft-ietf-core-groupcomm-05txt
Group Communication for CoAP
Summary of Changes (14)
n I-D had two updates (Rev 04 amp 05) after IETF-85 (Atlanta) Many of the updates were due to the detailed review by Peter van der Stokn Thank you Peter for your valuable comments
n Changes from ietf-03 to ietf-04 n Section 23 (Potential Solutions for Group Communications) moved to
draft-dijk-core-groupcomm-misc (266)n Added reference to draft-keoh-tls-multicast-security to section 6 (Security
Considerations) n Appendix B (CoAP-Observe Alternative to Group Communications) moved
to draft-dijk-core-groupcomm-misc (267) n Deleted section 8 (Conclusions) as it is redundant (268) n Simplified light switch use case (269) by splitting into basic operations and
additional functions (269)
Summary of Changes (24)
n Changes from ietf-03 to ietf-04 (Continued) n Moved section 37 (CoAP Multicast and HTTP Unicast Interworking) to
draft-dijk-core-groupcomm-misc (270) n Moved section 331 (DNS-SD) and 332 (CoRE Resource Directory) to
draft-dijk-core-groupcomm-miscClarified that DNS based features are optional (272)
n Focus section 35 (Configuring Group Membership) on a single proposed solution
n Scope of section 53 (Use of MLD) widened to multicast destination advertisement methods in general
n Rewrote section 22 (Scope) for improved readibility n Moved use cases that are not adressed to draft-dijk-core-groupcomm-miscn Various editorial updates for improved readibility
Summary of Changes (34)
n Changes from ietf-04 to ietf-05 n Added a new section 39 (Exceptions) that highlights that IP multicast (and
hence group communications) is not always available (187) n Included guidelines on when (not) to use CoAP responses to multicast
requests and when (not) to accept multicast requests (273) n Added guideline on use of core-block for minimizing response size (275)n Restructured section 6 (Security Considerations) to more fully describe
threats and threat mitigation (277) n Clearly indicated that DNS resolution and reverse DNS lookup are optional n Removed confusing text about a single group having multiple IP addresses
If multiple IP addresses are required then multiple groups (with the same members) should be created
n Removed repetitive text about the fact that group communications is not guaranteed
Summary of Changes (44)
n Changes from ietf-04 to ietf-05 (Continued) n Merged previous section 52 (Multicast Routing) into 31 (IP Multicast
Routing Background) and added link to section 52 (Advertising Membership of Multicast Groups)
n Clarified text in section 38 (Congestion Control) regarding precedence of use of IP multicast domains (ie first try to use link-local scope then site-local scope and only use global IP Communication for CoAP multicast as a last resort)
n Extended group resource manipulation guidelines with use of preconfigured portspaths for the multicast group
n Consolidated all text relating to ports in a new section 33 (Port Configuration)
n Clarified that all methods (GETPUTPOST) for configuring group membership in endpoints should be unicast (and not multicast) in section 37 (Configuring Group Membership In Endpoints)
n Various editorial updates for improved readability
Discussion item (11)
n Solution for Configuring Group Membership (no ticket)n Example of (unicast) configuring an endpoint to be part of one multicast
groupReq POST gp (Content-Format applicationjson)
n floor1westbldg6examplecom ip ff154200f7feed3714cb Res 204 Changed
n Where the ldquogprdquo resource has resource type (rt) ldquocoregprdquo which is defined for this purpose
n Question Do we want specify such a solution (or for example leave it completely up to implementation)
Open Issues(15)
n Review Groupcomm requirements language (271)n Decision made to keep requirements language for informational draftn Each use of MAYMUSTSHOULD etc is to be reviewed
Open Issues(25)
n Add section on multicast via Proxy and its limitations (274)n Add a section to explain the issues amp limitations of doing CoAP multicast
requests via a CoAP Proxy n Goal is to warn and guide implementers in this subject n Also such a section would provide a placeholderreminder of the problems
that might be addressed further in the futuren Based on IETF 85 CoRE WG meeting discussion on Multicast CoAP
requests via a Proxy Discussion summary for referencen Aggregation of responses in a proxy is difficult since it doesnt know
when to stop aggregating responses n SIP tried to deal with this problem but didnt solve it n There may be an expectancy of CoAP client to get single response
back from proxy not multiple The client in this case may not even know what it could expect It may not even know the Proxy-URI contains a multicast target
n Presented via-proxy use case exposes gap in the core-coap specification regarding multicast via proxy (Note Expectation is that core-coap wonrsquot address it in the first planned RFC release)
Open Issues(35)
n Issues with twomultiple Resource Directories in use case (280)n Some potential issues with RD came out of review Peter van der Stok and
WG discussion IETF85 n There are two RD servers use case shows that only one is found despite
the fact that site-local multicast is used - should be two RDs found n Proposal simplify use case to a single RD server on the backbone to avoid
such RD-specific issues like synchronization of RD information between servers
Open Issues(45)
n Add single-subnet configuration to use cases (278)n Suggested by review Peter van der Stok and IETF85 WG discussion that
its best to start explaining the simplebasic cases and then gradually build up complexity
n Simplest case not shown yet would be a single subnet network configuration which is currently not present in the I-D only the 2-subnet configuration of Fig 1
n Question Do we need to add such case or doesnt it add muchn (Note that core-coap Figure 22 already shows the simplest case of link-local
multicast)
Open Issues(55)
n Add use case with controller (client) located on the backbone (279)n Suggested by discussion following review Peter van der Stok n Case missing where a controller (client) is located on the backbonen Question Do we need to add such case or does it add much
Group 2a other old friends
25
Angelo Castellani Salvatore Loreto Akbar Rahman Thomas Fossati Esko Dijk
IETF 86 March 2013httpwwwietforgiddraft-castellani-core-http-mapping-07txt
Best Practices for HTTP-CoAP Mapping
Implementation
Summary of Changes (from -06 rev)
n Based on discussion at last IETF-85 (Atlanta)n Clarification of HTTP-CoAP Proxies
n Definitionn Placementn Benefits
n Clarification of HTTP-CoAP URI mapping options
Goals of I-D
n For Reverse HTTP-CoAP Cross Protocol Proxyn Provide more detailed information to proxy designers (beyond
Section 10 of [I-Dietf-core-coap]) to help implement proxies that correctly inter-work with other CoAP and HTTP clientserver implementations that adhere to the specifications
n Define a consistent set of guidelines that a HTTP-to-CoAP proxy implementation MAY adhere to The main reason of adhering to such guidelines is to reduce variation between proxy implementations thereby increasing interoperabilityn As an example use case a proxy conforming to these guidelines made
by vendor A can be easily replaced by a proxy from vendor B that also conforms to the guidelines
I-D Outline
n Guidance on HTTP to CoAP URI mappingn HTTP-CoAP Reverse cross-protocol proxy implementation
n Placementn Response code amp media type translationsn Caching and congestion controln Cache refresh via Observen Use of CoAP blockwise transfern Security translation
n Security Considerationsn Traffic overflown Handling secured exchanges
Definitions (12)
n Cross-Protocol Proxy (or Cross Proxy) is a proxy performing a cross- protocol mapping in the context of this document a HTTP-CoAP (HC) mapping A Cross-Protocol Proxy can behave as a Forward Proxy Reverse Proxy or Interception Proxy n Note In this document we focus on the Reverse Proxy mode of the
Cross-Protocol Proxy
n Forward Proxy a message forwarding agent that is selected by the client usually via local configuration rules to receive requests for some type(s) of absolute URI and to attempt to satisfy those requests via translation to the protocol indicated by the absolute URI The user decides (is willing to) use the proxy as the forwardingdereferencing agent for a predefined subset of the URI space
Definitions (22)
n Reverse Proxy a receiving agent that acts as a layer above some other server(s) and translates the received requests to the underlying servers protocol It behaves as an origin (HTTP) server on its connection towards the (HTTP) client and as a (CoAP) client on its connection towards the (CoAP) origin server The (HTTP) client uses the origin-form [I-Dietf-httpbis-p1-messaging] as a request- target URI
n Reverse and Forward proxies are technically very similar with main differences being that the former appears to a client as an origin server while the latter does not and that clients may be unaware they are communicating with a proxy
Reverse Cross-Protocol Proxy Deployment Scenario
HTTP-CoAP Response Code Mapping
Implementation Experience
n Direct experience from the draft authorsn Squid HTTP-CoAP mapping module
n University of Padovan httptelecomdeiunipditiotn Both Forward and Interception operation supported
n HTTP-CoAP proxy based on EvCoAPn KoanLogic University of Bologna and Salvatore
Loreto (as individual)n httpsgithubcomkoanlogicwebthingstreemasterbridgesw
libevcoapn The document is open to input from other implementations
Next Steps
n Does the WG recommend adoptionn Intended status Informational Best Practicen Purpose Reduce arbitrary variation between proxy
implementations thereby increasing interoperability
Backup
HTTP to CoAP URI Mapping Options (12)
n Embedded Mapping n In an embedded mapping approach the HTTP URI has embedded
inside it the authority and path part of the CoAP URI n Example The CoAP resource nodecoapsomethingnetfoo can
be accessed by an HTTP client by inserting in the request httphc-proxysomethingnetcoapnodecoapsomethingnetfoo The Cross-Protocol Proxy then maps the URI to coapnodecoapsomethingnetfoo
HTTP to CoAP URI Mapping Options (22)
n Homogeneous Mapping n In a homogeneous mapping approach only the scheme portion of the URI
needs to be mapped The rest of the URI (ie authority path etc) remains unchanged
n Example The CoAP resource coapnodecoapsomethingnetfoo can be accessed by an HTTP client by requesting httpnodecoapsomethingnetfoo The Cross-Protocol Proxy receiving the request is responsible to map the URI to coapnodecoapsomethingnetfoo
n Background info n The assumption in this case is that the HTTP client would be able to
successfully resolve nodecoapsomethingnet using DNS infrastructure to return the IP address of the HC proxy Most likely this would be through a two step DNS lookup where the first DNS lookup would resolve somethingnet using public DNS infrastructure
n Then the second DNS lookup on the subdomain coap and the host node would typically be resolved by a DNS server operated by the owner of domain somethingnet So this domain owner can manage its own internal node names and subdomain allocation which would correspond to the CoAP namespace
Group 3 ldquonew workrdquo
39
Transport of CoAP over SMS USSD and GPRSdraft-becker-core-coap-sms-gprs-03
Markus Becker Kepeng LiKoojana Kuladinithi Thomas Poumltsch
CoRE WG IETF-86 Orlando
1 10
ScenariosI In M2M communication IP connectivity is not alwayssupported by the constrained end-points
I Power savingI Coverage (GPRS 3G LTE)
I SMS and USSD based communication is almost alwayssupported
210
Changes from draft-01 to draft-03 (1)
I Added possible CONNONACK interactions Section 5
I Option name changed from Reply-To- to Response-To-Section 16 and Section 101
I Added URI schemeEg coap+tel+15105550101well-knowncore Section 11
I Added possible M2M proxy scenarios Section 14
3 10
Changes from draft-01 to draft-03 (2)
I Added reference to bormann-coap-misc for other SMSencoding Section 71
I Updated requirements on Uri-Host and Uri-Port forcoap+tel Section 10
I Added security considerations Transport and ObjectSecurity Section 15
I Chose CoAP option numbers and updated the optionnumber table to meet draft-ietf-core-coap-10 Table 1
I Added an IANA registration for the URI scheme coap+telSection 162
4 10
Feedback Split coap+tel into coap+smsand coap+ussd
I How else to differ the various transports in the URII Or is the transport to use decided by the implementationI See alsodraft-silverajan-core-coap-alternative-transports-01
5 10
Feedback Response-To-Scheme option
I Should there be a Response-To-Scheme optionadditionally to Response-To-Uri-Host andResponse-To-Uri-Path
I So that a CoAP end-point which receives a request by CoAPover non-IP transport can be instructed to also use thenon-IP transport for the response
I This would imply to add aResponse-To-Telephone-Subscriber and more options forother transports that have other URI schemes than coapand coaps
6 10
Feedback Selection of Transport by Client
I When a server is reachable by various transports howdoes a client decide which transport to use
I Client-side application congurationI Leave it to a proxy which uses cellular network lookupfunctions
7 10
Feedback Potential Threats
I Trigger expensive short messagesI Redirect trac to other addressesI More threats
I Are the security measures in the draft adequateI Whitelisting on serverI Relying on cellular network security (dedicated M2M APNs)I Object security on CoAP payload
8 10
Feedback Message Exchanges
I Figures 11-18 show possible message exchanges whenclient and server have two addresses
I With NON Not using CoAP retransmission capabilityI ACK on different transportI Additional (costly) message on Transport AI Request with Content
I Which ones are allowedI Which ones are meaningful
9 10
Next steps
I Rene Uri schemeI Response-To-Scheme optionI Selection of Message ExchangeI Rene Proxying
10 10
CoAP13 Communicaon13 with13 Alternave13 Transports
Bill Silverajan and Teemu SavolainenCore WG IETF 86 Orlando
031113
Objecves13 (In13 Scope)
bull Unambiguous13 representaon13 of13 transport13 to13 be13 used13 by13 CoAP
bull Details13 how13 the13 transport13 can13 carry13 CoAP13 packet
bull Focus13 is13 on13 what13 CoAP13 communicaons13 requirements13 are
bull Allow13 CoAP13 mechanisms13 to13 exploit13 cross-shy‐layer13 opmisaons
51
031113
Non13 Goals13 (Not13 in13 scope)
bull Applicaon-shy‐level13 QoS13 requirementsbull Real-shy‐me13 constraintsbull Ordering13 reliability13 congeson13 controlbull Applicaon13 and13 network13 adaptaonbull Mobility13 and13 readdressing13 supportbull Network13 protocol13 (eg13 IPsec)13 configuraon
52
031113
Use13 Cases
bull NAT13 and13 Firewall13 traversal13 with13 TCPbull Delay13 Tolerant13 Networkingbull Non-shy‐IP13 Low13 Energy13 Protocols
53
031113
Related13 Work
bull OMA13 Lightweight13 M2M13 Protocolbull CoAP13 over13 SMSGPRSUSSD
54
031113
What13 does13 the13 work13 entail
bull The13 ability13 to13 specify13 end13 point13 idenfiers13 and13 URIs13 to13 reflect13 which13 transport13 CoAP13 can13 use
bull The13 ability13 to13 register13 to13 resource13 directories13 resource13 types13 reflecng13 types13 of13 transport13 available
bull Ability13 for13 mul-shy‐transport13 nodes13 to13 select13 transport13 to13 use13 without13 significant13 alteraon13 to13 CoAP13 packet13 structure
55
031113
Points13 to13 consider
bull Requirements13 for13 transport13 layer13 protocol13 to13 carry13 CoAP13 packets
bull Representaon13 of13 URI13 scheme13 for13 generic13 transport13 protocols
bull Opon13 extensions13 for13 CoAP13 to13 express13 available13 transports
bull Mapping13 and13 message13 sizebull Security13 consideraons
56
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
URI13 =13 scheme13 13 13 authority13 path-shy‐abempty13 [13 query13 ]
bull Within13 the13 scheme13 namebull In13 the13 URI13 pathbull As13 a13 query13 component
57
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
bull Within13 the13 scheme13 namendash coap+tel+15105550101well-shy‐knowncorendash coap+tcpexamplecom5683temperaturendash coap+blel2cap[1234567890AB]4pulse
bull Easy13 URI13 parsing13 for13 transport13 type13 and13 idenfier
bull Each13 new13 scheme13 name13 requires13 IANA13 registraon
58
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
bull In13 the13 URI13 pathndash coaphostexamplecomtransport=tcpwell-shy‐knowncorert=core-shy‐rd
bull Easy13 adopon13 of13 new13 (and13 experimental)13 CoAP13 transports13 without13 IANA13 registraon
bull Caveat13 Uri-shy‐Path13 opon13 is13 a13 Crical13 CoAP13 opon13 see13 secon13 54113 of13 I-shy‐Diep-shy‐core-shy‐coap
59
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
bull As13 a13 URI13 query13 componentndash coaphostexamplecomwell-shy‐knowncorert=core-shy‐rdq=tcp
bull Also13 easy13 to13 adopt13 new13 (and13 experimental)13 CoAP13 transports13 without13 IANA13 registraon
bull Caveat13 Uri-shy‐Query13 opon13 is13 a13 Crical13 CoAP13 opon13 see13 secon13 54113 of13 I-shy‐Diep-shy‐core-shy‐coap
60
031113
URI13 Representaons13 for13 CoAPNon13 standard13 ways
bull Transport13 in13 the13 URI13 authority13 componentndash coaphost[port][transport]13 instead13 of13 coaphost[port]
bull Transport13 as13 a13 service13 URLndash servicecoaptcphostexamplecomwell-shy‐knowncorert=core-shy‐rd
bull Above13 two13 ways13 break13 exisng13 compability13 (although13 both13 are13 based13 on13 valid13 IANA13 URI13 registraons)
61
031113
URI13 Representaons13 for13 CoAPMiscellaneous13 Consideraons
bull Ensure13 that13 transport13 is13 defined13 unambiguously13 (eg13 L2CAP13 used13 by13 both13 BLE13 and13 standard13 Bluetooth13 so13 avoid13 rdquocoap+l2caprdquo13 or13 rdquotransport=l2caprdquo13 or13 rdquoq=l2caprdquondash Can13 be13 done13 as13 WG13 consensusndash Namespace13 approach13 eg13 rdquocoap+blel2caprdquo13 or13 rdquoq=blel2caprdquo
bull Allow13 end-shy‐points13 to13 use13 CoAP13 Resource13 Directory13 to13 register13 alternave13 transports13 and13 idenfiers13 and13 provide13 periodic13 updatesndash Register13 rdquocore-shy‐transportrdquo13 resource13 type
62
031113
Transport13 Consideraons
bull Uniqueness13 of13 end-shy‐point13 idenficaonbull Communicaon13 support13 Unidireconal13 Bidireconal13 1N13 (broadcast13 mulcast13 anycast)13 messaging
bull Binary13 encoding13 Network13 byte13 orderingbull MTU13 correlaon13 with13 CoAP13 PDU13 sizebull Transport13 latency
63
031113
Security13 Consideraons
bull Drar13 does13 not13 introduce13 new13 security13 requirements13 by13 itself
bull There13 may13 be13 privacy13 issues13 if13 nodes13 use13 telephone13 numbers13 or13 MAC13 addresses13 as13 public13 end13 point13 idenfiers
64
Akbar Rahman
IETF 86 March 2013 httpwwwietforgiddraft-rahman-core-sleepy-02txt
Enhanced Sleepy Node Support for CoAP
Introduction
It is expected that in CoAP networks there will be a certain portion of devices that are sleepy and which may occasionally go into a sleep mode (ie go into a low power state to conserve power) and subsequently have reduced CoAP protocol communication ability
This I-D proposes a minimal and efficient mechanism building on the Resource Directory concept (which will be integrated into a CoAP Proxy) to enhance sleepy node support in CoAP networks
Main Question from IETF-85 (Atlanta)
What performance benefit does the proposed Sleepy Node support solution give in a network that already has standard CoAP caching enabled
Sleepy Node Performance Analysis
Experimental Network
1-5 clients
Both Sleepy and Non-
Sleepy servers
Sleepy Node Performance Analysis Network Setup
CoAPSleepyServer(s)
CoAPSleepAwareReverseProxy
CoAP
Client(s)
Request
Response
Sleep9AwareCoREResourceDirectoryCapability
PublishedSleepParameters
Sleep9AwareCoAPStoreandForwardCapability Response
Request
SleepAwareCoAP503ResponseCapability
CoAPCachingCapability
bull Server supports publishing sleep parameters to proxy bull Eg Irsquom going to be asleep for X seconds
bull Proxy supports sleep-awareness capabilities bull Proxy also supports caching capability based off of maxAge bull Protocol flow similar to approach of Figure 1 (Synchronous RD Based Sleep
Tracking) of I-D
Proxy capabilities can be selectively enableddisabled
Proxy ndash Server Interface
Client ndash Proxy Interface
CoAP Sleep-Aware Reverse Proxy Features CoRE Sleep-aware Resource Directory
Support storing published sleep parameters from CoAP servers sleepState (AWAKE ASLEEP) sleepDuration
Sleep-aware CoAP 503 Response Capability If CoAP request to a sleeping server is received proxy returns a
lsquo503 Retry-Afterrsquo response to client 503 contains a timestamp indicating when the sever will wake back up
(timestamp delivered in CoAP maxAge option) Sleep-aware CoAP Store-and-Forward Capability
If CoAP request to a sleeping server is received proxy stores request until server wakes up and then forwards it
Caching capability Cache GET responses from server if maxAge option is present
(this is not a sleep aware feature)
Goals of Performance Analysis
For networks having sleepy servers provide measurements to quantify the impact that CoAP sleep-awareness capabilities can have
See if sleep-awareness capabilities can
provide additional benefits even when CoAP caching is used
Overview of Performance Analysis Performed The analysis was broken up into a set of test scenarios Each test scenario used a different combination of the following
variables Client issued GET requests Server was configured as a sleepy or non-sleepy server Proxy caching of GET responses was enabled or disabled Proxy sleep-aware 503 response capability was enabled or disabled Proxy store-and-forward capability was enabled or disabled maxAge in GET responses ndash Two values were tested 60sec and 5sec of Clients ndash Two values were used ndash 1 client and 5 clients
For comparison purposes the following were held constant across all test scenarios Client issued a fixed number of requests (100) across all test scenarios Client used a delay between each GET request (35sec) to better exercise
proxyrsquos caching and sleep-awareness capabilities For sleepy server test scenarios the server slept 60 sec awake for 3 sec
Format of Results The following results were collected for each
test scenario
Breakdown of the and types of transactions occurring between clientproxyserver
ldquoGETrdquo ndash Test Scenario Results
GET ndash Description of Test Scenarios
TestScenarios-GET
Scenario
CoAPSleepyServerSe7ngs CoAPSleepAwareReverseProxySe7ngs CoAPClientSe7ngs
SleepDuragton(sec)
AwakeDuragton(sec)
maxAge(sec) Caching SleepAwareSAF+
503NumberofClients
NumberofGETs
DelayBetweenClient
Requests(sec)
1a 0 Always 60 Enabled Disabled 1 100 35
1b 60 3 60 Enabled Disabled 1 100 35
1c 60 3 60 Enabled Enabled 1 100 35
2a 0 Always 60 Enabled Disabled 5 100 35
2b 60 3 60 Enabled Disabled 5 100 35
2c 60 3 60 Enabled Enabled 5 100 35
3a 0 Always 5 Enabled Disabled 5 100 35
3b 60 3 5 Enabled Disabled 5 100 35
3c 60 3 5 Enabled Enabled 5 100 35
ldquoGETrdquo ndash Test Scenario 1 Results
maxAge = 60 and 1 Client
GET ndash Scenario 1 ClientProxy Interface Transaction Mix
Scenarios 1a - Non-Sleepy Server Caching Proxy maxAge = 60sec 1b- Sleepy Server Caching Proxy maxAge = 60sec 1c - Sleepy Server Sleep Aware Proxy maxAge = 60sec
Sleep Aware Proxy has better performance for sleepy servers
0
100
200
300
400
500
600
700
1a 1b 1c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
GET ndash Scenario 1 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
Scenarios 1a - Non-Sleepy Server Caching Proxy maxAge = 60sec 1b- Sleepy Server Caching Proxy maxAge = 60sec 1c - Sleepy Server Sleep Aware Proxy maxAge = 60sec
0
100
200
300
400
500
600
700
800
1a 1b 1c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
ldquoGETrdquo ndash Test Scenario 2 Results
maxAge = 60 and 5 Clients
GET ndash Scenario 2 ClientProxy Interface Transaction Mix
Sleep Aware Proxy has slightly better performance for sleepy servers
0
200
400
600
800
1000
1200
1400
2a 2b 2c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
Scenarios 2a - Non-Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2b- Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2c - Sleepy Server Sleep Aware Proxy maxAge = 60sec 5 Clients
See ldquoExperimental Artifactsrdquo Note 1
GET ndash Scenario 2 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has slightly better performance for sleepy servers
0
50
100
150
200
250
300
350
400
2a 2b 2c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
Scenarios 2a - Non-Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2b- Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2c - Sleepy Server Sleep Aware Proxy maxAge = 60sec 5 Clients
See ldquoExperimental Artifactsrdquo Note 2
Experimental Artifacts Note 1
Currently in the experiment the sleep aware proxy checks the cached state of a resource before putting a request into its Store-and-forward queue while a server is sleeping Once in the queue the proxy unconditionally forwards the queued requests to the server once it wakes up This is not the most efficient setup and can easily be improved If the proxy instead checks its cache again before forwarding each queued request it may not need to forward the request to the server For example if there are two queued GET requests in the proxyrsquos queue that address the same resource Only the first request needs to be sent to the server the second request can use the cached response from the first request
Note 2 Currently in the experiment the sleepy server sends a sleepState PUT request to the
proxy each time it goes to sleep This is not the most efficient setup and can easily be improved For example if the server assumes that the proxy can keep track of its ONOFF cycles with its internal timers (eg as per Fig 1 of I-D) then the number of messages from the sleepy server dramatically goes down
ldquoGETrdquo ndash Test Scenario 3 Results
maxAge = 5 and 5 Clients
GET ndash Scenario 3 ClientProxy Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
Scenarios 3a - Non-Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3b- Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3c - Sleepy Server Sleep Aware Proxy maxAge = 5sec 5 Clients
0
500
1000
1500
2000
2500
3000
3500
4000
4500
5000
3a 3b 3c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
GET ndash Scenario 3 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
0
1000
2000
3000
4000
5000
6000
7000
3a 3b 3c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
Scenarios 3a - Non-Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3b- Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3c - Sleepy Server Sleep Aware Proxy maxAge = 5sec 5 Clients
Conclusions
Conclusions These results show that sleep-aware CoAP
proxy features can significantly optimize communication with sleepy servers in most scenarios
These results also show that sleep-
awareness capabilities can provide additional benefits above and beyond CoAP caching in most scenarios
Backup
Current CoAP Support of Sleepy Node (12)
CoAP proxies can use a previously cached response to service a new GET request for a sleepy origin server (as in HTTP) But if no valid cache then proxy has to attempt to
retrieve and may fail if origin server is sleeping [I-Dietf-core-coap]
Clients can discover list of resources from RD (GET rd-lookuphellip) for sleepy servers But attempt to GET resource from sleepy origin server
may fail if origin server is sleeping [IDietf-core-link-format amp IDshelby-core-resource-
directory]
Current CoAP Support of Sleepy Node (22)
Lower layer support for sleepy nodes in most wireless technologies (eg WiFi ZigBee) But limited to MAC packet scheduling for sleepy nodes
and not aware of specific needs of IP applications (like CoAP)
Proposal ndash RD Based Sleep Tracking (14)
The current CoAP approach to support sleepy nodes can be significantly improved by introducing RD based mechanisms for a CoAP client to determine whether A targeted resource is located on a sleepy server A sleepy server is currently in sleep mode or not
There is any associated caching Proxy (possibly the RD itself) for a sleepy server
Proposal ndash RD Based Sleep Tracking (24)
We define the following new RD attributes to characterize the properties of a sleepy node SleepState - Indicates whether the node is currently in
sleep mode or not (ie Sleeping or Awake) SleepDuration - Indicates the maximum duration of time
that the node stays in sleep mode TimeSleeping - Indicates the length of time the node
has been sleeping (ie if Sleep State = Sleeping) NextSleep - Indicates the next time the node will go to
sleep (ie if Sleep State = Awake)
CachingProxy ndash Indicates the caching proxy of the sleepy node (ie the RD itself or another node)
Proposal ndash RD Based Sleep Tracking (34)
These attributes are all server (node) level and are new parameters added to the RD URI Template Variables
Finally we also define a new lookup-type (ss) for the RD lookup interface specified in [I-Dshelby-core-resource-directory] This new lookup-type supports looking up the
ldquoSleepStaterdquo (ss) of a specified end-point
Proposal ndash RD Based Sleep Tracking (44)
The three time based parameters (SleepDuration TimeSleeping NextSleep) can be based on either an absolute network time (for a time synchronized network) or a relative local time (measured at the local node)
Following the approach of [I-Dietf-core-link-format] and [I-Dshelby-core-resource-directory] sleep parameters for sleepy servers can be stored by the server in the RD and accessed by all interested clients
Examples of using these parameters in a synchronous or asynchronous manner are shown in the I-D
http6lowappnet coreIETF86 2013-03-12-13
We assume people have read the drafts
Meetings serve to advance difficult issues by making good use of face-to-face communications
Note Well Be aware of the IPR principles according to RFC 3979 and its updates
uumlBlue sheetsuumlScribe(s)
96
drar-shy‐iep-shy‐core-shy‐coapsubmiqed13 to13 IESG
2013-shy‐03-shy‐13
97
OMA Lightweight M2M Overview(A new standard using lots of IETF specs including DTLS
CoAP Block Observe Resource Directory SenMLhellip)
Zach ShelbyCoRE WG IETF-86 Orlando
OMA Lightweight M2Mbull Open Mobile Alliance is well known for Device Management (DM)bull OMA Lightweight M2M is a new standard from the alliance
ndash Focused on constrained Cellular and sensor network M2M devicesndash Driven by leading operators and vendors
bull Scopendash Interfaces protocol amp security between Device and Serverndash Object and Resource modelndash Bootstrap Device Access Control Connectivity and Firmware Objects
bull Draft Specifications are availablendash httpmemberopenmobileallianceorgftpPublic_documentsDM
LightweightM2MPermanent_documentsOMA-TS-LightweightM2M-V1_0_0-20130301-Dzip
bull Timelinendash Requirements and Architecture completed 3Q2012ndash Spec ready for Consistency Review 2Q2013ndash Candidate Approval expected 3Q2013
2 CoRE WG IETF-86 Orlando
Architecture
3
Scope of LWM2M
CoRE WG IETF-86 Orlando
Object Model
bull A Client has one or more Object Instancesbull An Object is a collection of Resourcesbull A Resource is an atomic piece of information
ndash Read Written or Executed
bull Resources can have multiple instancesbull Objects and Resources are identified by a
16-bit Integer Instances by an 8-bit Integerbull ObjectsResources are accessed with
simple URIs Object IDObject InstanceResource ID
eg 1213
4 CoRE WG IETF-86 Orlando
CoRE WG IETF-86 Orlando
CoRE Resource Directory
draft-shelby-core-resource-directory-05
Z Shelby C Bormann S Krco
Backgroundbull Not a new concept
ndash think web search engine or any link directorybull Defines the interfaces to a Resource Directorybull Based on Web Linking framework and the CoRE Link Formatbull Generic REST design for use over HTTP and CoAPbull Used by OMA Lightweight M2Mbull Has already been deployed
ndash In traffic monitoring systemsndash In street lighting systemsndash For vehicular asset trackingndash By a major Cellular M2M operator
Changes since -04
bull Restricted Update to parameter updatesbull Added pagination support for the Lookup interfacebull Changed rt= to et= for the registration amp update
interfacebull Added group support
Group Management
bull RD now includes group management featuresbull New Group Function Set
ndash Register a groupbull Group name domain multicast address endpoint members
ndash Remove a groupbull Group lookup using the Lookup Function Set
ndash List registered groupsndash Find the members of a groupndash Find groups with certain endpoints or resources
Registering a Group
EP RD
| |
| - POST rd-groupgp=lights ltgtep=node1 --gt |
| |
| |
| lt---- 201 Created Location rd-group12 ---- |
| |
Req POST coaprdexamplecomrd-groupgp=lights
Payload
ltgtep=node1
ltgtep=node2
Res 201 Created
Location rd-group12
Looking up Group Members
Client RD
| |
| ----- GET rd-lookupepgp=lights1 ----------------------gt |
| |
| |
| lt-- 205 Content ltrdgtd=domain1ltrdgtd=domain2 --------- |
| |
Req GET rd-lookupepgp=lights1
Res 205 Content
ltcoaphostportgtep=node1
ltcoaphostportgtep=node2rdquo
Things for the futurebull Support for JSON representation of Web Links
ndash httptoolsietforgiddraft-bormann-core-links-json-02txtbull Registry for RD registration query parameters
ndash Already OMA Lightweight has defined some new onesbull More examples
Group 3 ldquonew workrdquo(continued)
109
drar-shy‐greevenbosch-shy‐core-shy‐profile-shy‐descripon-shy‐01Bert13 GreevenboschJeroen13 Hoebeke
Isam13 IshaqFloris13 Van13 den13 Abeele
Descripon
bull JSON13 format13 for13 signalling13 the13 servers13 capabilies
bull Signalling13 of13 supported13 opons13 media13 types13 and13 block13 sizendash Other13 items13 can13 be13 added
bull Filtering13 on13 specific13 fields13 through13 URI-shy‐Querybull Link13 hqpdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐profile-shy‐descripon
well-shy‐knownprofile
bull To13 acquire13 profile13 data13 of13 resources13 on13 a13 parcular13 service13 the13 well-shy‐knownprofile13 URI-shy‐path13 is13 introduced
bull For13 example13 to13 get13 all13 informaon13 from13 sensors13 served13 by13 wwwexampleorg13 we13 can13 do13 a13 GET13 to13 coapwwwexampleorgwell-shy‐knownprofile
bull Filtering13 on13 parcular13 resources13 is13 done13 through13 URI-shy‐Queries
Format
bull Currently13 the13 following13 fields13 are13 definedndash ldquopathrdquo13 contains13 the13 URI-shy‐path13 associated13 with13 a13 resource
ndash ldquooprdquo13 a13 numerical13 list13 of13 supported13 opon13 numbers
ndash ldquocfrdquo13 a13 numerical13 list13 of13 supported13 content-shy‐format13 numbers
ndash ldquob1srdquo13 ldquob2srdquo13 supported13 block13 sizes13 for13 Block113 and13 Block213 respecvely
Examplebull On13 the13 right13 is13 an13 example13 of13 a13 camera13 sensor13 at13 coapwwwexampleorgcam13 that13 supports13 the13 Uri-shy‐Host13 (3)13 ETag13 (4)13 Uri-shy‐Port13 (7)13 Uri-shy‐Path13 (11)13 Content-shy‐Format13 (12)13 Token13 (19)13 Block213 (23)13 and13 Proxy-shy‐Uri13 (35)13 opons
bull The13 supported13 content13 formats13 are13 textplain13 (0)13 applicaon13 link-shy‐format13 (40)13 and13 applicaonjson13 (50)
bull The13 supported13 Block213 can13 use13 25613 or13 51213 byte13 blocks
Req13 GET13 coapwwwexampleorgwell-shy‐knownprofile13 Res13 20513 Content13 (applicationjson)13 13 13 13 profile13 13 13 13 13 13 13 13 pathcam13 13 13 13 op[3471112192335]13 13 13 13 13 cf[04050]13 13 13 13 13 b2s[45]13 13 13 13
Filtering13 through13 use13 of13 URI-shy‐Query
bull Filtering13 can13 be13 done13 through13 the13 URI-shy‐Querybull Query13 format13 N=V
ndash N13 is13 a13 profile13 fieldndash V13 is13 the13 desired13 value
bull Examplesndash To13 find13 resources13 that13 support13 content13 format13 ldquoapplicaonjsonrdquo
13 GET13 wwwexampleorgwell-shy‐knownprofilecf=50ndash To13 get13 informaon13 about13 the13 camera
13 GET13 wwwexampleorgwell-shy‐knownprofilepath=cam
Open13 issues
bull Which13 other13 profile13 data13 needs13 signallingndash Content-shy‐type13 for13 different13 methods
bull Fix13 the13 order13 in13 which13 the13 profile13 fields13 must13 appearndash Non-shy‐fixed13 order13 easier13 extensible
bull Inheritance13 of13 a13 profile13 descriponbull Extend13 usage13 to13 signal13 the13 client13 profilebull Integraon13 with13 link13 format
Thank13 youQuesons
drar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval-shy‐00
Bert13 Greevenbosch
Descripon
bull The13 ldquoMinimumRequestInterval13 opon13 can13 be13 used13 to13 indicate13 the13 minimum13 me13 between13 two13 requests13 in13 a13 transacon
bull Originally13 intended13 for13 Block13 but13 also13 usable13 for13 other13 transaconsndash Example13 browsing13 a13 server
bull The13 goal13 is13 to13 reduce13 the13 server13 load13 and13 network13 traffic
bull Link13 hqpsdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval
Usage
bull The13 client13 keeps13 the13 server13 informed13 about13 its13 request13 speed13 through13 inclusion13 of13 the13 ldquoMinimumRequestIntervalrdquo13 opon
bull In13 responses13 the13 server13 fixes13 the13 minimum13 request13 interval13 through13 the13 same13 opon
bull The13 client13 obeys13 the13 speed13 indicated13 by13 the13 server
bull The13 client13 can13 send13 slower13 but13 not13 faster
Advantages
bull The13 server13 has13 means13 to13 limit13 the13 amount13 of13 incoming13 traffic
bull The13 server13 can13 prevent13 to13 become13 overloaded13 with13 too13 many13 tasks
bull The13 server13 does13 not13 need13 arficially13 slow13 down13 the13 client13 by13 sending13 late13 ACKsndash No13 need13 to13 keep13 track13 of13 delayed13 ACKsndash The13 server13 can13 perform13 other13 tasks13 instead
bull Reduced13 network13 traffic
Thank13 youQuesons
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-links-json-02txt
123
RFC 6690 (link-format) documents are somewhat foreign to many web app developerssect would prefer to have them in JSON format
There is no standard way to represent link-format documents in applicationssect but everyone knows how to handle JSON
Define a standard JSON translation for link-format
Itrsquos
not
rock
et
scien
ce
ltsensorsgtct=40title=Sensor Index ltsensorstempgtrt=temperature-cif=sensor ltsensorslightgtrt=light-luxif=sensor lthttpwwwexamplecomsensorst123gt anchor=sensorstemprel=describedby lttgtanchor=sensorstemprel=alternate [hrefsensorsct40titleSensor Index hrefsensorstemprttemperature-cifsensor hrefsensorslightrtlight-luxifsensor hrefhttpwwwexamplecomsensorst123 anchorsensorstempreldescribedby hreftanchorsensorstemprelalternate]
124
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-ipsec-for-coap-00txt
IPsec definitions for CoAP Mostly placeholder at this time Who has implementation experience with this
125
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-cross-reverse-convention-00txt
This draft has two lines of payload(based on a WGLC comment by Cullen Jennings)
coap12344567foobara=3
httpwwwproxycomwellknowncore-translate1234_4567foobara=3
Is that a useful convention to have
126
Insert CI slides here
127
128
0
5
10
15
20
25
30
35
40
10 20 30 40 50 60 70
good
put (
pps)
pps
Goodput vs pps (Econotags)
goodput
[Khattak preliminary]
Congestion Control
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-cocoa-00txt
ldquoadvancedrdquo cc (The draft is just a first shot) Others may have better ideas
129
Insert post-WGLC discussion slides here
130
Stop Continue Start
131
An Agile Retrospective
http6lowappnet coreIETF86 2013-03-12-13
Stop
132
Endless new CoAP optionssect instead use RESTful as much as possible
Move general security lifecycle out Looking at theoretical problems
http6lowappnet coreIETF86 2013-03-12-13
Continue
Interops Running code Look at real-world examples and deployments Solve their actual problems
sect Unilateral enhancements eg higher performance congestion control
sect Transports (SMS hellip)sect Make Web linking and Directories more and more usefulsect RESTful Design Paradigms for real-world problems
133
http6lowappnet coreIETF86 2013-03-12-13
Start
Further push into the (browser) web world (HTML5 browser security)
Specific supporting worksect SenMLsect URI work (dev URN hellip)sect Security Processes (next slide)
Spin outsect (We donrsquot really get to decide where this is done)
134
http6lowappnet coreIETF86 2013-03-12-13
Security
Integrate Application Network Group Keyingsect Tunnel-free setup
Donrsquot redo what has been done alreadysect ZigBee IP is finesect But what about other scenarios
Simple REST interfaces for working with keying materials and authorizationsect Start with defining objectives
Object Security for Constrained Nodes135
Re-chartering CoREWhat do we want to do now that wersquore grown up
Zach ShelbyCoRE WG IETF-86 Orlando
What is the scope
bull So we have a protocol and Web Linking what next
bull Keep with what we know besthellip1 Enhancements around CoAP2 New transports for CoAP3 New representations for Web Links4 General application layer solutions
CoRE WG IETF-86 Orlando 2
Enhancements around CoAP
bull Advanced congestion control
CoRE WG IETF-86 Orlando 3
New Transports for CoAP
bull Infrastructure for CoAP over foondash httptoolsietforgiddraft-silverajan-core-
coap-alternative-transports-01txtbull CoAP over SMS
ndash httptoolsietforgiddraft-becker-core-coap-sms-gprs-03txt
ndash OMA Lightweightbull CoAP over TCP
ndash httptoolsietforgiddraft-li-core-coap-payload-length-option-01txt
CoRE WG IETF-86 Orlando 4
New support for Web Links
bull JSON Web Linksndash httptoolsietforgiddraft-bormann-core-links-
json-02txt
2332010 CoRE WG IETF-77 Anaheim 5
General application layer solutions
bull Resource Directoryndash httptoolsietforgiddraft-shelby-core-
resource-directory-05txtndash OMA Lightweight
2332010 CoRE WG IETF-77 Anaheim 6
http6lowappnet coreIETF86 2013-03-12-13
Tickets
hellip are our way to make the steps forward are at
http toolsietforgwgcore Updates are sent to the mailing list
sect Please review When we close a ticket please review once more
12
Group 2 groupcomm
13
Akbar RahmanEsko Dijk
IETF 86 March 2013httpwwwietforgiddraft-ietf-core-groupcomm-05txt
Group Communication for CoAP
Summary of Changes (14)
n I-D had two updates (Rev 04 amp 05) after IETF-85 (Atlanta) Many of the updates were due to the detailed review by Peter van der Stokn Thank you Peter for your valuable comments
n Changes from ietf-03 to ietf-04 n Section 23 (Potential Solutions for Group Communications) moved to
draft-dijk-core-groupcomm-misc (266)n Added reference to draft-keoh-tls-multicast-security to section 6 (Security
Considerations) n Appendix B (CoAP-Observe Alternative to Group Communications) moved
to draft-dijk-core-groupcomm-misc (267) n Deleted section 8 (Conclusions) as it is redundant (268) n Simplified light switch use case (269) by splitting into basic operations and
additional functions (269)
Summary of Changes (24)
n Changes from ietf-03 to ietf-04 (Continued) n Moved section 37 (CoAP Multicast and HTTP Unicast Interworking) to
draft-dijk-core-groupcomm-misc (270) n Moved section 331 (DNS-SD) and 332 (CoRE Resource Directory) to
draft-dijk-core-groupcomm-miscClarified that DNS based features are optional (272)
n Focus section 35 (Configuring Group Membership) on a single proposed solution
n Scope of section 53 (Use of MLD) widened to multicast destination advertisement methods in general
n Rewrote section 22 (Scope) for improved readibility n Moved use cases that are not adressed to draft-dijk-core-groupcomm-miscn Various editorial updates for improved readibility
Summary of Changes (34)
n Changes from ietf-04 to ietf-05 n Added a new section 39 (Exceptions) that highlights that IP multicast (and
hence group communications) is not always available (187) n Included guidelines on when (not) to use CoAP responses to multicast
requests and when (not) to accept multicast requests (273) n Added guideline on use of core-block for minimizing response size (275)n Restructured section 6 (Security Considerations) to more fully describe
threats and threat mitigation (277) n Clearly indicated that DNS resolution and reverse DNS lookup are optional n Removed confusing text about a single group having multiple IP addresses
If multiple IP addresses are required then multiple groups (with the same members) should be created
n Removed repetitive text about the fact that group communications is not guaranteed
Summary of Changes (44)
n Changes from ietf-04 to ietf-05 (Continued) n Merged previous section 52 (Multicast Routing) into 31 (IP Multicast
Routing Background) and added link to section 52 (Advertising Membership of Multicast Groups)
n Clarified text in section 38 (Congestion Control) regarding precedence of use of IP multicast domains (ie first try to use link-local scope then site-local scope and only use global IP Communication for CoAP multicast as a last resort)
n Extended group resource manipulation guidelines with use of preconfigured portspaths for the multicast group
n Consolidated all text relating to ports in a new section 33 (Port Configuration)
n Clarified that all methods (GETPUTPOST) for configuring group membership in endpoints should be unicast (and not multicast) in section 37 (Configuring Group Membership In Endpoints)
n Various editorial updates for improved readability
Discussion item (11)
n Solution for Configuring Group Membership (no ticket)n Example of (unicast) configuring an endpoint to be part of one multicast
groupReq POST gp (Content-Format applicationjson)
n floor1westbldg6examplecom ip ff154200f7feed3714cb Res 204 Changed
n Where the ldquogprdquo resource has resource type (rt) ldquocoregprdquo which is defined for this purpose
n Question Do we want specify such a solution (or for example leave it completely up to implementation)
Open Issues(15)
n Review Groupcomm requirements language (271)n Decision made to keep requirements language for informational draftn Each use of MAYMUSTSHOULD etc is to be reviewed
Open Issues(25)
n Add section on multicast via Proxy and its limitations (274)n Add a section to explain the issues amp limitations of doing CoAP multicast
requests via a CoAP Proxy n Goal is to warn and guide implementers in this subject n Also such a section would provide a placeholderreminder of the problems
that might be addressed further in the futuren Based on IETF 85 CoRE WG meeting discussion on Multicast CoAP
requests via a Proxy Discussion summary for referencen Aggregation of responses in a proxy is difficult since it doesnt know
when to stop aggregating responses n SIP tried to deal with this problem but didnt solve it n There may be an expectancy of CoAP client to get single response
back from proxy not multiple The client in this case may not even know what it could expect It may not even know the Proxy-URI contains a multicast target
n Presented via-proxy use case exposes gap in the core-coap specification regarding multicast via proxy (Note Expectation is that core-coap wonrsquot address it in the first planned RFC release)
Open Issues(35)
n Issues with twomultiple Resource Directories in use case (280)n Some potential issues with RD came out of review Peter van der Stok and
WG discussion IETF85 n There are two RD servers use case shows that only one is found despite
the fact that site-local multicast is used - should be two RDs found n Proposal simplify use case to a single RD server on the backbone to avoid
such RD-specific issues like synchronization of RD information between servers
Open Issues(45)
n Add single-subnet configuration to use cases (278)n Suggested by review Peter van der Stok and IETF85 WG discussion that
its best to start explaining the simplebasic cases and then gradually build up complexity
n Simplest case not shown yet would be a single subnet network configuration which is currently not present in the I-D only the 2-subnet configuration of Fig 1
n Question Do we need to add such case or doesnt it add muchn (Note that core-coap Figure 22 already shows the simplest case of link-local
multicast)
Open Issues(55)
n Add use case with controller (client) located on the backbone (279)n Suggested by discussion following review Peter van der Stok n Case missing where a controller (client) is located on the backbonen Question Do we need to add such case or does it add much
Group 2a other old friends
25
Angelo Castellani Salvatore Loreto Akbar Rahman Thomas Fossati Esko Dijk
IETF 86 March 2013httpwwwietforgiddraft-castellani-core-http-mapping-07txt
Best Practices for HTTP-CoAP Mapping
Implementation
Summary of Changes (from -06 rev)
n Based on discussion at last IETF-85 (Atlanta)n Clarification of HTTP-CoAP Proxies
n Definitionn Placementn Benefits
n Clarification of HTTP-CoAP URI mapping options
Goals of I-D
n For Reverse HTTP-CoAP Cross Protocol Proxyn Provide more detailed information to proxy designers (beyond
Section 10 of [I-Dietf-core-coap]) to help implement proxies that correctly inter-work with other CoAP and HTTP clientserver implementations that adhere to the specifications
n Define a consistent set of guidelines that a HTTP-to-CoAP proxy implementation MAY adhere to The main reason of adhering to such guidelines is to reduce variation between proxy implementations thereby increasing interoperabilityn As an example use case a proxy conforming to these guidelines made
by vendor A can be easily replaced by a proxy from vendor B that also conforms to the guidelines
I-D Outline
n Guidance on HTTP to CoAP URI mappingn HTTP-CoAP Reverse cross-protocol proxy implementation
n Placementn Response code amp media type translationsn Caching and congestion controln Cache refresh via Observen Use of CoAP blockwise transfern Security translation
n Security Considerationsn Traffic overflown Handling secured exchanges
Definitions (12)
n Cross-Protocol Proxy (or Cross Proxy) is a proxy performing a cross- protocol mapping in the context of this document a HTTP-CoAP (HC) mapping A Cross-Protocol Proxy can behave as a Forward Proxy Reverse Proxy or Interception Proxy n Note In this document we focus on the Reverse Proxy mode of the
Cross-Protocol Proxy
n Forward Proxy a message forwarding agent that is selected by the client usually via local configuration rules to receive requests for some type(s) of absolute URI and to attempt to satisfy those requests via translation to the protocol indicated by the absolute URI The user decides (is willing to) use the proxy as the forwardingdereferencing agent for a predefined subset of the URI space
Definitions (22)
n Reverse Proxy a receiving agent that acts as a layer above some other server(s) and translates the received requests to the underlying servers protocol It behaves as an origin (HTTP) server on its connection towards the (HTTP) client and as a (CoAP) client on its connection towards the (CoAP) origin server The (HTTP) client uses the origin-form [I-Dietf-httpbis-p1-messaging] as a request- target URI
n Reverse and Forward proxies are technically very similar with main differences being that the former appears to a client as an origin server while the latter does not and that clients may be unaware they are communicating with a proxy
Reverse Cross-Protocol Proxy Deployment Scenario
HTTP-CoAP Response Code Mapping
Implementation Experience
n Direct experience from the draft authorsn Squid HTTP-CoAP mapping module
n University of Padovan httptelecomdeiunipditiotn Both Forward and Interception operation supported
n HTTP-CoAP proxy based on EvCoAPn KoanLogic University of Bologna and Salvatore
Loreto (as individual)n httpsgithubcomkoanlogicwebthingstreemasterbridgesw
libevcoapn The document is open to input from other implementations
Next Steps
n Does the WG recommend adoptionn Intended status Informational Best Practicen Purpose Reduce arbitrary variation between proxy
implementations thereby increasing interoperability
Backup
HTTP to CoAP URI Mapping Options (12)
n Embedded Mapping n In an embedded mapping approach the HTTP URI has embedded
inside it the authority and path part of the CoAP URI n Example The CoAP resource nodecoapsomethingnetfoo can
be accessed by an HTTP client by inserting in the request httphc-proxysomethingnetcoapnodecoapsomethingnetfoo The Cross-Protocol Proxy then maps the URI to coapnodecoapsomethingnetfoo
HTTP to CoAP URI Mapping Options (22)
n Homogeneous Mapping n In a homogeneous mapping approach only the scheme portion of the URI
needs to be mapped The rest of the URI (ie authority path etc) remains unchanged
n Example The CoAP resource coapnodecoapsomethingnetfoo can be accessed by an HTTP client by requesting httpnodecoapsomethingnetfoo The Cross-Protocol Proxy receiving the request is responsible to map the URI to coapnodecoapsomethingnetfoo
n Background info n The assumption in this case is that the HTTP client would be able to
successfully resolve nodecoapsomethingnet using DNS infrastructure to return the IP address of the HC proxy Most likely this would be through a two step DNS lookup where the first DNS lookup would resolve somethingnet using public DNS infrastructure
n Then the second DNS lookup on the subdomain coap and the host node would typically be resolved by a DNS server operated by the owner of domain somethingnet So this domain owner can manage its own internal node names and subdomain allocation which would correspond to the CoAP namespace
Group 3 ldquonew workrdquo
39
Transport of CoAP over SMS USSD and GPRSdraft-becker-core-coap-sms-gprs-03
Markus Becker Kepeng LiKoojana Kuladinithi Thomas Poumltsch
CoRE WG IETF-86 Orlando
1 10
ScenariosI In M2M communication IP connectivity is not alwayssupported by the constrained end-points
I Power savingI Coverage (GPRS 3G LTE)
I SMS and USSD based communication is almost alwayssupported
210
Changes from draft-01 to draft-03 (1)
I Added possible CONNONACK interactions Section 5
I Option name changed from Reply-To- to Response-To-Section 16 and Section 101
I Added URI schemeEg coap+tel+15105550101well-knowncore Section 11
I Added possible M2M proxy scenarios Section 14
3 10
Changes from draft-01 to draft-03 (2)
I Added reference to bormann-coap-misc for other SMSencoding Section 71
I Updated requirements on Uri-Host and Uri-Port forcoap+tel Section 10
I Added security considerations Transport and ObjectSecurity Section 15
I Chose CoAP option numbers and updated the optionnumber table to meet draft-ietf-core-coap-10 Table 1
I Added an IANA registration for the URI scheme coap+telSection 162
4 10
Feedback Split coap+tel into coap+smsand coap+ussd
I How else to differ the various transports in the URII Or is the transport to use decided by the implementationI See alsodraft-silverajan-core-coap-alternative-transports-01
5 10
Feedback Response-To-Scheme option
I Should there be a Response-To-Scheme optionadditionally to Response-To-Uri-Host andResponse-To-Uri-Path
I So that a CoAP end-point which receives a request by CoAPover non-IP transport can be instructed to also use thenon-IP transport for the response
I This would imply to add aResponse-To-Telephone-Subscriber and more options forother transports that have other URI schemes than coapand coaps
6 10
Feedback Selection of Transport by Client
I When a server is reachable by various transports howdoes a client decide which transport to use
I Client-side application congurationI Leave it to a proxy which uses cellular network lookupfunctions
7 10
Feedback Potential Threats
I Trigger expensive short messagesI Redirect trac to other addressesI More threats
I Are the security measures in the draft adequateI Whitelisting on serverI Relying on cellular network security (dedicated M2M APNs)I Object security on CoAP payload
8 10
Feedback Message Exchanges
I Figures 11-18 show possible message exchanges whenclient and server have two addresses
I With NON Not using CoAP retransmission capabilityI ACK on different transportI Additional (costly) message on Transport AI Request with Content
I Which ones are allowedI Which ones are meaningful
9 10
Next steps
I Rene Uri schemeI Response-To-Scheme optionI Selection of Message ExchangeI Rene Proxying
10 10
CoAP13 Communicaon13 with13 Alternave13 Transports
Bill Silverajan and Teemu SavolainenCore WG IETF 86 Orlando
031113
Objecves13 (In13 Scope)
bull Unambiguous13 representaon13 of13 transport13 to13 be13 used13 by13 CoAP
bull Details13 how13 the13 transport13 can13 carry13 CoAP13 packet
bull Focus13 is13 on13 what13 CoAP13 communicaons13 requirements13 are
bull Allow13 CoAP13 mechanisms13 to13 exploit13 cross-shy‐layer13 opmisaons
51
031113
Non13 Goals13 (Not13 in13 scope)
bull Applicaon-shy‐level13 QoS13 requirementsbull Real-shy‐me13 constraintsbull Ordering13 reliability13 congeson13 controlbull Applicaon13 and13 network13 adaptaonbull Mobility13 and13 readdressing13 supportbull Network13 protocol13 (eg13 IPsec)13 configuraon
52
031113
Use13 Cases
bull NAT13 and13 Firewall13 traversal13 with13 TCPbull Delay13 Tolerant13 Networkingbull Non-shy‐IP13 Low13 Energy13 Protocols
53
031113
Related13 Work
bull OMA13 Lightweight13 M2M13 Protocolbull CoAP13 over13 SMSGPRSUSSD
54
031113
What13 does13 the13 work13 entail
bull The13 ability13 to13 specify13 end13 point13 idenfiers13 and13 URIs13 to13 reflect13 which13 transport13 CoAP13 can13 use
bull The13 ability13 to13 register13 to13 resource13 directories13 resource13 types13 reflecng13 types13 of13 transport13 available
bull Ability13 for13 mul-shy‐transport13 nodes13 to13 select13 transport13 to13 use13 without13 significant13 alteraon13 to13 CoAP13 packet13 structure
55
031113
Points13 to13 consider
bull Requirements13 for13 transport13 layer13 protocol13 to13 carry13 CoAP13 packets
bull Representaon13 of13 URI13 scheme13 for13 generic13 transport13 protocols
bull Opon13 extensions13 for13 CoAP13 to13 express13 available13 transports
bull Mapping13 and13 message13 sizebull Security13 consideraons
56
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
URI13 =13 scheme13 13 13 authority13 path-shy‐abempty13 [13 query13 ]
bull Within13 the13 scheme13 namebull In13 the13 URI13 pathbull As13 a13 query13 component
57
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
bull Within13 the13 scheme13 namendash coap+tel+15105550101well-shy‐knowncorendash coap+tcpexamplecom5683temperaturendash coap+blel2cap[1234567890AB]4pulse
bull Easy13 URI13 parsing13 for13 transport13 type13 and13 idenfier
bull Each13 new13 scheme13 name13 requires13 IANA13 registraon
58
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
bull In13 the13 URI13 pathndash coaphostexamplecomtransport=tcpwell-shy‐knowncorert=core-shy‐rd
bull Easy13 adopon13 of13 new13 (and13 experimental)13 CoAP13 transports13 without13 IANA13 registraon
bull Caveat13 Uri-shy‐Path13 opon13 is13 a13 Crical13 CoAP13 opon13 see13 secon13 54113 of13 I-shy‐Diep-shy‐core-shy‐coap
59
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
bull As13 a13 URI13 query13 componentndash coaphostexamplecomwell-shy‐knowncorert=core-shy‐rdq=tcp
bull Also13 easy13 to13 adopt13 new13 (and13 experimental)13 CoAP13 transports13 without13 IANA13 registraon
bull Caveat13 Uri-shy‐Query13 opon13 is13 a13 Crical13 CoAP13 opon13 see13 secon13 54113 of13 I-shy‐Diep-shy‐core-shy‐coap
60
031113
URI13 Representaons13 for13 CoAPNon13 standard13 ways
bull Transport13 in13 the13 URI13 authority13 componentndash coaphost[port][transport]13 instead13 of13 coaphost[port]
bull Transport13 as13 a13 service13 URLndash servicecoaptcphostexamplecomwell-shy‐knowncorert=core-shy‐rd
bull Above13 two13 ways13 break13 exisng13 compability13 (although13 both13 are13 based13 on13 valid13 IANA13 URI13 registraons)
61
031113
URI13 Representaons13 for13 CoAPMiscellaneous13 Consideraons
bull Ensure13 that13 transport13 is13 defined13 unambiguously13 (eg13 L2CAP13 used13 by13 both13 BLE13 and13 standard13 Bluetooth13 so13 avoid13 rdquocoap+l2caprdquo13 or13 rdquotransport=l2caprdquo13 or13 rdquoq=l2caprdquondash Can13 be13 done13 as13 WG13 consensusndash Namespace13 approach13 eg13 rdquocoap+blel2caprdquo13 or13 rdquoq=blel2caprdquo
bull Allow13 end-shy‐points13 to13 use13 CoAP13 Resource13 Directory13 to13 register13 alternave13 transports13 and13 idenfiers13 and13 provide13 periodic13 updatesndash Register13 rdquocore-shy‐transportrdquo13 resource13 type
62
031113
Transport13 Consideraons
bull Uniqueness13 of13 end-shy‐point13 idenficaonbull Communicaon13 support13 Unidireconal13 Bidireconal13 1N13 (broadcast13 mulcast13 anycast)13 messaging
bull Binary13 encoding13 Network13 byte13 orderingbull MTU13 correlaon13 with13 CoAP13 PDU13 sizebull Transport13 latency
63
031113
Security13 Consideraons
bull Drar13 does13 not13 introduce13 new13 security13 requirements13 by13 itself
bull There13 may13 be13 privacy13 issues13 if13 nodes13 use13 telephone13 numbers13 or13 MAC13 addresses13 as13 public13 end13 point13 idenfiers
64
Akbar Rahman
IETF 86 March 2013 httpwwwietforgiddraft-rahman-core-sleepy-02txt
Enhanced Sleepy Node Support for CoAP
Introduction
It is expected that in CoAP networks there will be a certain portion of devices that are sleepy and which may occasionally go into a sleep mode (ie go into a low power state to conserve power) and subsequently have reduced CoAP protocol communication ability
This I-D proposes a minimal and efficient mechanism building on the Resource Directory concept (which will be integrated into a CoAP Proxy) to enhance sleepy node support in CoAP networks
Main Question from IETF-85 (Atlanta)
What performance benefit does the proposed Sleepy Node support solution give in a network that already has standard CoAP caching enabled
Sleepy Node Performance Analysis
Experimental Network
1-5 clients
Both Sleepy and Non-
Sleepy servers
Sleepy Node Performance Analysis Network Setup
CoAPSleepyServer(s)
CoAPSleepAwareReverseProxy
CoAP
Client(s)
Request
Response
Sleep9AwareCoREResourceDirectoryCapability
PublishedSleepParameters
Sleep9AwareCoAPStoreandForwardCapability Response
Request
SleepAwareCoAP503ResponseCapability
CoAPCachingCapability
bull Server supports publishing sleep parameters to proxy bull Eg Irsquom going to be asleep for X seconds
bull Proxy supports sleep-awareness capabilities bull Proxy also supports caching capability based off of maxAge bull Protocol flow similar to approach of Figure 1 (Synchronous RD Based Sleep
Tracking) of I-D
Proxy capabilities can be selectively enableddisabled
Proxy ndash Server Interface
Client ndash Proxy Interface
CoAP Sleep-Aware Reverse Proxy Features CoRE Sleep-aware Resource Directory
Support storing published sleep parameters from CoAP servers sleepState (AWAKE ASLEEP) sleepDuration
Sleep-aware CoAP 503 Response Capability If CoAP request to a sleeping server is received proxy returns a
lsquo503 Retry-Afterrsquo response to client 503 contains a timestamp indicating when the sever will wake back up
(timestamp delivered in CoAP maxAge option) Sleep-aware CoAP Store-and-Forward Capability
If CoAP request to a sleeping server is received proxy stores request until server wakes up and then forwards it
Caching capability Cache GET responses from server if maxAge option is present
(this is not a sleep aware feature)
Goals of Performance Analysis
For networks having sleepy servers provide measurements to quantify the impact that CoAP sleep-awareness capabilities can have
See if sleep-awareness capabilities can
provide additional benefits even when CoAP caching is used
Overview of Performance Analysis Performed The analysis was broken up into a set of test scenarios Each test scenario used a different combination of the following
variables Client issued GET requests Server was configured as a sleepy or non-sleepy server Proxy caching of GET responses was enabled or disabled Proxy sleep-aware 503 response capability was enabled or disabled Proxy store-and-forward capability was enabled or disabled maxAge in GET responses ndash Two values were tested 60sec and 5sec of Clients ndash Two values were used ndash 1 client and 5 clients
For comparison purposes the following were held constant across all test scenarios Client issued a fixed number of requests (100) across all test scenarios Client used a delay between each GET request (35sec) to better exercise
proxyrsquos caching and sleep-awareness capabilities For sleepy server test scenarios the server slept 60 sec awake for 3 sec
Format of Results The following results were collected for each
test scenario
Breakdown of the and types of transactions occurring between clientproxyserver
ldquoGETrdquo ndash Test Scenario Results
GET ndash Description of Test Scenarios
TestScenarios-GET
Scenario
CoAPSleepyServerSe7ngs CoAPSleepAwareReverseProxySe7ngs CoAPClientSe7ngs
SleepDuragton(sec)
AwakeDuragton(sec)
maxAge(sec) Caching SleepAwareSAF+
503NumberofClients
NumberofGETs
DelayBetweenClient
Requests(sec)
1a 0 Always 60 Enabled Disabled 1 100 35
1b 60 3 60 Enabled Disabled 1 100 35
1c 60 3 60 Enabled Enabled 1 100 35
2a 0 Always 60 Enabled Disabled 5 100 35
2b 60 3 60 Enabled Disabled 5 100 35
2c 60 3 60 Enabled Enabled 5 100 35
3a 0 Always 5 Enabled Disabled 5 100 35
3b 60 3 5 Enabled Disabled 5 100 35
3c 60 3 5 Enabled Enabled 5 100 35
ldquoGETrdquo ndash Test Scenario 1 Results
maxAge = 60 and 1 Client
GET ndash Scenario 1 ClientProxy Interface Transaction Mix
Scenarios 1a - Non-Sleepy Server Caching Proxy maxAge = 60sec 1b- Sleepy Server Caching Proxy maxAge = 60sec 1c - Sleepy Server Sleep Aware Proxy maxAge = 60sec
Sleep Aware Proxy has better performance for sleepy servers
0
100
200
300
400
500
600
700
1a 1b 1c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
GET ndash Scenario 1 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
Scenarios 1a - Non-Sleepy Server Caching Proxy maxAge = 60sec 1b- Sleepy Server Caching Proxy maxAge = 60sec 1c - Sleepy Server Sleep Aware Proxy maxAge = 60sec
0
100
200
300
400
500
600
700
800
1a 1b 1c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
ldquoGETrdquo ndash Test Scenario 2 Results
maxAge = 60 and 5 Clients
GET ndash Scenario 2 ClientProxy Interface Transaction Mix
Sleep Aware Proxy has slightly better performance for sleepy servers
0
200
400
600
800
1000
1200
1400
2a 2b 2c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
Scenarios 2a - Non-Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2b- Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2c - Sleepy Server Sleep Aware Proxy maxAge = 60sec 5 Clients
See ldquoExperimental Artifactsrdquo Note 1
GET ndash Scenario 2 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has slightly better performance for sleepy servers
0
50
100
150
200
250
300
350
400
2a 2b 2c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
Scenarios 2a - Non-Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2b- Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2c - Sleepy Server Sleep Aware Proxy maxAge = 60sec 5 Clients
See ldquoExperimental Artifactsrdquo Note 2
Experimental Artifacts Note 1
Currently in the experiment the sleep aware proxy checks the cached state of a resource before putting a request into its Store-and-forward queue while a server is sleeping Once in the queue the proxy unconditionally forwards the queued requests to the server once it wakes up This is not the most efficient setup and can easily be improved If the proxy instead checks its cache again before forwarding each queued request it may not need to forward the request to the server For example if there are two queued GET requests in the proxyrsquos queue that address the same resource Only the first request needs to be sent to the server the second request can use the cached response from the first request
Note 2 Currently in the experiment the sleepy server sends a sleepState PUT request to the
proxy each time it goes to sleep This is not the most efficient setup and can easily be improved For example if the server assumes that the proxy can keep track of its ONOFF cycles with its internal timers (eg as per Fig 1 of I-D) then the number of messages from the sleepy server dramatically goes down
ldquoGETrdquo ndash Test Scenario 3 Results
maxAge = 5 and 5 Clients
GET ndash Scenario 3 ClientProxy Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
Scenarios 3a - Non-Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3b- Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3c - Sleepy Server Sleep Aware Proxy maxAge = 5sec 5 Clients
0
500
1000
1500
2000
2500
3000
3500
4000
4500
5000
3a 3b 3c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
GET ndash Scenario 3 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
0
1000
2000
3000
4000
5000
6000
7000
3a 3b 3c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
Scenarios 3a - Non-Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3b- Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3c - Sleepy Server Sleep Aware Proxy maxAge = 5sec 5 Clients
Conclusions
Conclusions These results show that sleep-aware CoAP
proxy features can significantly optimize communication with sleepy servers in most scenarios
These results also show that sleep-
awareness capabilities can provide additional benefits above and beyond CoAP caching in most scenarios
Backup
Current CoAP Support of Sleepy Node (12)
CoAP proxies can use a previously cached response to service a new GET request for a sleepy origin server (as in HTTP) But if no valid cache then proxy has to attempt to
retrieve and may fail if origin server is sleeping [I-Dietf-core-coap]
Clients can discover list of resources from RD (GET rd-lookuphellip) for sleepy servers But attempt to GET resource from sleepy origin server
may fail if origin server is sleeping [IDietf-core-link-format amp IDshelby-core-resource-
directory]
Current CoAP Support of Sleepy Node (22)
Lower layer support for sleepy nodes in most wireless technologies (eg WiFi ZigBee) But limited to MAC packet scheduling for sleepy nodes
and not aware of specific needs of IP applications (like CoAP)
Proposal ndash RD Based Sleep Tracking (14)
The current CoAP approach to support sleepy nodes can be significantly improved by introducing RD based mechanisms for a CoAP client to determine whether A targeted resource is located on a sleepy server A sleepy server is currently in sleep mode or not
There is any associated caching Proxy (possibly the RD itself) for a sleepy server
Proposal ndash RD Based Sleep Tracking (24)
We define the following new RD attributes to characterize the properties of a sleepy node SleepState - Indicates whether the node is currently in
sleep mode or not (ie Sleeping or Awake) SleepDuration - Indicates the maximum duration of time
that the node stays in sleep mode TimeSleeping - Indicates the length of time the node
has been sleeping (ie if Sleep State = Sleeping) NextSleep - Indicates the next time the node will go to
sleep (ie if Sleep State = Awake)
CachingProxy ndash Indicates the caching proxy of the sleepy node (ie the RD itself or another node)
Proposal ndash RD Based Sleep Tracking (34)
These attributes are all server (node) level and are new parameters added to the RD URI Template Variables
Finally we also define a new lookup-type (ss) for the RD lookup interface specified in [I-Dshelby-core-resource-directory] This new lookup-type supports looking up the
ldquoSleepStaterdquo (ss) of a specified end-point
Proposal ndash RD Based Sleep Tracking (44)
The three time based parameters (SleepDuration TimeSleeping NextSleep) can be based on either an absolute network time (for a time synchronized network) or a relative local time (measured at the local node)
Following the approach of [I-Dietf-core-link-format] and [I-Dshelby-core-resource-directory] sleep parameters for sleepy servers can be stored by the server in the RD and accessed by all interested clients
Examples of using these parameters in a synchronous or asynchronous manner are shown in the I-D
http6lowappnet coreIETF86 2013-03-12-13
We assume people have read the drafts
Meetings serve to advance difficult issues by making good use of face-to-face communications
Note Well Be aware of the IPR principles according to RFC 3979 and its updates
uumlBlue sheetsuumlScribe(s)
96
drar-shy‐iep-shy‐core-shy‐coapsubmiqed13 to13 IESG
2013-shy‐03-shy‐13
97
OMA Lightweight M2M Overview(A new standard using lots of IETF specs including DTLS
CoAP Block Observe Resource Directory SenMLhellip)
Zach ShelbyCoRE WG IETF-86 Orlando
OMA Lightweight M2Mbull Open Mobile Alliance is well known for Device Management (DM)bull OMA Lightweight M2M is a new standard from the alliance
ndash Focused on constrained Cellular and sensor network M2M devicesndash Driven by leading operators and vendors
bull Scopendash Interfaces protocol amp security between Device and Serverndash Object and Resource modelndash Bootstrap Device Access Control Connectivity and Firmware Objects
bull Draft Specifications are availablendash httpmemberopenmobileallianceorgftpPublic_documentsDM
LightweightM2MPermanent_documentsOMA-TS-LightweightM2M-V1_0_0-20130301-Dzip
bull Timelinendash Requirements and Architecture completed 3Q2012ndash Spec ready for Consistency Review 2Q2013ndash Candidate Approval expected 3Q2013
2 CoRE WG IETF-86 Orlando
Architecture
3
Scope of LWM2M
CoRE WG IETF-86 Orlando
Object Model
bull A Client has one or more Object Instancesbull An Object is a collection of Resourcesbull A Resource is an atomic piece of information
ndash Read Written or Executed
bull Resources can have multiple instancesbull Objects and Resources are identified by a
16-bit Integer Instances by an 8-bit Integerbull ObjectsResources are accessed with
simple URIs Object IDObject InstanceResource ID
eg 1213
4 CoRE WG IETF-86 Orlando
CoRE WG IETF-86 Orlando
CoRE Resource Directory
draft-shelby-core-resource-directory-05
Z Shelby C Bormann S Krco
Backgroundbull Not a new concept
ndash think web search engine or any link directorybull Defines the interfaces to a Resource Directorybull Based on Web Linking framework and the CoRE Link Formatbull Generic REST design for use over HTTP and CoAPbull Used by OMA Lightweight M2Mbull Has already been deployed
ndash In traffic monitoring systemsndash In street lighting systemsndash For vehicular asset trackingndash By a major Cellular M2M operator
Changes since -04
bull Restricted Update to parameter updatesbull Added pagination support for the Lookup interfacebull Changed rt= to et= for the registration amp update
interfacebull Added group support
Group Management
bull RD now includes group management featuresbull New Group Function Set
ndash Register a groupbull Group name domain multicast address endpoint members
ndash Remove a groupbull Group lookup using the Lookup Function Set
ndash List registered groupsndash Find the members of a groupndash Find groups with certain endpoints or resources
Registering a Group
EP RD
| |
| - POST rd-groupgp=lights ltgtep=node1 --gt |
| |
| |
| lt---- 201 Created Location rd-group12 ---- |
| |
Req POST coaprdexamplecomrd-groupgp=lights
Payload
ltgtep=node1
ltgtep=node2
Res 201 Created
Location rd-group12
Looking up Group Members
Client RD
| |
| ----- GET rd-lookupepgp=lights1 ----------------------gt |
| |
| |
| lt-- 205 Content ltrdgtd=domain1ltrdgtd=domain2 --------- |
| |
Req GET rd-lookupepgp=lights1
Res 205 Content
ltcoaphostportgtep=node1
ltcoaphostportgtep=node2rdquo
Things for the futurebull Support for JSON representation of Web Links
ndash httptoolsietforgiddraft-bormann-core-links-json-02txtbull Registry for RD registration query parameters
ndash Already OMA Lightweight has defined some new onesbull More examples
Group 3 ldquonew workrdquo(continued)
109
drar-shy‐greevenbosch-shy‐core-shy‐profile-shy‐descripon-shy‐01Bert13 GreevenboschJeroen13 Hoebeke
Isam13 IshaqFloris13 Van13 den13 Abeele
Descripon
bull JSON13 format13 for13 signalling13 the13 servers13 capabilies
bull Signalling13 of13 supported13 opons13 media13 types13 and13 block13 sizendash Other13 items13 can13 be13 added
bull Filtering13 on13 specific13 fields13 through13 URI-shy‐Querybull Link13 hqpdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐profile-shy‐descripon
well-shy‐knownprofile
bull To13 acquire13 profile13 data13 of13 resources13 on13 a13 parcular13 service13 the13 well-shy‐knownprofile13 URI-shy‐path13 is13 introduced
bull For13 example13 to13 get13 all13 informaon13 from13 sensors13 served13 by13 wwwexampleorg13 we13 can13 do13 a13 GET13 to13 coapwwwexampleorgwell-shy‐knownprofile
bull Filtering13 on13 parcular13 resources13 is13 done13 through13 URI-shy‐Queries
Format
bull Currently13 the13 following13 fields13 are13 definedndash ldquopathrdquo13 contains13 the13 URI-shy‐path13 associated13 with13 a13 resource
ndash ldquooprdquo13 a13 numerical13 list13 of13 supported13 opon13 numbers
ndash ldquocfrdquo13 a13 numerical13 list13 of13 supported13 content-shy‐format13 numbers
ndash ldquob1srdquo13 ldquob2srdquo13 supported13 block13 sizes13 for13 Block113 and13 Block213 respecvely
Examplebull On13 the13 right13 is13 an13 example13 of13 a13 camera13 sensor13 at13 coapwwwexampleorgcam13 that13 supports13 the13 Uri-shy‐Host13 (3)13 ETag13 (4)13 Uri-shy‐Port13 (7)13 Uri-shy‐Path13 (11)13 Content-shy‐Format13 (12)13 Token13 (19)13 Block213 (23)13 and13 Proxy-shy‐Uri13 (35)13 opons
bull The13 supported13 content13 formats13 are13 textplain13 (0)13 applicaon13 link-shy‐format13 (40)13 and13 applicaonjson13 (50)
bull The13 supported13 Block213 can13 use13 25613 or13 51213 byte13 blocks
Req13 GET13 coapwwwexampleorgwell-shy‐knownprofile13 Res13 20513 Content13 (applicationjson)13 13 13 13 profile13 13 13 13 13 13 13 13 pathcam13 13 13 13 op[3471112192335]13 13 13 13 13 cf[04050]13 13 13 13 13 b2s[45]13 13 13 13
Filtering13 through13 use13 of13 URI-shy‐Query
bull Filtering13 can13 be13 done13 through13 the13 URI-shy‐Querybull Query13 format13 N=V
ndash N13 is13 a13 profile13 fieldndash V13 is13 the13 desired13 value
bull Examplesndash To13 find13 resources13 that13 support13 content13 format13 ldquoapplicaonjsonrdquo
13 GET13 wwwexampleorgwell-shy‐knownprofilecf=50ndash To13 get13 informaon13 about13 the13 camera
13 GET13 wwwexampleorgwell-shy‐knownprofilepath=cam
Open13 issues
bull Which13 other13 profile13 data13 needs13 signallingndash Content-shy‐type13 for13 different13 methods
bull Fix13 the13 order13 in13 which13 the13 profile13 fields13 must13 appearndash Non-shy‐fixed13 order13 easier13 extensible
bull Inheritance13 of13 a13 profile13 descriponbull Extend13 usage13 to13 signal13 the13 client13 profilebull Integraon13 with13 link13 format
Thank13 youQuesons
drar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval-shy‐00
Bert13 Greevenbosch
Descripon
bull The13 ldquoMinimumRequestInterval13 opon13 can13 be13 used13 to13 indicate13 the13 minimum13 me13 between13 two13 requests13 in13 a13 transacon
bull Originally13 intended13 for13 Block13 but13 also13 usable13 for13 other13 transaconsndash Example13 browsing13 a13 server
bull The13 goal13 is13 to13 reduce13 the13 server13 load13 and13 network13 traffic
bull Link13 hqpsdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval
Usage
bull The13 client13 keeps13 the13 server13 informed13 about13 its13 request13 speed13 through13 inclusion13 of13 the13 ldquoMinimumRequestIntervalrdquo13 opon
bull In13 responses13 the13 server13 fixes13 the13 minimum13 request13 interval13 through13 the13 same13 opon
bull The13 client13 obeys13 the13 speed13 indicated13 by13 the13 server
bull The13 client13 can13 send13 slower13 but13 not13 faster
Advantages
bull The13 server13 has13 means13 to13 limit13 the13 amount13 of13 incoming13 traffic
bull The13 server13 can13 prevent13 to13 become13 overloaded13 with13 too13 many13 tasks
bull The13 server13 does13 not13 need13 arficially13 slow13 down13 the13 client13 by13 sending13 late13 ACKsndash No13 need13 to13 keep13 track13 of13 delayed13 ACKsndash The13 server13 can13 perform13 other13 tasks13 instead
bull Reduced13 network13 traffic
Thank13 youQuesons
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-links-json-02txt
123
RFC 6690 (link-format) documents are somewhat foreign to many web app developerssect would prefer to have them in JSON format
There is no standard way to represent link-format documents in applicationssect but everyone knows how to handle JSON
Define a standard JSON translation for link-format
Itrsquos
not
rock
et
scien
ce
ltsensorsgtct=40title=Sensor Index ltsensorstempgtrt=temperature-cif=sensor ltsensorslightgtrt=light-luxif=sensor lthttpwwwexamplecomsensorst123gt anchor=sensorstemprel=describedby lttgtanchor=sensorstemprel=alternate [hrefsensorsct40titleSensor Index hrefsensorstemprttemperature-cifsensor hrefsensorslightrtlight-luxifsensor hrefhttpwwwexamplecomsensorst123 anchorsensorstempreldescribedby hreftanchorsensorstemprelalternate]
124
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-ipsec-for-coap-00txt
IPsec definitions for CoAP Mostly placeholder at this time Who has implementation experience with this
125
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-cross-reverse-convention-00txt
This draft has two lines of payload(based on a WGLC comment by Cullen Jennings)
coap12344567foobara=3
httpwwwproxycomwellknowncore-translate1234_4567foobara=3
Is that a useful convention to have
126
Insert CI slides here
127
128
0
5
10
15
20
25
30
35
40
10 20 30 40 50 60 70
good
put (
pps)
pps
Goodput vs pps (Econotags)
goodput
[Khattak preliminary]
Congestion Control
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-cocoa-00txt
ldquoadvancedrdquo cc (The draft is just a first shot) Others may have better ideas
129
Insert post-WGLC discussion slides here
130
Stop Continue Start
131
An Agile Retrospective
http6lowappnet coreIETF86 2013-03-12-13
Stop
132
Endless new CoAP optionssect instead use RESTful as much as possible
Move general security lifecycle out Looking at theoretical problems
http6lowappnet coreIETF86 2013-03-12-13
Continue
Interops Running code Look at real-world examples and deployments Solve their actual problems
sect Unilateral enhancements eg higher performance congestion control
sect Transports (SMS hellip)sect Make Web linking and Directories more and more usefulsect RESTful Design Paradigms for real-world problems
133
http6lowappnet coreIETF86 2013-03-12-13
Start
Further push into the (browser) web world (HTML5 browser security)
Specific supporting worksect SenMLsect URI work (dev URN hellip)sect Security Processes (next slide)
Spin outsect (We donrsquot really get to decide where this is done)
134
http6lowappnet coreIETF86 2013-03-12-13
Security
Integrate Application Network Group Keyingsect Tunnel-free setup
Donrsquot redo what has been done alreadysect ZigBee IP is finesect But what about other scenarios
Simple REST interfaces for working with keying materials and authorizationsect Start with defining objectives
Object Security for Constrained Nodes135
Re-chartering CoREWhat do we want to do now that wersquore grown up
Zach ShelbyCoRE WG IETF-86 Orlando
What is the scope
bull So we have a protocol and Web Linking what next
bull Keep with what we know besthellip1 Enhancements around CoAP2 New transports for CoAP3 New representations for Web Links4 General application layer solutions
CoRE WG IETF-86 Orlando 2
Enhancements around CoAP
bull Advanced congestion control
CoRE WG IETF-86 Orlando 3
New Transports for CoAP
bull Infrastructure for CoAP over foondash httptoolsietforgiddraft-silverajan-core-
coap-alternative-transports-01txtbull CoAP over SMS
ndash httptoolsietforgiddraft-becker-core-coap-sms-gprs-03txt
ndash OMA Lightweightbull CoAP over TCP
ndash httptoolsietforgiddraft-li-core-coap-payload-length-option-01txt
CoRE WG IETF-86 Orlando 4
New support for Web Links
bull JSON Web Linksndash httptoolsietforgiddraft-bormann-core-links-
json-02txt
2332010 CoRE WG IETF-77 Anaheim 5
General application layer solutions
bull Resource Directoryndash httptoolsietforgiddraft-shelby-core-
resource-directory-05txtndash OMA Lightweight
2332010 CoRE WG IETF-77 Anaheim 6
Group 2 groupcomm
13
Akbar RahmanEsko Dijk
IETF 86 March 2013httpwwwietforgiddraft-ietf-core-groupcomm-05txt
Group Communication for CoAP
Summary of Changes (14)
n I-D had two updates (Rev 04 amp 05) after IETF-85 (Atlanta) Many of the updates were due to the detailed review by Peter van der Stokn Thank you Peter for your valuable comments
n Changes from ietf-03 to ietf-04 n Section 23 (Potential Solutions for Group Communications) moved to
draft-dijk-core-groupcomm-misc (266)n Added reference to draft-keoh-tls-multicast-security to section 6 (Security
Considerations) n Appendix B (CoAP-Observe Alternative to Group Communications) moved
to draft-dijk-core-groupcomm-misc (267) n Deleted section 8 (Conclusions) as it is redundant (268) n Simplified light switch use case (269) by splitting into basic operations and
additional functions (269)
Summary of Changes (24)
n Changes from ietf-03 to ietf-04 (Continued) n Moved section 37 (CoAP Multicast and HTTP Unicast Interworking) to
draft-dijk-core-groupcomm-misc (270) n Moved section 331 (DNS-SD) and 332 (CoRE Resource Directory) to
draft-dijk-core-groupcomm-miscClarified that DNS based features are optional (272)
n Focus section 35 (Configuring Group Membership) on a single proposed solution
n Scope of section 53 (Use of MLD) widened to multicast destination advertisement methods in general
n Rewrote section 22 (Scope) for improved readibility n Moved use cases that are not adressed to draft-dijk-core-groupcomm-miscn Various editorial updates for improved readibility
Summary of Changes (34)
n Changes from ietf-04 to ietf-05 n Added a new section 39 (Exceptions) that highlights that IP multicast (and
hence group communications) is not always available (187) n Included guidelines on when (not) to use CoAP responses to multicast
requests and when (not) to accept multicast requests (273) n Added guideline on use of core-block for minimizing response size (275)n Restructured section 6 (Security Considerations) to more fully describe
threats and threat mitigation (277) n Clearly indicated that DNS resolution and reverse DNS lookup are optional n Removed confusing text about a single group having multiple IP addresses
If multiple IP addresses are required then multiple groups (with the same members) should be created
n Removed repetitive text about the fact that group communications is not guaranteed
Summary of Changes (44)
n Changes from ietf-04 to ietf-05 (Continued) n Merged previous section 52 (Multicast Routing) into 31 (IP Multicast
Routing Background) and added link to section 52 (Advertising Membership of Multicast Groups)
n Clarified text in section 38 (Congestion Control) regarding precedence of use of IP multicast domains (ie first try to use link-local scope then site-local scope and only use global IP Communication for CoAP multicast as a last resort)
n Extended group resource manipulation guidelines with use of preconfigured portspaths for the multicast group
n Consolidated all text relating to ports in a new section 33 (Port Configuration)
n Clarified that all methods (GETPUTPOST) for configuring group membership in endpoints should be unicast (and not multicast) in section 37 (Configuring Group Membership In Endpoints)
n Various editorial updates for improved readability
Discussion item (11)
n Solution for Configuring Group Membership (no ticket)n Example of (unicast) configuring an endpoint to be part of one multicast
groupReq POST gp (Content-Format applicationjson)
n floor1westbldg6examplecom ip ff154200f7feed3714cb Res 204 Changed
n Where the ldquogprdquo resource has resource type (rt) ldquocoregprdquo which is defined for this purpose
n Question Do we want specify such a solution (or for example leave it completely up to implementation)
Open Issues(15)
n Review Groupcomm requirements language (271)n Decision made to keep requirements language for informational draftn Each use of MAYMUSTSHOULD etc is to be reviewed
Open Issues(25)
n Add section on multicast via Proxy and its limitations (274)n Add a section to explain the issues amp limitations of doing CoAP multicast
requests via a CoAP Proxy n Goal is to warn and guide implementers in this subject n Also such a section would provide a placeholderreminder of the problems
that might be addressed further in the futuren Based on IETF 85 CoRE WG meeting discussion on Multicast CoAP
requests via a Proxy Discussion summary for referencen Aggregation of responses in a proxy is difficult since it doesnt know
when to stop aggregating responses n SIP tried to deal with this problem but didnt solve it n There may be an expectancy of CoAP client to get single response
back from proxy not multiple The client in this case may not even know what it could expect It may not even know the Proxy-URI contains a multicast target
n Presented via-proxy use case exposes gap in the core-coap specification regarding multicast via proxy (Note Expectation is that core-coap wonrsquot address it in the first planned RFC release)
Open Issues(35)
n Issues with twomultiple Resource Directories in use case (280)n Some potential issues with RD came out of review Peter van der Stok and
WG discussion IETF85 n There are two RD servers use case shows that only one is found despite
the fact that site-local multicast is used - should be two RDs found n Proposal simplify use case to a single RD server on the backbone to avoid
such RD-specific issues like synchronization of RD information between servers
Open Issues(45)
n Add single-subnet configuration to use cases (278)n Suggested by review Peter van der Stok and IETF85 WG discussion that
its best to start explaining the simplebasic cases and then gradually build up complexity
n Simplest case not shown yet would be a single subnet network configuration which is currently not present in the I-D only the 2-subnet configuration of Fig 1
n Question Do we need to add such case or doesnt it add muchn (Note that core-coap Figure 22 already shows the simplest case of link-local
multicast)
Open Issues(55)
n Add use case with controller (client) located on the backbone (279)n Suggested by discussion following review Peter van der Stok n Case missing where a controller (client) is located on the backbonen Question Do we need to add such case or does it add much
Group 2a other old friends
25
Angelo Castellani Salvatore Loreto Akbar Rahman Thomas Fossati Esko Dijk
IETF 86 March 2013httpwwwietforgiddraft-castellani-core-http-mapping-07txt
Best Practices for HTTP-CoAP Mapping
Implementation
Summary of Changes (from -06 rev)
n Based on discussion at last IETF-85 (Atlanta)n Clarification of HTTP-CoAP Proxies
n Definitionn Placementn Benefits
n Clarification of HTTP-CoAP URI mapping options
Goals of I-D
n For Reverse HTTP-CoAP Cross Protocol Proxyn Provide more detailed information to proxy designers (beyond
Section 10 of [I-Dietf-core-coap]) to help implement proxies that correctly inter-work with other CoAP and HTTP clientserver implementations that adhere to the specifications
n Define a consistent set of guidelines that a HTTP-to-CoAP proxy implementation MAY adhere to The main reason of adhering to such guidelines is to reduce variation between proxy implementations thereby increasing interoperabilityn As an example use case a proxy conforming to these guidelines made
by vendor A can be easily replaced by a proxy from vendor B that also conforms to the guidelines
I-D Outline
n Guidance on HTTP to CoAP URI mappingn HTTP-CoAP Reverse cross-protocol proxy implementation
n Placementn Response code amp media type translationsn Caching and congestion controln Cache refresh via Observen Use of CoAP blockwise transfern Security translation
n Security Considerationsn Traffic overflown Handling secured exchanges
Definitions (12)
n Cross-Protocol Proxy (or Cross Proxy) is a proxy performing a cross- protocol mapping in the context of this document a HTTP-CoAP (HC) mapping A Cross-Protocol Proxy can behave as a Forward Proxy Reverse Proxy or Interception Proxy n Note In this document we focus on the Reverse Proxy mode of the
Cross-Protocol Proxy
n Forward Proxy a message forwarding agent that is selected by the client usually via local configuration rules to receive requests for some type(s) of absolute URI and to attempt to satisfy those requests via translation to the protocol indicated by the absolute URI The user decides (is willing to) use the proxy as the forwardingdereferencing agent for a predefined subset of the URI space
Definitions (22)
n Reverse Proxy a receiving agent that acts as a layer above some other server(s) and translates the received requests to the underlying servers protocol It behaves as an origin (HTTP) server on its connection towards the (HTTP) client and as a (CoAP) client on its connection towards the (CoAP) origin server The (HTTP) client uses the origin-form [I-Dietf-httpbis-p1-messaging] as a request- target URI
n Reverse and Forward proxies are technically very similar with main differences being that the former appears to a client as an origin server while the latter does not and that clients may be unaware they are communicating with a proxy
Reverse Cross-Protocol Proxy Deployment Scenario
HTTP-CoAP Response Code Mapping
Implementation Experience
n Direct experience from the draft authorsn Squid HTTP-CoAP mapping module
n University of Padovan httptelecomdeiunipditiotn Both Forward and Interception operation supported
n HTTP-CoAP proxy based on EvCoAPn KoanLogic University of Bologna and Salvatore
Loreto (as individual)n httpsgithubcomkoanlogicwebthingstreemasterbridgesw
libevcoapn The document is open to input from other implementations
Next Steps
n Does the WG recommend adoptionn Intended status Informational Best Practicen Purpose Reduce arbitrary variation between proxy
implementations thereby increasing interoperability
Backup
HTTP to CoAP URI Mapping Options (12)
n Embedded Mapping n In an embedded mapping approach the HTTP URI has embedded
inside it the authority and path part of the CoAP URI n Example The CoAP resource nodecoapsomethingnetfoo can
be accessed by an HTTP client by inserting in the request httphc-proxysomethingnetcoapnodecoapsomethingnetfoo The Cross-Protocol Proxy then maps the URI to coapnodecoapsomethingnetfoo
HTTP to CoAP URI Mapping Options (22)
n Homogeneous Mapping n In a homogeneous mapping approach only the scheme portion of the URI
needs to be mapped The rest of the URI (ie authority path etc) remains unchanged
n Example The CoAP resource coapnodecoapsomethingnetfoo can be accessed by an HTTP client by requesting httpnodecoapsomethingnetfoo The Cross-Protocol Proxy receiving the request is responsible to map the URI to coapnodecoapsomethingnetfoo
n Background info n The assumption in this case is that the HTTP client would be able to
successfully resolve nodecoapsomethingnet using DNS infrastructure to return the IP address of the HC proxy Most likely this would be through a two step DNS lookup where the first DNS lookup would resolve somethingnet using public DNS infrastructure
n Then the second DNS lookup on the subdomain coap and the host node would typically be resolved by a DNS server operated by the owner of domain somethingnet So this domain owner can manage its own internal node names and subdomain allocation which would correspond to the CoAP namespace
Group 3 ldquonew workrdquo
39
Transport of CoAP over SMS USSD and GPRSdraft-becker-core-coap-sms-gprs-03
Markus Becker Kepeng LiKoojana Kuladinithi Thomas Poumltsch
CoRE WG IETF-86 Orlando
1 10
ScenariosI In M2M communication IP connectivity is not alwayssupported by the constrained end-points
I Power savingI Coverage (GPRS 3G LTE)
I SMS and USSD based communication is almost alwayssupported
210
Changes from draft-01 to draft-03 (1)
I Added possible CONNONACK interactions Section 5
I Option name changed from Reply-To- to Response-To-Section 16 and Section 101
I Added URI schemeEg coap+tel+15105550101well-knowncore Section 11
I Added possible M2M proxy scenarios Section 14
3 10
Changes from draft-01 to draft-03 (2)
I Added reference to bormann-coap-misc for other SMSencoding Section 71
I Updated requirements on Uri-Host and Uri-Port forcoap+tel Section 10
I Added security considerations Transport and ObjectSecurity Section 15
I Chose CoAP option numbers and updated the optionnumber table to meet draft-ietf-core-coap-10 Table 1
I Added an IANA registration for the URI scheme coap+telSection 162
4 10
Feedback Split coap+tel into coap+smsand coap+ussd
I How else to differ the various transports in the URII Or is the transport to use decided by the implementationI See alsodraft-silverajan-core-coap-alternative-transports-01
5 10
Feedback Response-To-Scheme option
I Should there be a Response-To-Scheme optionadditionally to Response-To-Uri-Host andResponse-To-Uri-Path
I So that a CoAP end-point which receives a request by CoAPover non-IP transport can be instructed to also use thenon-IP transport for the response
I This would imply to add aResponse-To-Telephone-Subscriber and more options forother transports that have other URI schemes than coapand coaps
6 10
Feedback Selection of Transport by Client
I When a server is reachable by various transports howdoes a client decide which transport to use
I Client-side application congurationI Leave it to a proxy which uses cellular network lookupfunctions
7 10
Feedback Potential Threats
I Trigger expensive short messagesI Redirect trac to other addressesI More threats
I Are the security measures in the draft adequateI Whitelisting on serverI Relying on cellular network security (dedicated M2M APNs)I Object security on CoAP payload
8 10
Feedback Message Exchanges
I Figures 11-18 show possible message exchanges whenclient and server have two addresses
I With NON Not using CoAP retransmission capabilityI ACK on different transportI Additional (costly) message on Transport AI Request with Content
I Which ones are allowedI Which ones are meaningful
9 10
Next steps
I Rene Uri schemeI Response-To-Scheme optionI Selection of Message ExchangeI Rene Proxying
10 10
CoAP13 Communicaon13 with13 Alternave13 Transports
Bill Silverajan and Teemu SavolainenCore WG IETF 86 Orlando
031113
Objecves13 (In13 Scope)
bull Unambiguous13 representaon13 of13 transport13 to13 be13 used13 by13 CoAP
bull Details13 how13 the13 transport13 can13 carry13 CoAP13 packet
bull Focus13 is13 on13 what13 CoAP13 communicaons13 requirements13 are
bull Allow13 CoAP13 mechanisms13 to13 exploit13 cross-shy‐layer13 opmisaons
51
031113
Non13 Goals13 (Not13 in13 scope)
bull Applicaon-shy‐level13 QoS13 requirementsbull Real-shy‐me13 constraintsbull Ordering13 reliability13 congeson13 controlbull Applicaon13 and13 network13 adaptaonbull Mobility13 and13 readdressing13 supportbull Network13 protocol13 (eg13 IPsec)13 configuraon
52
031113
Use13 Cases
bull NAT13 and13 Firewall13 traversal13 with13 TCPbull Delay13 Tolerant13 Networkingbull Non-shy‐IP13 Low13 Energy13 Protocols
53
031113
Related13 Work
bull OMA13 Lightweight13 M2M13 Protocolbull CoAP13 over13 SMSGPRSUSSD
54
031113
What13 does13 the13 work13 entail
bull The13 ability13 to13 specify13 end13 point13 idenfiers13 and13 URIs13 to13 reflect13 which13 transport13 CoAP13 can13 use
bull The13 ability13 to13 register13 to13 resource13 directories13 resource13 types13 reflecng13 types13 of13 transport13 available
bull Ability13 for13 mul-shy‐transport13 nodes13 to13 select13 transport13 to13 use13 without13 significant13 alteraon13 to13 CoAP13 packet13 structure
55
031113
Points13 to13 consider
bull Requirements13 for13 transport13 layer13 protocol13 to13 carry13 CoAP13 packets
bull Representaon13 of13 URI13 scheme13 for13 generic13 transport13 protocols
bull Opon13 extensions13 for13 CoAP13 to13 express13 available13 transports
bull Mapping13 and13 message13 sizebull Security13 consideraons
56
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
URI13 =13 scheme13 13 13 authority13 path-shy‐abempty13 [13 query13 ]
bull Within13 the13 scheme13 namebull In13 the13 URI13 pathbull As13 a13 query13 component
57
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
bull Within13 the13 scheme13 namendash coap+tel+15105550101well-shy‐knowncorendash coap+tcpexamplecom5683temperaturendash coap+blel2cap[1234567890AB]4pulse
bull Easy13 URI13 parsing13 for13 transport13 type13 and13 idenfier
bull Each13 new13 scheme13 name13 requires13 IANA13 registraon
58
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
bull In13 the13 URI13 pathndash coaphostexamplecomtransport=tcpwell-shy‐knowncorert=core-shy‐rd
bull Easy13 adopon13 of13 new13 (and13 experimental)13 CoAP13 transports13 without13 IANA13 registraon
bull Caveat13 Uri-shy‐Path13 opon13 is13 a13 Crical13 CoAP13 opon13 see13 secon13 54113 of13 I-shy‐Diep-shy‐core-shy‐coap
59
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
bull As13 a13 URI13 query13 componentndash coaphostexamplecomwell-shy‐knowncorert=core-shy‐rdq=tcp
bull Also13 easy13 to13 adopt13 new13 (and13 experimental)13 CoAP13 transports13 without13 IANA13 registraon
bull Caveat13 Uri-shy‐Query13 opon13 is13 a13 Crical13 CoAP13 opon13 see13 secon13 54113 of13 I-shy‐Diep-shy‐core-shy‐coap
60
031113
URI13 Representaons13 for13 CoAPNon13 standard13 ways
bull Transport13 in13 the13 URI13 authority13 componentndash coaphost[port][transport]13 instead13 of13 coaphost[port]
bull Transport13 as13 a13 service13 URLndash servicecoaptcphostexamplecomwell-shy‐knowncorert=core-shy‐rd
bull Above13 two13 ways13 break13 exisng13 compability13 (although13 both13 are13 based13 on13 valid13 IANA13 URI13 registraons)
61
031113
URI13 Representaons13 for13 CoAPMiscellaneous13 Consideraons
bull Ensure13 that13 transport13 is13 defined13 unambiguously13 (eg13 L2CAP13 used13 by13 both13 BLE13 and13 standard13 Bluetooth13 so13 avoid13 rdquocoap+l2caprdquo13 or13 rdquotransport=l2caprdquo13 or13 rdquoq=l2caprdquondash Can13 be13 done13 as13 WG13 consensusndash Namespace13 approach13 eg13 rdquocoap+blel2caprdquo13 or13 rdquoq=blel2caprdquo
bull Allow13 end-shy‐points13 to13 use13 CoAP13 Resource13 Directory13 to13 register13 alternave13 transports13 and13 idenfiers13 and13 provide13 periodic13 updatesndash Register13 rdquocore-shy‐transportrdquo13 resource13 type
62
031113
Transport13 Consideraons
bull Uniqueness13 of13 end-shy‐point13 idenficaonbull Communicaon13 support13 Unidireconal13 Bidireconal13 1N13 (broadcast13 mulcast13 anycast)13 messaging
bull Binary13 encoding13 Network13 byte13 orderingbull MTU13 correlaon13 with13 CoAP13 PDU13 sizebull Transport13 latency
63
031113
Security13 Consideraons
bull Drar13 does13 not13 introduce13 new13 security13 requirements13 by13 itself
bull There13 may13 be13 privacy13 issues13 if13 nodes13 use13 telephone13 numbers13 or13 MAC13 addresses13 as13 public13 end13 point13 idenfiers
64
Akbar Rahman
IETF 86 March 2013 httpwwwietforgiddraft-rahman-core-sleepy-02txt
Enhanced Sleepy Node Support for CoAP
Introduction
It is expected that in CoAP networks there will be a certain portion of devices that are sleepy and which may occasionally go into a sleep mode (ie go into a low power state to conserve power) and subsequently have reduced CoAP protocol communication ability
This I-D proposes a minimal and efficient mechanism building on the Resource Directory concept (which will be integrated into a CoAP Proxy) to enhance sleepy node support in CoAP networks
Main Question from IETF-85 (Atlanta)
What performance benefit does the proposed Sleepy Node support solution give in a network that already has standard CoAP caching enabled
Sleepy Node Performance Analysis
Experimental Network
1-5 clients
Both Sleepy and Non-
Sleepy servers
Sleepy Node Performance Analysis Network Setup
CoAPSleepyServer(s)
CoAPSleepAwareReverseProxy
CoAP
Client(s)
Request
Response
Sleep9AwareCoREResourceDirectoryCapability
PublishedSleepParameters
Sleep9AwareCoAPStoreandForwardCapability Response
Request
SleepAwareCoAP503ResponseCapability
CoAPCachingCapability
bull Server supports publishing sleep parameters to proxy bull Eg Irsquom going to be asleep for X seconds
bull Proxy supports sleep-awareness capabilities bull Proxy also supports caching capability based off of maxAge bull Protocol flow similar to approach of Figure 1 (Synchronous RD Based Sleep
Tracking) of I-D
Proxy capabilities can be selectively enableddisabled
Proxy ndash Server Interface
Client ndash Proxy Interface
CoAP Sleep-Aware Reverse Proxy Features CoRE Sleep-aware Resource Directory
Support storing published sleep parameters from CoAP servers sleepState (AWAKE ASLEEP) sleepDuration
Sleep-aware CoAP 503 Response Capability If CoAP request to a sleeping server is received proxy returns a
lsquo503 Retry-Afterrsquo response to client 503 contains a timestamp indicating when the sever will wake back up
(timestamp delivered in CoAP maxAge option) Sleep-aware CoAP Store-and-Forward Capability
If CoAP request to a sleeping server is received proxy stores request until server wakes up and then forwards it
Caching capability Cache GET responses from server if maxAge option is present
(this is not a sleep aware feature)
Goals of Performance Analysis
For networks having sleepy servers provide measurements to quantify the impact that CoAP sleep-awareness capabilities can have
See if sleep-awareness capabilities can
provide additional benefits even when CoAP caching is used
Overview of Performance Analysis Performed The analysis was broken up into a set of test scenarios Each test scenario used a different combination of the following
variables Client issued GET requests Server was configured as a sleepy or non-sleepy server Proxy caching of GET responses was enabled or disabled Proxy sleep-aware 503 response capability was enabled or disabled Proxy store-and-forward capability was enabled or disabled maxAge in GET responses ndash Two values were tested 60sec and 5sec of Clients ndash Two values were used ndash 1 client and 5 clients
For comparison purposes the following were held constant across all test scenarios Client issued a fixed number of requests (100) across all test scenarios Client used a delay between each GET request (35sec) to better exercise
proxyrsquos caching and sleep-awareness capabilities For sleepy server test scenarios the server slept 60 sec awake for 3 sec
Format of Results The following results were collected for each
test scenario
Breakdown of the and types of transactions occurring between clientproxyserver
ldquoGETrdquo ndash Test Scenario Results
GET ndash Description of Test Scenarios
TestScenarios-GET
Scenario
CoAPSleepyServerSe7ngs CoAPSleepAwareReverseProxySe7ngs CoAPClientSe7ngs
SleepDuragton(sec)
AwakeDuragton(sec)
maxAge(sec) Caching SleepAwareSAF+
503NumberofClients
NumberofGETs
DelayBetweenClient
Requests(sec)
1a 0 Always 60 Enabled Disabled 1 100 35
1b 60 3 60 Enabled Disabled 1 100 35
1c 60 3 60 Enabled Enabled 1 100 35
2a 0 Always 60 Enabled Disabled 5 100 35
2b 60 3 60 Enabled Disabled 5 100 35
2c 60 3 60 Enabled Enabled 5 100 35
3a 0 Always 5 Enabled Disabled 5 100 35
3b 60 3 5 Enabled Disabled 5 100 35
3c 60 3 5 Enabled Enabled 5 100 35
ldquoGETrdquo ndash Test Scenario 1 Results
maxAge = 60 and 1 Client
GET ndash Scenario 1 ClientProxy Interface Transaction Mix
Scenarios 1a - Non-Sleepy Server Caching Proxy maxAge = 60sec 1b- Sleepy Server Caching Proxy maxAge = 60sec 1c - Sleepy Server Sleep Aware Proxy maxAge = 60sec
Sleep Aware Proxy has better performance for sleepy servers
0
100
200
300
400
500
600
700
1a 1b 1c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
GET ndash Scenario 1 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
Scenarios 1a - Non-Sleepy Server Caching Proxy maxAge = 60sec 1b- Sleepy Server Caching Proxy maxAge = 60sec 1c - Sleepy Server Sleep Aware Proxy maxAge = 60sec
0
100
200
300
400
500
600
700
800
1a 1b 1c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
ldquoGETrdquo ndash Test Scenario 2 Results
maxAge = 60 and 5 Clients
GET ndash Scenario 2 ClientProxy Interface Transaction Mix
Sleep Aware Proxy has slightly better performance for sleepy servers
0
200
400
600
800
1000
1200
1400
2a 2b 2c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
Scenarios 2a - Non-Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2b- Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2c - Sleepy Server Sleep Aware Proxy maxAge = 60sec 5 Clients
See ldquoExperimental Artifactsrdquo Note 1
GET ndash Scenario 2 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has slightly better performance for sleepy servers
0
50
100
150
200
250
300
350
400
2a 2b 2c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
Scenarios 2a - Non-Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2b- Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2c - Sleepy Server Sleep Aware Proxy maxAge = 60sec 5 Clients
See ldquoExperimental Artifactsrdquo Note 2
Experimental Artifacts Note 1
Currently in the experiment the sleep aware proxy checks the cached state of a resource before putting a request into its Store-and-forward queue while a server is sleeping Once in the queue the proxy unconditionally forwards the queued requests to the server once it wakes up This is not the most efficient setup and can easily be improved If the proxy instead checks its cache again before forwarding each queued request it may not need to forward the request to the server For example if there are two queued GET requests in the proxyrsquos queue that address the same resource Only the first request needs to be sent to the server the second request can use the cached response from the first request
Note 2 Currently in the experiment the sleepy server sends a sleepState PUT request to the
proxy each time it goes to sleep This is not the most efficient setup and can easily be improved For example if the server assumes that the proxy can keep track of its ONOFF cycles with its internal timers (eg as per Fig 1 of I-D) then the number of messages from the sleepy server dramatically goes down
ldquoGETrdquo ndash Test Scenario 3 Results
maxAge = 5 and 5 Clients
GET ndash Scenario 3 ClientProxy Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
Scenarios 3a - Non-Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3b- Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3c - Sleepy Server Sleep Aware Proxy maxAge = 5sec 5 Clients
0
500
1000
1500
2000
2500
3000
3500
4000
4500
5000
3a 3b 3c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
GET ndash Scenario 3 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
0
1000
2000
3000
4000
5000
6000
7000
3a 3b 3c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
Scenarios 3a - Non-Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3b- Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3c - Sleepy Server Sleep Aware Proxy maxAge = 5sec 5 Clients
Conclusions
Conclusions These results show that sleep-aware CoAP
proxy features can significantly optimize communication with sleepy servers in most scenarios
These results also show that sleep-
awareness capabilities can provide additional benefits above and beyond CoAP caching in most scenarios
Backup
Current CoAP Support of Sleepy Node (12)
CoAP proxies can use a previously cached response to service a new GET request for a sleepy origin server (as in HTTP) But if no valid cache then proxy has to attempt to
retrieve and may fail if origin server is sleeping [I-Dietf-core-coap]
Clients can discover list of resources from RD (GET rd-lookuphellip) for sleepy servers But attempt to GET resource from sleepy origin server
may fail if origin server is sleeping [IDietf-core-link-format amp IDshelby-core-resource-
directory]
Current CoAP Support of Sleepy Node (22)
Lower layer support for sleepy nodes in most wireless technologies (eg WiFi ZigBee) But limited to MAC packet scheduling for sleepy nodes
and not aware of specific needs of IP applications (like CoAP)
Proposal ndash RD Based Sleep Tracking (14)
The current CoAP approach to support sleepy nodes can be significantly improved by introducing RD based mechanisms for a CoAP client to determine whether A targeted resource is located on a sleepy server A sleepy server is currently in sleep mode or not
There is any associated caching Proxy (possibly the RD itself) for a sleepy server
Proposal ndash RD Based Sleep Tracking (24)
We define the following new RD attributes to characterize the properties of a sleepy node SleepState - Indicates whether the node is currently in
sleep mode or not (ie Sleeping or Awake) SleepDuration - Indicates the maximum duration of time
that the node stays in sleep mode TimeSleeping - Indicates the length of time the node
has been sleeping (ie if Sleep State = Sleeping) NextSleep - Indicates the next time the node will go to
sleep (ie if Sleep State = Awake)
CachingProxy ndash Indicates the caching proxy of the sleepy node (ie the RD itself or another node)
Proposal ndash RD Based Sleep Tracking (34)
These attributes are all server (node) level and are new parameters added to the RD URI Template Variables
Finally we also define a new lookup-type (ss) for the RD lookup interface specified in [I-Dshelby-core-resource-directory] This new lookup-type supports looking up the
ldquoSleepStaterdquo (ss) of a specified end-point
Proposal ndash RD Based Sleep Tracking (44)
The three time based parameters (SleepDuration TimeSleeping NextSleep) can be based on either an absolute network time (for a time synchronized network) or a relative local time (measured at the local node)
Following the approach of [I-Dietf-core-link-format] and [I-Dshelby-core-resource-directory] sleep parameters for sleepy servers can be stored by the server in the RD and accessed by all interested clients
Examples of using these parameters in a synchronous or asynchronous manner are shown in the I-D
http6lowappnet coreIETF86 2013-03-12-13
We assume people have read the drafts
Meetings serve to advance difficult issues by making good use of face-to-face communications
Note Well Be aware of the IPR principles according to RFC 3979 and its updates
uumlBlue sheetsuumlScribe(s)
96
drar-shy‐iep-shy‐core-shy‐coapsubmiqed13 to13 IESG
2013-shy‐03-shy‐13
97
OMA Lightweight M2M Overview(A new standard using lots of IETF specs including DTLS
CoAP Block Observe Resource Directory SenMLhellip)
Zach ShelbyCoRE WG IETF-86 Orlando
OMA Lightweight M2Mbull Open Mobile Alliance is well known for Device Management (DM)bull OMA Lightweight M2M is a new standard from the alliance
ndash Focused on constrained Cellular and sensor network M2M devicesndash Driven by leading operators and vendors
bull Scopendash Interfaces protocol amp security between Device and Serverndash Object and Resource modelndash Bootstrap Device Access Control Connectivity and Firmware Objects
bull Draft Specifications are availablendash httpmemberopenmobileallianceorgftpPublic_documentsDM
LightweightM2MPermanent_documentsOMA-TS-LightweightM2M-V1_0_0-20130301-Dzip
bull Timelinendash Requirements and Architecture completed 3Q2012ndash Spec ready for Consistency Review 2Q2013ndash Candidate Approval expected 3Q2013
2 CoRE WG IETF-86 Orlando
Architecture
3
Scope of LWM2M
CoRE WG IETF-86 Orlando
Object Model
bull A Client has one or more Object Instancesbull An Object is a collection of Resourcesbull A Resource is an atomic piece of information
ndash Read Written or Executed
bull Resources can have multiple instancesbull Objects and Resources are identified by a
16-bit Integer Instances by an 8-bit Integerbull ObjectsResources are accessed with
simple URIs Object IDObject InstanceResource ID
eg 1213
4 CoRE WG IETF-86 Orlando
CoRE WG IETF-86 Orlando
CoRE Resource Directory
draft-shelby-core-resource-directory-05
Z Shelby C Bormann S Krco
Backgroundbull Not a new concept
ndash think web search engine or any link directorybull Defines the interfaces to a Resource Directorybull Based on Web Linking framework and the CoRE Link Formatbull Generic REST design for use over HTTP and CoAPbull Used by OMA Lightweight M2Mbull Has already been deployed
ndash In traffic monitoring systemsndash In street lighting systemsndash For vehicular asset trackingndash By a major Cellular M2M operator
Changes since -04
bull Restricted Update to parameter updatesbull Added pagination support for the Lookup interfacebull Changed rt= to et= for the registration amp update
interfacebull Added group support
Group Management
bull RD now includes group management featuresbull New Group Function Set
ndash Register a groupbull Group name domain multicast address endpoint members
ndash Remove a groupbull Group lookup using the Lookup Function Set
ndash List registered groupsndash Find the members of a groupndash Find groups with certain endpoints or resources
Registering a Group
EP RD
| |
| - POST rd-groupgp=lights ltgtep=node1 --gt |
| |
| |
| lt---- 201 Created Location rd-group12 ---- |
| |
Req POST coaprdexamplecomrd-groupgp=lights
Payload
ltgtep=node1
ltgtep=node2
Res 201 Created
Location rd-group12
Looking up Group Members
Client RD
| |
| ----- GET rd-lookupepgp=lights1 ----------------------gt |
| |
| |
| lt-- 205 Content ltrdgtd=domain1ltrdgtd=domain2 --------- |
| |
Req GET rd-lookupepgp=lights1
Res 205 Content
ltcoaphostportgtep=node1
ltcoaphostportgtep=node2rdquo
Things for the futurebull Support for JSON representation of Web Links
ndash httptoolsietforgiddraft-bormann-core-links-json-02txtbull Registry for RD registration query parameters
ndash Already OMA Lightweight has defined some new onesbull More examples
Group 3 ldquonew workrdquo(continued)
109
drar-shy‐greevenbosch-shy‐core-shy‐profile-shy‐descripon-shy‐01Bert13 GreevenboschJeroen13 Hoebeke
Isam13 IshaqFloris13 Van13 den13 Abeele
Descripon
bull JSON13 format13 for13 signalling13 the13 servers13 capabilies
bull Signalling13 of13 supported13 opons13 media13 types13 and13 block13 sizendash Other13 items13 can13 be13 added
bull Filtering13 on13 specific13 fields13 through13 URI-shy‐Querybull Link13 hqpdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐profile-shy‐descripon
well-shy‐knownprofile
bull To13 acquire13 profile13 data13 of13 resources13 on13 a13 parcular13 service13 the13 well-shy‐knownprofile13 URI-shy‐path13 is13 introduced
bull For13 example13 to13 get13 all13 informaon13 from13 sensors13 served13 by13 wwwexampleorg13 we13 can13 do13 a13 GET13 to13 coapwwwexampleorgwell-shy‐knownprofile
bull Filtering13 on13 parcular13 resources13 is13 done13 through13 URI-shy‐Queries
Format
bull Currently13 the13 following13 fields13 are13 definedndash ldquopathrdquo13 contains13 the13 URI-shy‐path13 associated13 with13 a13 resource
ndash ldquooprdquo13 a13 numerical13 list13 of13 supported13 opon13 numbers
ndash ldquocfrdquo13 a13 numerical13 list13 of13 supported13 content-shy‐format13 numbers
ndash ldquob1srdquo13 ldquob2srdquo13 supported13 block13 sizes13 for13 Block113 and13 Block213 respecvely
Examplebull On13 the13 right13 is13 an13 example13 of13 a13 camera13 sensor13 at13 coapwwwexampleorgcam13 that13 supports13 the13 Uri-shy‐Host13 (3)13 ETag13 (4)13 Uri-shy‐Port13 (7)13 Uri-shy‐Path13 (11)13 Content-shy‐Format13 (12)13 Token13 (19)13 Block213 (23)13 and13 Proxy-shy‐Uri13 (35)13 opons
bull The13 supported13 content13 formats13 are13 textplain13 (0)13 applicaon13 link-shy‐format13 (40)13 and13 applicaonjson13 (50)
bull The13 supported13 Block213 can13 use13 25613 or13 51213 byte13 blocks
Req13 GET13 coapwwwexampleorgwell-shy‐knownprofile13 Res13 20513 Content13 (applicationjson)13 13 13 13 profile13 13 13 13 13 13 13 13 pathcam13 13 13 13 op[3471112192335]13 13 13 13 13 cf[04050]13 13 13 13 13 b2s[45]13 13 13 13
Filtering13 through13 use13 of13 URI-shy‐Query
bull Filtering13 can13 be13 done13 through13 the13 URI-shy‐Querybull Query13 format13 N=V
ndash N13 is13 a13 profile13 fieldndash V13 is13 the13 desired13 value
bull Examplesndash To13 find13 resources13 that13 support13 content13 format13 ldquoapplicaonjsonrdquo
13 GET13 wwwexampleorgwell-shy‐knownprofilecf=50ndash To13 get13 informaon13 about13 the13 camera
13 GET13 wwwexampleorgwell-shy‐knownprofilepath=cam
Open13 issues
bull Which13 other13 profile13 data13 needs13 signallingndash Content-shy‐type13 for13 different13 methods
bull Fix13 the13 order13 in13 which13 the13 profile13 fields13 must13 appearndash Non-shy‐fixed13 order13 easier13 extensible
bull Inheritance13 of13 a13 profile13 descriponbull Extend13 usage13 to13 signal13 the13 client13 profilebull Integraon13 with13 link13 format
Thank13 youQuesons
drar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval-shy‐00
Bert13 Greevenbosch
Descripon
bull The13 ldquoMinimumRequestInterval13 opon13 can13 be13 used13 to13 indicate13 the13 minimum13 me13 between13 two13 requests13 in13 a13 transacon
bull Originally13 intended13 for13 Block13 but13 also13 usable13 for13 other13 transaconsndash Example13 browsing13 a13 server
bull The13 goal13 is13 to13 reduce13 the13 server13 load13 and13 network13 traffic
bull Link13 hqpsdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval
Usage
bull The13 client13 keeps13 the13 server13 informed13 about13 its13 request13 speed13 through13 inclusion13 of13 the13 ldquoMinimumRequestIntervalrdquo13 opon
bull In13 responses13 the13 server13 fixes13 the13 minimum13 request13 interval13 through13 the13 same13 opon
bull The13 client13 obeys13 the13 speed13 indicated13 by13 the13 server
bull The13 client13 can13 send13 slower13 but13 not13 faster
Advantages
bull The13 server13 has13 means13 to13 limit13 the13 amount13 of13 incoming13 traffic
bull The13 server13 can13 prevent13 to13 become13 overloaded13 with13 too13 many13 tasks
bull The13 server13 does13 not13 need13 arficially13 slow13 down13 the13 client13 by13 sending13 late13 ACKsndash No13 need13 to13 keep13 track13 of13 delayed13 ACKsndash The13 server13 can13 perform13 other13 tasks13 instead
bull Reduced13 network13 traffic
Thank13 youQuesons
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-links-json-02txt
123
RFC 6690 (link-format) documents are somewhat foreign to many web app developerssect would prefer to have them in JSON format
There is no standard way to represent link-format documents in applicationssect but everyone knows how to handle JSON
Define a standard JSON translation for link-format
Itrsquos
not
rock
et
scien
ce
ltsensorsgtct=40title=Sensor Index ltsensorstempgtrt=temperature-cif=sensor ltsensorslightgtrt=light-luxif=sensor lthttpwwwexamplecomsensorst123gt anchor=sensorstemprel=describedby lttgtanchor=sensorstemprel=alternate [hrefsensorsct40titleSensor Index hrefsensorstemprttemperature-cifsensor hrefsensorslightrtlight-luxifsensor hrefhttpwwwexamplecomsensorst123 anchorsensorstempreldescribedby hreftanchorsensorstemprelalternate]
124
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-ipsec-for-coap-00txt
IPsec definitions for CoAP Mostly placeholder at this time Who has implementation experience with this
125
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-cross-reverse-convention-00txt
This draft has two lines of payload(based on a WGLC comment by Cullen Jennings)
coap12344567foobara=3
httpwwwproxycomwellknowncore-translate1234_4567foobara=3
Is that a useful convention to have
126
Insert CI slides here
127
128
0
5
10
15
20
25
30
35
40
10 20 30 40 50 60 70
good
put (
pps)
pps
Goodput vs pps (Econotags)
goodput
[Khattak preliminary]
Congestion Control
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-cocoa-00txt
ldquoadvancedrdquo cc (The draft is just a first shot) Others may have better ideas
129
Insert post-WGLC discussion slides here
130
Stop Continue Start
131
An Agile Retrospective
http6lowappnet coreIETF86 2013-03-12-13
Stop
132
Endless new CoAP optionssect instead use RESTful as much as possible
Move general security lifecycle out Looking at theoretical problems
http6lowappnet coreIETF86 2013-03-12-13
Continue
Interops Running code Look at real-world examples and deployments Solve their actual problems
sect Unilateral enhancements eg higher performance congestion control
sect Transports (SMS hellip)sect Make Web linking and Directories more and more usefulsect RESTful Design Paradigms for real-world problems
133
http6lowappnet coreIETF86 2013-03-12-13
Start
Further push into the (browser) web world (HTML5 browser security)
Specific supporting worksect SenMLsect URI work (dev URN hellip)sect Security Processes (next slide)
Spin outsect (We donrsquot really get to decide where this is done)
134
http6lowappnet coreIETF86 2013-03-12-13
Security
Integrate Application Network Group Keyingsect Tunnel-free setup
Donrsquot redo what has been done alreadysect ZigBee IP is finesect But what about other scenarios
Simple REST interfaces for working with keying materials and authorizationsect Start with defining objectives
Object Security for Constrained Nodes135
Re-chartering CoREWhat do we want to do now that wersquore grown up
Zach ShelbyCoRE WG IETF-86 Orlando
What is the scope
bull So we have a protocol and Web Linking what next
bull Keep with what we know besthellip1 Enhancements around CoAP2 New transports for CoAP3 New representations for Web Links4 General application layer solutions
CoRE WG IETF-86 Orlando 2
Enhancements around CoAP
bull Advanced congestion control
CoRE WG IETF-86 Orlando 3
New Transports for CoAP
bull Infrastructure for CoAP over foondash httptoolsietforgiddraft-silverajan-core-
coap-alternative-transports-01txtbull CoAP over SMS
ndash httptoolsietforgiddraft-becker-core-coap-sms-gprs-03txt
ndash OMA Lightweightbull CoAP over TCP
ndash httptoolsietforgiddraft-li-core-coap-payload-length-option-01txt
CoRE WG IETF-86 Orlando 4
New support for Web Links
bull JSON Web Linksndash httptoolsietforgiddraft-bormann-core-links-
json-02txt
2332010 CoRE WG IETF-77 Anaheim 5
General application layer solutions
bull Resource Directoryndash httptoolsietforgiddraft-shelby-core-
resource-directory-05txtndash OMA Lightweight
2332010 CoRE WG IETF-77 Anaheim 6
Akbar RahmanEsko Dijk
IETF 86 March 2013httpwwwietforgiddraft-ietf-core-groupcomm-05txt
Group Communication for CoAP
Summary of Changes (14)
n I-D had two updates (Rev 04 amp 05) after IETF-85 (Atlanta) Many of the updates were due to the detailed review by Peter van der Stokn Thank you Peter for your valuable comments
n Changes from ietf-03 to ietf-04 n Section 23 (Potential Solutions for Group Communications) moved to
draft-dijk-core-groupcomm-misc (266)n Added reference to draft-keoh-tls-multicast-security to section 6 (Security
Considerations) n Appendix B (CoAP-Observe Alternative to Group Communications) moved
to draft-dijk-core-groupcomm-misc (267) n Deleted section 8 (Conclusions) as it is redundant (268) n Simplified light switch use case (269) by splitting into basic operations and
additional functions (269)
Summary of Changes (24)
n Changes from ietf-03 to ietf-04 (Continued) n Moved section 37 (CoAP Multicast and HTTP Unicast Interworking) to
draft-dijk-core-groupcomm-misc (270) n Moved section 331 (DNS-SD) and 332 (CoRE Resource Directory) to
draft-dijk-core-groupcomm-miscClarified that DNS based features are optional (272)
n Focus section 35 (Configuring Group Membership) on a single proposed solution
n Scope of section 53 (Use of MLD) widened to multicast destination advertisement methods in general
n Rewrote section 22 (Scope) for improved readibility n Moved use cases that are not adressed to draft-dijk-core-groupcomm-miscn Various editorial updates for improved readibility
Summary of Changes (34)
n Changes from ietf-04 to ietf-05 n Added a new section 39 (Exceptions) that highlights that IP multicast (and
hence group communications) is not always available (187) n Included guidelines on when (not) to use CoAP responses to multicast
requests and when (not) to accept multicast requests (273) n Added guideline on use of core-block for minimizing response size (275)n Restructured section 6 (Security Considerations) to more fully describe
threats and threat mitigation (277) n Clearly indicated that DNS resolution and reverse DNS lookup are optional n Removed confusing text about a single group having multiple IP addresses
If multiple IP addresses are required then multiple groups (with the same members) should be created
n Removed repetitive text about the fact that group communications is not guaranteed
Summary of Changes (44)
n Changes from ietf-04 to ietf-05 (Continued) n Merged previous section 52 (Multicast Routing) into 31 (IP Multicast
Routing Background) and added link to section 52 (Advertising Membership of Multicast Groups)
n Clarified text in section 38 (Congestion Control) regarding precedence of use of IP multicast domains (ie first try to use link-local scope then site-local scope and only use global IP Communication for CoAP multicast as a last resort)
n Extended group resource manipulation guidelines with use of preconfigured portspaths for the multicast group
n Consolidated all text relating to ports in a new section 33 (Port Configuration)
n Clarified that all methods (GETPUTPOST) for configuring group membership in endpoints should be unicast (and not multicast) in section 37 (Configuring Group Membership In Endpoints)
n Various editorial updates for improved readability
Discussion item (11)
n Solution for Configuring Group Membership (no ticket)n Example of (unicast) configuring an endpoint to be part of one multicast
groupReq POST gp (Content-Format applicationjson)
n floor1westbldg6examplecom ip ff154200f7feed3714cb Res 204 Changed
n Where the ldquogprdquo resource has resource type (rt) ldquocoregprdquo which is defined for this purpose
n Question Do we want specify such a solution (or for example leave it completely up to implementation)
Open Issues(15)
n Review Groupcomm requirements language (271)n Decision made to keep requirements language for informational draftn Each use of MAYMUSTSHOULD etc is to be reviewed
Open Issues(25)
n Add section on multicast via Proxy and its limitations (274)n Add a section to explain the issues amp limitations of doing CoAP multicast
requests via a CoAP Proxy n Goal is to warn and guide implementers in this subject n Also such a section would provide a placeholderreminder of the problems
that might be addressed further in the futuren Based on IETF 85 CoRE WG meeting discussion on Multicast CoAP
requests via a Proxy Discussion summary for referencen Aggregation of responses in a proxy is difficult since it doesnt know
when to stop aggregating responses n SIP tried to deal with this problem but didnt solve it n There may be an expectancy of CoAP client to get single response
back from proxy not multiple The client in this case may not even know what it could expect It may not even know the Proxy-URI contains a multicast target
n Presented via-proxy use case exposes gap in the core-coap specification regarding multicast via proxy (Note Expectation is that core-coap wonrsquot address it in the first planned RFC release)
Open Issues(35)
n Issues with twomultiple Resource Directories in use case (280)n Some potential issues with RD came out of review Peter van der Stok and
WG discussion IETF85 n There are two RD servers use case shows that only one is found despite
the fact that site-local multicast is used - should be two RDs found n Proposal simplify use case to a single RD server on the backbone to avoid
such RD-specific issues like synchronization of RD information between servers
Open Issues(45)
n Add single-subnet configuration to use cases (278)n Suggested by review Peter van der Stok and IETF85 WG discussion that
its best to start explaining the simplebasic cases and then gradually build up complexity
n Simplest case not shown yet would be a single subnet network configuration which is currently not present in the I-D only the 2-subnet configuration of Fig 1
n Question Do we need to add such case or doesnt it add muchn (Note that core-coap Figure 22 already shows the simplest case of link-local
multicast)
Open Issues(55)
n Add use case with controller (client) located on the backbone (279)n Suggested by discussion following review Peter van der Stok n Case missing where a controller (client) is located on the backbonen Question Do we need to add such case or does it add much
Group 2a other old friends
25
Angelo Castellani Salvatore Loreto Akbar Rahman Thomas Fossati Esko Dijk
IETF 86 March 2013httpwwwietforgiddraft-castellani-core-http-mapping-07txt
Best Practices for HTTP-CoAP Mapping
Implementation
Summary of Changes (from -06 rev)
n Based on discussion at last IETF-85 (Atlanta)n Clarification of HTTP-CoAP Proxies
n Definitionn Placementn Benefits
n Clarification of HTTP-CoAP URI mapping options
Goals of I-D
n For Reverse HTTP-CoAP Cross Protocol Proxyn Provide more detailed information to proxy designers (beyond
Section 10 of [I-Dietf-core-coap]) to help implement proxies that correctly inter-work with other CoAP and HTTP clientserver implementations that adhere to the specifications
n Define a consistent set of guidelines that a HTTP-to-CoAP proxy implementation MAY adhere to The main reason of adhering to such guidelines is to reduce variation between proxy implementations thereby increasing interoperabilityn As an example use case a proxy conforming to these guidelines made
by vendor A can be easily replaced by a proxy from vendor B that also conforms to the guidelines
I-D Outline
n Guidance on HTTP to CoAP URI mappingn HTTP-CoAP Reverse cross-protocol proxy implementation
n Placementn Response code amp media type translationsn Caching and congestion controln Cache refresh via Observen Use of CoAP blockwise transfern Security translation
n Security Considerationsn Traffic overflown Handling secured exchanges
Definitions (12)
n Cross-Protocol Proxy (or Cross Proxy) is a proxy performing a cross- protocol mapping in the context of this document a HTTP-CoAP (HC) mapping A Cross-Protocol Proxy can behave as a Forward Proxy Reverse Proxy or Interception Proxy n Note In this document we focus on the Reverse Proxy mode of the
Cross-Protocol Proxy
n Forward Proxy a message forwarding agent that is selected by the client usually via local configuration rules to receive requests for some type(s) of absolute URI and to attempt to satisfy those requests via translation to the protocol indicated by the absolute URI The user decides (is willing to) use the proxy as the forwardingdereferencing agent for a predefined subset of the URI space
Definitions (22)
n Reverse Proxy a receiving agent that acts as a layer above some other server(s) and translates the received requests to the underlying servers protocol It behaves as an origin (HTTP) server on its connection towards the (HTTP) client and as a (CoAP) client on its connection towards the (CoAP) origin server The (HTTP) client uses the origin-form [I-Dietf-httpbis-p1-messaging] as a request- target URI
n Reverse and Forward proxies are technically very similar with main differences being that the former appears to a client as an origin server while the latter does not and that clients may be unaware they are communicating with a proxy
Reverse Cross-Protocol Proxy Deployment Scenario
HTTP-CoAP Response Code Mapping
Implementation Experience
n Direct experience from the draft authorsn Squid HTTP-CoAP mapping module
n University of Padovan httptelecomdeiunipditiotn Both Forward and Interception operation supported
n HTTP-CoAP proxy based on EvCoAPn KoanLogic University of Bologna and Salvatore
Loreto (as individual)n httpsgithubcomkoanlogicwebthingstreemasterbridgesw
libevcoapn The document is open to input from other implementations
Next Steps
n Does the WG recommend adoptionn Intended status Informational Best Practicen Purpose Reduce arbitrary variation between proxy
implementations thereby increasing interoperability
Backup
HTTP to CoAP URI Mapping Options (12)
n Embedded Mapping n In an embedded mapping approach the HTTP URI has embedded
inside it the authority and path part of the CoAP URI n Example The CoAP resource nodecoapsomethingnetfoo can
be accessed by an HTTP client by inserting in the request httphc-proxysomethingnetcoapnodecoapsomethingnetfoo The Cross-Protocol Proxy then maps the URI to coapnodecoapsomethingnetfoo
HTTP to CoAP URI Mapping Options (22)
n Homogeneous Mapping n In a homogeneous mapping approach only the scheme portion of the URI
needs to be mapped The rest of the URI (ie authority path etc) remains unchanged
n Example The CoAP resource coapnodecoapsomethingnetfoo can be accessed by an HTTP client by requesting httpnodecoapsomethingnetfoo The Cross-Protocol Proxy receiving the request is responsible to map the URI to coapnodecoapsomethingnetfoo
n Background info n The assumption in this case is that the HTTP client would be able to
successfully resolve nodecoapsomethingnet using DNS infrastructure to return the IP address of the HC proxy Most likely this would be through a two step DNS lookup where the first DNS lookup would resolve somethingnet using public DNS infrastructure
n Then the second DNS lookup on the subdomain coap and the host node would typically be resolved by a DNS server operated by the owner of domain somethingnet So this domain owner can manage its own internal node names and subdomain allocation which would correspond to the CoAP namespace
Group 3 ldquonew workrdquo
39
Transport of CoAP over SMS USSD and GPRSdraft-becker-core-coap-sms-gprs-03
Markus Becker Kepeng LiKoojana Kuladinithi Thomas Poumltsch
CoRE WG IETF-86 Orlando
1 10
ScenariosI In M2M communication IP connectivity is not alwayssupported by the constrained end-points
I Power savingI Coverage (GPRS 3G LTE)
I SMS and USSD based communication is almost alwayssupported
210
Changes from draft-01 to draft-03 (1)
I Added possible CONNONACK interactions Section 5
I Option name changed from Reply-To- to Response-To-Section 16 and Section 101
I Added URI schemeEg coap+tel+15105550101well-knowncore Section 11
I Added possible M2M proxy scenarios Section 14
3 10
Changes from draft-01 to draft-03 (2)
I Added reference to bormann-coap-misc for other SMSencoding Section 71
I Updated requirements on Uri-Host and Uri-Port forcoap+tel Section 10
I Added security considerations Transport and ObjectSecurity Section 15
I Chose CoAP option numbers and updated the optionnumber table to meet draft-ietf-core-coap-10 Table 1
I Added an IANA registration for the URI scheme coap+telSection 162
4 10
Feedback Split coap+tel into coap+smsand coap+ussd
I How else to differ the various transports in the URII Or is the transport to use decided by the implementationI See alsodraft-silverajan-core-coap-alternative-transports-01
5 10
Feedback Response-To-Scheme option
I Should there be a Response-To-Scheme optionadditionally to Response-To-Uri-Host andResponse-To-Uri-Path
I So that a CoAP end-point which receives a request by CoAPover non-IP transport can be instructed to also use thenon-IP transport for the response
I This would imply to add aResponse-To-Telephone-Subscriber and more options forother transports that have other URI schemes than coapand coaps
6 10
Feedback Selection of Transport by Client
I When a server is reachable by various transports howdoes a client decide which transport to use
I Client-side application congurationI Leave it to a proxy which uses cellular network lookupfunctions
7 10
Feedback Potential Threats
I Trigger expensive short messagesI Redirect trac to other addressesI More threats
I Are the security measures in the draft adequateI Whitelisting on serverI Relying on cellular network security (dedicated M2M APNs)I Object security on CoAP payload
8 10
Feedback Message Exchanges
I Figures 11-18 show possible message exchanges whenclient and server have two addresses
I With NON Not using CoAP retransmission capabilityI ACK on different transportI Additional (costly) message on Transport AI Request with Content
I Which ones are allowedI Which ones are meaningful
9 10
Next steps
I Rene Uri schemeI Response-To-Scheme optionI Selection of Message ExchangeI Rene Proxying
10 10
CoAP13 Communicaon13 with13 Alternave13 Transports
Bill Silverajan and Teemu SavolainenCore WG IETF 86 Orlando
031113
Objecves13 (In13 Scope)
bull Unambiguous13 representaon13 of13 transport13 to13 be13 used13 by13 CoAP
bull Details13 how13 the13 transport13 can13 carry13 CoAP13 packet
bull Focus13 is13 on13 what13 CoAP13 communicaons13 requirements13 are
bull Allow13 CoAP13 mechanisms13 to13 exploit13 cross-shy‐layer13 opmisaons
51
031113
Non13 Goals13 (Not13 in13 scope)
bull Applicaon-shy‐level13 QoS13 requirementsbull Real-shy‐me13 constraintsbull Ordering13 reliability13 congeson13 controlbull Applicaon13 and13 network13 adaptaonbull Mobility13 and13 readdressing13 supportbull Network13 protocol13 (eg13 IPsec)13 configuraon
52
031113
Use13 Cases
bull NAT13 and13 Firewall13 traversal13 with13 TCPbull Delay13 Tolerant13 Networkingbull Non-shy‐IP13 Low13 Energy13 Protocols
53
031113
Related13 Work
bull OMA13 Lightweight13 M2M13 Protocolbull CoAP13 over13 SMSGPRSUSSD
54
031113
What13 does13 the13 work13 entail
bull The13 ability13 to13 specify13 end13 point13 idenfiers13 and13 URIs13 to13 reflect13 which13 transport13 CoAP13 can13 use
bull The13 ability13 to13 register13 to13 resource13 directories13 resource13 types13 reflecng13 types13 of13 transport13 available
bull Ability13 for13 mul-shy‐transport13 nodes13 to13 select13 transport13 to13 use13 without13 significant13 alteraon13 to13 CoAP13 packet13 structure
55
031113
Points13 to13 consider
bull Requirements13 for13 transport13 layer13 protocol13 to13 carry13 CoAP13 packets
bull Representaon13 of13 URI13 scheme13 for13 generic13 transport13 protocols
bull Opon13 extensions13 for13 CoAP13 to13 express13 available13 transports
bull Mapping13 and13 message13 sizebull Security13 consideraons
56
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
URI13 =13 scheme13 13 13 authority13 path-shy‐abempty13 [13 query13 ]
bull Within13 the13 scheme13 namebull In13 the13 URI13 pathbull As13 a13 query13 component
57
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
bull Within13 the13 scheme13 namendash coap+tel+15105550101well-shy‐knowncorendash coap+tcpexamplecom5683temperaturendash coap+blel2cap[1234567890AB]4pulse
bull Easy13 URI13 parsing13 for13 transport13 type13 and13 idenfier
bull Each13 new13 scheme13 name13 requires13 IANA13 registraon
58
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
bull In13 the13 URI13 pathndash coaphostexamplecomtransport=tcpwell-shy‐knowncorert=core-shy‐rd
bull Easy13 adopon13 of13 new13 (and13 experimental)13 CoAP13 transports13 without13 IANA13 registraon
bull Caveat13 Uri-shy‐Path13 opon13 is13 a13 Crical13 CoAP13 opon13 see13 secon13 54113 of13 I-shy‐Diep-shy‐core-shy‐coap
59
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
bull As13 a13 URI13 query13 componentndash coaphostexamplecomwell-shy‐knowncorert=core-shy‐rdq=tcp
bull Also13 easy13 to13 adopt13 new13 (and13 experimental)13 CoAP13 transports13 without13 IANA13 registraon
bull Caveat13 Uri-shy‐Query13 opon13 is13 a13 Crical13 CoAP13 opon13 see13 secon13 54113 of13 I-shy‐Diep-shy‐core-shy‐coap
60
031113
URI13 Representaons13 for13 CoAPNon13 standard13 ways
bull Transport13 in13 the13 URI13 authority13 componentndash coaphost[port][transport]13 instead13 of13 coaphost[port]
bull Transport13 as13 a13 service13 URLndash servicecoaptcphostexamplecomwell-shy‐knowncorert=core-shy‐rd
bull Above13 two13 ways13 break13 exisng13 compability13 (although13 both13 are13 based13 on13 valid13 IANA13 URI13 registraons)
61
031113
URI13 Representaons13 for13 CoAPMiscellaneous13 Consideraons
bull Ensure13 that13 transport13 is13 defined13 unambiguously13 (eg13 L2CAP13 used13 by13 both13 BLE13 and13 standard13 Bluetooth13 so13 avoid13 rdquocoap+l2caprdquo13 or13 rdquotransport=l2caprdquo13 or13 rdquoq=l2caprdquondash Can13 be13 done13 as13 WG13 consensusndash Namespace13 approach13 eg13 rdquocoap+blel2caprdquo13 or13 rdquoq=blel2caprdquo
bull Allow13 end-shy‐points13 to13 use13 CoAP13 Resource13 Directory13 to13 register13 alternave13 transports13 and13 idenfiers13 and13 provide13 periodic13 updatesndash Register13 rdquocore-shy‐transportrdquo13 resource13 type
62
031113
Transport13 Consideraons
bull Uniqueness13 of13 end-shy‐point13 idenficaonbull Communicaon13 support13 Unidireconal13 Bidireconal13 1N13 (broadcast13 mulcast13 anycast)13 messaging
bull Binary13 encoding13 Network13 byte13 orderingbull MTU13 correlaon13 with13 CoAP13 PDU13 sizebull Transport13 latency
63
031113
Security13 Consideraons
bull Drar13 does13 not13 introduce13 new13 security13 requirements13 by13 itself
bull There13 may13 be13 privacy13 issues13 if13 nodes13 use13 telephone13 numbers13 or13 MAC13 addresses13 as13 public13 end13 point13 idenfiers
64
Akbar Rahman
IETF 86 March 2013 httpwwwietforgiddraft-rahman-core-sleepy-02txt
Enhanced Sleepy Node Support for CoAP
Introduction
It is expected that in CoAP networks there will be a certain portion of devices that are sleepy and which may occasionally go into a sleep mode (ie go into a low power state to conserve power) and subsequently have reduced CoAP protocol communication ability
This I-D proposes a minimal and efficient mechanism building on the Resource Directory concept (which will be integrated into a CoAP Proxy) to enhance sleepy node support in CoAP networks
Main Question from IETF-85 (Atlanta)
What performance benefit does the proposed Sleepy Node support solution give in a network that already has standard CoAP caching enabled
Sleepy Node Performance Analysis
Experimental Network
1-5 clients
Both Sleepy and Non-
Sleepy servers
Sleepy Node Performance Analysis Network Setup
CoAPSleepyServer(s)
CoAPSleepAwareReverseProxy
CoAP
Client(s)
Request
Response
Sleep9AwareCoREResourceDirectoryCapability
PublishedSleepParameters
Sleep9AwareCoAPStoreandForwardCapability Response
Request
SleepAwareCoAP503ResponseCapability
CoAPCachingCapability
bull Server supports publishing sleep parameters to proxy bull Eg Irsquom going to be asleep for X seconds
bull Proxy supports sleep-awareness capabilities bull Proxy also supports caching capability based off of maxAge bull Protocol flow similar to approach of Figure 1 (Synchronous RD Based Sleep
Tracking) of I-D
Proxy capabilities can be selectively enableddisabled
Proxy ndash Server Interface
Client ndash Proxy Interface
CoAP Sleep-Aware Reverse Proxy Features CoRE Sleep-aware Resource Directory
Support storing published sleep parameters from CoAP servers sleepState (AWAKE ASLEEP) sleepDuration
Sleep-aware CoAP 503 Response Capability If CoAP request to a sleeping server is received proxy returns a
lsquo503 Retry-Afterrsquo response to client 503 contains a timestamp indicating when the sever will wake back up
(timestamp delivered in CoAP maxAge option) Sleep-aware CoAP Store-and-Forward Capability
If CoAP request to a sleeping server is received proxy stores request until server wakes up and then forwards it
Caching capability Cache GET responses from server if maxAge option is present
(this is not a sleep aware feature)
Goals of Performance Analysis
For networks having sleepy servers provide measurements to quantify the impact that CoAP sleep-awareness capabilities can have
See if sleep-awareness capabilities can
provide additional benefits even when CoAP caching is used
Overview of Performance Analysis Performed The analysis was broken up into a set of test scenarios Each test scenario used a different combination of the following
variables Client issued GET requests Server was configured as a sleepy or non-sleepy server Proxy caching of GET responses was enabled or disabled Proxy sleep-aware 503 response capability was enabled or disabled Proxy store-and-forward capability was enabled or disabled maxAge in GET responses ndash Two values were tested 60sec and 5sec of Clients ndash Two values were used ndash 1 client and 5 clients
For comparison purposes the following were held constant across all test scenarios Client issued a fixed number of requests (100) across all test scenarios Client used a delay between each GET request (35sec) to better exercise
proxyrsquos caching and sleep-awareness capabilities For sleepy server test scenarios the server slept 60 sec awake for 3 sec
Format of Results The following results were collected for each
test scenario
Breakdown of the and types of transactions occurring between clientproxyserver
ldquoGETrdquo ndash Test Scenario Results
GET ndash Description of Test Scenarios
TestScenarios-GET
Scenario
CoAPSleepyServerSe7ngs CoAPSleepAwareReverseProxySe7ngs CoAPClientSe7ngs
SleepDuragton(sec)
AwakeDuragton(sec)
maxAge(sec) Caching SleepAwareSAF+
503NumberofClients
NumberofGETs
DelayBetweenClient
Requests(sec)
1a 0 Always 60 Enabled Disabled 1 100 35
1b 60 3 60 Enabled Disabled 1 100 35
1c 60 3 60 Enabled Enabled 1 100 35
2a 0 Always 60 Enabled Disabled 5 100 35
2b 60 3 60 Enabled Disabled 5 100 35
2c 60 3 60 Enabled Enabled 5 100 35
3a 0 Always 5 Enabled Disabled 5 100 35
3b 60 3 5 Enabled Disabled 5 100 35
3c 60 3 5 Enabled Enabled 5 100 35
ldquoGETrdquo ndash Test Scenario 1 Results
maxAge = 60 and 1 Client
GET ndash Scenario 1 ClientProxy Interface Transaction Mix
Scenarios 1a - Non-Sleepy Server Caching Proxy maxAge = 60sec 1b- Sleepy Server Caching Proxy maxAge = 60sec 1c - Sleepy Server Sleep Aware Proxy maxAge = 60sec
Sleep Aware Proxy has better performance for sleepy servers
0
100
200
300
400
500
600
700
1a 1b 1c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
GET ndash Scenario 1 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
Scenarios 1a - Non-Sleepy Server Caching Proxy maxAge = 60sec 1b- Sleepy Server Caching Proxy maxAge = 60sec 1c - Sleepy Server Sleep Aware Proxy maxAge = 60sec
0
100
200
300
400
500
600
700
800
1a 1b 1c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
ldquoGETrdquo ndash Test Scenario 2 Results
maxAge = 60 and 5 Clients
GET ndash Scenario 2 ClientProxy Interface Transaction Mix
Sleep Aware Proxy has slightly better performance for sleepy servers
0
200
400
600
800
1000
1200
1400
2a 2b 2c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
Scenarios 2a - Non-Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2b- Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2c - Sleepy Server Sleep Aware Proxy maxAge = 60sec 5 Clients
See ldquoExperimental Artifactsrdquo Note 1
GET ndash Scenario 2 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has slightly better performance for sleepy servers
0
50
100
150
200
250
300
350
400
2a 2b 2c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
Scenarios 2a - Non-Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2b- Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2c - Sleepy Server Sleep Aware Proxy maxAge = 60sec 5 Clients
See ldquoExperimental Artifactsrdquo Note 2
Experimental Artifacts Note 1
Currently in the experiment the sleep aware proxy checks the cached state of a resource before putting a request into its Store-and-forward queue while a server is sleeping Once in the queue the proxy unconditionally forwards the queued requests to the server once it wakes up This is not the most efficient setup and can easily be improved If the proxy instead checks its cache again before forwarding each queued request it may not need to forward the request to the server For example if there are two queued GET requests in the proxyrsquos queue that address the same resource Only the first request needs to be sent to the server the second request can use the cached response from the first request
Note 2 Currently in the experiment the sleepy server sends a sleepState PUT request to the
proxy each time it goes to sleep This is not the most efficient setup and can easily be improved For example if the server assumes that the proxy can keep track of its ONOFF cycles with its internal timers (eg as per Fig 1 of I-D) then the number of messages from the sleepy server dramatically goes down
ldquoGETrdquo ndash Test Scenario 3 Results
maxAge = 5 and 5 Clients
GET ndash Scenario 3 ClientProxy Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
Scenarios 3a - Non-Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3b- Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3c - Sleepy Server Sleep Aware Proxy maxAge = 5sec 5 Clients
0
500
1000
1500
2000
2500
3000
3500
4000
4500
5000
3a 3b 3c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
GET ndash Scenario 3 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
0
1000
2000
3000
4000
5000
6000
7000
3a 3b 3c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
Scenarios 3a - Non-Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3b- Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3c - Sleepy Server Sleep Aware Proxy maxAge = 5sec 5 Clients
Conclusions
Conclusions These results show that sleep-aware CoAP
proxy features can significantly optimize communication with sleepy servers in most scenarios
These results also show that sleep-
awareness capabilities can provide additional benefits above and beyond CoAP caching in most scenarios
Backup
Current CoAP Support of Sleepy Node (12)
CoAP proxies can use a previously cached response to service a new GET request for a sleepy origin server (as in HTTP) But if no valid cache then proxy has to attempt to
retrieve and may fail if origin server is sleeping [I-Dietf-core-coap]
Clients can discover list of resources from RD (GET rd-lookuphellip) for sleepy servers But attempt to GET resource from sleepy origin server
may fail if origin server is sleeping [IDietf-core-link-format amp IDshelby-core-resource-
directory]
Current CoAP Support of Sleepy Node (22)
Lower layer support for sleepy nodes in most wireless technologies (eg WiFi ZigBee) But limited to MAC packet scheduling for sleepy nodes
and not aware of specific needs of IP applications (like CoAP)
Proposal ndash RD Based Sleep Tracking (14)
The current CoAP approach to support sleepy nodes can be significantly improved by introducing RD based mechanisms for a CoAP client to determine whether A targeted resource is located on a sleepy server A sleepy server is currently in sleep mode or not
There is any associated caching Proxy (possibly the RD itself) for a sleepy server
Proposal ndash RD Based Sleep Tracking (24)
We define the following new RD attributes to characterize the properties of a sleepy node SleepState - Indicates whether the node is currently in
sleep mode or not (ie Sleeping or Awake) SleepDuration - Indicates the maximum duration of time
that the node stays in sleep mode TimeSleeping - Indicates the length of time the node
has been sleeping (ie if Sleep State = Sleeping) NextSleep - Indicates the next time the node will go to
sleep (ie if Sleep State = Awake)
CachingProxy ndash Indicates the caching proxy of the sleepy node (ie the RD itself or another node)
Proposal ndash RD Based Sleep Tracking (34)
These attributes are all server (node) level and are new parameters added to the RD URI Template Variables
Finally we also define a new lookup-type (ss) for the RD lookup interface specified in [I-Dshelby-core-resource-directory] This new lookup-type supports looking up the
ldquoSleepStaterdquo (ss) of a specified end-point
Proposal ndash RD Based Sleep Tracking (44)
The three time based parameters (SleepDuration TimeSleeping NextSleep) can be based on either an absolute network time (for a time synchronized network) or a relative local time (measured at the local node)
Following the approach of [I-Dietf-core-link-format] and [I-Dshelby-core-resource-directory] sleep parameters for sleepy servers can be stored by the server in the RD and accessed by all interested clients
Examples of using these parameters in a synchronous or asynchronous manner are shown in the I-D
http6lowappnet coreIETF86 2013-03-12-13
We assume people have read the drafts
Meetings serve to advance difficult issues by making good use of face-to-face communications
Note Well Be aware of the IPR principles according to RFC 3979 and its updates
uumlBlue sheetsuumlScribe(s)
96
drar-shy‐iep-shy‐core-shy‐coapsubmiqed13 to13 IESG
2013-shy‐03-shy‐13
97
OMA Lightweight M2M Overview(A new standard using lots of IETF specs including DTLS
CoAP Block Observe Resource Directory SenMLhellip)
Zach ShelbyCoRE WG IETF-86 Orlando
OMA Lightweight M2Mbull Open Mobile Alliance is well known for Device Management (DM)bull OMA Lightweight M2M is a new standard from the alliance
ndash Focused on constrained Cellular and sensor network M2M devicesndash Driven by leading operators and vendors
bull Scopendash Interfaces protocol amp security between Device and Serverndash Object and Resource modelndash Bootstrap Device Access Control Connectivity and Firmware Objects
bull Draft Specifications are availablendash httpmemberopenmobileallianceorgftpPublic_documentsDM
LightweightM2MPermanent_documentsOMA-TS-LightweightM2M-V1_0_0-20130301-Dzip
bull Timelinendash Requirements and Architecture completed 3Q2012ndash Spec ready for Consistency Review 2Q2013ndash Candidate Approval expected 3Q2013
2 CoRE WG IETF-86 Orlando
Architecture
3
Scope of LWM2M
CoRE WG IETF-86 Orlando
Object Model
bull A Client has one or more Object Instancesbull An Object is a collection of Resourcesbull A Resource is an atomic piece of information
ndash Read Written or Executed
bull Resources can have multiple instancesbull Objects and Resources are identified by a
16-bit Integer Instances by an 8-bit Integerbull ObjectsResources are accessed with
simple URIs Object IDObject InstanceResource ID
eg 1213
4 CoRE WG IETF-86 Orlando
CoRE WG IETF-86 Orlando
CoRE Resource Directory
draft-shelby-core-resource-directory-05
Z Shelby C Bormann S Krco
Backgroundbull Not a new concept
ndash think web search engine or any link directorybull Defines the interfaces to a Resource Directorybull Based on Web Linking framework and the CoRE Link Formatbull Generic REST design for use over HTTP and CoAPbull Used by OMA Lightweight M2Mbull Has already been deployed
ndash In traffic monitoring systemsndash In street lighting systemsndash For vehicular asset trackingndash By a major Cellular M2M operator
Changes since -04
bull Restricted Update to parameter updatesbull Added pagination support for the Lookup interfacebull Changed rt= to et= for the registration amp update
interfacebull Added group support
Group Management
bull RD now includes group management featuresbull New Group Function Set
ndash Register a groupbull Group name domain multicast address endpoint members
ndash Remove a groupbull Group lookup using the Lookup Function Set
ndash List registered groupsndash Find the members of a groupndash Find groups with certain endpoints or resources
Registering a Group
EP RD
| |
| - POST rd-groupgp=lights ltgtep=node1 --gt |
| |
| |
| lt---- 201 Created Location rd-group12 ---- |
| |
Req POST coaprdexamplecomrd-groupgp=lights
Payload
ltgtep=node1
ltgtep=node2
Res 201 Created
Location rd-group12
Looking up Group Members
Client RD
| |
| ----- GET rd-lookupepgp=lights1 ----------------------gt |
| |
| |
| lt-- 205 Content ltrdgtd=domain1ltrdgtd=domain2 --------- |
| |
Req GET rd-lookupepgp=lights1
Res 205 Content
ltcoaphostportgtep=node1
ltcoaphostportgtep=node2rdquo
Things for the futurebull Support for JSON representation of Web Links
ndash httptoolsietforgiddraft-bormann-core-links-json-02txtbull Registry for RD registration query parameters
ndash Already OMA Lightweight has defined some new onesbull More examples
Group 3 ldquonew workrdquo(continued)
109
drar-shy‐greevenbosch-shy‐core-shy‐profile-shy‐descripon-shy‐01Bert13 GreevenboschJeroen13 Hoebeke
Isam13 IshaqFloris13 Van13 den13 Abeele
Descripon
bull JSON13 format13 for13 signalling13 the13 servers13 capabilies
bull Signalling13 of13 supported13 opons13 media13 types13 and13 block13 sizendash Other13 items13 can13 be13 added
bull Filtering13 on13 specific13 fields13 through13 URI-shy‐Querybull Link13 hqpdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐profile-shy‐descripon
well-shy‐knownprofile
bull To13 acquire13 profile13 data13 of13 resources13 on13 a13 parcular13 service13 the13 well-shy‐knownprofile13 URI-shy‐path13 is13 introduced
bull For13 example13 to13 get13 all13 informaon13 from13 sensors13 served13 by13 wwwexampleorg13 we13 can13 do13 a13 GET13 to13 coapwwwexampleorgwell-shy‐knownprofile
bull Filtering13 on13 parcular13 resources13 is13 done13 through13 URI-shy‐Queries
Format
bull Currently13 the13 following13 fields13 are13 definedndash ldquopathrdquo13 contains13 the13 URI-shy‐path13 associated13 with13 a13 resource
ndash ldquooprdquo13 a13 numerical13 list13 of13 supported13 opon13 numbers
ndash ldquocfrdquo13 a13 numerical13 list13 of13 supported13 content-shy‐format13 numbers
ndash ldquob1srdquo13 ldquob2srdquo13 supported13 block13 sizes13 for13 Block113 and13 Block213 respecvely
Examplebull On13 the13 right13 is13 an13 example13 of13 a13 camera13 sensor13 at13 coapwwwexampleorgcam13 that13 supports13 the13 Uri-shy‐Host13 (3)13 ETag13 (4)13 Uri-shy‐Port13 (7)13 Uri-shy‐Path13 (11)13 Content-shy‐Format13 (12)13 Token13 (19)13 Block213 (23)13 and13 Proxy-shy‐Uri13 (35)13 opons
bull The13 supported13 content13 formats13 are13 textplain13 (0)13 applicaon13 link-shy‐format13 (40)13 and13 applicaonjson13 (50)
bull The13 supported13 Block213 can13 use13 25613 or13 51213 byte13 blocks
Req13 GET13 coapwwwexampleorgwell-shy‐knownprofile13 Res13 20513 Content13 (applicationjson)13 13 13 13 profile13 13 13 13 13 13 13 13 pathcam13 13 13 13 op[3471112192335]13 13 13 13 13 cf[04050]13 13 13 13 13 b2s[45]13 13 13 13
Filtering13 through13 use13 of13 URI-shy‐Query
bull Filtering13 can13 be13 done13 through13 the13 URI-shy‐Querybull Query13 format13 N=V
ndash N13 is13 a13 profile13 fieldndash V13 is13 the13 desired13 value
bull Examplesndash To13 find13 resources13 that13 support13 content13 format13 ldquoapplicaonjsonrdquo
13 GET13 wwwexampleorgwell-shy‐knownprofilecf=50ndash To13 get13 informaon13 about13 the13 camera
13 GET13 wwwexampleorgwell-shy‐knownprofilepath=cam
Open13 issues
bull Which13 other13 profile13 data13 needs13 signallingndash Content-shy‐type13 for13 different13 methods
bull Fix13 the13 order13 in13 which13 the13 profile13 fields13 must13 appearndash Non-shy‐fixed13 order13 easier13 extensible
bull Inheritance13 of13 a13 profile13 descriponbull Extend13 usage13 to13 signal13 the13 client13 profilebull Integraon13 with13 link13 format
Thank13 youQuesons
drar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval-shy‐00
Bert13 Greevenbosch
Descripon
bull The13 ldquoMinimumRequestInterval13 opon13 can13 be13 used13 to13 indicate13 the13 minimum13 me13 between13 two13 requests13 in13 a13 transacon
bull Originally13 intended13 for13 Block13 but13 also13 usable13 for13 other13 transaconsndash Example13 browsing13 a13 server
bull The13 goal13 is13 to13 reduce13 the13 server13 load13 and13 network13 traffic
bull Link13 hqpsdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval
Usage
bull The13 client13 keeps13 the13 server13 informed13 about13 its13 request13 speed13 through13 inclusion13 of13 the13 ldquoMinimumRequestIntervalrdquo13 opon
bull In13 responses13 the13 server13 fixes13 the13 minimum13 request13 interval13 through13 the13 same13 opon
bull The13 client13 obeys13 the13 speed13 indicated13 by13 the13 server
bull The13 client13 can13 send13 slower13 but13 not13 faster
Advantages
bull The13 server13 has13 means13 to13 limit13 the13 amount13 of13 incoming13 traffic
bull The13 server13 can13 prevent13 to13 become13 overloaded13 with13 too13 many13 tasks
bull The13 server13 does13 not13 need13 arficially13 slow13 down13 the13 client13 by13 sending13 late13 ACKsndash No13 need13 to13 keep13 track13 of13 delayed13 ACKsndash The13 server13 can13 perform13 other13 tasks13 instead
bull Reduced13 network13 traffic
Thank13 youQuesons
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-links-json-02txt
123
RFC 6690 (link-format) documents are somewhat foreign to many web app developerssect would prefer to have them in JSON format
There is no standard way to represent link-format documents in applicationssect but everyone knows how to handle JSON
Define a standard JSON translation for link-format
Itrsquos
not
rock
et
scien
ce
ltsensorsgtct=40title=Sensor Index ltsensorstempgtrt=temperature-cif=sensor ltsensorslightgtrt=light-luxif=sensor lthttpwwwexamplecomsensorst123gt anchor=sensorstemprel=describedby lttgtanchor=sensorstemprel=alternate [hrefsensorsct40titleSensor Index hrefsensorstemprttemperature-cifsensor hrefsensorslightrtlight-luxifsensor hrefhttpwwwexamplecomsensorst123 anchorsensorstempreldescribedby hreftanchorsensorstemprelalternate]
124
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-ipsec-for-coap-00txt
IPsec definitions for CoAP Mostly placeholder at this time Who has implementation experience with this
125
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-cross-reverse-convention-00txt
This draft has two lines of payload(based on a WGLC comment by Cullen Jennings)
coap12344567foobara=3
httpwwwproxycomwellknowncore-translate1234_4567foobara=3
Is that a useful convention to have
126
Insert CI slides here
127
128
0
5
10
15
20
25
30
35
40
10 20 30 40 50 60 70
good
put (
pps)
pps
Goodput vs pps (Econotags)
goodput
[Khattak preliminary]
Congestion Control
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-cocoa-00txt
ldquoadvancedrdquo cc (The draft is just a first shot) Others may have better ideas
129
Insert post-WGLC discussion slides here
130
Stop Continue Start
131
An Agile Retrospective
http6lowappnet coreIETF86 2013-03-12-13
Stop
132
Endless new CoAP optionssect instead use RESTful as much as possible
Move general security lifecycle out Looking at theoretical problems
http6lowappnet coreIETF86 2013-03-12-13
Continue
Interops Running code Look at real-world examples and deployments Solve their actual problems
sect Unilateral enhancements eg higher performance congestion control
sect Transports (SMS hellip)sect Make Web linking and Directories more and more usefulsect RESTful Design Paradigms for real-world problems
133
http6lowappnet coreIETF86 2013-03-12-13
Start
Further push into the (browser) web world (HTML5 browser security)
Specific supporting worksect SenMLsect URI work (dev URN hellip)sect Security Processes (next slide)
Spin outsect (We donrsquot really get to decide where this is done)
134
http6lowappnet coreIETF86 2013-03-12-13
Security
Integrate Application Network Group Keyingsect Tunnel-free setup
Donrsquot redo what has been done alreadysect ZigBee IP is finesect But what about other scenarios
Simple REST interfaces for working with keying materials and authorizationsect Start with defining objectives
Object Security for Constrained Nodes135
Re-chartering CoREWhat do we want to do now that wersquore grown up
Zach ShelbyCoRE WG IETF-86 Orlando
What is the scope
bull So we have a protocol and Web Linking what next
bull Keep with what we know besthellip1 Enhancements around CoAP2 New transports for CoAP3 New representations for Web Links4 General application layer solutions
CoRE WG IETF-86 Orlando 2
Enhancements around CoAP
bull Advanced congestion control
CoRE WG IETF-86 Orlando 3
New Transports for CoAP
bull Infrastructure for CoAP over foondash httptoolsietforgiddraft-silverajan-core-
coap-alternative-transports-01txtbull CoAP over SMS
ndash httptoolsietforgiddraft-becker-core-coap-sms-gprs-03txt
ndash OMA Lightweightbull CoAP over TCP
ndash httptoolsietforgiddraft-li-core-coap-payload-length-option-01txt
CoRE WG IETF-86 Orlando 4
New support for Web Links
bull JSON Web Linksndash httptoolsietforgiddraft-bormann-core-links-
json-02txt
2332010 CoRE WG IETF-77 Anaheim 5
General application layer solutions
bull Resource Directoryndash httptoolsietforgiddraft-shelby-core-
resource-directory-05txtndash OMA Lightweight
2332010 CoRE WG IETF-77 Anaheim 6
Summary of Changes (14)
n I-D had two updates (Rev 04 amp 05) after IETF-85 (Atlanta) Many of the updates were due to the detailed review by Peter van der Stokn Thank you Peter for your valuable comments
n Changes from ietf-03 to ietf-04 n Section 23 (Potential Solutions for Group Communications) moved to
draft-dijk-core-groupcomm-misc (266)n Added reference to draft-keoh-tls-multicast-security to section 6 (Security
Considerations) n Appendix B (CoAP-Observe Alternative to Group Communications) moved
to draft-dijk-core-groupcomm-misc (267) n Deleted section 8 (Conclusions) as it is redundant (268) n Simplified light switch use case (269) by splitting into basic operations and
additional functions (269)
Summary of Changes (24)
n Changes from ietf-03 to ietf-04 (Continued) n Moved section 37 (CoAP Multicast and HTTP Unicast Interworking) to
draft-dijk-core-groupcomm-misc (270) n Moved section 331 (DNS-SD) and 332 (CoRE Resource Directory) to
draft-dijk-core-groupcomm-miscClarified that DNS based features are optional (272)
n Focus section 35 (Configuring Group Membership) on a single proposed solution
n Scope of section 53 (Use of MLD) widened to multicast destination advertisement methods in general
n Rewrote section 22 (Scope) for improved readibility n Moved use cases that are not adressed to draft-dijk-core-groupcomm-miscn Various editorial updates for improved readibility
Summary of Changes (34)
n Changes from ietf-04 to ietf-05 n Added a new section 39 (Exceptions) that highlights that IP multicast (and
hence group communications) is not always available (187) n Included guidelines on when (not) to use CoAP responses to multicast
requests and when (not) to accept multicast requests (273) n Added guideline on use of core-block for minimizing response size (275)n Restructured section 6 (Security Considerations) to more fully describe
threats and threat mitigation (277) n Clearly indicated that DNS resolution and reverse DNS lookup are optional n Removed confusing text about a single group having multiple IP addresses
If multiple IP addresses are required then multiple groups (with the same members) should be created
n Removed repetitive text about the fact that group communications is not guaranteed
Summary of Changes (44)
n Changes from ietf-04 to ietf-05 (Continued) n Merged previous section 52 (Multicast Routing) into 31 (IP Multicast
Routing Background) and added link to section 52 (Advertising Membership of Multicast Groups)
n Clarified text in section 38 (Congestion Control) regarding precedence of use of IP multicast domains (ie first try to use link-local scope then site-local scope and only use global IP Communication for CoAP multicast as a last resort)
n Extended group resource manipulation guidelines with use of preconfigured portspaths for the multicast group
n Consolidated all text relating to ports in a new section 33 (Port Configuration)
n Clarified that all methods (GETPUTPOST) for configuring group membership in endpoints should be unicast (and not multicast) in section 37 (Configuring Group Membership In Endpoints)
n Various editorial updates for improved readability
Discussion item (11)
n Solution for Configuring Group Membership (no ticket)n Example of (unicast) configuring an endpoint to be part of one multicast
groupReq POST gp (Content-Format applicationjson)
n floor1westbldg6examplecom ip ff154200f7feed3714cb Res 204 Changed
n Where the ldquogprdquo resource has resource type (rt) ldquocoregprdquo which is defined for this purpose
n Question Do we want specify such a solution (or for example leave it completely up to implementation)
Open Issues(15)
n Review Groupcomm requirements language (271)n Decision made to keep requirements language for informational draftn Each use of MAYMUSTSHOULD etc is to be reviewed
Open Issues(25)
n Add section on multicast via Proxy and its limitations (274)n Add a section to explain the issues amp limitations of doing CoAP multicast
requests via a CoAP Proxy n Goal is to warn and guide implementers in this subject n Also such a section would provide a placeholderreminder of the problems
that might be addressed further in the futuren Based on IETF 85 CoRE WG meeting discussion on Multicast CoAP
requests via a Proxy Discussion summary for referencen Aggregation of responses in a proxy is difficult since it doesnt know
when to stop aggregating responses n SIP tried to deal with this problem but didnt solve it n There may be an expectancy of CoAP client to get single response
back from proxy not multiple The client in this case may not even know what it could expect It may not even know the Proxy-URI contains a multicast target
n Presented via-proxy use case exposes gap in the core-coap specification regarding multicast via proxy (Note Expectation is that core-coap wonrsquot address it in the first planned RFC release)
Open Issues(35)
n Issues with twomultiple Resource Directories in use case (280)n Some potential issues with RD came out of review Peter van der Stok and
WG discussion IETF85 n There are two RD servers use case shows that only one is found despite
the fact that site-local multicast is used - should be two RDs found n Proposal simplify use case to a single RD server on the backbone to avoid
such RD-specific issues like synchronization of RD information between servers
Open Issues(45)
n Add single-subnet configuration to use cases (278)n Suggested by review Peter van der Stok and IETF85 WG discussion that
its best to start explaining the simplebasic cases and then gradually build up complexity
n Simplest case not shown yet would be a single subnet network configuration which is currently not present in the I-D only the 2-subnet configuration of Fig 1
n Question Do we need to add such case or doesnt it add muchn (Note that core-coap Figure 22 already shows the simplest case of link-local
multicast)
Open Issues(55)
n Add use case with controller (client) located on the backbone (279)n Suggested by discussion following review Peter van der Stok n Case missing where a controller (client) is located on the backbonen Question Do we need to add such case or does it add much
Group 2a other old friends
25
Angelo Castellani Salvatore Loreto Akbar Rahman Thomas Fossati Esko Dijk
IETF 86 March 2013httpwwwietforgiddraft-castellani-core-http-mapping-07txt
Best Practices for HTTP-CoAP Mapping
Implementation
Summary of Changes (from -06 rev)
n Based on discussion at last IETF-85 (Atlanta)n Clarification of HTTP-CoAP Proxies
n Definitionn Placementn Benefits
n Clarification of HTTP-CoAP URI mapping options
Goals of I-D
n For Reverse HTTP-CoAP Cross Protocol Proxyn Provide more detailed information to proxy designers (beyond
Section 10 of [I-Dietf-core-coap]) to help implement proxies that correctly inter-work with other CoAP and HTTP clientserver implementations that adhere to the specifications
n Define a consistent set of guidelines that a HTTP-to-CoAP proxy implementation MAY adhere to The main reason of adhering to such guidelines is to reduce variation between proxy implementations thereby increasing interoperabilityn As an example use case a proxy conforming to these guidelines made
by vendor A can be easily replaced by a proxy from vendor B that also conforms to the guidelines
I-D Outline
n Guidance on HTTP to CoAP URI mappingn HTTP-CoAP Reverse cross-protocol proxy implementation
n Placementn Response code amp media type translationsn Caching and congestion controln Cache refresh via Observen Use of CoAP blockwise transfern Security translation
n Security Considerationsn Traffic overflown Handling secured exchanges
Definitions (12)
n Cross-Protocol Proxy (or Cross Proxy) is a proxy performing a cross- protocol mapping in the context of this document a HTTP-CoAP (HC) mapping A Cross-Protocol Proxy can behave as a Forward Proxy Reverse Proxy or Interception Proxy n Note In this document we focus on the Reverse Proxy mode of the
Cross-Protocol Proxy
n Forward Proxy a message forwarding agent that is selected by the client usually via local configuration rules to receive requests for some type(s) of absolute URI and to attempt to satisfy those requests via translation to the protocol indicated by the absolute URI The user decides (is willing to) use the proxy as the forwardingdereferencing agent for a predefined subset of the URI space
Definitions (22)
n Reverse Proxy a receiving agent that acts as a layer above some other server(s) and translates the received requests to the underlying servers protocol It behaves as an origin (HTTP) server on its connection towards the (HTTP) client and as a (CoAP) client on its connection towards the (CoAP) origin server The (HTTP) client uses the origin-form [I-Dietf-httpbis-p1-messaging] as a request- target URI
n Reverse and Forward proxies are technically very similar with main differences being that the former appears to a client as an origin server while the latter does not and that clients may be unaware they are communicating with a proxy
Reverse Cross-Protocol Proxy Deployment Scenario
HTTP-CoAP Response Code Mapping
Implementation Experience
n Direct experience from the draft authorsn Squid HTTP-CoAP mapping module
n University of Padovan httptelecomdeiunipditiotn Both Forward and Interception operation supported
n HTTP-CoAP proxy based on EvCoAPn KoanLogic University of Bologna and Salvatore
Loreto (as individual)n httpsgithubcomkoanlogicwebthingstreemasterbridgesw
libevcoapn The document is open to input from other implementations
Next Steps
n Does the WG recommend adoptionn Intended status Informational Best Practicen Purpose Reduce arbitrary variation between proxy
implementations thereby increasing interoperability
Backup
HTTP to CoAP URI Mapping Options (12)
n Embedded Mapping n In an embedded mapping approach the HTTP URI has embedded
inside it the authority and path part of the CoAP URI n Example The CoAP resource nodecoapsomethingnetfoo can
be accessed by an HTTP client by inserting in the request httphc-proxysomethingnetcoapnodecoapsomethingnetfoo The Cross-Protocol Proxy then maps the URI to coapnodecoapsomethingnetfoo
HTTP to CoAP URI Mapping Options (22)
n Homogeneous Mapping n In a homogeneous mapping approach only the scheme portion of the URI
needs to be mapped The rest of the URI (ie authority path etc) remains unchanged
n Example The CoAP resource coapnodecoapsomethingnetfoo can be accessed by an HTTP client by requesting httpnodecoapsomethingnetfoo The Cross-Protocol Proxy receiving the request is responsible to map the URI to coapnodecoapsomethingnetfoo
n Background info n The assumption in this case is that the HTTP client would be able to
successfully resolve nodecoapsomethingnet using DNS infrastructure to return the IP address of the HC proxy Most likely this would be through a two step DNS lookup where the first DNS lookup would resolve somethingnet using public DNS infrastructure
n Then the second DNS lookup on the subdomain coap and the host node would typically be resolved by a DNS server operated by the owner of domain somethingnet So this domain owner can manage its own internal node names and subdomain allocation which would correspond to the CoAP namespace
Group 3 ldquonew workrdquo
39
Transport of CoAP over SMS USSD and GPRSdraft-becker-core-coap-sms-gprs-03
Markus Becker Kepeng LiKoojana Kuladinithi Thomas Poumltsch
CoRE WG IETF-86 Orlando
1 10
ScenariosI In M2M communication IP connectivity is not alwayssupported by the constrained end-points
I Power savingI Coverage (GPRS 3G LTE)
I SMS and USSD based communication is almost alwayssupported
210
Changes from draft-01 to draft-03 (1)
I Added possible CONNONACK interactions Section 5
I Option name changed from Reply-To- to Response-To-Section 16 and Section 101
I Added URI schemeEg coap+tel+15105550101well-knowncore Section 11
I Added possible M2M proxy scenarios Section 14
3 10
Changes from draft-01 to draft-03 (2)
I Added reference to bormann-coap-misc for other SMSencoding Section 71
I Updated requirements on Uri-Host and Uri-Port forcoap+tel Section 10
I Added security considerations Transport and ObjectSecurity Section 15
I Chose CoAP option numbers and updated the optionnumber table to meet draft-ietf-core-coap-10 Table 1
I Added an IANA registration for the URI scheme coap+telSection 162
4 10
Feedback Split coap+tel into coap+smsand coap+ussd
I How else to differ the various transports in the URII Or is the transport to use decided by the implementationI See alsodraft-silverajan-core-coap-alternative-transports-01
5 10
Feedback Response-To-Scheme option
I Should there be a Response-To-Scheme optionadditionally to Response-To-Uri-Host andResponse-To-Uri-Path
I So that a CoAP end-point which receives a request by CoAPover non-IP transport can be instructed to also use thenon-IP transport for the response
I This would imply to add aResponse-To-Telephone-Subscriber and more options forother transports that have other URI schemes than coapand coaps
6 10
Feedback Selection of Transport by Client
I When a server is reachable by various transports howdoes a client decide which transport to use
I Client-side application congurationI Leave it to a proxy which uses cellular network lookupfunctions
7 10
Feedback Potential Threats
I Trigger expensive short messagesI Redirect trac to other addressesI More threats
I Are the security measures in the draft adequateI Whitelisting on serverI Relying on cellular network security (dedicated M2M APNs)I Object security on CoAP payload
8 10
Feedback Message Exchanges
I Figures 11-18 show possible message exchanges whenclient and server have two addresses
I With NON Not using CoAP retransmission capabilityI ACK on different transportI Additional (costly) message on Transport AI Request with Content
I Which ones are allowedI Which ones are meaningful
9 10
Next steps
I Rene Uri schemeI Response-To-Scheme optionI Selection of Message ExchangeI Rene Proxying
10 10
CoAP13 Communicaon13 with13 Alternave13 Transports
Bill Silverajan and Teemu SavolainenCore WG IETF 86 Orlando
031113
Objecves13 (In13 Scope)
bull Unambiguous13 representaon13 of13 transport13 to13 be13 used13 by13 CoAP
bull Details13 how13 the13 transport13 can13 carry13 CoAP13 packet
bull Focus13 is13 on13 what13 CoAP13 communicaons13 requirements13 are
bull Allow13 CoAP13 mechanisms13 to13 exploit13 cross-shy‐layer13 opmisaons
51
031113
Non13 Goals13 (Not13 in13 scope)
bull Applicaon-shy‐level13 QoS13 requirementsbull Real-shy‐me13 constraintsbull Ordering13 reliability13 congeson13 controlbull Applicaon13 and13 network13 adaptaonbull Mobility13 and13 readdressing13 supportbull Network13 protocol13 (eg13 IPsec)13 configuraon
52
031113
Use13 Cases
bull NAT13 and13 Firewall13 traversal13 with13 TCPbull Delay13 Tolerant13 Networkingbull Non-shy‐IP13 Low13 Energy13 Protocols
53
031113
Related13 Work
bull OMA13 Lightweight13 M2M13 Protocolbull CoAP13 over13 SMSGPRSUSSD
54
031113
What13 does13 the13 work13 entail
bull The13 ability13 to13 specify13 end13 point13 idenfiers13 and13 URIs13 to13 reflect13 which13 transport13 CoAP13 can13 use
bull The13 ability13 to13 register13 to13 resource13 directories13 resource13 types13 reflecng13 types13 of13 transport13 available
bull Ability13 for13 mul-shy‐transport13 nodes13 to13 select13 transport13 to13 use13 without13 significant13 alteraon13 to13 CoAP13 packet13 structure
55
031113
Points13 to13 consider
bull Requirements13 for13 transport13 layer13 protocol13 to13 carry13 CoAP13 packets
bull Representaon13 of13 URI13 scheme13 for13 generic13 transport13 protocols
bull Opon13 extensions13 for13 CoAP13 to13 express13 available13 transports
bull Mapping13 and13 message13 sizebull Security13 consideraons
56
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
URI13 =13 scheme13 13 13 authority13 path-shy‐abempty13 [13 query13 ]
bull Within13 the13 scheme13 namebull In13 the13 URI13 pathbull As13 a13 query13 component
57
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
bull Within13 the13 scheme13 namendash coap+tel+15105550101well-shy‐knowncorendash coap+tcpexamplecom5683temperaturendash coap+blel2cap[1234567890AB]4pulse
bull Easy13 URI13 parsing13 for13 transport13 type13 and13 idenfier
bull Each13 new13 scheme13 name13 requires13 IANA13 registraon
58
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
bull In13 the13 URI13 pathndash coaphostexamplecomtransport=tcpwell-shy‐knowncorert=core-shy‐rd
bull Easy13 adopon13 of13 new13 (and13 experimental)13 CoAP13 transports13 without13 IANA13 registraon
bull Caveat13 Uri-shy‐Path13 opon13 is13 a13 Crical13 CoAP13 opon13 see13 secon13 54113 of13 I-shy‐Diep-shy‐core-shy‐coap
59
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
bull As13 a13 URI13 query13 componentndash coaphostexamplecomwell-shy‐knowncorert=core-shy‐rdq=tcp
bull Also13 easy13 to13 adopt13 new13 (and13 experimental)13 CoAP13 transports13 without13 IANA13 registraon
bull Caveat13 Uri-shy‐Query13 opon13 is13 a13 Crical13 CoAP13 opon13 see13 secon13 54113 of13 I-shy‐Diep-shy‐core-shy‐coap
60
031113
URI13 Representaons13 for13 CoAPNon13 standard13 ways
bull Transport13 in13 the13 URI13 authority13 componentndash coaphost[port][transport]13 instead13 of13 coaphost[port]
bull Transport13 as13 a13 service13 URLndash servicecoaptcphostexamplecomwell-shy‐knowncorert=core-shy‐rd
bull Above13 two13 ways13 break13 exisng13 compability13 (although13 both13 are13 based13 on13 valid13 IANA13 URI13 registraons)
61
031113
URI13 Representaons13 for13 CoAPMiscellaneous13 Consideraons
bull Ensure13 that13 transport13 is13 defined13 unambiguously13 (eg13 L2CAP13 used13 by13 both13 BLE13 and13 standard13 Bluetooth13 so13 avoid13 rdquocoap+l2caprdquo13 or13 rdquotransport=l2caprdquo13 or13 rdquoq=l2caprdquondash Can13 be13 done13 as13 WG13 consensusndash Namespace13 approach13 eg13 rdquocoap+blel2caprdquo13 or13 rdquoq=blel2caprdquo
bull Allow13 end-shy‐points13 to13 use13 CoAP13 Resource13 Directory13 to13 register13 alternave13 transports13 and13 idenfiers13 and13 provide13 periodic13 updatesndash Register13 rdquocore-shy‐transportrdquo13 resource13 type
62
031113
Transport13 Consideraons
bull Uniqueness13 of13 end-shy‐point13 idenficaonbull Communicaon13 support13 Unidireconal13 Bidireconal13 1N13 (broadcast13 mulcast13 anycast)13 messaging
bull Binary13 encoding13 Network13 byte13 orderingbull MTU13 correlaon13 with13 CoAP13 PDU13 sizebull Transport13 latency
63
031113
Security13 Consideraons
bull Drar13 does13 not13 introduce13 new13 security13 requirements13 by13 itself
bull There13 may13 be13 privacy13 issues13 if13 nodes13 use13 telephone13 numbers13 or13 MAC13 addresses13 as13 public13 end13 point13 idenfiers
64
Akbar Rahman
IETF 86 March 2013 httpwwwietforgiddraft-rahman-core-sleepy-02txt
Enhanced Sleepy Node Support for CoAP
Introduction
It is expected that in CoAP networks there will be a certain portion of devices that are sleepy and which may occasionally go into a sleep mode (ie go into a low power state to conserve power) and subsequently have reduced CoAP protocol communication ability
This I-D proposes a minimal and efficient mechanism building on the Resource Directory concept (which will be integrated into a CoAP Proxy) to enhance sleepy node support in CoAP networks
Main Question from IETF-85 (Atlanta)
What performance benefit does the proposed Sleepy Node support solution give in a network that already has standard CoAP caching enabled
Sleepy Node Performance Analysis
Experimental Network
1-5 clients
Both Sleepy and Non-
Sleepy servers
Sleepy Node Performance Analysis Network Setup
CoAPSleepyServer(s)
CoAPSleepAwareReverseProxy
CoAP
Client(s)
Request
Response
Sleep9AwareCoREResourceDirectoryCapability
PublishedSleepParameters
Sleep9AwareCoAPStoreandForwardCapability Response
Request
SleepAwareCoAP503ResponseCapability
CoAPCachingCapability
bull Server supports publishing sleep parameters to proxy bull Eg Irsquom going to be asleep for X seconds
bull Proxy supports sleep-awareness capabilities bull Proxy also supports caching capability based off of maxAge bull Protocol flow similar to approach of Figure 1 (Synchronous RD Based Sleep
Tracking) of I-D
Proxy capabilities can be selectively enableddisabled
Proxy ndash Server Interface
Client ndash Proxy Interface
CoAP Sleep-Aware Reverse Proxy Features CoRE Sleep-aware Resource Directory
Support storing published sleep parameters from CoAP servers sleepState (AWAKE ASLEEP) sleepDuration
Sleep-aware CoAP 503 Response Capability If CoAP request to a sleeping server is received proxy returns a
lsquo503 Retry-Afterrsquo response to client 503 contains a timestamp indicating when the sever will wake back up
(timestamp delivered in CoAP maxAge option) Sleep-aware CoAP Store-and-Forward Capability
If CoAP request to a sleeping server is received proxy stores request until server wakes up and then forwards it
Caching capability Cache GET responses from server if maxAge option is present
(this is not a sleep aware feature)
Goals of Performance Analysis
For networks having sleepy servers provide measurements to quantify the impact that CoAP sleep-awareness capabilities can have
See if sleep-awareness capabilities can
provide additional benefits even when CoAP caching is used
Overview of Performance Analysis Performed The analysis was broken up into a set of test scenarios Each test scenario used a different combination of the following
variables Client issued GET requests Server was configured as a sleepy or non-sleepy server Proxy caching of GET responses was enabled or disabled Proxy sleep-aware 503 response capability was enabled or disabled Proxy store-and-forward capability was enabled or disabled maxAge in GET responses ndash Two values were tested 60sec and 5sec of Clients ndash Two values were used ndash 1 client and 5 clients
For comparison purposes the following were held constant across all test scenarios Client issued a fixed number of requests (100) across all test scenarios Client used a delay between each GET request (35sec) to better exercise
proxyrsquos caching and sleep-awareness capabilities For sleepy server test scenarios the server slept 60 sec awake for 3 sec
Format of Results The following results were collected for each
test scenario
Breakdown of the and types of transactions occurring between clientproxyserver
ldquoGETrdquo ndash Test Scenario Results
GET ndash Description of Test Scenarios
TestScenarios-GET
Scenario
CoAPSleepyServerSe7ngs CoAPSleepAwareReverseProxySe7ngs CoAPClientSe7ngs
SleepDuragton(sec)
AwakeDuragton(sec)
maxAge(sec) Caching SleepAwareSAF+
503NumberofClients
NumberofGETs
DelayBetweenClient
Requests(sec)
1a 0 Always 60 Enabled Disabled 1 100 35
1b 60 3 60 Enabled Disabled 1 100 35
1c 60 3 60 Enabled Enabled 1 100 35
2a 0 Always 60 Enabled Disabled 5 100 35
2b 60 3 60 Enabled Disabled 5 100 35
2c 60 3 60 Enabled Enabled 5 100 35
3a 0 Always 5 Enabled Disabled 5 100 35
3b 60 3 5 Enabled Disabled 5 100 35
3c 60 3 5 Enabled Enabled 5 100 35
ldquoGETrdquo ndash Test Scenario 1 Results
maxAge = 60 and 1 Client
GET ndash Scenario 1 ClientProxy Interface Transaction Mix
Scenarios 1a - Non-Sleepy Server Caching Proxy maxAge = 60sec 1b- Sleepy Server Caching Proxy maxAge = 60sec 1c - Sleepy Server Sleep Aware Proxy maxAge = 60sec
Sleep Aware Proxy has better performance for sleepy servers
0
100
200
300
400
500
600
700
1a 1b 1c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
GET ndash Scenario 1 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
Scenarios 1a - Non-Sleepy Server Caching Proxy maxAge = 60sec 1b- Sleepy Server Caching Proxy maxAge = 60sec 1c - Sleepy Server Sleep Aware Proxy maxAge = 60sec
0
100
200
300
400
500
600
700
800
1a 1b 1c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
ldquoGETrdquo ndash Test Scenario 2 Results
maxAge = 60 and 5 Clients
GET ndash Scenario 2 ClientProxy Interface Transaction Mix
Sleep Aware Proxy has slightly better performance for sleepy servers
0
200
400
600
800
1000
1200
1400
2a 2b 2c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
Scenarios 2a - Non-Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2b- Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2c - Sleepy Server Sleep Aware Proxy maxAge = 60sec 5 Clients
See ldquoExperimental Artifactsrdquo Note 1
GET ndash Scenario 2 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has slightly better performance for sleepy servers
0
50
100
150
200
250
300
350
400
2a 2b 2c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
Scenarios 2a - Non-Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2b- Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2c - Sleepy Server Sleep Aware Proxy maxAge = 60sec 5 Clients
See ldquoExperimental Artifactsrdquo Note 2
Experimental Artifacts Note 1
Currently in the experiment the sleep aware proxy checks the cached state of a resource before putting a request into its Store-and-forward queue while a server is sleeping Once in the queue the proxy unconditionally forwards the queued requests to the server once it wakes up This is not the most efficient setup and can easily be improved If the proxy instead checks its cache again before forwarding each queued request it may not need to forward the request to the server For example if there are two queued GET requests in the proxyrsquos queue that address the same resource Only the first request needs to be sent to the server the second request can use the cached response from the first request
Note 2 Currently in the experiment the sleepy server sends a sleepState PUT request to the
proxy each time it goes to sleep This is not the most efficient setup and can easily be improved For example if the server assumes that the proxy can keep track of its ONOFF cycles with its internal timers (eg as per Fig 1 of I-D) then the number of messages from the sleepy server dramatically goes down
ldquoGETrdquo ndash Test Scenario 3 Results
maxAge = 5 and 5 Clients
GET ndash Scenario 3 ClientProxy Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
Scenarios 3a - Non-Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3b- Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3c - Sleepy Server Sleep Aware Proxy maxAge = 5sec 5 Clients
0
500
1000
1500
2000
2500
3000
3500
4000
4500
5000
3a 3b 3c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
GET ndash Scenario 3 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
0
1000
2000
3000
4000
5000
6000
7000
3a 3b 3c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
Scenarios 3a - Non-Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3b- Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3c - Sleepy Server Sleep Aware Proxy maxAge = 5sec 5 Clients
Conclusions
Conclusions These results show that sleep-aware CoAP
proxy features can significantly optimize communication with sleepy servers in most scenarios
These results also show that sleep-
awareness capabilities can provide additional benefits above and beyond CoAP caching in most scenarios
Backup
Current CoAP Support of Sleepy Node (12)
CoAP proxies can use a previously cached response to service a new GET request for a sleepy origin server (as in HTTP) But if no valid cache then proxy has to attempt to
retrieve and may fail if origin server is sleeping [I-Dietf-core-coap]
Clients can discover list of resources from RD (GET rd-lookuphellip) for sleepy servers But attempt to GET resource from sleepy origin server
may fail if origin server is sleeping [IDietf-core-link-format amp IDshelby-core-resource-
directory]
Current CoAP Support of Sleepy Node (22)
Lower layer support for sleepy nodes in most wireless technologies (eg WiFi ZigBee) But limited to MAC packet scheduling for sleepy nodes
and not aware of specific needs of IP applications (like CoAP)
Proposal ndash RD Based Sleep Tracking (14)
The current CoAP approach to support sleepy nodes can be significantly improved by introducing RD based mechanisms for a CoAP client to determine whether A targeted resource is located on a sleepy server A sleepy server is currently in sleep mode or not
There is any associated caching Proxy (possibly the RD itself) for a sleepy server
Proposal ndash RD Based Sleep Tracking (24)
We define the following new RD attributes to characterize the properties of a sleepy node SleepState - Indicates whether the node is currently in
sleep mode or not (ie Sleeping or Awake) SleepDuration - Indicates the maximum duration of time
that the node stays in sleep mode TimeSleeping - Indicates the length of time the node
has been sleeping (ie if Sleep State = Sleeping) NextSleep - Indicates the next time the node will go to
sleep (ie if Sleep State = Awake)
CachingProxy ndash Indicates the caching proxy of the sleepy node (ie the RD itself or another node)
Proposal ndash RD Based Sleep Tracking (34)
These attributes are all server (node) level and are new parameters added to the RD URI Template Variables
Finally we also define a new lookup-type (ss) for the RD lookup interface specified in [I-Dshelby-core-resource-directory] This new lookup-type supports looking up the
ldquoSleepStaterdquo (ss) of a specified end-point
Proposal ndash RD Based Sleep Tracking (44)
The three time based parameters (SleepDuration TimeSleeping NextSleep) can be based on either an absolute network time (for a time synchronized network) or a relative local time (measured at the local node)
Following the approach of [I-Dietf-core-link-format] and [I-Dshelby-core-resource-directory] sleep parameters for sleepy servers can be stored by the server in the RD and accessed by all interested clients
Examples of using these parameters in a synchronous or asynchronous manner are shown in the I-D
http6lowappnet coreIETF86 2013-03-12-13
We assume people have read the drafts
Meetings serve to advance difficult issues by making good use of face-to-face communications
Note Well Be aware of the IPR principles according to RFC 3979 and its updates
uumlBlue sheetsuumlScribe(s)
96
drar-shy‐iep-shy‐core-shy‐coapsubmiqed13 to13 IESG
2013-shy‐03-shy‐13
97
OMA Lightweight M2M Overview(A new standard using lots of IETF specs including DTLS
CoAP Block Observe Resource Directory SenMLhellip)
Zach ShelbyCoRE WG IETF-86 Orlando
OMA Lightweight M2Mbull Open Mobile Alliance is well known for Device Management (DM)bull OMA Lightweight M2M is a new standard from the alliance
ndash Focused on constrained Cellular and sensor network M2M devicesndash Driven by leading operators and vendors
bull Scopendash Interfaces protocol amp security between Device and Serverndash Object and Resource modelndash Bootstrap Device Access Control Connectivity and Firmware Objects
bull Draft Specifications are availablendash httpmemberopenmobileallianceorgftpPublic_documentsDM
LightweightM2MPermanent_documentsOMA-TS-LightweightM2M-V1_0_0-20130301-Dzip
bull Timelinendash Requirements and Architecture completed 3Q2012ndash Spec ready for Consistency Review 2Q2013ndash Candidate Approval expected 3Q2013
2 CoRE WG IETF-86 Orlando
Architecture
3
Scope of LWM2M
CoRE WG IETF-86 Orlando
Object Model
bull A Client has one or more Object Instancesbull An Object is a collection of Resourcesbull A Resource is an atomic piece of information
ndash Read Written or Executed
bull Resources can have multiple instancesbull Objects and Resources are identified by a
16-bit Integer Instances by an 8-bit Integerbull ObjectsResources are accessed with
simple URIs Object IDObject InstanceResource ID
eg 1213
4 CoRE WG IETF-86 Orlando
CoRE WG IETF-86 Orlando
CoRE Resource Directory
draft-shelby-core-resource-directory-05
Z Shelby C Bormann S Krco
Backgroundbull Not a new concept
ndash think web search engine or any link directorybull Defines the interfaces to a Resource Directorybull Based on Web Linking framework and the CoRE Link Formatbull Generic REST design for use over HTTP and CoAPbull Used by OMA Lightweight M2Mbull Has already been deployed
ndash In traffic monitoring systemsndash In street lighting systemsndash For vehicular asset trackingndash By a major Cellular M2M operator
Changes since -04
bull Restricted Update to parameter updatesbull Added pagination support for the Lookup interfacebull Changed rt= to et= for the registration amp update
interfacebull Added group support
Group Management
bull RD now includes group management featuresbull New Group Function Set
ndash Register a groupbull Group name domain multicast address endpoint members
ndash Remove a groupbull Group lookup using the Lookup Function Set
ndash List registered groupsndash Find the members of a groupndash Find groups with certain endpoints or resources
Registering a Group
EP RD
| |
| - POST rd-groupgp=lights ltgtep=node1 --gt |
| |
| |
| lt---- 201 Created Location rd-group12 ---- |
| |
Req POST coaprdexamplecomrd-groupgp=lights
Payload
ltgtep=node1
ltgtep=node2
Res 201 Created
Location rd-group12
Looking up Group Members
Client RD
| |
| ----- GET rd-lookupepgp=lights1 ----------------------gt |
| |
| |
| lt-- 205 Content ltrdgtd=domain1ltrdgtd=domain2 --------- |
| |
Req GET rd-lookupepgp=lights1
Res 205 Content
ltcoaphostportgtep=node1
ltcoaphostportgtep=node2rdquo
Things for the futurebull Support for JSON representation of Web Links
ndash httptoolsietforgiddraft-bormann-core-links-json-02txtbull Registry for RD registration query parameters
ndash Already OMA Lightweight has defined some new onesbull More examples
Group 3 ldquonew workrdquo(continued)
109
drar-shy‐greevenbosch-shy‐core-shy‐profile-shy‐descripon-shy‐01Bert13 GreevenboschJeroen13 Hoebeke
Isam13 IshaqFloris13 Van13 den13 Abeele
Descripon
bull JSON13 format13 for13 signalling13 the13 servers13 capabilies
bull Signalling13 of13 supported13 opons13 media13 types13 and13 block13 sizendash Other13 items13 can13 be13 added
bull Filtering13 on13 specific13 fields13 through13 URI-shy‐Querybull Link13 hqpdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐profile-shy‐descripon
well-shy‐knownprofile
bull To13 acquire13 profile13 data13 of13 resources13 on13 a13 parcular13 service13 the13 well-shy‐knownprofile13 URI-shy‐path13 is13 introduced
bull For13 example13 to13 get13 all13 informaon13 from13 sensors13 served13 by13 wwwexampleorg13 we13 can13 do13 a13 GET13 to13 coapwwwexampleorgwell-shy‐knownprofile
bull Filtering13 on13 parcular13 resources13 is13 done13 through13 URI-shy‐Queries
Format
bull Currently13 the13 following13 fields13 are13 definedndash ldquopathrdquo13 contains13 the13 URI-shy‐path13 associated13 with13 a13 resource
ndash ldquooprdquo13 a13 numerical13 list13 of13 supported13 opon13 numbers
ndash ldquocfrdquo13 a13 numerical13 list13 of13 supported13 content-shy‐format13 numbers
ndash ldquob1srdquo13 ldquob2srdquo13 supported13 block13 sizes13 for13 Block113 and13 Block213 respecvely
Examplebull On13 the13 right13 is13 an13 example13 of13 a13 camera13 sensor13 at13 coapwwwexampleorgcam13 that13 supports13 the13 Uri-shy‐Host13 (3)13 ETag13 (4)13 Uri-shy‐Port13 (7)13 Uri-shy‐Path13 (11)13 Content-shy‐Format13 (12)13 Token13 (19)13 Block213 (23)13 and13 Proxy-shy‐Uri13 (35)13 opons
bull The13 supported13 content13 formats13 are13 textplain13 (0)13 applicaon13 link-shy‐format13 (40)13 and13 applicaonjson13 (50)
bull The13 supported13 Block213 can13 use13 25613 or13 51213 byte13 blocks
Req13 GET13 coapwwwexampleorgwell-shy‐knownprofile13 Res13 20513 Content13 (applicationjson)13 13 13 13 profile13 13 13 13 13 13 13 13 pathcam13 13 13 13 op[3471112192335]13 13 13 13 13 cf[04050]13 13 13 13 13 b2s[45]13 13 13 13
Filtering13 through13 use13 of13 URI-shy‐Query
bull Filtering13 can13 be13 done13 through13 the13 URI-shy‐Querybull Query13 format13 N=V
ndash N13 is13 a13 profile13 fieldndash V13 is13 the13 desired13 value
bull Examplesndash To13 find13 resources13 that13 support13 content13 format13 ldquoapplicaonjsonrdquo
13 GET13 wwwexampleorgwell-shy‐knownprofilecf=50ndash To13 get13 informaon13 about13 the13 camera
13 GET13 wwwexampleorgwell-shy‐knownprofilepath=cam
Open13 issues
bull Which13 other13 profile13 data13 needs13 signallingndash Content-shy‐type13 for13 different13 methods
bull Fix13 the13 order13 in13 which13 the13 profile13 fields13 must13 appearndash Non-shy‐fixed13 order13 easier13 extensible
bull Inheritance13 of13 a13 profile13 descriponbull Extend13 usage13 to13 signal13 the13 client13 profilebull Integraon13 with13 link13 format
Thank13 youQuesons
drar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval-shy‐00
Bert13 Greevenbosch
Descripon
bull The13 ldquoMinimumRequestInterval13 opon13 can13 be13 used13 to13 indicate13 the13 minimum13 me13 between13 two13 requests13 in13 a13 transacon
bull Originally13 intended13 for13 Block13 but13 also13 usable13 for13 other13 transaconsndash Example13 browsing13 a13 server
bull The13 goal13 is13 to13 reduce13 the13 server13 load13 and13 network13 traffic
bull Link13 hqpsdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval
Usage
bull The13 client13 keeps13 the13 server13 informed13 about13 its13 request13 speed13 through13 inclusion13 of13 the13 ldquoMinimumRequestIntervalrdquo13 opon
bull In13 responses13 the13 server13 fixes13 the13 minimum13 request13 interval13 through13 the13 same13 opon
bull The13 client13 obeys13 the13 speed13 indicated13 by13 the13 server
bull The13 client13 can13 send13 slower13 but13 not13 faster
Advantages
bull The13 server13 has13 means13 to13 limit13 the13 amount13 of13 incoming13 traffic
bull The13 server13 can13 prevent13 to13 become13 overloaded13 with13 too13 many13 tasks
bull The13 server13 does13 not13 need13 arficially13 slow13 down13 the13 client13 by13 sending13 late13 ACKsndash No13 need13 to13 keep13 track13 of13 delayed13 ACKsndash The13 server13 can13 perform13 other13 tasks13 instead
bull Reduced13 network13 traffic
Thank13 youQuesons
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-links-json-02txt
123
RFC 6690 (link-format) documents are somewhat foreign to many web app developerssect would prefer to have them in JSON format
There is no standard way to represent link-format documents in applicationssect but everyone knows how to handle JSON
Define a standard JSON translation for link-format
Itrsquos
not
rock
et
scien
ce
ltsensorsgtct=40title=Sensor Index ltsensorstempgtrt=temperature-cif=sensor ltsensorslightgtrt=light-luxif=sensor lthttpwwwexamplecomsensorst123gt anchor=sensorstemprel=describedby lttgtanchor=sensorstemprel=alternate [hrefsensorsct40titleSensor Index hrefsensorstemprttemperature-cifsensor hrefsensorslightrtlight-luxifsensor hrefhttpwwwexamplecomsensorst123 anchorsensorstempreldescribedby hreftanchorsensorstemprelalternate]
124
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-ipsec-for-coap-00txt
IPsec definitions for CoAP Mostly placeholder at this time Who has implementation experience with this
125
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-cross-reverse-convention-00txt
This draft has two lines of payload(based on a WGLC comment by Cullen Jennings)
coap12344567foobara=3
httpwwwproxycomwellknowncore-translate1234_4567foobara=3
Is that a useful convention to have
126
Insert CI slides here
127
128
0
5
10
15
20
25
30
35
40
10 20 30 40 50 60 70
good
put (
pps)
pps
Goodput vs pps (Econotags)
goodput
[Khattak preliminary]
Congestion Control
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-cocoa-00txt
ldquoadvancedrdquo cc (The draft is just a first shot) Others may have better ideas
129
Insert post-WGLC discussion slides here
130
Stop Continue Start
131
An Agile Retrospective
http6lowappnet coreIETF86 2013-03-12-13
Stop
132
Endless new CoAP optionssect instead use RESTful as much as possible
Move general security lifecycle out Looking at theoretical problems
http6lowappnet coreIETF86 2013-03-12-13
Continue
Interops Running code Look at real-world examples and deployments Solve their actual problems
sect Unilateral enhancements eg higher performance congestion control
sect Transports (SMS hellip)sect Make Web linking and Directories more and more usefulsect RESTful Design Paradigms for real-world problems
133
http6lowappnet coreIETF86 2013-03-12-13
Start
Further push into the (browser) web world (HTML5 browser security)
Specific supporting worksect SenMLsect URI work (dev URN hellip)sect Security Processes (next slide)
Spin outsect (We donrsquot really get to decide where this is done)
134
http6lowappnet coreIETF86 2013-03-12-13
Security
Integrate Application Network Group Keyingsect Tunnel-free setup
Donrsquot redo what has been done alreadysect ZigBee IP is finesect But what about other scenarios
Simple REST interfaces for working with keying materials and authorizationsect Start with defining objectives
Object Security for Constrained Nodes135
Re-chartering CoREWhat do we want to do now that wersquore grown up
Zach ShelbyCoRE WG IETF-86 Orlando
What is the scope
bull So we have a protocol and Web Linking what next
bull Keep with what we know besthellip1 Enhancements around CoAP2 New transports for CoAP3 New representations for Web Links4 General application layer solutions
CoRE WG IETF-86 Orlando 2
Enhancements around CoAP
bull Advanced congestion control
CoRE WG IETF-86 Orlando 3
New Transports for CoAP
bull Infrastructure for CoAP over foondash httptoolsietforgiddraft-silverajan-core-
coap-alternative-transports-01txtbull CoAP over SMS
ndash httptoolsietforgiddraft-becker-core-coap-sms-gprs-03txt
ndash OMA Lightweightbull CoAP over TCP
ndash httptoolsietforgiddraft-li-core-coap-payload-length-option-01txt
CoRE WG IETF-86 Orlando 4
New support for Web Links
bull JSON Web Linksndash httptoolsietforgiddraft-bormann-core-links-
json-02txt
2332010 CoRE WG IETF-77 Anaheim 5
General application layer solutions
bull Resource Directoryndash httptoolsietforgiddraft-shelby-core-
resource-directory-05txtndash OMA Lightweight
2332010 CoRE WG IETF-77 Anaheim 6
Summary of Changes (24)
n Changes from ietf-03 to ietf-04 (Continued) n Moved section 37 (CoAP Multicast and HTTP Unicast Interworking) to
draft-dijk-core-groupcomm-misc (270) n Moved section 331 (DNS-SD) and 332 (CoRE Resource Directory) to
draft-dijk-core-groupcomm-miscClarified that DNS based features are optional (272)
n Focus section 35 (Configuring Group Membership) on a single proposed solution
n Scope of section 53 (Use of MLD) widened to multicast destination advertisement methods in general
n Rewrote section 22 (Scope) for improved readibility n Moved use cases that are not adressed to draft-dijk-core-groupcomm-miscn Various editorial updates for improved readibility
Summary of Changes (34)
n Changes from ietf-04 to ietf-05 n Added a new section 39 (Exceptions) that highlights that IP multicast (and
hence group communications) is not always available (187) n Included guidelines on when (not) to use CoAP responses to multicast
requests and when (not) to accept multicast requests (273) n Added guideline on use of core-block for minimizing response size (275)n Restructured section 6 (Security Considerations) to more fully describe
threats and threat mitigation (277) n Clearly indicated that DNS resolution and reverse DNS lookup are optional n Removed confusing text about a single group having multiple IP addresses
If multiple IP addresses are required then multiple groups (with the same members) should be created
n Removed repetitive text about the fact that group communications is not guaranteed
Summary of Changes (44)
n Changes from ietf-04 to ietf-05 (Continued) n Merged previous section 52 (Multicast Routing) into 31 (IP Multicast
Routing Background) and added link to section 52 (Advertising Membership of Multicast Groups)
n Clarified text in section 38 (Congestion Control) regarding precedence of use of IP multicast domains (ie first try to use link-local scope then site-local scope and only use global IP Communication for CoAP multicast as a last resort)
n Extended group resource manipulation guidelines with use of preconfigured portspaths for the multicast group
n Consolidated all text relating to ports in a new section 33 (Port Configuration)
n Clarified that all methods (GETPUTPOST) for configuring group membership in endpoints should be unicast (and not multicast) in section 37 (Configuring Group Membership In Endpoints)
n Various editorial updates for improved readability
Discussion item (11)
n Solution for Configuring Group Membership (no ticket)n Example of (unicast) configuring an endpoint to be part of one multicast
groupReq POST gp (Content-Format applicationjson)
n floor1westbldg6examplecom ip ff154200f7feed3714cb Res 204 Changed
n Where the ldquogprdquo resource has resource type (rt) ldquocoregprdquo which is defined for this purpose
n Question Do we want specify such a solution (or for example leave it completely up to implementation)
Open Issues(15)
n Review Groupcomm requirements language (271)n Decision made to keep requirements language for informational draftn Each use of MAYMUSTSHOULD etc is to be reviewed
Open Issues(25)
n Add section on multicast via Proxy and its limitations (274)n Add a section to explain the issues amp limitations of doing CoAP multicast
requests via a CoAP Proxy n Goal is to warn and guide implementers in this subject n Also such a section would provide a placeholderreminder of the problems
that might be addressed further in the futuren Based on IETF 85 CoRE WG meeting discussion on Multicast CoAP
requests via a Proxy Discussion summary for referencen Aggregation of responses in a proxy is difficult since it doesnt know
when to stop aggregating responses n SIP tried to deal with this problem but didnt solve it n There may be an expectancy of CoAP client to get single response
back from proxy not multiple The client in this case may not even know what it could expect It may not even know the Proxy-URI contains a multicast target
n Presented via-proxy use case exposes gap in the core-coap specification regarding multicast via proxy (Note Expectation is that core-coap wonrsquot address it in the first planned RFC release)
Open Issues(35)
n Issues with twomultiple Resource Directories in use case (280)n Some potential issues with RD came out of review Peter van der Stok and
WG discussion IETF85 n There are two RD servers use case shows that only one is found despite
the fact that site-local multicast is used - should be two RDs found n Proposal simplify use case to a single RD server on the backbone to avoid
such RD-specific issues like synchronization of RD information between servers
Open Issues(45)
n Add single-subnet configuration to use cases (278)n Suggested by review Peter van der Stok and IETF85 WG discussion that
its best to start explaining the simplebasic cases and then gradually build up complexity
n Simplest case not shown yet would be a single subnet network configuration which is currently not present in the I-D only the 2-subnet configuration of Fig 1
n Question Do we need to add such case or doesnt it add muchn (Note that core-coap Figure 22 already shows the simplest case of link-local
multicast)
Open Issues(55)
n Add use case with controller (client) located on the backbone (279)n Suggested by discussion following review Peter van der Stok n Case missing where a controller (client) is located on the backbonen Question Do we need to add such case or does it add much
Group 2a other old friends
25
Angelo Castellani Salvatore Loreto Akbar Rahman Thomas Fossati Esko Dijk
IETF 86 March 2013httpwwwietforgiddraft-castellani-core-http-mapping-07txt
Best Practices for HTTP-CoAP Mapping
Implementation
Summary of Changes (from -06 rev)
n Based on discussion at last IETF-85 (Atlanta)n Clarification of HTTP-CoAP Proxies
n Definitionn Placementn Benefits
n Clarification of HTTP-CoAP URI mapping options
Goals of I-D
n For Reverse HTTP-CoAP Cross Protocol Proxyn Provide more detailed information to proxy designers (beyond
Section 10 of [I-Dietf-core-coap]) to help implement proxies that correctly inter-work with other CoAP and HTTP clientserver implementations that adhere to the specifications
n Define a consistent set of guidelines that a HTTP-to-CoAP proxy implementation MAY adhere to The main reason of adhering to such guidelines is to reduce variation between proxy implementations thereby increasing interoperabilityn As an example use case a proxy conforming to these guidelines made
by vendor A can be easily replaced by a proxy from vendor B that also conforms to the guidelines
I-D Outline
n Guidance on HTTP to CoAP URI mappingn HTTP-CoAP Reverse cross-protocol proxy implementation
n Placementn Response code amp media type translationsn Caching and congestion controln Cache refresh via Observen Use of CoAP blockwise transfern Security translation
n Security Considerationsn Traffic overflown Handling secured exchanges
Definitions (12)
n Cross-Protocol Proxy (or Cross Proxy) is a proxy performing a cross- protocol mapping in the context of this document a HTTP-CoAP (HC) mapping A Cross-Protocol Proxy can behave as a Forward Proxy Reverse Proxy or Interception Proxy n Note In this document we focus on the Reverse Proxy mode of the
Cross-Protocol Proxy
n Forward Proxy a message forwarding agent that is selected by the client usually via local configuration rules to receive requests for some type(s) of absolute URI and to attempt to satisfy those requests via translation to the protocol indicated by the absolute URI The user decides (is willing to) use the proxy as the forwardingdereferencing agent for a predefined subset of the URI space
Definitions (22)
n Reverse Proxy a receiving agent that acts as a layer above some other server(s) and translates the received requests to the underlying servers protocol It behaves as an origin (HTTP) server on its connection towards the (HTTP) client and as a (CoAP) client on its connection towards the (CoAP) origin server The (HTTP) client uses the origin-form [I-Dietf-httpbis-p1-messaging] as a request- target URI
n Reverse and Forward proxies are technically very similar with main differences being that the former appears to a client as an origin server while the latter does not and that clients may be unaware they are communicating with a proxy
Reverse Cross-Protocol Proxy Deployment Scenario
HTTP-CoAP Response Code Mapping
Implementation Experience
n Direct experience from the draft authorsn Squid HTTP-CoAP mapping module
n University of Padovan httptelecomdeiunipditiotn Both Forward and Interception operation supported
n HTTP-CoAP proxy based on EvCoAPn KoanLogic University of Bologna and Salvatore
Loreto (as individual)n httpsgithubcomkoanlogicwebthingstreemasterbridgesw
libevcoapn The document is open to input from other implementations
Next Steps
n Does the WG recommend adoptionn Intended status Informational Best Practicen Purpose Reduce arbitrary variation between proxy
implementations thereby increasing interoperability
Backup
HTTP to CoAP URI Mapping Options (12)
n Embedded Mapping n In an embedded mapping approach the HTTP URI has embedded
inside it the authority and path part of the CoAP URI n Example The CoAP resource nodecoapsomethingnetfoo can
be accessed by an HTTP client by inserting in the request httphc-proxysomethingnetcoapnodecoapsomethingnetfoo The Cross-Protocol Proxy then maps the URI to coapnodecoapsomethingnetfoo
HTTP to CoAP URI Mapping Options (22)
n Homogeneous Mapping n In a homogeneous mapping approach only the scheme portion of the URI
needs to be mapped The rest of the URI (ie authority path etc) remains unchanged
n Example The CoAP resource coapnodecoapsomethingnetfoo can be accessed by an HTTP client by requesting httpnodecoapsomethingnetfoo The Cross-Protocol Proxy receiving the request is responsible to map the URI to coapnodecoapsomethingnetfoo
n Background info n The assumption in this case is that the HTTP client would be able to
successfully resolve nodecoapsomethingnet using DNS infrastructure to return the IP address of the HC proxy Most likely this would be through a two step DNS lookup where the first DNS lookup would resolve somethingnet using public DNS infrastructure
n Then the second DNS lookup on the subdomain coap and the host node would typically be resolved by a DNS server operated by the owner of domain somethingnet So this domain owner can manage its own internal node names and subdomain allocation which would correspond to the CoAP namespace
Group 3 ldquonew workrdquo
39
Transport of CoAP over SMS USSD and GPRSdraft-becker-core-coap-sms-gprs-03
Markus Becker Kepeng LiKoojana Kuladinithi Thomas Poumltsch
CoRE WG IETF-86 Orlando
1 10
ScenariosI In M2M communication IP connectivity is not alwayssupported by the constrained end-points
I Power savingI Coverage (GPRS 3G LTE)
I SMS and USSD based communication is almost alwayssupported
210
Changes from draft-01 to draft-03 (1)
I Added possible CONNONACK interactions Section 5
I Option name changed from Reply-To- to Response-To-Section 16 and Section 101
I Added URI schemeEg coap+tel+15105550101well-knowncore Section 11
I Added possible M2M proxy scenarios Section 14
3 10
Changes from draft-01 to draft-03 (2)
I Added reference to bormann-coap-misc for other SMSencoding Section 71
I Updated requirements on Uri-Host and Uri-Port forcoap+tel Section 10
I Added security considerations Transport and ObjectSecurity Section 15
I Chose CoAP option numbers and updated the optionnumber table to meet draft-ietf-core-coap-10 Table 1
I Added an IANA registration for the URI scheme coap+telSection 162
4 10
Feedback Split coap+tel into coap+smsand coap+ussd
I How else to differ the various transports in the URII Or is the transport to use decided by the implementationI See alsodraft-silverajan-core-coap-alternative-transports-01
5 10
Feedback Response-To-Scheme option
I Should there be a Response-To-Scheme optionadditionally to Response-To-Uri-Host andResponse-To-Uri-Path
I So that a CoAP end-point which receives a request by CoAPover non-IP transport can be instructed to also use thenon-IP transport for the response
I This would imply to add aResponse-To-Telephone-Subscriber and more options forother transports that have other URI schemes than coapand coaps
6 10
Feedback Selection of Transport by Client
I When a server is reachable by various transports howdoes a client decide which transport to use
I Client-side application congurationI Leave it to a proxy which uses cellular network lookupfunctions
7 10
Feedback Potential Threats
I Trigger expensive short messagesI Redirect trac to other addressesI More threats
I Are the security measures in the draft adequateI Whitelisting on serverI Relying on cellular network security (dedicated M2M APNs)I Object security on CoAP payload
8 10
Feedback Message Exchanges
I Figures 11-18 show possible message exchanges whenclient and server have two addresses
I With NON Not using CoAP retransmission capabilityI ACK on different transportI Additional (costly) message on Transport AI Request with Content
I Which ones are allowedI Which ones are meaningful
9 10
Next steps
I Rene Uri schemeI Response-To-Scheme optionI Selection of Message ExchangeI Rene Proxying
10 10
CoAP13 Communicaon13 with13 Alternave13 Transports
Bill Silverajan and Teemu SavolainenCore WG IETF 86 Orlando
031113
Objecves13 (In13 Scope)
bull Unambiguous13 representaon13 of13 transport13 to13 be13 used13 by13 CoAP
bull Details13 how13 the13 transport13 can13 carry13 CoAP13 packet
bull Focus13 is13 on13 what13 CoAP13 communicaons13 requirements13 are
bull Allow13 CoAP13 mechanisms13 to13 exploit13 cross-shy‐layer13 opmisaons
51
031113
Non13 Goals13 (Not13 in13 scope)
bull Applicaon-shy‐level13 QoS13 requirementsbull Real-shy‐me13 constraintsbull Ordering13 reliability13 congeson13 controlbull Applicaon13 and13 network13 adaptaonbull Mobility13 and13 readdressing13 supportbull Network13 protocol13 (eg13 IPsec)13 configuraon
52
031113
Use13 Cases
bull NAT13 and13 Firewall13 traversal13 with13 TCPbull Delay13 Tolerant13 Networkingbull Non-shy‐IP13 Low13 Energy13 Protocols
53
031113
Related13 Work
bull OMA13 Lightweight13 M2M13 Protocolbull CoAP13 over13 SMSGPRSUSSD
54
031113
What13 does13 the13 work13 entail
bull The13 ability13 to13 specify13 end13 point13 idenfiers13 and13 URIs13 to13 reflect13 which13 transport13 CoAP13 can13 use
bull The13 ability13 to13 register13 to13 resource13 directories13 resource13 types13 reflecng13 types13 of13 transport13 available
bull Ability13 for13 mul-shy‐transport13 nodes13 to13 select13 transport13 to13 use13 without13 significant13 alteraon13 to13 CoAP13 packet13 structure
55
031113
Points13 to13 consider
bull Requirements13 for13 transport13 layer13 protocol13 to13 carry13 CoAP13 packets
bull Representaon13 of13 URI13 scheme13 for13 generic13 transport13 protocols
bull Opon13 extensions13 for13 CoAP13 to13 express13 available13 transports
bull Mapping13 and13 message13 sizebull Security13 consideraons
56
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
URI13 =13 scheme13 13 13 authority13 path-shy‐abempty13 [13 query13 ]
bull Within13 the13 scheme13 namebull In13 the13 URI13 pathbull As13 a13 query13 component
57
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
bull Within13 the13 scheme13 namendash coap+tel+15105550101well-shy‐knowncorendash coap+tcpexamplecom5683temperaturendash coap+blel2cap[1234567890AB]4pulse
bull Easy13 URI13 parsing13 for13 transport13 type13 and13 idenfier
bull Each13 new13 scheme13 name13 requires13 IANA13 registraon
58
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
bull In13 the13 URI13 pathndash coaphostexamplecomtransport=tcpwell-shy‐knowncorert=core-shy‐rd
bull Easy13 adopon13 of13 new13 (and13 experimental)13 CoAP13 transports13 without13 IANA13 registraon
bull Caveat13 Uri-shy‐Path13 opon13 is13 a13 Crical13 CoAP13 opon13 see13 secon13 54113 of13 I-shy‐Diep-shy‐core-shy‐coap
59
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
bull As13 a13 URI13 query13 componentndash coaphostexamplecomwell-shy‐knowncorert=core-shy‐rdq=tcp
bull Also13 easy13 to13 adopt13 new13 (and13 experimental)13 CoAP13 transports13 without13 IANA13 registraon
bull Caveat13 Uri-shy‐Query13 opon13 is13 a13 Crical13 CoAP13 opon13 see13 secon13 54113 of13 I-shy‐Diep-shy‐core-shy‐coap
60
031113
URI13 Representaons13 for13 CoAPNon13 standard13 ways
bull Transport13 in13 the13 URI13 authority13 componentndash coaphost[port][transport]13 instead13 of13 coaphost[port]
bull Transport13 as13 a13 service13 URLndash servicecoaptcphostexamplecomwell-shy‐knowncorert=core-shy‐rd
bull Above13 two13 ways13 break13 exisng13 compability13 (although13 both13 are13 based13 on13 valid13 IANA13 URI13 registraons)
61
031113
URI13 Representaons13 for13 CoAPMiscellaneous13 Consideraons
bull Ensure13 that13 transport13 is13 defined13 unambiguously13 (eg13 L2CAP13 used13 by13 both13 BLE13 and13 standard13 Bluetooth13 so13 avoid13 rdquocoap+l2caprdquo13 or13 rdquotransport=l2caprdquo13 or13 rdquoq=l2caprdquondash Can13 be13 done13 as13 WG13 consensusndash Namespace13 approach13 eg13 rdquocoap+blel2caprdquo13 or13 rdquoq=blel2caprdquo
bull Allow13 end-shy‐points13 to13 use13 CoAP13 Resource13 Directory13 to13 register13 alternave13 transports13 and13 idenfiers13 and13 provide13 periodic13 updatesndash Register13 rdquocore-shy‐transportrdquo13 resource13 type
62
031113
Transport13 Consideraons
bull Uniqueness13 of13 end-shy‐point13 idenficaonbull Communicaon13 support13 Unidireconal13 Bidireconal13 1N13 (broadcast13 mulcast13 anycast)13 messaging
bull Binary13 encoding13 Network13 byte13 orderingbull MTU13 correlaon13 with13 CoAP13 PDU13 sizebull Transport13 latency
63
031113
Security13 Consideraons
bull Drar13 does13 not13 introduce13 new13 security13 requirements13 by13 itself
bull There13 may13 be13 privacy13 issues13 if13 nodes13 use13 telephone13 numbers13 or13 MAC13 addresses13 as13 public13 end13 point13 idenfiers
64
Akbar Rahman
IETF 86 March 2013 httpwwwietforgiddraft-rahman-core-sleepy-02txt
Enhanced Sleepy Node Support for CoAP
Introduction
It is expected that in CoAP networks there will be a certain portion of devices that are sleepy and which may occasionally go into a sleep mode (ie go into a low power state to conserve power) and subsequently have reduced CoAP protocol communication ability
This I-D proposes a minimal and efficient mechanism building on the Resource Directory concept (which will be integrated into a CoAP Proxy) to enhance sleepy node support in CoAP networks
Main Question from IETF-85 (Atlanta)
What performance benefit does the proposed Sleepy Node support solution give in a network that already has standard CoAP caching enabled
Sleepy Node Performance Analysis
Experimental Network
1-5 clients
Both Sleepy and Non-
Sleepy servers
Sleepy Node Performance Analysis Network Setup
CoAPSleepyServer(s)
CoAPSleepAwareReverseProxy
CoAP
Client(s)
Request
Response
Sleep9AwareCoREResourceDirectoryCapability
PublishedSleepParameters
Sleep9AwareCoAPStoreandForwardCapability Response
Request
SleepAwareCoAP503ResponseCapability
CoAPCachingCapability
bull Server supports publishing sleep parameters to proxy bull Eg Irsquom going to be asleep for X seconds
bull Proxy supports sleep-awareness capabilities bull Proxy also supports caching capability based off of maxAge bull Protocol flow similar to approach of Figure 1 (Synchronous RD Based Sleep
Tracking) of I-D
Proxy capabilities can be selectively enableddisabled
Proxy ndash Server Interface
Client ndash Proxy Interface
CoAP Sleep-Aware Reverse Proxy Features CoRE Sleep-aware Resource Directory
Support storing published sleep parameters from CoAP servers sleepState (AWAKE ASLEEP) sleepDuration
Sleep-aware CoAP 503 Response Capability If CoAP request to a sleeping server is received proxy returns a
lsquo503 Retry-Afterrsquo response to client 503 contains a timestamp indicating when the sever will wake back up
(timestamp delivered in CoAP maxAge option) Sleep-aware CoAP Store-and-Forward Capability
If CoAP request to a sleeping server is received proxy stores request until server wakes up and then forwards it
Caching capability Cache GET responses from server if maxAge option is present
(this is not a sleep aware feature)
Goals of Performance Analysis
For networks having sleepy servers provide measurements to quantify the impact that CoAP sleep-awareness capabilities can have
See if sleep-awareness capabilities can
provide additional benefits even when CoAP caching is used
Overview of Performance Analysis Performed The analysis was broken up into a set of test scenarios Each test scenario used a different combination of the following
variables Client issued GET requests Server was configured as a sleepy or non-sleepy server Proxy caching of GET responses was enabled or disabled Proxy sleep-aware 503 response capability was enabled or disabled Proxy store-and-forward capability was enabled or disabled maxAge in GET responses ndash Two values were tested 60sec and 5sec of Clients ndash Two values were used ndash 1 client and 5 clients
For comparison purposes the following were held constant across all test scenarios Client issued a fixed number of requests (100) across all test scenarios Client used a delay between each GET request (35sec) to better exercise
proxyrsquos caching and sleep-awareness capabilities For sleepy server test scenarios the server slept 60 sec awake for 3 sec
Format of Results The following results were collected for each
test scenario
Breakdown of the and types of transactions occurring between clientproxyserver
ldquoGETrdquo ndash Test Scenario Results
GET ndash Description of Test Scenarios
TestScenarios-GET
Scenario
CoAPSleepyServerSe7ngs CoAPSleepAwareReverseProxySe7ngs CoAPClientSe7ngs
SleepDuragton(sec)
AwakeDuragton(sec)
maxAge(sec) Caching SleepAwareSAF+
503NumberofClients
NumberofGETs
DelayBetweenClient
Requests(sec)
1a 0 Always 60 Enabled Disabled 1 100 35
1b 60 3 60 Enabled Disabled 1 100 35
1c 60 3 60 Enabled Enabled 1 100 35
2a 0 Always 60 Enabled Disabled 5 100 35
2b 60 3 60 Enabled Disabled 5 100 35
2c 60 3 60 Enabled Enabled 5 100 35
3a 0 Always 5 Enabled Disabled 5 100 35
3b 60 3 5 Enabled Disabled 5 100 35
3c 60 3 5 Enabled Enabled 5 100 35
ldquoGETrdquo ndash Test Scenario 1 Results
maxAge = 60 and 1 Client
GET ndash Scenario 1 ClientProxy Interface Transaction Mix
Scenarios 1a - Non-Sleepy Server Caching Proxy maxAge = 60sec 1b- Sleepy Server Caching Proxy maxAge = 60sec 1c - Sleepy Server Sleep Aware Proxy maxAge = 60sec
Sleep Aware Proxy has better performance for sleepy servers
0
100
200
300
400
500
600
700
1a 1b 1c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
GET ndash Scenario 1 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
Scenarios 1a - Non-Sleepy Server Caching Proxy maxAge = 60sec 1b- Sleepy Server Caching Proxy maxAge = 60sec 1c - Sleepy Server Sleep Aware Proxy maxAge = 60sec
0
100
200
300
400
500
600
700
800
1a 1b 1c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
ldquoGETrdquo ndash Test Scenario 2 Results
maxAge = 60 and 5 Clients
GET ndash Scenario 2 ClientProxy Interface Transaction Mix
Sleep Aware Proxy has slightly better performance for sleepy servers
0
200
400
600
800
1000
1200
1400
2a 2b 2c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
Scenarios 2a - Non-Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2b- Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2c - Sleepy Server Sleep Aware Proxy maxAge = 60sec 5 Clients
See ldquoExperimental Artifactsrdquo Note 1
GET ndash Scenario 2 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has slightly better performance for sleepy servers
0
50
100
150
200
250
300
350
400
2a 2b 2c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
Scenarios 2a - Non-Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2b- Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2c - Sleepy Server Sleep Aware Proxy maxAge = 60sec 5 Clients
See ldquoExperimental Artifactsrdquo Note 2
Experimental Artifacts Note 1
Currently in the experiment the sleep aware proxy checks the cached state of a resource before putting a request into its Store-and-forward queue while a server is sleeping Once in the queue the proxy unconditionally forwards the queued requests to the server once it wakes up This is not the most efficient setup and can easily be improved If the proxy instead checks its cache again before forwarding each queued request it may not need to forward the request to the server For example if there are two queued GET requests in the proxyrsquos queue that address the same resource Only the first request needs to be sent to the server the second request can use the cached response from the first request
Note 2 Currently in the experiment the sleepy server sends a sleepState PUT request to the
proxy each time it goes to sleep This is not the most efficient setup and can easily be improved For example if the server assumes that the proxy can keep track of its ONOFF cycles with its internal timers (eg as per Fig 1 of I-D) then the number of messages from the sleepy server dramatically goes down
ldquoGETrdquo ndash Test Scenario 3 Results
maxAge = 5 and 5 Clients
GET ndash Scenario 3 ClientProxy Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
Scenarios 3a - Non-Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3b- Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3c - Sleepy Server Sleep Aware Proxy maxAge = 5sec 5 Clients
0
500
1000
1500
2000
2500
3000
3500
4000
4500
5000
3a 3b 3c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
GET ndash Scenario 3 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
0
1000
2000
3000
4000
5000
6000
7000
3a 3b 3c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
Scenarios 3a - Non-Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3b- Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3c - Sleepy Server Sleep Aware Proxy maxAge = 5sec 5 Clients
Conclusions
Conclusions These results show that sleep-aware CoAP
proxy features can significantly optimize communication with sleepy servers in most scenarios
These results also show that sleep-
awareness capabilities can provide additional benefits above and beyond CoAP caching in most scenarios
Backup
Current CoAP Support of Sleepy Node (12)
CoAP proxies can use a previously cached response to service a new GET request for a sleepy origin server (as in HTTP) But if no valid cache then proxy has to attempt to
retrieve and may fail if origin server is sleeping [I-Dietf-core-coap]
Clients can discover list of resources from RD (GET rd-lookuphellip) for sleepy servers But attempt to GET resource from sleepy origin server
may fail if origin server is sleeping [IDietf-core-link-format amp IDshelby-core-resource-
directory]
Current CoAP Support of Sleepy Node (22)
Lower layer support for sleepy nodes in most wireless technologies (eg WiFi ZigBee) But limited to MAC packet scheduling for sleepy nodes
and not aware of specific needs of IP applications (like CoAP)
Proposal ndash RD Based Sleep Tracking (14)
The current CoAP approach to support sleepy nodes can be significantly improved by introducing RD based mechanisms for a CoAP client to determine whether A targeted resource is located on a sleepy server A sleepy server is currently in sleep mode or not
There is any associated caching Proxy (possibly the RD itself) for a sleepy server
Proposal ndash RD Based Sleep Tracking (24)
We define the following new RD attributes to characterize the properties of a sleepy node SleepState - Indicates whether the node is currently in
sleep mode or not (ie Sleeping or Awake) SleepDuration - Indicates the maximum duration of time
that the node stays in sleep mode TimeSleeping - Indicates the length of time the node
has been sleeping (ie if Sleep State = Sleeping) NextSleep - Indicates the next time the node will go to
sleep (ie if Sleep State = Awake)
CachingProxy ndash Indicates the caching proxy of the sleepy node (ie the RD itself or another node)
Proposal ndash RD Based Sleep Tracking (34)
These attributes are all server (node) level and are new parameters added to the RD URI Template Variables
Finally we also define a new lookup-type (ss) for the RD lookup interface specified in [I-Dshelby-core-resource-directory] This new lookup-type supports looking up the
ldquoSleepStaterdquo (ss) of a specified end-point
Proposal ndash RD Based Sleep Tracking (44)
The three time based parameters (SleepDuration TimeSleeping NextSleep) can be based on either an absolute network time (for a time synchronized network) or a relative local time (measured at the local node)
Following the approach of [I-Dietf-core-link-format] and [I-Dshelby-core-resource-directory] sleep parameters for sleepy servers can be stored by the server in the RD and accessed by all interested clients
Examples of using these parameters in a synchronous or asynchronous manner are shown in the I-D
http6lowappnet coreIETF86 2013-03-12-13
We assume people have read the drafts
Meetings serve to advance difficult issues by making good use of face-to-face communications
Note Well Be aware of the IPR principles according to RFC 3979 and its updates
uumlBlue sheetsuumlScribe(s)
96
drar-shy‐iep-shy‐core-shy‐coapsubmiqed13 to13 IESG
2013-shy‐03-shy‐13
97
OMA Lightweight M2M Overview(A new standard using lots of IETF specs including DTLS
CoAP Block Observe Resource Directory SenMLhellip)
Zach ShelbyCoRE WG IETF-86 Orlando
OMA Lightweight M2Mbull Open Mobile Alliance is well known for Device Management (DM)bull OMA Lightweight M2M is a new standard from the alliance
ndash Focused on constrained Cellular and sensor network M2M devicesndash Driven by leading operators and vendors
bull Scopendash Interfaces protocol amp security between Device and Serverndash Object and Resource modelndash Bootstrap Device Access Control Connectivity and Firmware Objects
bull Draft Specifications are availablendash httpmemberopenmobileallianceorgftpPublic_documentsDM
LightweightM2MPermanent_documentsOMA-TS-LightweightM2M-V1_0_0-20130301-Dzip
bull Timelinendash Requirements and Architecture completed 3Q2012ndash Spec ready for Consistency Review 2Q2013ndash Candidate Approval expected 3Q2013
2 CoRE WG IETF-86 Orlando
Architecture
3
Scope of LWM2M
CoRE WG IETF-86 Orlando
Object Model
bull A Client has one or more Object Instancesbull An Object is a collection of Resourcesbull A Resource is an atomic piece of information
ndash Read Written or Executed
bull Resources can have multiple instancesbull Objects and Resources are identified by a
16-bit Integer Instances by an 8-bit Integerbull ObjectsResources are accessed with
simple URIs Object IDObject InstanceResource ID
eg 1213
4 CoRE WG IETF-86 Orlando
CoRE WG IETF-86 Orlando
CoRE Resource Directory
draft-shelby-core-resource-directory-05
Z Shelby C Bormann S Krco
Backgroundbull Not a new concept
ndash think web search engine or any link directorybull Defines the interfaces to a Resource Directorybull Based on Web Linking framework and the CoRE Link Formatbull Generic REST design for use over HTTP and CoAPbull Used by OMA Lightweight M2Mbull Has already been deployed
ndash In traffic monitoring systemsndash In street lighting systemsndash For vehicular asset trackingndash By a major Cellular M2M operator
Changes since -04
bull Restricted Update to parameter updatesbull Added pagination support for the Lookup interfacebull Changed rt= to et= for the registration amp update
interfacebull Added group support
Group Management
bull RD now includes group management featuresbull New Group Function Set
ndash Register a groupbull Group name domain multicast address endpoint members
ndash Remove a groupbull Group lookup using the Lookup Function Set
ndash List registered groupsndash Find the members of a groupndash Find groups with certain endpoints or resources
Registering a Group
EP RD
| |
| - POST rd-groupgp=lights ltgtep=node1 --gt |
| |
| |
| lt---- 201 Created Location rd-group12 ---- |
| |
Req POST coaprdexamplecomrd-groupgp=lights
Payload
ltgtep=node1
ltgtep=node2
Res 201 Created
Location rd-group12
Looking up Group Members
Client RD
| |
| ----- GET rd-lookupepgp=lights1 ----------------------gt |
| |
| |
| lt-- 205 Content ltrdgtd=domain1ltrdgtd=domain2 --------- |
| |
Req GET rd-lookupepgp=lights1
Res 205 Content
ltcoaphostportgtep=node1
ltcoaphostportgtep=node2rdquo
Things for the futurebull Support for JSON representation of Web Links
ndash httptoolsietforgiddraft-bormann-core-links-json-02txtbull Registry for RD registration query parameters
ndash Already OMA Lightweight has defined some new onesbull More examples
Group 3 ldquonew workrdquo(continued)
109
drar-shy‐greevenbosch-shy‐core-shy‐profile-shy‐descripon-shy‐01Bert13 GreevenboschJeroen13 Hoebeke
Isam13 IshaqFloris13 Van13 den13 Abeele
Descripon
bull JSON13 format13 for13 signalling13 the13 servers13 capabilies
bull Signalling13 of13 supported13 opons13 media13 types13 and13 block13 sizendash Other13 items13 can13 be13 added
bull Filtering13 on13 specific13 fields13 through13 URI-shy‐Querybull Link13 hqpdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐profile-shy‐descripon
well-shy‐knownprofile
bull To13 acquire13 profile13 data13 of13 resources13 on13 a13 parcular13 service13 the13 well-shy‐knownprofile13 URI-shy‐path13 is13 introduced
bull For13 example13 to13 get13 all13 informaon13 from13 sensors13 served13 by13 wwwexampleorg13 we13 can13 do13 a13 GET13 to13 coapwwwexampleorgwell-shy‐knownprofile
bull Filtering13 on13 parcular13 resources13 is13 done13 through13 URI-shy‐Queries
Format
bull Currently13 the13 following13 fields13 are13 definedndash ldquopathrdquo13 contains13 the13 URI-shy‐path13 associated13 with13 a13 resource
ndash ldquooprdquo13 a13 numerical13 list13 of13 supported13 opon13 numbers
ndash ldquocfrdquo13 a13 numerical13 list13 of13 supported13 content-shy‐format13 numbers
ndash ldquob1srdquo13 ldquob2srdquo13 supported13 block13 sizes13 for13 Block113 and13 Block213 respecvely
Examplebull On13 the13 right13 is13 an13 example13 of13 a13 camera13 sensor13 at13 coapwwwexampleorgcam13 that13 supports13 the13 Uri-shy‐Host13 (3)13 ETag13 (4)13 Uri-shy‐Port13 (7)13 Uri-shy‐Path13 (11)13 Content-shy‐Format13 (12)13 Token13 (19)13 Block213 (23)13 and13 Proxy-shy‐Uri13 (35)13 opons
bull The13 supported13 content13 formats13 are13 textplain13 (0)13 applicaon13 link-shy‐format13 (40)13 and13 applicaonjson13 (50)
bull The13 supported13 Block213 can13 use13 25613 or13 51213 byte13 blocks
Req13 GET13 coapwwwexampleorgwell-shy‐knownprofile13 Res13 20513 Content13 (applicationjson)13 13 13 13 profile13 13 13 13 13 13 13 13 pathcam13 13 13 13 op[3471112192335]13 13 13 13 13 cf[04050]13 13 13 13 13 b2s[45]13 13 13 13
Filtering13 through13 use13 of13 URI-shy‐Query
bull Filtering13 can13 be13 done13 through13 the13 URI-shy‐Querybull Query13 format13 N=V
ndash N13 is13 a13 profile13 fieldndash V13 is13 the13 desired13 value
bull Examplesndash To13 find13 resources13 that13 support13 content13 format13 ldquoapplicaonjsonrdquo
13 GET13 wwwexampleorgwell-shy‐knownprofilecf=50ndash To13 get13 informaon13 about13 the13 camera
13 GET13 wwwexampleorgwell-shy‐knownprofilepath=cam
Open13 issues
bull Which13 other13 profile13 data13 needs13 signallingndash Content-shy‐type13 for13 different13 methods
bull Fix13 the13 order13 in13 which13 the13 profile13 fields13 must13 appearndash Non-shy‐fixed13 order13 easier13 extensible
bull Inheritance13 of13 a13 profile13 descriponbull Extend13 usage13 to13 signal13 the13 client13 profilebull Integraon13 with13 link13 format
Thank13 youQuesons
drar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval-shy‐00
Bert13 Greevenbosch
Descripon
bull The13 ldquoMinimumRequestInterval13 opon13 can13 be13 used13 to13 indicate13 the13 minimum13 me13 between13 two13 requests13 in13 a13 transacon
bull Originally13 intended13 for13 Block13 but13 also13 usable13 for13 other13 transaconsndash Example13 browsing13 a13 server
bull The13 goal13 is13 to13 reduce13 the13 server13 load13 and13 network13 traffic
bull Link13 hqpsdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval
Usage
bull The13 client13 keeps13 the13 server13 informed13 about13 its13 request13 speed13 through13 inclusion13 of13 the13 ldquoMinimumRequestIntervalrdquo13 opon
bull In13 responses13 the13 server13 fixes13 the13 minimum13 request13 interval13 through13 the13 same13 opon
bull The13 client13 obeys13 the13 speed13 indicated13 by13 the13 server
bull The13 client13 can13 send13 slower13 but13 not13 faster
Advantages
bull The13 server13 has13 means13 to13 limit13 the13 amount13 of13 incoming13 traffic
bull The13 server13 can13 prevent13 to13 become13 overloaded13 with13 too13 many13 tasks
bull The13 server13 does13 not13 need13 arficially13 slow13 down13 the13 client13 by13 sending13 late13 ACKsndash No13 need13 to13 keep13 track13 of13 delayed13 ACKsndash The13 server13 can13 perform13 other13 tasks13 instead
bull Reduced13 network13 traffic
Thank13 youQuesons
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-links-json-02txt
123
RFC 6690 (link-format) documents are somewhat foreign to many web app developerssect would prefer to have them in JSON format
There is no standard way to represent link-format documents in applicationssect but everyone knows how to handle JSON
Define a standard JSON translation for link-format
Itrsquos
not
rock
et
scien
ce
ltsensorsgtct=40title=Sensor Index ltsensorstempgtrt=temperature-cif=sensor ltsensorslightgtrt=light-luxif=sensor lthttpwwwexamplecomsensorst123gt anchor=sensorstemprel=describedby lttgtanchor=sensorstemprel=alternate [hrefsensorsct40titleSensor Index hrefsensorstemprttemperature-cifsensor hrefsensorslightrtlight-luxifsensor hrefhttpwwwexamplecomsensorst123 anchorsensorstempreldescribedby hreftanchorsensorstemprelalternate]
124
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-ipsec-for-coap-00txt
IPsec definitions for CoAP Mostly placeholder at this time Who has implementation experience with this
125
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-cross-reverse-convention-00txt
This draft has two lines of payload(based on a WGLC comment by Cullen Jennings)
coap12344567foobara=3
httpwwwproxycomwellknowncore-translate1234_4567foobara=3
Is that a useful convention to have
126
Insert CI slides here
127
128
0
5
10
15
20
25
30
35
40
10 20 30 40 50 60 70
good
put (
pps)
pps
Goodput vs pps (Econotags)
goodput
[Khattak preliminary]
Congestion Control
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-cocoa-00txt
ldquoadvancedrdquo cc (The draft is just a first shot) Others may have better ideas
129
Insert post-WGLC discussion slides here
130
Stop Continue Start
131
An Agile Retrospective
http6lowappnet coreIETF86 2013-03-12-13
Stop
132
Endless new CoAP optionssect instead use RESTful as much as possible
Move general security lifecycle out Looking at theoretical problems
http6lowappnet coreIETF86 2013-03-12-13
Continue
Interops Running code Look at real-world examples and deployments Solve their actual problems
sect Unilateral enhancements eg higher performance congestion control
sect Transports (SMS hellip)sect Make Web linking and Directories more and more usefulsect RESTful Design Paradigms for real-world problems
133
http6lowappnet coreIETF86 2013-03-12-13
Start
Further push into the (browser) web world (HTML5 browser security)
Specific supporting worksect SenMLsect URI work (dev URN hellip)sect Security Processes (next slide)
Spin outsect (We donrsquot really get to decide where this is done)
134
http6lowappnet coreIETF86 2013-03-12-13
Security
Integrate Application Network Group Keyingsect Tunnel-free setup
Donrsquot redo what has been done alreadysect ZigBee IP is finesect But what about other scenarios
Simple REST interfaces for working with keying materials and authorizationsect Start with defining objectives
Object Security for Constrained Nodes135
Re-chartering CoREWhat do we want to do now that wersquore grown up
Zach ShelbyCoRE WG IETF-86 Orlando
What is the scope
bull So we have a protocol and Web Linking what next
bull Keep with what we know besthellip1 Enhancements around CoAP2 New transports for CoAP3 New representations for Web Links4 General application layer solutions
CoRE WG IETF-86 Orlando 2
Enhancements around CoAP
bull Advanced congestion control
CoRE WG IETF-86 Orlando 3
New Transports for CoAP
bull Infrastructure for CoAP over foondash httptoolsietforgiddraft-silverajan-core-
coap-alternative-transports-01txtbull CoAP over SMS
ndash httptoolsietforgiddraft-becker-core-coap-sms-gprs-03txt
ndash OMA Lightweightbull CoAP over TCP
ndash httptoolsietforgiddraft-li-core-coap-payload-length-option-01txt
CoRE WG IETF-86 Orlando 4
New support for Web Links
bull JSON Web Linksndash httptoolsietforgiddraft-bormann-core-links-
json-02txt
2332010 CoRE WG IETF-77 Anaheim 5
General application layer solutions
bull Resource Directoryndash httptoolsietforgiddraft-shelby-core-
resource-directory-05txtndash OMA Lightweight
2332010 CoRE WG IETF-77 Anaheim 6
Summary of Changes (34)
n Changes from ietf-04 to ietf-05 n Added a new section 39 (Exceptions) that highlights that IP multicast (and
hence group communications) is not always available (187) n Included guidelines on when (not) to use CoAP responses to multicast
requests and when (not) to accept multicast requests (273) n Added guideline on use of core-block for minimizing response size (275)n Restructured section 6 (Security Considerations) to more fully describe
threats and threat mitigation (277) n Clearly indicated that DNS resolution and reverse DNS lookup are optional n Removed confusing text about a single group having multiple IP addresses
If multiple IP addresses are required then multiple groups (with the same members) should be created
n Removed repetitive text about the fact that group communications is not guaranteed
Summary of Changes (44)
n Changes from ietf-04 to ietf-05 (Continued) n Merged previous section 52 (Multicast Routing) into 31 (IP Multicast
Routing Background) and added link to section 52 (Advertising Membership of Multicast Groups)
n Clarified text in section 38 (Congestion Control) regarding precedence of use of IP multicast domains (ie first try to use link-local scope then site-local scope and only use global IP Communication for CoAP multicast as a last resort)
n Extended group resource manipulation guidelines with use of preconfigured portspaths for the multicast group
n Consolidated all text relating to ports in a new section 33 (Port Configuration)
n Clarified that all methods (GETPUTPOST) for configuring group membership in endpoints should be unicast (and not multicast) in section 37 (Configuring Group Membership In Endpoints)
n Various editorial updates for improved readability
Discussion item (11)
n Solution for Configuring Group Membership (no ticket)n Example of (unicast) configuring an endpoint to be part of one multicast
groupReq POST gp (Content-Format applicationjson)
n floor1westbldg6examplecom ip ff154200f7feed3714cb Res 204 Changed
n Where the ldquogprdquo resource has resource type (rt) ldquocoregprdquo which is defined for this purpose
n Question Do we want specify such a solution (or for example leave it completely up to implementation)
Open Issues(15)
n Review Groupcomm requirements language (271)n Decision made to keep requirements language for informational draftn Each use of MAYMUSTSHOULD etc is to be reviewed
Open Issues(25)
n Add section on multicast via Proxy and its limitations (274)n Add a section to explain the issues amp limitations of doing CoAP multicast
requests via a CoAP Proxy n Goal is to warn and guide implementers in this subject n Also such a section would provide a placeholderreminder of the problems
that might be addressed further in the futuren Based on IETF 85 CoRE WG meeting discussion on Multicast CoAP
requests via a Proxy Discussion summary for referencen Aggregation of responses in a proxy is difficult since it doesnt know
when to stop aggregating responses n SIP tried to deal with this problem but didnt solve it n There may be an expectancy of CoAP client to get single response
back from proxy not multiple The client in this case may not even know what it could expect It may not even know the Proxy-URI contains a multicast target
n Presented via-proxy use case exposes gap in the core-coap specification regarding multicast via proxy (Note Expectation is that core-coap wonrsquot address it in the first planned RFC release)
Open Issues(35)
n Issues with twomultiple Resource Directories in use case (280)n Some potential issues with RD came out of review Peter van der Stok and
WG discussion IETF85 n There are two RD servers use case shows that only one is found despite
the fact that site-local multicast is used - should be two RDs found n Proposal simplify use case to a single RD server on the backbone to avoid
such RD-specific issues like synchronization of RD information between servers
Open Issues(45)
n Add single-subnet configuration to use cases (278)n Suggested by review Peter van der Stok and IETF85 WG discussion that
its best to start explaining the simplebasic cases and then gradually build up complexity
n Simplest case not shown yet would be a single subnet network configuration which is currently not present in the I-D only the 2-subnet configuration of Fig 1
n Question Do we need to add such case or doesnt it add muchn (Note that core-coap Figure 22 already shows the simplest case of link-local
multicast)
Open Issues(55)
n Add use case with controller (client) located on the backbone (279)n Suggested by discussion following review Peter van der Stok n Case missing where a controller (client) is located on the backbonen Question Do we need to add such case or does it add much
Group 2a other old friends
25
Angelo Castellani Salvatore Loreto Akbar Rahman Thomas Fossati Esko Dijk
IETF 86 March 2013httpwwwietforgiddraft-castellani-core-http-mapping-07txt
Best Practices for HTTP-CoAP Mapping
Implementation
Summary of Changes (from -06 rev)
n Based on discussion at last IETF-85 (Atlanta)n Clarification of HTTP-CoAP Proxies
n Definitionn Placementn Benefits
n Clarification of HTTP-CoAP URI mapping options
Goals of I-D
n For Reverse HTTP-CoAP Cross Protocol Proxyn Provide more detailed information to proxy designers (beyond
Section 10 of [I-Dietf-core-coap]) to help implement proxies that correctly inter-work with other CoAP and HTTP clientserver implementations that adhere to the specifications
n Define a consistent set of guidelines that a HTTP-to-CoAP proxy implementation MAY adhere to The main reason of adhering to such guidelines is to reduce variation between proxy implementations thereby increasing interoperabilityn As an example use case a proxy conforming to these guidelines made
by vendor A can be easily replaced by a proxy from vendor B that also conforms to the guidelines
I-D Outline
n Guidance on HTTP to CoAP URI mappingn HTTP-CoAP Reverse cross-protocol proxy implementation
n Placementn Response code amp media type translationsn Caching and congestion controln Cache refresh via Observen Use of CoAP blockwise transfern Security translation
n Security Considerationsn Traffic overflown Handling secured exchanges
Definitions (12)
n Cross-Protocol Proxy (or Cross Proxy) is a proxy performing a cross- protocol mapping in the context of this document a HTTP-CoAP (HC) mapping A Cross-Protocol Proxy can behave as a Forward Proxy Reverse Proxy or Interception Proxy n Note In this document we focus on the Reverse Proxy mode of the
Cross-Protocol Proxy
n Forward Proxy a message forwarding agent that is selected by the client usually via local configuration rules to receive requests for some type(s) of absolute URI and to attempt to satisfy those requests via translation to the protocol indicated by the absolute URI The user decides (is willing to) use the proxy as the forwardingdereferencing agent for a predefined subset of the URI space
Definitions (22)
n Reverse Proxy a receiving agent that acts as a layer above some other server(s) and translates the received requests to the underlying servers protocol It behaves as an origin (HTTP) server on its connection towards the (HTTP) client and as a (CoAP) client on its connection towards the (CoAP) origin server The (HTTP) client uses the origin-form [I-Dietf-httpbis-p1-messaging] as a request- target URI
n Reverse and Forward proxies are technically very similar with main differences being that the former appears to a client as an origin server while the latter does not and that clients may be unaware they are communicating with a proxy
Reverse Cross-Protocol Proxy Deployment Scenario
HTTP-CoAP Response Code Mapping
Implementation Experience
n Direct experience from the draft authorsn Squid HTTP-CoAP mapping module
n University of Padovan httptelecomdeiunipditiotn Both Forward and Interception operation supported
n HTTP-CoAP proxy based on EvCoAPn KoanLogic University of Bologna and Salvatore
Loreto (as individual)n httpsgithubcomkoanlogicwebthingstreemasterbridgesw
libevcoapn The document is open to input from other implementations
Next Steps
n Does the WG recommend adoptionn Intended status Informational Best Practicen Purpose Reduce arbitrary variation between proxy
implementations thereby increasing interoperability
Backup
HTTP to CoAP URI Mapping Options (12)
n Embedded Mapping n In an embedded mapping approach the HTTP URI has embedded
inside it the authority and path part of the CoAP URI n Example The CoAP resource nodecoapsomethingnetfoo can
be accessed by an HTTP client by inserting in the request httphc-proxysomethingnetcoapnodecoapsomethingnetfoo The Cross-Protocol Proxy then maps the URI to coapnodecoapsomethingnetfoo
HTTP to CoAP URI Mapping Options (22)
n Homogeneous Mapping n In a homogeneous mapping approach only the scheme portion of the URI
needs to be mapped The rest of the URI (ie authority path etc) remains unchanged
n Example The CoAP resource coapnodecoapsomethingnetfoo can be accessed by an HTTP client by requesting httpnodecoapsomethingnetfoo The Cross-Protocol Proxy receiving the request is responsible to map the URI to coapnodecoapsomethingnetfoo
n Background info n The assumption in this case is that the HTTP client would be able to
successfully resolve nodecoapsomethingnet using DNS infrastructure to return the IP address of the HC proxy Most likely this would be through a two step DNS lookup where the first DNS lookup would resolve somethingnet using public DNS infrastructure
n Then the second DNS lookup on the subdomain coap and the host node would typically be resolved by a DNS server operated by the owner of domain somethingnet So this domain owner can manage its own internal node names and subdomain allocation which would correspond to the CoAP namespace
Group 3 ldquonew workrdquo
39
Transport of CoAP over SMS USSD and GPRSdraft-becker-core-coap-sms-gprs-03
Markus Becker Kepeng LiKoojana Kuladinithi Thomas Poumltsch
CoRE WG IETF-86 Orlando
1 10
ScenariosI In M2M communication IP connectivity is not alwayssupported by the constrained end-points
I Power savingI Coverage (GPRS 3G LTE)
I SMS and USSD based communication is almost alwayssupported
210
Changes from draft-01 to draft-03 (1)
I Added possible CONNONACK interactions Section 5
I Option name changed from Reply-To- to Response-To-Section 16 and Section 101
I Added URI schemeEg coap+tel+15105550101well-knowncore Section 11
I Added possible M2M proxy scenarios Section 14
3 10
Changes from draft-01 to draft-03 (2)
I Added reference to bormann-coap-misc for other SMSencoding Section 71
I Updated requirements on Uri-Host and Uri-Port forcoap+tel Section 10
I Added security considerations Transport and ObjectSecurity Section 15
I Chose CoAP option numbers and updated the optionnumber table to meet draft-ietf-core-coap-10 Table 1
I Added an IANA registration for the URI scheme coap+telSection 162
4 10
Feedback Split coap+tel into coap+smsand coap+ussd
I How else to differ the various transports in the URII Or is the transport to use decided by the implementationI See alsodraft-silverajan-core-coap-alternative-transports-01
5 10
Feedback Response-To-Scheme option
I Should there be a Response-To-Scheme optionadditionally to Response-To-Uri-Host andResponse-To-Uri-Path
I So that a CoAP end-point which receives a request by CoAPover non-IP transport can be instructed to also use thenon-IP transport for the response
I This would imply to add aResponse-To-Telephone-Subscriber and more options forother transports that have other URI schemes than coapand coaps
6 10
Feedback Selection of Transport by Client
I When a server is reachable by various transports howdoes a client decide which transport to use
I Client-side application congurationI Leave it to a proxy which uses cellular network lookupfunctions
7 10
Feedback Potential Threats
I Trigger expensive short messagesI Redirect trac to other addressesI More threats
I Are the security measures in the draft adequateI Whitelisting on serverI Relying on cellular network security (dedicated M2M APNs)I Object security on CoAP payload
8 10
Feedback Message Exchanges
I Figures 11-18 show possible message exchanges whenclient and server have two addresses
I With NON Not using CoAP retransmission capabilityI ACK on different transportI Additional (costly) message on Transport AI Request with Content
I Which ones are allowedI Which ones are meaningful
9 10
Next steps
I Rene Uri schemeI Response-To-Scheme optionI Selection of Message ExchangeI Rene Proxying
10 10
CoAP13 Communicaon13 with13 Alternave13 Transports
Bill Silverajan and Teemu SavolainenCore WG IETF 86 Orlando
031113
Objecves13 (In13 Scope)
bull Unambiguous13 representaon13 of13 transport13 to13 be13 used13 by13 CoAP
bull Details13 how13 the13 transport13 can13 carry13 CoAP13 packet
bull Focus13 is13 on13 what13 CoAP13 communicaons13 requirements13 are
bull Allow13 CoAP13 mechanisms13 to13 exploit13 cross-shy‐layer13 opmisaons
51
031113
Non13 Goals13 (Not13 in13 scope)
bull Applicaon-shy‐level13 QoS13 requirementsbull Real-shy‐me13 constraintsbull Ordering13 reliability13 congeson13 controlbull Applicaon13 and13 network13 adaptaonbull Mobility13 and13 readdressing13 supportbull Network13 protocol13 (eg13 IPsec)13 configuraon
52
031113
Use13 Cases
bull NAT13 and13 Firewall13 traversal13 with13 TCPbull Delay13 Tolerant13 Networkingbull Non-shy‐IP13 Low13 Energy13 Protocols
53
031113
Related13 Work
bull OMA13 Lightweight13 M2M13 Protocolbull CoAP13 over13 SMSGPRSUSSD
54
031113
What13 does13 the13 work13 entail
bull The13 ability13 to13 specify13 end13 point13 idenfiers13 and13 URIs13 to13 reflect13 which13 transport13 CoAP13 can13 use
bull The13 ability13 to13 register13 to13 resource13 directories13 resource13 types13 reflecng13 types13 of13 transport13 available
bull Ability13 for13 mul-shy‐transport13 nodes13 to13 select13 transport13 to13 use13 without13 significant13 alteraon13 to13 CoAP13 packet13 structure
55
031113
Points13 to13 consider
bull Requirements13 for13 transport13 layer13 protocol13 to13 carry13 CoAP13 packets
bull Representaon13 of13 URI13 scheme13 for13 generic13 transport13 protocols
bull Opon13 extensions13 for13 CoAP13 to13 express13 available13 transports
bull Mapping13 and13 message13 sizebull Security13 consideraons
56
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
URI13 =13 scheme13 13 13 authority13 path-shy‐abempty13 [13 query13 ]
bull Within13 the13 scheme13 namebull In13 the13 URI13 pathbull As13 a13 query13 component
57
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
bull Within13 the13 scheme13 namendash coap+tel+15105550101well-shy‐knowncorendash coap+tcpexamplecom5683temperaturendash coap+blel2cap[1234567890AB]4pulse
bull Easy13 URI13 parsing13 for13 transport13 type13 and13 idenfier
bull Each13 new13 scheme13 name13 requires13 IANA13 registraon
58
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
bull In13 the13 URI13 pathndash coaphostexamplecomtransport=tcpwell-shy‐knowncorert=core-shy‐rd
bull Easy13 adopon13 of13 new13 (and13 experimental)13 CoAP13 transports13 without13 IANA13 registraon
bull Caveat13 Uri-shy‐Path13 opon13 is13 a13 Crical13 CoAP13 opon13 see13 secon13 54113 of13 I-shy‐Diep-shy‐core-shy‐coap
59
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
bull As13 a13 URI13 query13 componentndash coaphostexamplecomwell-shy‐knowncorert=core-shy‐rdq=tcp
bull Also13 easy13 to13 adopt13 new13 (and13 experimental)13 CoAP13 transports13 without13 IANA13 registraon
bull Caveat13 Uri-shy‐Query13 opon13 is13 a13 Crical13 CoAP13 opon13 see13 secon13 54113 of13 I-shy‐Diep-shy‐core-shy‐coap
60
031113
URI13 Representaons13 for13 CoAPNon13 standard13 ways
bull Transport13 in13 the13 URI13 authority13 componentndash coaphost[port][transport]13 instead13 of13 coaphost[port]
bull Transport13 as13 a13 service13 URLndash servicecoaptcphostexamplecomwell-shy‐knowncorert=core-shy‐rd
bull Above13 two13 ways13 break13 exisng13 compability13 (although13 both13 are13 based13 on13 valid13 IANA13 URI13 registraons)
61
031113
URI13 Representaons13 for13 CoAPMiscellaneous13 Consideraons
bull Ensure13 that13 transport13 is13 defined13 unambiguously13 (eg13 L2CAP13 used13 by13 both13 BLE13 and13 standard13 Bluetooth13 so13 avoid13 rdquocoap+l2caprdquo13 or13 rdquotransport=l2caprdquo13 or13 rdquoq=l2caprdquondash Can13 be13 done13 as13 WG13 consensusndash Namespace13 approach13 eg13 rdquocoap+blel2caprdquo13 or13 rdquoq=blel2caprdquo
bull Allow13 end-shy‐points13 to13 use13 CoAP13 Resource13 Directory13 to13 register13 alternave13 transports13 and13 idenfiers13 and13 provide13 periodic13 updatesndash Register13 rdquocore-shy‐transportrdquo13 resource13 type
62
031113
Transport13 Consideraons
bull Uniqueness13 of13 end-shy‐point13 idenficaonbull Communicaon13 support13 Unidireconal13 Bidireconal13 1N13 (broadcast13 mulcast13 anycast)13 messaging
bull Binary13 encoding13 Network13 byte13 orderingbull MTU13 correlaon13 with13 CoAP13 PDU13 sizebull Transport13 latency
63
031113
Security13 Consideraons
bull Drar13 does13 not13 introduce13 new13 security13 requirements13 by13 itself
bull There13 may13 be13 privacy13 issues13 if13 nodes13 use13 telephone13 numbers13 or13 MAC13 addresses13 as13 public13 end13 point13 idenfiers
64
Akbar Rahman
IETF 86 March 2013 httpwwwietforgiddraft-rahman-core-sleepy-02txt
Enhanced Sleepy Node Support for CoAP
Introduction
It is expected that in CoAP networks there will be a certain portion of devices that are sleepy and which may occasionally go into a sleep mode (ie go into a low power state to conserve power) and subsequently have reduced CoAP protocol communication ability
This I-D proposes a minimal and efficient mechanism building on the Resource Directory concept (which will be integrated into a CoAP Proxy) to enhance sleepy node support in CoAP networks
Main Question from IETF-85 (Atlanta)
What performance benefit does the proposed Sleepy Node support solution give in a network that already has standard CoAP caching enabled
Sleepy Node Performance Analysis
Experimental Network
1-5 clients
Both Sleepy and Non-
Sleepy servers
Sleepy Node Performance Analysis Network Setup
CoAPSleepyServer(s)
CoAPSleepAwareReverseProxy
CoAP
Client(s)
Request
Response
Sleep9AwareCoREResourceDirectoryCapability
PublishedSleepParameters
Sleep9AwareCoAPStoreandForwardCapability Response
Request
SleepAwareCoAP503ResponseCapability
CoAPCachingCapability
bull Server supports publishing sleep parameters to proxy bull Eg Irsquom going to be asleep for X seconds
bull Proxy supports sleep-awareness capabilities bull Proxy also supports caching capability based off of maxAge bull Protocol flow similar to approach of Figure 1 (Synchronous RD Based Sleep
Tracking) of I-D
Proxy capabilities can be selectively enableddisabled
Proxy ndash Server Interface
Client ndash Proxy Interface
CoAP Sleep-Aware Reverse Proxy Features CoRE Sleep-aware Resource Directory
Support storing published sleep parameters from CoAP servers sleepState (AWAKE ASLEEP) sleepDuration
Sleep-aware CoAP 503 Response Capability If CoAP request to a sleeping server is received proxy returns a
lsquo503 Retry-Afterrsquo response to client 503 contains a timestamp indicating when the sever will wake back up
(timestamp delivered in CoAP maxAge option) Sleep-aware CoAP Store-and-Forward Capability
If CoAP request to a sleeping server is received proxy stores request until server wakes up and then forwards it
Caching capability Cache GET responses from server if maxAge option is present
(this is not a sleep aware feature)
Goals of Performance Analysis
For networks having sleepy servers provide measurements to quantify the impact that CoAP sleep-awareness capabilities can have
See if sleep-awareness capabilities can
provide additional benefits even when CoAP caching is used
Overview of Performance Analysis Performed The analysis was broken up into a set of test scenarios Each test scenario used a different combination of the following
variables Client issued GET requests Server was configured as a sleepy or non-sleepy server Proxy caching of GET responses was enabled or disabled Proxy sleep-aware 503 response capability was enabled or disabled Proxy store-and-forward capability was enabled or disabled maxAge in GET responses ndash Two values were tested 60sec and 5sec of Clients ndash Two values were used ndash 1 client and 5 clients
For comparison purposes the following were held constant across all test scenarios Client issued a fixed number of requests (100) across all test scenarios Client used a delay between each GET request (35sec) to better exercise
proxyrsquos caching and sleep-awareness capabilities For sleepy server test scenarios the server slept 60 sec awake for 3 sec
Format of Results The following results were collected for each
test scenario
Breakdown of the and types of transactions occurring between clientproxyserver
ldquoGETrdquo ndash Test Scenario Results
GET ndash Description of Test Scenarios
TestScenarios-GET
Scenario
CoAPSleepyServerSe7ngs CoAPSleepAwareReverseProxySe7ngs CoAPClientSe7ngs
SleepDuragton(sec)
AwakeDuragton(sec)
maxAge(sec) Caching SleepAwareSAF+
503NumberofClients
NumberofGETs
DelayBetweenClient
Requests(sec)
1a 0 Always 60 Enabled Disabled 1 100 35
1b 60 3 60 Enabled Disabled 1 100 35
1c 60 3 60 Enabled Enabled 1 100 35
2a 0 Always 60 Enabled Disabled 5 100 35
2b 60 3 60 Enabled Disabled 5 100 35
2c 60 3 60 Enabled Enabled 5 100 35
3a 0 Always 5 Enabled Disabled 5 100 35
3b 60 3 5 Enabled Disabled 5 100 35
3c 60 3 5 Enabled Enabled 5 100 35
ldquoGETrdquo ndash Test Scenario 1 Results
maxAge = 60 and 1 Client
GET ndash Scenario 1 ClientProxy Interface Transaction Mix
Scenarios 1a - Non-Sleepy Server Caching Proxy maxAge = 60sec 1b- Sleepy Server Caching Proxy maxAge = 60sec 1c - Sleepy Server Sleep Aware Proxy maxAge = 60sec
Sleep Aware Proxy has better performance for sleepy servers
0
100
200
300
400
500
600
700
1a 1b 1c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
GET ndash Scenario 1 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
Scenarios 1a - Non-Sleepy Server Caching Proxy maxAge = 60sec 1b- Sleepy Server Caching Proxy maxAge = 60sec 1c - Sleepy Server Sleep Aware Proxy maxAge = 60sec
0
100
200
300
400
500
600
700
800
1a 1b 1c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
ldquoGETrdquo ndash Test Scenario 2 Results
maxAge = 60 and 5 Clients
GET ndash Scenario 2 ClientProxy Interface Transaction Mix
Sleep Aware Proxy has slightly better performance for sleepy servers
0
200
400
600
800
1000
1200
1400
2a 2b 2c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
Scenarios 2a - Non-Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2b- Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2c - Sleepy Server Sleep Aware Proxy maxAge = 60sec 5 Clients
See ldquoExperimental Artifactsrdquo Note 1
GET ndash Scenario 2 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has slightly better performance for sleepy servers
0
50
100
150
200
250
300
350
400
2a 2b 2c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
Scenarios 2a - Non-Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2b- Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2c - Sleepy Server Sleep Aware Proxy maxAge = 60sec 5 Clients
See ldquoExperimental Artifactsrdquo Note 2
Experimental Artifacts Note 1
Currently in the experiment the sleep aware proxy checks the cached state of a resource before putting a request into its Store-and-forward queue while a server is sleeping Once in the queue the proxy unconditionally forwards the queued requests to the server once it wakes up This is not the most efficient setup and can easily be improved If the proxy instead checks its cache again before forwarding each queued request it may not need to forward the request to the server For example if there are two queued GET requests in the proxyrsquos queue that address the same resource Only the first request needs to be sent to the server the second request can use the cached response from the first request
Note 2 Currently in the experiment the sleepy server sends a sleepState PUT request to the
proxy each time it goes to sleep This is not the most efficient setup and can easily be improved For example if the server assumes that the proxy can keep track of its ONOFF cycles with its internal timers (eg as per Fig 1 of I-D) then the number of messages from the sleepy server dramatically goes down
ldquoGETrdquo ndash Test Scenario 3 Results
maxAge = 5 and 5 Clients
GET ndash Scenario 3 ClientProxy Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
Scenarios 3a - Non-Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3b- Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3c - Sleepy Server Sleep Aware Proxy maxAge = 5sec 5 Clients
0
500
1000
1500
2000
2500
3000
3500
4000
4500
5000
3a 3b 3c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
GET ndash Scenario 3 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
0
1000
2000
3000
4000
5000
6000
7000
3a 3b 3c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
Scenarios 3a - Non-Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3b- Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3c - Sleepy Server Sleep Aware Proxy maxAge = 5sec 5 Clients
Conclusions
Conclusions These results show that sleep-aware CoAP
proxy features can significantly optimize communication with sleepy servers in most scenarios
These results also show that sleep-
awareness capabilities can provide additional benefits above and beyond CoAP caching in most scenarios
Backup
Current CoAP Support of Sleepy Node (12)
CoAP proxies can use a previously cached response to service a new GET request for a sleepy origin server (as in HTTP) But if no valid cache then proxy has to attempt to
retrieve and may fail if origin server is sleeping [I-Dietf-core-coap]
Clients can discover list of resources from RD (GET rd-lookuphellip) for sleepy servers But attempt to GET resource from sleepy origin server
may fail if origin server is sleeping [IDietf-core-link-format amp IDshelby-core-resource-
directory]
Current CoAP Support of Sleepy Node (22)
Lower layer support for sleepy nodes in most wireless technologies (eg WiFi ZigBee) But limited to MAC packet scheduling for sleepy nodes
and not aware of specific needs of IP applications (like CoAP)
Proposal ndash RD Based Sleep Tracking (14)
The current CoAP approach to support sleepy nodes can be significantly improved by introducing RD based mechanisms for a CoAP client to determine whether A targeted resource is located on a sleepy server A sleepy server is currently in sleep mode or not
There is any associated caching Proxy (possibly the RD itself) for a sleepy server
Proposal ndash RD Based Sleep Tracking (24)
We define the following new RD attributes to characterize the properties of a sleepy node SleepState - Indicates whether the node is currently in
sleep mode or not (ie Sleeping or Awake) SleepDuration - Indicates the maximum duration of time
that the node stays in sleep mode TimeSleeping - Indicates the length of time the node
has been sleeping (ie if Sleep State = Sleeping) NextSleep - Indicates the next time the node will go to
sleep (ie if Sleep State = Awake)
CachingProxy ndash Indicates the caching proxy of the sleepy node (ie the RD itself or another node)
Proposal ndash RD Based Sleep Tracking (34)
These attributes are all server (node) level and are new parameters added to the RD URI Template Variables
Finally we also define a new lookup-type (ss) for the RD lookup interface specified in [I-Dshelby-core-resource-directory] This new lookup-type supports looking up the
ldquoSleepStaterdquo (ss) of a specified end-point
Proposal ndash RD Based Sleep Tracking (44)
The three time based parameters (SleepDuration TimeSleeping NextSleep) can be based on either an absolute network time (for a time synchronized network) or a relative local time (measured at the local node)
Following the approach of [I-Dietf-core-link-format] and [I-Dshelby-core-resource-directory] sleep parameters for sleepy servers can be stored by the server in the RD and accessed by all interested clients
Examples of using these parameters in a synchronous or asynchronous manner are shown in the I-D
http6lowappnet coreIETF86 2013-03-12-13
We assume people have read the drafts
Meetings serve to advance difficult issues by making good use of face-to-face communications
Note Well Be aware of the IPR principles according to RFC 3979 and its updates
uumlBlue sheetsuumlScribe(s)
96
drar-shy‐iep-shy‐core-shy‐coapsubmiqed13 to13 IESG
2013-shy‐03-shy‐13
97
OMA Lightweight M2M Overview(A new standard using lots of IETF specs including DTLS
CoAP Block Observe Resource Directory SenMLhellip)
Zach ShelbyCoRE WG IETF-86 Orlando
OMA Lightweight M2Mbull Open Mobile Alliance is well known for Device Management (DM)bull OMA Lightweight M2M is a new standard from the alliance
ndash Focused on constrained Cellular and sensor network M2M devicesndash Driven by leading operators and vendors
bull Scopendash Interfaces protocol amp security between Device and Serverndash Object and Resource modelndash Bootstrap Device Access Control Connectivity and Firmware Objects
bull Draft Specifications are availablendash httpmemberopenmobileallianceorgftpPublic_documentsDM
LightweightM2MPermanent_documentsOMA-TS-LightweightM2M-V1_0_0-20130301-Dzip
bull Timelinendash Requirements and Architecture completed 3Q2012ndash Spec ready for Consistency Review 2Q2013ndash Candidate Approval expected 3Q2013
2 CoRE WG IETF-86 Orlando
Architecture
3
Scope of LWM2M
CoRE WG IETF-86 Orlando
Object Model
bull A Client has one or more Object Instancesbull An Object is a collection of Resourcesbull A Resource is an atomic piece of information
ndash Read Written or Executed
bull Resources can have multiple instancesbull Objects and Resources are identified by a
16-bit Integer Instances by an 8-bit Integerbull ObjectsResources are accessed with
simple URIs Object IDObject InstanceResource ID
eg 1213
4 CoRE WG IETF-86 Orlando
CoRE WG IETF-86 Orlando
CoRE Resource Directory
draft-shelby-core-resource-directory-05
Z Shelby C Bormann S Krco
Backgroundbull Not a new concept
ndash think web search engine or any link directorybull Defines the interfaces to a Resource Directorybull Based on Web Linking framework and the CoRE Link Formatbull Generic REST design for use over HTTP and CoAPbull Used by OMA Lightweight M2Mbull Has already been deployed
ndash In traffic monitoring systemsndash In street lighting systemsndash For vehicular asset trackingndash By a major Cellular M2M operator
Changes since -04
bull Restricted Update to parameter updatesbull Added pagination support for the Lookup interfacebull Changed rt= to et= for the registration amp update
interfacebull Added group support
Group Management
bull RD now includes group management featuresbull New Group Function Set
ndash Register a groupbull Group name domain multicast address endpoint members
ndash Remove a groupbull Group lookup using the Lookup Function Set
ndash List registered groupsndash Find the members of a groupndash Find groups with certain endpoints or resources
Registering a Group
EP RD
| |
| - POST rd-groupgp=lights ltgtep=node1 --gt |
| |
| |
| lt---- 201 Created Location rd-group12 ---- |
| |
Req POST coaprdexamplecomrd-groupgp=lights
Payload
ltgtep=node1
ltgtep=node2
Res 201 Created
Location rd-group12
Looking up Group Members
Client RD
| |
| ----- GET rd-lookupepgp=lights1 ----------------------gt |
| |
| |
| lt-- 205 Content ltrdgtd=domain1ltrdgtd=domain2 --------- |
| |
Req GET rd-lookupepgp=lights1
Res 205 Content
ltcoaphostportgtep=node1
ltcoaphostportgtep=node2rdquo
Things for the futurebull Support for JSON representation of Web Links
ndash httptoolsietforgiddraft-bormann-core-links-json-02txtbull Registry for RD registration query parameters
ndash Already OMA Lightweight has defined some new onesbull More examples
Group 3 ldquonew workrdquo(continued)
109
drar-shy‐greevenbosch-shy‐core-shy‐profile-shy‐descripon-shy‐01Bert13 GreevenboschJeroen13 Hoebeke
Isam13 IshaqFloris13 Van13 den13 Abeele
Descripon
bull JSON13 format13 for13 signalling13 the13 servers13 capabilies
bull Signalling13 of13 supported13 opons13 media13 types13 and13 block13 sizendash Other13 items13 can13 be13 added
bull Filtering13 on13 specific13 fields13 through13 URI-shy‐Querybull Link13 hqpdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐profile-shy‐descripon
well-shy‐knownprofile
bull To13 acquire13 profile13 data13 of13 resources13 on13 a13 parcular13 service13 the13 well-shy‐knownprofile13 URI-shy‐path13 is13 introduced
bull For13 example13 to13 get13 all13 informaon13 from13 sensors13 served13 by13 wwwexampleorg13 we13 can13 do13 a13 GET13 to13 coapwwwexampleorgwell-shy‐knownprofile
bull Filtering13 on13 parcular13 resources13 is13 done13 through13 URI-shy‐Queries
Format
bull Currently13 the13 following13 fields13 are13 definedndash ldquopathrdquo13 contains13 the13 URI-shy‐path13 associated13 with13 a13 resource
ndash ldquooprdquo13 a13 numerical13 list13 of13 supported13 opon13 numbers
ndash ldquocfrdquo13 a13 numerical13 list13 of13 supported13 content-shy‐format13 numbers
ndash ldquob1srdquo13 ldquob2srdquo13 supported13 block13 sizes13 for13 Block113 and13 Block213 respecvely
Examplebull On13 the13 right13 is13 an13 example13 of13 a13 camera13 sensor13 at13 coapwwwexampleorgcam13 that13 supports13 the13 Uri-shy‐Host13 (3)13 ETag13 (4)13 Uri-shy‐Port13 (7)13 Uri-shy‐Path13 (11)13 Content-shy‐Format13 (12)13 Token13 (19)13 Block213 (23)13 and13 Proxy-shy‐Uri13 (35)13 opons
bull The13 supported13 content13 formats13 are13 textplain13 (0)13 applicaon13 link-shy‐format13 (40)13 and13 applicaonjson13 (50)
bull The13 supported13 Block213 can13 use13 25613 or13 51213 byte13 blocks
Req13 GET13 coapwwwexampleorgwell-shy‐knownprofile13 Res13 20513 Content13 (applicationjson)13 13 13 13 profile13 13 13 13 13 13 13 13 pathcam13 13 13 13 op[3471112192335]13 13 13 13 13 cf[04050]13 13 13 13 13 b2s[45]13 13 13 13
Filtering13 through13 use13 of13 URI-shy‐Query
bull Filtering13 can13 be13 done13 through13 the13 URI-shy‐Querybull Query13 format13 N=V
ndash N13 is13 a13 profile13 fieldndash V13 is13 the13 desired13 value
bull Examplesndash To13 find13 resources13 that13 support13 content13 format13 ldquoapplicaonjsonrdquo
13 GET13 wwwexampleorgwell-shy‐knownprofilecf=50ndash To13 get13 informaon13 about13 the13 camera
13 GET13 wwwexampleorgwell-shy‐knownprofilepath=cam
Open13 issues
bull Which13 other13 profile13 data13 needs13 signallingndash Content-shy‐type13 for13 different13 methods
bull Fix13 the13 order13 in13 which13 the13 profile13 fields13 must13 appearndash Non-shy‐fixed13 order13 easier13 extensible
bull Inheritance13 of13 a13 profile13 descriponbull Extend13 usage13 to13 signal13 the13 client13 profilebull Integraon13 with13 link13 format
Thank13 youQuesons
drar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval-shy‐00
Bert13 Greevenbosch
Descripon
bull The13 ldquoMinimumRequestInterval13 opon13 can13 be13 used13 to13 indicate13 the13 minimum13 me13 between13 two13 requests13 in13 a13 transacon
bull Originally13 intended13 for13 Block13 but13 also13 usable13 for13 other13 transaconsndash Example13 browsing13 a13 server
bull The13 goal13 is13 to13 reduce13 the13 server13 load13 and13 network13 traffic
bull Link13 hqpsdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval
Usage
bull The13 client13 keeps13 the13 server13 informed13 about13 its13 request13 speed13 through13 inclusion13 of13 the13 ldquoMinimumRequestIntervalrdquo13 opon
bull In13 responses13 the13 server13 fixes13 the13 minimum13 request13 interval13 through13 the13 same13 opon
bull The13 client13 obeys13 the13 speed13 indicated13 by13 the13 server
bull The13 client13 can13 send13 slower13 but13 not13 faster
Advantages
bull The13 server13 has13 means13 to13 limit13 the13 amount13 of13 incoming13 traffic
bull The13 server13 can13 prevent13 to13 become13 overloaded13 with13 too13 many13 tasks
bull The13 server13 does13 not13 need13 arficially13 slow13 down13 the13 client13 by13 sending13 late13 ACKsndash No13 need13 to13 keep13 track13 of13 delayed13 ACKsndash The13 server13 can13 perform13 other13 tasks13 instead
bull Reduced13 network13 traffic
Thank13 youQuesons
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-links-json-02txt
123
RFC 6690 (link-format) documents are somewhat foreign to many web app developerssect would prefer to have them in JSON format
There is no standard way to represent link-format documents in applicationssect but everyone knows how to handle JSON
Define a standard JSON translation for link-format
Itrsquos
not
rock
et
scien
ce
ltsensorsgtct=40title=Sensor Index ltsensorstempgtrt=temperature-cif=sensor ltsensorslightgtrt=light-luxif=sensor lthttpwwwexamplecomsensorst123gt anchor=sensorstemprel=describedby lttgtanchor=sensorstemprel=alternate [hrefsensorsct40titleSensor Index hrefsensorstemprttemperature-cifsensor hrefsensorslightrtlight-luxifsensor hrefhttpwwwexamplecomsensorst123 anchorsensorstempreldescribedby hreftanchorsensorstemprelalternate]
124
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-ipsec-for-coap-00txt
IPsec definitions for CoAP Mostly placeholder at this time Who has implementation experience with this
125
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-cross-reverse-convention-00txt
This draft has two lines of payload(based on a WGLC comment by Cullen Jennings)
coap12344567foobara=3
httpwwwproxycomwellknowncore-translate1234_4567foobara=3
Is that a useful convention to have
126
Insert CI slides here
127
128
0
5
10
15
20
25
30
35
40
10 20 30 40 50 60 70
good
put (
pps)
pps
Goodput vs pps (Econotags)
goodput
[Khattak preliminary]
Congestion Control
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-cocoa-00txt
ldquoadvancedrdquo cc (The draft is just a first shot) Others may have better ideas
129
Insert post-WGLC discussion slides here
130
Stop Continue Start
131
An Agile Retrospective
http6lowappnet coreIETF86 2013-03-12-13
Stop
132
Endless new CoAP optionssect instead use RESTful as much as possible
Move general security lifecycle out Looking at theoretical problems
http6lowappnet coreIETF86 2013-03-12-13
Continue
Interops Running code Look at real-world examples and deployments Solve their actual problems
sect Unilateral enhancements eg higher performance congestion control
sect Transports (SMS hellip)sect Make Web linking and Directories more and more usefulsect RESTful Design Paradigms for real-world problems
133
http6lowappnet coreIETF86 2013-03-12-13
Start
Further push into the (browser) web world (HTML5 browser security)
Specific supporting worksect SenMLsect URI work (dev URN hellip)sect Security Processes (next slide)
Spin outsect (We donrsquot really get to decide where this is done)
134
http6lowappnet coreIETF86 2013-03-12-13
Security
Integrate Application Network Group Keyingsect Tunnel-free setup
Donrsquot redo what has been done alreadysect ZigBee IP is finesect But what about other scenarios
Simple REST interfaces for working with keying materials and authorizationsect Start with defining objectives
Object Security for Constrained Nodes135
Re-chartering CoREWhat do we want to do now that wersquore grown up
Zach ShelbyCoRE WG IETF-86 Orlando
What is the scope
bull So we have a protocol and Web Linking what next
bull Keep with what we know besthellip1 Enhancements around CoAP2 New transports for CoAP3 New representations for Web Links4 General application layer solutions
CoRE WG IETF-86 Orlando 2
Enhancements around CoAP
bull Advanced congestion control
CoRE WG IETF-86 Orlando 3
New Transports for CoAP
bull Infrastructure for CoAP over foondash httptoolsietforgiddraft-silverajan-core-
coap-alternative-transports-01txtbull CoAP over SMS
ndash httptoolsietforgiddraft-becker-core-coap-sms-gprs-03txt
ndash OMA Lightweightbull CoAP over TCP
ndash httptoolsietforgiddraft-li-core-coap-payload-length-option-01txt
CoRE WG IETF-86 Orlando 4
New support for Web Links
bull JSON Web Linksndash httptoolsietforgiddraft-bormann-core-links-
json-02txt
2332010 CoRE WG IETF-77 Anaheim 5
General application layer solutions
bull Resource Directoryndash httptoolsietforgiddraft-shelby-core-
resource-directory-05txtndash OMA Lightweight
2332010 CoRE WG IETF-77 Anaheim 6
Summary of Changes (44)
n Changes from ietf-04 to ietf-05 (Continued) n Merged previous section 52 (Multicast Routing) into 31 (IP Multicast
Routing Background) and added link to section 52 (Advertising Membership of Multicast Groups)
n Clarified text in section 38 (Congestion Control) regarding precedence of use of IP multicast domains (ie first try to use link-local scope then site-local scope and only use global IP Communication for CoAP multicast as a last resort)
n Extended group resource manipulation guidelines with use of preconfigured portspaths for the multicast group
n Consolidated all text relating to ports in a new section 33 (Port Configuration)
n Clarified that all methods (GETPUTPOST) for configuring group membership in endpoints should be unicast (and not multicast) in section 37 (Configuring Group Membership In Endpoints)
n Various editorial updates for improved readability
Discussion item (11)
n Solution for Configuring Group Membership (no ticket)n Example of (unicast) configuring an endpoint to be part of one multicast
groupReq POST gp (Content-Format applicationjson)
n floor1westbldg6examplecom ip ff154200f7feed3714cb Res 204 Changed
n Where the ldquogprdquo resource has resource type (rt) ldquocoregprdquo which is defined for this purpose
n Question Do we want specify such a solution (or for example leave it completely up to implementation)
Open Issues(15)
n Review Groupcomm requirements language (271)n Decision made to keep requirements language for informational draftn Each use of MAYMUSTSHOULD etc is to be reviewed
Open Issues(25)
n Add section on multicast via Proxy and its limitations (274)n Add a section to explain the issues amp limitations of doing CoAP multicast
requests via a CoAP Proxy n Goal is to warn and guide implementers in this subject n Also such a section would provide a placeholderreminder of the problems
that might be addressed further in the futuren Based on IETF 85 CoRE WG meeting discussion on Multicast CoAP
requests via a Proxy Discussion summary for referencen Aggregation of responses in a proxy is difficult since it doesnt know
when to stop aggregating responses n SIP tried to deal with this problem but didnt solve it n There may be an expectancy of CoAP client to get single response
back from proxy not multiple The client in this case may not even know what it could expect It may not even know the Proxy-URI contains a multicast target
n Presented via-proxy use case exposes gap in the core-coap specification regarding multicast via proxy (Note Expectation is that core-coap wonrsquot address it in the first planned RFC release)
Open Issues(35)
n Issues with twomultiple Resource Directories in use case (280)n Some potential issues with RD came out of review Peter van der Stok and
WG discussion IETF85 n There are two RD servers use case shows that only one is found despite
the fact that site-local multicast is used - should be two RDs found n Proposal simplify use case to a single RD server on the backbone to avoid
such RD-specific issues like synchronization of RD information between servers
Open Issues(45)
n Add single-subnet configuration to use cases (278)n Suggested by review Peter van der Stok and IETF85 WG discussion that
its best to start explaining the simplebasic cases and then gradually build up complexity
n Simplest case not shown yet would be a single subnet network configuration which is currently not present in the I-D only the 2-subnet configuration of Fig 1
n Question Do we need to add such case or doesnt it add muchn (Note that core-coap Figure 22 already shows the simplest case of link-local
multicast)
Open Issues(55)
n Add use case with controller (client) located on the backbone (279)n Suggested by discussion following review Peter van der Stok n Case missing where a controller (client) is located on the backbonen Question Do we need to add such case or does it add much
Group 2a other old friends
25
Angelo Castellani Salvatore Loreto Akbar Rahman Thomas Fossati Esko Dijk
IETF 86 March 2013httpwwwietforgiddraft-castellani-core-http-mapping-07txt
Best Practices for HTTP-CoAP Mapping
Implementation
Summary of Changes (from -06 rev)
n Based on discussion at last IETF-85 (Atlanta)n Clarification of HTTP-CoAP Proxies
n Definitionn Placementn Benefits
n Clarification of HTTP-CoAP URI mapping options
Goals of I-D
n For Reverse HTTP-CoAP Cross Protocol Proxyn Provide more detailed information to proxy designers (beyond
Section 10 of [I-Dietf-core-coap]) to help implement proxies that correctly inter-work with other CoAP and HTTP clientserver implementations that adhere to the specifications
n Define a consistent set of guidelines that a HTTP-to-CoAP proxy implementation MAY adhere to The main reason of adhering to such guidelines is to reduce variation between proxy implementations thereby increasing interoperabilityn As an example use case a proxy conforming to these guidelines made
by vendor A can be easily replaced by a proxy from vendor B that also conforms to the guidelines
I-D Outline
n Guidance on HTTP to CoAP URI mappingn HTTP-CoAP Reverse cross-protocol proxy implementation
n Placementn Response code amp media type translationsn Caching and congestion controln Cache refresh via Observen Use of CoAP blockwise transfern Security translation
n Security Considerationsn Traffic overflown Handling secured exchanges
Definitions (12)
n Cross-Protocol Proxy (or Cross Proxy) is a proxy performing a cross- protocol mapping in the context of this document a HTTP-CoAP (HC) mapping A Cross-Protocol Proxy can behave as a Forward Proxy Reverse Proxy or Interception Proxy n Note In this document we focus on the Reverse Proxy mode of the
Cross-Protocol Proxy
n Forward Proxy a message forwarding agent that is selected by the client usually via local configuration rules to receive requests for some type(s) of absolute URI and to attempt to satisfy those requests via translation to the protocol indicated by the absolute URI The user decides (is willing to) use the proxy as the forwardingdereferencing agent for a predefined subset of the URI space
Definitions (22)
n Reverse Proxy a receiving agent that acts as a layer above some other server(s) and translates the received requests to the underlying servers protocol It behaves as an origin (HTTP) server on its connection towards the (HTTP) client and as a (CoAP) client on its connection towards the (CoAP) origin server The (HTTP) client uses the origin-form [I-Dietf-httpbis-p1-messaging] as a request- target URI
n Reverse and Forward proxies are technically very similar with main differences being that the former appears to a client as an origin server while the latter does not and that clients may be unaware they are communicating with a proxy
Reverse Cross-Protocol Proxy Deployment Scenario
HTTP-CoAP Response Code Mapping
Implementation Experience
n Direct experience from the draft authorsn Squid HTTP-CoAP mapping module
n University of Padovan httptelecomdeiunipditiotn Both Forward and Interception operation supported
n HTTP-CoAP proxy based on EvCoAPn KoanLogic University of Bologna and Salvatore
Loreto (as individual)n httpsgithubcomkoanlogicwebthingstreemasterbridgesw
libevcoapn The document is open to input from other implementations
Next Steps
n Does the WG recommend adoptionn Intended status Informational Best Practicen Purpose Reduce arbitrary variation between proxy
implementations thereby increasing interoperability
Backup
HTTP to CoAP URI Mapping Options (12)
n Embedded Mapping n In an embedded mapping approach the HTTP URI has embedded
inside it the authority and path part of the CoAP URI n Example The CoAP resource nodecoapsomethingnetfoo can
be accessed by an HTTP client by inserting in the request httphc-proxysomethingnetcoapnodecoapsomethingnetfoo The Cross-Protocol Proxy then maps the URI to coapnodecoapsomethingnetfoo
HTTP to CoAP URI Mapping Options (22)
n Homogeneous Mapping n In a homogeneous mapping approach only the scheme portion of the URI
needs to be mapped The rest of the URI (ie authority path etc) remains unchanged
n Example The CoAP resource coapnodecoapsomethingnetfoo can be accessed by an HTTP client by requesting httpnodecoapsomethingnetfoo The Cross-Protocol Proxy receiving the request is responsible to map the URI to coapnodecoapsomethingnetfoo
n Background info n The assumption in this case is that the HTTP client would be able to
successfully resolve nodecoapsomethingnet using DNS infrastructure to return the IP address of the HC proxy Most likely this would be through a two step DNS lookup where the first DNS lookup would resolve somethingnet using public DNS infrastructure
n Then the second DNS lookup on the subdomain coap and the host node would typically be resolved by a DNS server operated by the owner of domain somethingnet So this domain owner can manage its own internal node names and subdomain allocation which would correspond to the CoAP namespace
Group 3 ldquonew workrdquo
39
Transport of CoAP over SMS USSD and GPRSdraft-becker-core-coap-sms-gprs-03
Markus Becker Kepeng LiKoojana Kuladinithi Thomas Poumltsch
CoRE WG IETF-86 Orlando
1 10
ScenariosI In M2M communication IP connectivity is not alwayssupported by the constrained end-points
I Power savingI Coverage (GPRS 3G LTE)
I SMS and USSD based communication is almost alwayssupported
210
Changes from draft-01 to draft-03 (1)
I Added possible CONNONACK interactions Section 5
I Option name changed from Reply-To- to Response-To-Section 16 and Section 101
I Added URI schemeEg coap+tel+15105550101well-knowncore Section 11
I Added possible M2M proxy scenarios Section 14
3 10
Changes from draft-01 to draft-03 (2)
I Added reference to bormann-coap-misc for other SMSencoding Section 71
I Updated requirements on Uri-Host and Uri-Port forcoap+tel Section 10
I Added security considerations Transport and ObjectSecurity Section 15
I Chose CoAP option numbers and updated the optionnumber table to meet draft-ietf-core-coap-10 Table 1
I Added an IANA registration for the URI scheme coap+telSection 162
4 10
Feedback Split coap+tel into coap+smsand coap+ussd
I How else to differ the various transports in the URII Or is the transport to use decided by the implementationI See alsodraft-silverajan-core-coap-alternative-transports-01
5 10
Feedback Response-To-Scheme option
I Should there be a Response-To-Scheme optionadditionally to Response-To-Uri-Host andResponse-To-Uri-Path
I So that a CoAP end-point which receives a request by CoAPover non-IP transport can be instructed to also use thenon-IP transport for the response
I This would imply to add aResponse-To-Telephone-Subscriber and more options forother transports that have other URI schemes than coapand coaps
6 10
Feedback Selection of Transport by Client
I When a server is reachable by various transports howdoes a client decide which transport to use
I Client-side application congurationI Leave it to a proxy which uses cellular network lookupfunctions
7 10
Feedback Potential Threats
I Trigger expensive short messagesI Redirect trac to other addressesI More threats
I Are the security measures in the draft adequateI Whitelisting on serverI Relying on cellular network security (dedicated M2M APNs)I Object security on CoAP payload
8 10
Feedback Message Exchanges
I Figures 11-18 show possible message exchanges whenclient and server have two addresses
I With NON Not using CoAP retransmission capabilityI ACK on different transportI Additional (costly) message on Transport AI Request with Content
I Which ones are allowedI Which ones are meaningful
9 10
Next steps
I Rene Uri schemeI Response-To-Scheme optionI Selection of Message ExchangeI Rene Proxying
10 10
CoAP13 Communicaon13 with13 Alternave13 Transports
Bill Silverajan and Teemu SavolainenCore WG IETF 86 Orlando
031113
Objecves13 (In13 Scope)
bull Unambiguous13 representaon13 of13 transport13 to13 be13 used13 by13 CoAP
bull Details13 how13 the13 transport13 can13 carry13 CoAP13 packet
bull Focus13 is13 on13 what13 CoAP13 communicaons13 requirements13 are
bull Allow13 CoAP13 mechanisms13 to13 exploit13 cross-shy‐layer13 opmisaons
51
031113
Non13 Goals13 (Not13 in13 scope)
bull Applicaon-shy‐level13 QoS13 requirementsbull Real-shy‐me13 constraintsbull Ordering13 reliability13 congeson13 controlbull Applicaon13 and13 network13 adaptaonbull Mobility13 and13 readdressing13 supportbull Network13 protocol13 (eg13 IPsec)13 configuraon
52
031113
Use13 Cases
bull NAT13 and13 Firewall13 traversal13 with13 TCPbull Delay13 Tolerant13 Networkingbull Non-shy‐IP13 Low13 Energy13 Protocols
53
031113
Related13 Work
bull OMA13 Lightweight13 M2M13 Protocolbull CoAP13 over13 SMSGPRSUSSD
54
031113
What13 does13 the13 work13 entail
bull The13 ability13 to13 specify13 end13 point13 idenfiers13 and13 URIs13 to13 reflect13 which13 transport13 CoAP13 can13 use
bull The13 ability13 to13 register13 to13 resource13 directories13 resource13 types13 reflecng13 types13 of13 transport13 available
bull Ability13 for13 mul-shy‐transport13 nodes13 to13 select13 transport13 to13 use13 without13 significant13 alteraon13 to13 CoAP13 packet13 structure
55
031113
Points13 to13 consider
bull Requirements13 for13 transport13 layer13 protocol13 to13 carry13 CoAP13 packets
bull Representaon13 of13 URI13 scheme13 for13 generic13 transport13 protocols
bull Opon13 extensions13 for13 CoAP13 to13 express13 available13 transports
bull Mapping13 and13 message13 sizebull Security13 consideraons
56
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
URI13 =13 scheme13 13 13 authority13 path-shy‐abempty13 [13 query13 ]
bull Within13 the13 scheme13 namebull In13 the13 URI13 pathbull As13 a13 query13 component
57
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
bull Within13 the13 scheme13 namendash coap+tel+15105550101well-shy‐knowncorendash coap+tcpexamplecom5683temperaturendash coap+blel2cap[1234567890AB]4pulse
bull Easy13 URI13 parsing13 for13 transport13 type13 and13 idenfier
bull Each13 new13 scheme13 name13 requires13 IANA13 registraon
58
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
bull In13 the13 URI13 pathndash coaphostexamplecomtransport=tcpwell-shy‐knowncorert=core-shy‐rd
bull Easy13 adopon13 of13 new13 (and13 experimental)13 CoAP13 transports13 without13 IANA13 registraon
bull Caveat13 Uri-shy‐Path13 opon13 is13 a13 Crical13 CoAP13 opon13 see13 secon13 54113 of13 I-shy‐Diep-shy‐core-shy‐coap
59
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
bull As13 a13 URI13 query13 componentndash coaphostexamplecomwell-shy‐knowncorert=core-shy‐rdq=tcp
bull Also13 easy13 to13 adopt13 new13 (and13 experimental)13 CoAP13 transports13 without13 IANA13 registraon
bull Caveat13 Uri-shy‐Query13 opon13 is13 a13 Crical13 CoAP13 opon13 see13 secon13 54113 of13 I-shy‐Diep-shy‐core-shy‐coap
60
031113
URI13 Representaons13 for13 CoAPNon13 standard13 ways
bull Transport13 in13 the13 URI13 authority13 componentndash coaphost[port][transport]13 instead13 of13 coaphost[port]
bull Transport13 as13 a13 service13 URLndash servicecoaptcphostexamplecomwell-shy‐knowncorert=core-shy‐rd
bull Above13 two13 ways13 break13 exisng13 compability13 (although13 both13 are13 based13 on13 valid13 IANA13 URI13 registraons)
61
031113
URI13 Representaons13 for13 CoAPMiscellaneous13 Consideraons
bull Ensure13 that13 transport13 is13 defined13 unambiguously13 (eg13 L2CAP13 used13 by13 both13 BLE13 and13 standard13 Bluetooth13 so13 avoid13 rdquocoap+l2caprdquo13 or13 rdquotransport=l2caprdquo13 or13 rdquoq=l2caprdquondash Can13 be13 done13 as13 WG13 consensusndash Namespace13 approach13 eg13 rdquocoap+blel2caprdquo13 or13 rdquoq=blel2caprdquo
bull Allow13 end-shy‐points13 to13 use13 CoAP13 Resource13 Directory13 to13 register13 alternave13 transports13 and13 idenfiers13 and13 provide13 periodic13 updatesndash Register13 rdquocore-shy‐transportrdquo13 resource13 type
62
031113
Transport13 Consideraons
bull Uniqueness13 of13 end-shy‐point13 idenficaonbull Communicaon13 support13 Unidireconal13 Bidireconal13 1N13 (broadcast13 mulcast13 anycast)13 messaging
bull Binary13 encoding13 Network13 byte13 orderingbull MTU13 correlaon13 with13 CoAP13 PDU13 sizebull Transport13 latency
63
031113
Security13 Consideraons
bull Drar13 does13 not13 introduce13 new13 security13 requirements13 by13 itself
bull There13 may13 be13 privacy13 issues13 if13 nodes13 use13 telephone13 numbers13 or13 MAC13 addresses13 as13 public13 end13 point13 idenfiers
64
Akbar Rahman
IETF 86 March 2013 httpwwwietforgiddraft-rahman-core-sleepy-02txt
Enhanced Sleepy Node Support for CoAP
Introduction
It is expected that in CoAP networks there will be a certain portion of devices that are sleepy and which may occasionally go into a sleep mode (ie go into a low power state to conserve power) and subsequently have reduced CoAP protocol communication ability
This I-D proposes a minimal and efficient mechanism building on the Resource Directory concept (which will be integrated into a CoAP Proxy) to enhance sleepy node support in CoAP networks
Main Question from IETF-85 (Atlanta)
What performance benefit does the proposed Sleepy Node support solution give in a network that already has standard CoAP caching enabled
Sleepy Node Performance Analysis
Experimental Network
1-5 clients
Both Sleepy and Non-
Sleepy servers
Sleepy Node Performance Analysis Network Setup
CoAPSleepyServer(s)
CoAPSleepAwareReverseProxy
CoAP
Client(s)
Request
Response
Sleep9AwareCoREResourceDirectoryCapability
PublishedSleepParameters
Sleep9AwareCoAPStoreandForwardCapability Response
Request
SleepAwareCoAP503ResponseCapability
CoAPCachingCapability
bull Server supports publishing sleep parameters to proxy bull Eg Irsquom going to be asleep for X seconds
bull Proxy supports sleep-awareness capabilities bull Proxy also supports caching capability based off of maxAge bull Protocol flow similar to approach of Figure 1 (Synchronous RD Based Sleep
Tracking) of I-D
Proxy capabilities can be selectively enableddisabled
Proxy ndash Server Interface
Client ndash Proxy Interface
CoAP Sleep-Aware Reverse Proxy Features CoRE Sleep-aware Resource Directory
Support storing published sleep parameters from CoAP servers sleepState (AWAKE ASLEEP) sleepDuration
Sleep-aware CoAP 503 Response Capability If CoAP request to a sleeping server is received proxy returns a
lsquo503 Retry-Afterrsquo response to client 503 contains a timestamp indicating when the sever will wake back up
(timestamp delivered in CoAP maxAge option) Sleep-aware CoAP Store-and-Forward Capability
If CoAP request to a sleeping server is received proxy stores request until server wakes up and then forwards it
Caching capability Cache GET responses from server if maxAge option is present
(this is not a sleep aware feature)
Goals of Performance Analysis
For networks having sleepy servers provide measurements to quantify the impact that CoAP sleep-awareness capabilities can have
See if sleep-awareness capabilities can
provide additional benefits even when CoAP caching is used
Overview of Performance Analysis Performed The analysis was broken up into a set of test scenarios Each test scenario used a different combination of the following
variables Client issued GET requests Server was configured as a sleepy or non-sleepy server Proxy caching of GET responses was enabled or disabled Proxy sleep-aware 503 response capability was enabled or disabled Proxy store-and-forward capability was enabled or disabled maxAge in GET responses ndash Two values were tested 60sec and 5sec of Clients ndash Two values were used ndash 1 client and 5 clients
For comparison purposes the following were held constant across all test scenarios Client issued a fixed number of requests (100) across all test scenarios Client used a delay between each GET request (35sec) to better exercise
proxyrsquos caching and sleep-awareness capabilities For sleepy server test scenarios the server slept 60 sec awake for 3 sec
Format of Results The following results were collected for each
test scenario
Breakdown of the and types of transactions occurring between clientproxyserver
ldquoGETrdquo ndash Test Scenario Results
GET ndash Description of Test Scenarios
TestScenarios-GET
Scenario
CoAPSleepyServerSe7ngs CoAPSleepAwareReverseProxySe7ngs CoAPClientSe7ngs
SleepDuragton(sec)
AwakeDuragton(sec)
maxAge(sec) Caching SleepAwareSAF+
503NumberofClients
NumberofGETs
DelayBetweenClient
Requests(sec)
1a 0 Always 60 Enabled Disabled 1 100 35
1b 60 3 60 Enabled Disabled 1 100 35
1c 60 3 60 Enabled Enabled 1 100 35
2a 0 Always 60 Enabled Disabled 5 100 35
2b 60 3 60 Enabled Disabled 5 100 35
2c 60 3 60 Enabled Enabled 5 100 35
3a 0 Always 5 Enabled Disabled 5 100 35
3b 60 3 5 Enabled Disabled 5 100 35
3c 60 3 5 Enabled Enabled 5 100 35
ldquoGETrdquo ndash Test Scenario 1 Results
maxAge = 60 and 1 Client
GET ndash Scenario 1 ClientProxy Interface Transaction Mix
Scenarios 1a - Non-Sleepy Server Caching Proxy maxAge = 60sec 1b- Sleepy Server Caching Proxy maxAge = 60sec 1c - Sleepy Server Sleep Aware Proxy maxAge = 60sec
Sleep Aware Proxy has better performance for sleepy servers
0
100
200
300
400
500
600
700
1a 1b 1c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
GET ndash Scenario 1 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
Scenarios 1a - Non-Sleepy Server Caching Proxy maxAge = 60sec 1b- Sleepy Server Caching Proxy maxAge = 60sec 1c - Sleepy Server Sleep Aware Proxy maxAge = 60sec
0
100
200
300
400
500
600
700
800
1a 1b 1c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
ldquoGETrdquo ndash Test Scenario 2 Results
maxAge = 60 and 5 Clients
GET ndash Scenario 2 ClientProxy Interface Transaction Mix
Sleep Aware Proxy has slightly better performance for sleepy servers
0
200
400
600
800
1000
1200
1400
2a 2b 2c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
Scenarios 2a - Non-Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2b- Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2c - Sleepy Server Sleep Aware Proxy maxAge = 60sec 5 Clients
See ldquoExperimental Artifactsrdquo Note 1
GET ndash Scenario 2 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has slightly better performance for sleepy servers
0
50
100
150
200
250
300
350
400
2a 2b 2c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
Scenarios 2a - Non-Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2b- Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2c - Sleepy Server Sleep Aware Proxy maxAge = 60sec 5 Clients
See ldquoExperimental Artifactsrdquo Note 2
Experimental Artifacts Note 1
Currently in the experiment the sleep aware proxy checks the cached state of a resource before putting a request into its Store-and-forward queue while a server is sleeping Once in the queue the proxy unconditionally forwards the queued requests to the server once it wakes up This is not the most efficient setup and can easily be improved If the proxy instead checks its cache again before forwarding each queued request it may not need to forward the request to the server For example if there are two queued GET requests in the proxyrsquos queue that address the same resource Only the first request needs to be sent to the server the second request can use the cached response from the first request
Note 2 Currently in the experiment the sleepy server sends a sleepState PUT request to the
proxy each time it goes to sleep This is not the most efficient setup and can easily be improved For example if the server assumes that the proxy can keep track of its ONOFF cycles with its internal timers (eg as per Fig 1 of I-D) then the number of messages from the sleepy server dramatically goes down
ldquoGETrdquo ndash Test Scenario 3 Results
maxAge = 5 and 5 Clients
GET ndash Scenario 3 ClientProxy Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
Scenarios 3a - Non-Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3b- Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3c - Sleepy Server Sleep Aware Proxy maxAge = 5sec 5 Clients
0
500
1000
1500
2000
2500
3000
3500
4000
4500
5000
3a 3b 3c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
GET ndash Scenario 3 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
0
1000
2000
3000
4000
5000
6000
7000
3a 3b 3c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
Scenarios 3a - Non-Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3b- Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3c - Sleepy Server Sleep Aware Proxy maxAge = 5sec 5 Clients
Conclusions
Conclusions These results show that sleep-aware CoAP
proxy features can significantly optimize communication with sleepy servers in most scenarios
These results also show that sleep-
awareness capabilities can provide additional benefits above and beyond CoAP caching in most scenarios
Backup
Current CoAP Support of Sleepy Node (12)
CoAP proxies can use a previously cached response to service a new GET request for a sleepy origin server (as in HTTP) But if no valid cache then proxy has to attempt to
retrieve and may fail if origin server is sleeping [I-Dietf-core-coap]
Clients can discover list of resources from RD (GET rd-lookuphellip) for sleepy servers But attempt to GET resource from sleepy origin server
may fail if origin server is sleeping [IDietf-core-link-format amp IDshelby-core-resource-
directory]
Current CoAP Support of Sleepy Node (22)
Lower layer support for sleepy nodes in most wireless technologies (eg WiFi ZigBee) But limited to MAC packet scheduling for sleepy nodes
and not aware of specific needs of IP applications (like CoAP)
Proposal ndash RD Based Sleep Tracking (14)
The current CoAP approach to support sleepy nodes can be significantly improved by introducing RD based mechanisms for a CoAP client to determine whether A targeted resource is located on a sleepy server A sleepy server is currently in sleep mode or not
There is any associated caching Proxy (possibly the RD itself) for a sleepy server
Proposal ndash RD Based Sleep Tracking (24)
We define the following new RD attributes to characterize the properties of a sleepy node SleepState - Indicates whether the node is currently in
sleep mode or not (ie Sleeping or Awake) SleepDuration - Indicates the maximum duration of time
that the node stays in sleep mode TimeSleeping - Indicates the length of time the node
has been sleeping (ie if Sleep State = Sleeping) NextSleep - Indicates the next time the node will go to
sleep (ie if Sleep State = Awake)
CachingProxy ndash Indicates the caching proxy of the sleepy node (ie the RD itself or another node)
Proposal ndash RD Based Sleep Tracking (34)
These attributes are all server (node) level and are new parameters added to the RD URI Template Variables
Finally we also define a new lookup-type (ss) for the RD lookup interface specified in [I-Dshelby-core-resource-directory] This new lookup-type supports looking up the
ldquoSleepStaterdquo (ss) of a specified end-point
Proposal ndash RD Based Sleep Tracking (44)
The three time based parameters (SleepDuration TimeSleeping NextSleep) can be based on either an absolute network time (for a time synchronized network) or a relative local time (measured at the local node)
Following the approach of [I-Dietf-core-link-format] and [I-Dshelby-core-resource-directory] sleep parameters for sleepy servers can be stored by the server in the RD and accessed by all interested clients
Examples of using these parameters in a synchronous or asynchronous manner are shown in the I-D
http6lowappnet coreIETF86 2013-03-12-13
We assume people have read the drafts
Meetings serve to advance difficult issues by making good use of face-to-face communications
Note Well Be aware of the IPR principles according to RFC 3979 and its updates
uumlBlue sheetsuumlScribe(s)
96
drar-shy‐iep-shy‐core-shy‐coapsubmiqed13 to13 IESG
2013-shy‐03-shy‐13
97
OMA Lightweight M2M Overview(A new standard using lots of IETF specs including DTLS
CoAP Block Observe Resource Directory SenMLhellip)
Zach ShelbyCoRE WG IETF-86 Orlando
OMA Lightweight M2Mbull Open Mobile Alliance is well known for Device Management (DM)bull OMA Lightweight M2M is a new standard from the alliance
ndash Focused on constrained Cellular and sensor network M2M devicesndash Driven by leading operators and vendors
bull Scopendash Interfaces protocol amp security between Device and Serverndash Object and Resource modelndash Bootstrap Device Access Control Connectivity and Firmware Objects
bull Draft Specifications are availablendash httpmemberopenmobileallianceorgftpPublic_documentsDM
LightweightM2MPermanent_documentsOMA-TS-LightweightM2M-V1_0_0-20130301-Dzip
bull Timelinendash Requirements and Architecture completed 3Q2012ndash Spec ready for Consistency Review 2Q2013ndash Candidate Approval expected 3Q2013
2 CoRE WG IETF-86 Orlando
Architecture
3
Scope of LWM2M
CoRE WG IETF-86 Orlando
Object Model
bull A Client has one or more Object Instancesbull An Object is a collection of Resourcesbull A Resource is an atomic piece of information
ndash Read Written or Executed
bull Resources can have multiple instancesbull Objects and Resources are identified by a
16-bit Integer Instances by an 8-bit Integerbull ObjectsResources are accessed with
simple URIs Object IDObject InstanceResource ID
eg 1213
4 CoRE WG IETF-86 Orlando
CoRE WG IETF-86 Orlando
CoRE Resource Directory
draft-shelby-core-resource-directory-05
Z Shelby C Bormann S Krco
Backgroundbull Not a new concept
ndash think web search engine or any link directorybull Defines the interfaces to a Resource Directorybull Based on Web Linking framework and the CoRE Link Formatbull Generic REST design for use over HTTP and CoAPbull Used by OMA Lightweight M2Mbull Has already been deployed
ndash In traffic monitoring systemsndash In street lighting systemsndash For vehicular asset trackingndash By a major Cellular M2M operator
Changes since -04
bull Restricted Update to parameter updatesbull Added pagination support for the Lookup interfacebull Changed rt= to et= for the registration amp update
interfacebull Added group support
Group Management
bull RD now includes group management featuresbull New Group Function Set
ndash Register a groupbull Group name domain multicast address endpoint members
ndash Remove a groupbull Group lookup using the Lookup Function Set
ndash List registered groupsndash Find the members of a groupndash Find groups with certain endpoints or resources
Registering a Group
EP RD
| |
| - POST rd-groupgp=lights ltgtep=node1 --gt |
| |
| |
| lt---- 201 Created Location rd-group12 ---- |
| |
Req POST coaprdexamplecomrd-groupgp=lights
Payload
ltgtep=node1
ltgtep=node2
Res 201 Created
Location rd-group12
Looking up Group Members
Client RD
| |
| ----- GET rd-lookupepgp=lights1 ----------------------gt |
| |
| |
| lt-- 205 Content ltrdgtd=domain1ltrdgtd=domain2 --------- |
| |
Req GET rd-lookupepgp=lights1
Res 205 Content
ltcoaphostportgtep=node1
ltcoaphostportgtep=node2rdquo
Things for the futurebull Support for JSON representation of Web Links
ndash httptoolsietforgiddraft-bormann-core-links-json-02txtbull Registry for RD registration query parameters
ndash Already OMA Lightweight has defined some new onesbull More examples
Group 3 ldquonew workrdquo(continued)
109
drar-shy‐greevenbosch-shy‐core-shy‐profile-shy‐descripon-shy‐01Bert13 GreevenboschJeroen13 Hoebeke
Isam13 IshaqFloris13 Van13 den13 Abeele
Descripon
bull JSON13 format13 for13 signalling13 the13 servers13 capabilies
bull Signalling13 of13 supported13 opons13 media13 types13 and13 block13 sizendash Other13 items13 can13 be13 added
bull Filtering13 on13 specific13 fields13 through13 URI-shy‐Querybull Link13 hqpdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐profile-shy‐descripon
well-shy‐knownprofile
bull To13 acquire13 profile13 data13 of13 resources13 on13 a13 parcular13 service13 the13 well-shy‐knownprofile13 URI-shy‐path13 is13 introduced
bull For13 example13 to13 get13 all13 informaon13 from13 sensors13 served13 by13 wwwexampleorg13 we13 can13 do13 a13 GET13 to13 coapwwwexampleorgwell-shy‐knownprofile
bull Filtering13 on13 parcular13 resources13 is13 done13 through13 URI-shy‐Queries
Format
bull Currently13 the13 following13 fields13 are13 definedndash ldquopathrdquo13 contains13 the13 URI-shy‐path13 associated13 with13 a13 resource
ndash ldquooprdquo13 a13 numerical13 list13 of13 supported13 opon13 numbers
ndash ldquocfrdquo13 a13 numerical13 list13 of13 supported13 content-shy‐format13 numbers
ndash ldquob1srdquo13 ldquob2srdquo13 supported13 block13 sizes13 for13 Block113 and13 Block213 respecvely
Examplebull On13 the13 right13 is13 an13 example13 of13 a13 camera13 sensor13 at13 coapwwwexampleorgcam13 that13 supports13 the13 Uri-shy‐Host13 (3)13 ETag13 (4)13 Uri-shy‐Port13 (7)13 Uri-shy‐Path13 (11)13 Content-shy‐Format13 (12)13 Token13 (19)13 Block213 (23)13 and13 Proxy-shy‐Uri13 (35)13 opons
bull The13 supported13 content13 formats13 are13 textplain13 (0)13 applicaon13 link-shy‐format13 (40)13 and13 applicaonjson13 (50)
bull The13 supported13 Block213 can13 use13 25613 or13 51213 byte13 blocks
Req13 GET13 coapwwwexampleorgwell-shy‐knownprofile13 Res13 20513 Content13 (applicationjson)13 13 13 13 profile13 13 13 13 13 13 13 13 pathcam13 13 13 13 op[3471112192335]13 13 13 13 13 cf[04050]13 13 13 13 13 b2s[45]13 13 13 13
Filtering13 through13 use13 of13 URI-shy‐Query
bull Filtering13 can13 be13 done13 through13 the13 URI-shy‐Querybull Query13 format13 N=V
ndash N13 is13 a13 profile13 fieldndash V13 is13 the13 desired13 value
bull Examplesndash To13 find13 resources13 that13 support13 content13 format13 ldquoapplicaonjsonrdquo
13 GET13 wwwexampleorgwell-shy‐knownprofilecf=50ndash To13 get13 informaon13 about13 the13 camera
13 GET13 wwwexampleorgwell-shy‐knownprofilepath=cam
Open13 issues
bull Which13 other13 profile13 data13 needs13 signallingndash Content-shy‐type13 for13 different13 methods
bull Fix13 the13 order13 in13 which13 the13 profile13 fields13 must13 appearndash Non-shy‐fixed13 order13 easier13 extensible
bull Inheritance13 of13 a13 profile13 descriponbull Extend13 usage13 to13 signal13 the13 client13 profilebull Integraon13 with13 link13 format
Thank13 youQuesons
drar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval-shy‐00
Bert13 Greevenbosch
Descripon
bull The13 ldquoMinimumRequestInterval13 opon13 can13 be13 used13 to13 indicate13 the13 minimum13 me13 between13 two13 requests13 in13 a13 transacon
bull Originally13 intended13 for13 Block13 but13 also13 usable13 for13 other13 transaconsndash Example13 browsing13 a13 server
bull The13 goal13 is13 to13 reduce13 the13 server13 load13 and13 network13 traffic
bull Link13 hqpsdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval
Usage
bull The13 client13 keeps13 the13 server13 informed13 about13 its13 request13 speed13 through13 inclusion13 of13 the13 ldquoMinimumRequestIntervalrdquo13 opon
bull In13 responses13 the13 server13 fixes13 the13 minimum13 request13 interval13 through13 the13 same13 opon
bull The13 client13 obeys13 the13 speed13 indicated13 by13 the13 server
bull The13 client13 can13 send13 slower13 but13 not13 faster
Advantages
bull The13 server13 has13 means13 to13 limit13 the13 amount13 of13 incoming13 traffic
bull The13 server13 can13 prevent13 to13 become13 overloaded13 with13 too13 many13 tasks
bull The13 server13 does13 not13 need13 arficially13 slow13 down13 the13 client13 by13 sending13 late13 ACKsndash No13 need13 to13 keep13 track13 of13 delayed13 ACKsndash The13 server13 can13 perform13 other13 tasks13 instead
bull Reduced13 network13 traffic
Thank13 youQuesons
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-links-json-02txt
123
RFC 6690 (link-format) documents are somewhat foreign to many web app developerssect would prefer to have them in JSON format
There is no standard way to represent link-format documents in applicationssect but everyone knows how to handle JSON
Define a standard JSON translation for link-format
Itrsquos
not
rock
et
scien
ce
ltsensorsgtct=40title=Sensor Index ltsensorstempgtrt=temperature-cif=sensor ltsensorslightgtrt=light-luxif=sensor lthttpwwwexamplecomsensorst123gt anchor=sensorstemprel=describedby lttgtanchor=sensorstemprel=alternate [hrefsensorsct40titleSensor Index hrefsensorstemprttemperature-cifsensor hrefsensorslightrtlight-luxifsensor hrefhttpwwwexamplecomsensorst123 anchorsensorstempreldescribedby hreftanchorsensorstemprelalternate]
124
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-ipsec-for-coap-00txt
IPsec definitions for CoAP Mostly placeholder at this time Who has implementation experience with this
125
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-cross-reverse-convention-00txt
This draft has two lines of payload(based on a WGLC comment by Cullen Jennings)
coap12344567foobara=3
httpwwwproxycomwellknowncore-translate1234_4567foobara=3
Is that a useful convention to have
126
Insert CI slides here
127
128
0
5
10
15
20
25
30
35
40
10 20 30 40 50 60 70
good
put (
pps)
pps
Goodput vs pps (Econotags)
goodput
[Khattak preliminary]
Congestion Control
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-cocoa-00txt
ldquoadvancedrdquo cc (The draft is just a first shot) Others may have better ideas
129
Insert post-WGLC discussion slides here
130
Stop Continue Start
131
An Agile Retrospective
http6lowappnet coreIETF86 2013-03-12-13
Stop
132
Endless new CoAP optionssect instead use RESTful as much as possible
Move general security lifecycle out Looking at theoretical problems
http6lowappnet coreIETF86 2013-03-12-13
Continue
Interops Running code Look at real-world examples and deployments Solve their actual problems
sect Unilateral enhancements eg higher performance congestion control
sect Transports (SMS hellip)sect Make Web linking and Directories more and more usefulsect RESTful Design Paradigms for real-world problems
133
http6lowappnet coreIETF86 2013-03-12-13
Start
Further push into the (browser) web world (HTML5 browser security)
Specific supporting worksect SenMLsect URI work (dev URN hellip)sect Security Processes (next slide)
Spin outsect (We donrsquot really get to decide where this is done)
134
http6lowappnet coreIETF86 2013-03-12-13
Security
Integrate Application Network Group Keyingsect Tunnel-free setup
Donrsquot redo what has been done alreadysect ZigBee IP is finesect But what about other scenarios
Simple REST interfaces for working with keying materials and authorizationsect Start with defining objectives
Object Security for Constrained Nodes135
Re-chartering CoREWhat do we want to do now that wersquore grown up
Zach ShelbyCoRE WG IETF-86 Orlando
What is the scope
bull So we have a protocol and Web Linking what next
bull Keep with what we know besthellip1 Enhancements around CoAP2 New transports for CoAP3 New representations for Web Links4 General application layer solutions
CoRE WG IETF-86 Orlando 2
Enhancements around CoAP
bull Advanced congestion control
CoRE WG IETF-86 Orlando 3
New Transports for CoAP
bull Infrastructure for CoAP over foondash httptoolsietforgiddraft-silverajan-core-
coap-alternative-transports-01txtbull CoAP over SMS
ndash httptoolsietforgiddraft-becker-core-coap-sms-gprs-03txt
ndash OMA Lightweightbull CoAP over TCP
ndash httptoolsietforgiddraft-li-core-coap-payload-length-option-01txt
CoRE WG IETF-86 Orlando 4
New support for Web Links
bull JSON Web Linksndash httptoolsietforgiddraft-bormann-core-links-
json-02txt
2332010 CoRE WG IETF-77 Anaheim 5
General application layer solutions
bull Resource Directoryndash httptoolsietforgiddraft-shelby-core-
resource-directory-05txtndash OMA Lightweight
2332010 CoRE WG IETF-77 Anaheim 6
Discussion item (11)
n Solution for Configuring Group Membership (no ticket)n Example of (unicast) configuring an endpoint to be part of one multicast
groupReq POST gp (Content-Format applicationjson)
n floor1westbldg6examplecom ip ff154200f7feed3714cb Res 204 Changed
n Where the ldquogprdquo resource has resource type (rt) ldquocoregprdquo which is defined for this purpose
n Question Do we want specify such a solution (or for example leave it completely up to implementation)
Open Issues(15)
n Review Groupcomm requirements language (271)n Decision made to keep requirements language for informational draftn Each use of MAYMUSTSHOULD etc is to be reviewed
Open Issues(25)
n Add section on multicast via Proxy and its limitations (274)n Add a section to explain the issues amp limitations of doing CoAP multicast
requests via a CoAP Proxy n Goal is to warn and guide implementers in this subject n Also such a section would provide a placeholderreminder of the problems
that might be addressed further in the futuren Based on IETF 85 CoRE WG meeting discussion on Multicast CoAP
requests via a Proxy Discussion summary for referencen Aggregation of responses in a proxy is difficult since it doesnt know
when to stop aggregating responses n SIP tried to deal with this problem but didnt solve it n There may be an expectancy of CoAP client to get single response
back from proxy not multiple The client in this case may not even know what it could expect It may not even know the Proxy-URI contains a multicast target
n Presented via-proxy use case exposes gap in the core-coap specification regarding multicast via proxy (Note Expectation is that core-coap wonrsquot address it in the first planned RFC release)
Open Issues(35)
n Issues with twomultiple Resource Directories in use case (280)n Some potential issues with RD came out of review Peter van der Stok and
WG discussion IETF85 n There are two RD servers use case shows that only one is found despite
the fact that site-local multicast is used - should be two RDs found n Proposal simplify use case to a single RD server on the backbone to avoid
such RD-specific issues like synchronization of RD information between servers
Open Issues(45)
n Add single-subnet configuration to use cases (278)n Suggested by review Peter van der Stok and IETF85 WG discussion that
its best to start explaining the simplebasic cases and then gradually build up complexity
n Simplest case not shown yet would be a single subnet network configuration which is currently not present in the I-D only the 2-subnet configuration of Fig 1
n Question Do we need to add such case or doesnt it add muchn (Note that core-coap Figure 22 already shows the simplest case of link-local
multicast)
Open Issues(55)
n Add use case with controller (client) located on the backbone (279)n Suggested by discussion following review Peter van der Stok n Case missing where a controller (client) is located on the backbonen Question Do we need to add such case or does it add much
Group 2a other old friends
25
Angelo Castellani Salvatore Loreto Akbar Rahman Thomas Fossati Esko Dijk
IETF 86 March 2013httpwwwietforgiddraft-castellani-core-http-mapping-07txt
Best Practices for HTTP-CoAP Mapping
Implementation
Summary of Changes (from -06 rev)
n Based on discussion at last IETF-85 (Atlanta)n Clarification of HTTP-CoAP Proxies
n Definitionn Placementn Benefits
n Clarification of HTTP-CoAP URI mapping options
Goals of I-D
n For Reverse HTTP-CoAP Cross Protocol Proxyn Provide more detailed information to proxy designers (beyond
Section 10 of [I-Dietf-core-coap]) to help implement proxies that correctly inter-work with other CoAP and HTTP clientserver implementations that adhere to the specifications
n Define a consistent set of guidelines that a HTTP-to-CoAP proxy implementation MAY adhere to The main reason of adhering to such guidelines is to reduce variation between proxy implementations thereby increasing interoperabilityn As an example use case a proxy conforming to these guidelines made
by vendor A can be easily replaced by a proxy from vendor B that also conforms to the guidelines
I-D Outline
n Guidance on HTTP to CoAP URI mappingn HTTP-CoAP Reverse cross-protocol proxy implementation
n Placementn Response code amp media type translationsn Caching and congestion controln Cache refresh via Observen Use of CoAP blockwise transfern Security translation
n Security Considerationsn Traffic overflown Handling secured exchanges
Definitions (12)
n Cross-Protocol Proxy (or Cross Proxy) is a proxy performing a cross- protocol mapping in the context of this document a HTTP-CoAP (HC) mapping A Cross-Protocol Proxy can behave as a Forward Proxy Reverse Proxy or Interception Proxy n Note In this document we focus on the Reverse Proxy mode of the
Cross-Protocol Proxy
n Forward Proxy a message forwarding agent that is selected by the client usually via local configuration rules to receive requests for some type(s) of absolute URI and to attempt to satisfy those requests via translation to the protocol indicated by the absolute URI The user decides (is willing to) use the proxy as the forwardingdereferencing agent for a predefined subset of the URI space
Definitions (22)
n Reverse Proxy a receiving agent that acts as a layer above some other server(s) and translates the received requests to the underlying servers protocol It behaves as an origin (HTTP) server on its connection towards the (HTTP) client and as a (CoAP) client on its connection towards the (CoAP) origin server The (HTTP) client uses the origin-form [I-Dietf-httpbis-p1-messaging] as a request- target URI
n Reverse and Forward proxies are technically very similar with main differences being that the former appears to a client as an origin server while the latter does not and that clients may be unaware they are communicating with a proxy
Reverse Cross-Protocol Proxy Deployment Scenario
HTTP-CoAP Response Code Mapping
Implementation Experience
n Direct experience from the draft authorsn Squid HTTP-CoAP mapping module
n University of Padovan httptelecomdeiunipditiotn Both Forward and Interception operation supported
n HTTP-CoAP proxy based on EvCoAPn KoanLogic University of Bologna and Salvatore
Loreto (as individual)n httpsgithubcomkoanlogicwebthingstreemasterbridgesw
libevcoapn The document is open to input from other implementations
Next Steps
n Does the WG recommend adoptionn Intended status Informational Best Practicen Purpose Reduce arbitrary variation between proxy
implementations thereby increasing interoperability
Backup
HTTP to CoAP URI Mapping Options (12)
n Embedded Mapping n In an embedded mapping approach the HTTP URI has embedded
inside it the authority and path part of the CoAP URI n Example The CoAP resource nodecoapsomethingnetfoo can
be accessed by an HTTP client by inserting in the request httphc-proxysomethingnetcoapnodecoapsomethingnetfoo The Cross-Protocol Proxy then maps the URI to coapnodecoapsomethingnetfoo
HTTP to CoAP URI Mapping Options (22)
n Homogeneous Mapping n In a homogeneous mapping approach only the scheme portion of the URI
needs to be mapped The rest of the URI (ie authority path etc) remains unchanged
n Example The CoAP resource coapnodecoapsomethingnetfoo can be accessed by an HTTP client by requesting httpnodecoapsomethingnetfoo The Cross-Protocol Proxy receiving the request is responsible to map the URI to coapnodecoapsomethingnetfoo
n Background info n The assumption in this case is that the HTTP client would be able to
successfully resolve nodecoapsomethingnet using DNS infrastructure to return the IP address of the HC proxy Most likely this would be through a two step DNS lookup where the first DNS lookup would resolve somethingnet using public DNS infrastructure
n Then the second DNS lookup on the subdomain coap and the host node would typically be resolved by a DNS server operated by the owner of domain somethingnet So this domain owner can manage its own internal node names and subdomain allocation which would correspond to the CoAP namespace
Group 3 ldquonew workrdquo
39
Transport of CoAP over SMS USSD and GPRSdraft-becker-core-coap-sms-gprs-03
Markus Becker Kepeng LiKoojana Kuladinithi Thomas Poumltsch
CoRE WG IETF-86 Orlando
1 10
ScenariosI In M2M communication IP connectivity is not alwayssupported by the constrained end-points
I Power savingI Coverage (GPRS 3G LTE)
I SMS and USSD based communication is almost alwayssupported
210
Changes from draft-01 to draft-03 (1)
I Added possible CONNONACK interactions Section 5
I Option name changed from Reply-To- to Response-To-Section 16 and Section 101
I Added URI schemeEg coap+tel+15105550101well-knowncore Section 11
I Added possible M2M proxy scenarios Section 14
3 10
Changes from draft-01 to draft-03 (2)
I Added reference to bormann-coap-misc for other SMSencoding Section 71
I Updated requirements on Uri-Host and Uri-Port forcoap+tel Section 10
I Added security considerations Transport and ObjectSecurity Section 15
I Chose CoAP option numbers and updated the optionnumber table to meet draft-ietf-core-coap-10 Table 1
I Added an IANA registration for the URI scheme coap+telSection 162
4 10
Feedback Split coap+tel into coap+smsand coap+ussd
I How else to differ the various transports in the URII Or is the transport to use decided by the implementationI See alsodraft-silverajan-core-coap-alternative-transports-01
5 10
Feedback Response-To-Scheme option
I Should there be a Response-To-Scheme optionadditionally to Response-To-Uri-Host andResponse-To-Uri-Path
I So that a CoAP end-point which receives a request by CoAPover non-IP transport can be instructed to also use thenon-IP transport for the response
I This would imply to add aResponse-To-Telephone-Subscriber and more options forother transports that have other URI schemes than coapand coaps
6 10
Feedback Selection of Transport by Client
I When a server is reachable by various transports howdoes a client decide which transport to use
I Client-side application congurationI Leave it to a proxy which uses cellular network lookupfunctions
7 10
Feedback Potential Threats
I Trigger expensive short messagesI Redirect trac to other addressesI More threats
I Are the security measures in the draft adequateI Whitelisting on serverI Relying on cellular network security (dedicated M2M APNs)I Object security on CoAP payload
8 10
Feedback Message Exchanges
I Figures 11-18 show possible message exchanges whenclient and server have two addresses
I With NON Not using CoAP retransmission capabilityI ACK on different transportI Additional (costly) message on Transport AI Request with Content
I Which ones are allowedI Which ones are meaningful
9 10
Next steps
I Rene Uri schemeI Response-To-Scheme optionI Selection of Message ExchangeI Rene Proxying
10 10
CoAP13 Communicaon13 with13 Alternave13 Transports
Bill Silverajan and Teemu SavolainenCore WG IETF 86 Orlando
031113
Objecves13 (In13 Scope)
bull Unambiguous13 representaon13 of13 transport13 to13 be13 used13 by13 CoAP
bull Details13 how13 the13 transport13 can13 carry13 CoAP13 packet
bull Focus13 is13 on13 what13 CoAP13 communicaons13 requirements13 are
bull Allow13 CoAP13 mechanisms13 to13 exploit13 cross-shy‐layer13 opmisaons
51
031113
Non13 Goals13 (Not13 in13 scope)
bull Applicaon-shy‐level13 QoS13 requirementsbull Real-shy‐me13 constraintsbull Ordering13 reliability13 congeson13 controlbull Applicaon13 and13 network13 adaptaonbull Mobility13 and13 readdressing13 supportbull Network13 protocol13 (eg13 IPsec)13 configuraon
52
031113
Use13 Cases
bull NAT13 and13 Firewall13 traversal13 with13 TCPbull Delay13 Tolerant13 Networkingbull Non-shy‐IP13 Low13 Energy13 Protocols
53
031113
Related13 Work
bull OMA13 Lightweight13 M2M13 Protocolbull CoAP13 over13 SMSGPRSUSSD
54
031113
What13 does13 the13 work13 entail
bull The13 ability13 to13 specify13 end13 point13 idenfiers13 and13 URIs13 to13 reflect13 which13 transport13 CoAP13 can13 use
bull The13 ability13 to13 register13 to13 resource13 directories13 resource13 types13 reflecng13 types13 of13 transport13 available
bull Ability13 for13 mul-shy‐transport13 nodes13 to13 select13 transport13 to13 use13 without13 significant13 alteraon13 to13 CoAP13 packet13 structure
55
031113
Points13 to13 consider
bull Requirements13 for13 transport13 layer13 protocol13 to13 carry13 CoAP13 packets
bull Representaon13 of13 URI13 scheme13 for13 generic13 transport13 protocols
bull Opon13 extensions13 for13 CoAP13 to13 express13 available13 transports
bull Mapping13 and13 message13 sizebull Security13 consideraons
56
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
URI13 =13 scheme13 13 13 authority13 path-shy‐abempty13 [13 query13 ]
bull Within13 the13 scheme13 namebull In13 the13 URI13 pathbull As13 a13 query13 component
57
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
bull Within13 the13 scheme13 namendash coap+tel+15105550101well-shy‐knowncorendash coap+tcpexamplecom5683temperaturendash coap+blel2cap[1234567890AB]4pulse
bull Easy13 URI13 parsing13 for13 transport13 type13 and13 idenfier
bull Each13 new13 scheme13 name13 requires13 IANA13 registraon
58
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
bull In13 the13 URI13 pathndash coaphostexamplecomtransport=tcpwell-shy‐knowncorert=core-shy‐rd
bull Easy13 adopon13 of13 new13 (and13 experimental)13 CoAP13 transports13 without13 IANA13 registraon
bull Caveat13 Uri-shy‐Path13 opon13 is13 a13 Crical13 CoAP13 opon13 see13 secon13 54113 of13 I-shy‐Diep-shy‐core-shy‐coap
59
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
bull As13 a13 URI13 query13 componentndash coaphostexamplecomwell-shy‐knowncorert=core-shy‐rdq=tcp
bull Also13 easy13 to13 adopt13 new13 (and13 experimental)13 CoAP13 transports13 without13 IANA13 registraon
bull Caveat13 Uri-shy‐Query13 opon13 is13 a13 Crical13 CoAP13 opon13 see13 secon13 54113 of13 I-shy‐Diep-shy‐core-shy‐coap
60
031113
URI13 Representaons13 for13 CoAPNon13 standard13 ways
bull Transport13 in13 the13 URI13 authority13 componentndash coaphost[port][transport]13 instead13 of13 coaphost[port]
bull Transport13 as13 a13 service13 URLndash servicecoaptcphostexamplecomwell-shy‐knowncorert=core-shy‐rd
bull Above13 two13 ways13 break13 exisng13 compability13 (although13 both13 are13 based13 on13 valid13 IANA13 URI13 registraons)
61
031113
URI13 Representaons13 for13 CoAPMiscellaneous13 Consideraons
bull Ensure13 that13 transport13 is13 defined13 unambiguously13 (eg13 L2CAP13 used13 by13 both13 BLE13 and13 standard13 Bluetooth13 so13 avoid13 rdquocoap+l2caprdquo13 or13 rdquotransport=l2caprdquo13 or13 rdquoq=l2caprdquondash Can13 be13 done13 as13 WG13 consensusndash Namespace13 approach13 eg13 rdquocoap+blel2caprdquo13 or13 rdquoq=blel2caprdquo
bull Allow13 end-shy‐points13 to13 use13 CoAP13 Resource13 Directory13 to13 register13 alternave13 transports13 and13 idenfiers13 and13 provide13 periodic13 updatesndash Register13 rdquocore-shy‐transportrdquo13 resource13 type
62
031113
Transport13 Consideraons
bull Uniqueness13 of13 end-shy‐point13 idenficaonbull Communicaon13 support13 Unidireconal13 Bidireconal13 1N13 (broadcast13 mulcast13 anycast)13 messaging
bull Binary13 encoding13 Network13 byte13 orderingbull MTU13 correlaon13 with13 CoAP13 PDU13 sizebull Transport13 latency
63
031113
Security13 Consideraons
bull Drar13 does13 not13 introduce13 new13 security13 requirements13 by13 itself
bull There13 may13 be13 privacy13 issues13 if13 nodes13 use13 telephone13 numbers13 or13 MAC13 addresses13 as13 public13 end13 point13 idenfiers
64
Akbar Rahman
IETF 86 March 2013 httpwwwietforgiddraft-rahman-core-sleepy-02txt
Enhanced Sleepy Node Support for CoAP
Introduction
It is expected that in CoAP networks there will be a certain portion of devices that are sleepy and which may occasionally go into a sleep mode (ie go into a low power state to conserve power) and subsequently have reduced CoAP protocol communication ability
This I-D proposes a minimal and efficient mechanism building on the Resource Directory concept (which will be integrated into a CoAP Proxy) to enhance sleepy node support in CoAP networks
Main Question from IETF-85 (Atlanta)
What performance benefit does the proposed Sleepy Node support solution give in a network that already has standard CoAP caching enabled
Sleepy Node Performance Analysis
Experimental Network
1-5 clients
Both Sleepy and Non-
Sleepy servers
Sleepy Node Performance Analysis Network Setup
CoAPSleepyServer(s)
CoAPSleepAwareReverseProxy
CoAP
Client(s)
Request
Response
Sleep9AwareCoREResourceDirectoryCapability
PublishedSleepParameters
Sleep9AwareCoAPStoreandForwardCapability Response
Request
SleepAwareCoAP503ResponseCapability
CoAPCachingCapability
bull Server supports publishing sleep parameters to proxy bull Eg Irsquom going to be asleep for X seconds
bull Proxy supports sleep-awareness capabilities bull Proxy also supports caching capability based off of maxAge bull Protocol flow similar to approach of Figure 1 (Synchronous RD Based Sleep
Tracking) of I-D
Proxy capabilities can be selectively enableddisabled
Proxy ndash Server Interface
Client ndash Proxy Interface
CoAP Sleep-Aware Reverse Proxy Features CoRE Sleep-aware Resource Directory
Support storing published sleep parameters from CoAP servers sleepState (AWAKE ASLEEP) sleepDuration
Sleep-aware CoAP 503 Response Capability If CoAP request to a sleeping server is received proxy returns a
lsquo503 Retry-Afterrsquo response to client 503 contains a timestamp indicating when the sever will wake back up
(timestamp delivered in CoAP maxAge option) Sleep-aware CoAP Store-and-Forward Capability
If CoAP request to a sleeping server is received proxy stores request until server wakes up and then forwards it
Caching capability Cache GET responses from server if maxAge option is present
(this is not a sleep aware feature)
Goals of Performance Analysis
For networks having sleepy servers provide measurements to quantify the impact that CoAP sleep-awareness capabilities can have
See if sleep-awareness capabilities can
provide additional benefits even when CoAP caching is used
Overview of Performance Analysis Performed The analysis was broken up into a set of test scenarios Each test scenario used a different combination of the following
variables Client issued GET requests Server was configured as a sleepy or non-sleepy server Proxy caching of GET responses was enabled or disabled Proxy sleep-aware 503 response capability was enabled or disabled Proxy store-and-forward capability was enabled or disabled maxAge in GET responses ndash Two values were tested 60sec and 5sec of Clients ndash Two values were used ndash 1 client and 5 clients
For comparison purposes the following were held constant across all test scenarios Client issued a fixed number of requests (100) across all test scenarios Client used a delay between each GET request (35sec) to better exercise
proxyrsquos caching and sleep-awareness capabilities For sleepy server test scenarios the server slept 60 sec awake for 3 sec
Format of Results The following results were collected for each
test scenario
Breakdown of the and types of transactions occurring between clientproxyserver
ldquoGETrdquo ndash Test Scenario Results
GET ndash Description of Test Scenarios
TestScenarios-GET
Scenario
CoAPSleepyServerSe7ngs CoAPSleepAwareReverseProxySe7ngs CoAPClientSe7ngs
SleepDuragton(sec)
AwakeDuragton(sec)
maxAge(sec) Caching SleepAwareSAF+
503NumberofClients
NumberofGETs
DelayBetweenClient
Requests(sec)
1a 0 Always 60 Enabled Disabled 1 100 35
1b 60 3 60 Enabled Disabled 1 100 35
1c 60 3 60 Enabled Enabled 1 100 35
2a 0 Always 60 Enabled Disabled 5 100 35
2b 60 3 60 Enabled Disabled 5 100 35
2c 60 3 60 Enabled Enabled 5 100 35
3a 0 Always 5 Enabled Disabled 5 100 35
3b 60 3 5 Enabled Disabled 5 100 35
3c 60 3 5 Enabled Enabled 5 100 35
ldquoGETrdquo ndash Test Scenario 1 Results
maxAge = 60 and 1 Client
GET ndash Scenario 1 ClientProxy Interface Transaction Mix
Scenarios 1a - Non-Sleepy Server Caching Proxy maxAge = 60sec 1b- Sleepy Server Caching Proxy maxAge = 60sec 1c - Sleepy Server Sleep Aware Proxy maxAge = 60sec
Sleep Aware Proxy has better performance for sleepy servers
0
100
200
300
400
500
600
700
1a 1b 1c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
GET ndash Scenario 1 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
Scenarios 1a - Non-Sleepy Server Caching Proxy maxAge = 60sec 1b- Sleepy Server Caching Proxy maxAge = 60sec 1c - Sleepy Server Sleep Aware Proxy maxAge = 60sec
0
100
200
300
400
500
600
700
800
1a 1b 1c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
ldquoGETrdquo ndash Test Scenario 2 Results
maxAge = 60 and 5 Clients
GET ndash Scenario 2 ClientProxy Interface Transaction Mix
Sleep Aware Proxy has slightly better performance for sleepy servers
0
200
400
600
800
1000
1200
1400
2a 2b 2c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
Scenarios 2a - Non-Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2b- Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2c - Sleepy Server Sleep Aware Proxy maxAge = 60sec 5 Clients
See ldquoExperimental Artifactsrdquo Note 1
GET ndash Scenario 2 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has slightly better performance for sleepy servers
0
50
100
150
200
250
300
350
400
2a 2b 2c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
Scenarios 2a - Non-Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2b- Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2c - Sleepy Server Sleep Aware Proxy maxAge = 60sec 5 Clients
See ldquoExperimental Artifactsrdquo Note 2
Experimental Artifacts Note 1
Currently in the experiment the sleep aware proxy checks the cached state of a resource before putting a request into its Store-and-forward queue while a server is sleeping Once in the queue the proxy unconditionally forwards the queued requests to the server once it wakes up This is not the most efficient setup and can easily be improved If the proxy instead checks its cache again before forwarding each queued request it may not need to forward the request to the server For example if there are two queued GET requests in the proxyrsquos queue that address the same resource Only the first request needs to be sent to the server the second request can use the cached response from the first request
Note 2 Currently in the experiment the sleepy server sends a sleepState PUT request to the
proxy each time it goes to sleep This is not the most efficient setup and can easily be improved For example if the server assumes that the proxy can keep track of its ONOFF cycles with its internal timers (eg as per Fig 1 of I-D) then the number of messages from the sleepy server dramatically goes down
ldquoGETrdquo ndash Test Scenario 3 Results
maxAge = 5 and 5 Clients
GET ndash Scenario 3 ClientProxy Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
Scenarios 3a - Non-Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3b- Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3c - Sleepy Server Sleep Aware Proxy maxAge = 5sec 5 Clients
0
500
1000
1500
2000
2500
3000
3500
4000
4500
5000
3a 3b 3c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
GET ndash Scenario 3 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
0
1000
2000
3000
4000
5000
6000
7000
3a 3b 3c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
Scenarios 3a - Non-Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3b- Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3c - Sleepy Server Sleep Aware Proxy maxAge = 5sec 5 Clients
Conclusions
Conclusions These results show that sleep-aware CoAP
proxy features can significantly optimize communication with sleepy servers in most scenarios
These results also show that sleep-
awareness capabilities can provide additional benefits above and beyond CoAP caching in most scenarios
Backup
Current CoAP Support of Sleepy Node (12)
CoAP proxies can use a previously cached response to service a new GET request for a sleepy origin server (as in HTTP) But if no valid cache then proxy has to attempt to
retrieve and may fail if origin server is sleeping [I-Dietf-core-coap]
Clients can discover list of resources from RD (GET rd-lookuphellip) for sleepy servers But attempt to GET resource from sleepy origin server
may fail if origin server is sleeping [IDietf-core-link-format amp IDshelby-core-resource-
directory]
Current CoAP Support of Sleepy Node (22)
Lower layer support for sleepy nodes in most wireless technologies (eg WiFi ZigBee) But limited to MAC packet scheduling for sleepy nodes
and not aware of specific needs of IP applications (like CoAP)
Proposal ndash RD Based Sleep Tracking (14)
The current CoAP approach to support sleepy nodes can be significantly improved by introducing RD based mechanisms for a CoAP client to determine whether A targeted resource is located on a sleepy server A sleepy server is currently in sleep mode or not
There is any associated caching Proxy (possibly the RD itself) for a sleepy server
Proposal ndash RD Based Sleep Tracking (24)
We define the following new RD attributes to characterize the properties of a sleepy node SleepState - Indicates whether the node is currently in
sleep mode or not (ie Sleeping or Awake) SleepDuration - Indicates the maximum duration of time
that the node stays in sleep mode TimeSleeping - Indicates the length of time the node
has been sleeping (ie if Sleep State = Sleeping) NextSleep - Indicates the next time the node will go to
sleep (ie if Sleep State = Awake)
CachingProxy ndash Indicates the caching proxy of the sleepy node (ie the RD itself or another node)
Proposal ndash RD Based Sleep Tracking (34)
These attributes are all server (node) level and are new parameters added to the RD URI Template Variables
Finally we also define a new lookup-type (ss) for the RD lookup interface specified in [I-Dshelby-core-resource-directory] This new lookup-type supports looking up the
ldquoSleepStaterdquo (ss) of a specified end-point
Proposal ndash RD Based Sleep Tracking (44)
The three time based parameters (SleepDuration TimeSleeping NextSleep) can be based on either an absolute network time (for a time synchronized network) or a relative local time (measured at the local node)
Following the approach of [I-Dietf-core-link-format] and [I-Dshelby-core-resource-directory] sleep parameters for sleepy servers can be stored by the server in the RD and accessed by all interested clients
Examples of using these parameters in a synchronous or asynchronous manner are shown in the I-D
http6lowappnet coreIETF86 2013-03-12-13
We assume people have read the drafts
Meetings serve to advance difficult issues by making good use of face-to-face communications
Note Well Be aware of the IPR principles according to RFC 3979 and its updates
uumlBlue sheetsuumlScribe(s)
96
drar-shy‐iep-shy‐core-shy‐coapsubmiqed13 to13 IESG
2013-shy‐03-shy‐13
97
OMA Lightweight M2M Overview(A new standard using lots of IETF specs including DTLS
CoAP Block Observe Resource Directory SenMLhellip)
Zach ShelbyCoRE WG IETF-86 Orlando
OMA Lightweight M2Mbull Open Mobile Alliance is well known for Device Management (DM)bull OMA Lightweight M2M is a new standard from the alliance
ndash Focused on constrained Cellular and sensor network M2M devicesndash Driven by leading operators and vendors
bull Scopendash Interfaces protocol amp security between Device and Serverndash Object and Resource modelndash Bootstrap Device Access Control Connectivity and Firmware Objects
bull Draft Specifications are availablendash httpmemberopenmobileallianceorgftpPublic_documentsDM
LightweightM2MPermanent_documentsOMA-TS-LightweightM2M-V1_0_0-20130301-Dzip
bull Timelinendash Requirements and Architecture completed 3Q2012ndash Spec ready for Consistency Review 2Q2013ndash Candidate Approval expected 3Q2013
2 CoRE WG IETF-86 Orlando
Architecture
3
Scope of LWM2M
CoRE WG IETF-86 Orlando
Object Model
bull A Client has one or more Object Instancesbull An Object is a collection of Resourcesbull A Resource is an atomic piece of information
ndash Read Written or Executed
bull Resources can have multiple instancesbull Objects and Resources are identified by a
16-bit Integer Instances by an 8-bit Integerbull ObjectsResources are accessed with
simple URIs Object IDObject InstanceResource ID
eg 1213
4 CoRE WG IETF-86 Orlando
CoRE WG IETF-86 Orlando
CoRE Resource Directory
draft-shelby-core-resource-directory-05
Z Shelby C Bormann S Krco
Backgroundbull Not a new concept
ndash think web search engine or any link directorybull Defines the interfaces to a Resource Directorybull Based on Web Linking framework and the CoRE Link Formatbull Generic REST design for use over HTTP and CoAPbull Used by OMA Lightweight M2Mbull Has already been deployed
ndash In traffic monitoring systemsndash In street lighting systemsndash For vehicular asset trackingndash By a major Cellular M2M operator
Changes since -04
bull Restricted Update to parameter updatesbull Added pagination support for the Lookup interfacebull Changed rt= to et= for the registration amp update
interfacebull Added group support
Group Management
bull RD now includes group management featuresbull New Group Function Set
ndash Register a groupbull Group name domain multicast address endpoint members
ndash Remove a groupbull Group lookup using the Lookup Function Set
ndash List registered groupsndash Find the members of a groupndash Find groups with certain endpoints or resources
Registering a Group
EP RD
| |
| - POST rd-groupgp=lights ltgtep=node1 --gt |
| |
| |
| lt---- 201 Created Location rd-group12 ---- |
| |
Req POST coaprdexamplecomrd-groupgp=lights
Payload
ltgtep=node1
ltgtep=node2
Res 201 Created
Location rd-group12
Looking up Group Members
Client RD
| |
| ----- GET rd-lookupepgp=lights1 ----------------------gt |
| |
| |
| lt-- 205 Content ltrdgtd=domain1ltrdgtd=domain2 --------- |
| |
Req GET rd-lookupepgp=lights1
Res 205 Content
ltcoaphostportgtep=node1
ltcoaphostportgtep=node2rdquo
Things for the futurebull Support for JSON representation of Web Links
ndash httptoolsietforgiddraft-bormann-core-links-json-02txtbull Registry for RD registration query parameters
ndash Already OMA Lightweight has defined some new onesbull More examples
Group 3 ldquonew workrdquo(continued)
109
drar-shy‐greevenbosch-shy‐core-shy‐profile-shy‐descripon-shy‐01Bert13 GreevenboschJeroen13 Hoebeke
Isam13 IshaqFloris13 Van13 den13 Abeele
Descripon
bull JSON13 format13 for13 signalling13 the13 servers13 capabilies
bull Signalling13 of13 supported13 opons13 media13 types13 and13 block13 sizendash Other13 items13 can13 be13 added
bull Filtering13 on13 specific13 fields13 through13 URI-shy‐Querybull Link13 hqpdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐profile-shy‐descripon
well-shy‐knownprofile
bull To13 acquire13 profile13 data13 of13 resources13 on13 a13 parcular13 service13 the13 well-shy‐knownprofile13 URI-shy‐path13 is13 introduced
bull For13 example13 to13 get13 all13 informaon13 from13 sensors13 served13 by13 wwwexampleorg13 we13 can13 do13 a13 GET13 to13 coapwwwexampleorgwell-shy‐knownprofile
bull Filtering13 on13 parcular13 resources13 is13 done13 through13 URI-shy‐Queries
Format
bull Currently13 the13 following13 fields13 are13 definedndash ldquopathrdquo13 contains13 the13 URI-shy‐path13 associated13 with13 a13 resource
ndash ldquooprdquo13 a13 numerical13 list13 of13 supported13 opon13 numbers
ndash ldquocfrdquo13 a13 numerical13 list13 of13 supported13 content-shy‐format13 numbers
ndash ldquob1srdquo13 ldquob2srdquo13 supported13 block13 sizes13 for13 Block113 and13 Block213 respecvely
Examplebull On13 the13 right13 is13 an13 example13 of13 a13 camera13 sensor13 at13 coapwwwexampleorgcam13 that13 supports13 the13 Uri-shy‐Host13 (3)13 ETag13 (4)13 Uri-shy‐Port13 (7)13 Uri-shy‐Path13 (11)13 Content-shy‐Format13 (12)13 Token13 (19)13 Block213 (23)13 and13 Proxy-shy‐Uri13 (35)13 opons
bull The13 supported13 content13 formats13 are13 textplain13 (0)13 applicaon13 link-shy‐format13 (40)13 and13 applicaonjson13 (50)
bull The13 supported13 Block213 can13 use13 25613 or13 51213 byte13 blocks
Req13 GET13 coapwwwexampleorgwell-shy‐knownprofile13 Res13 20513 Content13 (applicationjson)13 13 13 13 profile13 13 13 13 13 13 13 13 pathcam13 13 13 13 op[3471112192335]13 13 13 13 13 cf[04050]13 13 13 13 13 b2s[45]13 13 13 13
Filtering13 through13 use13 of13 URI-shy‐Query
bull Filtering13 can13 be13 done13 through13 the13 URI-shy‐Querybull Query13 format13 N=V
ndash N13 is13 a13 profile13 fieldndash V13 is13 the13 desired13 value
bull Examplesndash To13 find13 resources13 that13 support13 content13 format13 ldquoapplicaonjsonrdquo
13 GET13 wwwexampleorgwell-shy‐knownprofilecf=50ndash To13 get13 informaon13 about13 the13 camera
13 GET13 wwwexampleorgwell-shy‐knownprofilepath=cam
Open13 issues
bull Which13 other13 profile13 data13 needs13 signallingndash Content-shy‐type13 for13 different13 methods
bull Fix13 the13 order13 in13 which13 the13 profile13 fields13 must13 appearndash Non-shy‐fixed13 order13 easier13 extensible
bull Inheritance13 of13 a13 profile13 descriponbull Extend13 usage13 to13 signal13 the13 client13 profilebull Integraon13 with13 link13 format
Thank13 youQuesons
drar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval-shy‐00
Bert13 Greevenbosch
Descripon
bull The13 ldquoMinimumRequestInterval13 opon13 can13 be13 used13 to13 indicate13 the13 minimum13 me13 between13 two13 requests13 in13 a13 transacon
bull Originally13 intended13 for13 Block13 but13 also13 usable13 for13 other13 transaconsndash Example13 browsing13 a13 server
bull The13 goal13 is13 to13 reduce13 the13 server13 load13 and13 network13 traffic
bull Link13 hqpsdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval
Usage
bull The13 client13 keeps13 the13 server13 informed13 about13 its13 request13 speed13 through13 inclusion13 of13 the13 ldquoMinimumRequestIntervalrdquo13 opon
bull In13 responses13 the13 server13 fixes13 the13 minimum13 request13 interval13 through13 the13 same13 opon
bull The13 client13 obeys13 the13 speed13 indicated13 by13 the13 server
bull The13 client13 can13 send13 slower13 but13 not13 faster
Advantages
bull The13 server13 has13 means13 to13 limit13 the13 amount13 of13 incoming13 traffic
bull The13 server13 can13 prevent13 to13 become13 overloaded13 with13 too13 many13 tasks
bull The13 server13 does13 not13 need13 arficially13 slow13 down13 the13 client13 by13 sending13 late13 ACKsndash No13 need13 to13 keep13 track13 of13 delayed13 ACKsndash The13 server13 can13 perform13 other13 tasks13 instead
bull Reduced13 network13 traffic
Thank13 youQuesons
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-links-json-02txt
123
RFC 6690 (link-format) documents are somewhat foreign to many web app developerssect would prefer to have them in JSON format
There is no standard way to represent link-format documents in applicationssect but everyone knows how to handle JSON
Define a standard JSON translation for link-format
Itrsquos
not
rock
et
scien
ce
ltsensorsgtct=40title=Sensor Index ltsensorstempgtrt=temperature-cif=sensor ltsensorslightgtrt=light-luxif=sensor lthttpwwwexamplecomsensorst123gt anchor=sensorstemprel=describedby lttgtanchor=sensorstemprel=alternate [hrefsensorsct40titleSensor Index hrefsensorstemprttemperature-cifsensor hrefsensorslightrtlight-luxifsensor hrefhttpwwwexamplecomsensorst123 anchorsensorstempreldescribedby hreftanchorsensorstemprelalternate]
124
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-ipsec-for-coap-00txt
IPsec definitions for CoAP Mostly placeholder at this time Who has implementation experience with this
125
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-cross-reverse-convention-00txt
This draft has two lines of payload(based on a WGLC comment by Cullen Jennings)
coap12344567foobara=3
httpwwwproxycomwellknowncore-translate1234_4567foobara=3
Is that a useful convention to have
126
Insert CI slides here
127
128
0
5
10
15
20
25
30
35
40
10 20 30 40 50 60 70
good
put (
pps)
pps
Goodput vs pps (Econotags)
goodput
[Khattak preliminary]
Congestion Control
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-cocoa-00txt
ldquoadvancedrdquo cc (The draft is just a first shot) Others may have better ideas
129
Insert post-WGLC discussion slides here
130
Stop Continue Start
131
An Agile Retrospective
http6lowappnet coreIETF86 2013-03-12-13
Stop
132
Endless new CoAP optionssect instead use RESTful as much as possible
Move general security lifecycle out Looking at theoretical problems
http6lowappnet coreIETF86 2013-03-12-13
Continue
Interops Running code Look at real-world examples and deployments Solve their actual problems
sect Unilateral enhancements eg higher performance congestion control
sect Transports (SMS hellip)sect Make Web linking and Directories more and more usefulsect RESTful Design Paradigms for real-world problems
133
http6lowappnet coreIETF86 2013-03-12-13
Start
Further push into the (browser) web world (HTML5 browser security)
Specific supporting worksect SenMLsect URI work (dev URN hellip)sect Security Processes (next slide)
Spin outsect (We donrsquot really get to decide where this is done)
134
http6lowappnet coreIETF86 2013-03-12-13
Security
Integrate Application Network Group Keyingsect Tunnel-free setup
Donrsquot redo what has been done alreadysect ZigBee IP is finesect But what about other scenarios
Simple REST interfaces for working with keying materials and authorizationsect Start with defining objectives
Object Security for Constrained Nodes135
Re-chartering CoREWhat do we want to do now that wersquore grown up
Zach ShelbyCoRE WG IETF-86 Orlando
What is the scope
bull So we have a protocol and Web Linking what next
bull Keep with what we know besthellip1 Enhancements around CoAP2 New transports for CoAP3 New representations for Web Links4 General application layer solutions
CoRE WG IETF-86 Orlando 2
Enhancements around CoAP
bull Advanced congestion control
CoRE WG IETF-86 Orlando 3
New Transports for CoAP
bull Infrastructure for CoAP over foondash httptoolsietforgiddraft-silverajan-core-
coap-alternative-transports-01txtbull CoAP over SMS
ndash httptoolsietforgiddraft-becker-core-coap-sms-gprs-03txt
ndash OMA Lightweightbull CoAP over TCP
ndash httptoolsietforgiddraft-li-core-coap-payload-length-option-01txt
CoRE WG IETF-86 Orlando 4
New support for Web Links
bull JSON Web Linksndash httptoolsietforgiddraft-bormann-core-links-
json-02txt
2332010 CoRE WG IETF-77 Anaheim 5
General application layer solutions
bull Resource Directoryndash httptoolsietforgiddraft-shelby-core-
resource-directory-05txtndash OMA Lightweight
2332010 CoRE WG IETF-77 Anaheim 6
Open Issues(15)
n Review Groupcomm requirements language (271)n Decision made to keep requirements language for informational draftn Each use of MAYMUSTSHOULD etc is to be reviewed
Open Issues(25)
n Add section on multicast via Proxy and its limitations (274)n Add a section to explain the issues amp limitations of doing CoAP multicast
requests via a CoAP Proxy n Goal is to warn and guide implementers in this subject n Also such a section would provide a placeholderreminder of the problems
that might be addressed further in the futuren Based on IETF 85 CoRE WG meeting discussion on Multicast CoAP
requests via a Proxy Discussion summary for referencen Aggregation of responses in a proxy is difficult since it doesnt know
when to stop aggregating responses n SIP tried to deal with this problem but didnt solve it n There may be an expectancy of CoAP client to get single response
back from proxy not multiple The client in this case may not even know what it could expect It may not even know the Proxy-URI contains a multicast target
n Presented via-proxy use case exposes gap in the core-coap specification regarding multicast via proxy (Note Expectation is that core-coap wonrsquot address it in the first planned RFC release)
Open Issues(35)
n Issues with twomultiple Resource Directories in use case (280)n Some potential issues with RD came out of review Peter van der Stok and
WG discussion IETF85 n There are two RD servers use case shows that only one is found despite
the fact that site-local multicast is used - should be two RDs found n Proposal simplify use case to a single RD server on the backbone to avoid
such RD-specific issues like synchronization of RD information between servers
Open Issues(45)
n Add single-subnet configuration to use cases (278)n Suggested by review Peter van der Stok and IETF85 WG discussion that
its best to start explaining the simplebasic cases and then gradually build up complexity
n Simplest case not shown yet would be a single subnet network configuration which is currently not present in the I-D only the 2-subnet configuration of Fig 1
n Question Do we need to add such case or doesnt it add muchn (Note that core-coap Figure 22 already shows the simplest case of link-local
multicast)
Open Issues(55)
n Add use case with controller (client) located on the backbone (279)n Suggested by discussion following review Peter van der Stok n Case missing where a controller (client) is located on the backbonen Question Do we need to add such case or does it add much
Group 2a other old friends
25
Angelo Castellani Salvatore Loreto Akbar Rahman Thomas Fossati Esko Dijk
IETF 86 March 2013httpwwwietforgiddraft-castellani-core-http-mapping-07txt
Best Practices for HTTP-CoAP Mapping
Implementation
Summary of Changes (from -06 rev)
n Based on discussion at last IETF-85 (Atlanta)n Clarification of HTTP-CoAP Proxies
n Definitionn Placementn Benefits
n Clarification of HTTP-CoAP URI mapping options
Goals of I-D
n For Reverse HTTP-CoAP Cross Protocol Proxyn Provide more detailed information to proxy designers (beyond
Section 10 of [I-Dietf-core-coap]) to help implement proxies that correctly inter-work with other CoAP and HTTP clientserver implementations that adhere to the specifications
n Define a consistent set of guidelines that a HTTP-to-CoAP proxy implementation MAY adhere to The main reason of adhering to such guidelines is to reduce variation between proxy implementations thereby increasing interoperabilityn As an example use case a proxy conforming to these guidelines made
by vendor A can be easily replaced by a proxy from vendor B that also conforms to the guidelines
I-D Outline
n Guidance on HTTP to CoAP URI mappingn HTTP-CoAP Reverse cross-protocol proxy implementation
n Placementn Response code amp media type translationsn Caching and congestion controln Cache refresh via Observen Use of CoAP blockwise transfern Security translation
n Security Considerationsn Traffic overflown Handling secured exchanges
Definitions (12)
n Cross-Protocol Proxy (or Cross Proxy) is a proxy performing a cross- protocol mapping in the context of this document a HTTP-CoAP (HC) mapping A Cross-Protocol Proxy can behave as a Forward Proxy Reverse Proxy or Interception Proxy n Note In this document we focus on the Reverse Proxy mode of the
Cross-Protocol Proxy
n Forward Proxy a message forwarding agent that is selected by the client usually via local configuration rules to receive requests for some type(s) of absolute URI and to attempt to satisfy those requests via translation to the protocol indicated by the absolute URI The user decides (is willing to) use the proxy as the forwardingdereferencing agent for a predefined subset of the URI space
Definitions (22)
n Reverse Proxy a receiving agent that acts as a layer above some other server(s) and translates the received requests to the underlying servers protocol It behaves as an origin (HTTP) server on its connection towards the (HTTP) client and as a (CoAP) client on its connection towards the (CoAP) origin server The (HTTP) client uses the origin-form [I-Dietf-httpbis-p1-messaging] as a request- target URI
n Reverse and Forward proxies are technically very similar with main differences being that the former appears to a client as an origin server while the latter does not and that clients may be unaware they are communicating with a proxy
Reverse Cross-Protocol Proxy Deployment Scenario
HTTP-CoAP Response Code Mapping
Implementation Experience
n Direct experience from the draft authorsn Squid HTTP-CoAP mapping module
n University of Padovan httptelecomdeiunipditiotn Both Forward and Interception operation supported
n HTTP-CoAP proxy based on EvCoAPn KoanLogic University of Bologna and Salvatore
Loreto (as individual)n httpsgithubcomkoanlogicwebthingstreemasterbridgesw
libevcoapn The document is open to input from other implementations
Next Steps
n Does the WG recommend adoptionn Intended status Informational Best Practicen Purpose Reduce arbitrary variation between proxy
implementations thereby increasing interoperability
Backup
HTTP to CoAP URI Mapping Options (12)
n Embedded Mapping n In an embedded mapping approach the HTTP URI has embedded
inside it the authority and path part of the CoAP URI n Example The CoAP resource nodecoapsomethingnetfoo can
be accessed by an HTTP client by inserting in the request httphc-proxysomethingnetcoapnodecoapsomethingnetfoo The Cross-Protocol Proxy then maps the URI to coapnodecoapsomethingnetfoo
HTTP to CoAP URI Mapping Options (22)
n Homogeneous Mapping n In a homogeneous mapping approach only the scheme portion of the URI
needs to be mapped The rest of the URI (ie authority path etc) remains unchanged
n Example The CoAP resource coapnodecoapsomethingnetfoo can be accessed by an HTTP client by requesting httpnodecoapsomethingnetfoo The Cross-Protocol Proxy receiving the request is responsible to map the URI to coapnodecoapsomethingnetfoo
n Background info n The assumption in this case is that the HTTP client would be able to
successfully resolve nodecoapsomethingnet using DNS infrastructure to return the IP address of the HC proxy Most likely this would be through a two step DNS lookup where the first DNS lookup would resolve somethingnet using public DNS infrastructure
n Then the second DNS lookup on the subdomain coap and the host node would typically be resolved by a DNS server operated by the owner of domain somethingnet So this domain owner can manage its own internal node names and subdomain allocation which would correspond to the CoAP namespace
Group 3 ldquonew workrdquo
39
Transport of CoAP over SMS USSD and GPRSdraft-becker-core-coap-sms-gprs-03
Markus Becker Kepeng LiKoojana Kuladinithi Thomas Poumltsch
CoRE WG IETF-86 Orlando
1 10
ScenariosI In M2M communication IP connectivity is not alwayssupported by the constrained end-points
I Power savingI Coverage (GPRS 3G LTE)
I SMS and USSD based communication is almost alwayssupported
210
Changes from draft-01 to draft-03 (1)
I Added possible CONNONACK interactions Section 5
I Option name changed from Reply-To- to Response-To-Section 16 and Section 101
I Added URI schemeEg coap+tel+15105550101well-knowncore Section 11
I Added possible M2M proxy scenarios Section 14
3 10
Changes from draft-01 to draft-03 (2)
I Added reference to bormann-coap-misc for other SMSencoding Section 71
I Updated requirements on Uri-Host and Uri-Port forcoap+tel Section 10
I Added security considerations Transport and ObjectSecurity Section 15
I Chose CoAP option numbers and updated the optionnumber table to meet draft-ietf-core-coap-10 Table 1
I Added an IANA registration for the URI scheme coap+telSection 162
4 10
Feedback Split coap+tel into coap+smsand coap+ussd
I How else to differ the various transports in the URII Or is the transport to use decided by the implementationI See alsodraft-silverajan-core-coap-alternative-transports-01
5 10
Feedback Response-To-Scheme option
I Should there be a Response-To-Scheme optionadditionally to Response-To-Uri-Host andResponse-To-Uri-Path
I So that a CoAP end-point which receives a request by CoAPover non-IP transport can be instructed to also use thenon-IP transport for the response
I This would imply to add aResponse-To-Telephone-Subscriber and more options forother transports that have other URI schemes than coapand coaps
6 10
Feedback Selection of Transport by Client
I When a server is reachable by various transports howdoes a client decide which transport to use
I Client-side application congurationI Leave it to a proxy which uses cellular network lookupfunctions
7 10
Feedback Potential Threats
I Trigger expensive short messagesI Redirect trac to other addressesI More threats
I Are the security measures in the draft adequateI Whitelisting on serverI Relying on cellular network security (dedicated M2M APNs)I Object security on CoAP payload
8 10
Feedback Message Exchanges
I Figures 11-18 show possible message exchanges whenclient and server have two addresses
I With NON Not using CoAP retransmission capabilityI ACK on different transportI Additional (costly) message on Transport AI Request with Content
I Which ones are allowedI Which ones are meaningful
9 10
Next steps
I Rene Uri schemeI Response-To-Scheme optionI Selection of Message ExchangeI Rene Proxying
10 10
CoAP13 Communicaon13 with13 Alternave13 Transports
Bill Silverajan and Teemu SavolainenCore WG IETF 86 Orlando
031113
Objecves13 (In13 Scope)
bull Unambiguous13 representaon13 of13 transport13 to13 be13 used13 by13 CoAP
bull Details13 how13 the13 transport13 can13 carry13 CoAP13 packet
bull Focus13 is13 on13 what13 CoAP13 communicaons13 requirements13 are
bull Allow13 CoAP13 mechanisms13 to13 exploit13 cross-shy‐layer13 opmisaons
51
031113
Non13 Goals13 (Not13 in13 scope)
bull Applicaon-shy‐level13 QoS13 requirementsbull Real-shy‐me13 constraintsbull Ordering13 reliability13 congeson13 controlbull Applicaon13 and13 network13 adaptaonbull Mobility13 and13 readdressing13 supportbull Network13 protocol13 (eg13 IPsec)13 configuraon
52
031113
Use13 Cases
bull NAT13 and13 Firewall13 traversal13 with13 TCPbull Delay13 Tolerant13 Networkingbull Non-shy‐IP13 Low13 Energy13 Protocols
53
031113
Related13 Work
bull OMA13 Lightweight13 M2M13 Protocolbull CoAP13 over13 SMSGPRSUSSD
54
031113
What13 does13 the13 work13 entail
bull The13 ability13 to13 specify13 end13 point13 idenfiers13 and13 URIs13 to13 reflect13 which13 transport13 CoAP13 can13 use
bull The13 ability13 to13 register13 to13 resource13 directories13 resource13 types13 reflecng13 types13 of13 transport13 available
bull Ability13 for13 mul-shy‐transport13 nodes13 to13 select13 transport13 to13 use13 without13 significant13 alteraon13 to13 CoAP13 packet13 structure
55
031113
Points13 to13 consider
bull Requirements13 for13 transport13 layer13 protocol13 to13 carry13 CoAP13 packets
bull Representaon13 of13 URI13 scheme13 for13 generic13 transport13 protocols
bull Opon13 extensions13 for13 CoAP13 to13 express13 available13 transports
bull Mapping13 and13 message13 sizebull Security13 consideraons
56
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
URI13 =13 scheme13 13 13 authority13 path-shy‐abempty13 [13 query13 ]
bull Within13 the13 scheme13 namebull In13 the13 URI13 pathbull As13 a13 query13 component
57
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
bull Within13 the13 scheme13 namendash coap+tel+15105550101well-shy‐knowncorendash coap+tcpexamplecom5683temperaturendash coap+blel2cap[1234567890AB]4pulse
bull Easy13 URI13 parsing13 for13 transport13 type13 and13 idenfier
bull Each13 new13 scheme13 name13 requires13 IANA13 registraon
58
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
bull In13 the13 URI13 pathndash coaphostexamplecomtransport=tcpwell-shy‐knowncorert=core-shy‐rd
bull Easy13 adopon13 of13 new13 (and13 experimental)13 CoAP13 transports13 without13 IANA13 registraon
bull Caveat13 Uri-shy‐Path13 opon13 is13 a13 Crical13 CoAP13 opon13 see13 secon13 54113 of13 I-shy‐Diep-shy‐core-shy‐coap
59
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
bull As13 a13 URI13 query13 componentndash coaphostexamplecomwell-shy‐knowncorert=core-shy‐rdq=tcp
bull Also13 easy13 to13 adopt13 new13 (and13 experimental)13 CoAP13 transports13 without13 IANA13 registraon
bull Caveat13 Uri-shy‐Query13 opon13 is13 a13 Crical13 CoAP13 opon13 see13 secon13 54113 of13 I-shy‐Diep-shy‐core-shy‐coap
60
031113
URI13 Representaons13 for13 CoAPNon13 standard13 ways
bull Transport13 in13 the13 URI13 authority13 componentndash coaphost[port][transport]13 instead13 of13 coaphost[port]
bull Transport13 as13 a13 service13 URLndash servicecoaptcphostexamplecomwell-shy‐knowncorert=core-shy‐rd
bull Above13 two13 ways13 break13 exisng13 compability13 (although13 both13 are13 based13 on13 valid13 IANA13 URI13 registraons)
61
031113
URI13 Representaons13 for13 CoAPMiscellaneous13 Consideraons
bull Ensure13 that13 transport13 is13 defined13 unambiguously13 (eg13 L2CAP13 used13 by13 both13 BLE13 and13 standard13 Bluetooth13 so13 avoid13 rdquocoap+l2caprdquo13 or13 rdquotransport=l2caprdquo13 or13 rdquoq=l2caprdquondash Can13 be13 done13 as13 WG13 consensusndash Namespace13 approach13 eg13 rdquocoap+blel2caprdquo13 or13 rdquoq=blel2caprdquo
bull Allow13 end-shy‐points13 to13 use13 CoAP13 Resource13 Directory13 to13 register13 alternave13 transports13 and13 idenfiers13 and13 provide13 periodic13 updatesndash Register13 rdquocore-shy‐transportrdquo13 resource13 type
62
031113
Transport13 Consideraons
bull Uniqueness13 of13 end-shy‐point13 idenficaonbull Communicaon13 support13 Unidireconal13 Bidireconal13 1N13 (broadcast13 mulcast13 anycast)13 messaging
bull Binary13 encoding13 Network13 byte13 orderingbull MTU13 correlaon13 with13 CoAP13 PDU13 sizebull Transport13 latency
63
031113
Security13 Consideraons
bull Drar13 does13 not13 introduce13 new13 security13 requirements13 by13 itself
bull There13 may13 be13 privacy13 issues13 if13 nodes13 use13 telephone13 numbers13 or13 MAC13 addresses13 as13 public13 end13 point13 idenfiers
64
Akbar Rahman
IETF 86 March 2013 httpwwwietforgiddraft-rahman-core-sleepy-02txt
Enhanced Sleepy Node Support for CoAP
Introduction
It is expected that in CoAP networks there will be a certain portion of devices that are sleepy and which may occasionally go into a sleep mode (ie go into a low power state to conserve power) and subsequently have reduced CoAP protocol communication ability
This I-D proposes a minimal and efficient mechanism building on the Resource Directory concept (which will be integrated into a CoAP Proxy) to enhance sleepy node support in CoAP networks
Main Question from IETF-85 (Atlanta)
What performance benefit does the proposed Sleepy Node support solution give in a network that already has standard CoAP caching enabled
Sleepy Node Performance Analysis
Experimental Network
1-5 clients
Both Sleepy and Non-
Sleepy servers
Sleepy Node Performance Analysis Network Setup
CoAPSleepyServer(s)
CoAPSleepAwareReverseProxy
CoAP
Client(s)
Request
Response
Sleep9AwareCoREResourceDirectoryCapability
PublishedSleepParameters
Sleep9AwareCoAPStoreandForwardCapability Response
Request
SleepAwareCoAP503ResponseCapability
CoAPCachingCapability
bull Server supports publishing sleep parameters to proxy bull Eg Irsquom going to be asleep for X seconds
bull Proxy supports sleep-awareness capabilities bull Proxy also supports caching capability based off of maxAge bull Protocol flow similar to approach of Figure 1 (Synchronous RD Based Sleep
Tracking) of I-D
Proxy capabilities can be selectively enableddisabled
Proxy ndash Server Interface
Client ndash Proxy Interface
CoAP Sleep-Aware Reverse Proxy Features CoRE Sleep-aware Resource Directory
Support storing published sleep parameters from CoAP servers sleepState (AWAKE ASLEEP) sleepDuration
Sleep-aware CoAP 503 Response Capability If CoAP request to a sleeping server is received proxy returns a
lsquo503 Retry-Afterrsquo response to client 503 contains a timestamp indicating when the sever will wake back up
(timestamp delivered in CoAP maxAge option) Sleep-aware CoAP Store-and-Forward Capability
If CoAP request to a sleeping server is received proxy stores request until server wakes up and then forwards it
Caching capability Cache GET responses from server if maxAge option is present
(this is not a sleep aware feature)
Goals of Performance Analysis
For networks having sleepy servers provide measurements to quantify the impact that CoAP sleep-awareness capabilities can have
See if sleep-awareness capabilities can
provide additional benefits even when CoAP caching is used
Overview of Performance Analysis Performed The analysis was broken up into a set of test scenarios Each test scenario used a different combination of the following
variables Client issued GET requests Server was configured as a sleepy or non-sleepy server Proxy caching of GET responses was enabled or disabled Proxy sleep-aware 503 response capability was enabled or disabled Proxy store-and-forward capability was enabled or disabled maxAge in GET responses ndash Two values were tested 60sec and 5sec of Clients ndash Two values were used ndash 1 client and 5 clients
For comparison purposes the following were held constant across all test scenarios Client issued a fixed number of requests (100) across all test scenarios Client used a delay between each GET request (35sec) to better exercise
proxyrsquos caching and sleep-awareness capabilities For sleepy server test scenarios the server slept 60 sec awake for 3 sec
Format of Results The following results were collected for each
test scenario
Breakdown of the and types of transactions occurring between clientproxyserver
ldquoGETrdquo ndash Test Scenario Results
GET ndash Description of Test Scenarios
TestScenarios-GET
Scenario
CoAPSleepyServerSe7ngs CoAPSleepAwareReverseProxySe7ngs CoAPClientSe7ngs
SleepDuragton(sec)
AwakeDuragton(sec)
maxAge(sec) Caching SleepAwareSAF+
503NumberofClients
NumberofGETs
DelayBetweenClient
Requests(sec)
1a 0 Always 60 Enabled Disabled 1 100 35
1b 60 3 60 Enabled Disabled 1 100 35
1c 60 3 60 Enabled Enabled 1 100 35
2a 0 Always 60 Enabled Disabled 5 100 35
2b 60 3 60 Enabled Disabled 5 100 35
2c 60 3 60 Enabled Enabled 5 100 35
3a 0 Always 5 Enabled Disabled 5 100 35
3b 60 3 5 Enabled Disabled 5 100 35
3c 60 3 5 Enabled Enabled 5 100 35
ldquoGETrdquo ndash Test Scenario 1 Results
maxAge = 60 and 1 Client
GET ndash Scenario 1 ClientProxy Interface Transaction Mix
Scenarios 1a - Non-Sleepy Server Caching Proxy maxAge = 60sec 1b- Sleepy Server Caching Proxy maxAge = 60sec 1c - Sleepy Server Sleep Aware Proxy maxAge = 60sec
Sleep Aware Proxy has better performance for sleepy servers
0
100
200
300
400
500
600
700
1a 1b 1c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
GET ndash Scenario 1 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
Scenarios 1a - Non-Sleepy Server Caching Proxy maxAge = 60sec 1b- Sleepy Server Caching Proxy maxAge = 60sec 1c - Sleepy Server Sleep Aware Proxy maxAge = 60sec
0
100
200
300
400
500
600
700
800
1a 1b 1c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
ldquoGETrdquo ndash Test Scenario 2 Results
maxAge = 60 and 5 Clients
GET ndash Scenario 2 ClientProxy Interface Transaction Mix
Sleep Aware Proxy has slightly better performance for sleepy servers
0
200
400
600
800
1000
1200
1400
2a 2b 2c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
Scenarios 2a - Non-Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2b- Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2c - Sleepy Server Sleep Aware Proxy maxAge = 60sec 5 Clients
See ldquoExperimental Artifactsrdquo Note 1
GET ndash Scenario 2 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has slightly better performance for sleepy servers
0
50
100
150
200
250
300
350
400
2a 2b 2c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
Scenarios 2a - Non-Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2b- Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2c - Sleepy Server Sleep Aware Proxy maxAge = 60sec 5 Clients
See ldquoExperimental Artifactsrdquo Note 2
Experimental Artifacts Note 1
Currently in the experiment the sleep aware proxy checks the cached state of a resource before putting a request into its Store-and-forward queue while a server is sleeping Once in the queue the proxy unconditionally forwards the queued requests to the server once it wakes up This is not the most efficient setup and can easily be improved If the proxy instead checks its cache again before forwarding each queued request it may not need to forward the request to the server For example if there are two queued GET requests in the proxyrsquos queue that address the same resource Only the first request needs to be sent to the server the second request can use the cached response from the first request
Note 2 Currently in the experiment the sleepy server sends a sleepState PUT request to the
proxy each time it goes to sleep This is not the most efficient setup and can easily be improved For example if the server assumes that the proxy can keep track of its ONOFF cycles with its internal timers (eg as per Fig 1 of I-D) then the number of messages from the sleepy server dramatically goes down
ldquoGETrdquo ndash Test Scenario 3 Results
maxAge = 5 and 5 Clients
GET ndash Scenario 3 ClientProxy Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
Scenarios 3a - Non-Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3b- Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3c - Sleepy Server Sleep Aware Proxy maxAge = 5sec 5 Clients
0
500
1000
1500
2000
2500
3000
3500
4000
4500
5000
3a 3b 3c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
GET ndash Scenario 3 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
0
1000
2000
3000
4000
5000
6000
7000
3a 3b 3c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
Scenarios 3a - Non-Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3b- Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3c - Sleepy Server Sleep Aware Proxy maxAge = 5sec 5 Clients
Conclusions
Conclusions These results show that sleep-aware CoAP
proxy features can significantly optimize communication with sleepy servers in most scenarios
These results also show that sleep-
awareness capabilities can provide additional benefits above and beyond CoAP caching in most scenarios
Backup
Current CoAP Support of Sleepy Node (12)
CoAP proxies can use a previously cached response to service a new GET request for a sleepy origin server (as in HTTP) But if no valid cache then proxy has to attempt to
retrieve and may fail if origin server is sleeping [I-Dietf-core-coap]
Clients can discover list of resources from RD (GET rd-lookuphellip) for sleepy servers But attempt to GET resource from sleepy origin server
may fail if origin server is sleeping [IDietf-core-link-format amp IDshelby-core-resource-
directory]
Current CoAP Support of Sleepy Node (22)
Lower layer support for sleepy nodes in most wireless technologies (eg WiFi ZigBee) But limited to MAC packet scheduling for sleepy nodes
and not aware of specific needs of IP applications (like CoAP)
Proposal ndash RD Based Sleep Tracking (14)
The current CoAP approach to support sleepy nodes can be significantly improved by introducing RD based mechanisms for a CoAP client to determine whether A targeted resource is located on a sleepy server A sleepy server is currently in sleep mode or not
There is any associated caching Proxy (possibly the RD itself) for a sleepy server
Proposal ndash RD Based Sleep Tracking (24)
We define the following new RD attributes to characterize the properties of a sleepy node SleepState - Indicates whether the node is currently in
sleep mode or not (ie Sleeping or Awake) SleepDuration - Indicates the maximum duration of time
that the node stays in sleep mode TimeSleeping - Indicates the length of time the node
has been sleeping (ie if Sleep State = Sleeping) NextSleep - Indicates the next time the node will go to
sleep (ie if Sleep State = Awake)
CachingProxy ndash Indicates the caching proxy of the sleepy node (ie the RD itself or another node)
Proposal ndash RD Based Sleep Tracking (34)
These attributes are all server (node) level and are new parameters added to the RD URI Template Variables
Finally we also define a new lookup-type (ss) for the RD lookup interface specified in [I-Dshelby-core-resource-directory] This new lookup-type supports looking up the
ldquoSleepStaterdquo (ss) of a specified end-point
Proposal ndash RD Based Sleep Tracking (44)
The three time based parameters (SleepDuration TimeSleeping NextSleep) can be based on either an absolute network time (for a time synchronized network) or a relative local time (measured at the local node)
Following the approach of [I-Dietf-core-link-format] and [I-Dshelby-core-resource-directory] sleep parameters for sleepy servers can be stored by the server in the RD and accessed by all interested clients
Examples of using these parameters in a synchronous or asynchronous manner are shown in the I-D
http6lowappnet coreIETF86 2013-03-12-13
We assume people have read the drafts
Meetings serve to advance difficult issues by making good use of face-to-face communications
Note Well Be aware of the IPR principles according to RFC 3979 and its updates
uumlBlue sheetsuumlScribe(s)
96
drar-shy‐iep-shy‐core-shy‐coapsubmiqed13 to13 IESG
2013-shy‐03-shy‐13
97
OMA Lightweight M2M Overview(A new standard using lots of IETF specs including DTLS
CoAP Block Observe Resource Directory SenMLhellip)
Zach ShelbyCoRE WG IETF-86 Orlando
OMA Lightweight M2Mbull Open Mobile Alliance is well known for Device Management (DM)bull OMA Lightweight M2M is a new standard from the alliance
ndash Focused on constrained Cellular and sensor network M2M devicesndash Driven by leading operators and vendors
bull Scopendash Interfaces protocol amp security between Device and Serverndash Object and Resource modelndash Bootstrap Device Access Control Connectivity and Firmware Objects
bull Draft Specifications are availablendash httpmemberopenmobileallianceorgftpPublic_documentsDM
LightweightM2MPermanent_documentsOMA-TS-LightweightM2M-V1_0_0-20130301-Dzip
bull Timelinendash Requirements and Architecture completed 3Q2012ndash Spec ready for Consistency Review 2Q2013ndash Candidate Approval expected 3Q2013
2 CoRE WG IETF-86 Orlando
Architecture
3
Scope of LWM2M
CoRE WG IETF-86 Orlando
Object Model
bull A Client has one or more Object Instancesbull An Object is a collection of Resourcesbull A Resource is an atomic piece of information
ndash Read Written or Executed
bull Resources can have multiple instancesbull Objects and Resources are identified by a
16-bit Integer Instances by an 8-bit Integerbull ObjectsResources are accessed with
simple URIs Object IDObject InstanceResource ID
eg 1213
4 CoRE WG IETF-86 Orlando
CoRE WG IETF-86 Orlando
CoRE Resource Directory
draft-shelby-core-resource-directory-05
Z Shelby C Bormann S Krco
Backgroundbull Not a new concept
ndash think web search engine or any link directorybull Defines the interfaces to a Resource Directorybull Based on Web Linking framework and the CoRE Link Formatbull Generic REST design for use over HTTP and CoAPbull Used by OMA Lightweight M2Mbull Has already been deployed
ndash In traffic monitoring systemsndash In street lighting systemsndash For vehicular asset trackingndash By a major Cellular M2M operator
Changes since -04
bull Restricted Update to parameter updatesbull Added pagination support for the Lookup interfacebull Changed rt= to et= for the registration amp update
interfacebull Added group support
Group Management
bull RD now includes group management featuresbull New Group Function Set
ndash Register a groupbull Group name domain multicast address endpoint members
ndash Remove a groupbull Group lookup using the Lookup Function Set
ndash List registered groupsndash Find the members of a groupndash Find groups with certain endpoints or resources
Registering a Group
EP RD
| |
| - POST rd-groupgp=lights ltgtep=node1 --gt |
| |
| |
| lt---- 201 Created Location rd-group12 ---- |
| |
Req POST coaprdexamplecomrd-groupgp=lights
Payload
ltgtep=node1
ltgtep=node2
Res 201 Created
Location rd-group12
Looking up Group Members
Client RD
| |
| ----- GET rd-lookupepgp=lights1 ----------------------gt |
| |
| |
| lt-- 205 Content ltrdgtd=domain1ltrdgtd=domain2 --------- |
| |
Req GET rd-lookupepgp=lights1
Res 205 Content
ltcoaphostportgtep=node1
ltcoaphostportgtep=node2rdquo
Things for the futurebull Support for JSON representation of Web Links
ndash httptoolsietforgiddraft-bormann-core-links-json-02txtbull Registry for RD registration query parameters
ndash Already OMA Lightweight has defined some new onesbull More examples
Group 3 ldquonew workrdquo(continued)
109
drar-shy‐greevenbosch-shy‐core-shy‐profile-shy‐descripon-shy‐01Bert13 GreevenboschJeroen13 Hoebeke
Isam13 IshaqFloris13 Van13 den13 Abeele
Descripon
bull JSON13 format13 for13 signalling13 the13 servers13 capabilies
bull Signalling13 of13 supported13 opons13 media13 types13 and13 block13 sizendash Other13 items13 can13 be13 added
bull Filtering13 on13 specific13 fields13 through13 URI-shy‐Querybull Link13 hqpdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐profile-shy‐descripon
well-shy‐knownprofile
bull To13 acquire13 profile13 data13 of13 resources13 on13 a13 parcular13 service13 the13 well-shy‐knownprofile13 URI-shy‐path13 is13 introduced
bull For13 example13 to13 get13 all13 informaon13 from13 sensors13 served13 by13 wwwexampleorg13 we13 can13 do13 a13 GET13 to13 coapwwwexampleorgwell-shy‐knownprofile
bull Filtering13 on13 parcular13 resources13 is13 done13 through13 URI-shy‐Queries
Format
bull Currently13 the13 following13 fields13 are13 definedndash ldquopathrdquo13 contains13 the13 URI-shy‐path13 associated13 with13 a13 resource
ndash ldquooprdquo13 a13 numerical13 list13 of13 supported13 opon13 numbers
ndash ldquocfrdquo13 a13 numerical13 list13 of13 supported13 content-shy‐format13 numbers
ndash ldquob1srdquo13 ldquob2srdquo13 supported13 block13 sizes13 for13 Block113 and13 Block213 respecvely
Examplebull On13 the13 right13 is13 an13 example13 of13 a13 camera13 sensor13 at13 coapwwwexampleorgcam13 that13 supports13 the13 Uri-shy‐Host13 (3)13 ETag13 (4)13 Uri-shy‐Port13 (7)13 Uri-shy‐Path13 (11)13 Content-shy‐Format13 (12)13 Token13 (19)13 Block213 (23)13 and13 Proxy-shy‐Uri13 (35)13 opons
bull The13 supported13 content13 formats13 are13 textplain13 (0)13 applicaon13 link-shy‐format13 (40)13 and13 applicaonjson13 (50)
bull The13 supported13 Block213 can13 use13 25613 or13 51213 byte13 blocks
Req13 GET13 coapwwwexampleorgwell-shy‐knownprofile13 Res13 20513 Content13 (applicationjson)13 13 13 13 profile13 13 13 13 13 13 13 13 pathcam13 13 13 13 op[3471112192335]13 13 13 13 13 cf[04050]13 13 13 13 13 b2s[45]13 13 13 13
Filtering13 through13 use13 of13 URI-shy‐Query
bull Filtering13 can13 be13 done13 through13 the13 URI-shy‐Querybull Query13 format13 N=V
ndash N13 is13 a13 profile13 fieldndash V13 is13 the13 desired13 value
bull Examplesndash To13 find13 resources13 that13 support13 content13 format13 ldquoapplicaonjsonrdquo
13 GET13 wwwexampleorgwell-shy‐knownprofilecf=50ndash To13 get13 informaon13 about13 the13 camera
13 GET13 wwwexampleorgwell-shy‐knownprofilepath=cam
Open13 issues
bull Which13 other13 profile13 data13 needs13 signallingndash Content-shy‐type13 for13 different13 methods
bull Fix13 the13 order13 in13 which13 the13 profile13 fields13 must13 appearndash Non-shy‐fixed13 order13 easier13 extensible
bull Inheritance13 of13 a13 profile13 descriponbull Extend13 usage13 to13 signal13 the13 client13 profilebull Integraon13 with13 link13 format
Thank13 youQuesons
drar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval-shy‐00
Bert13 Greevenbosch
Descripon
bull The13 ldquoMinimumRequestInterval13 opon13 can13 be13 used13 to13 indicate13 the13 minimum13 me13 between13 two13 requests13 in13 a13 transacon
bull Originally13 intended13 for13 Block13 but13 also13 usable13 for13 other13 transaconsndash Example13 browsing13 a13 server
bull The13 goal13 is13 to13 reduce13 the13 server13 load13 and13 network13 traffic
bull Link13 hqpsdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval
Usage
bull The13 client13 keeps13 the13 server13 informed13 about13 its13 request13 speed13 through13 inclusion13 of13 the13 ldquoMinimumRequestIntervalrdquo13 opon
bull In13 responses13 the13 server13 fixes13 the13 minimum13 request13 interval13 through13 the13 same13 opon
bull The13 client13 obeys13 the13 speed13 indicated13 by13 the13 server
bull The13 client13 can13 send13 slower13 but13 not13 faster
Advantages
bull The13 server13 has13 means13 to13 limit13 the13 amount13 of13 incoming13 traffic
bull The13 server13 can13 prevent13 to13 become13 overloaded13 with13 too13 many13 tasks
bull The13 server13 does13 not13 need13 arficially13 slow13 down13 the13 client13 by13 sending13 late13 ACKsndash No13 need13 to13 keep13 track13 of13 delayed13 ACKsndash The13 server13 can13 perform13 other13 tasks13 instead
bull Reduced13 network13 traffic
Thank13 youQuesons
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-links-json-02txt
123
RFC 6690 (link-format) documents are somewhat foreign to many web app developerssect would prefer to have them in JSON format
There is no standard way to represent link-format documents in applicationssect but everyone knows how to handle JSON
Define a standard JSON translation for link-format
Itrsquos
not
rock
et
scien
ce
ltsensorsgtct=40title=Sensor Index ltsensorstempgtrt=temperature-cif=sensor ltsensorslightgtrt=light-luxif=sensor lthttpwwwexamplecomsensorst123gt anchor=sensorstemprel=describedby lttgtanchor=sensorstemprel=alternate [hrefsensorsct40titleSensor Index hrefsensorstemprttemperature-cifsensor hrefsensorslightrtlight-luxifsensor hrefhttpwwwexamplecomsensorst123 anchorsensorstempreldescribedby hreftanchorsensorstemprelalternate]
124
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-ipsec-for-coap-00txt
IPsec definitions for CoAP Mostly placeholder at this time Who has implementation experience with this
125
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-cross-reverse-convention-00txt
This draft has two lines of payload(based on a WGLC comment by Cullen Jennings)
coap12344567foobara=3
httpwwwproxycomwellknowncore-translate1234_4567foobara=3
Is that a useful convention to have
126
Insert CI slides here
127
128
0
5
10
15
20
25
30
35
40
10 20 30 40 50 60 70
good
put (
pps)
pps
Goodput vs pps (Econotags)
goodput
[Khattak preliminary]
Congestion Control
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-cocoa-00txt
ldquoadvancedrdquo cc (The draft is just a first shot) Others may have better ideas
129
Insert post-WGLC discussion slides here
130
Stop Continue Start
131
An Agile Retrospective
http6lowappnet coreIETF86 2013-03-12-13
Stop
132
Endless new CoAP optionssect instead use RESTful as much as possible
Move general security lifecycle out Looking at theoretical problems
http6lowappnet coreIETF86 2013-03-12-13
Continue
Interops Running code Look at real-world examples and deployments Solve their actual problems
sect Unilateral enhancements eg higher performance congestion control
sect Transports (SMS hellip)sect Make Web linking and Directories more and more usefulsect RESTful Design Paradigms for real-world problems
133
http6lowappnet coreIETF86 2013-03-12-13
Start
Further push into the (browser) web world (HTML5 browser security)
Specific supporting worksect SenMLsect URI work (dev URN hellip)sect Security Processes (next slide)
Spin outsect (We donrsquot really get to decide where this is done)
134
http6lowappnet coreIETF86 2013-03-12-13
Security
Integrate Application Network Group Keyingsect Tunnel-free setup
Donrsquot redo what has been done alreadysect ZigBee IP is finesect But what about other scenarios
Simple REST interfaces for working with keying materials and authorizationsect Start with defining objectives
Object Security for Constrained Nodes135
Re-chartering CoREWhat do we want to do now that wersquore grown up
Zach ShelbyCoRE WG IETF-86 Orlando
What is the scope
bull So we have a protocol and Web Linking what next
bull Keep with what we know besthellip1 Enhancements around CoAP2 New transports for CoAP3 New representations for Web Links4 General application layer solutions
CoRE WG IETF-86 Orlando 2
Enhancements around CoAP
bull Advanced congestion control
CoRE WG IETF-86 Orlando 3
New Transports for CoAP
bull Infrastructure for CoAP over foondash httptoolsietforgiddraft-silverajan-core-
coap-alternative-transports-01txtbull CoAP over SMS
ndash httptoolsietforgiddraft-becker-core-coap-sms-gprs-03txt
ndash OMA Lightweightbull CoAP over TCP
ndash httptoolsietforgiddraft-li-core-coap-payload-length-option-01txt
CoRE WG IETF-86 Orlando 4
New support for Web Links
bull JSON Web Linksndash httptoolsietforgiddraft-bormann-core-links-
json-02txt
2332010 CoRE WG IETF-77 Anaheim 5
General application layer solutions
bull Resource Directoryndash httptoolsietforgiddraft-shelby-core-
resource-directory-05txtndash OMA Lightweight
2332010 CoRE WG IETF-77 Anaheim 6
Open Issues(25)
n Add section on multicast via Proxy and its limitations (274)n Add a section to explain the issues amp limitations of doing CoAP multicast
requests via a CoAP Proxy n Goal is to warn and guide implementers in this subject n Also such a section would provide a placeholderreminder of the problems
that might be addressed further in the futuren Based on IETF 85 CoRE WG meeting discussion on Multicast CoAP
requests via a Proxy Discussion summary for referencen Aggregation of responses in a proxy is difficult since it doesnt know
when to stop aggregating responses n SIP tried to deal with this problem but didnt solve it n There may be an expectancy of CoAP client to get single response
back from proxy not multiple The client in this case may not even know what it could expect It may not even know the Proxy-URI contains a multicast target
n Presented via-proxy use case exposes gap in the core-coap specification regarding multicast via proxy (Note Expectation is that core-coap wonrsquot address it in the first planned RFC release)
Open Issues(35)
n Issues with twomultiple Resource Directories in use case (280)n Some potential issues with RD came out of review Peter van der Stok and
WG discussion IETF85 n There are two RD servers use case shows that only one is found despite
the fact that site-local multicast is used - should be two RDs found n Proposal simplify use case to a single RD server on the backbone to avoid
such RD-specific issues like synchronization of RD information between servers
Open Issues(45)
n Add single-subnet configuration to use cases (278)n Suggested by review Peter van der Stok and IETF85 WG discussion that
its best to start explaining the simplebasic cases and then gradually build up complexity
n Simplest case not shown yet would be a single subnet network configuration which is currently not present in the I-D only the 2-subnet configuration of Fig 1
n Question Do we need to add such case or doesnt it add muchn (Note that core-coap Figure 22 already shows the simplest case of link-local
multicast)
Open Issues(55)
n Add use case with controller (client) located on the backbone (279)n Suggested by discussion following review Peter van der Stok n Case missing where a controller (client) is located on the backbonen Question Do we need to add such case or does it add much
Group 2a other old friends
25
Angelo Castellani Salvatore Loreto Akbar Rahman Thomas Fossati Esko Dijk
IETF 86 March 2013httpwwwietforgiddraft-castellani-core-http-mapping-07txt
Best Practices for HTTP-CoAP Mapping
Implementation
Summary of Changes (from -06 rev)
n Based on discussion at last IETF-85 (Atlanta)n Clarification of HTTP-CoAP Proxies
n Definitionn Placementn Benefits
n Clarification of HTTP-CoAP URI mapping options
Goals of I-D
n For Reverse HTTP-CoAP Cross Protocol Proxyn Provide more detailed information to proxy designers (beyond
Section 10 of [I-Dietf-core-coap]) to help implement proxies that correctly inter-work with other CoAP and HTTP clientserver implementations that adhere to the specifications
n Define a consistent set of guidelines that a HTTP-to-CoAP proxy implementation MAY adhere to The main reason of adhering to such guidelines is to reduce variation between proxy implementations thereby increasing interoperabilityn As an example use case a proxy conforming to these guidelines made
by vendor A can be easily replaced by a proxy from vendor B that also conforms to the guidelines
I-D Outline
n Guidance on HTTP to CoAP URI mappingn HTTP-CoAP Reverse cross-protocol proxy implementation
n Placementn Response code amp media type translationsn Caching and congestion controln Cache refresh via Observen Use of CoAP blockwise transfern Security translation
n Security Considerationsn Traffic overflown Handling secured exchanges
Definitions (12)
n Cross-Protocol Proxy (or Cross Proxy) is a proxy performing a cross- protocol mapping in the context of this document a HTTP-CoAP (HC) mapping A Cross-Protocol Proxy can behave as a Forward Proxy Reverse Proxy or Interception Proxy n Note In this document we focus on the Reverse Proxy mode of the
Cross-Protocol Proxy
n Forward Proxy a message forwarding agent that is selected by the client usually via local configuration rules to receive requests for some type(s) of absolute URI and to attempt to satisfy those requests via translation to the protocol indicated by the absolute URI The user decides (is willing to) use the proxy as the forwardingdereferencing agent for a predefined subset of the URI space
Definitions (22)
n Reverse Proxy a receiving agent that acts as a layer above some other server(s) and translates the received requests to the underlying servers protocol It behaves as an origin (HTTP) server on its connection towards the (HTTP) client and as a (CoAP) client on its connection towards the (CoAP) origin server The (HTTP) client uses the origin-form [I-Dietf-httpbis-p1-messaging] as a request- target URI
n Reverse and Forward proxies are technically very similar with main differences being that the former appears to a client as an origin server while the latter does not and that clients may be unaware they are communicating with a proxy
Reverse Cross-Protocol Proxy Deployment Scenario
HTTP-CoAP Response Code Mapping
Implementation Experience
n Direct experience from the draft authorsn Squid HTTP-CoAP mapping module
n University of Padovan httptelecomdeiunipditiotn Both Forward and Interception operation supported
n HTTP-CoAP proxy based on EvCoAPn KoanLogic University of Bologna and Salvatore
Loreto (as individual)n httpsgithubcomkoanlogicwebthingstreemasterbridgesw
libevcoapn The document is open to input from other implementations
Next Steps
n Does the WG recommend adoptionn Intended status Informational Best Practicen Purpose Reduce arbitrary variation between proxy
implementations thereby increasing interoperability
Backup
HTTP to CoAP URI Mapping Options (12)
n Embedded Mapping n In an embedded mapping approach the HTTP URI has embedded
inside it the authority and path part of the CoAP URI n Example The CoAP resource nodecoapsomethingnetfoo can
be accessed by an HTTP client by inserting in the request httphc-proxysomethingnetcoapnodecoapsomethingnetfoo The Cross-Protocol Proxy then maps the URI to coapnodecoapsomethingnetfoo
HTTP to CoAP URI Mapping Options (22)
n Homogeneous Mapping n In a homogeneous mapping approach only the scheme portion of the URI
needs to be mapped The rest of the URI (ie authority path etc) remains unchanged
n Example The CoAP resource coapnodecoapsomethingnetfoo can be accessed by an HTTP client by requesting httpnodecoapsomethingnetfoo The Cross-Protocol Proxy receiving the request is responsible to map the URI to coapnodecoapsomethingnetfoo
n Background info n The assumption in this case is that the HTTP client would be able to
successfully resolve nodecoapsomethingnet using DNS infrastructure to return the IP address of the HC proxy Most likely this would be through a two step DNS lookup where the first DNS lookup would resolve somethingnet using public DNS infrastructure
n Then the second DNS lookup on the subdomain coap and the host node would typically be resolved by a DNS server operated by the owner of domain somethingnet So this domain owner can manage its own internal node names and subdomain allocation which would correspond to the CoAP namespace
Group 3 ldquonew workrdquo
39
Transport of CoAP over SMS USSD and GPRSdraft-becker-core-coap-sms-gprs-03
Markus Becker Kepeng LiKoojana Kuladinithi Thomas Poumltsch
CoRE WG IETF-86 Orlando
1 10
ScenariosI In M2M communication IP connectivity is not alwayssupported by the constrained end-points
I Power savingI Coverage (GPRS 3G LTE)
I SMS and USSD based communication is almost alwayssupported
210
Changes from draft-01 to draft-03 (1)
I Added possible CONNONACK interactions Section 5
I Option name changed from Reply-To- to Response-To-Section 16 and Section 101
I Added URI schemeEg coap+tel+15105550101well-knowncore Section 11
I Added possible M2M proxy scenarios Section 14
3 10
Changes from draft-01 to draft-03 (2)
I Added reference to bormann-coap-misc for other SMSencoding Section 71
I Updated requirements on Uri-Host and Uri-Port forcoap+tel Section 10
I Added security considerations Transport and ObjectSecurity Section 15
I Chose CoAP option numbers and updated the optionnumber table to meet draft-ietf-core-coap-10 Table 1
I Added an IANA registration for the URI scheme coap+telSection 162
4 10
Feedback Split coap+tel into coap+smsand coap+ussd
I How else to differ the various transports in the URII Or is the transport to use decided by the implementationI See alsodraft-silverajan-core-coap-alternative-transports-01
5 10
Feedback Response-To-Scheme option
I Should there be a Response-To-Scheme optionadditionally to Response-To-Uri-Host andResponse-To-Uri-Path
I So that a CoAP end-point which receives a request by CoAPover non-IP transport can be instructed to also use thenon-IP transport for the response
I This would imply to add aResponse-To-Telephone-Subscriber and more options forother transports that have other URI schemes than coapand coaps
6 10
Feedback Selection of Transport by Client
I When a server is reachable by various transports howdoes a client decide which transport to use
I Client-side application congurationI Leave it to a proxy which uses cellular network lookupfunctions
7 10
Feedback Potential Threats
I Trigger expensive short messagesI Redirect trac to other addressesI More threats
I Are the security measures in the draft adequateI Whitelisting on serverI Relying on cellular network security (dedicated M2M APNs)I Object security on CoAP payload
8 10
Feedback Message Exchanges
I Figures 11-18 show possible message exchanges whenclient and server have two addresses
I With NON Not using CoAP retransmission capabilityI ACK on different transportI Additional (costly) message on Transport AI Request with Content
I Which ones are allowedI Which ones are meaningful
9 10
Next steps
I Rene Uri schemeI Response-To-Scheme optionI Selection of Message ExchangeI Rene Proxying
10 10
CoAP13 Communicaon13 with13 Alternave13 Transports
Bill Silverajan and Teemu SavolainenCore WG IETF 86 Orlando
031113
Objecves13 (In13 Scope)
bull Unambiguous13 representaon13 of13 transport13 to13 be13 used13 by13 CoAP
bull Details13 how13 the13 transport13 can13 carry13 CoAP13 packet
bull Focus13 is13 on13 what13 CoAP13 communicaons13 requirements13 are
bull Allow13 CoAP13 mechanisms13 to13 exploit13 cross-shy‐layer13 opmisaons
51
031113
Non13 Goals13 (Not13 in13 scope)
bull Applicaon-shy‐level13 QoS13 requirementsbull Real-shy‐me13 constraintsbull Ordering13 reliability13 congeson13 controlbull Applicaon13 and13 network13 adaptaonbull Mobility13 and13 readdressing13 supportbull Network13 protocol13 (eg13 IPsec)13 configuraon
52
031113
Use13 Cases
bull NAT13 and13 Firewall13 traversal13 with13 TCPbull Delay13 Tolerant13 Networkingbull Non-shy‐IP13 Low13 Energy13 Protocols
53
031113
Related13 Work
bull OMA13 Lightweight13 M2M13 Protocolbull CoAP13 over13 SMSGPRSUSSD
54
031113
What13 does13 the13 work13 entail
bull The13 ability13 to13 specify13 end13 point13 idenfiers13 and13 URIs13 to13 reflect13 which13 transport13 CoAP13 can13 use
bull The13 ability13 to13 register13 to13 resource13 directories13 resource13 types13 reflecng13 types13 of13 transport13 available
bull Ability13 for13 mul-shy‐transport13 nodes13 to13 select13 transport13 to13 use13 without13 significant13 alteraon13 to13 CoAP13 packet13 structure
55
031113
Points13 to13 consider
bull Requirements13 for13 transport13 layer13 protocol13 to13 carry13 CoAP13 packets
bull Representaon13 of13 URI13 scheme13 for13 generic13 transport13 protocols
bull Opon13 extensions13 for13 CoAP13 to13 express13 available13 transports
bull Mapping13 and13 message13 sizebull Security13 consideraons
56
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
URI13 =13 scheme13 13 13 authority13 path-shy‐abempty13 [13 query13 ]
bull Within13 the13 scheme13 namebull In13 the13 URI13 pathbull As13 a13 query13 component
57
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
bull Within13 the13 scheme13 namendash coap+tel+15105550101well-shy‐knowncorendash coap+tcpexamplecom5683temperaturendash coap+blel2cap[1234567890AB]4pulse
bull Easy13 URI13 parsing13 for13 transport13 type13 and13 idenfier
bull Each13 new13 scheme13 name13 requires13 IANA13 registraon
58
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
bull In13 the13 URI13 pathndash coaphostexamplecomtransport=tcpwell-shy‐knowncorert=core-shy‐rd
bull Easy13 adopon13 of13 new13 (and13 experimental)13 CoAP13 transports13 without13 IANA13 registraon
bull Caveat13 Uri-shy‐Path13 opon13 is13 a13 Crical13 CoAP13 opon13 see13 secon13 54113 of13 I-shy‐Diep-shy‐core-shy‐coap
59
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
bull As13 a13 URI13 query13 componentndash coaphostexamplecomwell-shy‐knowncorert=core-shy‐rdq=tcp
bull Also13 easy13 to13 adopt13 new13 (and13 experimental)13 CoAP13 transports13 without13 IANA13 registraon
bull Caveat13 Uri-shy‐Query13 opon13 is13 a13 Crical13 CoAP13 opon13 see13 secon13 54113 of13 I-shy‐Diep-shy‐core-shy‐coap
60
031113
URI13 Representaons13 for13 CoAPNon13 standard13 ways
bull Transport13 in13 the13 URI13 authority13 componentndash coaphost[port][transport]13 instead13 of13 coaphost[port]
bull Transport13 as13 a13 service13 URLndash servicecoaptcphostexamplecomwell-shy‐knowncorert=core-shy‐rd
bull Above13 two13 ways13 break13 exisng13 compability13 (although13 both13 are13 based13 on13 valid13 IANA13 URI13 registraons)
61
031113
URI13 Representaons13 for13 CoAPMiscellaneous13 Consideraons
bull Ensure13 that13 transport13 is13 defined13 unambiguously13 (eg13 L2CAP13 used13 by13 both13 BLE13 and13 standard13 Bluetooth13 so13 avoid13 rdquocoap+l2caprdquo13 or13 rdquotransport=l2caprdquo13 or13 rdquoq=l2caprdquondash Can13 be13 done13 as13 WG13 consensusndash Namespace13 approach13 eg13 rdquocoap+blel2caprdquo13 or13 rdquoq=blel2caprdquo
bull Allow13 end-shy‐points13 to13 use13 CoAP13 Resource13 Directory13 to13 register13 alternave13 transports13 and13 idenfiers13 and13 provide13 periodic13 updatesndash Register13 rdquocore-shy‐transportrdquo13 resource13 type
62
031113
Transport13 Consideraons
bull Uniqueness13 of13 end-shy‐point13 idenficaonbull Communicaon13 support13 Unidireconal13 Bidireconal13 1N13 (broadcast13 mulcast13 anycast)13 messaging
bull Binary13 encoding13 Network13 byte13 orderingbull MTU13 correlaon13 with13 CoAP13 PDU13 sizebull Transport13 latency
63
031113
Security13 Consideraons
bull Drar13 does13 not13 introduce13 new13 security13 requirements13 by13 itself
bull There13 may13 be13 privacy13 issues13 if13 nodes13 use13 telephone13 numbers13 or13 MAC13 addresses13 as13 public13 end13 point13 idenfiers
64
Akbar Rahman
IETF 86 March 2013 httpwwwietforgiddraft-rahman-core-sleepy-02txt
Enhanced Sleepy Node Support for CoAP
Introduction
It is expected that in CoAP networks there will be a certain portion of devices that are sleepy and which may occasionally go into a sleep mode (ie go into a low power state to conserve power) and subsequently have reduced CoAP protocol communication ability
This I-D proposes a minimal and efficient mechanism building on the Resource Directory concept (which will be integrated into a CoAP Proxy) to enhance sleepy node support in CoAP networks
Main Question from IETF-85 (Atlanta)
What performance benefit does the proposed Sleepy Node support solution give in a network that already has standard CoAP caching enabled
Sleepy Node Performance Analysis
Experimental Network
1-5 clients
Both Sleepy and Non-
Sleepy servers
Sleepy Node Performance Analysis Network Setup
CoAPSleepyServer(s)
CoAPSleepAwareReverseProxy
CoAP
Client(s)
Request
Response
Sleep9AwareCoREResourceDirectoryCapability
PublishedSleepParameters
Sleep9AwareCoAPStoreandForwardCapability Response
Request
SleepAwareCoAP503ResponseCapability
CoAPCachingCapability
bull Server supports publishing sleep parameters to proxy bull Eg Irsquom going to be asleep for X seconds
bull Proxy supports sleep-awareness capabilities bull Proxy also supports caching capability based off of maxAge bull Protocol flow similar to approach of Figure 1 (Synchronous RD Based Sleep
Tracking) of I-D
Proxy capabilities can be selectively enableddisabled
Proxy ndash Server Interface
Client ndash Proxy Interface
CoAP Sleep-Aware Reverse Proxy Features CoRE Sleep-aware Resource Directory
Support storing published sleep parameters from CoAP servers sleepState (AWAKE ASLEEP) sleepDuration
Sleep-aware CoAP 503 Response Capability If CoAP request to a sleeping server is received proxy returns a
lsquo503 Retry-Afterrsquo response to client 503 contains a timestamp indicating when the sever will wake back up
(timestamp delivered in CoAP maxAge option) Sleep-aware CoAP Store-and-Forward Capability
If CoAP request to a sleeping server is received proxy stores request until server wakes up and then forwards it
Caching capability Cache GET responses from server if maxAge option is present
(this is not a sleep aware feature)
Goals of Performance Analysis
For networks having sleepy servers provide measurements to quantify the impact that CoAP sleep-awareness capabilities can have
See if sleep-awareness capabilities can
provide additional benefits even when CoAP caching is used
Overview of Performance Analysis Performed The analysis was broken up into a set of test scenarios Each test scenario used a different combination of the following
variables Client issued GET requests Server was configured as a sleepy or non-sleepy server Proxy caching of GET responses was enabled or disabled Proxy sleep-aware 503 response capability was enabled or disabled Proxy store-and-forward capability was enabled or disabled maxAge in GET responses ndash Two values were tested 60sec and 5sec of Clients ndash Two values were used ndash 1 client and 5 clients
For comparison purposes the following were held constant across all test scenarios Client issued a fixed number of requests (100) across all test scenarios Client used a delay between each GET request (35sec) to better exercise
proxyrsquos caching and sleep-awareness capabilities For sleepy server test scenarios the server slept 60 sec awake for 3 sec
Format of Results The following results were collected for each
test scenario
Breakdown of the and types of transactions occurring between clientproxyserver
ldquoGETrdquo ndash Test Scenario Results
GET ndash Description of Test Scenarios
TestScenarios-GET
Scenario
CoAPSleepyServerSe7ngs CoAPSleepAwareReverseProxySe7ngs CoAPClientSe7ngs
SleepDuragton(sec)
AwakeDuragton(sec)
maxAge(sec) Caching SleepAwareSAF+
503NumberofClients
NumberofGETs
DelayBetweenClient
Requests(sec)
1a 0 Always 60 Enabled Disabled 1 100 35
1b 60 3 60 Enabled Disabled 1 100 35
1c 60 3 60 Enabled Enabled 1 100 35
2a 0 Always 60 Enabled Disabled 5 100 35
2b 60 3 60 Enabled Disabled 5 100 35
2c 60 3 60 Enabled Enabled 5 100 35
3a 0 Always 5 Enabled Disabled 5 100 35
3b 60 3 5 Enabled Disabled 5 100 35
3c 60 3 5 Enabled Enabled 5 100 35
ldquoGETrdquo ndash Test Scenario 1 Results
maxAge = 60 and 1 Client
GET ndash Scenario 1 ClientProxy Interface Transaction Mix
Scenarios 1a - Non-Sleepy Server Caching Proxy maxAge = 60sec 1b- Sleepy Server Caching Proxy maxAge = 60sec 1c - Sleepy Server Sleep Aware Proxy maxAge = 60sec
Sleep Aware Proxy has better performance for sleepy servers
0
100
200
300
400
500
600
700
1a 1b 1c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
GET ndash Scenario 1 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
Scenarios 1a - Non-Sleepy Server Caching Proxy maxAge = 60sec 1b- Sleepy Server Caching Proxy maxAge = 60sec 1c - Sleepy Server Sleep Aware Proxy maxAge = 60sec
0
100
200
300
400
500
600
700
800
1a 1b 1c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
ldquoGETrdquo ndash Test Scenario 2 Results
maxAge = 60 and 5 Clients
GET ndash Scenario 2 ClientProxy Interface Transaction Mix
Sleep Aware Proxy has slightly better performance for sleepy servers
0
200
400
600
800
1000
1200
1400
2a 2b 2c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
Scenarios 2a - Non-Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2b- Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2c - Sleepy Server Sleep Aware Proxy maxAge = 60sec 5 Clients
See ldquoExperimental Artifactsrdquo Note 1
GET ndash Scenario 2 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has slightly better performance for sleepy servers
0
50
100
150
200
250
300
350
400
2a 2b 2c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
Scenarios 2a - Non-Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2b- Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2c - Sleepy Server Sleep Aware Proxy maxAge = 60sec 5 Clients
See ldquoExperimental Artifactsrdquo Note 2
Experimental Artifacts Note 1
Currently in the experiment the sleep aware proxy checks the cached state of a resource before putting a request into its Store-and-forward queue while a server is sleeping Once in the queue the proxy unconditionally forwards the queued requests to the server once it wakes up This is not the most efficient setup and can easily be improved If the proxy instead checks its cache again before forwarding each queued request it may not need to forward the request to the server For example if there are two queued GET requests in the proxyrsquos queue that address the same resource Only the first request needs to be sent to the server the second request can use the cached response from the first request
Note 2 Currently in the experiment the sleepy server sends a sleepState PUT request to the
proxy each time it goes to sleep This is not the most efficient setup and can easily be improved For example if the server assumes that the proxy can keep track of its ONOFF cycles with its internal timers (eg as per Fig 1 of I-D) then the number of messages from the sleepy server dramatically goes down
ldquoGETrdquo ndash Test Scenario 3 Results
maxAge = 5 and 5 Clients
GET ndash Scenario 3 ClientProxy Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
Scenarios 3a - Non-Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3b- Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3c - Sleepy Server Sleep Aware Proxy maxAge = 5sec 5 Clients
0
500
1000
1500
2000
2500
3000
3500
4000
4500
5000
3a 3b 3c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
GET ndash Scenario 3 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
0
1000
2000
3000
4000
5000
6000
7000
3a 3b 3c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
Scenarios 3a - Non-Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3b- Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3c - Sleepy Server Sleep Aware Proxy maxAge = 5sec 5 Clients
Conclusions
Conclusions These results show that sleep-aware CoAP
proxy features can significantly optimize communication with sleepy servers in most scenarios
These results also show that sleep-
awareness capabilities can provide additional benefits above and beyond CoAP caching in most scenarios
Backup
Current CoAP Support of Sleepy Node (12)
CoAP proxies can use a previously cached response to service a new GET request for a sleepy origin server (as in HTTP) But if no valid cache then proxy has to attempt to
retrieve and may fail if origin server is sleeping [I-Dietf-core-coap]
Clients can discover list of resources from RD (GET rd-lookuphellip) for sleepy servers But attempt to GET resource from sleepy origin server
may fail if origin server is sleeping [IDietf-core-link-format amp IDshelby-core-resource-
directory]
Current CoAP Support of Sleepy Node (22)
Lower layer support for sleepy nodes in most wireless technologies (eg WiFi ZigBee) But limited to MAC packet scheduling for sleepy nodes
and not aware of specific needs of IP applications (like CoAP)
Proposal ndash RD Based Sleep Tracking (14)
The current CoAP approach to support sleepy nodes can be significantly improved by introducing RD based mechanisms for a CoAP client to determine whether A targeted resource is located on a sleepy server A sleepy server is currently in sleep mode or not
There is any associated caching Proxy (possibly the RD itself) for a sleepy server
Proposal ndash RD Based Sleep Tracking (24)
We define the following new RD attributes to characterize the properties of a sleepy node SleepState - Indicates whether the node is currently in
sleep mode or not (ie Sleeping or Awake) SleepDuration - Indicates the maximum duration of time
that the node stays in sleep mode TimeSleeping - Indicates the length of time the node
has been sleeping (ie if Sleep State = Sleeping) NextSleep - Indicates the next time the node will go to
sleep (ie if Sleep State = Awake)
CachingProxy ndash Indicates the caching proxy of the sleepy node (ie the RD itself or another node)
Proposal ndash RD Based Sleep Tracking (34)
These attributes are all server (node) level and are new parameters added to the RD URI Template Variables
Finally we also define a new lookup-type (ss) for the RD lookup interface specified in [I-Dshelby-core-resource-directory] This new lookup-type supports looking up the
ldquoSleepStaterdquo (ss) of a specified end-point
Proposal ndash RD Based Sleep Tracking (44)
The three time based parameters (SleepDuration TimeSleeping NextSleep) can be based on either an absolute network time (for a time synchronized network) or a relative local time (measured at the local node)
Following the approach of [I-Dietf-core-link-format] and [I-Dshelby-core-resource-directory] sleep parameters for sleepy servers can be stored by the server in the RD and accessed by all interested clients
Examples of using these parameters in a synchronous or asynchronous manner are shown in the I-D
http6lowappnet coreIETF86 2013-03-12-13
We assume people have read the drafts
Meetings serve to advance difficult issues by making good use of face-to-face communications
Note Well Be aware of the IPR principles according to RFC 3979 and its updates
uumlBlue sheetsuumlScribe(s)
96
drar-shy‐iep-shy‐core-shy‐coapsubmiqed13 to13 IESG
2013-shy‐03-shy‐13
97
OMA Lightweight M2M Overview(A new standard using lots of IETF specs including DTLS
CoAP Block Observe Resource Directory SenMLhellip)
Zach ShelbyCoRE WG IETF-86 Orlando
OMA Lightweight M2Mbull Open Mobile Alliance is well known for Device Management (DM)bull OMA Lightweight M2M is a new standard from the alliance
ndash Focused on constrained Cellular and sensor network M2M devicesndash Driven by leading operators and vendors
bull Scopendash Interfaces protocol amp security between Device and Serverndash Object and Resource modelndash Bootstrap Device Access Control Connectivity and Firmware Objects
bull Draft Specifications are availablendash httpmemberopenmobileallianceorgftpPublic_documentsDM
LightweightM2MPermanent_documentsOMA-TS-LightweightM2M-V1_0_0-20130301-Dzip
bull Timelinendash Requirements and Architecture completed 3Q2012ndash Spec ready for Consistency Review 2Q2013ndash Candidate Approval expected 3Q2013
2 CoRE WG IETF-86 Orlando
Architecture
3
Scope of LWM2M
CoRE WG IETF-86 Orlando
Object Model
bull A Client has one or more Object Instancesbull An Object is a collection of Resourcesbull A Resource is an atomic piece of information
ndash Read Written or Executed
bull Resources can have multiple instancesbull Objects and Resources are identified by a
16-bit Integer Instances by an 8-bit Integerbull ObjectsResources are accessed with
simple URIs Object IDObject InstanceResource ID
eg 1213
4 CoRE WG IETF-86 Orlando
CoRE WG IETF-86 Orlando
CoRE Resource Directory
draft-shelby-core-resource-directory-05
Z Shelby C Bormann S Krco
Backgroundbull Not a new concept
ndash think web search engine or any link directorybull Defines the interfaces to a Resource Directorybull Based on Web Linking framework and the CoRE Link Formatbull Generic REST design for use over HTTP and CoAPbull Used by OMA Lightweight M2Mbull Has already been deployed
ndash In traffic monitoring systemsndash In street lighting systemsndash For vehicular asset trackingndash By a major Cellular M2M operator
Changes since -04
bull Restricted Update to parameter updatesbull Added pagination support for the Lookup interfacebull Changed rt= to et= for the registration amp update
interfacebull Added group support
Group Management
bull RD now includes group management featuresbull New Group Function Set
ndash Register a groupbull Group name domain multicast address endpoint members
ndash Remove a groupbull Group lookup using the Lookup Function Set
ndash List registered groupsndash Find the members of a groupndash Find groups with certain endpoints or resources
Registering a Group
EP RD
| |
| - POST rd-groupgp=lights ltgtep=node1 --gt |
| |
| |
| lt---- 201 Created Location rd-group12 ---- |
| |
Req POST coaprdexamplecomrd-groupgp=lights
Payload
ltgtep=node1
ltgtep=node2
Res 201 Created
Location rd-group12
Looking up Group Members
Client RD
| |
| ----- GET rd-lookupepgp=lights1 ----------------------gt |
| |
| |
| lt-- 205 Content ltrdgtd=domain1ltrdgtd=domain2 --------- |
| |
Req GET rd-lookupepgp=lights1
Res 205 Content
ltcoaphostportgtep=node1
ltcoaphostportgtep=node2rdquo
Things for the futurebull Support for JSON representation of Web Links
ndash httptoolsietforgiddraft-bormann-core-links-json-02txtbull Registry for RD registration query parameters
ndash Already OMA Lightweight has defined some new onesbull More examples
Group 3 ldquonew workrdquo(continued)
109
drar-shy‐greevenbosch-shy‐core-shy‐profile-shy‐descripon-shy‐01Bert13 GreevenboschJeroen13 Hoebeke
Isam13 IshaqFloris13 Van13 den13 Abeele
Descripon
bull JSON13 format13 for13 signalling13 the13 servers13 capabilies
bull Signalling13 of13 supported13 opons13 media13 types13 and13 block13 sizendash Other13 items13 can13 be13 added
bull Filtering13 on13 specific13 fields13 through13 URI-shy‐Querybull Link13 hqpdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐profile-shy‐descripon
well-shy‐knownprofile
bull To13 acquire13 profile13 data13 of13 resources13 on13 a13 parcular13 service13 the13 well-shy‐knownprofile13 URI-shy‐path13 is13 introduced
bull For13 example13 to13 get13 all13 informaon13 from13 sensors13 served13 by13 wwwexampleorg13 we13 can13 do13 a13 GET13 to13 coapwwwexampleorgwell-shy‐knownprofile
bull Filtering13 on13 parcular13 resources13 is13 done13 through13 URI-shy‐Queries
Format
bull Currently13 the13 following13 fields13 are13 definedndash ldquopathrdquo13 contains13 the13 URI-shy‐path13 associated13 with13 a13 resource
ndash ldquooprdquo13 a13 numerical13 list13 of13 supported13 opon13 numbers
ndash ldquocfrdquo13 a13 numerical13 list13 of13 supported13 content-shy‐format13 numbers
ndash ldquob1srdquo13 ldquob2srdquo13 supported13 block13 sizes13 for13 Block113 and13 Block213 respecvely
Examplebull On13 the13 right13 is13 an13 example13 of13 a13 camera13 sensor13 at13 coapwwwexampleorgcam13 that13 supports13 the13 Uri-shy‐Host13 (3)13 ETag13 (4)13 Uri-shy‐Port13 (7)13 Uri-shy‐Path13 (11)13 Content-shy‐Format13 (12)13 Token13 (19)13 Block213 (23)13 and13 Proxy-shy‐Uri13 (35)13 opons
bull The13 supported13 content13 formats13 are13 textplain13 (0)13 applicaon13 link-shy‐format13 (40)13 and13 applicaonjson13 (50)
bull The13 supported13 Block213 can13 use13 25613 or13 51213 byte13 blocks
Req13 GET13 coapwwwexampleorgwell-shy‐knownprofile13 Res13 20513 Content13 (applicationjson)13 13 13 13 profile13 13 13 13 13 13 13 13 pathcam13 13 13 13 op[3471112192335]13 13 13 13 13 cf[04050]13 13 13 13 13 b2s[45]13 13 13 13
Filtering13 through13 use13 of13 URI-shy‐Query
bull Filtering13 can13 be13 done13 through13 the13 URI-shy‐Querybull Query13 format13 N=V
ndash N13 is13 a13 profile13 fieldndash V13 is13 the13 desired13 value
bull Examplesndash To13 find13 resources13 that13 support13 content13 format13 ldquoapplicaonjsonrdquo
13 GET13 wwwexampleorgwell-shy‐knownprofilecf=50ndash To13 get13 informaon13 about13 the13 camera
13 GET13 wwwexampleorgwell-shy‐knownprofilepath=cam
Open13 issues
bull Which13 other13 profile13 data13 needs13 signallingndash Content-shy‐type13 for13 different13 methods
bull Fix13 the13 order13 in13 which13 the13 profile13 fields13 must13 appearndash Non-shy‐fixed13 order13 easier13 extensible
bull Inheritance13 of13 a13 profile13 descriponbull Extend13 usage13 to13 signal13 the13 client13 profilebull Integraon13 with13 link13 format
Thank13 youQuesons
drar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval-shy‐00
Bert13 Greevenbosch
Descripon
bull The13 ldquoMinimumRequestInterval13 opon13 can13 be13 used13 to13 indicate13 the13 minimum13 me13 between13 two13 requests13 in13 a13 transacon
bull Originally13 intended13 for13 Block13 but13 also13 usable13 for13 other13 transaconsndash Example13 browsing13 a13 server
bull The13 goal13 is13 to13 reduce13 the13 server13 load13 and13 network13 traffic
bull Link13 hqpsdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval
Usage
bull The13 client13 keeps13 the13 server13 informed13 about13 its13 request13 speed13 through13 inclusion13 of13 the13 ldquoMinimumRequestIntervalrdquo13 opon
bull In13 responses13 the13 server13 fixes13 the13 minimum13 request13 interval13 through13 the13 same13 opon
bull The13 client13 obeys13 the13 speed13 indicated13 by13 the13 server
bull The13 client13 can13 send13 slower13 but13 not13 faster
Advantages
bull The13 server13 has13 means13 to13 limit13 the13 amount13 of13 incoming13 traffic
bull The13 server13 can13 prevent13 to13 become13 overloaded13 with13 too13 many13 tasks
bull The13 server13 does13 not13 need13 arficially13 slow13 down13 the13 client13 by13 sending13 late13 ACKsndash No13 need13 to13 keep13 track13 of13 delayed13 ACKsndash The13 server13 can13 perform13 other13 tasks13 instead
bull Reduced13 network13 traffic
Thank13 youQuesons
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-links-json-02txt
123
RFC 6690 (link-format) documents are somewhat foreign to many web app developerssect would prefer to have them in JSON format
There is no standard way to represent link-format documents in applicationssect but everyone knows how to handle JSON
Define a standard JSON translation for link-format
Itrsquos
not
rock
et
scien
ce
ltsensorsgtct=40title=Sensor Index ltsensorstempgtrt=temperature-cif=sensor ltsensorslightgtrt=light-luxif=sensor lthttpwwwexamplecomsensorst123gt anchor=sensorstemprel=describedby lttgtanchor=sensorstemprel=alternate [hrefsensorsct40titleSensor Index hrefsensorstemprttemperature-cifsensor hrefsensorslightrtlight-luxifsensor hrefhttpwwwexamplecomsensorst123 anchorsensorstempreldescribedby hreftanchorsensorstemprelalternate]
124
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-ipsec-for-coap-00txt
IPsec definitions for CoAP Mostly placeholder at this time Who has implementation experience with this
125
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-cross-reverse-convention-00txt
This draft has two lines of payload(based on a WGLC comment by Cullen Jennings)
coap12344567foobara=3
httpwwwproxycomwellknowncore-translate1234_4567foobara=3
Is that a useful convention to have
126
Insert CI slides here
127
128
0
5
10
15
20
25
30
35
40
10 20 30 40 50 60 70
good
put (
pps)
pps
Goodput vs pps (Econotags)
goodput
[Khattak preliminary]
Congestion Control
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-cocoa-00txt
ldquoadvancedrdquo cc (The draft is just a first shot) Others may have better ideas
129
Insert post-WGLC discussion slides here
130
Stop Continue Start
131
An Agile Retrospective
http6lowappnet coreIETF86 2013-03-12-13
Stop
132
Endless new CoAP optionssect instead use RESTful as much as possible
Move general security lifecycle out Looking at theoretical problems
http6lowappnet coreIETF86 2013-03-12-13
Continue
Interops Running code Look at real-world examples and deployments Solve their actual problems
sect Unilateral enhancements eg higher performance congestion control
sect Transports (SMS hellip)sect Make Web linking and Directories more and more usefulsect RESTful Design Paradigms for real-world problems
133
http6lowappnet coreIETF86 2013-03-12-13
Start
Further push into the (browser) web world (HTML5 browser security)
Specific supporting worksect SenMLsect URI work (dev URN hellip)sect Security Processes (next slide)
Spin outsect (We donrsquot really get to decide where this is done)
134
http6lowappnet coreIETF86 2013-03-12-13
Security
Integrate Application Network Group Keyingsect Tunnel-free setup
Donrsquot redo what has been done alreadysect ZigBee IP is finesect But what about other scenarios
Simple REST interfaces for working with keying materials and authorizationsect Start with defining objectives
Object Security for Constrained Nodes135
Re-chartering CoREWhat do we want to do now that wersquore grown up
Zach ShelbyCoRE WG IETF-86 Orlando
What is the scope
bull So we have a protocol and Web Linking what next
bull Keep with what we know besthellip1 Enhancements around CoAP2 New transports for CoAP3 New representations for Web Links4 General application layer solutions
CoRE WG IETF-86 Orlando 2
Enhancements around CoAP
bull Advanced congestion control
CoRE WG IETF-86 Orlando 3
New Transports for CoAP
bull Infrastructure for CoAP over foondash httptoolsietforgiddraft-silverajan-core-
coap-alternative-transports-01txtbull CoAP over SMS
ndash httptoolsietforgiddraft-becker-core-coap-sms-gprs-03txt
ndash OMA Lightweightbull CoAP over TCP
ndash httptoolsietforgiddraft-li-core-coap-payload-length-option-01txt
CoRE WG IETF-86 Orlando 4
New support for Web Links
bull JSON Web Linksndash httptoolsietforgiddraft-bormann-core-links-
json-02txt
2332010 CoRE WG IETF-77 Anaheim 5
General application layer solutions
bull Resource Directoryndash httptoolsietforgiddraft-shelby-core-
resource-directory-05txtndash OMA Lightweight
2332010 CoRE WG IETF-77 Anaheim 6
Open Issues(35)
n Issues with twomultiple Resource Directories in use case (280)n Some potential issues with RD came out of review Peter van der Stok and
WG discussion IETF85 n There are two RD servers use case shows that only one is found despite
the fact that site-local multicast is used - should be two RDs found n Proposal simplify use case to a single RD server on the backbone to avoid
such RD-specific issues like synchronization of RD information between servers
Open Issues(45)
n Add single-subnet configuration to use cases (278)n Suggested by review Peter van der Stok and IETF85 WG discussion that
its best to start explaining the simplebasic cases and then gradually build up complexity
n Simplest case not shown yet would be a single subnet network configuration which is currently not present in the I-D only the 2-subnet configuration of Fig 1
n Question Do we need to add such case or doesnt it add muchn (Note that core-coap Figure 22 already shows the simplest case of link-local
multicast)
Open Issues(55)
n Add use case with controller (client) located on the backbone (279)n Suggested by discussion following review Peter van der Stok n Case missing where a controller (client) is located on the backbonen Question Do we need to add such case or does it add much
Group 2a other old friends
25
Angelo Castellani Salvatore Loreto Akbar Rahman Thomas Fossati Esko Dijk
IETF 86 March 2013httpwwwietforgiddraft-castellani-core-http-mapping-07txt
Best Practices for HTTP-CoAP Mapping
Implementation
Summary of Changes (from -06 rev)
n Based on discussion at last IETF-85 (Atlanta)n Clarification of HTTP-CoAP Proxies
n Definitionn Placementn Benefits
n Clarification of HTTP-CoAP URI mapping options
Goals of I-D
n For Reverse HTTP-CoAP Cross Protocol Proxyn Provide more detailed information to proxy designers (beyond
Section 10 of [I-Dietf-core-coap]) to help implement proxies that correctly inter-work with other CoAP and HTTP clientserver implementations that adhere to the specifications
n Define a consistent set of guidelines that a HTTP-to-CoAP proxy implementation MAY adhere to The main reason of adhering to such guidelines is to reduce variation between proxy implementations thereby increasing interoperabilityn As an example use case a proxy conforming to these guidelines made
by vendor A can be easily replaced by a proxy from vendor B that also conforms to the guidelines
I-D Outline
n Guidance on HTTP to CoAP URI mappingn HTTP-CoAP Reverse cross-protocol proxy implementation
n Placementn Response code amp media type translationsn Caching and congestion controln Cache refresh via Observen Use of CoAP blockwise transfern Security translation
n Security Considerationsn Traffic overflown Handling secured exchanges
Definitions (12)
n Cross-Protocol Proxy (or Cross Proxy) is a proxy performing a cross- protocol mapping in the context of this document a HTTP-CoAP (HC) mapping A Cross-Protocol Proxy can behave as a Forward Proxy Reverse Proxy or Interception Proxy n Note In this document we focus on the Reverse Proxy mode of the
Cross-Protocol Proxy
n Forward Proxy a message forwarding agent that is selected by the client usually via local configuration rules to receive requests for some type(s) of absolute URI and to attempt to satisfy those requests via translation to the protocol indicated by the absolute URI The user decides (is willing to) use the proxy as the forwardingdereferencing agent for a predefined subset of the URI space
Definitions (22)
n Reverse Proxy a receiving agent that acts as a layer above some other server(s) and translates the received requests to the underlying servers protocol It behaves as an origin (HTTP) server on its connection towards the (HTTP) client and as a (CoAP) client on its connection towards the (CoAP) origin server The (HTTP) client uses the origin-form [I-Dietf-httpbis-p1-messaging] as a request- target URI
n Reverse and Forward proxies are technically very similar with main differences being that the former appears to a client as an origin server while the latter does not and that clients may be unaware they are communicating with a proxy
Reverse Cross-Protocol Proxy Deployment Scenario
HTTP-CoAP Response Code Mapping
Implementation Experience
n Direct experience from the draft authorsn Squid HTTP-CoAP mapping module
n University of Padovan httptelecomdeiunipditiotn Both Forward and Interception operation supported
n HTTP-CoAP proxy based on EvCoAPn KoanLogic University of Bologna and Salvatore
Loreto (as individual)n httpsgithubcomkoanlogicwebthingstreemasterbridgesw
libevcoapn The document is open to input from other implementations
Next Steps
n Does the WG recommend adoptionn Intended status Informational Best Practicen Purpose Reduce arbitrary variation between proxy
implementations thereby increasing interoperability
Backup
HTTP to CoAP URI Mapping Options (12)
n Embedded Mapping n In an embedded mapping approach the HTTP URI has embedded
inside it the authority and path part of the CoAP URI n Example The CoAP resource nodecoapsomethingnetfoo can
be accessed by an HTTP client by inserting in the request httphc-proxysomethingnetcoapnodecoapsomethingnetfoo The Cross-Protocol Proxy then maps the URI to coapnodecoapsomethingnetfoo
HTTP to CoAP URI Mapping Options (22)
n Homogeneous Mapping n In a homogeneous mapping approach only the scheme portion of the URI
needs to be mapped The rest of the URI (ie authority path etc) remains unchanged
n Example The CoAP resource coapnodecoapsomethingnetfoo can be accessed by an HTTP client by requesting httpnodecoapsomethingnetfoo The Cross-Protocol Proxy receiving the request is responsible to map the URI to coapnodecoapsomethingnetfoo
n Background info n The assumption in this case is that the HTTP client would be able to
successfully resolve nodecoapsomethingnet using DNS infrastructure to return the IP address of the HC proxy Most likely this would be through a two step DNS lookup where the first DNS lookup would resolve somethingnet using public DNS infrastructure
n Then the second DNS lookup on the subdomain coap and the host node would typically be resolved by a DNS server operated by the owner of domain somethingnet So this domain owner can manage its own internal node names and subdomain allocation which would correspond to the CoAP namespace
Group 3 ldquonew workrdquo
39
Transport of CoAP over SMS USSD and GPRSdraft-becker-core-coap-sms-gprs-03
Markus Becker Kepeng LiKoojana Kuladinithi Thomas Poumltsch
CoRE WG IETF-86 Orlando
1 10
ScenariosI In M2M communication IP connectivity is not alwayssupported by the constrained end-points
I Power savingI Coverage (GPRS 3G LTE)
I SMS and USSD based communication is almost alwayssupported
210
Changes from draft-01 to draft-03 (1)
I Added possible CONNONACK interactions Section 5
I Option name changed from Reply-To- to Response-To-Section 16 and Section 101
I Added URI schemeEg coap+tel+15105550101well-knowncore Section 11
I Added possible M2M proxy scenarios Section 14
3 10
Changes from draft-01 to draft-03 (2)
I Added reference to bormann-coap-misc for other SMSencoding Section 71
I Updated requirements on Uri-Host and Uri-Port forcoap+tel Section 10
I Added security considerations Transport and ObjectSecurity Section 15
I Chose CoAP option numbers and updated the optionnumber table to meet draft-ietf-core-coap-10 Table 1
I Added an IANA registration for the URI scheme coap+telSection 162
4 10
Feedback Split coap+tel into coap+smsand coap+ussd
I How else to differ the various transports in the URII Or is the transport to use decided by the implementationI See alsodraft-silverajan-core-coap-alternative-transports-01
5 10
Feedback Response-To-Scheme option
I Should there be a Response-To-Scheme optionadditionally to Response-To-Uri-Host andResponse-To-Uri-Path
I So that a CoAP end-point which receives a request by CoAPover non-IP transport can be instructed to also use thenon-IP transport for the response
I This would imply to add aResponse-To-Telephone-Subscriber and more options forother transports that have other URI schemes than coapand coaps
6 10
Feedback Selection of Transport by Client
I When a server is reachable by various transports howdoes a client decide which transport to use
I Client-side application congurationI Leave it to a proxy which uses cellular network lookupfunctions
7 10
Feedback Potential Threats
I Trigger expensive short messagesI Redirect trac to other addressesI More threats
I Are the security measures in the draft adequateI Whitelisting on serverI Relying on cellular network security (dedicated M2M APNs)I Object security on CoAP payload
8 10
Feedback Message Exchanges
I Figures 11-18 show possible message exchanges whenclient and server have two addresses
I With NON Not using CoAP retransmission capabilityI ACK on different transportI Additional (costly) message on Transport AI Request with Content
I Which ones are allowedI Which ones are meaningful
9 10
Next steps
I Rene Uri schemeI Response-To-Scheme optionI Selection of Message ExchangeI Rene Proxying
10 10
CoAP13 Communicaon13 with13 Alternave13 Transports
Bill Silverajan and Teemu SavolainenCore WG IETF 86 Orlando
031113
Objecves13 (In13 Scope)
bull Unambiguous13 representaon13 of13 transport13 to13 be13 used13 by13 CoAP
bull Details13 how13 the13 transport13 can13 carry13 CoAP13 packet
bull Focus13 is13 on13 what13 CoAP13 communicaons13 requirements13 are
bull Allow13 CoAP13 mechanisms13 to13 exploit13 cross-shy‐layer13 opmisaons
51
031113
Non13 Goals13 (Not13 in13 scope)
bull Applicaon-shy‐level13 QoS13 requirementsbull Real-shy‐me13 constraintsbull Ordering13 reliability13 congeson13 controlbull Applicaon13 and13 network13 adaptaonbull Mobility13 and13 readdressing13 supportbull Network13 protocol13 (eg13 IPsec)13 configuraon
52
031113
Use13 Cases
bull NAT13 and13 Firewall13 traversal13 with13 TCPbull Delay13 Tolerant13 Networkingbull Non-shy‐IP13 Low13 Energy13 Protocols
53
031113
Related13 Work
bull OMA13 Lightweight13 M2M13 Protocolbull CoAP13 over13 SMSGPRSUSSD
54
031113
What13 does13 the13 work13 entail
bull The13 ability13 to13 specify13 end13 point13 idenfiers13 and13 URIs13 to13 reflect13 which13 transport13 CoAP13 can13 use
bull The13 ability13 to13 register13 to13 resource13 directories13 resource13 types13 reflecng13 types13 of13 transport13 available
bull Ability13 for13 mul-shy‐transport13 nodes13 to13 select13 transport13 to13 use13 without13 significant13 alteraon13 to13 CoAP13 packet13 structure
55
031113
Points13 to13 consider
bull Requirements13 for13 transport13 layer13 protocol13 to13 carry13 CoAP13 packets
bull Representaon13 of13 URI13 scheme13 for13 generic13 transport13 protocols
bull Opon13 extensions13 for13 CoAP13 to13 express13 available13 transports
bull Mapping13 and13 message13 sizebull Security13 consideraons
56
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
URI13 =13 scheme13 13 13 authority13 path-shy‐abempty13 [13 query13 ]
bull Within13 the13 scheme13 namebull In13 the13 URI13 pathbull As13 a13 query13 component
57
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
bull Within13 the13 scheme13 namendash coap+tel+15105550101well-shy‐knowncorendash coap+tcpexamplecom5683temperaturendash coap+blel2cap[1234567890AB]4pulse
bull Easy13 URI13 parsing13 for13 transport13 type13 and13 idenfier
bull Each13 new13 scheme13 name13 requires13 IANA13 registraon
58
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
bull In13 the13 URI13 pathndash coaphostexamplecomtransport=tcpwell-shy‐knowncorert=core-shy‐rd
bull Easy13 adopon13 of13 new13 (and13 experimental)13 CoAP13 transports13 without13 IANA13 registraon
bull Caveat13 Uri-shy‐Path13 opon13 is13 a13 Crical13 CoAP13 opon13 see13 secon13 54113 of13 I-shy‐Diep-shy‐core-shy‐coap
59
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
bull As13 a13 URI13 query13 componentndash coaphostexamplecomwell-shy‐knowncorert=core-shy‐rdq=tcp
bull Also13 easy13 to13 adopt13 new13 (and13 experimental)13 CoAP13 transports13 without13 IANA13 registraon
bull Caveat13 Uri-shy‐Query13 opon13 is13 a13 Crical13 CoAP13 opon13 see13 secon13 54113 of13 I-shy‐Diep-shy‐core-shy‐coap
60
031113
URI13 Representaons13 for13 CoAPNon13 standard13 ways
bull Transport13 in13 the13 URI13 authority13 componentndash coaphost[port][transport]13 instead13 of13 coaphost[port]
bull Transport13 as13 a13 service13 URLndash servicecoaptcphostexamplecomwell-shy‐knowncorert=core-shy‐rd
bull Above13 two13 ways13 break13 exisng13 compability13 (although13 both13 are13 based13 on13 valid13 IANA13 URI13 registraons)
61
031113
URI13 Representaons13 for13 CoAPMiscellaneous13 Consideraons
bull Ensure13 that13 transport13 is13 defined13 unambiguously13 (eg13 L2CAP13 used13 by13 both13 BLE13 and13 standard13 Bluetooth13 so13 avoid13 rdquocoap+l2caprdquo13 or13 rdquotransport=l2caprdquo13 or13 rdquoq=l2caprdquondash Can13 be13 done13 as13 WG13 consensusndash Namespace13 approach13 eg13 rdquocoap+blel2caprdquo13 or13 rdquoq=blel2caprdquo
bull Allow13 end-shy‐points13 to13 use13 CoAP13 Resource13 Directory13 to13 register13 alternave13 transports13 and13 idenfiers13 and13 provide13 periodic13 updatesndash Register13 rdquocore-shy‐transportrdquo13 resource13 type
62
031113
Transport13 Consideraons
bull Uniqueness13 of13 end-shy‐point13 idenficaonbull Communicaon13 support13 Unidireconal13 Bidireconal13 1N13 (broadcast13 mulcast13 anycast)13 messaging
bull Binary13 encoding13 Network13 byte13 orderingbull MTU13 correlaon13 with13 CoAP13 PDU13 sizebull Transport13 latency
63
031113
Security13 Consideraons
bull Drar13 does13 not13 introduce13 new13 security13 requirements13 by13 itself
bull There13 may13 be13 privacy13 issues13 if13 nodes13 use13 telephone13 numbers13 or13 MAC13 addresses13 as13 public13 end13 point13 idenfiers
64
Akbar Rahman
IETF 86 March 2013 httpwwwietforgiddraft-rahman-core-sleepy-02txt
Enhanced Sleepy Node Support for CoAP
Introduction
It is expected that in CoAP networks there will be a certain portion of devices that are sleepy and which may occasionally go into a sleep mode (ie go into a low power state to conserve power) and subsequently have reduced CoAP protocol communication ability
This I-D proposes a minimal and efficient mechanism building on the Resource Directory concept (which will be integrated into a CoAP Proxy) to enhance sleepy node support in CoAP networks
Main Question from IETF-85 (Atlanta)
What performance benefit does the proposed Sleepy Node support solution give in a network that already has standard CoAP caching enabled
Sleepy Node Performance Analysis
Experimental Network
1-5 clients
Both Sleepy and Non-
Sleepy servers
Sleepy Node Performance Analysis Network Setup
CoAPSleepyServer(s)
CoAPSleepAwareReverseProxy
CoAP
Client(s)
Request
Response
Sleep9AwareCoREResourceDirectoryCapability
PublishedSleepParameters
Sleep9AwareCoAPStoreandForwardCapability Response
Request
SleepAwareCoAP503ResponseCapability
CoAPCachingCapability
bull Server supports publishing sleep parameters to proxy bull Eg Irsquom going to be asleep for X seconds
bull Proxy supports sleep-awareness capabilities bull Proxy also supports caching capability based off of maxAge bull Protocol flow similar to approach of Figure 1 (Synchronous RD Based Sleep
Tracking) of I-D
Proxy capabilities can be selectively enableddisabled
Proxy ndash Server Interface
Client ndash Proxy Interface
CoAP Sleep-Aware Reverse Proxy Features CoRE Sleep-aware Resource Directory
Support storing published sleep parameters from CoAP servers sleepState (AWAKE ASLEEP) sleepDuration
Sleep-aware CoAP 503 Response Capability If CoAP request to a sleeping server is received proxy returns a
lsquo503 Retry-Afterrsquo response to client 503 contains a timestamp indicating when the sever will wake back up
(timestamp delivered in CoAP maxAge option) Sleep-aware CoAP Store-and-Forward Capability
If CoAP request to a sleeping server is received proxy stores request until server wakes up and then forwards it
Caching capability Cache GET responses from server if maxAge option is present
(this is not a sleep aware feature)
Goals of Performance Analysis
For networks having sleepy servers provide measurements to quantify the impact that CoAP sleep-awareness capabilities can have
See if sleep-awareness capabilities can
provide additional benefits even when CoAP caching is used
Overview of Performance Analysis Performed The analysis was broken up into a set of test scenarios Each test scenario used a different combination of the following
variables Client issued GET requests Server was configured as a sleepy or non-sleepy server Proxy caching of GET responses was enabled or disabled Proxy sleep-aware 503 response capability was enabled or disabled Proxy store-and-forward capability was enabled or disabled maxAge in GET responses ndash Two values were tested 60sec and 5sec of Clients ndash Two values were used ndash 1 client and 5 clients
For comparison purposes the following were held constant across all test scenarios Client issued a fixed number of requests (100) across all test scenarios Client used a delay between each GET request (35sec) to better exercise
proxyrsquos caching and sleep-awareness capabilities For sleepy server test scenarios the server slept 60 sec awake for 3 sec
Format of Results The following results were collected for each
test scenario
Breakdown of the and types of transactions occurring between clientproxyserver
ldquoGETrdquo ndash Test Scenario Results
GET ndash Description of Test Scenarios
TestScenarios-GET
Scenario
CoAPSleepyServerSe7ngs CoAPSleepAwareReverseProxySe7ngs CoAPClientSe7ngs
SleepDuragton(sec)
AwakeDuragton(sec)
maxAge(sec) Caching SleepAwareSAF+
503NumberofClients
NumberofGETs
DelayBetweenClient
Requests(sec)
1a 0 Always 60 Enabled Disabled 1 100 35
1b 60 3 60 Enabled Disabled 1 100 35
1c 60 3 60 Enabled Enabled 1 100 35
2a 0 Always 60 Enabled Disabled 5 100 35
2b 60 3 60 Enabled Disabled 5 100 35
2c 60 3 60 Enabled Enabled 5 100 35
3a 0 Always 5 Enabled Disabled 5 100 35
3b 60 3 5 Enabled Disabled 5 100 35
3c 60 3 5 Enabled Enabled 5 100 35
ldquoGETrdquo ndash Test Scenario 1 Results
maxAge = 60 and 1 Client
GET ndash Scenario 1 ClientProxy Interface Transaction Mix
Scenarios 1a - Non-Sleepy Server Caching Proxy maxAge = 60sec 1b- Sleepy Server Caching Proxy maxAge = 60sec 1c - Sleepy Server Sleep Aware Proxy maxAge = 60sec
Sleep Aware Proxy has better performance for sleepy servers
0
100
200
300
400
500
600
700
1a 1b 1c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
GET ndash Scenario 1 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
Scenarios 1a - Non-Sleepy Server Caching Proxy maxAge = 60sec 1b- Sleepy Server Caching Proxy maxAge = 60sec 1c - Sleepy Server Sleep Aware Proxy maxAge = 60sec
0
100
200
300
400
500
600
700
800
1a 1b 1c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
ldquoGETrdquo ndash Test Scenario 2 Results
maxAge = 60 and 5 Clients
GET ndash Scenario 2 ClientProxy Interface Transaction Mix
Sleep Aware Proxy has slightly better performance for sleepy servers
0
200
400
600
800
1000
1200
1400
2a 2b 2c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
Scenarios 2a - Non-Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2b- Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2c - Sleepy Server Sleep Aware Proxy maxAge = 60sec 5 Clients
See ldquoExperimental Artifactsrdquo Note 1
GET ndash Scenario 2 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has slightly better performance for sleepy servers
0
50
100
150
200
250
300
350
400
2a 2b 2c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
Scenarios 2a - Non-Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2b- Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2c - Sleepy Server Sleep Aware Proxy maxAge = 60sec 5 Clients
See ldquoExperimental Artifactsrdquo Note 2
Experimental Artifacts Note 1
Currently in the experiment the sleep aware proxy checks the cached state of a resource before putting a request into its Store-and-forward queue while a server is sleeping Once in the queue the proxy unconditionally forwards the queued requests to the server once it wakes up This is not the most efficient setup and can easily be improved If the proxy instead checks its cache again before forwarding each queued request it may not need to forward the request to the server For example if there are two queued GET requests in the proxyrsquos queue that address the same resource Only the first request needs to be sent to the server the second request can use the cached response from the first request
Note 2 Currently in the experiment the sleepy server sends a sleepState PUT request to the
proxy each time it goes to sleep This is not the most efficient setup and can easily be improved For example if the server assumes that the proxy can keep track of its ONOFF cycles with its internal timers (eg as per Fig 1 of I-D) then the number of messages from the sleepy server dramatically goes down
ldquoGETrdquo ndash Test Scenario 3 Results
maxAge = 5 and 5 Clients
GET ndash Scenario 3 ClientProxy Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
Scenarios 3a - Non-Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3b- Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3c - Sleepy Server Sleep Aware Proxy maxAge = 5sec 5 Clients
0
500
1000
1500
2000
2500
3000
3500
4000
4500
5000
3a 3b 3c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
GET ndash Scenario 3 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
0
1000
2000
3000
4000
5000
6000
7000
3a 3b 3c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
Scenarios 3a - Non-Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3b- Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3c - Sleepy Server Sleep Aware Proxy maxAge = 5sec 5 Clients
Conclusions
Conclusions These results show that sleep-aware CoAP
proxy features can significantly optimize communication with sleepy servers in most scenarios
These results also show that sleep-
awareness capabilities can provide additional benefits above and beyond CoAP caching in most scenarios
Backup
Current CoAP Support of Sleepy Node (12)
CoAP proxies can use a previously cached response to service a new GET request for a sleepy origin server (as in HTTP) But if no valid cache then proxy has to attempt to
retrieve and may fail if origin server is sleeping [I-Dietf-core-coap]
Clients can discover list of resources from RD (GET rd-lookuphellip) for sleepy servers But attempt to GET resource from sleepy origin server
may fail if origin server is sleeping [IDietf-core-link-format amp IDshelby-core-resource-
directory]
Current CoAP Support of Sleepy Node (22)
Lower layer support for sleepy nodes in most wireless technologies (eg WiFi ZigBee) But limited to MAC packet scheduling for sleepy nodes
and not aware of specific needs of IP applications (like CoAP)
Proposal ndash RD Based Sleep Tracking (14)
The current CoAP approach to support sleepy nodes can be significantly improved by introducing RD based mechanisms for a CoAP client to determine whether A targeted resource is located on a sleepy server A sleepy server is currently in sleep mode or not
There is any associated caching Proxy (possibly the RD itself) for a sleepy server
Proposal ndash RD Based Sleep Tracking (24)
We define the following new RD attributes to characterize the properties of a sleepy node SleepState - Indicates whether the node is currently in
sleep mode or not (ie Sleeping or Awake) SleepDuration - Indicates the maximum duration of time
that the node stays in sleep mode TimeSleeping - Indicates the length of time the node
has been sleeping (ie if Sleep State = Sleeping) NextSleep - Indicates the next time the node will go to
sleep (ie if Sleep State = Awake)
CachingProxy ndash Indicates the caching proxy of the sleepy node (ie the RD itself or another node)
Proposal ndash RD Based Sleep Tracking (34)
These attributes are all server (node) level and are new parameters added to the RD URI Template Variables
Finally we also define a new lookup-type (ss) for the RD lookup interface specified in [I-Dshelby-core-resource-directory] This new lookup-type supports looking up the
ldquoSleepStaterdquo (ss) of a specified end-point
Proposal ndash RD Based Sleep Tracking (44)
The three time based parameters (SleepDuration TimeSleeping NextSleep) can be based on either an absolute network time (for a time synchronized network) or a relative local time (measured at the local node)
Following the approach of [I-Dietf-core-link-format] and [I-Dshelby-core-resource-directory] sleep parameters for sleepy servers can be stored by the server in the RD and accessed by all interested clients
Examples of using these parameters in a synchronous or asynchronous manner are shown in the I-D
http6lowappnet coreIETF86 2013-03-12-13
We assume people have read the drafts
Meetings serve to advance difficult issues by making good use of face-to-face communications
Note Well Be aware of the IPR principles according to RFC 3979 and its updates
uumlBlue sheetsuumlScribe(s)
96
drar-shy‐iep-shy‐core-shy‐coapsubmiqed13 to13 IESG
2013-shy‐03-shy‐13
97
OMA Lightweight M2M Overview(A new standard using lots of IETF specs including DTLS
CoAP Block Observe Resource Directory SenMLhellip)
Zach ShelbyCoRE WG IETF-86 Orlando
OMA Lightweight M2Mbull Open Mobile Alliance is well known for Device Management (DM)bull OMA Lightweight M2M is a new standard from the alliance
ndash Focused on constrained Cellular and sensor network M2M devicesndash Driven by leading operators and vendors
bull Scopendash Interfaces protocol amp security between Device and Serverndash Object and Resource modelndash Bootstrap Device Access Control Connectivity and Firmware Objects
bull Draft Specifications are availablendash httpmemberopenmobileallianceorgftpPublic_documentsDM
LightweightM2MPermanent_documentsOMA-TS-LightweightM2M-V1_0_0-20130301-Dzip
bull Timelinendash Requirements and Architecture completed 3Q2012ndash Spec ready for Consistency Review 2Q2013ndash Candidate Approval expected 3Q2013
2 CoRE WG IETF-86 Orlando
Architecture
3
Scope of LWM2M
CoRE WG IETF-86 Orlando
Object Model
bull A Client has one or more Object Instancesbull An Object is a collection of Resourcesbull A Resource is an atomic piece of information
ndash Read Written or Executed
bull Resources can have multiple instancesbull Objects and Resources are identified by a
16-bit Integer Instances by an 8-bit Integerbull ObjectsResources are accessed with
simple URIs Object IDObject InstanceResource ID
eg 1213
4 CoRE WG IETF-86 Orlando
CoRE WG IETF-86 Orlando
CoRE Resource Directory
draft-shelby-core-resource-directory-05
Z Shelby C Bormann S Krco
Backgroundbull Not a new concept
ndash think web search engine or any link directorybull Defines the interfaces to a Resource Directorybull Based on Web Linking framework and the CoRE Link Formatbull Generic REST design for use over HTTP and CoAPbull Used by OMA Lightweight M2Mbull Has already been deployed
ndash In traffic monitoring systemsndash In street lighting systemsndash For vehicular asset trackingndash By a major Cellular M2M operator
Changes since -04
bull Restricted Update to parameter updatesbull Added pagination support for the Lookup interfacebull Changed rt= to et= for the registration amp update
interfacebull Added group support
Group Management
bull RD now includes group management featuresbull New Group Function Set
ndash Register a groupbull Group name domain multicast address endpoint members
ndash Remove a groupbull Group lookup using the Lookup Function Set
ndash List registered groupsndash Find the members of a groupndash Find groups with certain endpoints or resources
Registering a Group
EP RD
| |
| - POST rd-groupgp=lights ltgtep=node1 --gt |
| |
| |
| lt---- 201 Created Location rd-group12 ---- |
| |
Req POST coaprdexamplecomrd-groupgp=lights
Payload
ltgtep=node1
ltgtep=node2
Res 201 Created
Location rd-group12
Looking up Group Members
Client RD
| |
| ----- GET rd-lookupepgp=lights1 ----------------------gt |
| |
| |
| lt-- 205 Content ltrdgtd=domain1ltrdgtd=domain2 --------- |
| |
Req GET rd-lookupepgp=lights1
Res 205 Content
ltcoaphostportgtep=node1
ltcoaphostportgtep=node2rdquo
Things for the futurebull Support for JSON representation of Web Links
ndash httptoolsietforgiddraft-bormann-core-links-json-02txtbull Registry for RD registration query parameters
ndash Already OMA Lightweight has defined some new onesbull More examples
Group 3 ldquonew workrdquo(continued)
109
drar-shy‐greevenbosch-shy‐core-shy‐profile-shy‐descripon-shy‐01Bert13 GreevenboschJeroen13 Hoebeke
Isam13 IshaqFloris13 Van13 den13 Abeele
Descripon
bull JSON13 format13 for13 signalling13 the13 servers13 capabilies
bull Signalling13 of13 supported13 opons13 media13 types13 and13 block13 sizendash Other13 items13 can13 be13 added
bull Filtering13 on13 specific13 fields13 through13 URI-shy‐Querybull Link13 hqpdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐profile-shy‐descripon
well-shy‐knownprofile
bull To13 acquire13 profile13 data13 of13 resources13 on13 a13 parcular13 service13 the13 well-shy‐knownprofile13 URI-shy‐path13 is13 introduced
bull For13 example13 to13 get13 all13 informaon13 from13 sensors13 served13 by13 wwwexampleorg13 we13 can13 do13 a13 GET13 to13 coapwwwexampleorgwell-shy‐knownprofile
bull Filtering13 on13 parcular13 resources13 is13 done13 through13 URI-shy‐Queries
Format
bull Currently13 the13 following13 fields13 are13 definedndash ldquopathrdquo13 contains13 the13 URI-shy‐path13 associated13 with13 a13 resource
ndash ldquooprdquo13 a13 numerical13 list13 of13 supported13 opon13 numbers
ndash ldquocfrdquo13 a13 numerical13 list13 of13 supported13 content-shy‐format13 numbers
ndash ldquob1srdquo13 ldquob2srdquo13 supported13 block13 sizes13 for13 Block113 and13 Block213 respecvely
Examplebull On13 the13 right13 is13 an13 example13 of13 a13 camera13 sensor13 at13 coapwwwexampleorgcam13 that13 supports13 the13 Uri-shy‐Host13 (3)13 ETag13 (4)13 Uri-shy‐Port13 (7)13 Uri-shy‐Path13 (11)13 Content-shy‐Format13 (12)13 Token13 (19)13 Block213 (23)13 and13 Proxy-shy‐Uri13 (35)13 opons
bull The13 supported13 content13 formats13 are13 textplain13 (0)13 applicaon13 link-shy‐format13 (40)13 and13 applicaonjson13 (50)
bull The13 supported13 Block213 can13 use13 25613 or13 51213 byte13 blocks
Req13 GET13 coapwwwexampleorgwell-shy‐knownprofile13 Res13 20513 Content13 (applicationjson)13 13 13 13 profile13 13 13 13 13 13 13 13 pathcam13 13 13 13 op[3471112192335]13 13 13 13 13 cf[04050]13 13 13 13 13 b2s[45]13 13 13 13
Filtering13 through13 use13 of13 URI-shy‐Query
bull Filtering13 can13 be13 done13 through13 the13 URI-shy‐Querybull Query13 format13 N=V
ndash N13 is13 a13 profile13 fieldndash V13 is13 the13 desired13 value
bull Examplesndash To13 find13 resources13 that13 support13 content13 format13 ldquoapplicaonjsonrdquo
13 GET13 wwwexampleorgwell-shy‐knownprofilecf=50ndash To13 get13 informaon13 about13 the13 camera
13 GET13 wwwexampleorgwell-shy‐knownprofilepath=cam
Open13 issues
bull Which13 other13 profile13 data13 needs13 signallingndash Content-shy‐type13 for13 different13 methods
bull Fix13 the13 order13 in13 which13 the13 profile13 fields13 must13 appearndash Non-shy‐fixed13 order13 easier13 extensible
bull Inheritance13 of13 a13 profile13 descriponbull Extend13 usage13 to13 signal13 the13 client13 profilebull Integraon13 with13 link13 format
Thank13 youQuesons
drar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval-shy‐00
Bert13 Greevenbosch
Descripon
bull The13 ldquoMinimumRequestInterval13 opon13 can13 be13 used13 to13 indicate13 the13 minimum13 me13 between13 two13 requests13 in13 a13 transacon
bull Originally13 intended13 for13 Block13 but13 also13 usable13 for13 other13 transaconsndash Example13 browsing13 a13 server
bull The13 goal13 is13 to13 reduce13 the13 server13 load13 and13 network13 traffic
bull Link13 hqpsdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval
Usage
bull The13 client13 keeps13 the13 server13 informed13 about13 its13 request13 speed13 through13 inclusion13 of13 the13 ldquoMinimumRequestIntervalrdquo13 opon
bull In13 responses13 the13 server13 fixes13 the13 minimum13 request13 interval13 through13 the13 same13 opon
bull The13 client13 obeys13 the13 speed13 indicated13 by13 the13 server
bull The13 client13 can13 send13 slower13 but13 not13 faster
Advantages
bull The13 server13 has13 means13 to13 limit13 the13 amount13 of13 incoming13 traffic
bull The13 server13 can13 prevent13 to13 become13 overloaded13 with13 too13 many13 tasks
bull The13 server13 does13 not13 need13 arficially13 slow13 down13 the13 client13 by13 sending13 late13 ACKsndash No13 need13 to13 keep13 track13 of13 delayed13 ACKsndash The13 server13 can13 perform13 other13 tasks13 instead
bull Reduced13 network13 traffic
Thank13 youQuesons
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-links-json-02txt
123
RFC 6690 (link-format) documents are somewhat foreign to many web app developerssect would prefer to have them in JSON format
There is no standard way to represent link-format documents in applicationssect but everyone knows how to handle JSON
Define a standard JSON translation for link-format
Itrsquos
not
rock
et
scien
ce
ltsensorsgtct=40title=Sensor Index ltsensorstempgtrt=temperature-cif=sensor ltsensorslightgtrt=light-luxif=sensor lthttpwwwexamplecomsensorst123gt anchor=sensorstemprel=describedby lttgtanchor=sensorstemprel=alternate [hrefsensorsct40titleSensor Index hrefsensorstemprttemperature-cifsensor hrefsensorslightrtlight-luxifsensor hrefhttpwwwexamplecomsensorst123 anchorsensorstempreldescribedby hreftanchorsensorstemprelalternate]
124
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-ipsec-for-coap-00txt
IPsec definitions for CoAP Mostly placeholder at this time Who has implementation experience with this
125
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-cross-reverse-convention-00txt
This draft has two lines of payload(based on a WGLC comment by Cullen Jennings)
coap12344567foobara=3
httpwwwproxycomwellknowncore-translate1234_4567foobara=3
Is that a useful convention to have
126
Insert CI slides here
127
128
0
5
10
15
20
25
30
35
40
10 20 30 40 50 60 70
good
put (
pps)
pps
Goodput vs pps (Econotags)
goodput
[Khattak preliminary]
Congestion Control
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-cocoa-00txt
ldquoadvancedrdquo cc (The draft is just a first shot) Others may have better ideas
129
Insert post-WGLC discussion slides here
130
Stop Continue Start
131
An Agile Retrospective
http6lowappnet coreIETF86 2013-03-12-13
Stop
132
Endless new CoAP optionssect instead use RESTful as much as possible
Move general security lifecycle out Looking at theoretical problems
http6lowappnet coreIETF86 2013-03-12-13
Continue
Interops Running code Look at real-world examples and deployments Solve their actual problems
sect Unilateral enhancements eg higher performance congestion control
sect Transports (SMS hellip)sect Make Web linking and Directories more and more usefulsect RESTful Design Paradigms for real-world problems
133
http6lowappnet coreIETF86 2013-03-12-13
Start
Further push into the (browser) web world (HTML5 browser security)
Specific supporting worksect SenMLsect URI work (dev URN hellip)sect Security Processes (next slide)
Spin outsect (We donrsquot really get to decide where this is done)
134
http6lowappnet coreIETF86 2013-03-12-13
Security
Integrate Application Network Group Keyingsect Tunnel-free setup
Donrsquot redo what has been done alreadysect ZigBee IP is finesect But what about other scenarios
Simple REST interfaces for working with keying materials and authorizationsect Start with defining objectives
Object Security for Constrained Nodes135
Re-chartering CoREWhat do we want to do now that wersquore grown up
Zach ShelbyCoRE WG IETF-86 Orlando
What is the scope
bull So we have a protocol and Web Linking what next
bull Keep with what we know besthellip1 Enhancements around CoAP2 New transports for CoAP3 New representations for Web Links4 General application layer solutions
CoRE WG IETF-86 Orlando 2
Enhancements around CoAP
bull Advanced congestion control
CoRE WG IETF-86 Orlando 3
New Transports for CoAP
bull Infrastructure for CoAP over foondash httptoolsietforgiddraft-silverajan-core-
coap-alternative-transports-01txtbull CoAP over SMS
ndash httptoolsietforgiddraft-becker-core-coap-sms-gprs-03txt
ndash OMA Lightweightbull CoAP over TCP
ndash httptoolsietforgiddraft-li-core-coap-payload-length-option-01txt
CoRE WG IETF-86 Orlando 4
New support for Web Links
bull JSON Web Linksndash httptoolsietforgiddraft-bormann-core-links-
json-02txt
2332010 CoRE WG IETF-77 Anaheim 5
General application layer solutions
bull Resource Directoryndash httptoolsietforgiddraft-shelby-core-
resource-directory-05txtndash OMA Lightweight
2332010 CoRE WG IETF-77 Anaheim 6
Open Issues(45)
n Add single-subnet configuration to use cases (278)n Suggested by review Peter van der Stok and IETF85 WG discussion that
its best to start explaining the simplebasic cases and then gradually build up complexity
n Simplest case not shown yet would be a single subnet network configuration which is currently not present in the I-D only the 2-subnet configuration of Fig 1
n Question Do we need to add such case or doesnt it add muchn (Note that core-coap Figure 22 already shows the simplest case of link-local
multicast)
Open Issues(55)
n Add use case with controller (client) located on the backbone (279)n Suggested by discussion following review Peter van der Stok n Case missing where a controller (client) is located on the backbonen Question Do we need to add such case or does it add much
Group 2a other old friends
25
Angelo Castellani Salvatore Loreto Akbar Rahman Thomas Fossati Esko Dijk
IETF 86 March 2013httpwwwietforgiddraft-castellani-core-http-mapping-07txt
Best Practices for HTTP-CoAP Mapping
Implementation
Summary of Changes (from -06 rev)
n Based on discussion at last IETF-85 (Atlanta)n Clarification of HTTP-CoAP Proxies
n Definitionn Placementn Benefits
n Clarification of HTTP-CoAP URI mapping options
Goals of I-D
n For Reverse HTTP-CoAP Cross Protocol Proxyn Provide more detailed information to proxy designers (beyond
Section 10 of [I-Dietf-core-coap]) to help implement proxies that correctly inter-work with other CoAP and HTTP clientserver implementations that adhere to the specifications
n Define a consistent set of guidelines that a HTTP-to-CoAP proxy implementation MAY adhere to The main reason of adhering to such guidelines is to reduce variation between proxy implementations thereby increasing interoperabilityn As an example use case a proxy conforming to these guidelines made
by vendor A can be easily replaced by a proxy from vendor B that also conforms to the guidelines
I-D Outline
n Guidance on HTTP to CoAP URI mappingn HTTP-CoAP Reverse cross-protocol proxy implementation
n Placementn Response code amp media type translationsn Caching and congestion controln Cache refresh via Observen Use of CoAP blockwise transfern Security translation
n Security Considerationsn Traffic overflown Handling secured exchanges
Definitions (12)
n Cross-Protocol Proxy (or Cross Proxy) is a proxy performing a cross- protocol mapping in the context of this document a HTTP-CoAP (HC) mapping A Cross-Protocol Proxy can behave as a Forward Proxy Reverse Proxy or Interception Proxy n Note In this document we focus on the Reverse Proxy mode of the
Cross-Protocol Proxy
n Forward Proxy a message forwarding agent that is selected by the client usually via local configuration rules to receive requests for some type(s) of absolute URI and to attempt to satisfy those requests via translation to the protocol indicated by the absolute URI The user decides (is willing to) use the proxy as the forwardingdereferencing agent for a predefined subset of the URI space
Definitions (22)
n Reverse Proxy a receiving agent that acts as a layer above some other server(s) and translates the received requests to the underlying servers protocol It behaves as an origin (HTTP) server on its connection towards the (HTTP) client and as a (CoAP) client on its connection towards the (CoAP) origin server The (HTTP) client uses the origin-form [I-Dietf-httpbis-p1-messaging] as a request- target URI
n Reverse and Forward proxies are technically very similar with main differences being that the former appears to a client as an origin server while the latter does not and that clients may be unaware they are communicating with a proxy
Reverse Cross-Protocol Proxy Deployment Scenario
HTTP-CoAP Response Code Mapping
Implementation Experience
n Direct experience from the draft authorsn Squid HTTP-CoAP mapping module
n University of Padovan httptelecomdeiunipditiotn Both Forward and Interception operation supported
n HTTP-CoAP proxy based on EvCoAPn KoanLogic University of Bologna and Salvatore
Loreto (as individual)n httpsgithubcomkoanlogicwebthingstreemasterbridgesw
libevcoapn The document is open to input from other implementations
Next Steps
n Does the WG recommend adoptionn Intended status Informational Best Practicen Purpose Reduce arbitrary variation between proxy
implementations thereby increasing interoperability
Backup
HTTP to CoAP URI Mapping Options (12)
n Embedded Mapping n In an embedded mapping approach the HTTP URI has embedded
inside it the authority and path part of the CoAP URI n Example The CoAP resource nodecoapsomethingnetfoo can
be accessed by an HTTP client by inserting in the request httphc-proxysomethingnetcoapnodecoapsomethingnetfoo The Cross-Protocol Proxy then maps the URI to coapnodecoapsomethingnetfoo
HTTP to CoAP URI Mapping Options (22)
n Homogeneous Mapping n In a homogeneous mapping approach only the scheme portion of the URI
needs to be mapped The rest of the URI (ie authority path etc) remains unchanged
n Example The CoAP resource coapnodecoapsomethingnetfoo can be accessed by an HTTP client by requesting httpnodecoapsomethingnetfoo The Cross-Protocol Proxy receiving the request is responsible to map the URI to coapnodecoapsomethingnetfoo
n Background info n The assumption in this case is that the HTTP client would be able to
successfully resolve nodecoapsomethingnet using DNS infrastructure to return the IP address of the HC proxy Most likely this would be through a two step DNS lookup where the first DNS lookup would resolve somethingnet using public DNS infrastructure
n Then the second DNS lookup on the subdomain coap and the host node would typically be resolved by a DNS server operated by the owner of domain somethingnet So this domain owner can manage its own internal node names and subdomain allocation which would correspond to the CoAP namespace
Group 3 ldquonew workrdquo
39
Transport of CoAP over SMS USSD and GPRSdraft-becker-core-coap-sms-gprs-03
Markus Becker Kepeng LiKoojana Kuladinithi Thomas Poumltsch
CoRE WG IETF-86 Orlando
1 10
ScenariosI In M2M communication IP connectivity is not alwayssupported by the constrained end-points
I Power savingI Coverage (GPRS 3G LTE)
I SMS and USSD based communication is almost alwayssupported
210
Changes from draft-01 to draft-03 (1)
I Added possible CONNONACK interactions Section 5
I Option name changed from Reply-To- to Response-To-Section 16 and Section 101
I Added URI schemeEg coap+tel+15105550101well-knowncore Section 11
I Added possible M2M proxy scenarios Section 14
3 10
Changes from draft-01 to draft-03 (2)
I Added reference to bormann-coap-misc for other SMSencoding Section 71
I Updated requirements on Uri-Host and Uri-Port forcoap+tel Section 10
I Added security considerations Transport and ObjectSecurity Section 15
I Chose CoAP option numbers and updated the optionnumber table to meet draft-ietf-core-coap-10 Table 1
I Added an IANA registration for the URI scheme coap+telSection 162
4 10
Feedback Split coap+tel into coap+smsand coap+ussd
I How else to differ the various transports in the URII Or is the transport to use decided by the implementationI See alsodraft-silverajan-core-coap-alternative-transports-01
5 10
Feedback Response-To-Scheme option
I Should there be a Response-To-Scheme optionadditionally to Response-To-Uri-Host andResponse-To-Uri-Path
I So that a CoAP end-point which receives a request by CoAPover non-IP transport can be instructed to also use thenon-IP transport for the response
I This would imply to add aResponse-To-Telephone-Subscriber and more options forother transports that have other URI schemes than coapand coaps
6 10
Feedback Selection of Transport by Client
I When a server is reachable by various transports howdoes a client decide which transport to use
I Client-side application congurationI Leave it to a proxy which uses cellular network lookupfunctions
7 10
Feedback Potential Threats
I Trigger expensive short messagesI Redirect trac to other addressesI More threats
I Are the security measures in the draft adequateI Whitelisting on serverI Relying on cellular network security (dedicated M2M APNs)I Object security on CoAP payload
8 10
Feedback Message Exchanges
I Figures 11-18 show possible message exchanges whenclient and server have two addresses
I With NON Not using CoAP retransmission capabilityI ACK on different transportI Additional (costly) message on Transport AI Request with Content
I Which ones are allowedI Which ones are meaningful
9 10
Next steps
I Rene Uri schemeI Response-To-Scheme optionI Selection of Message ExchangeI Rene Proxying
10 10
CoAP13 Communicaon13 with13 Alternave13 Transports
Bill Silverajan and Teemu SavolainenCore WG IETF 86 Orlando
031113
Objecves13 (In13 Scope)
bull Unambiguous13 representaon13 of13 transport13 to13 be13 used13 by13 CoAP
bull Details13 how13 the13 transport13 can13 carry13 CoAP13 packet
bull Focus13 is13 on13 what13 CoAP13 communicaons13 requirements13 are
bull Allow13 CoAP13 mechanisms13 to13 exploit13 cross-shy‐layer13 opmisaons
51
031113
Non13 Goals13 (Not13 in13 scope)
bull Applicaon-shy‐level13 QoS13 requirementsbull Real-shy‐me13 constraintsbull Ordering13 reliability13 congeson13 controlbull Applicaon13 and13 network13 adaptaonbull Mobility13 and13 readdressing13 supportbull Network13 protocol13 (eg13 IPsec)13 configuraon
52
031113
Use13 Cases
bull NAT13 and13 Firewall13 traversal13 with13 TCPbull Delay13 Tolerant13 Networkingbull Non-shy‐IP13 Low13 Energy13 Protocols
53
031113
Related13 Work
bull OMA13 Lightweight13 M2M13 Protocolbull CoAP13 over13 SMSGPRSUSSD
54
031113
What13 does13 the13 work13 entail
bull The13 ability13 to13 specify13 end13 point13 idenfiers13 and13 URIs13 to13 reflect13 which13 transport13 CoAP13 can13 use
bull The13 ability13 to13 register13 to13 resource13 directories13 resource13 types13 reflecng13 types13 of13 transport13 available
bull Ability13 for13 mul-shy‐transport13 nodes13 to13 select13 transport13 to13 use13 without13 significant13 alteraon13 to13 CoAP13 packet13 structure
55
031113
Points13 to13 consider
bull Requirements13 for13 transport13 layer13 protocol13 to13 carry13 CoAP13 packets
bull Representaon13 of13 URI13 scheme13 for13 generic13 transport13 protocols
bull Opon13 extensions13 for13 CoAP13 to13 express13 available13 transports
bull Mapping13 and13 message13 sizebull Security13 consideraons
56
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
URI13 =13 scheme13 13 13 authority13 path-shy‐abempty13 [13 query13 ]
bull Within13 the13 scheme13 namebull In13 the13 URI13 pathbull As13 a13 query13 component
57
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
bull Within13 the13 scheme13 namendash coap+tel+15105550101well-shy‐knowncorendash coap+tcpexamplecom5683temperaturendash coap+blel2cap[1234567890AB]4pulse
bull Easy13 URI13 parsing13 for13 transport13 type13 and13 idenfier
bull Each13 new13 scheme13 name13 requires13 IANA13 registraon
58
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
bull In13 the13 URI13 pathndash coaphostexamplecomtransport=tcpwell-shy‐knowncorert=core-shy‐rd
bull Easy13 adopon13 of13 new13 (and13 experimental)13 CoAP13 transports13 without13 IANA13 registraon
bull Caveat13 Uri-shy‐Path13 opon13 is13 a13 Crical13 CoAP13 opon13 see13 secon13 54113 of13 I-shy‐Diep-shy‐core-shy‐coap
59
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
bull As13 a13 URI13 query13 componentndash coaphostexamplecomwell-shy‐knowncorert=core-shy‐rdq=tcp
bull Also13 easy13 to13 adopt13 new13 (and13 experimental)13 CoAP13 transports13 without13 IANA13 registraon
bull Caveat13 Uri-shy‐Query13 opon13 is13 a13 Crical13 CoAP13 opon13 see13 secon13 54113 of13 I-shy‐Diep-shy‐core-shy‐coap
60
031113
URI13 Representaons13 for13 CoAPNon13 standard13 ways
bull Transport13 in13 the13 URI13 authority13 componentndash coaphost[port][transport]13 instead13 of13 coaphost[port]
bull Transport13 as13 a13 service13 URLndash servicecoaptcphostexamplecomwell-shy‐knowncorert=core-shy‐rd
bull Above13 two13 ways13 break13 exisng13 compability13 (although13 both13 are13 based13 on13 valid13 IANA13 URI13 registraons)
61
031113
URI13 Representaons13 for13 CoAPMiscellaneous13 Consideraons
bull Ensure13 that13 transport13 is13 defined13 unambiguously13 (eg13 L2CAP13 used13 by13 both13 BLE13 and13 standard13 Bluetooth13 so13 avoid13 rdquocoap+l2caprdquo13 or13 rdquotransport=l2caprdquo13 or13 rdquoq=l2caprdquondash Can13 be13 done13 as13 WG13 consensusndash Namespace13 approach13 eg13 rdquocoap+blel2caprdquo13 or13 rdquoq=blel2caprdquo
bull Allow13 end-shy‐points13 to13 use13 CoAP13 Resource13 Directory13 to13 register13 alternave13 transports13 and13 idenfiers13 and13 provide13 periodic13 updatesndash Register13 rdquocore-shy‐transportrdquo13 resource13 type
62
031113
Transport13 Consideraons
bull Uniqueness13 of13 end-shy‐point13 idenficaonbull Communicaon13 support13 Unidireconal13 Bidireconal13 1N13 (broadcast13 mulcast13 anycast)13 messaging
bull Binary13 encoding13 Network13 byte13 orderingbull MTU13 correlaon13 with13 CoAP13 PDU13 sizebull Transport13 latency
63
031113
Security13 Consideraons
bull Drar13 does13 not13 introduce13 new13 security13 requirements13 by13 itself
bull There13 may13 be13 privacy13 issues13 if13 nodes13 use13 telephone13 numbers13 or13 MAC13 addresses13 as13 public13 end13 point13 idenfiers
64
Akbar Rahman
IETF 86 March 2013 httpwwwietforgiddraft-rahman-core-sleepy-02txt
Enhanced Sleepy Node Support for CoAP
Introduction
It is expected that in CoAP networks there will be a certain portion of devices that are sleepy and which may occasionally go into a sleep mode (ie go into a low power state to conserve power) and subsequently have reduced CoAP protocol communication ability
This I-D proposes a minimal and efficient mechanism building on the Resource Directory concept (which will be integrated into a CoAP Proxy) to enhance sleepy node support in CoAP networks
Main Question from IETF-85 (Atlanta)
What performance benefit does the proposed Sleepy Node support solution give in a network that already has standard CoAP caching enabled
Sleepy Node Performance Analysis
Experimental Network
1-5 clients
Both Sleepy and Non-
Sleepy servers
Sleepy Node Performance Analysis Network Setup
CoAPSleepyServer(s)
CoAPSleepAwareReverseProxy
CoAP
Client(s)
Request
Response
Sleep9AwareCoREResourceDirectoryCapability
PublishedSleepParameters
Sleep9AwareCoAPStoreandForwardCapability Response
Request
SleepAwareCoAP503ResponseCapability
CoAPCachingCapability
bull Server supports publishing sleep parameters to proxy bull Eg Irsquom going to be asleep for X seconds
bull Proxy supports sleep-awareness capabilities bull Proxy also supports caching capability based off of maxAge bull Protocol flow similar to approach of Figure 1 (Synchronous RD Based Sleep
Tracking) of I-D
Proxy capabilities can be selectively enableddisabled
Proxy ndash Server Interface
Client ndash Proxy Interface
CoAP Sleep-Aware Reverse Proxy Features CoRE Sleep-aware Resource Directory
Support storing published sleep parameters from CoAP servers sleepState (AWAKE ASLEEP) sleepDuration
Sleep-aware CoAP 503 Response Capability If CoAP request to a sleeping server is received proxy returns a
lsquo503 Retry-Afterrsquo response to client 503 contains a timestamp indicating when the sever will wake back up
(timestamp delivered in CoAP maxAge option) Sleep-aware CoAP Store-and-Forward Capability
If CoAP request to a sleeping server is received proxy stores request until server wakes up and then forwards it
Caching capability Cache GET responses from server if maxAge option is present
(this is not a sleep aware feature)
Goals of Performance Analysis
For networks having sleepy servers provide measurements to quantify the impact that CoAP sleep-awareness capabilities can have
See if sleep-awareness capabilities can
provide additional benefits even when CoAP caching is used
Overview of Performance Analysis Performed The analysis was broken up into a set of test scenarios Each test scenario used a different combination of the following
variables Client issued GET requests Server was configured as a sleepy or non-sleepy server Proxy caching of GET responses was enabled or disabled Proxy sleep-aware 503 response capability was enabled or disabled Proxy store-and-forward capability was enabled or disabled maxAge in GET responses ndash Two values were tested 60sec and 5sec of Clients ndash Two values were used ndash 1 client and 5 clients
For comparison purposes the following were held constant across all test scenarios Client issued a fixed number of requests (100) across all test scenarios Client used a delay between each GET request (35sec) to better exercise
proxyrsquos caching and sleep-awareness capabilities For sleepy server test scenarios the server slept 60 sec awake for 3 sec
Format of Results The following results were collected for each
test scenario
Breakdown of the and types of transactions occurring between clientproxyserver
ldquoGETrdquo ndash Test Scenario Results
GET ndash Description of Test Scenarios
TestScenarios-GET
Scenario
CoAPSleepyServerSe7ngs CoAPSleepAwareReverseProxySe7ngs CoAPClientSe7ngs
SleepDuragton(sec)
AwakeDuragton(sec)
maxAge(sec) Caching SleepAwareSAF+
503NumberofClients
NumberofGETs
DelayBetweenClient
Requests(sec)
1a 0 Always 60 Enabled Disabled 1 100 35
1b 60 3 60 Enabled Disabled 1 100 35
1c 60 3 60 Enabled Enabled 1 100 35
2a 0 Always 60 Enabled Disabled 5 100 35
2b 60 3 60 Enabled Disabled 5 100 35
2c 60 3 60 Enabled Enabled 5 100 35
3a 0 Always 5 Enabled Disabled 5 100 35
3b 60 3 5 Enabled Disabled 5 100 35
3c 60 3 5 Enabled Enabled 5 100 35
ldquoGETrdquo ndash Test Scenario 1 Results
maxAge = 60 and 1 Client
GET ndash Scenario 1 ClientProxy Interface Transaction Mix
Scenarios 1a - Non-Sleepy Server Caching Proxy maxAge = 60sec 1b- Sleepy Server Caching Proxy maxAge = 60sec 1c - Sleepy Server Sleep Aware Proxy maxAge = 60sec
Sleep Aware Proxy has better performance for sleepy servers
0
100
200
300
400
500
600
700
1a 1b 1c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
GET ndash Scenario 1 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
Scenarios 1a - Non-Sleepy Server Caching Proxy maxAge = 60sec 1b- Sleepy Server Caching Proxy maxAge = 60sec 1c - Sleepy Server Sleep Aware Proxy maxAge = 60sec
0
100
200
300
400
500
600
700
800
1a 1b 1c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
ldquoGETrdquo ndash Test Scenario 2 Results
maxAge = 60 and 5 Clients
GET ndash Scenario 2 ClientProxy Interface Transaction Mix
Sleep Aware Proxy has slightly better performance for sleepy servers
0
200
400
600
800
1000
1200
1400
2a 2b 2c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
Scenarios 2a - Non-Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2b- Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2c - Sleepy Server Sleep Aware Proxy maxAge = 60sec 5 Clients
See ldquoExperimental Artifactsrdquo Note 1
GET ndash Scenario 2 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has slightly better performance for sleepy servers
0
50
100
150
200
250
300
350
400
2a 2b 2c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
Scenarios 2a - Non-Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2b- Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2c - Sleepy Server Sleep Aware Proxy maxAge = 60sec 5 Clients
See ldquoExperimental Artifactsrdquo Note 2
Experimental Artifacts Note 1
Currently in the experiment the sleep aware proxy checks the cached state of a resource before putting a request into its Store-and-forward queue while a server is sleeping Once in the queue the proxy unconditionally forwards the queued requests to the server once it wakes up This is not the most efficient setup and can easily be improved If the proxy instead checks its cache again before forwarding each queued request it may not need to forward the request to the server For example if there are two queued GET requests in the proxyrsquos queue that address the same resource Only the first request needs to be sent to the server the second request can use the cached response from the first request
Note 2 Currently in the experiment the sleepy server sends a sleepState PUT request to the
proxy each time it goes to sleep This is not the most efficient setup and can easily be improved For example if the server assumes that the proxy can keep track of its ONOFF cycles with its internal timers (eg as per Fig 1 of I-D) then the number of messages from the sleepy server dramatically goes down
ldquoGETrdquo ndash Test Scenario 3 Results
maxAge = 5 and 5 Clients
GET ndash Scenario 3 ClientProxy Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
Scenarios 3a - Non-Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3b- Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3c - Sleepy Server Sleep Aware Proxy maxAge = 5sec 5 Clients
0
500
1000
1500
2000
2500
3000
3500
4000
4500
5000
3a 3b 3c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
GET ndash Scenario 3 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
0
1000
2000
3000
4000
5000
6000
7000
3a 3b 3c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
Scenarios 3a - Non-Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3b- Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3c - Sleepy Server Sleep Aware Proxy maxAge = 5sec 5 Clients
Conclusions
Conclusions These results show that sleep-aware CoAP
proxy features can significantly optimize communication with sleepy servers in most scenarios
These results also show that sleep-
awareness capabilities can provide additional benefits above and beyond CoAP caching in most scenarios
Backup
Current CoAP Support of Sleepy Node (12)
CoAP proxies can use a previously cached response to service a new GET request for a sleepy origin server (as in HTTP) But if no valid cache then proxy has to attempt to
retrieve and may fail if origin server is sleeping [I-Dietf-core-coap]
Clients can discover list of resources from RD (GET rd-lookuphellip) for sleepy servers But attempt to GET resource from sleepy origin server
may fail if origin server is sleeping [IDietf-core-link-format amp IDshelby-core-resource-
directory]
Current CoAP Support of Sleepy Node (22)
Lower layer support for sleepy nodes in most wireless technologies (eg WiFi ZigBee) But limited to MAC packet scheduling for sleepy nodes
and not aware of specific needs of IP applications (like CoAP)
Proposal ndash RD Based Sleep Tracking (14)
The current CoAP approach to support sleepy nodes can be significantly improved by introducing RD based mechanisms for a CoAP client to determine whether A targeted resource is located on a sleepy server A sleepy server is currently in sleep mode or not
There is any associated caching Proxy (possibly the RD itself) for a sleepy server
Proposal ndash RD Based Sleep Tracking (24)
We define the following new RD attributes to characterize the properties of a sleepy node SleepState - Indicates whether the node is currently in
sleep mode or not (ie Sleeping or Awake) SleepDuration - Indicates the maximum duration of time
that the node stays in sleep mode TimeSleeping - Indicates the length of time the node
has been sleeping (ie if Sleep State = Sleeping) NextSleep - Indicates the next time the node will go to
sleep (ie if Sleep State = Awake)
CachingProxy ndash Indicates the caching proxy of the sleepy node (ie the RD itself or another node)
Proposal ndash RD Based Sleep Tracking (34)
These attributes are all server (node) level and are new parameters added to the RD URI Template Variables
Finally we also define a new lookup-type (ss) for the RD lookup interface specified in [I-Dshelby-core-resource-directory] This new lookup-type supports looking up the
ldquoSleepStaterdquo (ss) of a specified end-point
Proposal ndash RD Based Sleep Tracking (44)
The three time based parameters (SleepDuration TimeSleeping NextSleep) can be based on either an absolute network time (for a time synchronized network) or a relative local time (measured at the local node)
Following the approach of [I-Dietf-core-link-format] and [I-Dshelby-core-resource-directory] sleep parameters for sleepy servers can be stored by the server in the RD and accessed by all interested clients
Examples of using these parameters in a synchronous or asynchronous manner are shown in the I-D
http6lowappnet coreIETF86 2013-03-12-13
We assume people have read the drafts
Meetings serve to advance difficult issues by making good use of face-to-face communications
Note Well Be aware of the IPR principles according to RFC 3979 and its updates
uumlBlue sheetsuumlScribe(s)
96
drar-shy‐iep-shy‐core-shy‐coapsubmiqed13 to13 IESG
2013-shy‐03-shy‐13
97
OMA Lightweight M2M Overview(A new standard using lots of IETF specs including DTLS
CoAP Block Observe Resource Directory SenMLhellip)
Zach ShelbyCoRE WG IETF-86 Orlando
OMA Lightweight M2Mbull Open Mobile Alliance is well known for Device Management (DM)bull OMA Lightweight M2M is a new standard from the alliance
ndash Focused on constrained Cellular and sensor network M2M devicesndash Driven by leading operators and vendors
bull Scopendash Interfaces protocol amp security between Device and Serverndash Object and Resource modelndash Bootstrap Device Access Control Connectivity and Firmware Objects
bull Draft Specifications are availablendash httpmemberopenmobileallianceorgftpPublic_documentsDM
LightweightM2MPermanent_documentsOMA-TS-LightweightM2M-V1_0_0-20130301-Dzip
bull Timelinendash Requirements and Architecture completed 3Q2012ndash Spec ready for Consistency Review 2Q2013ndash Candidate Approval expected 3Q2013
2 CoRE WG IETF-86 Orlando
Architecture
3
Scope of LWM2M
CoRE WG IETF-86 Orlando
Object Model
bull A Client has one or more Object Instancesbull An Object is a collection of Resourcesbull A Resource is an atomic piece of information
ndash Read Written or Executed
bull Resources can have multiple instancesbull Objects and Resources are identified by a
16-bit Integer Instances by an 8-bit Integerbull ObjectsResources are accessed with
simple URIs Object IDObject InstanceResource ID
eg 1213
4 CoRE WG IETF-86 Orlando
CoRE WG IETF-86 Orlando
CoRE Resource Directory
draft-shelby-core-resource-directory-05
Z Shelby C Bormann S Krco
Backgroundbull Not a new concept
ndash think web search engine or any link directorybull Defines the interfaces to a Resource Directorybull Based on Web Linking framework and the CoRE Link Formatbull Generic REST design for use over HTTP and CoAPbull Used by OMA Lightweight M2Mbull Has already been deployed
ndash In traffic monitoring systemsndash In street lighting systemsndash For vehicular asset trackingndash By a major Cellular M2M operator
Changes since -04
bull Restricted Update to parameter updatesbull Added pagination support for the Lookup interfacebull Changed rt= to et= for the registration amp update
interfacebull Added group support
Group Management
bull RD now includes group management featuresbull New Group Function Set
ndash Register a groupbull Group name domain multicast address endpoint members
ndash Remove a groupbull Group lookup using the Lookup Function Set
ndash List registered groupsndash Find the members of a groupndash Find groups with certain endpoints or resources
Registering a Group
EP RD
| |
| - POST rd-groupgp=lights ltgtep=node1 --gt |
| |
| |
| lt---- 201 Created Location rd-group12 ---- |
| |
Req POST coaprdexamplecomrd-groupgp=lights
Payload
ltgtep=node1
ltgtep=node2
Res 201 Created
Location rd-group12
Looking up Group Members
Client RD
| |
| ----- GET rd-lookupepgp=lights1 ----------------------gt |
| |
| |
| lt-- 205 Content ltrdgtd=domain1ltrdgtd=domain2 --------- |
| |
Req GET rd-lookupepgp=lights1
Res 205 Content
ltcoaphostportgtep=node1
ltcoaphostportgtep=node2rdquo
Things for the futurebull Support for JSON representation of Web Links
ndash httptoolsietforgiddraft-bormann-core-links-json-02txtbull Registry for RD registration query parameters
ndash Already OMA Lightweight has defined some new onesbull More examples
Group 3 ldquonew workrdquo(continued)
109
drar-shy‐greevenbosch-shy‐core-shy‐profile-shy‐descripon-shy‐01Bert13 GreevenboschJeroen13 Hoebeke
Isam13 IshaqFloris13 Van13 den13 Abeele
Descripon
bull JSON13 format13 for13 signalling13 the13 servers13 capabilies
bull Signalling13 of13 supported13 opons13 media13 types13 and13 block13 sizendash Other13 items13 can13 be13 added
bull Filtering13 on13 specific13 fields13 through13 URI-shy‐Querybull Link13 hqpdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐profile-shy‐descripon
well-shy‐knownprofile
bull To13 acquire13 profile13 data13 of13 resources13 on13 a13 parcular13 service13 the13 well-shy‐knownprofile13 URI-shy‐path13 is13 introduced
bull For13 example13 to13 get13 all13 informaon13 from13 sensors13 served13 by13 wwwexampleorg13 we13 can13 do13 a13 GET13 to13 coapwwwexampleorgwell-shy‐knownprofile
bull Filtering13 on13 parcular13 resources13 is13 done13 through13 URI-shy‐Queries
Format
bull Currently13 the13 following13 fields13 are13 definedndash ldquopathrdquo13 contains13 the13 URI-shy‐path13 associated13 with13 a13 resource
ndash ldquooprdquo13 a13 numerical13 list13 of13 supported13 opon13 numbers
ndash ldquocfrdquo13 a13 numerical13 list13 of13 supported13 content-shy‐format13 numbers
ndash ldquob1srdquo13 ldquob2srdquo13 supported13 block13 sizes13 for13 Block113 and13 Block213 respecvely
Examplebull On13 the13 right13 is13 an13 example13 of13 a13 camera13 sensor13 at13 coapwwwexampleorgcam13 that13 supports13 the13 Uri-shy‐Host13 (3)13 ETag13 (4)13 Uri-shy‐Port13 (7)13 Uri-shy‐Path13 (11)13 Content-shy‐Format13 (12)13 Token13 (19)13 Block213 (23)13 and13 Proxy-shy‐Uri13 (35)13 opons
bull The13 supported13 content13 formats13 are13 textplain13 (0)13 applicaon13 link-shy‐format13 (40)13 and13 applicaonjson13 (50)
bull The13 supported13 Block213 can13 use13 25613 or13 51213 byte13 blocks
Req13 GET13 coapwwwexampleorgwell-shy‐knownprofile13 Res13 20513 Content13 (applicationjson)13 13 13 13 profile13 13 13 13 13 13 13 13 pathcam13 13 13 13 op[3471112192335]13 13 13 13 13 cf[04050]13 13 13 13 13 b2s[45]13 13 13 13
Filtering13 through13 use13 of13 URI-shy‐Query
bull Filtering13 can13 be13 done13 through13 the13 URI-shy‐Querybull Query13 format13 N=V
ndash N13 is13 a13 profile13 fieldndash V13 is13 the13 desired13 value
bull Examplesndash To13 find13 resources13 that13 support13 content13 format13 ldquoapplicaonjsonrdquo
13 GET13 wwwexampleorgwell-shy‐knownprofilecf=50ndash To13 get13 informaon13 about13 the13 camera
13 GET13 wwwexampleorgwell-shy‐knownprofilepath=cam
Open13 issues
bull Which13 other13 profile13 data13 needs13 signallingndash Content-shy‐type13 for13 different13 methods
bull Fix13 the13 order13 in13 which13 the13 profile13 fields13 must13 appearndash Non-shy‐fixed13 order13 easier13 extensible
bull Inheritance13 of13 a13 profile13 descriponbull Extend13 usage13 to13 signal13 the13 client13 profilebull Integraon13 with13 link13 format
Thank13 youQuesons
drar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval-shy‐00
Bert13 Greevenbosch
Descripon
bull The13 ldquoMinimumRequestInterval13 opon13 can13 be13 used13 to13 indicate13 the13 minimum13 me13 between13 two13 requests13 in13 a13 transacon
bull Originally13 intended13 for13 Block13 but13 also13 usable13 for13 other13 transaconsndash Example13 browsing13 a13 server
bull The13 goal13 is13 to13 reduce13 the13 server13 load13 and13 network13 traffic
bull Link13 hqpsdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval
Usage
bull The13 client13 keeps13 the13 server13 informed13 about13 its13 request13 speed13 through13 inclusion13 of13 the13 ldquoMinimumRequestIntervalrdquo13 opon
bull In13 responses13 the13 server13 fixes13 the13 minimum13 request13 interval13 through13 the13 same13 opon
bull The13 client13 obeys13 the13 speed13 indicated13 by13 the13 server
bull The13 client13 can13 send13 slower13 but13 not13 faster
Advantages
bull The13 server13 has13 means13 to13 limit13 the13 amount13 of13 incoming13 traffic
bull The13 server13 can13 prevent13 to13 become13 overloaded13 with13 too13 many13 tasks
bull The13 server13 does13 not13 need13 arficially13 slow13 down13 the13 client13 by13 sending13 late13 ACKsndash No13 need13 to13 keep13 track13 of13 delayed13 ACKsndash The13 server13 can13 perform13 other13 tasks13 instead
bull Reduced13 network13 traffic
Thank13 youQuesons
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-links-json-02txt
123
RFC 6690 (link-format) documents are somewhat foreign to many web app developerssect would prefer to have them in JSON format
There is no standard way to represent link-format documents in applicationssect but everyone knows how to handle JSON
Define a standard JSON translation for link-format
Itrsquos
not
rock
et
scien
ce
ltsensorsgtct=40title=Sensor Index ltsensorstempgtrt=temperature-cif=sensor ltsensorslightgtrt=light-luxif=sensor lthttpwwwexamplecomsensorst123gt anchor=sensorstemprel=describedby lttgtanchor=sensorstemprel=alternate [hrefsensorsct40titleSensor Index hrefsensorstemprttemperature-cifsensor hrefsensorslightrtlight-luxifsensor hrefhttpwwwexamplecomsensorst123 anchorsensorstempreldescribedby hreftanchorsensorstemprelalternate]
124
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-ipsec-for-coap-00txt
IPsec definitions for CoAP Mostly placeholder at this time Who has implementation experience with this
125
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-cross-reverse-convention-00txt
This draft has two lines of payload(based on a WGLC comment by Cullen Jennings)
coap12344567foobara=3
httpwwwproxycomwellknowncore-translate1234_4567foobara=3
Is that a useful convention to have
126
Insert CI slides here
127
128
0
5
10
15
20
25
30
35
40
10 20 30 40 50 60 70
good
put (
pps)
pps
Goodput vs pps (Econotags)
goodput
[Khattak preliminary]
Congestion Control
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-cocoa-00txt
ldquoadvancedrdquo cc (The draft is just a first shot) Others may have better ideas
129
Insert post-WGLC discussion slides here
130
Stop Continue Start
131
An Agile Retrospective
http6lowappnet coreIETF86 2013-03-12-13
Stop
132
Endless new CoAP optionssect instead use RESTful as much as possible
Move general security lifecycle out Looking at theoretical problems
http6lowappnet coreIETF86 2013-03-12-13
Continue
Interops Running code Look at real-world examples and deployments Solve their actual problems
sect Unilateral enhancements eg higher performance congestion control
sect Transports (SMS hellip)sect Make Web linking and Directories more and more usefulsect RESTful Design Paradigms for real-world problems
133
http6lowappnet coreIETF86 2013-03-12-13
Start
Further push into the (browser) web world (HTML5 browser security)
Specific supporting worksect SenMLsect URI work (dev URN hellip)sect Security Processes (next slide)
Spin outsect (We donrsquot really get to decide where this is done)
134
http6lowappnet coreIETF86 2013-03-12-13
Security
Integrate Application Network Group Keyingsect Tunnel-free setup
Donrsquot redo what has been done alreadysect ZigBee IP is finesect But what about other scenarios
Simple REST interfaces for working with keying materials and authorizationsect Start with defining objectives
Object Security for Constrained Nodes135
Re-chartering CoREWhat do we want to do now that wersquore grown up
Zach ShelbyCoRE WG IETF-86 Orlando
What is the scope
bull So we have a protocol and Web Linking what next
bull Keep with what we know besthellip1 Enhancements around CoAP2 New transports for CoAP3 New representations for Web Links4 General application layer solutions
CoRE WG IETF-86 Orlando 2
Enhancements around CoAP
bull Advanced congestion control
CoRE WG IETF-86 Orlando 3
New Transports for CoAP
bull Infrastructure for CoAP over foondash httptoolsietforgiddraft-silverajan-core-
coap-alternative-transports-01txtbull CoAP over SMS
ndash httptoolsietforgiddraft-becker-core-coap-sms-gprs-03txt
ndash OMA Lightweightbull CoAP over TCP
ndash httptoolsietforgiddraft-li-core-coap-payload-length-option-01txt
CoRE WG IETF-86 Orlando 4
New support for Web Links
bull JSON Web Linksndash httptoolsietforgiddraft-bormann-core-links-
json-02txt
2332010 CoRE WG IETF-77 Anaheim 5
General application layer solutions
bull Resource Directoryndash httptoolsietforgiddraft-shelby-core-
resource-directory-05txtndash OMA Lightweight
2332010 CoRE WG IETF-77 Anaheim 6
Open Issues(55)
n Add use case with controller (client) located on the backbone (279)n Suggested by discussion following review Peter van der Stok n Case missing where a controller (client) is located on the backbonen Question Do we need to add such case or does it add much
Group 2a other old friends
25
Angelo Castellani Salvatore Loreto Akbar Rahman Thomas Fossati Esko Dijk
IETF 86 March 2013httpwwwietforgiddraft-castellani-core-http-mapping-07txt
Best Practices for HTTP-CoAP Mapping
Implementation
Summary of Changes (from -06 rev)
n Based on discussion at last IETF-85 (Atlanta)n Clarification of HTTP-CoAP Proxies
n Definitionn Placementn Benefits
n Clarification of HTTP-CoAP URI mapping options
Goals of I-D
n For Reverse HTTP-CoAP Cross Protocol Proxyn Provide more detailed information to proxy designers (beyond
Section 10 of [I-Dietf-core-coap]) to help implement proxies that correctly inter-work with other CoAP and HTTP clientserver implementations that adhere to the specifications
n Define a consistent set of guidelines that a HTTP-to-CoAP proxy implementation MAY adhere to The main reason of adhering to such guidelines is to reduce variation between proxy implementations thereby increasing interoperabilityn As an example use case a proxy conforming to these guidelines made
by vendor A can be easily replaced by a proxy from vendor B that also conforms to the guidelines
I-D Outline
n Guidance on HTTP to CoAP URI mappingn HTTP-CoAP Reverse cross-protocol proxy implementation
n Placementn Response code amp media type translationsn Caching and congestion controln Cache refresh via Observen Use of CoAP blockwise transfern Security translation
n Security Considerationsn Traffic overflown Handling secured exchanges
Definitions (12)
n Cross-Protocol Proxy (or Cross Proxy) is a proxy performing a cross- protocol mapping in the context of this document a HTTP-CoAP (HC) mapping A Cross-Protocol Proxy can behave as a Forward Proxy Reverse Proxy or Interception Proxy n Note In this document we focus on the Reverse Proxy mode of the
Cross-Protocol Proxy
n Forward Proxy a message forwarding agent that is selected by the client usually via local configuration rules to receive requests for some type(s) of absolute URI and to attempt to satisfy those requests via translation to the protocol indicated by the absolute URI The user decides (is willing to) use the proxy as the forwardingdereferencing agent for a predefined subset of the URI space
Definitions (22)
n Reverse Proxy a receiving agent that acts as a layer above some other server(s) and translates the received requests to the underlying servers protocol It behaves as an origin (HTTP) server on its connection towards the (HTTP) client and as a (CoAP) client on its connection towards the (CoAP) origin server The (HTTP) client uses the origin-form [I-Dietf-httpbis-p1-messaging] as a request- target URI
n Reverse and Forward proxies are technically very similar with main differences being that the former appears to a client as an origin server while the latter does not and that clients may be unaware they are communicating with a proxy
Reverse Cross-Protocol Proxy Deployment Scenario
HTTP-CoAP Response Code Mapping
Implementation Experience
n Direct experience from the draft authorsn Squid HTTP-CoAP mapping module
n University of Padovan httptelecomdeiunipditiotn Both Forward and Interception operation supported
n HTTP-CoAP proxy based on EvCoAPn KoanLogic University of Bologna and Salvatore
Loreto (as individual)n httpsgithubcomkoanlogicwebthingstreemasterbridgesw
libevcoapn The document is open to input from other implementations
Next Steps
n Does the WG recommend adoptionn Intended status Informational Best Practicen Purpose Reduce arbitrary variation between proxy
implementations thereby increasing interoperability
Backup
HTTP to CoAP URI Mapping Options (12)
n Embedded Mapping n In an embedded mapping approach the HTTP URI has embedded
inside it the authority and path part of the CoAP URI n Example The CoAP resource nodecoapsomethingnetfoo can
be accessed by an HTTP client by inserting in the request httphc-proxysomethingnetcoapnodecoapsomethingnetfoo The Cross-Protocol Proxy then maps the URI to coapnodecoapsomethingnetfoo
HTTP to CoAP URI Mapping Options (22)
n Homogeneous Mapping n In a homogeneous mapping approach only the scheme portion of the URI
needs to be mapped The rest of the URI (ie authority path etc) remains unchanged
n Example The CoAP resource coapnodecoapsomethingnetfoo can be accessed by an HTTP client by requesting httpnodecoapsomethingnetfoo The Cross-Protocol Proxy receiving the request is responsible to map the URI to coapnodecoapsomethingnetfoo
n Background info n The assumption in this case is that the HTTP client would be able to
successfully resolve nodecoapsomethingnet using DNS infrastructure to return the IP address of the HC proxy Most likely this would be through a two step DNS lookup where the first DNS lookup would resolve somethingnet using public DNS infrastructure
n Then the second DNS lookup on the subdomain coap and the host node would typically be resolved by a DNS server operated by the owner of domain somethingnet So this domain owner can manage its own internal node names and subdomain allocation which would correspond to the CoAP namespace
Group 3 ldquonew workrdquo
39
Transport of CoAP over SMS USSD and GPRSdraft-becker-core-coap-sms-gprs-03
Markus Becker Kepeng LiKoojana Kuladinithi Thomas Poumltsch
CoRE WG IETF-86 Orlando
1 10
ScenariosI In M2M communication IP connectivity is not alwayssupported by the constrained end-points
I Power savingI Coverage (GPRS 3G LTE)
I SMS and USSD based communication is almost alwayssupported
210
Changes from draft-01 to draft-03 (1)
I Added possible CONNONACK interactions Section 5
I Option name changed from Reply-To- to Response-To-Section 16 and Section 101
I Added URI schemeEg coap+tel+15105550101well-knowncore Section 11
I Added possible M2M proxy scenarios Section 14
3 10
Changes from draft-01 to draft-03 (2)
I Added reference to bormann-coap-misc for other SMSencoding Section 71
I Updated requirements on Uri-Host and Uri-Port forcoap+tel Section 10
I Added security considerations Transport and ObjectSecurity Section 15
I Chose CoAP option numbers and updated the optionnumber table to meet draft-ietf-core-coap-10 Table 1
I Added an IANA registration for the URI scheme coap+telSection 162
4 10
Feedback Split coap+tel into coap+smsand coap+ussd
I How else to differ the various transports in the URII Or is the transport to use decided by the implementationI See alsodraft-silverajan-core-coap-alternative-transports-01
5 10
Feedback Response-To-Scheme option
I Should there be a Response-To-Scheme optionadditionally to Response-To-Uri-Host andResponse-To-Uri-Path
I So that a CoAP end-point which receives a request by CoAPover non-IP transport can be instructed to also use thenon-IP transport for the response
I This would imply to add aResponse-To-Telephone-Subscriber and more options forother transports that have other URI schemes than coapand coaps
6 10
Feedback Selection of Transport by Client
I When a server is reachable by various transports howdoes a client decide which transport to use
I Client-side application congurationI Leave it to a proxy which uses cellular network lookupfunctions
7 10
Feedback Potential Threats
I Trigger expensive short messagesI Redirect trac to other addressesI More threats
I Are the security measures in the draft adequateI Whitelisting on serverI Relying on cellular network security (dedicated M2M APNs)I Object security on CoAP payload
8 10
Feedback Message Exchanges
I Figures 11-18 show possible message exchanges whenclient and server have two addresses
I With NON Not using CoAP retransmission capabilityI ACK on different transportI Additional (costly) message on Transport AI Request with Content
I Which ones are allowedI Which ones are meaningful
9 10
Next steps
I Rene Uri schemeI Response-To-Scheme optionI Selection of Message ExchangeI Rene Proxying
10 10
CoAP13 Communicaon13 with13 Alternave13 Transports
Bill Silverajan and Teemu SavolainenCore WG IETF 86 Orlando
031113
Objecves13 (In13 Scope)
bull Unambiguous13 representaon13 of13 transport13 to13 be13 used13 by13 CoAP
bull Details13 how13 the13 transport13 can13 carry13 CoAP13 packet
bull Focus13 is13 on13 what13 CoAP13 communicaons13 requirements13 are
bull Allow13 CoAP13 mechanisms13 to13 exploit13 cross-shy‐layer13 opmisaons
51
031113
Non13 Goals13 (Not13 in13 scope)
bull Applicaon-shy‐level13 QoS13 requirementsbull Real-shy‐me13 constraintsbull Ordering13 reliability13 congeson13 controlbull Applicaon13 and13 network13 adaptaonbull Mobility13 and13 readdressing13 supportbull Network13 protocol13 (eg13 IPsec)13 configuraon
52
031113
Use13 Cases
bull NAT13 and13 Firewall13 traversal13 with13 TCPbull Delay13 Tolerant13 Networkingbull Non-shy‐IP13 Low13 Energy13 Protocols
53
031113
Related13 Work
bull OMA13 Lightweight13 M2M13 Protocolbull CoAP13 over13 SMSGPRSUSSD
54
031113
What13 does13 the13 work13 entail
bull The13 ability13 to13 specify13 end13 point13 idenfiers13 and13 URIs13 to13 reflect13 which13 transport13 CoAP13 can13 use
bull The13 ability13 to13 register13 to13 resource13 directories13 resource13 types13 reflecng13 types13 of13 transport13 available
bull Ability13 for13 mul-shy‐transport13 nodes13 to13 select13 transport13 to13 use13 without13 significant13 alteraon13 to13 CoAP13 packet13 structure
55
031113
Points13 to13 consider
bull Requirements13 for13 transport13 layer13 protocol13 to13 carry13 CoAP13 packets
bull Representaon13 of13 URI13 scheme13 for13 generic13 transport13 protocols
bull Opon13 extensions13 for13 CoAP13 to13 express13 available13 transports
bull Mapping13 and13 message13 sizebull Security13 consideraons
56
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
URI13 =13 scheme13 13 13 authority13 path-shy‐abempty13 [13 query13 ]
bull Within13 the13 scheme13 namebull In13 the13 URI13 pathbull As13 a13 query13 component
57
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
bull Within13 the13 scheme13 namendash coap+tel+15105550101well-shy‐knowncorendash coap+tcpexamplecom5683temperaturendash coap+blel2cap[1234567890AB]4pulse
bull Easy13 URI13 parsing13 for13 transport13 type13 and13 idenfier
bull Each13 new13 scheme13 name13 requires13 IANA13 registraon
58
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
bull In13 the13 URI13 pathndash coaphostexamplecomtransport=tcpwell-shy‐knowncorert=core-shy‐rd
bull Easy13 adopon13 of13 new13 (and13 experimental)13 CoAP13 transports13 without13 IANA13 registraon
bull Caveat13 Uri-shy‐Path13 opon13 is13 a13 Crical13 CoAP13 opon13 see13 secon13 54113 of13 I-shy‐Diep-shy‐core-shy‐coap
59
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
bull As13 a13 URI13 query13 componentndash coaphostexamplecomwell-shy‐knowncorert=core-shy‐rdq=tcp
bull Also13 easy13 to13 adopt13 new13 (and13 experimental)13 CoAP13 transports13 without13 IANA13 registraon
bull Caveat13 Uri-shy‐Query13 opon13 is13 a13 Crical13 CoAP13 opon13 see13 secon13 54113 of13 I-shy‐Diep-shy‐core-shy‐coap
60
031113
URI13 Representaons13 for13 CoAPNon13 standard13 ways
bull Transport13 in13 the13 URI13 authority13 componentndash coaphost[port][transport]13 instead13 of13 coaphost[port]
bull Transport13 as13 a13 service13 URLndash servicecoaptcphostexamplecomwell-shy‐knowncorert=core-shy‐rd
bull Above13 two13 ways13 break13 exisng13 compability13 (although13 both13 are13 based13 on13 valid13 IANA13 URI13 registraons)
61
031113
URI13 Representaons13 for13 CoAPMiscellaneous13 Consideraons
bull Ensure13 that13 transport13 is13 defined13 unambiguously13 (eg13 L2CAP13 used13 by13 both13 BLE13 and13 standard13 Bluetooth13 so13 avoid13 rdquocoap+l2caprdquo13 or13 rdquotransport=l2caprdquo13 or13 rdquoq=l2caprdquondash Can13 be13 done13 as13 WG13 consensusndash Namespace13 approach13 eg13 rdquocoap+blel2caprdquo13 or13 rdquoq=blel2caprdquo
bull Allow13 end-shy‐points13 to13 use13 CoAP13 Resource13 Directory13 to13 register13 alternave13 transports13 and13 idenfiers13 and13 provide13 periodic13 updatesndash Register13 rdquocore-shy‐transportrdquo13 resource13 type
62
031113
Transport13 Consideraons
bull Uniqueness13 of13 end-shy‐point13 idenficaonbull Communicaon13 support13 Unidireconal13 Bidireconal13 1N13 (broadcast13 mulcast13 anycast)13 messaging
bull Binary13 encoding13 Network13 byte13 orderingbull MTU13 correlaon13 with13 CoAP13 PDU13 sizebull Transport13 latency
63
031113
Security13 Consideraons
bull Drar13 does13 not13 introduce13 new13 security13 requirements13 by13 itself
bull There13 may13 be13 privacy13 issues13 if13 nodes13 use13 telephone13 numbers13 or13 MAC13 addresses13 as13 public13 end13 point13 idenfiers
64
Akbar Rahman
IETF 86 March 2013 httpwwwietforgiddraft-rahman-core-sleepy-02txt
Enhanced Sleepy Node Support for CoAP
Introduction
It is expected that in CoAP networks there will be a certain portion of devices that are sleepy and which may occasionally go into a sleep mode (ie go into a low power state to conserve power) and subsequently have reduced CoAP protocol communication ability
This I-D proposes a minimal and efficient mechanism building on the Resource Directory concept (which will be integrated into a CoAP Proxy) to enhance sleepy node support in CoAP networks
Main Question from IETF-85 (Atlanta)
What performance benefit does the proposed Sleepy Node support solution give in a network that already has standard CoAP caching enabled
Sleepy Node Performance Analysis
Experimental Network
1-5 clients
Both Sleepy and Non-
Sleepy servers
Sleepy Node Performance Analysis Network Setup
CoAPSleepyServer(s)
CoAPSleepAwareReverseProxy
CoAP
Client(s)
Request
Response
Sleep9AwareCoREResourceDirectoryCapability
PublishedSleepParameters
Sleep9AwareCoAPStoreandForwardCapability Response
Request
SleepAwareCoAP503ResponseCapability
CoAPCachingCapability
bull Server supports publishing sleep parameters to proxy bull Eg Irsquom going to be asleep for X seconds
bull Proxy supports sleep-awareness capabilities bull Proxy also supports caching capability based off of maxAge bull Protocol flow similar to approach of Figure 1 (Synchronous RD Based Sleep
Tracking) of I-D
Proxy capabilities can be selectively enableddisabled
Proxy ndash Server Interface
Client ndash Proxy Interface
CoAP Sleep-Aware Reverse Proxy Features CoRE Sleep-aware Resource Directory
Support storing published sleep parameters from CoAP servers sleepState (AWAKE ASLEEP) sleepDuration
Sleep-aware CoAP 503 Response Capability If CoAP request to a sleeping server is received proxy returns a
lsquo503 Retry-Afterrsquo response to client 503 contains a timestamp indicating when the sever will wake back up
(timestamp delivered in CoAP maxAge option) Sleep-aware CoAP Store-and-Forward Capability
If CoAP request to a sleeping server is received proxy stores request until server wakes up and then forwards it
Caching capability Cache GET responses from server if maxAge option is present
(this is not a sleep aware feature)
Goals of Performance Analysis
For networks having sleepy servers provide measurements to quantify the impact that CoAP sleep-awareness capabilities can have
See if sleep-awareness capabilities can
provide additional benefits even when CoAP caching is used
Overview of Performance Analysis Performed The analysis was broken up into a set of test scenarios Each test scenario used a different combination of the following
variables Client issued GET requests Server was configured as a sleepy or non-sleepy server Proxy caching of GET responses was enabled or disabled Proxy sleep-aware 503 response capability was enabled or disabled Proxy store-and-forward capability was enabled or disabled maxAge in GET responses ndash Two values were tested 60sec and 5sec of Clients ndash Two values were used ndash 1 client and 5 clients
For comparison purposes the following were held constant across all test scenarios Client issued a fixed number of requests (100) across all test scenarios Client used a delay between each GET request (35sec) to better exercise
proxyrsquos caching and sleep-awareness capabilities For sleepy server test scenarios the server slept 60 sec awake for 3 sec
Format of Results The following results were collected for each
test scenario
Breakdown of the and types of transactions occurring between clientproxyserver
ldquoGETrdquo ndash Test Scenario Results
GET ndash Description of Test Scenarios
TestScenarios-GET
Scenario
CoAPSleepyServerSe7ngs CoAPSleepAwareReverseProxySe7ngs CoAPClientSe7ngs
SleepDuragton(sec)
AwakeDuragton(sec)
maxAge(sec) Caching SleepAwareSAF+
503NumberofClients
NumberofGETs
DelayBetweenClient
Requests(sec)
1a 0 Always 60 Enabled Disabled 1 100 35
1b 60 3 60 Enabled Disabled 1 100 35
1c 60 3 60 Enabled Enabled 1 100 35
2a 0 Always 60 Enabled Disabled 5 100 35
2b 60 3 60 Enabled Disabled 5 100 35
2c 60 3 60 Enabled Enabled 5 100 35
3a 0 Always 5 Enabled Disabled 5 100 35
3b 60 3 5 Enabled Disabled 5 100 35
3c 60 3 5 Enabled Enabled 5 100 35
ldquoGETrdquo ndash Test Scenario 1 Results
maxAge = 60 and 1 Client
GET ndash Scenario 1 ClientProxy Interface Transaction Mix
Scenarios 1a - Non-Sleepy Server Caching Proxy maxAge = 60sec 1b- Sleepy Server Caching Proxy maxAge = 60sec 1c - Sleepy Server Sleep Aware Proxy maxAge = 60sec
Sleep Aware Proxy has better performance for sleepy servers
0
100
200
300
400
500
600
700
1a 1b 1c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
GET ndash Scenario 1 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
Scenarios 1a - Non-Sleepy Server Caching Proxy maxAge = 60sec 1b- Sleepy Server Caching Proxy maxAge = 60sec 1c - Sleepy Server Sleep Aware Proxy maxAge = 60sec
0
100
200
300
400
500
600
700
800
1a 1b 1c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
ldquoGETrdquo ndash Test Scenario 2 Results
maxAge = 60 and 5 Clients
GET ndash Scenario 2 ClientProxy Interface Transaction Mix
Sleep Aware Proxy has slightly better performance for sleepy servers
0
200
400
600
800
1000
1200
1400
2a 2b 2c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
Scenarios 2a - Non-Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2b- Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2c - Sleepy Server Sleep Aware Proxy maxAge = 60sec 5 Clients
See ldquoExperimental Artifactsrdquo Note 1
GET ndash Scenario 2 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has slightly better performance for sleepy servers
0
50
100
150
200
250
300
350
400
2a 2b 2c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
Scenarios 2a - Non-Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2b- Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2c - Sleepy Server Sleep Aware Proxy maxAge = 60sec 5 Clients
See ldquoExperimental Artifactsrdquo Note 2
Experimental Artifacts Note 1
Currently in the experiment the sleep aware proxy checks the cached state of a resource before putting a request into its Store-and-forward queue while a server is sleeping Once in the queue the proxy unconditionally forwards the queued requests to the server once it wakes up This is not the most efficient setup and can easily be improved If the proxy instead checks its cache again before forwarding each queued request it may not need to forward the request to the server For example if there are two queued GET requests in the proxyrsquos queue that address the same resource Only the first request needs to be sent to the server the second request can use the cached response from the first request
Note 2 Currently in the experiment the sleepy server sends a sleepState PUT request to the
proxy each time it goes to sleep This is not the most efficient setup and can easily be improved For example if the server assumes that the proxy can keep track of its ONOFF cycles with its internal timers (eg as per Fig 1 of I-D) then the number of messages from the sleepy server dramatically goes down
ldquoGETrdquo ndash Test Scenario 3 Results
maxAge = 5 and 5 Clients
GET ndash Scenario 3 ClientProxy Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
Scenarios 3a - Non-Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3b- Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3c - Sleepy Server Sleep Aware Proxy maxAge = 5sec 5 Clients
0
500
1000
1500
2000
2500
3000
3500
4000
4500
5000
3a 3b 3c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
GET ndash Scenario 3 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
0
1000
2000
3000
4000
5000
6000
7000
3a 3b 3c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
Scenarios 3a - Non-Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3b- Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3c - Sleepy Server Sleep Aware Proxy maxAge = 5sec 5 Clients
Conclusions
Conclusions These results show that sleep-aware CoAP
proxy features can significantly optimize communication with sleepy servers in most scenarios
These results also show that sleep-
awareness capabilities can provide additional benefits above and beyond CoAP caching in most scenarios
Backup
Current CoAP Support of Sleepy Node (12)
CoAP proxies can use a previously cached response to service a new GET request for a sleepy origin server (as in HTTP) But if no valid cache then proxy has to attempt to
retrieve and may fail if origin server is sleeping [I-Dietf-core-coap]
Clients can discover list of resources from RD (GET rd-lookuphellip) for sleepy servers But attempt to GET resource from sleepy origin server
may fail if origin server is sleeping [IDietf-core-link-format amp IDshelby-core-resource-
directory]
Current CoAP Support of Sleepy Node (22)
Lower layer support for sleepy nodes in most wireless technologies (eg WiFi ZigBee) But limited to MAC packet scheduling for sleepy nodes
and not aware of specific needs of IP applications (like CoAP)
Proposal ndash RD Based Sleep Tracking (14)
The current CoAP approach to support sleepy nodes can be significantly improved by introducing RD based mechanisms for a CoAP client to determine whether A targeted resource is located on a sleepy server A sleepy server is currently in sleep mode or not
There is any associated caching Proxy (possibly the RD itself) for a sleepy server
Proposal ndash RD Based Sleep Tracking (24)
We define the following new RD attributes to characterize the properties of a sleepy node SleepState - Indicates whether the node is currently in
sleep mode or not (ie Sleeping or Awake) SleepDuration - Indicates the maximum duration of time
that the node stays in sleep mode TimeSleeping - Indicates the length of time the node
has been sleeping (ie if Sleep State = Sleeping) NextSleep - Indicates the next time the node will go to
sleep (ie if Sleep State = Awake)
CachingProxy ndash Indicates the caching proxy of the sleepy node (ie the RD itself or another node)
Proposal ndash RD Based Sleep Tracking (34)
These attributes are all server (node) level and are new parameters added to the RD URI Template Variables
Finally we also define a new lookup-type (ss) for the RD lookup interface specified in [I-Dshelby-core-resource-directory] This new lookup-type supports looking up the
ldquoSleepStaterdquo (ss) of a specified end-point
Proposal ndash RD Based Sleep Tracking (44)
The three time based parameters (SleepDuration TimeSleeping NextSleep) can be based on either an absolute network time (for a time synchronized network) or a relative local time (measured at the local node)
Following the approach of [I-Dietf-core-link-format] and [I-Dshelby-core-resource-directory] sleep parameters for sleepy servers can be stored by the server in the RD and accessed by all interested clients
Examples of using these parameters in a synchronous or asynchronous manner are shown in the I-D
http6lowappnet coreIETF86 2013-03-12-13
We assume people have read the drafts
Meetings serve to advance difficult issues by making good use of face-to-face communications
Note Well Be aware of the IPR principles according to RFC 3979 and its updates
uumlBlue sheetsuumlScribe(s)
96
drar-shy‐iep-shy‐core-shy‐coapsubmiqed13 to13 IESG
2013-shy‐03-shy‐13
97
OMA Lightweight M2M Overview(A new standard using lots of IETF specs including DTLS
CoAP Block Observe Resource Directory SenMLhellip)
Zach ShelbyCoRE WG IETF-86 Orlando
OMA Lightweight M2Mbull Open Mobile Alliance is well known for Device Management (DM)bull OMA Lightweight M2M is a new standard from the alliance
ndash Focused on constrained Cellular and sensor network M2M devicesndash Driven by leading operators and vendors
bull Scopendash Interfaces protocol amp security between Device and Serverndash Object and Resource modelndash Bootstrap Device Access Control Connectivity and Firmware Objects
bull Draft Specifications are availablendash httpmemberopenmobileallianceorgftpPublic_documentsDM
LightweightM2MPermanent_documentsOMA-TS-LightweightM2M-V1_0_0-20130301-Dzip
bull Timelinendash Requirements and Architecture completed 3Q2012ndash Spec ready for Consistency Review 2Q2013ndash Candidate Approval expected 3Q2013
2 CoRE WG IETF-86 Orlando
Architecture
3
Scope of LWM2M
CoRE WG IETF-86 Orlando
Object Model
bull A Client has one or more Object Instancesbull An Object is a collection of Resourcesbull A Resource is an atomic piece of information
ndash Read Written or Executed
bull Resources can have multiple instancesbull Objects and Resources are identified by a
16-bit Integer Instances by an 8-bit Integerbull ObjectsResources are accessed with
simple URIs Object IDObject InstanceResource ID
eg 1213
4 CoRE WG IETF-86 Orlando
CoRE WG IETF-86 Orlando
CoRE Resource Directory
draft-shelby-core-resource-directory-05
Z Shelby C Bormann S Krco
Backgroundbull Not a new concept
ndash think web search engine or any link directorybull Defines the interfaces to a Resource Directorybull Based on Web Linking framework and the CoRE Link Formatbull Generic REST design for use over HTTP and CoAPbull Used by OMA Lightweight M2Mbull Has already been deployed
ndash In traffic monitoring systemsndash In street lighting systemsndash For vehicular asset trackingndash By a major Cellular M2M operator
Changes since -04
bull Restricted Update to parameter updatesbull Added pagination support for the Lookup interfacebull Changed rt= to et= for the registration amp update
interfacebull Added group support
Group Management
bull RD now includes group management featuresbull New Group Function Set
ndash Register a groupbull Group name domain multicast address endpoint members
ndash Remove a groupbull Group lookup using the Lookup Function Set
ndash List registered groupsndash Find the members of a groupndash Find groups with certain endpoints or resources
Registering a Group
EP RD
| |
| - POST rd-groupgp=lights ltgtep=node1 --gt |
| |
| |
| lt---- 201 Created Location rd-group12 ---- |
| |
Req POST coaprdexamplecomrd-groupgp=lights
Payload
ltgtep=node1
ltgtep=node2
Res 201 Created
Location rd-group12
Looking up Group Members
Client RD
| |
| ----- GET rd-lookupepgp=lights1 ----------------------gt |
| |
| |
| lt-- 205 Content ltrdgtd=domain1ltrdgtd=domain2 --------- |
| |
Req GET rd-lookupepgp=lights1
Res 205 Content
ltcoaphostportgtep=node1
ltcoaphostportgtep=node2rdquo
Things for the futurebull Support for JSON representation of Web Links
ndash httptoolsietforgiddraft-bormann-core-links-json-02txtbull Registry for RD registration query parameters
ndash Already OMA Lightweight has defined some new onesbull More examples
Group 3 ldquonew workrdquo(continued)
109
drar-shy‐greevenbosch-shy‐core-shy‐profile-shy‐descripon-shy‐01Bert13 GreevenboschJeroen13 Hoebeke
Isam13 IshaqFloris13 Van13 den13 Abeele
Descripon
bull JSON13 format13 for13 signalling13 the13 servers13 capabilies
bull Signalling13 of13 supported13 opons13 media13 types13 and13 block13 sizendash Other13 items13 can13 be13 added
bull Filtering13 on13 specific13 fields13 through13 URI-shy‐Querybull Link13 hqpdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐profile-shy‐descripon
well-shy‐knownprofile
bull To13 acquire13 profile13 data13 of13 resources13 on13 a13 parcular13 service13 the13 well-shy‐knownprofile13 URI-shy‐path13 is13 introduced
bull For13 example13 to13 get13 all13 informaon13 from13 sensors13 served13 by13 wwwexampleorg13 we13 can13 do13 a13 GET13 to13 coapwwwexampleorgwell-shy‐knownprofile
bull Filtering13 on13 parcular13 resources13 is13 done13 through13 URI-shy‐Queries
Format
bull Currently13 the13 following13 fields13 are13 definedndash ldquopathrdquo13 contains13 the13 URI-shy‐path13 associated13 with13 a13 resource
ndash ldquooprdquo13 a13 numerical13 list13 of13 supported13 opon13 numbers
ndash ldquocfrdquo13 a13 numerical13 list13 of13 supported13 content-shy‐format13 numbers
ndash ldquob1srdquo13 ldquob2srdquo13 supported13 block13 sizes13 for13 Block113 and13 Block213 respecvely
Examplebull On13 the13 right13 is13 an13 example13 of13 a13 camera13 sensor13 at13 coapwwwexampleorgcam13 that13 supports13 the13 Uri-shy‐Host13 (3)13 ETag13 (4)13 Uri-shy‐Port13 (7)13 Uri-shy‐Path13 (11)13 Content-shy‐Format13 (12)13 Token13 (19)13 Block213 (23)13 and13 Proxy-shy‐Uri13 (35)13 opons
bull The13 supported13 content13 formats13 are13 textplain13 (0)13 applicaon13 link-shy‐format13 (40)13 and13 applicaonjson13 (50)
bull The13 supported13 Block213 can13 use13 25613 or13 51213 byte13 blocks
Req13 GET13 coapwwwexampleorgwell-shy‐knownprofile13 Res13 20513 Content13 (applicationjson)13 13 13 13 profile13 13 13 13 13 13 13 13 pathcam13 13 13 13 op[3471112192335]13 13 13 13 13 cf[04050]13 13 13 13 13 b2s[45]13 13 13 13
Filtering13 through13 use13 of13 URI-shy‐Query
bull Filtering13 can13 be13 done13 through13 the13 URI-shy‐Querybull Query13 format13 N=V
ndash N13 is13 a13 profile13 fieldndash V13 is13 the13 desired13 value
bull Examplesndash To13 find13 resources13 that13 support13 content13 format13 ldquoapplicaonjsonrdquo
13 GET13 wwwexampleorgwell-shy‐knownprofilecf=50ndash To13 get13 informaon13 about13 the13 camera
13 GET13 wwwexampleorgwell-shy‐knownprofilepath=cam
Open13 issues
bull Which13 other13 profile13 data13 needs13 signallingndash Content-shy‐type13 for13 different13 methods
bull Fix13 the13 order13 in13 which13 the13 profile13 fields13 must13 appearndash Non-shy‐fixed13 order13 easier13 extensible
bull Inheritance13 of13 a13 profile13 descriponbull Extend13 usage13 to13 signal13 the13 client13 profilebull Integraon13 with13 link13 format
Thank13 youQuesons
drar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval-shy‐00
Bert13 Greevenbosch
Descripon
bull The13 ldquoMinimumRequestInterval13 opon13 can13 be13 used13 to13 indicate13 the13 minimum13 me13 between13 two13 requests13 in13 a13 transacon
bull Originally13 intended13 for13 Block13 but13 also13 usable13 for13 other13 transaconsndash Example13 browsing13 a13 server
bull The13 goal13 is13 to13 reduce13 the13 server13 load13 and13 network13 traffic
bull Link13 hqpsdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval
Usage
bull The13 client13 keeps13 the13 server13 informed13 about13 its13 request13 speed13 through13 inclusion13 of13 the13 ldquoMinimumRequestIntervalrdquo13 opon
bull In13 responses13 the13 server13 fixes13 the13 minimum13 request13 interval13 through13 the13 same13 opon
bull The13 client13 obeys13 the13 speed13 indicated13 by13 the13 server
bull The13 client13 can13 send13 slower13 but13 not13 faster
Advantages
bull The13 server13 has13 means13 to13 limit13 the13 amount13 of13 incoming13 traffic
bull The13 server13 can13 prevent13 to13 become13 overloaded13 with13 too13 many13 tasks
bull The13 server13 does13 not13 need13 arficially13 slow13 down13 the13 client13 by13 sending13 late13 ACKsndash No13 need13 to13 keep13 track13 of13 delayed13 ACKsndash The13 server13 can13 perform13 other13 tasks13 instead
bull Reduced13 network13 traffic
Thank13 youQuesons
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-links-json-02txt
123
RFC 6690 (link-format) documents are somewhat foreign to many web app developerssect would prefer to have them in JSON format
There is no standard way to represent link-format documents in applicationssect but everyone knows how to handle JSON
Define a standard JSON translation for link-format
Itrsquos
not
rock
et
scien
ce
ltsensorsgtct=40title=Sensor Index ltsensorstempgtrt=temperature-cif=sensor ltsensorslightgtrt=light-luxif=sensor lthttpwwwexamplecomsensorst123gt anchor=sensorstemprel=describedby lttgtanchor=sensorstemprel=alternate [hrefsensorsct40titleSensor Index hrefsensorstemprttemperature-cifsensor hrefsensorslightrtlight-luxifsensor hrefhttpwwwexamplecomsensorst123 anchorsensorstempreldescribedby hreftanchorsensorstemprelalternate]
124
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-ipsec-for-coap-00txt
IPsec definitions for CoAP Mostly placeholder at this time Who has implementation experience with this
125
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-cross-reverse-convention-00txt
This draft has two lines of payload(based on a WGLC comment by Cullen Jennings)
coap12344567foobara=3
httpwwwproxycomwellknowncore-translate1234_4567foobara=3
Is that a useful convention to have
126
Insert CI slides here
127
128
0
5
10
15
20
25
30
35
40
10 20 30 40 50 60 70
good
put (
pps)
pps
Goodput vs pps (Econotags)
goodput
[Khattak preliminary]
Congestion Control
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-cocoa-00txt
ldquoadvancedrdquo cc (The draft is just a first shot) Others may have better ideas
129
Insert post-WGLC discussion slides here
130
Stop Continue Start
131
An Agile Retrospective
http6lowappnet coreIETF86 2013-03-12-13
Stop
132
Endless new CoAP optionssect instead use RESTful as much as possible
Move general security lifecycle out Looking at theoretical problems
http6lowappnet coreIETF86 2013-03-12-13
Continue
Interops Running code Look at real-world examples and deployments Solve their actual problems
sect Unilateral enhancements eg higher performance congestion control
sect Transports (SMS hellip)sect Make Web linking and Directories more and more usefulsect RESTful Design Paradigms for real-world problems
133
http6lowappnet coreIETF86 2013-03-12-13
Start
Further push into the (browser) web world (HTML5 browser security)
Specific supporting worksect SenMLsect URI work (dev URN hellip)sect Security Processes (next slide)
Spin outsect (We donrsquot really get to decide where this is done)
134
http6lowappnet coreIETF86 2013-03-12-13
Security
Integrate Application Network Group Keyingsect Tunnel-free setup
Donrsquot redo what has been done alreadysect ZigBee IP is finesect But what about other scenarios
Simple REST interfaces for working with keying materials and authorizationsect Start with defining objectives
Object Security for Constrained Nodes135
Re-chartering CoREWhat do we want to do now that wersquore grown up
Zach ShelbyCoRE WG IETF-86 Orlando
What is the scope
bull So we have a protocol and Web Linking what next
bull Keep with what we know besthellip1 Enhancements around CoAP2 New transports for CoAP3 New representations for Web Links4 General application layer solutions
CoRE WG IETF-86 Orlando 2
Enhancements around CoAP
bull Advanced congestion control
CoRE WG IETF-86 Orlando 3
New Transports for CoAP
bull Infrastructure for CoAP over foondash httptoolsietforgiddraft-silverajan-core-
coap-alternative-transports-01txtbull CoAP over SMS
ndash httptoolsietforgiddraft-becker-core-coap-sms-gprs-03txt
ndash OMA Lightweightbull CoAP over TCP
ndash httptoolsietforgiddraft-li-core-coap-payload-length-option-01txt
CoRE WG IETF-86 Orlando 4
New support for Web Links
bull JSON Web Linksndash httptoolsietforgiddraft-bormann-core-links-
json-02txt
2332010 CoRE WG IETF-77 Anaheim 5
General application layer solutions
bull Resource Directoryndash httptoolsietforgiddraft-shelby-core-
resource-directory-05txtndash OMA Lightweight
2332010 CoRE WG IETF-77 Anaheim 6
Group 2a other old friends
25
Angelo Castellani Salvatore Loreto Akbar Rahman Thomas Fossati Esko Dijk
IETF 86 March 2013httpwwwietforgiddraft-castellani-core-http-mapping-07txt
Best Practices for HTTP-CoAP Mapping
Implementation
Summary of Changes (from -06 rev)
n Based on discussion at last IETF-85 (Atlanta)n Clarification of HTTP-CoAP Proxies
n Definitionn Placementn Benefits
n Clarification of HTTP-CoAP URI mapping options
Goals of I-D
n For Reverse HTTP-CoAP Cross Protocol Proxyn Provide more detailed information to proxy designers (beyond
Section 10 of [I-Dietf-core-coap]) to help implement proxies that correctly inter-work with other CoAP and HTTP clientserver implementations that adhere to the specifications
n Define a consistent set of guidelines that a HTTP-to-CoAP proxy implementation MAY adhere to The main reason of adhering to such guidelines is to reduce variation between proxy implementations thereby increasing interoperabilityn As an example use case a proxy conforming to these guidelines made
by vendor A can be easily replaced by a proxy from vendor B that also conforms to the guidelines
I-D Outline
n Guidance on HTTP to CoAP URI mappingn HTTP-CoAP Reverse cross-protocol proxy implementation
n Placementn Response code amp media type translationsn Caching and congestion controln Cache refresh via Observen Use of CoAP blockwise transfern Security translation
n Security Considerationsn Traffic overflown Handling secured exchanges
Definitions (12)
n Cross-Protocol Proxy (or Cross Proxy) is a proxy performing a cross- protocol mapping in the context of this document a HTTP-CoAP (HC) mapping A Cross-Protocol Proxy can behave as a Forward Proxy Reverse Proxy or Interception Proxy n Note In this document we focus on the Reverse Proxy mode of the
Cross-Protocol Proxy
n Forward Proxy a message forwarding agent that is selected by the client usually via local configuration rules to receive requests for some type(s) of absolute URI and to attempt to satisfy those requests via translation to the protocol indicated by the absolute URI The user decides (is willing to) use the proxy as the forwardingdereferencing agent for a predefined subset of the URI space
Definitions (22)
n Reverse Proxy a receiving agent that acts as a layer above some other server(s) and translates the received requests to the underlying servers protocol It behaves as an origin (HTTP) server on its connection towards the (HTTP) client and as a (CoAP) client on its connection towards the (CoAP) origin server The (HTTP) client uses the origin-form [I-Dietf-httpbis-p1-messaging] as a request- target URI
n Reverse and Forward proxies are technically very similar with main differences being that the former appears to a client as an origin server while the latter does not and that clients may be unaware they are communicating with a proxy
Reverse Cross-Protocol Proxy Deployment Scenario
HTTP-CoAP Response Code Mapping
Implementation Experience
n Direct experience from the draft authorsn Squid HTTP-CoAP mapping module
n University of Padovan httptelecomdeiunipditiotn Both Forward and Interception operation supported
n HTTP-CoAP proxy based on EvCoAPn KoanLogic University of Bologna and Salvatore
Loreto (as individual)n httpsgithubcomkoanlogicwebthingstreemasterbridgesw
libevcoapn The document is open to input from other implementations
Next Steps
n Does the WG recommend adoptionn Intended status Informational Best Practicen Purpose Reduce arbitrary variation between proxy
implementations thereby increasing interoperability
Backup
HTTP to CoAP URI Mapping Options (12)
n Embedded Mapping n In an embedded mapping approach the HTTP URI has embedded
inside it the authority and path part of the CoAP URI n Example The CoAP resource nodecoapsomethingnetfoo can
be accessed by an HTTP client by inserting in the request httphc-proxysomethingnetcoapnodecoapsomethingnetfoo The Cross-Protocol Proxy then maps the URI to coapnodecoapsomethingnetfoo
HTTP to CoAP URI Mapping Options (22)
n Homogeneous Mapping n In a homogeneous mapping approach only the scheme portion of the URI
needs to be mapped The rest of the URI (ie authority path etc) remains unchanged
n Example The CoAP resource coapnodecoapsomethingnetfoo can be accessed by an HTTP client by requesting httpnodecoapsomethingnetfoo The Cross-Protocol Proxy receiving the request is responsible to map the URI to coapnodecoapsomethingnetfoo
n Background info n The assumption in this case is that the HTTP client would be able to
successfully resolve nodecoapsomethingnet using DNS infrastructure to return the IP address of the HC proxy Most likely this would be through a two step DNS lookup where the first DNS lookup would resolve somethingnet using public DNS infrastructure
n Then the second DNS lookup on the subdomain coap and the host node would typically be resolved by a DNS server operated by the owner of domain somethingnet So this domain owner can manage its own internal node names and subdomain allocation which would correspond to the CoAP namespace
Group 3 ldquonew workrdquo
39
Transport of CoAP over SMS USSD and GPRSdraft-becker-core-coap-sms-gprs-03
Markus Becker Kepeng LiKoojana Kuladinithi Thomas Poumltsch
CoRE WG IETF-86 Orlando
1 10
ScenariosI In M2M communication IP connectivity is not alwayssupported by the constrained end-points
I Power savingI Coverage (GPRS 3G LTE)
I SMS and USSD based communication is almost alwayssupported
210
Changes from draft-01 to draft-03 (1)
I Added possible CONNONACK interactions Section 5
I Option name changed from Reply-To- to Response-To-Section 16 and Section 101
I Added URI schemeEg coap+tel+15105550101well-knowncore Section 11
I Added possible M2M proxy scenarios Section 14
3 10
Changes from draft-01 to draft-03 (2)
I Added reference to bormann-coap-misc for other SMSencoding Section 71
I Updated requirements on Uri-Host and Uri-Port forcoap+tel Section 10
I Added security considerations Transport and ObjectSecurity Section 15
I Chose CoAP option numbers and updated the optionnumber table to meet draft-ietf-core-coap-10 Table 1
I Added an IANA registration for the URI scheme coap+telSection 162
4 10
Feedback Split coap+tel into coap+smsand coap+ussd
I How else to differ the various transports in the URII Or is the transport to use decided by the implementationI See alsodraft-silverajan-core-coap-alternative-transports-01
5 10
Feedback Response-To-Scheme option
I Should there be a Response-To-Scheme optionadditionally to Response-To-Uri-Host andResponse-To-Uri-Path
I So that a CoAP end-point which receives a request by CoAPover non-IP transport can be instructed to also use thenon-IP transport for the response
I This would imply to add aResponse-To-Telephone-Subscriber and more options forother transports that have other URI schemes than coapand coaps
6 10
Feedback Selection of Transport by Client
I When a server is reachable by various transports howdoes a client decide which transport to use
I Client-side application congurationI Leave it to a proxy which uses cellular network lookupfunctions
7 10
Feedback Potential Threats
I Trigger expensive short messagesI Redirect trac to other addressesI More threats
I Are the security measures in the draft adequateI Whitelisting on serverI Relying on cellular network security (dedicated M2M APNs)I Object security on CoAP payload
8 10
Feedback Message Exchanges
I Figures 11-18 show possible message exchanges whenclient and server have two addresses
I With NON Not using CoAP retransmission capabilityI ACK on different transportI Additional (costly) message on Transport AI Request with Content
I Which ones are allowedI Which ones are meaningful
9 10
Next steps
I Rene Uri schemeI Response-To-Scheme optionI Selection of Message ExchangeI Rene Proxying
10 10
CoAP13 Communicaon13 with13 Alternave13 Transports
Bill Silverajan and Teemu SavolainenCore WG IETF 86 Orlando
031113
Objecves13 (In13 Scope)
bull Unambiguous13 representaon13 of13 transport13 to13 be13 used13 by13 CoAP
bull Details13 how13 the13 transport13 can13 carry13 CoAP13 packet
bull Focus13 is13 on13 what13 CoAP13 communicaons13 requirements13 are
bull Allow13 CoAP13 mechanisms13 to13 exploit13 cross-shy‐layer13 opmisaons
51
031113
Non13 Goals13 (Not13 in13 scope)
bull Applicaon-shy‐level13 QoS13 requirementsbull Real-shy‐me13 constraintsbull Ordering13 reliability13 congeson13 controlbull Applicaon13 and13 network13 adaptaonbull Mobility13 and13 readdressing13 supportbull Network13 protocol13 (eg13 IPsec)13 configuraon
52
031113
Use13 Cases
bull NAT13 and13 Firewall13 traversal13 with13 TCPbull Delay13 Tolerant13 Networkingbull Non-shy‐IP13 Low13 Energy13 Protocols
53
031113
Related13 Work
bull OMA13 Lightweight13 M2M13 Protocolbull CoAP13 over13 SMSGPRSUSSD
54
031113
What13 does13 the13 work13 entail
bull The13 ability13 to13 specify13 end13 point13 idenfiers13 and13 URIs13 to13 reflect13 which13 transport13 CoAP13 can13 use
bull The13 ability13 to13 register13 to13 resource13 directories13 resource13 types13 reflecng13 types13 of13 transport13 available
bull Ability13 for13 mul-shy‐transport13 nodes13 to13 select13 transport13 to13 use13 without13 significant13 alteraon13 to13 CoAP13 packet13 structure
55
031113
Points13 to13 consider
bull Requirements13 for13 transport13 layer13 protocol13 to13 carry13 CoAP13 packets
bull Representaon13 of13 URI13 scheme13 for13 generic13 transport13 protocols
bull Opon13 extensions13 for13 CoAP13 to13 express13 available13 transports
bull Mapping13 and13 message13 sizebull Security13 consideraons
56
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
URI13 =13 scheme13 13 13 authority13 path-shy‐abempty13 [13 query13 ]
bull Within13 the13 scheme13 namebull In13 the13 URI13 pathbull As13 a13 query13 component
57
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
bull Within13 the13 scheme13 namendash coap+tel+15105550101well-shy‐knowncorendash coap+tcpexamplecom5683temperaturendash coap+blel2cap[1234567890AB]4pulse
bull Easy13 URI13 parsing13 for13 transport13 type13 and13 idenfier
bull Each13 new13 scheme13 name13 requires13 IANA13 registraon
58
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
bull In13 the13 URI13 pathndash coaphostexamplecomtransport=tcpwell-shy‐knowncorert=core-shy‐rd
bull Easy13 adopon13 of13 new13 (and13 experimental)13 CoAP13 transports13 without13 IANA13 registraon
bull Caveat13 Uri-shy‐Path13 opon13 is13 a13 Crical13 CoAP13 opon13 see13 secon13 54113 of13 I-shy‐Diep-shy‐core-shy‐coap
59
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
bull As13 a13 URI13 query13 componentndash coaphostexamplecomwell-shy‐knowncorert=core-shy‐rdq=tcp
bull Also13 easy13 to13 adopt13 new13 (and13 experimental)13 CoAP13 transports13 without13 IANA13 registraon
bull Caveat13 Uri-shy‐Query13 opon13 is13 a13 Crical13 CoAP13 opon13 see13 secon13 54113 of13 I-shy‐Diep-shy‐core-shy‐coap
60
031113
URI13 Representaons13 for13 CoAPNon13 standard13 ways
bull Transport13 in13 the13 URI13 authority13 componentndash coaphost[port][transport]13 instead13 of13 coaphost[port]
bull Transport13 as13 a13 service13 URLndash servicecoaptcphostexamplecomwell-shy‐knowncorert=core-shy‐rd
bull Above13 two13 ways13 break13 exisng13 compability13 (although13 both13 are13 based13 on13 valid13 IANA13 URI13 registraons)
61
031113
URI13 Representaons13 for13 CoAPMiscellaneous13 Consideraons
bull Ensure13 that13 transport13 is13 defined13 unambiguously13 (eg13 L2CAP13 used13 by13 both13 BLE13 and13 standard13 Bluetooth13 so13 avoid13 rdquocoap+l2caprdquo13 or13 rdquotransport=l2caprdquo13 or13 rdquoq=l2caprdquondash Can13 be13 done13 as13 WG13 consensusndash Namespace13 approach13 eg13 rdquocoap+blel2caprdquo13 or13 rdquoq=blel2caprdquo
bull Allow13 end-shy‐points13 to13 use13 CoAP13 Resource13 Directory13 to13 register13 alternave13 transports13 and13 idenfiers13 and13 provide13 periodic13 updatesndash Register13 rdquocore-shy‐transportrdquo13 resource13 type
62
031113
Transport13 Consideraons
bull Uniqueness13 of13 end-shy‐point13 idenficaonbull Communicaon13 support13 Unidireconal13 Bidireconal13 1N13 (broadcast13 mulcast13 anycast)13 messaging
bull Binary13 encoding13 Network13 byte13 orderingbull MTU13 correlaon13 with13 CoAP13 PDU13 sizebull Transport13 latency
63
031113
Security13 Consideraons
bull Drar13 does13 not13 introduce13 new13 security13 requirements13 by13 itself
bull There13 may13 be13 privacy13 issues13 if13 nodes13 use13 telephone13 numbers13 or13 MAC13 addresses13 as13 public13 end13 point13 idenfiers
64
Akbar Rahman
IETF 86 March 2013 httpwwwietforgiddraft-rahman-core-sleepy-02txt
Enhanced Sleepy Node Support for CoAP
Introduction
It is expected that in CoAP networks there will be a certain portion of devices that are sleepy and which may occasionally go into a sleep mode (ie go into a low power state to conserve power) and subsequently have reduced CoAP protocol communication ability
This I-D proposes a minimal and efficient mechanism building on the Resource Directory concept (which will be integrated into a CoAP Proxy) to enhance sleepy node support in CoAP networks
Main Question from IETF-85 (Atlanta)
What performance benefit does the proposed Sleepy Node support solution give in a network that already has standard CoAP caching enabled
Sleepy Node Performance Analysis
Experimental Network
1-5 clients
Both Sleepy and Non-
Sleepy servers
Sleepy Node Performance Analysis Network Setup
CoAPSleepyServer(s)
CoAPSleepAwareReverseProxy
CoAP
Client(s)
Request
Response
Sleep9AwareCoREResourceDirectoryCapability
PublishedSleepParameters
Sleep9AwareCoAPStoreandForwardCapability Response
Request
SleepAwareCoAP503ResponseCapability
CoAPCachingCapability
bull Server supports publishing sleep parameters to proxy bull Eg Irsquom going to be asleep for X seconds
bull Proxy supports sleep-awareness capabilities bull Proxy also supports caching capability based off of maxAge bull Protocol flow similar to approach of Figure 1 (Synchronous RD Based Sleep
Tracking) of I-D
Proxy capabilities can be selectively enableddisabled
Proxy ndash Server Interface
Client ndash Proxy Interface
CoAP Sleep-Aware Reverse Proxy Features CoRE Sleep-aware Resource Directory
Support storing published sleep parameters from CoAP servers sleepState (AWAKE ASLEEP) sleepDuration
Sleep-aware CoAP 503 Response Capability If CoAP request to a sleeping server is received proxy returns a
lsquo503 Retry-Afterrsquo response to client 503 contains a timestamp indicating when the sever will wake back up
(timestamp delivered in CoAP maxAge option) Sleep-aware CoAP Store-and-Forward Capability
If CoAP request to a sleeping server is received proxy stores request until server wakes up and then forwards it
Caching capability Cache GET responses from server if maxAge option is present
(this is not a sleep aware feature)
Goals of Performance Analysis
For networks having sleepy servers provide measurements to quantify the impact that CoAP sleep-awareness capabilities can have
See if sleep-awareness capabilities can
provide additional benefits even when CoAP caching is used
Overview of Performance Analysis Performed The analysis was broken up into a set of test scenarios Each test scenario used a different combination of the following
variables Client issued GET requests Server was configured as a sleepy or non-sleepy server Proxy caching of GET responses was enabled or disabled Proxy sleep-aware 503 response capability was enabled or disabled Proxy store-and-forward capability was enabled or disabled maxAge in GET responses ndash Two values were tested 60sec and 5sec of Clients ndash Two values were used ndash 1 client and 5 clients
For comparison purposes the following were held constant across all test scenarios Client issued a fixed number of requests (100) across all test scenarios Client used a delay between each GET request (35sec) to better exercise
proxyrsquos caching and sleep-awareness capabilities For sleepy server test scenarios the server slept 60 sec awake for 3 sec
Format of Results The following results were collected for each
test scenario
Breakdown of the and types of transactions occurring between clientproxyserver
ldquoGETrdquo ndash Test Scenario Results
GET ndash Description of Test Scenarios
TestScenarios-GET
Scenario
CoAPSleepyServerSe7ngs CoAPSleepAwareReverseProxySe7ngs CoAPClientSe7ngs
SleepDuragton(sec)
AwakeDuragton(sec)
maxAge(sec) Caching SleepAwareSAF+
503NumberofClients
NumberofGETs
DelayBetweenClient
Requests(sec)
1a 0 Always 60 Enabled Disabled 1 100 35
1b 60 3 60 Enabled Disabled 1 100 35
1c 60 3 60 Enabled Enabled 1 100 35
2a 0 Always 60 Enabled Disabled 5 100 35
2b 60 3 60 Enabled Disabled 5 100 35
2c 60 3 60 Enabled Enabled 5 100 35
3a 0 Always 5 Enabled Disabled 5 100 35
3b 60 3 5 Enabled Disabled 5 100 35
3c 60 3 5 Enabled Enabled 5 100 35
ldquoGETrdquo ndash Test Scenario 1 Results
maxAge = 60 and 1 Client
GET ndash Scenario 1 ClientProxy Interface Transaction Mix
Scenarios 1a - Non-Sleepy Server Caching Proxy maxAge = 60sec 1b- Sleepy Server Caching Proxy maxAge = 60sec 1c - Sleepy Server Sleep Aware Proxy maxAge = 60sec
Sleep Aware Proxy has better performance for sleepy servers
0
100
200
300
400
500
600
700
1a 1b 1c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
GET ndash Scenario 1 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
Scenarios 1a - Non-Sleepy Server Caching Proxy maxAge = 60sec 1b- Sleepy Server Caching Proxy maxAge = 60sec 1c - Sleepy Server Sleep Aware Proxy maxAge = 60sec
0
100
200
300
400
500
600
700
800
1a 1b 1c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
ldquoGETrdquo ndash Test Scenario 2 Results
maxAge = 60 and 5 Clients
GET ndash Scenario 2 ClientProxy Interface Transaction Mix
Sleep Aware Proxy has slightly better performance for sleepy servers
0
200
400
600
800
1000
1200
1400
2a 2b 2c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
Scenarios 2a - Non-Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2b- Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2c - Sleepy Server Sleep Aware Proxy maxAge = 60sec 5 Clients
See ldquoExperimental Artifactsrdquo Note 1
GET ndash Scenario 2 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has slightly better performance for sleepy servers
0
50
100
150
200
250
300
350
400
2a 2b 2c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
Scenarios 2a - Non-Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2b- Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2c - Sleepy Server Sleep Aware Proxy maxAge = 60sec 5 Clients
See ldquoExperimental Artifactsrdquo Note 2
Experimental Artifacts Note 1
Currently in the experiment the sleep aware proxy checks the cached state of a resource before putting a request into its Store-and-forward queue while a server is sleeping Once in the queue the proxy unconditionally forwards the queued requests to the server once it wakes up This is not the most efficient setup and can easily be improved If the proxy instead checks its cache again before forwarding each queued request it may not need to forward the request to the server For example if there are two queued GET requests in the proxyrsquos queue that address the same resource Only the first request needs to be sent to the server the second request can use the cached response from the first request
Note 2 Currently in the experiment the sleepy server sends a sleepState PUT request to the
proxy each time it goes to sleep This is not the most efficient setup and can easily be improved For example if the server assumes that the proxy can keep track of its ONOFF cycles with its internal timers (eg as per Fig 1 of I-D) then the number of messages from the sleepy server dramatically goes down
ldquoGETrdquo ndash Test Scenario 3 Results
maxAge = 5 and 5 Clients
GET ndash Scenario 3 ClientProxy Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
Scenarios 3a - Non-Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3b- Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3c - Sleepy Server Sleep Aware Proxy maxAge = 5sec 5 Clients
0
500
1000
1500
2000
2500
3000
3500
4000
4500
5000
3a 3b 3c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
GET ndash Scenario 3 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
0
1000
2000
3000
4000
5000
6000
7000
3a 3b 3c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
Scenarios 3a - Non-Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3b- Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3c - Sleepy Server Sleep Aware Proxy maxAge = 5sec 5 Clients
Conclusions
Conclusions These results show that sleep-aware CoAP
proxy features can significantly optimize communication with sleepy servers in most scenarios
These results also show that sleep-
awareness capabilities can provide additional benefits above and beyond CoAP caching in most scenarios
Backup
Current CoAP Support of Sleepy Node (12)
CoAP proxies can use a previously cached response to service a new GET request for a sleepy origin server (as in HTTP) But if no valid cache then proxy has to attempt to
retrieve and may fail if origin server is sleeping [I-Dietf-core-coap]
Clients can discover list of resources from RD (GET rd-lookuphellip) for sleepy servers But attempt to GET resource from sleepy origin server
may fail if origin server is sleeping [IDietf-core-link-format amp IDshelby-core-resource-
directory]
Current CoAP Support of Sleepy Node (22)
Lower layer support for sleepy nodes in most wireless technologies (eg WiFi ZigBee) But limited to MAC packet scheduling for sleepy nodes
and not aware of specific needs of IP applications (like CoAP)
Proposal ndash RD Based Sleep Tracking (14)
The current CoAP approach to support sleepy nodes can be significantly improved by introducing RD based mechanisms for a CoAP client to determine whether A targeted resource is located on a sleepy server A sleepy server is currently in sleep mode or not
There is any associated caching Proxy (possibly the RD itself) for a sleepy server
Proposal ndash RD Based Sleep Tracking (24)
We define the following new RD attributes to characterize the properties of a sleepy node SleepState - Indicates whether the node is currently in
sleep mode or not (ie Sleeping or Awake) SleepDuration - Indicates the maximum duration of time
that the node stays in sleep mode TimeSleeping - Indicates the length of time the node
has been sleeping (ie if Sleep State = Sleeping) NextSleep - Indicates the next time the node will go to
sleep (ie if Sleep State = Awake)
CachingProxy ndash Indicates the caching proxy of the sleepy node (ie the RD itself or another node)
Proposal ndash RD Based Sleep Tracking (34)
These attributes are all server (node) level and are new parameters added to the RD URI Template Variables
Finally we also define a new lookup-type (ss) for the RD lookup interface specified in [I-Dshelby-core-resource-directory] This new lookup-type supports looking up the
ldquoSleepStaterdquo (ss) of a specified end-point
Proposal ndash RD Based Sleep Tracking (44)
The three time based parameters (SleepDuration TimeSleeping NextSleep) can be based on either an absolute network time (for a time synchronized network) or a relative local time (measured at the local node)
Following the approach of [I-Dietf-core-link-format] and [I-Dshelby-core-resource-directory] sleep parameters for sleepy servers can be stored by the server in the RD and accessed by all interested clients
Examples of using these parameters in a synchronous or asynchronous manner are shown in the I-D
http6lowappnet coreIETF86 2013-03-12-13
We assume people have read the drafts
Meetings serve to advance difficult issues by making good use of face-to-face communications
Note Well Be aware of the IPR principles according to RFC 3979 and its updates
uumlBlue sheetsuumlScribe(s)
96
drar-shy‐iep-shy‐core-shy‐coapsubmiqed13 to13 IESG
2013-shy‐03-shy‐13
97
OMA Lightweight M2M Overview(A new standard using lots of IETF specs including DTLS
CoAP Block Observe Resource Directory SenMLhellip)
Zach ShelbyCoRE WG IETF-86 Orlando
OMA Lightweight M2Mbull Open Mobile Alliance is well known for Device Management (DM)bull OMA Lightweight M2M is a new standard from the alliance
ndash Focused on constrained Cellular and sensor network M2M devicesndash Driven by leading operators and vendors
bull Scopendash Interfaces protocol amp security between Device and Serverndash Object and Resource modelndash Bootstrap Device Access Control Connectivity and Firmware Objects
bull Draft Specifications are availablendash httpmemberopenmobileallianceorgftpPublic_documentsDM
LightweightM2MPermanent_documentsOMA-TS-LightweightM2M-V1_0_0-20130301-Dzip
bull Timelinendash Requirements and Architecture completed 3Q2012ndash Spec ready for Consistency Review 2Q2013ndash Candidate Approval expected 3Q2013
2 CoRE WG IETF-86 Orlando
Architecture
3
Scope of LWM2M
CoRE WG IETF-86 Orlando
Object Model
bull A Client has one or more Object Instancesbull An Object is a collection of Resourcesbull A Resource is an atomic piece of information
ndash Read Written or Executed
bull Resources can have multiple instancesbull Objects and Resources are identified by a
16-bit Integer Instances by an 8-bit Integerbull ObjectsResources are accessed with
simple URIs Object IDObject InstanceResource ID
eg 1213
4 CoRE WG IETF-86 Orlando
CoRE WG IETF-86 Orlando
CoRE Resource Directory
draft-shelby-core-resource-directory-05
Z Shelby C Bormann S Krco
Backgroundbull Not a new concept
ndash think web search engine or any link directorybull Defines the interfaces to a Resource Directorybull Based on Web Linking framework and the CoRE Link Formatbull Generic REST design for use over HTTP and CoAPbull Used by OMA Lightweight M2Mbull Has already been deployed
ndash In traffic monitoring systemsndash In street lighting systemsndash For vehicular asset trackingndash By a major Cellular M2M operator
Changes since -04
bull Restricted Update to parameter updatesbull Added pagination support for the Lookup interfacebull Changed rt= to et= for the registration amp update
interfacebull Added group support
Group Management
bull RD now includes group management featuresbull New Group Function Set
ndash Register a groupbull Group name domain multicast address endpoint members
ndash Remove a groupbull Group lookup using the Lookup Function Set
ndash List registered groupsndash Find the members of a groupndash Find groups with certain endpoints or resources
Registering a Group
EP RD
| |
| - POST rd-groupgp=lights ltgtep=node1 --gt |
| |
| |
| lt---- 201 Created Location rd-group12 ---- |
| |
Req POST coaprdexamplecomrd-groupgp=lights
Payload
ltgtep=node1
ltgtep=node2
Res 201 Created
Location rd-group12
Looking up Group Members
Client RD
| |
| ----- GET rd-lookupepgp=lights1 ----------------------gt |
| |
| |
| lt-- 205 Content ltrdgtd=domain1ltrdgtd=domain2 --------- |
| |
Req GET rd-lookupepgp=lights1
Res 205 Content
ltcoaphostportgtep=node1
ltcoaphostportgtep=node2rdquo
Things for the futurebull Support for JSON representation of Web Links
ndash httptoolsietforgiddraft-bormann-core-links-json-02txtbull Registry for RD registration query parameters
ndash Already OMA Lightweight has defined some new onesbull More examples
Group 3 ldquonew workrdquo(continued)
109
drar-shy‐greevenbosch-shy‐core-shy‐profile-shy‐descripon-shy‐01Bert13 GreevenboschJeroen13 Hoebeke
Isam13 IshaqFloris13 Van13 den13 Abeele
Descripon
bull JSON13 format13 for13 signalling13 the13 servers13 capabilies
bull Signalling13 of13 supported13 opons13 media13 types13 and13 block13 sizendash Other13 items13 can13 be13 added
bull Filtering13 on13 specific13 fields13 through13 URI-shy‐Querybull Link13 hqpdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐profile-shy‐descripon
well-shy‐knownprofile
bull To13 acquire13 profile13 data13 of13 resources13 on13 a13 parcular13 service13 the13 well-shy‐knownprofile13 URI-shy‐path13 is13 introduced
bull For13 example13 to13 get13 all13 informaon13 from13 sensors13 served13 by13 wwwexampleorg13 we13 can13 do13 a13 GET13 to13 coapwwwexampleorgwell-shy‐knownprofile
bull Filtering13 on13 parcular13 resources13 is13 done13 through13 URI-shy‐Queries
Format
bull Currently13 the13 following13 fields13 are13 definedndash ldquopathrdquo13 contains13 the13 URI-shy‐path13 associated13 with13 a13 resource
ndash ldquooprdquo13 a13 numerical13 list13 of13 supported13 opon13 numbers
ndash ldquocfrdquo13 a13 numerical13 list13 of13 supported13 content-shy‐format13 numbers
ndash ldquob1srdquo13 ldquob2srdquo13 supported13 block13 sizes13 for13 Block113 and13 Block213 respecvely
Examplebull On13 the13 right13 is13 an13 example13 of13 a13 camera13 sensor13 at13 coapwwwexampleorgcam13 that13 supports13 the13 Uri-shy‐Host13 (3)13 ETag13 (4)13 Uri-shy‐Port13 (7)13 Uri-shy‐Path13 (11)13 Content-shy‐Format13 (12)13 Token13 (19)13 Block213 (23)13 and13 Proxy-shy‐Uri13 (35)13 opons
bull The13 supported13 content13 formats13 are13 textplain13 (0)13 applicaon13 link-shy‐format13 (40)13 and13 applicaonjson13 (50)
bull The13 supported13 Block213 can13 use13 25613 or13 51213 byte13 blocks
Req13 GET13 coapwwwexampleorgwell-shy‐knownprofile13 Res13 20513 Content13 (applicationjson)13 13 13 13 profile13 13 13 13 13 13 13 13 pathcam13 13 13 13 op[3471112192335]13 13 13 13 13 cf[04050]13 13 13 13 13 b2s[45]13 13 13 13
Filtering13 through13 use13 of13 URI-shy‐Query
bull Filtering13 can13 be13 done13 through13 the13 URI-shy‐Querybull Query13 format13 N=V
ndash N13 is13 a13 profile13 fieldndash V13 is13 the13 desired13 value
bull Examplesndash To13 find13 resources13 that13 support13 content13 format13 ldquoapplicaonjsonrdquo
13 GET13 wwwexampleorgwell-shy‐knownprofilecf=50ndash To13 get13 informaon13 about13 the13 camera
13 GET13 wwwexampleorgwell-shy‐knownprofilepath=cam
Open13 issues
bull Which13 other13 profile13 data13 needs13 signallingndash Content-shy‐type13 for13 different13 methods
bull Fix13 the13 order13 in13 which13 the13 profile13 fields13 must13 appearndash Non-shy‐fixed13 order13 easier13 extensible
bull Inheritance13 of13 a13 profile13 descriponbull Extend13 usage13 to13 signal13 the13 client13 profilebull Integraon13 with13 link13 format
Thank13 youQuesons
drar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval-shy‐00
Bert13 Greevenbosch
Descripon
bull The13 ldquoMinimumRequestInterval13 opon13 can13 be13 used13 to13 indicate13 the13 minimum13 me13 between13 two13 requests13 in13 a13 transacon
bull Originally13 intended13 for13 Block13 but13 also13 usable13 for13 other13 transaconsndash Example13 browsing13 a13 server
bull The13 goal13 is13 to13 reduce13 the13 server13 load13 and13 network13 traffic
bull Link13 hqpsdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval
Usage
bull The13 client13 keeps13 the13 server13 informed13 about13 its13 request13 speed13 through13 inclusion13 of13 the13 ldquoMinimumRequestIntervalrdquo13 opon
bull In13 responses13 the13 server13 fixes13 the13 minimum13 request13 interval13 through13 the13 same13 opon
bull The13 client13 obeys13 the13 speed13 indicated13 by13 the13 server
bull The13 client13 can13 send13 slower13 but13 not13 faster
Advantages
bull The13 server13 has13 means13 to13 limit13 the13 amount13 of13 incoming13 traffic
bull The13 server13 can13 prevent13 to13 become13 overloaded13 with13 too13 many13 tasks
bull The13 server13 does13 not13 need13 arficially13 slow13 down13 the13 client13 by13 sending13 late13 ACKsndash No13 need13 to13 keep13 track13 of13 delayed13 ACKsndash The13 server13 can13 perform13 other13 tasks13 instead
bull Reduced13 network13 traffic
Thank13 youQuesons
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-links-json-02txt
123
RFC 6690 (link-format) documents are somewhat foreign to many web app developerssect would prefer to have them in JSON format
There is no standard way to represent link-format documents in applicationssect but everyone knows how to handle JSON
Define a standard JSON translation for link-format
Itrsquos
not
rock
et
scien
ce
ltsensorsgtct=40title=Sensor Index ltsensorstempgtrt=temperature-cif=sensor ltsensorslightgtrt=light-luxif=sensor lthttpwwwexamplecomsensorst123gt anchor=sensorstemprel=describedby lttgtanchor=sensorstemprel=alternate [hrefsensorsct40titleSensor Index hrefsensorstemprttemperature-cifsensor hrefsensorslightrtlight-luxifsensor hrefhttpwwwexamplecomsensorst123 anchorsensorstempreldescribedby hreftanchorsensorstemprelalternate]
124
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-ipsec-for-coap-00txt
IPsec definitions for CoAP Mostly placeholder at this time Who has implementation experience with this
125
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-cross-reverse-convention-00txt
This draft has two lines of payload(based on a WGLC comment by Cullen Jennings)
coap12344567foobara=3
httpwwwproxycomwellknowncore-translate1234_4567foobara=3
Is that a useful convention to have
126
Insert CI slides here
127
128
0
5
10
15
20
25
30
35
40
10 20 30 40 50 60 70
good
put (
pps)
pps
Goodput vs pps (Econotags)
goodput
[Khattak preliminary]
Congestion Control
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-cocoa-00txt
ldquoadvancedrdquo cc (The draft is just a first shot) Others may have better ideas
129
Insert post-WGLC discussion slides here
130
Stop Continue Start
131
An Agile Retrospective
http6lowappnet coreIETF86 2013-03-12-13
Stop
132
Endless new CoAP optionssect instead use RESTful as much as possible
Move general security lifecycle out Looking at theoretical problems
http6lowappnet coreIETF86 2013-03-12-13
Continue
Interops Running code Look at real-world examples and deployments Solve their actual problems
sect Unilateral enhancements eg higher performance congestion control
sect Transports (SMS hellip)sect Make Web linking and Directories more and more usefulsect RESTful Design Paradigms for real-world problems
133
http6lowappnet coreIETF86 2013-03-12-13
Start
Further push into the (browser) web world (HTML5 browser security)
Specific supporting worksect SenMLsect URI work (dev URN hellip)sect Security Processes (next slide)
Spin outsect (We donrsquot really get to decide where this is done)
134
http6lowappnet coreIETF86 2013-03-12-13
Security
Integrate Application Network Group Keyingsect Tunnel-free setup
Donrsquot redo what has been done alreadysect ZigBee IP is finesect But what about other scenarios
Simple REST interfaces for working with keying materials and authorizationsect Start with defining objectives
Object Security for Constrained Nodes135
Re-chartering CoREWhat do we want to do now that wersquore grown up
Zach ShelbyCoRE WG IETF-86 Orlando
What is the scope
bull So we have a protocol and Web Linking what next
bull Keep with what we know besthellip1 Enhancements around CoAP2 New transports for CoAP3 New representations for Web Links4 General application layer solutions
CoRE WG IETF-86 Orlando 2
Enhancements around CoAP
bull Advanced congestion control
CoRE WG IETF-86 Orlando 3
New Transports for CoAP
bull Infrastructure for CoAP over foondash httptoolsietforgiddraft-silverajan-core-
coap-alternative-transports-01txtbull CoAP over SMS
ndash httptoolsietforgiddraft-becker-core-coap-sms-gprs-03txt
ndash OMA Lightweightbull CoAP over TCP
ndash httptoolsietforgiddraft-li-core-coap-payload-length-option-01txt
CoRE WG IETF-86 Orlando 4
New support for Web Links
bull JSON Web Linksndash httptoolsietforgiddraft-bormann-core-links-
json-02txt
2332010 CoRE WG IETF-77 Anaheim 5
General application layer solutions
bull Resource Directoryndash httptoolsietforgiddraft-shelby-core-
resource-directory-05txtndash OMA Lightweight
2332010 CoRE WG IETF-77 Anaheim 6
Angelo Castellani Salvatore Loreto Akbar Rahman Thomas Fossati Esko Dijk
IETF 86 March 2013httpwwwietforgiddraft-castellani-core-http-mapping-07txt
Best Practices for HTTP-CoAP Mapping
Implementation
Summary of Changes (from -06 rev)
n Based on discussion at last IETF-85 (Atlanta)n Clarification of HTTP-CoAP Proxies
n Definitionn Placementn Benefits
n Clarification of HTTP-CoAP URI mapping options
Goals of I-D
n For Reverse HTTP-CoAP Cross Protocol Proxyn Provide more detailed information to proxy designers (beyond
Section 10 of [I-Dietf-core-coap]) to help implement proxies that correctly inter-work with other CoAP and HTTP clientserver implementations that adhere to the specifications
n Define a consistent set of guidelines that a HTTP-to-CoAP proxy implementation MAY adhere to The main reason of adhering to such guidelines is to reduce variation between proxy implementations thereby increasing interoperabilityn As an example use case a proxy conforming to these guidelines made
by vendor A can be easily replaced by a proxy from vendor B that also conforms to the guidelines
I-D Outline
n Guidance on HTTP to CoAP URI mappingn HTTP-CoAP Reverse cross-protocol proxy implementation
n Placementn Response code amp media type translationsn Caching and congestion controln Cache refresh via Observen Use of CoAP blockwise transfern Security translation
n Security Considerationsn Traffic overflown Handling secured exchanges
Definitions (12)
n Cross-Protocol Proxy (or Cross Proxy) is a proxy performing a cross- protocol mapping in the context of this document a HTTP-CoAP (HC) mapping A Cross-Protocol Proxy can behave as a Forward Proxy Reverse Proxy or Interception Proxy n Note In this document we focus on the Reverse Proxy mode of the
Cross-Protocol Proxy
n Forward Proxy a message forwarding agent that is selected by the client usually via local configuration rules to receive requests for some type(s) of absolute URI and to attempt to satisfy those requests via translation to the protocol indicated by the absolute URI The user decides (is willing to) use the proxy as the forwardingdereferencing agent for a predefined subset of the URI space
Definitions (22)
n Reverse Proxy a receiving agent that acts as a layer above some other server(s) and translates the received requests to the underlying servers protocol It behaves as an origin (HTTP) server on its connection towards the (HTTP) client and as a (CoAP) client on its connection towards the (CoAP) origin server The (HTTP) client uses the origin-form [I-Dietf-httpbis-p1-messaging] as a request- target URI
n Reverse and Forward proxies are technically very similar with main differences being that the former appears to a client as an origin server while the latter does not and that clients may be unaware they are communicating with a proxy
Reverse Cross-Protocol Proxy Deployment Scenario
HTTP-CoAP Response Code Mapping
Implementation Experience
n Direct experience from the draft authorsn Squid HTTP-CoAP mapping module
n University of Padovan httptelecomdeiunipditiotn Both Forward and Interception operation supported
n HTTP-CoAP proxy based on EvCoAPn KoanLogic University of Bologna and Salvatore
Loreto (as individual)n httpsgithubcomkoanlogicwebthingstreemasterbridgesw
libevcoapn The document is open to input from other implementations
Next Steps
n Does the WG recommend adoptionn Intended status Informational Best Practicen Purpose Reduce arbitrary variation between proxy
implementations thereby increasing interoperability
Backup
HTTP to CoAP URI Mapping Options (12)
n Embedded Mapping n In an embedded mapping approach the HTTP URI has embedded
inside it the authority and path part of the CoAP URI n Example The CoAP resource nodecoapsomethingnetfoo can
be accessed by an HTTP client by inserting in the request httphc-proxysomethingnetcoapnodecoapsomethingnetfoo The Cross-Protocol Proxy then maps the URI to coapnodecoapsomethingnetfoo
HTTP to CoAP URI Mapping Options (22)
n Homogeneous Mapping n In a homogeneous mapping approach only the scheme portion of the URI
needs to be mapped The rest of the URI (ie authority path etc) remains unchanged
n Example The CoAP resource coapnodecoapsomethingnetfoo can be accessed by an HTTP client by requesting httpnodecoapsomethingnetfoo The Cross-Protocol Proxy receiving the request is responsible to map the URI to coapnodecoapsomethingnetfoo
n Background info n The assumption in this case is that the HTTP client would be able to
successfully resolve nodecoapsomethingnet using DNS infrastructure to return the IP address of the HC proxy Most likely this would be through a two step DNS lookup where the first DNS lookup would resolve somethingnet using public DNS infrastructure
n Then the second DNS lookup on the subdomain coap and the host node would typically be resolved by a DNS server operated by the owner of domain somethingnet So this domain owner can manage its own internal node names and subdomain allocation which would correspond to the CoAP namespace
Group 3 ldquonew workrdquo
39
Transport of CoAP over SMS USSD and GPRSdraft-becker-core-coap-sms-gprs-03
Markus Becker Kepeng LiKoojana Kuladinithi Thomas Poumltsch
CoRE WG IETF-86 Orlando
1 10
ScenariosI In M2M communication IP connectivity is not alwayssupported by the constrained end-points
I Power savingI Coverage (GPRS 3G LTE)
I SMS and USSD based communication is almost alwayssupported
210
Changes from draft-01 to draft-03 (1)
I Added possible CONNONACK interactions Section 5
I Option name changed from Reply-To- to Response-To-Section 16 and Section 101
I Added URI schemeEg coap+tel+15105550101well-knowncore Section 11
I Added possible M2M proxy scenarios Section 14
3 10
Changes from draft-01 to draft-03 (2)
I Added reference to bormann-coap-misc for other SMSencoding Section 71
I Updated requirements on Uri-Host and Uri-Port forcoap+tel Section 10
I Added security considerations Transport and ObjectSecurity Section 15
I Chose CoAP option numbers and updated the optionnumber table to meet draft-ietf-core-coap-10 Table 1
I Added an IANA registration for the URI scheme coap+telSection 162
4 10
Feedback Split coap+tel into coap+smsand coap+ussd
I How else to differ the various transports in the URII Or is the transport to use decided by the implementationI See alsodraft-silverajan-core-coap-alternative-transports-01
5 10
Feedback Response-To-Scheme option
I Should there be a Response-To-Scheme optionadditionally to Response-To-Uri-Host andResponse-To-Uri-Path
I So that a CoAP end-point which receives a request by CoAPover non-IP transport can be instructed to also use thenon-IP transport for the response
I This would imply to add aResponse-To-Telephone-Subscriber and more options forother transports that have other URI schemes than coapand coaps
6 10
Feedback Selection of Transport by Client
I When a server is reachable by various transports howdoes a client decide which transport to use
I Client-side application congurationI Leave it to a proxy which uses cellular network lookupfunctions
7 10
Feedback Potential Threats
I Trigger expensive short messagesI Redirect trac to other addressesI More threats
I Are the security measures in the draft adequateI Whitelisting on serverI Relying on cellular network security (dedicated M2M APNs)I Object security on CoAP payload
8 10
Feedback Message Exchanges
I Figures 11-18 show possible message exchanges whenclient and server have two addresses
I With NON Not using CoAP retransmission capabilityI ACK on different transportI Additional (costly) message on Transport AI Request with Content
I Which ones are allowedI Which ones are meaningful
9 10
Next steps
I Rene Uri schemeI Response-To-Scheme optionI Selection of Message ExchangeI Rene Proxying
10 10
CoAP13 Communicaon13 with13 Alternave13 Transports
Bill Silverajan and Teemu SavolainenCore WG IETF 86 Orlando
031113
Objecves13 (In13 Scope)
bull Unambiguous13 representaon13 of13 transport13 to13 be13 used13 by13 CoAP
bull Details13 how13 the13 transport13 can13 carry13 CoAP13 packet
bull Focus13 is13 on13 what13 CoAP13 communicaons13 requirements13 are
bull Allow13 CoAP13 mechanisms13 to13 exploit13 cross-shy‐layer13 opmisaons
51
031113
Non13 Goals13 (Not13 in13 scope)
bull Applicaon-shy‐level13 QoS13 requirementsbull Real-shy‐me13 constraintsbull Ordering13 reliability13 congeson13 controlbull Applicaon13 and13 network13 adaptaonbull Mobility13 and13 readdressing13 supportbull Network13 protocol13 (eg13 IPsec)13 configuraon
52
031113
Use13 Cases
bull NAT13 and13 Firewall13 traversal13 with13 TCPbull Delay13 Tolerant13 Networkingbull Non-shy‐IP13 Low13 Energy13 Protocols
53
031113
Related13 Work
bull OMA13 Lightweight13 M2M13 Protocolbull CoAP13 over13 SMSGPRSUSSD
54
031113
What13 does13 the13 work13 entail
bull The13 ability13 to13 specify13 end13 point13 idenfiers13 and13 URIs13 to13 reflect13 which13 transport13 CoAP13 can13 use
bull The13 ability13 to13 register13 to13 resource13 directories13 resource13 types13 reflecng13 types13 of13 transport13 available
bull Ability13 for13 mul-shy‐transport13 nodes13 to13 select13 transport13 to13 use13 without13 significant13 alteraon13 to13 CoAP13 packet13 structure
55
031113
Points13 to13 consider
bull Requirements13 for13 transport13 layer13 protocol13 to13 carry13 CoAP13 packets
bull Representaon13 of13 URI13 scheme13 for13 generic13 transport13 protocols
bull Opon13 extensions13 for13 CoAP13 to13 express13 available13 transports
bull Mapping13 and13 message13 sizebull Security13 consideraons
56
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
URI13 =13 scheme13 13 13 authority13 path-shy‐abempty13 [13 query13 ]
bull Within13 the13 scheme13 namebull In13 the13 URI13 pathbull As13 a13 query13 component
57
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
bull Within13 the13 scheme13 namendash coap+tel+15105550101well-shy‐knowncorendash coap+tcpexamplecom5683temperaturendash coap+blel2cap[1234567890AB]4pulse
bull Easy13 URI13 parsing13 for13 transport13 type13 and13 idenfier
bull Each13 new13 scheme13 name13 requires13 IANA13 registraon
58
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
bull In13 the13 URI13 pathndash coaphostexamplecomtransport=tcpwell-shy‐knowncorert=core-shy‐rd
bull Easy13 adopon13 of13 new13 (and13 experimental)13 CoAP13 transports13 without13 IANA13 registraon
bull Caveat13 Uri-shy‐Path13 opon13 is13 a13 Crical13 CoAP13 opon13 see13 secon13 54113 of13 I-shy‐Diep-shy‐core-shy‐coap
59
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
bull As13 a13 URI13 query13 componentndash coaphostexamplecomwell-shy‐knowncorert=core-shy‐rdq=tcp
bull Also13 easy13 to13 adopt13 new13 (and13 experimental)13 CoAP13 transports13 without13 IANA13 registraon
bull Caveat13 Uri-shy‐Query13 opon13 is13 a13 Crical13 CoAP13 opon13 see13 secon13 54113 of13 I-shy‐Diep-shy‐core-shy‐coap
60
031113
URI13 Representaons13 for13 CoAPNon13 standard13 ways
bull Transport13 in13 the13 URI13 authority13 componentndash coaphost[port][transport]13 instead13 of13 coaphost[port]
bull Transport13 as13 a13 service13 URLndash servicecoaptcphostexamplecomwell-shy‐knowncorert=core-shy‐rd
bull Above13 two13 ways13 break13 exisng13 compability13 (although13 both13 are13 based13 on13 valid13 IANA13 URI13 registraons)
61
031113
URI13 Representaons13 for13 CoAPMiscellaneous13 Consideraons
bull Ensure13 that13 transport13 is13 defined13 unambiguously13 (eg13 L2CAP13 used13 by13 both13 BLE13 and13 standard13 Bluetooth13 so13 avoid13 rdquocoap+l2caprdquo13 or13 rdquotransport=l2caprdquo13 or13 rdquoq=l2caprdquondash Can13 be13 done13 as13 WG13 consensusndash Namespace13 approach13 eg13 rdquocoap+blel2caprdquo13 or13 rdquoq=blel2caprdquo
bull Allow13 end-shy‐points13 to13 use13 CoAP13 Resource13 Directory13 to13 register13 alternave13 transports13 and13 idenfiers13 and13 provide13 periodic13 updatesndash Register13 rdquocore-shy‐transportrdquo13 resource13 type
62
031113
Transport13 Consideraons
bull Uniqueness13 of13 end-shy‐point13 idenficaonbull Communicaon13 support13 Unidireconal13 Bidireconal13 1N13 (broadcast13 mulcast13 anycast)13 messaging
bull Binary13 encoding13 Network13 byte13 orderingbull MTU13 correlaon13 with13 CoAP13 PDU13 sizebull Transport13 latency
63
031113
Security13 Consideraons
bull Drar13 does13 not13 introduce13 new13 security13 requirements13 by13 itself
bull There13 may13 be13 privacy13 issues13 if13 nodes13 use13 telephone13 numbers13 or13 MAC13 addresses13 as13 public13 end13 point13 idenfiers
64
Akbar Rahman
IETF 86 March 2013 httpwwwietforgiddraft-rahman-core-sleepy-02txt
Enhanced Sleepy Node Support for CoAP
Introduction
It is expected that in CoAP networks there will be a certain portion of devices that are sleepy and which may occasionally go into a sleep mode (ie go into a low power state to conserve power) and subsequently have reduced CoAP protocol communication ability
This I-D proposes a minimal and efficient mechanism building on the Resource Directory concept (which will be integrated into a CoAP Proxy) to enhance sleepy node support in CoAP networks
Main Question from IETF-85 (Atlanta)
What performance benefit does the proposed Sleepy Node support solution give in a network that already has standard CoAP caching enabled
Sleepy Node Performance Analysis
Experimental Network
1-5 clients
Both Sleepy and Non-
Sleepy servers
Sleepy Node Performance Analysis Network Setup
CoAPSleepyServer(s)
CoAPSleepAwareReverseProxy
CoAP
Client(s)
Request
Response
Sleep9AwareCoREResourceDirectoryCapability
PublishedSleepParameters
Sleep9AwareCoAPStoreandForwardCapability Response
Request
SleepAwareCoAP503ResponseCapability
CoAPCachingCapability
bull Server supports publishing sleep parameters to proxy bull Eg Irsquom going to be asleep for X seconds
bull Proxy supports sleep-awareness capabilities bull Proxy also supports caching capability based off of maxAge bull Protocol flow similar to approach of Figure 1 (Synchronous RD Based Sleep
Tracking) of I-D
Proxy capabilities can be selectively enableddisabled
Proxy ndash Server Interface
Client ndash Proxy Interface
CoAP Sleep-Aware Reverse Proxy Features CoRE Sleep-aware Resource Directory
Support storing published sleep parameters from CoAP servers sleepState (AWAKE ASLEEP) sleepDuration
Sleep-aware CoAP 503 Response Capability If CoAP request to a sleeping server is received proxy returns a
lsquo503 Retry-Afterrsquo response to client 503 contains a timestamp indicating when the sever will wake back up
(timestamp delivered in CoAP maxAge option) Sleep-aware CoAP Store-and-Forward Capability
If CoAP request to a sleeping server is received proxy stores request until server wakes up and then forwards it
Caching capability Cache GET responses from server if maxAge option is present
(this is not a sleep aware feature)
Goals of Performance Analysis
For networks having sleepy servers provide measurements to quantify the impact that CoAP sleep-awareness capabilities can have
See if sleep-awareness capabilities can
provide additional benefits even when CoAP caching is used
Overview of Performance Analysis Performed The analysis was broken up into a set of test scenarios Each test scenario used a different combination of the following
variables Client issued GET requests Server was configured as a sleepy or non-sleepy server Proxy caching of GET responses was enabled or disabled Proxy sleep-aware 503 response capability was enabled or disabled Proxy store-and-forward capability was enabled or disabled maxAge in GET responses ndash Two values were tested 60sec and 5sec of Clients ndash Two values were used ndash 1 client and 5 clients
For comparison purposes the following were held constant across all test scenarios Client issued a fixed number of requests (100) across all test scenarios Client used a delay between each GET request (35sec) to better exercise
proxyrsquos caching and sleep-awareness capabilities For sleepy server test scenarios the server slept 60 sec awake for 3 sec
Format of Results The following results were collected for each
test scenario
Breakdown of the and types of transactions occurring between clientproxyserver
ldquoGETrdquo ndash Test Scenario Results
GET ndash Description of Test Scenarios
TestScenarios-GET
Scenario
CoAPSleepyServerSe7ngs CoAPSleepAwareReverseProxySe7ngs CoAPClientSe7ngs
SleepDuragton(sec)
AwakeDuragton(sec)
maxAge(sec) Caching SleepAwareSAF+
503NumberofClients
NumberofGETs
DelayBetweenClient
Requests(sec)
1a 0 Always 60 Enabled Disabled 1 100 35
1b 60 3 60 Enabled Disabled 1 100 35
1c 60 3 60 Enabled Enabled 1 100 35
2a 0 Always 60 Enabled Disabled 5 100 35
2b 60 3 60 Enabled Disabled 5 100 35
2c 60 3 60 Enabled Enabled 5 100 35
3a 0 Always 5 Enabled Disabled 5 100 35
3b 60 3 5 Enabled Disabled 5 100 35
3c 60 3 5 Enabled Enabled 5 100 35
ldquoGETrdquo ndash Test Scenario 1 Results
maxAge = 60 and 1 Client
GET ndash Scenario 1 ClientProxy Interface Transaction Mix
Scenarios 1a - Non-Sleepy Server Caching Proxy maxAge = 60sec 1b- Sleepy Server Caching Proxy maxAge = 60sec 1c - Sleepy Server Sleep Aware Proxy maxAge = 60sec
Sleep Aware Proxy has better performance for sleepy servers
0
100
200
300
400
500
600
700
1a 1b 1c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
GET ndash Scenario 1 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
Scenarios 1a - Non-Sleepy Server Caching Proxy maxAge = 60sec 1b- Sleepy Server Caching Proxy maxAge = 60sec 1c - Sleepy Server Sleep Aware Proxy maxAge = 60sec
0
100
200
300
400
500
600
700
800
1a 1b 1c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
ldquoGETrdquo ndash Test Scenario 2 Results
maxAge = 60 and 5 Clients
GET ndash Scenario 2 ClientProxy Interface Transaction Mix
Sleep Aware Proxy has slightly better performance for sleepy servers
0
200
400
600
800
1000
1200
1400
2a 2b 2c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
Scenarios 2a - Non-Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2b- Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2c - Sleepy Server Sleep Aware Proxy maxAge = 60sec 5 Clients
See ldquoExperimental Artifactsrdquo Note 1
GET ndash Scenario 2 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has slightly better performance for sleepy servers
0
50
100
150
200
250
300
350
400
2a 2b 2c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
Scenarios 2a - Non-Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2b- Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2c - Sleepy Server Sleep Aware Proxy maxAge = 60sec 5 Clients
See ldquoExperimental Artifactsrdquo Note 2
Experimental Artifacts Note 1
Currently in the experiment the sleep aware proxy checks the cached state of a resource before putting a request into its Store-and-forward queue while a server is sleeping Once in the queue the proxy unconditionally forwards the queued requests to the server once it wakes up This is not the most efficient setup and can easily be improved If the proxy instead checks its cache again before forwarding each queued request it may not need to forward the request to the server For example if there are two queued GET requests in the proxyrsquos queue that address the same resource Only the first request needs to be sent to the server the second request can use the cached response from the first request
Note 2 Currently in the experiment the sleepy server sends a sleepState PUT request to the
proxy each time it goes to sleep This is not the most efficient setup and can easily be improved For example if the server assumes that the proxy can keep track of its ONOFF cycles with its internal timers (eg as per Fig 1 of I-D) then the number of messages from the sleepy server dramatically goes down
ldquoGETrdquo ndash Test Scenario 3 Results
maxAge = 5 and 5 Clients
GET ndash Scenario 3 ClientProxy Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
Scenarios 3a - Non-Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3b- Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3c - Sleepy Server Sleep Aware Proxy maxAge = 5sec 5 Clients
0
500
1000
1500
2000
2500
3000
3500
4000
4500
5000
3a 3b 3c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
GET ndash Scenario 3 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
0
1000
2000
3000
4000
5000
6000
7000
3a 3b 3c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
Scenarios 3a - Non-Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3b- Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3c - Sleepy Server Sleep Aware Proxy maxAge = 5sec 5 Clients
Conclusions
Conclusions These results show that sleep-aware CoAP
proxy features can significantly optimize communication with sleepy servers in most scenarios
These results also show that sleep-
awareness capabilities can provide additional benefits above and beyond CoAP caching in most scenarios
Backup
Current CoAP Support of Sleepy Node (12)
CoAP proxies can use a previously cached response to service a new GET request for a sleepy origin server (as in HTTP) But if no valid cache then proxy has to attempt to
retrieve and may fail if origin server is sleeping [I-Dietf-core-coap]
Clients can discover list of resources from RD (GET rd-lookuphellip) for sleepy servers But attempt to GET resource from sleepy origin server
may fail if origin server is sleeping [IDietf-core-link-format amp IDshelby-core-resource-
directory]
Current CoAP Support of Sleepy Node (22)
Lower layer support for sleepy nodes in most wireless technologies (eg WiFi ZigBee) But limited to MAC packet scheduling for sleepy nodes
and not aware of specific needs of IP applications (like CoAP)
Proposal ndash RD Based Sleep Tracking (14)
The current CoAP approach to support sleepy nodes can be significantly improved by introducing RD based mechanisms for a CoAP client to determine whether A targeted resource is located on a sleepy server A sleepy server is currently in sleep mode or not
There is any associated caching Proxy (possibly the RD itself) for a sleepy server
Proposal ndash RD Based Sleep Tracking (24)
We define the following new RD attributes to characterize the properties of a sleepy node SleepState - Indicates whether the node is currently in
sleep mode or not (ie Sleeping or Awake) SleepDuration - Indicates the maximum duration of time
that the node stays in sleep mode TimeSleeping - Indicates the length of time the node
has been sleeping (ie if Sleep State = Sleeping) NextSleep - Indicates the next time the node will go to
sleep (ie if Sleep State = Awake)
CachingProxy ndash Indicates the caching proxy of the sleepy node (ie the RD itself or another node)
Proposal ndash RD Based Sleep Tracking (34)
These attributes are all server (node) level and are new parameters added to the RD URI Template Variables
Finally we also define a new lookup-type (ss) for the RD lookup interface specified in [I-Dshelby-core-resource-directory] This new lookup-type supports looking up the
ldquoSleepStaterdquo (ss) of a specified end-point
Proposal ndash RD Based Sleep Tracking (44)
The three time based parameters (SleepDuration TimeSleeping NextSleep) can be based on either an absolute network time (for a time synchronized network) or a relative local time (measured at the local node)
Following the approach of [I-Dietf-core-link-format] and [I-Dshelby-core-resource-directory] sleep parameters for sleepy servers can be stored by the server in the RD and accessed by all interested clients
Examples of using these parameters in a synchronous or asynchronous manner are shown in the I-D
http6lowappnet coreIETF86 2013-03-12-13
We assume people have read the drafts
Meetings serve to advance difficult issues by making good use of face-to-face communications
Note Well Be aware of the IPR principles according to RFC 3979 and its updates
uumlBlue sheetsuumlScribe(s)
96
drar-shy‐iep-shy‐core-shy‐coapsubmiqed13 to13 IESG
2013-shy‐03-shy‐13
97
OMA Lightweight M2M Overview(A new standard using lots of IETF specs including DTLS
CoAP Block Observe Resource Directory SenMLhellip)
Zach ShelbyCoRE WG IETF-86 Orlando
OMA Lightweight M2Mbull Open Mobile Alliance is well known for Device Management (DM)bull OMA Lightweight M2M is a new standard from the alliance
ndash Focused on constrained Cellular and sensor network M2M devicesndash Driven by leading operators and vendors
bull Scopendash Interfaces protocol amp security between Device and Serverndash Object and Resource modelndash Bootstrap Device Access Control Connectivity and Firmware Objects
bull Draft Specifications are availablendash httpmemberopenmobileallianceorgftpPublic_documentsDM
LightweightM2MPermanent_documentsOMA-TS-LightweightM2M-V1_0_0-20130301-Dzip
bull Timelinendash Requirements and Architecture completed 3Q2012ndash Spec ready for Consistency Review 2Q2013ndash Candidate Approval expected 3Q2013
2 CoRE WG IETF-86 Orlando
Architecture
3
Scope of LWM2M
CoRE WG IETF-86 Orlando
Object Model
bull A Client has one or more Object Instancesbull An Object is a collection of Resourcesbull A Resource is an atomic piece of information
ndash Read Written or Executed
bull Resources can have multiple instancesbull Objects and Resources are identified by a
16-bit Integer Instances by an 8-bit Integerbull ObjectsResources are accessed with
simple URIs Object IDObject InstanceResource ID
eg 1213
4 CoRE WG IETF-86 Orlando
CoRE WG IETF-86 Orlando
CoRE Resource Directory
draft-shelby-core-resource-directory-05
Z Shelby C Bormann S Krco
Backgroundbull Not a new concept
ndash think web search engine or any link directorybull Defines the interfaces to a Resource Directorybull Based on Web Linking framework and the CoRE Link Formatbull Generic REST design for use over HTTP and CoAPbull Used by OMA Lightweight M2Mbull Has already been deployed
ndash In traffic monitoring systemsndash In street lighting systemsndash For vehicular asset trackingndash By a major Cellular M2M operator
Changes since -04
bull Restricted Update to parameter updatesbull Added pagination support for the Lookup interfacebull Changed rt= to et= for the registration amp update
interfacebull Added group support
Group Management
bull RD now includes group management featuresbull New Group Function Set
ndash Register a groupbull Group name domain multicast address endpoint members
ndash Remove a groupbull Group lookup using the Lookup Function Set
ndash List registered groupsndash Find the members of a groupndash Find groups with certain endpoints or resources
Registering a Group
EP RD
| |
| - POST rd-groupgp=lights ltgtep=node1 --gt |
| |
| |
| lt---- 201 Created Location rd-group12 ---- |
| |
Req POST coaprdexamplecomrd-groupgp=lights
Payload
ltgtep=node1
ltgtep=node2
Res 201 Created
Location rd-group12
Looking up Group Members
Client RD
| |
| ----- GET rd-lookupepgp=lights1 ----------------------gt |
| |
| |
| lt-- 205 Content ltrdgtd=domain1ltrdgtd=domain2 --------- |
| |
Req GET rd-lookupepgp=lights1
Res 205 Content
ltcoaphostportgtep=node1
ltcoaphostportgtep=node2rdquo
Things for the futurebull Support for JSON representation of Web Links
ndash httptoolsietforgiddraft-bormann-core-links-json-02txtbull Registry for RD registration query parameters
ndash Already OMA Lightweight has defined some new onesbull More examples
Group 3 ldquonew workrdquo(continued)
109
drar-shy‐greevenbosch-shy‐core-shy‐profile-shy‐descripon-shy‐01Bert13 GreevenboschJeroen13 Hoebeke
Isam13 IshaqFloris13 Van13 den13 Abeele
Descripon
bull JSON13 format13 for13 signalling13 the13 servers13 capabilies
bull Signalling13 of13 supported13 opons13 media13 types13 and13 block13 sizendash Other13 items13 can13 be13 added
bull Filtering13 on13 specific13 fields13 through13 URI-shy‐Querybull Link13 hqpdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐profile-shy‐descripon
well-shy‐knownprofile
bull To13 acquire13 profile13 data13 of13 resources13 on13 a13 parcular13 service13 the13 well-shy‐knownprofile13 URI-shy‐path13 is13 introduced
bull For13 example13 to13 get13 all13 informaon13 from13 sensors13 served13 by13 wwwexampleorg13 we13 can13 do13 a13 GET13 to13 coapwwwexampleorgwell-shy‐knownprofile
bull Filtering13 on13 parcular13 resources13 is13 done13 through13 URI-shy‐Queries
Format
bull Currently13 the13 following13 fields13 are13 definedndash ldquopathrdquo13 contains13 the13 URI-shy‐path13 associated13 with13 a13 resource
ndash ldquooprdquo13 a13 numerical13 list13 of13 supported13 opon13 numbers
ndash ldquocfrdquo13 a13 numerical13 list13 of13 supported13 content-shy‐format13 numbers
ndash ldquob1srdquo13 ldquob2srdquo13 supported13 block13 sizes13 for13 Block113 and13 Block213 respecvely
Examplebull On13 the13 right13 is13 an13 example13 of13 a13 camera13 sensor13 at13 coapwwwexampleorgcam13 that13 supports13 the13 Uri-shy‐Host13 (3)13 ETag13 (4)13 Uri-shy‐Port13 (7)13 Uri-shy‐Path13 (11)13 Content-shy‐Format13 (12)13 Token13 (19)13 Block213 (23)13 and13 Proxy-shy‐Uri13 (35)13 opons
bull The13 supported13 content13 formats13 are13 textplain13 (0)13 applicaon13 link-shy‐format13 (40)13 and13 applicaonjson13 (50)
bull The13 supported13 Block213 can13 use13 25613 or13 51213 byte13 blocks
Req13 GET13 coapwwwexampleorgwell-shy‐knownprofile13 Res13 20513 Content13 (applicationjson)13 13 13 13 profile13 13 13 13 13 13 13 13 pathcam13 13 13 13 op[3471112192335]13 13 13 13 13 cf[04050]13 13 13 13 13 b2s[45]13 13 13 13
Filtering13 through13 use13 of13 URI-shy‐Query
bull Filtering13 can13 be13 done13 through13 the13 URI-shy‐Querybull Query13 format13 N=V
ndash N13 is13 a13 profile13 fieldndash V13 is13 the13 desired13 value
bull Examplesndash To13 find13 resources13 that13 support13 content13 format13 ldquoapplicaonjsonrdquo
13 GET13 wwwexampleorgwell-shy‐knownprofilecf=50ndash To13 get13 informaon13 about13 the13 camera
13 GET13 wwwexampleorgwell-shy‐knownprofilepath=cam
Open13 issues
bull Which13 other13 profile13 data13 needs13 signallingndash Content-shy‐type13 for13 different13 methods
bull Fix13 the13 order13 in13 which13 the13 profile13 fields13 must13 appearndash Non-shy‐fixed13 order13 easier13 extensible
bull Inheritance13 of13 a13 profile13 descriponbull Extend13 usage13 to13 signal13 the13 client13 profilebull Integraon13 with13 link13 format
Thank13 youQuesons
drar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval-shy‐00
Bert13 Greevenbosch
Descripon
bull The13 ldquoMinimumRequestInterval13 opon13 can13 be13 used13 to13 indicate13 the13 minimum13 me13 between13 two13 requests13 in13 a13 transacon
bull Originally13 intended13 for13 Block13 but13 also13 usable13 for13 other13 transaconsndash Example13 browsing13 a13 server
bull The13 goal13 is13 to13 reduce13 the13 server13 load13 and13 network13 traffic
bull Link13 hqpsdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval
Usage
bull The13 client13 keeps13 the13 server13 informed13 about13 its13 request13 speed13 through13 inclusion13 of13 the13 ldquoMinimumRequestIntervalrdquo13 opon
bull In13 responses13 the13 server13 fixes13 the13 minimum13 request13 interval13 through13 the13 same13 opon
bull The13 client13 obeys13 the13 speed13 indicated13 by13 the13 server
bull The13 client13 can13 send13 slower13 but13 not13 faster
Advantages
bull The13 server13 has13 means13 to13 limit13 the13 amount13 of13 incoming13 traffic
bull The13 server13 can13 prevent13 to13 become13 overloaded13 with13 too13 many13 tasks
bull The13 server13 does13 not13 need13 arficially13 slow13 down13 the13 client13 by13 sending13 late13 ACKsndash No13 need13 to13 keep13 track13 of13 delayed13 ACKsndash The13 server13 can13 perform13 other13 tasks13 instead
bull Reduced13 network13 traffic
Thank13 youQuesons
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-links-json-02txt
123
RFC 6690 (link-format) documents are somewhat foreign to many web app developerssect would prefer to have them in JSON format
There is no standard way to represent link-format documents in applicationssect but everyone knows how to handle JSON
Define a standard JSON translation for link-format
Itrsquos
not
rock
et
scien
ce
ltsensorsgtct=40title=Sensor Index ltsensorstempgtrt=temperature-cif=sensor ltsensorslightgtrt=light-luxif=sensor lthttpwwwexamplecomsensorst123gt anchor=sensorstemprel=describedby lttgtanchor=sensorstemprel=alternate [hrefsensorsct40titleSensor Index hrefsensorstemprttemperature-cifsensor hrefsensorslightrtlight-luxifsensor hrefhttpwwwexamplecomsensorst123 anchorsensorstempreldescribedby hreftanchorsensorstemprelalternate]
124
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-ipsec-for-coap-00txt
IPsec definitions for CoAP Mostly placeholder at this time Who has implementation experience with this
125
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-cross-reverse-convention-00txt
This draft has two lines of payload(based on a WGLC comment by Cullen Jennings)
coap12344567foobara=3
httpwwwproxycomwellknowncore-translate1234_4567foobara=3
Is that a useful convention to have
126
Insert CI slides here
127
128
0
5
10
15
20
25
30
35
40
10 20 30 40 50 60 70
good
put (
pps)
pps
Goodput vs pps (Econotags)
goodput
[Khattak preliminary]
Congestion Control
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-cocoa-00txt
ldquoadvancedrdquo cc (The draft is just a first shot) Others may have better ideas
129
Insert post-WGLC discussion slides here
130
Stop Continue Start
131
An Agile Retrospective
http6lowappnet coreIETF86 2013-03-12-13
Stop
132
Endless new CoAP optionssect instead use RESTful as much as possible
Move general security lifecycle out Looking at theoretical problems
http6lowappnet coreIETF86 2013-03-12-13
Continue
Interops Running code Look at real-world examples and deployments Solve their actual problems
sect Unilateral enhancements eg higher performance congestion control
sect Transports (SMS hellip)sect Make Web linking and Directories more and more usefulsect RESTful Design Paradigms for real-world problems
133
http6lowappnet coreIETF86 2013-03-12-13
Start
Further push into the (browser) web world (HTML5 browser security)
Specific supporting worksect SenMLsect URI work (dev URN hellip)sect Security Processes (next slide)
Spin outsect (We donrsquot really get to decide where this is done)
134
http6lowappnet coreIETF86 2013-03-12-13
Security
Integrate Application Network Group Keyingsect Tunnel-free setup
Donrsquot redo what has been done alreadysect ZigBee IP is finesect But what about other scenarios
Simple REST interfaces for working with keying materials and authorizationsect Start with defining objectives
Object Security for Constrained Nodes135
Re-chartering CoREWhat do we want to do now that wersquore grown up
Zach ShelbyCoRE WG IETF-86 Orlando
What is the scope
bull So we have a protocol and Web Linking what next
bull Keep with what we know besthellip1 Enhancements around CoAP2 New transports for CoAP3 New representations for Web Links4 General application layer solutions
CoRE WG IETF-86 Orlando 2
Enhancements around CoAP
bull Advanced congestion control
CoRE WG IETF-86 Orlando 3
New Transports for CoAP
bull Infrastructure for CoAP over foondash httptoolsietforgiddraft-silverajan-core-
coap-alternative-transports-01txtbull CoAP over SMS
ndash httptoolsietforgiddraft-becker-core-coap-sms-gprs-03txt
ndash OMA Lightweightbull CoAP over TCP
ndash httptoolsietforgiddraft-li-core-coap-payload-length-option-01txt
CoRE WG IETF-86 Orlando 4
New support for Web Links
bull JSON Web Linksndash httptoolsietforgiddraft-bormann-core-links-
json-02txt
2332010 CoRE WG IETF-77 Anaheim 5
General application layer solutions
bull Resource Directoryndash httptoolsietforgiddraft-shelby-core-
resource-directory-05txtndash OMA Lightweight
2332010 CoRE WG IETF-77 Anaheim 6
Summary of Changes (from -06 rev)
n Based on discussion at last IETF-85 (Atlanta)n Clarification of HTTP-CoAP Proxies
n Definitionn Placementn Benefits
n Clarification of HTTP-CoAP URI mapping options
Goals of I-D
n For Reverse HTTP-CoAP Cross Protocol Proxyn Provide more detailed information to proxy designers (beyond
Section 10 of [I-Dietf-core-coap]) to help implement proxies that correctly inter-work with other CoAP and HTTP clientserver implementations that adhere to the specifications
n Define a consistent set of guidelines that a HTTP-to-CoAP proxy implementation MAY adhere to The main reason of adhering to such guidelines is to reduce variation between proxy implementations thereby increasing interoperabilityn As an example use case a proxy conforming to these guidelines made
by vendor A can be easily replaced by a proxy from vendor B that also conforms to the guidelines
I-D Outline
n Guidance on HTTP to CoAP URI mappingn HTTP-CoAP Reverse cross-protocol proxy implementation
n Placementn Response code amp media type translationsn Caching and congestion controln Cache refresh via Observen Use of CoAP blockwise transfern Security translation
n Security Considerationsn Traffic overflown Handling secured exchanges
Definitions (12)
n Cross-Protocol Proxy (or Cross Proxy) is a proxy performing a cross- protocol mapping in the context of this document a HTTP-CoAP (HC) mapping A Cross-Protocol Proxy can behave as a Forward Proxy Reverse Proxy or Interception Proxy n Note In this document we focus on the Reverse Proxy mode of the
Cross-Protocol Proxy
n Forward Proxy a message forwarding agent that is selected by the client usually via local configuration rules to receive requests for some type(s) of absolute URI and to attempt to satisfy those requests via translation to the protocol indicated by the absolute URI The user decides (is willing to) use the proxy as the forwardingdereferencing agent for a predefined subset of the URI space
Definitions (22)
n Reverse Proxy a receiving agent that acts as a layer above some other server(s) and translates the received requests to the underlying servers protocol It behaves as an origin (HTTP) server on its connection towards the (HTTP) client and as a (CoAP) client on its connection towards the (CoAP) origin server The (HTTP) client uses the origin-form [I-Dietf-httpbis-p1-messaging] as a request- target URI
n Reverse and Forward proxies are technically very similar with main differences being that the former appears to a client as an origin server while the latter does not and that clients may be unaware they are communicating with a proxy
Reverse Cross-Protocol Proxy Deployment Scenario
HTTP-CoAP Response Code Mapping
Implementation Experience
n Direct experience from the draft authorsn Squid HTTP-CoAP mapping module
n University of Padovan httptelecomdeiunipditiotn Both Forward and Interception operation supported
n HTTP-CoAP proxy based on EvCoAPn KoanLogic University of Bologna and Salvatore
Loreto (as individual)n httpsgithubcomkoanlogicwebthingstreemasterbridgesw
libevcoapn The document is open to input from other implementations
Next Steps
n Does the WG recommend adoptionn Intended status Informational Best Practicen Purpose Reduce arbitrary variation between proxy
implementations thereby increasing interoperability
Backup
HTTP to CoAP URI Mapping Options (12)
n Embedded Mapping n In an embedded mapping approach the HTTP URI has embedded
inside it the authority and path part of the CoAP URI n Example The CoAP resource nodecoapsomethingnetfoo can
be accessed by an HTTP client by inserting in the request httphc-proxysomethingnetcoapnodecoapsomethingnetfoo The Cross-Protocol Proxy then maps the URI to coapnodecoapsomethingnetfoo
HTTP to CoAP URI Mapping Options (22)
n Homogeneous Mapping n In a homogeneous mapping approach only the scheme portion of the URI
needs to be mapped The rest of the URI (ie authority path etc) remains unchanged
n Example The CoAP resource coapnodecoapsomethingnetfoo can be accessed by an HTTP client by requesting httpnodecoapsomethingnetfoo The Cross-Protocol Proxy receiving the request is responsible to map the URI to coapnodecoapsomethingnetfoo
n Background info n The assumption in this case is that the HTTP client would be able to
successfully resolve nodecoapsomethingnet using DNS infrastructure to return the IP address of the HC proxy Most likely this would be through a two step DNS lookup where the first DNS lookup would resolve somethingnet using public DNS infrastructure
n Then the second DNS lookup on the subdomain coap and the host node would typically be resolved by a DNS server operated by the owner of domain somethingnet So this domain owner can manage its own internal node names and subdomain allocation which would correspond to the CoAP namespace
Group 3 ldquonew workrdquo
39
Transport of CoAP over SMS USSD and GPRSdraft-becker-core-coap-sms-gprs-03
Markus Becker Kepeng LiKoojana Kuladinithi Thomas Poumltsch
CoRE WG IETF-86 Orlando
1 10
ScenariosI In M2M communication IP connectivity is not alwayssupported by the constrained end-points
I Power savingI Coverage (GPRS 3G LTE)
I SMS and USSD based communication is almost alwayssupported
210
Changes from draft-01 to draft-03 (1)
I Added possible CONNONACK interactions Section 5
I Option name changed from Reply-To- to Response-To-Section 16 and Section 101
I Added URI schemeEg coap+tel+15105550101well-knowncore Section 11
I Added possible M2M proxy scenarios Section 14
3 10
Changes from draft-01 to draft-03 (2)
I Added reference to bormann-coap-misc for other SMSencoding Section 71
I Updated requirements on Uri-Host and Uri-Port forcoap+tel Section 10
I Added security considerations Transport and ObjectSecurity Section 15
I Chose CoAP option numbers and updated the optionnumber table to meet draft-ietf-core-coap-10 Table 1
I Added an IANA registration for the URI scheme coap+telSection 162
4 10
Feedback Split coap+tel into coap+smsand coap+ussd
I How else to differ the various transports in the URII Or is the transport to use decided by the implementationI See alsodraft-silverajan-core-coap-alternative-transports-01
5 10
Feedback Response-To-Scheme option
I Should there be a Response-To-Scheme optionadditionally to Response-To-Uri-Host andResponse-To-Uri-Path
I So that a CoAP end-point which receives a request by CoAPover non-IP transport can be instructed to also use thenon-IP transport for the response
I This would imply to add aResponse-To-Telephone-Subscriber and more options forother transports that have other URI schemes than coapand coaps
6 10
Feedback Selection of Transport by Client
I When a server is reachable by various transports howdoes a client decide which transport to use
I Client-side application congurationI Leave it to a proxy which uses cellular network lookupfunctions
7 10
Feedback Potential Threats
I Trigger expensive short messagesI Redirect trac to other addressesI More threats
I Are the security measures in the draft adequateI Whitelisting on serverI Relying on cellular network security (dedicated M2M APNs)I Object security on CoAP payload
8 10
Feedback Message Exchanges
I Figures 11-18 show possible message exchanges whenclient and server have two addresses
I With NON Not using CoAP retransmission capabilityI ACK on different transportI Additional (costly) message on Transport AI Request with Content
I Which ones are allowedI Which ones are meaningful
9 10
Next steps
I Rene Uri schemeI Response-To-Scheme optionI Selection of Message ExchangeI Rene Proxying
10 10
CoAP13 Communicaon13 with13 Alternave13 Transports
Bill Silverajan and Teemu SavolainenCore WG IETF 86 Orlando
031113
Objecves13 (In13 Scope)
bull Unambiguous13 representaon13 of13 transport13 to13 be13 used13 by13 CoAP
bull Details13 how13 the13 transport13 can13 carry13 CoAP13 packet
bull Focus13 is13 on13 what13 CoAP13 communicaons13 requirements13 are
bull Allow13 CoAP13 mechanisms13 to13 exploit13 cross-shy‐layer13 opmisaons
51
031113
Non13 Goals13 (Not13 in13 scope)
bull Applicaon-shy‐level13 QoS13 requirementsbull Real-shy‐me13 constraintsbull Ordering13 reliability13 congeson13 controlbull Applicaon13 and13 network13 adaptaonbull Mobility13 and13 readdressing13 supportbull Network13 protocol13 (eg13 IPsec)13 configuraon
52
031113
Use13 Cases
bull NAT13 and13 Firewall13 traversal13 with13 TCPbull Delay13 Tolerant13 Networkingbull Non-shy‐IP13 Low13 Energy13 Protocols
53
031113
Related13 Work
bull OMA13 Lightweight13 M2M13 Protocolbull CoAP13 over13 SMSGPRSUSSD
54
031113
What13 does13 the13 work13 entail
bull The13 ability13 to13 specify13 end13 point13 idenfiers13 and13 URIs13 to13 reflect13 which13 transport13 CoAP13 can13 use
bull The13 ability13 to13 register13 to13 resource13 directories13 resource13 types13 reflecng13 types13 of13 transport13 available
bull Ability13 for13 mul-shy‐transport13 nodes13 to13 select13 transport13 to13 use13 without13 significant13 alteraon13 to13 CoAP13 packet13 structure
55
031113
Points13 to13 consider
bull Requirements13 for13 transport13 layer13 protocol13 to13 carry13 CoAP13 packets
bull Representaon13 of13 URI13 scheme13 for13 generic13 transport13 protocols
bull Opon13 extensions13 for13 CoAP13 to13 express13 available13 transports
bull Mapping13 and13 message13 sizebull Security13 consideraons
56
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
URI13 =13 scheme13 13 13 authority13 path-shy‐abempty13 [13 query13 ]
bull Within13 the13 scheme13 namebull In13 the13 URI13 pathbull As13 a13 query13 component
57
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
bull Within13 the13 scheme13 namendash coap+tel+15105550101well-shy‐knowncorendash coap+tcpexamplecom5683temperaturendash coap+blel2cap[1234567890AB]4pulse
bull Easy13 URI13 parsing13 for13 transport13 type13 and13 idenfier
bull Each13 new13 scheme13 name13 requires13 IANA13 registraon
58
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
bull In13 the13 URI13 pathndash coaphostexamplecomtransport=tcpwell-shy‐knowncorert=core-shy‐rd
bull Easy13 adopon13 of13 new13 (and13 experimental)13 CoAP13 transports13 without13 IANA13 registraon
bull Caveat13 Uri-shy‐Path13 opon13 is13 a13 Crical13 CoAP13 opon13 see13 secon13 54113 of13 I-shy‐Diep-shy‐core-shy‐coap
59
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
bull As13 a13 URI13 query13 componentndash coaphostexamplecomwell-shy‐knowncorert=core-shy‐rdq=tcp
bull Also13 easy13 to13 adopt13 new13 (and13 experimental)13 CoAP13 transports13 without13 IANA13 registraon
bull Caveat13 Uri-shy‐Query13 opon13 is13 a13 Crical13 CoAP13 opon13 see13 secon13 54113 of13 I-shy‐Diep-shy‐core-shy‐coap
60
031113
URI13 Representaons13 for13 CoAPNon13 standard13 ways
bull Transport13 in13 the13 URI13 authority13 componentndash coaphost[port][transport]13 instead13 of13 coaphost[port]
bull Transport13 as13 a13 service13 URLndash servicecoaptcphostexamplecomwell-shy‐knowncorert=core-shy‐rd
bull Above13 two13 ways13 break13 exisng13 compability13 (although13 both13 are13 based13 on13 valid13 IANA13 URI13 registraons)
61
031113
URI13 Representaons13 for13 CoAPMiscellaneous13 Consideraons
bull Ensure13 that13 transport13 is13 defined13 unambiguously13 (eg13 L2CAP13 used13 by13 both13 BLE13 and13 standard13 Bluetooth13 so13 avoid13 rdquocoap+l2caprdquo13 or13 rdquotransport=l2caprdquo13 or13 rdquoq=l2caprdquondash Can13 be13 done13 as13 WG13 consensusndash Namespace13 approach13 eg13 rdquocoap+blel2caprdquo13 or13 rdquoq=blel2caprdquo
bull Allow13 end-shy‐points13 to13 use13 CoAP13 Resource13 Directory13 to13 register13 alternave13 transports13 and13 idenfiers13 and13 provide13 periodic13 updatesndash Register13 rdquocore-shy‐transportrdquo13 resource13 type
62
031113
Transport13 Consideraons
bull Uniqueness13 of13 end-shy‐point13 idenficaonbull Communicaon13 support13 Unidireconal13 Bidireconal13 1N13 (broadcast13 mulcast13 anycast)13 messaging
bull Binary13 encoding13 Network13 byte13 orderingbull MTU13 correlaon13 with13 CoAP13 PDU13 sizebull Transport13 latency
63
031113
Security13 Consideraons
bull Drar13 does13 not13 introduce13 new13 security13 requirements13 by13 itself
bull There13 may13 be13 privacy13 issues13 if13 nodes13 use13 telephone13 numbers13 or13 MAC13 addresses13 as13 public13 end13 point13 idenfiers
64
Akbar Rahman
IETF 86 March 2013 httpwwwietforgiddraft-rahman-core-sleepy-02txt
Enhanced Sleepy Node Support for CoAP
Introduction
It is expected that in CoAP networks there will be a certain portion of devices that are sleepy and which may occasionally go into a sleep mode (ie go into a low power state to conserve power) and subsequently have reduced CoAP protocol communication ability
This I-D proposes a minimal and efficient mechanism building on the Resource Directory concept (which will be integrated into a CoAP Proxy) to enhance sleepy node support in CoAP networks
Main Question from IETF-85 (Atlanta)
What performance benefit does the proposed Sleepy Node support solution give in a network that already has standard CoAP caching enabled
Sleepy Node Performance Analysis
Experimental Network
1-5 clients
Both Sleepy and Non-
Sleepy servers
Sleepy Node Performance Analysis Network Setup
CoAPSleepyServer(s)
CoAPSleepAwareReverseProxy
CoAP
Client(s)
Request
Response
Sleep9AwareCoREResourceDirectoryCapability
PublishedSleepParameters
Sleep9AwareCoAPStoreandForwardCapability Response
Request
SleepAwareCoAP503ResponseCapability
CoAPCachingCapability
bull Server supports publishing sleep parameters to proxy bull Eg Irsquom going to be asleep for X seconds
bull Proxy supports sleep-awareness capabilities bull Proxy also supports caching capability based off of maxAge bull Protocol flow similar to approach of Figure 1 (Synchronous RD Based Sleep
Tracking) of I-D
Proxy capabilities can be selectively enableddisabled
Proxy ndash Server Interface
Client ndash Proxy Interface
CoAP Sleep-Aware Reverse Proxy Features CoRE Sleep-aware Resource Directory
Support storing published sleep parameters from CoAP servers sleepState (AWAKE ASLEEP) sleepDuration
Sleep-aware CoAP 503 Response Capability If CoAP request to a sleeping server is received proxy returns a
lsquo503 Retry-Afterrsquo response to client 503 contains a timestamp indicating when the sever will wake back up
(timestamp delivered in CoAP maxAge option) Sleep-aware CoAP Store-and-Forward Capability
If CoAP request to a sleeping server is received proxy stores request until server wakes up and then forwards it
Caching capability Cache GET responses from server if maxAge option is present
(this is not a sleep aware feature)
Goals of Performance Analysis
For networks having sleepy servers provide measurements to quantify the impact that CoAP sleep-awareness capabilities can have
See if sleep-awareness capabilities can
provide additional benefits even when CoAP caching is used
Overview of Performance Analysis Performed The analysis was broken up into a set of test scenarios Each test scenario used a different combination of the following
variables Client issued GET requests Server was configured as a sleepy or non-sleepy server Proxy caching of GET responses was enabled or disabled Proxy sleep-aware 503 response capability was enabled or disabled Proxy store-and-forward capability was enabled or disabled maxAge in GET responses ndash Two values were tested 60sec and 5sec of Clients ndash Two values were used ndash 1 client and 5 clients
For comparison purposes the following were held constant across all test scenarios Client issued a fixed number of requests (100) across all test scenarios Client used a delay between each GET request (35sec) to better exercise
proxyrsquos caching and sleep-awareness capabilities For sleepy server test scenarios the server slept 60 sec awake for 3 sec
Format of Results The following results were collected for each
test scenario
Breakdown of the and types of transactions occurring between clientproxyserver
ldquoGETrdquo ndash Test Scenario Results
GET ndash Description of Test Scenarios
TestScenarios-GET
Scenario
CoAPSleepyServerSe7ngs CoAPSleepAwareReverseProxySe7ngs CoAPClientSe7ngs
SleepDuragton(sec)
AwakeDuragton(sec)
maxAge(sec) Caching SleepAwareSAF+
503NumberofClients
NumberofGETs
DelayBetweenClient
Requests(sec)
1a 0 Always 60 Enabled Disabled 1 100 35
1b 60 3 60 Enabled Disabled 1 100 35
1c 60 3 60 Enabled Enabled 1 100 35
2a 0 Always 60 Enabled Disabled 5 100 35
2b 60 3 60 Enabled Disabled 5 100 35
2c 60 3 60 Enabled Enabled 5 100 35
3a 0 Always 5 Enabled Disabled 5 100 35
3b 60 3 5 Enabled Disabled 5 100 35
3c 60 3 5 Enabled Enabled 5 100 35
ldquoGETrdquo ndash Test Scenario 1 Results
maxAge = 60 and 1 Client
GET ndash Scenario 1 ClientProxy Interface Transaction Mix
Scenarios 1a - Non-Sleepy Server Caching Proxy maxAge = 60sec 1b- Sleepy Server Caching Proxy maxAge = 60sec 1c - Sleepy Server Sleep Aware Proxy maxAge = 60sec
Sleep Aware Proxy has better performance for sleepy servers
0
100
200
300
400
500
600
700
1a 1b 1c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
GET ndash Scenario 1 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
Scenarios 1a - Non-Sleepy Server Caching Proxy maxAge = 60sec 1b- Sleepy Server Caching Proxy maxAge = 60sec 1c - Sleepy Server Sleep Aware Proxy maxAge = 60sec
0
100
200
300
400
500
600
700
800
1a 1b 1c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
ldquoGETrdquo ndash Test Scenario 2 Results
maxAge = 60 and 5 Clients
GET ndash Scenario 2 ClientProxy Interface Transaction Mix
Sleep Aware Proxy has slightly better performance for sleepy servers
0
200
400
600
800
1000
1200
1400
2a 2b 2c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
Scenarios 2a - Non-Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2b- Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2c - Sleepy Server Sleep Aware Proxy maxAge = 60sec 5 Clients
See ldquoExperimental Artifactsrdquo Note 1
GET ndash Scenario 2 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has slightly better performance for sleepy servers
0
50
100
150
200
250
300
350
400
2a 2b 2c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
Scenarios 2a - Non-Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2b- Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2c - Sleepy Server Sleep Aware Proxy maxAge = 60sec 5 Clients
See ldquoExperimental Artifactsrdquo Note 2
Experimental Artifacts Note 1
Currently in the experiment the sleep aware proxy checks the cached state of a resource before putting a request into its Store-and-forward queue while a server is sleeping Once in the queue the proxy unconditionally forwards the queued requests to the server once it wakes up This is not the most efficient setup and can easily be improved If the proxy instead checks its cache again before forwarding each queued request it may not need to forward the request to the server For example if there are two queued GET requests in the proxyrsquos queue that address the same resource Only the first request needs to be sent to the server the second request can use the cached response from the first request
Note 2 Currently in the experiment the sleepy server sends a sleepState PUT request to the
proxy each time it goes to sleep This is not the most efficient setup and can easily be improved For example if the server assumes that the proxy can keep track of its ONOFF cycles with its internal timers (eg as per Fig 1 of I-D) then the number of messages from the sleepy server dramatically goes down
ldquoGETrdquo ndash Test Scenario 3 Results
maxAge = 5 and 5 Clients
GET ndash Scenario 3 ClientProxy Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
Scenarios 3a - Non-Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3b- Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3c - Sleepy Server Sleep Aware Proxy maxAge = 5sec 5 Clients
0
500
1000
1500
2000
2500
3000
3500
4000
4500
5000
3a 3b 3c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
GET ndash Scenario 3 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
0
1000
2000
3000
4000
5000
6000
7000
3a 3b 3c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
Scenarios 3a - Non-Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3b- Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3c - Sleepy Server Sleep Aware Proxy maxAge = 5sec 5 Clients
Conclusions
Conclusions These results show that sleep-aware CoAP
proxy features can significantly optimize communication with sleepy servers in most scenarios
These results also show that sleep-
awareness capabilities can provide additional benefits above and beyond CoAP caching in most scenarios
Backup
Current CoAP Support of Sleepy Node (12)
CoAP proxies can use a previously cached response to service a new GET request for a sleepy origin server (as in HTTP) But if no valid cache then proxy has to attempt to
retrieve and may fail if origin server is sleeping [I-Dietf-core-coap]
Clients can discover list of resources from RD (GET rd-lookuphellip) for sleepy servers But attempt to GET resource from sleepy origin server
may fail if origin server is sleeping [IDietf-core-link-format amp IDshelby-core-resource-
directory]
Current CoAP Support of Sleepy Node (22)
Lower layer support for sleepy nodes in most wireless technologies (eg WiFi ZigBee) But limited to MAC packet scheduling for sleepy nodes
and not aware of specific needs of IP applications (like CoAP)
Proposal ndash RD Based Sleep Tracking (14)
The current CoAP approach to support sleepy nodes can be significantly improved by introducing RD based mechanisms for a CoAP client to determine whether A targeted resource is located on a sleepy server A sleepy server is currently in sleep mode or not
There is any associated caching Proxy (possibly the RD itself) for a sleepy server
Proposal ndash RD Based Sleep Tracking (24)
We define the following new RD attributes to characterize the properties of a sleepy node SleepState - Indicates whether the node is currently in
sleep mode or not (ie Sleeping or Awake) SleepDuration - Indicates the maximum duration of time
that the node stays in sleep mode TimeSleeping - Indicates the length of time the node
has been sleeping (ie if Sleep State = Sleeping) NextSleep - Indicates the next time the node will go to
sleep (ie if Sleep State = Awake)
CachingProxy ndash Indicates the caching proxy of the sleepy node (ie the RD itself or another node)
Proposal ndash RD Based Sleep Tracking (34)
These attributes are all server (node) level and are new parameters added to the RD URI Template Variables
Finally we also define a new lookup-type (ss) for the RD lookup interface specified in [I-Dshelby-core-resource-directory] This new lookup-type supports looking up the
ldquoSleepStaterdquo (ss) of a specified end-point
Proposal ndash RD Based Sleep Tracking (44)
The three time based parameters (SleepDuration TimeSleeping NextSleep) can be based on either an absolute network time (for a time synchronized network) or a relative local time (measured at the local node)
Following the approach of [I-Dietf-core-link-format] and [I-Dshelby-core-resource-directory] sleep parameters for sleepy servers can be stored by the server in the RD and accessed by all interested clients
Examples of using these parameters in a synchronous or asynchronous manner are shown in the I-D
http6lowappnet coreIETF86 2013-03-12-13
We assume people have read the drafts
Meetings serve to advance difficult issues by making good use of face-to-face communications
Note Well Be aware of the IPR principles according to RFC 3979 and its updates
uumlBlue sheetsuumlScribe(s)
96
drar-shy‐iep-shy‐core-shy‐coapsubmiqed13 to13 IESG
2013-shy‐03-shy‐13
97
OMA Lightweight M2M Overview(A new standard using lots of IETF specs including DTLS
CoAP Block Observe Resource Directory SenMLhellip)
Zach ShelbyCoRE WG IETF-86 Orlando
OMA Lightweight M2Mbull Open Mobile Alliance is well known for Device Management (DM)bull OMA Lightweight M2M is a new standard from the alliance
ndash Focused on constrained Cellular and sensor network M2M devicesndash Driven by leading operators and vendors
bull Scopendash Interfaces protocol amp security between Device and Serverndash Object and Resource modelndash Bootstrap Device Access Control Connectivity and Firmware Objects
bull Draft Specifications are availablendash httpmemberopenmobileallianceorgftpPublic_documentsDM
LightweightM2MPermanent_documentsOMA-TS-LightweightM2M-V1_0_0-20130301-Dzip
bull Timelinendash Requirements and Architecture completed 3Q2012ndash Spec ready for Consistency Review 2Q2013ndash Candidate Approval expected 3Q2013
2 CoRE WG IETF-86 Orlando
Architecture
3
Scope of LWM2M
CoRE WG IETF-86 Orlando
Object Model
bull A Client has one or more Object Instancesbull An Object is a collection of Resourcesbull A Resource is an atomic piece of information
ndash Read Written or Executed
bull Resources can have multiple instancesbull Objects and Resources are identified by a
16-bit Integer Instances by an 8-bit Integerbull ObjectsResources are accessed with
simple URIs Object IDObject InstanceResource ID
eg 1213
4 CoRE WG IETF-86 Orlando
CoRE WG IETF-86 Orlando
CoRE Resource Directory
draft-shelby-core-resource-directory-05
Z Shelby C Bormann S Krco
Backgroundbull Not a new concept
ndash think web search engine or any link directorybull Defines the interfaces to a Resource Directorybull Based on Web Linking framework and the CoRE Link Formatbull Generic REST design for use over HTTP and CoAPbull Used by OMA Lightweight M2Mbull Has already been deployed
ndash In traffic monitoring systemsndash In street lighting systemsndash For vehicular asset trackingndash By a major Cellular M2M operator
Changes since -04
bull Restricted Update to parameter updatesbull Added pagination support for the Lookup interfacebull Changed rt= to et= for the registration amp update
interfacebull Added group support
Group Management
bull RD now includes group management featuresbull New Group Function Set
ndash Register a groupbull Group name domain multicast address endpoint members
ndash Remove a groupbull Group lookup using the Lookup Function Set
ndash List registered groupsndash Find the members of a groupndash Find groups with certain endpoints or resources
Registering a Group
EP RD
| |
| - POST rd-groupgp=lights ltgtep=node1 --gt |
| |
| |
| lt---- 201 Created Location rd-group12 ---- |
| |
Req POST coaprdexamplecomrd-groupgp=lights
Payload
ltgtep=node1
ltgtep=node2
Res 201 Created
Location rd-group12
Looking up Group Members
Client RD
| |
| ----- GET rd-lookupepgp=lights1 ----------------------gt |
| |
| |
| lt-- 205 Content ltrdgtd=domain1ltrdgtd=domain2 --------- |
| |
Req GET rd-lookupepgp=lights1
Res 205 Content
ltcoaphostportgtep=node1
ltcoaphostportgtep=node2rdquo
Things for the futurebull Support for JSON representation of Web Links
ndash httptoolsietforgiddraft-bormann-core-links-json-02txtbull Registry for RD registration query parameters
ndash Already OMA Lightweight has defined some new onesbull More examples
Group 3 ldquonew workrdquo(continued)
109
drar-shy‐greevenbosch-shy‐core-shy‐profile-shy‐descripon-shy‐01Bert13 GreevenboschJeroen13 Hoebeke
Isam13 IshaqFloris13 Van13 den13 Abeele
Descripon
bull JSON13 format13 for13 signalling13 the13 servers13 capabilies
bull Signalling13 of13 supported13 opons13 media13 types13 and13 block13 sizendash Other13 items13 can13 be13 added
bull Filtering13 on13 specific13 fields13 through13 URI-shy‐Querybull Link13 hqpdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐profile-shy‐descripon
well-shy‐knownprofile
bull To13 acquire13 profile13 data13 of13 resources13 on13 a13 parcular13 service13 the13 well-shy‐knownprofile13 URI-shy‐path13 is13 introduced
bull For13 example13 to13 get13 all13 informaon13 from13 sensors13 served13 by13 wwwexampleorg13 we13 can13 do13 a13 GET13 to13 coapwwwexampleorgwell-shy‐knownprofile
bull Filtering13 on13 parcular13 resources13 is13 done13 through13 URI-shy‐Queries
Format
bull Currently13 the13 following13 fields13 are13 definedndash ldquopathrdquo13 contains13 the13 URI-shy‐path13 associated13 with13 a13 resource
ndash ldquooprdquo13 a13 numerical13 list13 of13 supported13 opon13 numbers
ndash ldquocfrdquo13 a13 numerical13 list13 of13 supported13 content-shy‐format13 numbers
ndash ldquob1srdquo13 ldquob2srdquo13 supported13 block13 sizes13 for13 Block113 and13 Block213 respecvely
Examplebull On13 the13 right13 is13 an13 example13 of13 a13 camera13 sensor13 at13 coapwwwexampleorgcam13 that13 supports13 the13 Uri-shy‐Host13 (3)13 ETag13 (4)13 Uri-shy‐Port13 (7)13 Uri-shy‐Path13 (11)13 Content-shy‐Format13 (12)13 Token13 (19)13 Block213 (23)13 and13 Proxy-shy‐Uri13 (35)13 opons
bull The13 supported13 content13 formats13 are13 textplain13 (0)13 applicaon13 link-shy‐format13 (40)13 and13 applicaonjson13 (50)
bull The13 supported13 Block213 can13 use13 25613 or13 51213 byte13 blocks
Req13 GET13 coapwwwexampleorgwell-shy‐knownprofile13 Res13 20513 Content13 (applicationjson)13 13 13 13 profile13 13 13 13 13 13 13 13 pathcam13 13 13 13 op[3471112192335]13 13 13 13 13 cf[04050]13 13 13 13 13 b2s[45]13 13 13 13
Filtering13 through13 use13 of13 URI-shy‐Query
bull Filtering13 can13 be13 done13 through13 the13 URI-shy‐Querybull Query13 format13 N=V
ndash N13 is13 a13 profile13 fieldndash V13 is13 the13 desired13 value
bull Examplesndash To13 find13 resources13 that13 support13 content13 format13 ldquoapplicaonjsonrdquo
13 GET13 wwwexampleorgwell-shy‐knownprofilecf=50ndash To13 get13 informaon13 about13 the13 camera
13 GET13 wwwexampleorgwell-shy‐knownprofilepath=cam
Open13 issues
bull Which13 other13 profile13 data13 needs13 signallingndash Content-shy‐type13 for13 different13 methods
bull Fix13 the13 order13 in13 which13 the13 profile13 fields13 must13 appearndash Non-shy‐fixed13 order13 easier13 extensible
bull Inheritance13 of13 a13 profile13 descriponbull Extend13 usage13 to13 signal13 the13 client13 profilebull Integraon13 with13 link13 format
Thank13 youQuesons
drar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval-shy‐00
Bert13 Greevenbosch
Descripon
bull The13 ldquoMinimumRequestInterval13 opon13 can13 be13 used13 to13 indicate13 the13 minimum13 me13 between13 two13 requests13 in13 a13 transacon
bull Originally13 intended13 for13 Block13 but13 also13 usable13 for13 other13 transaconsndash Example13 browsing13 a13 server
bull The13 goal13 is13 to13 reduce13 the13 server13 load13 and13 network13 traffic
bull Link13 hqpsdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval
Usage
bull The13 client13 keeps13 the13 server13 informed13 about13 its13 request13 speed13 through13 inclusion13 of13 the13 ldquoMinimumRequestIntervalrdquo13 opon
bull In13 responses13 the13 server13 fixes13 the13 minimum13 request13 interval13 through13 the13 same13 opon
bull The13 client13 obeys13 the13 speed13 indicated13 by13 the13 server
bull The13 client13 can13 send13 slower13 but13 not13 faster
Advantages
bull The13 server13 has13 means13 to13 limit13 the13 amount13 of13 incoming13 traffic
bull The13 server13 can13 prevent13 to13 become13 overloaded13 with13 too13 many13 tasks
bull The13 server13 does13 not13 need13 arficially13 slow13 down13 the13 client13 by13 sending13 late13 ACKsndash No13 need13 to13 keep13 track13 of13 delayed13 ACKsndash The13 server13 can13 perform13 other13 tasks13 instead
bull Reduced13 network13 traffic
Thank13 youQuesons
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-links-json-02txt
123
RFC 6690 (link-format) documents are somewhat foreign to many web app developerssect would prefer to have them in JSON format
There is no standard way to represent link-format documents in applicationssect but everyone knows how to handle JSON
Define a standard JSON translation for link-format
Itrsquos
not
rock
et
scien
ce
ltsensorsgtct=40title=Sensor Index ltsensorstempgtrt=temperature-cif=sensor ltsensorslightgtrt=light-luxif=sensor lthttpwwwexamplecomsensorst123gt anchor=sensorstemprel=describedby lttgtanchor=sensorstemprel=alternate [hrefsensorsct40titleSensor Index hrefsensorstemprttemperature-cifsensor hrefsensorslightrtlight-luxifsensor hrefhttpwwwexamplecomsensorst123 anchorsensorstempreldescribedby hreftanchorsensorstemprelalternate]
124
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-ipsec-for-coap-00txt
IPsec definitions for CoAP Mostly placeholder at this time Who has implementation experience with this
125
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-cross-reverse-convention-00txt
This draft has two lines of payload(based on a WGLC comment by Cullen Jennings)
coap12344567foobara=3
httpwwwproxycomwellknowncore-translate1234_4567foobara=3
Is that a useful convention to have
126
Insert CI slides here
127
128
0
5
10
15
20
25
30
35
40
10 20 30 40 50 60 70
good
put (
pps)
pps
Goodput vs pps (Econotags)
goodput
[Khattak preliminary]
Congestion Control
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-cocoa-00txt
ldquoadvancedrdquo cc (The draft is just a first shot) Others may have better ideas
129
Insert post-WGLC discussion slides here
130
Stop Continue Start
131
An Agile Retrospective
http6lowappnet coreIETF86 2013-03-12-13
Stop
132
Endless new CoAP optionssect instead use RESTful as much as possible
Move general security lifecycle out Looking at theoretical problems
http6lowappnet coreIETF86 2013-03-12-13
Continue
Interops Running code Look at real-world examples and deployments Solve their actual problems
sect Unilateral enhancements eg higher performance congestion control
sect Transports (SMS hellip)sect Make Web linking and Directories more and more usefulsect RESTful Design Paradigms for real-world problems
133
http6lowappnet coreIETF86 2013-03-12-13
Start
Further push into the (browser) web world (HTML5 browser security)
Specific supporting worksect SenMLsect URI work (dev URN hellip)sect Security Processes (next slide)
Spin outsect (We donrsquot really get to decide where this is done)
134
http6lowappnet coreIETF86 2013-03-12-13
Security
Integrate Application Network Group Keyingsect Tunnel-free setup
Donrsquot redo what has been done alreadysect ZigBee IP is finesect But what about other scenarios
Simple REST interfaces for working with keying materials and authorizationsect Start with defining objectives
Object Security for Constrained Nodes135
Re-chartering CoREWhat do we want to do now that wersquore grown up
Zach ShelbyCoRE WG IETF-86 Orlando
What is the scope
bull So we have a protocol and Web Linking what next
bull Keep with what we know besthellip1 Enhancements around CoAP2 New transports for CoAP3 New representations for Web Links4 General application layer solutions
CoRE WG IETF-86 Orlando 2
Enhancements around CoAP
bull Advanced congestion control
CoRE WG IETF-86 Orlando 3
New Transports for CoAP
bull Infrastructure for CoAP over foondash httptoolsietforgiddraft-silverajan-core-
coap-alternative-transports-01txtbull CoAP over SMS
ndash httptoolsietforgiddraft-becker-core-coap-sms-gprs-03txt
ndash OMA Lightweightbull CoAP over TCP
ndash httptoolsietforgiddraft-li-core-coap-payload-length-option-01txt
CoRE WG IETF-86 Orlando 4
New support for Web Links
bull JSON Web Linksndash httptoolsietforgiddraft-bormann-core-links-
json-02txt
2332010 CoRE WG IETF-77 Anaheim 5
General application layer solutions
bull Resource Directoryndash httptoolsietforgiddraft-shelby-core-
resource-directory-05txtndash OMA Lightweight
2332010 CoRE WG IETF-77 Anaheim 6
Goals of I-D
n For Reverse HTTP-CoAP Cross Protocol Proxyn Provide more detailed information to proxy designers (beyond
Section 10 of [I-Dietf-core-coap]) to help implement proxies that correctly inter-work with other CoAP and HTTP clientserver implementations that adhere to the specifications
n Define a consistent set of guidelines that a HTTP-to-CoAP proxy implementation MAY adhere to The main reason of adhering to such guidelines is to reduce variation between proxy implementations thereby increasing interoperabilityn As an example use case a proxy conforming to these guidelines made
by vendor A can be easily replaced by a proxy from vendor B that also conforms to the guidelines
I-D Outline
n Guidance on HTTP to CoAP URI mappingn HTTP-CoAP Reverse cross-protocol proxy implementation
n Placementn Response code amp media type translationsn Caching and congestion controln Cache refresh via Observen Use of CoAP blockwise transfern Security translation
n Security Considerationsn Traffic overflown Handling secured exchanges
Definitions (12)
n Cross-Protocol Proxy (or Cross Proxy) is a proxy performing a cross- protocol mapping in the context of this document a HTTP-CoAP (HC) mapping A Cross-Protocol Proxy can behave as a Forward Proxy Reverse Proxy or Interception Proxy n Note In this document we focus on the Reverse Proxy mode of the
Cross-Protocol Proxy
n Forward Proxy a message forwarding agent that is selected by the client usually via local configuration rules to receive requests for some type(s) of absolute URI and to attempt to satisfy those requests via translation to the protocol indicated by the absolute URI The user decides (is willing to) use the proxy as the forwardingdereferencing agent for a predefined subset of the URI space
Definitions (22)
n Reverse Proxy a receiving agent that acts as a layer above some other server(s) and translates the received requests to the underlying servers protocol It behaves as an origin (HTTP) server on its connection towards the (HTTP) client and as a (CoAP) client on its connection towards the (CoAP) origin server The (HTTP) client uses the origin-form [I-Dietf-httpbis-p1-messaging] as a request- target URI
n Reverse and Forward proxies are technically very similar with main differences being that the former appears to a client as an origin server while the latter does not and that clients may be unaware they are communicating with a proxy
Reverse Cross-Protocol Proxy Deployment Scenario
HTTP-CoAP Response Code Mapping
Implementation Experience
n Direct experience from the draft authorsn Squid HTTP-CoAP mapping module
n University of Padovan httptelecomdeiunipditiotn Both Forward and Interception operation supported
n HTTP-CoAP proxy based on EvCoAPn KoanLogic University of Bologna and Salvatore
Loreto (as individual)n httpsgithubcomkoanlogicwebthingstreemasterbridgesw
libevcoapn The document is open to input from other implementations
Next Steps
n Does the WG recommend adoptionn Intended status Informational Best Practicen Purpose Reduce arbitrary variation between proxy
implementations thereby increasing interoperability
Backup
HTTP to CoAP URI Mapping Options (12)
n Embedded Mapping n In an embedded mapping approach the HTTP URI has embedded
inside it the authority and path part of the CoAP URI n Example The CoAP resource nodecoapsomethingnetfoo can
be accessed by an HTTP client by inserting in the request httphc-proxysomethingnetcoapnodecoapsomethingnetfoo The Cross-Protocol Proxy then maps the URI to coapnodecoapsomethingnetfoo
HTTP to CoAP URI Mapping Options (22)
n Homogeneous Mapping n In a homogeneous mapping approach only the scheme portion of the URI
needs to be mapped The rest of the URI (ie authority path etc) remains unchanged
n Example The CoAP resource coapnodecoapsomethingnetfoo can be accessed by an HTTP client by requesting httpnodecoapsomethingnetfoo The Cross-Protocol Proxy receiving the request is responsible to map the URI to coapnodecoapsomethingnetfoo
n Background info n The assumption in this case is that the HTTP client would be able to
successfully resolve nodecoapsomethingnet using DNS infrastructure to return the IP address of the HC proxy Most likely this would be through a two step DNS lookup where the first DNS lookup would resolve somethingnet using public DNS infrastructure
n Then the second DNS lookup on the subdomain coap and the host node would typically be resolved by a DNS server operated by the owner of domain somethingnet So this domain owner can manage its own internal node names and subdomain allocation which would correspond to the CoAP namespace
Group 3 ldquonew workrdquo
39
Transport of CoAP over SMS USSD and GPRSdraft-becker-core-coap-sms-gprs-03
Markus Becker Kepeng LiKoojana Kuladinithi Thomas Poumltsch
CoRE WG IETF-86 Orlando
1 10
ScenariosI In M2M communication IP connectivity is not alwayssupported by the constrained end-points
I Power savingI Coverage (GPRS 3G LTE)
I SMS and USSD based communication is almost alwayssupported
210
Changes from draft-01 to draft-03 (1)
I Added possible CONNONACK interactions Section 5
I Option name changed from Reply-To- to Response-To-Section 16 and Section 101
I Added URI schemeEg coap+tel+15105550101well-knowncore Section 11
I Added possible M2M proxy scenarios Section 14
3 10
Changes from draft-01 to draft-03 (2)
I Added reference to bormann-coap-misc for other SMSencoding Section 71
I Updated requirements on Uri-Host and Uri-Port forcoap+tel Section 10
I Added security considerations Transport and ObjectSecurity Section 15
I Chose CoAP option numbers and updated the optionnumber table to meet draft-ietf-core-coap-10 Table 1
I Added an IANA registration for the URI scheme coap+telSection 162
4 10
Feedback Split coap+tel into coap+smsand coap+ussd
I How else to differ the various transports in the URII Or is the transport to use decided by the implementationI See alsodraft-silverajan-core-coap-alternative-transports-01
5 10
Feedback Response-To-Scheme option
I Should there be a Response-To-Scheme optionadditionally to Response-To-Uri-Host andResponse-To-Uri-Path
I So that a CoAP end-point which receives a request by CoAPover non-IP transport can be instructed to also use thenon-IP transport for the response
I This would imply to add aResponse-To-Telephone-Subscriber and more options forother transports that have other URI schemes than coapand coaps
6 10
Feedback Selection of Transport by Client
I When a server is reachable by various transports howdoes a client decide which transport to use
I Client-side application congurationI Leave it to a proxy which uses cellular network lookupfunctions
7 10
Feedback Potential Threats
I Trigger expensive short messagesI Redirect trac to other addressesI More threats
I Are the security measures in the draft adequateI Whitelisting on serverI Relying on cellular network security (dedicated M2M APNs)I Object security on CoAP payload
8 10
Feedback Message Exchanges
I Figures 11-18 show possible message exchanges whenclient and server have two addresses
I With NON Not using CoAP retransmission capabilityI ACK on different transportI Additional (costly) message on Transport AI Request with Content
I Which ones are allowedI Which ones are meaningful
9 10
Next steps
I Rene Uri schemeI Response-To-Scheme optionI Selection of Message ExchangeI Rene Proxying
10 10
CoAP13 Communicaon13 with13 Alternave13 Transports
Bill Silverajan and Teemu SavolainenCore WG IETF 86 Orlando
031113
Objecves13 (In13 Scope)
bull Unambiguous13 representaon13 of13 transport13 to13 be13 used13 by13 CoAP
bull Details13 how13 the13 transport13 can13 carry13 CoAP13 packet
bull Focus13 is13 on13 what13 CoAP13 communicaons13 requirements13 are
bull Allow13 CoAP13 mechanisms13 to13 exploit13 cross-shy‐layer13 opmisaons
51
031113
Non13 Goals13 (Not13 in13 scope)
bull Applicaon-shy‐level13 QoS13 requirementsbull Real-shy‐me13 constraintsbull Ordering13 reliability13 congeson13 controlbull Applicaon13 and13 network13 adaptaonbull Mobility13 and13 readdressing13 supportbull Network13 protocol13 (eg13 IPsec)13 configuraon
52
031113
Use13 Cases
bull NAT13 and13 Firewall13 traversal13 with13 TCPbull Delay13 Tolerant13 Networkingbull Non-shy‐IP13 Low13 Energy13 Protocols
53
031113
Related13 Work
bull OMA13 Lightweight13 M2M13 Protocolbull CoAP13 over13 SMSGPRSUSSD
54
031113
What13 does13 the13 work13 entail
bull The13 ability13 to13 specify13 end13 point13 idenfiers13 and13 URIs13 to13 reflect13 which13 transport13 CoAP13 can13 use
bull The13 ability13 to13 register13 to13 resource13 directories13 resource13 types13 reflecng13 types13 of13 transport13 available
bull Ability13 for13 mul-shy‐transport13 nodes13 to13 select13 transport13 to13 use13 without13 significant13 alteraon13 to13 CoAP13 packet13 structure
55
031113
Points13 to13 consider
bull Requirements13 for13 transport13 layer13 protocol13 to13 carry13 CoAP13 packets
bull Representaon13 of13 URI13 scheme13 for13 generic13 transport13 protocols
bull Opon13 extensions13 for13 CoAP13 to13 express13 available13 transports
bull Mapping13 and13 message13 sizebull Security13 consideraons
56
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
URI13 =13 scheme13 13 13 authority13 path-shy‐abempty13 [13 query13 ]
bull Within13 the13 scheme13 namebull In13 the13 URI13 pathbull As13 a13 query13 component
57
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
bull Within13 the13 scheme13 namendash coap+tel+15105550101well-shy‐knowncorendash coap+tcpexamplecom5683temperaturendash coap+blel2cap[1234567890AB]4pulse
bull Easy13 URI13 parsing13 for13 transport13 type13 and13 idenfier
bull Each13 new13 scheme13 name13 requires13 IANA13 registraon
58
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
bull In13 the13 URI13 pathndash coaphostexamplecomtransport=tcpwell-shy‐knowncorert=core-shy‐rd
bull Easy13 adopon13 of13 new13 (and13 experimental)13 CoAP13 transports13 without13 IANA13 registraon
bull Caveat13 Uri-shy‐Path13 opon13 is13 a13 Crical13 CoAP13 opon13 see13 secon13 54113 of13 I-shy‐Diep-shy‐core-shy‐coap
59
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
bull As13 a13 URI13 query13 componentndash coaphostexamplecomwell-shy‐knowncorert=core-shy‐rdq=tcp
bull Also13 easy13 to13 adopt13 new13 (and13 experimental)13 CoAP13 transports13 without13 IANA13 registraon
bull Caveat13 Uri-shy‐Query13 opon13 is13 a13 Crical13 CoAP13 opon13 see13 secon13 54113 of13 I-shy‐Diep-shy‐core-shy‐coap
60
031113
URI13 Representaons13 for13 CoAPNon13 standard13 ways
bull Transport13 in13 the13 URI13 authority13 componentndash coaphost[port][transport]13 instead13 of13 coaphost[port]
bull Transport13 as13 a13 service13 URLndash servicecoaptcphostexamplecomwell-shy‐knowncorert=core-shy‐rd
bull Above13 two13 ways13 break13 exisng13 compability13 (although13 both13 are13 based13 on13 valid13 IANA13 URI13 registraons)
61
031113
URI13 Representaons13 for13 CoAPMiscellaneous13 Consideraons
bull Ensure13 that13 transport13 is13 defined13 unambiguously13 (eg13 L2CAP13 used13 by13 both13 BLE13 and13 standard13 Bluetooth13 so13 avoid13 rdquocoap+l2caprdquo13 or13 rdquotransport=l2caprdquo13 or13 rdquoq=l2caprdquondash Can13 be13 done13 as13 WG13 consensusndash Namespace13 approach13 eg13 rdquocoap+blel2caprdquo13 or13 rdquoq=blel2caprdquo
bull Allow13 end-shy‐points13 to13 use13 CoAP13 Resource13 Directory13 to13 register13 alternave13 transports13 and13 idenfiers13 and13 provide13 periodic13 updatesndash Register13 rdquocore-shy‐transportrdquo13 resource13 type
62
031113
Transport13 Consideraons
bull Uniqueness13 of13 end-shy‐point13 idenficaonbull Communicaon13 support13 Unidireconal13 Bidireconal13 1N13 (broadcast13 mulcast13 anycast)13 messaging
bull Binary13 encoding13 Network13 byte13 orderingbull MTU13 correlaon13 with13 CoAP13 PDU13 sizebull Transport13 latency
63
031113
Security13 Consideraons
bull Drar13 does13 not13 introduce13 new13 security13 requirements13 by13 itself
bull There13 may13 be13 privacy13 issues13 if13 nodes13 use13 telephone13 numbers13 or13 MAC13 addresses13 as13 public13 end13 point13 idenfiers
64
Akbar Rahman
IETF 86 March 2013 httpwwwietforgiddraft-rahman-core-sleepy-02txt
Enhanced Sleepy Node Support for CoAP
Introduction
It is expected that in CoAP networks there will be a certain portion of devices that are sleepy and which may occasionally go into a sleep mode (ie go into a low power state to conserve power) and subsequently have reduced CoAP protocol communication ability
This I-D proposes a minimal and efficient mechanism building on the Resource Directory concept (which will be integrated into a CoAP Proxy) to enhance sleepy node support in CoAP networks
Main Question from IETF-85 (Atlanta)
What performance benefit does the proposed Sleepy Node support solution give in a network that already has standard CoAP caching enabled
Sleepy Node Performance Analysis
Experimental Network
1-5 clients
Both Sleepy and Non-
Sleepy servers
Sleepy Node Performance Analysis Network Setup
CoAPSleepyServer(s)
CoAPSleepAwareReverseProxy
CoAP
Client(s)
Request
Response
Sleep9AwareCoREResourceDirectoryCapability
PublishedSleepParameters
Sleep9AwareCoAPStoreandForwardCapability Response
Request
SleepAwareCoAP503ResponseCapability
CoAPCachingCapability
bull Server supports publishing sleep parameters to proxy bull Eg Irsquom going to be asleep for X seconds
bull Proxy supports sleep-awareness capabilities bull Proxy also supports caching capability based off of maxAge bull Protocol flow similar to approach of Figure 1 (Synchronous RD Based Sleep
Tracking) of I-D
Proxy capabilities can be selectively enableddisabled
Proxy ndash Server Interface
Client ndash Proxy Interface
CoAP Sleep-Aware Reverse Proxy Features CoRE Sleep-aware Resource Directory
Support storing published sleep parameters from CoAP servers sleepState (AWAKE ASLEEP) sleepDuration
Sleep-aware CoAP 503 Response Capability If CoAP request to a sleeping server is received proxy returns a
lsquo503 Retry-Afterrsquo response to client 503 contains a timestamp indicating when the sever will wake back up
(timestamp delivered in CoAP maxAge option) Sleep-aware CoAP Store-and-Forward Capability
If CoAP request to a sleeping server is received proxy stores request until server wakes up and then forwards it
Caching capability Cache GET responses from server if maxAge option is present
(this is not a sleep aware feature)
Goals of Performance Analysis
For networks having sleepy servers provide measurements to quantify the impact that CoAP sleep-awareness capabilities can have
See if sleep-awareness capabilities can
provide additional benefits even when CoAP caching is used
Overview of Performance Analysis Performed The analysis was broken up into a set of test scenarios Each test scenario used a different combination of the following
variables Client issued GET requests Server was configured as a sleepy or non-sleepy server Proxy caching of GET responses was enabled or disabled Proxy sleep-aware 503 response capability was enabled or disabled Proxy store-and-forward capability was enabled or disabled maxAge in GET responses ndash Two values were tested 60sec and 5sec of Clients ndash Two values were used ndash 1 client and 5 clients
For comparison purposes the following were held constant across all test scenarios Client issued a fixed number of requests (100) across all test scenarios Client used a delay between each GET request (35sec) to better exercise
proxyrsquos caching and sleep-awareness capabilities For sleepy server test scenarios the server slept 60 sec awake for 3 sec
Format of Results The following results were collected for each
test scenario
Breakdown of the and types of transactions occurring between clientproxyserver
ldquoGETrdquo ndash Test Scenario Results
GET ndash Description of Test Scenarios
TestScenarios-GET
Scenario
CoAPSleepyServerSe7ngs CoAPSleepAwareReverseProxySe7ngs CoAPClientSe7ngs
SleepDuragton(sec)
AwakeDuragton(sec)
maxAge(sec) Caching SleepAwareSAF+
503NumberofClients
NumberofGETs
DelayBetweenClient
Requests(sec)
1a 0 Always 60 Enabled Disabled 1 100 35
1b 60 3 60 Enabled Disabled 1 100 35
1c 60 3 60 Enabled Enabled 1 100 35
2a 0 Always 60 Enabled Disabled 5 100 35
2b 60 3 60 Enabled Disabled 5 100 35
2c 60 3 60 Enabled Enabled 5 100 35
3a 0 Always 5 Enabled Disabled 5 100 35
3b 60 3 5 Enabled Disabled 5 100 35
3c 60 3 5 Enabled Enabled 5 100 35
ldquoGETrdquo ndash Test Scenario 1 Results
maxAge = 60 and 1 Client
GET ndash Scenario 1 ClientProxy Interface Transaction Mix
Scenarios 1a - Non-Sleepy Server Caching Proxy maxAge = 60sec 1b- Sleepy Server Caching Proxy maxAge = 60sec 1c - Sleepy Server Sleep Aware Proxy maxAge = 60sec
Sleep Aware Proxy has better performance for sleepy servers
0
100
200
300
400
500
600
700
1a 1b 1c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
GET ndash Scenario 1 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
Scenarios 1a - Non-Sleepy Server Caching Proxy maxAge = 60sec 1b- Sleepy Server Caching Proxy maxAge = 60sec 1c - Sleepy Server Sleep Aware Proxy maxAge = 60sec
0
100
200
300
400
500
600
700
800
1a 1b 1c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
ldquoGETrdquo ndash Test Scenario 2 Results
maxAge = 60 and 5 Clients
GET ndash Scenario 2 ClientProxy Interface Transaction Mix
Sleep Aware Proxy has slightly better performance for sleepy servers
0
200
400
600
800
1000
1200
1400
2a 2b 2c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
Scenarios 2a - Non-Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2b- Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2c - Sleepy Server Sleep Aware Proxy maxAge = 60sec 5 Clients
See ldquoExperimental Artifactsrdquo Note 1
GET ndash Scenario 2 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has slightly better performance for sleepy servers
0
50
100
150
200
250
300
350
400
2a 2b 2c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
Scenarios 2a - Non-Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2b- Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2c - Sleepy Server Sleep Aware Proxy maxAge = 60sec 5 Clients
See ldquoExperimental Artifactsrdquo Note 2
Experimental Artifacts Note 1
Currently in the experiment the sleep aware proxy checks the cached state of a resource before putting a request into its Store-and-forward queue while a server is sleeping Once in the queue the proxy unconditionally forwards the queued requests to the server once it wakes up This is not the most efficient setup and can easily be improved If the proxy instead checks its cache again before forwarding each queued request it may not need to forward the request to the server For example if there are two queued GET requests in the proxyrsquos queue that address the same resource Only the first request needs to be sent to the server the second request can use the cached response from the first request
Note 2 Currently in the experiment the sleepy server sends a sleepState PUT request to the
proxy each time it goes to sleep This is not the most efficient setup and can easily be improved For example if the server assumes that the proxy can keep track of its ONOFF cycles with its internal timers (eg as per Fig 1 of I-D) then the number of messages from the sleepy server dramatically goes down
ldquoGETrdquo ndash Test Scenario 3 Results
maxAge = 5 and 5 Clients
GET ndash Scenario 3 ClientProxy Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
Scenarios 3a - Non-Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3b- Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3c - Sleepy Server Sleep Aware Proxy maxAge = 5sec 5 Clients
0
500
1000
1500
2000
2500
3000
3500
4000
4500
5000
3a 3b 3c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
GET ndash Scenario 3 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
0
1000
2000
3000
4000
5000
6000
7000
3a 3b 3c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
Scenarios 3a - Non-Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3b- Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3c - Sleepy Server Sleep Aware Proxy maxAge = 5sec 5 Clients
Conclusions
Conclusions These results show that sleep-aware CoAP
proxy features can significantly optimize communication with sleepy servers in most scenarios
These results also show that sleep-
awareness capabilities can provide additional benefits above and beyond CoAP caching in most scenarios
Backup
Current CoAP Support of Sleepy Node (12)
CoAP proxies can use a previously cached response to service a new GET request for a sleepy origin server (as in HTTP) But if no valid cache then proxy has to attempt to
retrieve and may fail if origin server is sleeping [I-Dietf-core-coap]
Clients can discover list of resources from RD (GET rd-lookuphellip) for sleepy servers But attempt to GET resource from sleepy origin server
may fail if origin server is sleeping [IDietf-core-link-format amp IDshelby-core-resource-
directory]
Current CoAP Support of Sleepy Node (22)
Lower layer support for sleepy nodes in most wireless technologies (eg WiFi ZigBee) But limited to MAC packet scheduling for sleepy nodes
and not aware of specific needs of IP applications (like CoAP)
Proposal ndash RD Based Sleep Tracking (14)
The current CoAP approach to support sleepy nodes can be significantly improved by introducing RD based mechanisms for a CoAP client to determine whether A targeted resource is located on a sleepy server A sleepy server is currently in sleep mode or not
There is any associated caching Proxy (possibly the RD itself) for a sleepy server
Proposal ndash RD Based Sleep Tracking (24)
We define the following new RD attributes to characterize the properties of a sleepy node SleepState - Indicates whether the node is currently in
sleep mode or not (ie Sleeping or Awake) SleepDuration - Indicates the maximum duration of time
that the node stays in sleep mode TimeSleeping - Indicates the length of time the node
has been sleeping (ie if Sleep State = Sleeping) NextSleep - Indicates the next time the node will go to
sleep (ie if Sleep State = Awake)
CachingProxy ndash Indicates the caching proxy of the sleepy node (ie the RD itself or another node)
Proposal ndash RD Based Sleep Tracking (34)
These attributes are all server (node) level and are new parameters added to the RD URI Template Variables
Finally we also define a new lookup-type (ss) for the RD lookup interface specified in [I-Dshelby-core-resource-directory] This new lookup-type supports looking up the
ldquoSleepStaterdquo (ss) of a specified end-point
Proposal ndash RD Based Sleep Tracking (44)
The three time based parameters (SleepDuration TimeSleeping NextSleep) can be based on either an absolute network time (for a time synchronized network) or a relative local time (measured at the local node)
Following the approach of [I-Dietf-core-link-format] and [I-Dshelby-core-resource-directory] sleep parameters for sleepy servers can be stored by the server in the RD and accessed by all interested clients
Examples of using these parameters in a synchronous or asynchronous manner are shown in the I-D
http6lowappnet coreIETF86 2013-03-12-13
We assume people have read the drafts
Meetings serve to advance difficult issues by making good use of face-to-face communications
Note Well Be aware of the IPR principles according to RFC 3979 and its updates
uumlBlue sheetsuumlScribe(s)
96
drar-shy‐iep-shy‐core-shy‐coapsubmiqed13 to13 IESG
2013-shy‐03-shy‐13
97
OMA Lightweight M2M Overview(A new standard using lots of IETF specs including DTLS
CoAP Block Observe Resource Directory SenMLhellip)
Zach ShelbyCoRE WG IETF-86 Orlando
OMA Lightweight M2Mbull Open Mobile Alliance is well known for Device Management (DM)bull OMA Lightweight M2M is a new standard from the alliance
ndash Focused on constrained Cellular and sensor network M2M devicesndash Driven by leading operators and vendors
bull Scopendash Interfaces protocol amp security between Device and Serverndash Object and Resource modelndash Bootstrap Device Access Control Connectivity and Firmware Objects
bull Draft Specifications are availablendash httpmemberopenmobileallianceorgftpPublic_documentsDM
LightweightM2MPermanent_documentsOMA-TS-LightweightM2M-V1_0_0-20130301-Dzip
bull Timelinendash Requirements and Architecture completed 3Q2012ndash Spec ready for Consistency Review 2Q2013ndash Candidate Approval expected 3Q2013
2 CoRE WG IETF-86 Orlando
Architecture
3
Scope of LWM2M
CoRE WG IETF-86 Orlando
Object Model
bull A Client has one or more Object Instancesbull An Object is a collection of Resourcesbull A Resource is an atomic piece of information
ndash Read Written or Executed
bull Resources can have multiple instancesbull Objects and Resources are identified by a
16-bit Integer Instances by an 8-bit Integerbull ObjectsResources are accessed with
simple URIs Object IDObject InstanceResource ID
eg 1213
4 CoRE WG IETF-86 Orlando
CoRE WG IETF-86 Orlando
CoRE Resource Directory
draft-shelby-core-resource-directory-05
Z Shelby C Bormann S Krco
Backgroundbull Not a new concept
ndash think web search engine or any link directorybull Defines the interfaces to a Resource Directorybull Based on Web Linking framework and the CoRE Link Formatbull Generic REST design for use over HTTP and CoAPbull Used by OMA Lightweight M2Mbull Has already been deployed
ndash In traffic monitoring systemsndash In street lighting systemsndash For vehicular asset trackingndash By a major Cellular M2M operator
Changes since -04
bull Restricted Update to parameter updatesbull Added pagination support for the Lookup interfacebull Changed rt= to et= for the registration amp update
interfacebull Added group support
Group Management
bull RD now includes group management featuresbull New Group Function Set
ndash Register a groupbull Group name domain multicast address endpoint members
ndash Remove a groupbull Group lookup using the Lookup Function Set
ndash List registered groupsndash Find the members of a groupndash Find groups with certain endpoints or resources
Registering a Group
EP RD
| |
| - POST rd-groupgp=lights ltgtep=node1 --gt |
| |
| |
| lt---- 201 Created Location rd-group12 ---- |
| |
Req POST coaprdexamplecomrd-groupgp=lights
Payload
ltgtep=node1
ltgtep=node2
Res 201 Created
Location rd-group12
Looking up Group Members
Client RD
| |
| ----- GET rd-lookupepgp=lights1 ----------------------gt |
| |
| |
| lt-- 205 Content ltrdgtd=domain1ltrdgtd=domain2 --------- |
| |
Req GET rd-lookupepgp=lights1
Res 205 Content
ltcoaphostportgtep=node1
ltcoaphostportgtep=node2rdquo
Things for the futurebull Support for JSON representation of Web Links
ndash httptoolsietforgiddraft-bormann-core-links-json-02txtbull Registry for RD registration query parameters
ndash Already OMA Lightweight has defined some new onesbull More examples
Group 3 ldquonew workrdquo(continued)
109
drar-shy‐greevenbosch-shy‐core-shy‐profile-shy‐descripon-shy‐01Bert13 GreevenboschJeroen13 Hoebeke
Isam13 IshaqFloris13 Van13 den13 Abeele
Descripon
bull JSON13 format13 for13 signalling13 the13 servers13 capabilies
bull Signalling13 of13 supported13 opons13 media13 types13 and13 block13 sizendash Other13 items13 can13 be13 added
bull Filtering13 on13 specific13 fields13 through13 URI-shy‐Querybull Link13 hqpdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐profile-shy‐descripon
well-shy‐knownprofile
bull To13 acquire13 profile13 data13 of13 resources13 on13 a13 parcular13 service13 the13 well-shy‐knownprofile13 URI-shy‐path13 is13 introduced
bull For13 example13 to13 get13 all13 informaon13 from13 sensors13 served13 by13 wwwexampleorg13 we13 can13 do13 a13 GET13 to13 coapwwwexampleorgwell-shy‐knownprofile
bull Filtering13 on13 parcular13 resources13 is13 done13 through13 URI-shy‐Queries
Format
bull Currently13 the13 following13 fields13 are13 definedndash ldquopathrdquo13 contains13 the13 URI-shy‐path13 associated13 with13 a13 resource
ndash ldquooprdquo13 a13 numerical13 list13 of13 supported13 opon13 numbers
ndash ldquocfrdquo13 a13 numerical13 list13 of13 supported13 content-shy‐format13 numbers
ndash ldquob1srdquo13 ldquob2srdquo13 supported13 block13 sizes13 for13 Block113 and13 Block213 respecvely
Examplebull On13 the13 right13 is13 an13 example13 of13 a13 camera13 sensor13 at13 coapwwwexampleorgcam13 that13 supports13 the13 Uri-shy‐Host13 (3)13 ETag13 (4)13 Uri-shy‐Port13 (7)13 Uri-shy‐Path13 (11)13 Content-shy‐Format13 (12)13 Token13 (19)13 Block213 (23)13 and13 Proxy-shy‐Uri13 (35)13 opons
bull The13 supported13 content13 formats13 are13 textplain13 (0)13 applicaon13 link-shy‐format13 (40)13 and13 applicaonjson13 (50)
bull The13 supported13 Block213 can13 use13 25613 or13 51213 byte13 blocks
Req13 GET13 coapwwwexampleorgwell-shy‐knownprofile13 Res13 20513 Content13 (applicationjson)13 13 13 13 profile13 13 13 13 13 13 13 13 pathcam13 13 13 13 op[3471112192335]13 13 13 13 13 cf[04050]13 13 13 13 13 b2s[45]13 13 13 13
Filtering13 through13 use13 of13 URI-shy‐Query
bull Filtering13 can13 be13 done13 through13 the13 URI-shy‐Querybull Query13 format13 N=V
ndash N13 is13 a13 profile13 fieldndash V13 is13 the13 desired13 value
bull Examplesndash To13 find13 resources13 that13 support13 content13 format13 ldquoapplicaonjsonrdquo
13 GET13 wwwexampleorgwell-shy‐knownprofilecf=50ndash To13 get13 informaon13 about13 the13 camera
13 GET13 wwwexampleorgwell-shy‐knownprofilepath=cam
Open13 issues
bull Which13 other13 profile13 data13 needs13 signallingndash Content-shy‐type13 for13 different13 methods
bull Fix13 the13 order13 in13 which13 the13 profile13 fields13 must13 appearndash Non-shy‐fixed13 order13 easier13 extensible
bull Inheritance13 of13 a13 profile13 descriponbull Extend13 usage13 to13 signal13 the13 client13 profilebull Integraon13 with13 link13 format
Thank13 youQuesons
drar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval-shy‐00
Bert13 Greevenbosch
Descripon
bull The13 ldquoMinimumRequestInterval13 opon13 can13 be13 used13 to13 indicate13 the13 minimum13 me13 between13 two13 requests13 in13 a13 transacon
bull Originally13 intended13 for13 Block13 but13 also13 usable13 for13 other13 transaconsndash Example13 browsing13 a13 server
bull The13 goal13 is13 to13 reduce13 the13 server13 load13 and13 network13 traffic
bull Link13 hqpsdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval
Usage
bull The13 client13 keeps13 the13 server13 informed13 about13 its13 request13 speed13 through13 inclusion13 of13 the13 ldquoMinimumRequestIntervalrdquo13 opon
bull In13 responses13 the13 server13 fixes13 the13 minimum13 request13 interval13 through13 the13 same13 opon
bull The13 client13 obeys13 the13 speed13 indicated13 by13 the13 server
bull The13 client13 can13 send13 slower13 but13 not13 faster
Advantages
bull The13 server13 has13 means13 to13 limit13 the13 amount13 of13 incoming13 traffic
bull The13 server13 can13 prevent13 to13 become13 overloaded13 with13 too13 many13 tasks
bull The13 server13 does13 not13 need13 arficially13 slow13 down13 the13 client13 by13 sending13 late13 ACKsndash No13 need13 to13 keep13 track13 of13 delayed13 ACKsndash The13 server13 can13 perform13 other13 tasks13 instead
bull Reduced13 network13 traffic
Thank13 youQuesons
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-links-json-02txt
123
RFC 6690 (link-format) documents are somewhat foreign to many web app developerssect would prefer to have them in JSON format
There is no standard way to represent link-format documents in applicationssect but everyone knows how to handle JSON
Define a standard JSON translation for link-format
Itrsquos
not
rock
et
scien
ce
ltsensorsgtct=40title=Sensor Index ltsensorstempgtrt=temperature-cif=sensor ltsensorslightgtrt=light-luxif=sensor lthttpwwwexamplecomsensorst123gt anchor=sensorstemprel=describedby lttgtanchor=sensorstemprel=alternate [hrefsensorsct40titleSensor Index hrefsensorstemprttemperature-cifsensor hrefsensorslightrtlight-luxifsensor hrefhttpwwwexamplecomsensorst123 anchorsensorstempreldescribedby hreftanchorsensorstemprelalternate]
124
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-ipsec-for-coap-00txt
IPsec definitions for CoAP Mostly placeholder at this time Who has implementation experience with this
125
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-cross-reverse-convention-00txt
This draft has two lines of payload(based on a WGLC comment by Cullen Jennings)
coap12344567foobara=3
httpwwwproxycomwellknowncore-translate1234_4567foobara=3
Is that a useful convention to have
126
Insert CI slides here
127
128
0
5
10
15
20
25
30
35
40
10 20 30 40 50 60 70
good
put (
pps)
pps
Goodput vs pps (Econotags)
goodput
[Khattak preliminary]
Congestion Control
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-cocoa-00txt
ldquoadvancedrdquo cc (The draft is just a first shot) Others may have better ideas
129
Insert post-WGLC discussion slides here
130
Stop Continue Start
131
An Agile Retrospective
http6lowappnet coreIETF86 2013-03-12-13
Stop
132
Endless new CoAP optionssect instead use RESTful as much as possible
Move general security lifecycle out Looking at theoretical problems
http6lowappnet coreIETF86 2013-03-12-13
Continue
Interops Running code Look at real-world examples and deployments Solve their actual problems
sect Unilateral enhancements eg higher performance congestion control
sect Transports (SMS hellip)sect Make Web linking and Directories more and more usefulsect RESTful Design Paradigms for real-world problems
133
http6lowappnet coreIETF86 2013-03-12-13
Start
Further push into the (browser) web world (HTML5 browser security)
Specific supporting worksect SenMLsect URI work (dev URN hellip)sect Security Processes (next slide)
Spin outsect (We donrsquot really get to decide where this is done)
134
http6lowappnet coreIETF86 2013-03-12-13
Security
Integrate Application Network Group Keyingsect Tunnel-free setup
Donrsquot redo what has been done alreadysect ZigBee IP is finesect But what about other scenarios
Simple REST interfaces for working with keying materials and authorizationsect Start with defining objectives
Object Security for Constrained Nodes135
Re-chartering CoREWhat do we want to do now that wersquore grown up
Zach ShelbyCoRE WG IETF-86 Orlando
What is the scope
bull So we have a protocol and Web Linking what next
bull Keep with what we know besthellip1 Enhancements around CoAP2 New transports for CoAP3 New representations for Web Links4 General application layer solutions
CoRE WG IETF-86 Orlando 2
Enhancements around CoAP
bull Advanced congestion control
CoRE WG IETF-86 Orlando 3
New Transports for CoAP
bull Infrastructure for CoAP over foondash httptoolsietforgiddraft-silverajan-core-
coap-alternative-transports-01txtbull CoAP over SMS
ndash httptoolsietforgiddraft-becker-core-coap-sms-gprs-03txt
ndash OMA Lightweightbull CoAP over TCP
ndash httptoolsietforgiddraft-li-core-coap-payload-length-option-01txt
CoRE WG IETF-86 Orlando 4
New support for Web Links
bull JSON Web Linksndash httptoolsietforgiddraft-bormann-core-links-
json-02txt
2332010 CoRE WG IETF-77 Anaheim 5
General application layer solutions
bull Resource Directoryndash httptoolsietforgiddraft-shelby-core-
resource-directory-05txtndash OMA Lightweight
2332010 CoRE WG IETF-77 Anaheim 6
I-D Outline
n Guidance on HTTP to CoAP URI mappingn HTTP-CoAP Reverse cross-protocol proxy implementation
n Placementn Response code amp media type translationsn Caching and congestion controln Cache refresh via Observen Use of CoAP blockwise transfern Security translation
n Security Considerationsn Traffic overflown Handling secured exchanges
Definitions (12)
n Cross-Protocol Proxy (or Cross Proxy) is a proxy performing a cross- protocol mapping in the context of this document a HTTP-CoAP (HC) mapping A Cross-Protocol Proxy can behave as a Forward Proxy Reverse Proxy or Interception Proxy n Note In this document we focus on the Reverse Proxy mode of the
Cross-Protocol Proxy
n Forward Proxy a message forwarding agent that is selected by the client usually via local configuration rules to receive requests for some type(s) of absolute URI and to attempt to satisfy those requests via translation to the protocol indicated by the absolute URI The user decides (is willing to) use the proxy as the forwardingdereferencing agent for a predefined subset of the URI space
Definitions (22)
n Reverse Proxy a receiving agent that acts as a layer above some other server(s) and translates the received requests to the underlying servers protocol It behaves as an origin (HTTP) server on its connection towards the (HTTP) client and as a (CoAP) client on its connection towards the (CoAP) origin server The (HTTP) client uses the origin-form [I-Dietf-httpbis-p1-messaging] as a request- target URI
n Reverse and Forward proxies are technically very similar with main differences being that the former appears to a client as an origin server while the latter does not and that clients may be unaware they are communicating with a proxy
Reverse Cross-Protocol Proxy Deployment Scenario
HTTP-CoAP Response Code Mapping
Implementation Experience
n Direct experience from the draft authorsn Squid HTTP-CoAP mapping module
n University of Padovan httptelecomdeiunipditiotn Both Forward and Interception operation supported
n HTTP-CoAP proxy based on EvCoAPn KoanLogic University of Bologna and Salvatore
Loreto (as individual)n httpsgithubcomkoanlogicwebthingstreemasterbridgesw
libevcoapn The document is open to input from other implementations
Next Steps
n Does the WG recommend adoptionn Intended status Informational Best Practicen Purpose Reduce arbitrary variation between proxy
implementations thereby increasing interoperability
Backup
HTTP to CoAP URI Mapping Options (12)
n Embedded Mapping n In an embedded mapping approach the HTTP URI has embedded
inside it the authority and path part of the CoAP URI n Example The CoAP resource nodecoapsomethingnetfoo can
be accessed by an HTTP client by inserting in the request httphc-proxysomethingnetcoapnodecoapsomethingnetfoo The Cross-Protocol Proxy then maps the URI to coapnodecoapsomethingnetfoo
HTTP to CoAP URI Mapping Options (22)
n Homogeneous Mapping n In a homogeneous mapping approach only the scheme portion of the URI
needs to be mapped The rest of the URI (ie authority path etc) remains unchanged
n Example The CoAP resource coapnodecoapsomethingnetfoo can be accessed by an HTTP client by requesting httpnodecoapsomethingnetfoo The Cross-Protocol Proxy receiving the request is responsible to map the URI to coapnodecoapsomethingnetfoo
n Background info n The assumption in this case is that the HTTP client would be able to
successfully resolve nodecoapsomethingnet using DNS infrastructure to return the IP address of the HC proxy Most likely this would be through a two step DNS lookup where the first DNS lookup would resolve somethingnet using public DNS infrastructure
n Then the second DNS lookup on the subdomain coap and the host node would typically be resolved by a DNS server operated by the owner of domain somethingnet So this domain owner can manage its own internal node names and subdomain allocation which would correspond to the CoAP namespace
Group 3 ldquonew workrdquo
39
Transport of CoAP over SMS USSD and GPRSdraft-becker-core-coap-sms-gprs-03
Markus Becker Kepeng LiKoojana Kuladinithi Thomas Poumltsch
CoRE WG IETF-86 Orlando
1 10
ScenariosI In M2M communication IP connectivity is not alwayssupported by the constrained end-points
I Power savingI Coverage (GPRS 3G LTE)
I SMS and USSD based communication is almost alwayssupported
210
Changes from draft-01 to draft-03 (1)
I Added possible CONNONACK interactions Section 5
I Option name changed from Reply-To- to Response-To-Section 16 and Section 101
I Added URI schemeEg coap+tel+15105550101well-knowncore Section 11
I Added possible M2M proxy scenarios Section 14
3 10
Changes from draft-01 to draft-03 (2)
I Added reference to bormann-coap-misc for other SMSencoding Section 71
I Updated requirements on Uri-Host and Uri-Port forcoap+tel Section 10
I Added security considerations Transport and ObjectSecurity Section 15
I Chose CoAP option numbers and updated the optionnumber table to meet draft-ietf-core-coap-10 Table 1
I Added an IANA registration for the URI scheme coap+telSection 162
4 10
Feedback Split coap+tel into coap+smsand coap+ussd
I How else to differ the various transports in the URII Or is the transport to use decided by the implementationI See alsodraft-silverajan-core-coap-alternative-transports-01
5 10
Feedback Response-To-Scheme option
I Should there be a Response-To-Scheme optionadditionally to Response-To-Uri-Host andResponse-To-Uri-Path
I So that a CoAP end-point which receives a request by CoAPover non-IP transport can be instructed to also use thenon-IP transport for the response
I This would imply to add aResponse-To-Telephone-Subscriber and more options forother transports that have other URI schemes than coapand coaps
6 10
Feedback Selection of Transport by Client
I When a server is reachable by various transports howdoes a client decide which transport to use
I Client-side application congurationI Leave it to a proxy which uses cellular network lookupfunctions
7 10
Feedback Potential Threats
I Trigger expensive short messagesI Redirect trac to other addressesI More threats
I Are the security measures in the draft adequateI Whitelisting on serverI Relying on cellular network security (dedicated M2M APNs)I Object security on CoAP payload
8 10
Feedback Message Exchanges
I Figures 11-18 show possible message exchanges whenclient and server have two addresses
I With NON Not using CoAP retransmission capabilityI ACK on different transportI Additional (costly) message on Transport AI Request with Content
I Which ones are allowedI Which ones are meaningful
9 10
Next steps
I Rene Uri schemeI Response-To-Scheme optionI Selection of Message ExchangeI Rene Proxying
10 10
CoAP13 Communicaon13 with13 Alternave13 Transports
Bill Silverajan and Teemu SavolainenCore WG IETF 86 Orlando
031113
Objecves13 (In13 Scope)
bull Unambiguous13 representaon13 of13 transport13 to13 be13 used13 by13 CoAP
bull Details13 how13 the13 transport13 can13 carry13 CoAP13 packet
bull Focus13 is13 on13 what13 CoAP13 communicaons13 requirements13 are
bull Allow13 CoAP13 mechanisms13 to13 exploit13 cross-shy‐layer13 opmisaons
51
031113
Non13 Goals13 (Not13 in13 scope)
bull Applicaon-shy‐level13 QoS13 requirementsbull Real-shy‐me13 constraintsbull Ordering13 reliability13 congeson13 controlbull Applicaon13 and13 network13 adaptaonbull Mobility13 and13 readdressing13 supportbull Network13 protocol13 (eg13 IPsec)13 configuraon
52
031113
Use13 Cases
bull NAT13 and13 Firewall13 traversal13 with13 TCPbull Delay13 Tolerant13 Networkingbull Non-shy‐IP13 Low13 Energy13 Protocols
53
031113
Related13 Work
bull OMA13 Lightweight13 M2M13 Protocolbull CoAP13 over13 SMSGPRSUSSD
54
031113
What13 does13 the13 work13 entail
bull The13 ability13 to13 specify13 end13 point13 idenfiers13 and13 URIs13 to13 reflect13 which13 transport13 CoAP13 can13 use
bull The13 ability13 to13 register13 to13 resource13 directories13 resource13 types13 reflecng13 types13 of13 transport13 available
bull Ability13 for13 mul-shy‐transport13 nodes13 to13 select13 transport13 to13 use13 without13 significant13 alteraon13 to13 CoAP13 packet13 structure
55
031113
Points13 to13 consider
bull Requirements13 for13 transport13 layer13 protocol13 to13 carry13 CoAP13 packets
bull Representaon13 of13 URI13 scheme13 for13 generic13 transport13 protocols
bull Opon13 extensions13 for13 CoAP13 to13 express13 available13 transports
bull Mapping13 and13 message13 sizebull Security13 consideraons
56
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
URI13 =13 scheme13 13 13 authority13 path-shy‐abempty13 [13 query13 ]
bull Within13 the13 scheme13 namebull In13 the13 URI13 pathbull As13 a13 query13 component
57
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
bull Within13 the13 scheme13 namendash coap+tel+15105550101well-shy‐knowncorendash coap+tcpexamplecom5683temperaturendash coap+blel2cap[1234567890AB]4pulse
bull Easy13 URI13 parsing13 for13 transport13 type13 and13 idenfier
bull Each13 new13 scheme13 name13 requires13 IANA13 registraon
58
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
bull In13 the13 URI13 pathndash coaphostexamplecomtransport=tcpwell-shy‐knowncorert=core-shy‐rd
bull Easy13 adopon13 of13 new13 (and13 experimental)13 CoAP13 transports13 without13 IANA13 registraon
bull Caveat13 Uri-shy‐Path13 opon13 is13 a13 Crical13 CoAP13 opon13 see13 secon13 54113 of13 I-shy‐Diep-shy‐core-shy‐coap
59
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
bull As13 a13 URI13 query13 componentndash coaphostexamplecomwell-shy‐knowncorert=core-shy‐rdq=tcp
bull Also13 easy13 to13 adopt13 new13 (and13 experimental)13 CoAP13 transports13 without13 IANA13 registraon
bull Caveat13 Uri-shy‐Query13 opon13 is13 a13 Crical13 CoAP13 opon13 see13 secon13 54113 of13 I-shy‐Diep-shy‐core-shy‐coap
60
031113
URI13 Representaons13 for13 CoAPNon13 standard13 ways
bull Transport13 in13 the13 URI13 authority13 componentndash coaphost[port][transport]13 instead13 of13 coaphost[port]
bull Transport13 as13 a13 service13 URLndash servicecoaptcphostexamplecomwell-shy‐knowncorert=core-shy‐rd
bull Above13 two13 ways13 break13 exisng13 compability13 (although13 both13 are13 based13 on13 valid13 IANA13 URI13 registraons)
61
031113
URI13 Representaons13 for13 CoAPMiscellaneous13 Consideraons
bull Ensure13 that13 transport13 is13 defined13 unambiguously13 (eg13 L2CAP13 used13 by13 both13 BLE13 and13 standard13 Bluetooth13 so13 avoid13 rdquocoap+l2caprdquo13 or13 rdquotransport=l2caprdquo13 or13 rdquoq=l2caprdquondash Can13 be13 done13 as13 WG13 consensusndash Namespace13 approach13 eg13 rdquocoap+blel2caprdquo13 or13 rdquoq=blel2caprdquo
bull Allow13 end-shy‐points13 to13 use13 CoAP13 Resource13 Directory13 to13 register13 alternave13 transports13 and13 idenfiers13 and13 provide13 periodic13 updatesndash Register13 rdquocore-shy‐transportrdquo13 resource13 type
62
031113
Transport13 Consideraons
bull Uniqueness13 of13 end-shy‐point13 idenficaonbull Communicaon13 support13 Unidireconal13 Bidireconal13 1N13 (broadcast13 mulcast13 anycast)13 messaging
bull Binary13 encoding13 Network13 byte13 orderingbull MTU13 correlaon13 with13 CoAP13 PDU13 sizebull Transport13 latency
63
031113
Security13 Consideraons
bull Drar13 does13 not13 introduce13 new13 security13 requirements13 by13 itself
bull There13 may13 be13 privacy13 issues13 if13 nodes13 use13 telephone13 numbers13 or13 MAC13 addresses13 as13 public13 end13 point13 idenfiers
64
Akbar Rahman
IETF 86 March 2013 httpwwwietforgiddraft-rahman-core-sleepy-02txt
Enhanced Sleepy Node Support for CoAP
Introduction
It is expected that in CoAP networks there will be a certain portion of devices that are sleepy and which may occasionally go into a sleep mode (ie go into a low power state to conserve power) and subsequently have reduced CoAP protocol communication ability
This I-D proposes a minimal and efficient mechanism building on the Resource Directory concept (which will be integrated into a CoAP Proxy) to enhance sleepy node support in CoAP networks
Main Question from IETF-85 (Atlanta)
What performance benefit does the proposed Sleepy Node support solution give in a network that already has standard CoAP caching enabled
Sleepy Node Performance Analysis
Experimental Network
1-5 clients
Both Sleepy and Non-
Sleepy servers
Sleepy Node Performance Analysis Network Setup
CoAPSleepyServer(s)
CoAPSleepAwareReverseProxy
CoAP
Client(s)
Request
Response
Sleep9AwareCoREResourceDirectoryCapability
PublishedSleepParameters
Sleep9AwareCoAPStoreandForwardCapability Response
Request
SleepAwareCoAP503ResponseCapability
CoAPCachingCapability
bull Server supports publishing sleep parameters to proxy bull Eg Irsquom going to be asleep for X seconds
bull Proxy supports sleep-awareness capabilities bull Proxy also supports caching capability based off of maxAge bull Protocol flow similar to approach of Figure 1 (Synchronous RD Based Sleep
Tracking) of I-D
Proxy capabilities can be selectively enableddisabled
Proxy ndash Server Interface
Client ndash Proxy Interface
CoAP Sleep-Aware Reverse Proxy Features CoRE Sleep-aware Resource Directory
Support storing published sleep parameters from CoAP servers sleepState (AWAKE ASLEEP) sleepDuration
Sleep-aware CoAP 503 Response Capability If CoAP request to a sleeping server is received proxy returns a
lsquo503 Retry-Afterrsquo response to client 503 contains a timestamp indicating when the sever will wake back up
(timestamp delivered in CoAP maxAge option) Sleep-aware CoAP Store-and-Forward Capability
If CoAP request to a sleeping server is received proxy stores request until server wakes up and then forwards it
Caching capability Cache GET responses from server if maxAge option is present
(this is not a sleep aware feature)
Goals of Performance Analysis
For networks having sleepy servers provide measurements to quantify the impact that CoAP sleep-awareness capabilities can have
See if sleep-awareness capabilities can
provide additional benefits even when CoAP caching is used
Overview of Performance Analysis Performed The analysis was broken up into a set of test scenarios Each test scenario used a different combination of the following
variables Client issued GET requests Server was configured as a sleepy or non-sleepy server Proxy caching of GET responses was enabled or disabled Proxy sleep-aware 503 response capability was enabled or disabled Proxy store-and-forward capability was enabled or disabled maxAge in GET responses ndash Two values were tested 60sec and 5sec of Clients ndash Two values were used ndash 1 client and 5 clients
For comparison purposes the following were held constant across all test scenarios Client issued a fixed number of requests (100) across all test scenarios Client used a delay between each GET request (35sec) to better exercise
proxyrsquos caching and sleep-awareness capabilities For sleepy server test scenarios the server slept 60 sec awake for 3 sec
Format of Results The following results were collected for each
test scenario
Breakdown of the and types of transactions occurring between clientproxyserver
ldquoGETrdquo ndash Test Scenario Results
GET ndash Description of Test Scenarios
TestScenarios-GET
Scenario
CoAPSleepyServerSe7ngs CoAPSleepAwareReverseProxySe7ngs CoAPClientSe7ngs
SleepDuragton(sec)
AwakeDuragton(sec)
maxAge(sec) Caching SleepAwareSAF+
503NumberofClients
NumberofGETs
DelayBetweenClient
Requests(sec)
1a 0 Always 60 Enabled Disabled 1 100 35
1b 60 3 60 Enabled Disabled 1 100 35
1c 60 3 60 Enabled Enabled 1 100 35
2a 0 Always 60 Enabled Disabled 5 100 35
2b 60 3 60 Enabled Disabled 5 100 35
2c 60 3 60 Enabled Enabled 5 100 35
3a 0 Always 5 Enabled Disabled 5 100 35
3b 60 3 5 Enabled Disabled 5 100 35
3c 60 3 5 Enabled Enabled 5 100 35
ldquoGETrdquo ndash Test Scenario 1 Results
maxAge = 60 and 1 Client
GET ndash Scenario 1 ClientProxy Interface Transaction Mix
Scenarios 1a - Non-Sleepy Server Caching Proxy maxAge = 60sec 1b- Sleepy Server Caching Proxy maxAge = 60sec 1c - Sleepy Server Sleep Aware Proxy maxAge = 60sec
Sleep Aware Proxy has better performance for sleepy servers
0
100
200
300
400
500
600
700
1a 1b 1c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
GET ndash Scenario 1 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
Scenarios 1a - Non-Sleepy Server Caching Proxy maxAge = 60sec 1b- Sleepy Server Caching Proxy maxAge = 60sec 1c - Sleepy Server Sleep Aware Proxy maxAge = 60sec
0
100
200
300
400
500
600
700
800
1a 1b 1c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
ldquoGETrdquo ndash Test Scenario 2 Results
maxAge = 60 and 5 Clients
GET ndash Scenario 2 ClientProxy Interface Transaction Mix
Sleep Aware Proxy has slightly better performance for sleepy servers
0
200
400
600
800
1000
1200
1400
2a 2b 2c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
Scenarios 2a - Non-Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2b- Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2c - Sleepy Server Sleep Aware Proxy maxAge = 60sec 5 Clients
See ldquoExperimental Artifactsrdquo Note 1
GET ndash Scenario 2 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has slightly better performance for sleepy servers
0
50
100
150
200
250
300
350
400
2a 2b 2c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
Scenarios 2a - Non-Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2b- Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2c - Sleepy Server Sleep Aware Proxy maxAge = 60sec 5 Clients
See ldquoExperimental Artifactsrdquo Note 2
Experimental Artifacts Note 1
Currently in the experiment the sleep aware proxy checks the cached state of a resource before putting a request into its Store-and-forward queue while a server is sleeping Once in the queue the proxy unconditionally forwards the queued requests to the server once it wakes up This is not the most efficient setup and can easily be improved If the proxy instead checks its cache again before forwarding each queued request it may not need to forward the request to the server For example if there are two queued GET requests in the proxyrsquos queue that address the same resource Only the first request needs to be sent to the server the second request can use the cached response from the first request
Note 2 Currently in the experiment the sleepy server sends a sleepState PUT request to the
proxy each time it goes to sleep This is not the most efficient setup and can easily be improved For example if the server assumes that the proxy can keep track of its ONOFF cycles with its internal timers (eg as per Fig 1 of I-D) then the number of messages from the sleepy server dramatically goes down
ldquoGETrdquo ndash Test Scenario 3 Results
maxAge = 5 and 5 Clients
GET ndash Scenario 3 ClientProxy Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
Scenarios 3a - Non-Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3b- Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3c - Sleepy Server Sleep Aware Proxy maxAge = 5sec 5 Clients
0
500
1000
1500
2000
2500
3000
3500
4000
4500
5000
3a 3b 3c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
GET ndash Scenario 3 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
0
1000
2000
3000
4000
5000
6000
7000
3a 3b 3c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
Scenarios 3a - Non-Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3b- Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3c - Sleepy Server Sleep Aware Proxy maxAge = 5sec 5 Clients
Conclusions
Conclusions These results show that sleep-aware CoAP
proxy features can significantly optimize communication with sleepy servers in most scenarios
These results also show that sleep-
awareness capabilities can provide additional benefits above and beyond CoAP caching in most scenarios
Backup
Current CoAP Support of Sleepy Node (12)
CoAP proxies can use a previously cached response to service a new GET request for a sleepy origin server (as in HTTP) But if no valid cache then proxy has to attempt to
retrieve and may fail if origin server is sleeping [I-Dietf-core-coap]
Clients can discover list of resources from RD (GET rd-lookuphellip) for sleepy servers But attempt to GET resource from sleepy origin server
may fail if origin server is sleeping [IDietf-core-link-format amp IDshelby-core-resource-
directory]
Current CoAP Support of Sleepy Node (22)
Lower layer support for sleepy nodes in most wireless technologies (eg WiFi ZigBee) But limited to MAC packet scheduling for sleepy nodes
and not aware of specific needs of IP applications (like CoAP)
Proposal ndash RD Based Sleep Tracking (14)
The current CoAP approach to support sleepy nodes can be significantly improved by introducing RD based mechanisms for a CoAP client to determine whether A targeted resource is located on a sleepy server A sleepy server is currently in sleep mode or not
There is any associated caching Proxy (possibly the RD itself) for a sleepy server
Proposal ndash RD Based Sleep Tracking (24)
We define the following new RD attributes to characterize the properties of a sleepy node SleepState - Indicates whether the node is currently in
sleep mode or not (ie Sleeping or Awake) SleepDuration - Indicates the maximum duration of time
that the node stays in sleep mode TimeSleeping - Indicates the length of time the node
has been sleeping (ie if Sleep State = Sleeping) NextSleep - Indicates the next time the node will go to
sleep (ie if Sleep State = Awake)
CachingProxy ndash Indicates the caching proxy of the sleepy node (ie the RD itself or another node)
Proposal ndash RD Based Sleep Tracking (34)
These attributes are all server (node) level and are new parameters added to the RD URI Template Variables
Finally we also define a new lookup-type (ss) for the RD lookup interface specified in [I-Dshelby-core-resource-directory] This new lookup-type supports looking up the
ldquoSleepStaterdquo (ss) of a specified end-point
Proposal ndash RD Based Sleep Tracking (44)
The three time based parameters (SleepDuration TimeSleeping NextSleep) can be based on either an absolute network time (for a time synchronized network) or a relative local time (measured at the local node)
Following the approach of [I-Dietf-core-link-format] and [I-Dshelby-core-resource-directory] sleep parameters for sleepy servers can be stored by the server in the RD and accessed by all interested clients
Examples of using these parameters in a synchronous or asynchronous manner are shown in the I-D
http6lowappnet coreIETF86 2013-03-12-13
We assume people have read the drafts
Meetings serve to advance difficult issues by making good use of face-to-face communications
Note Well Be aware of the IPR principles according to RFC 3979 and its updates
uumlBlue sheetsuumlScribe(s)
96
drar-shy‐iep-shy‐core-shy‐coapsubmiqed13 to13 IESG
2013-shy‐03-shy‐13
97
OMA Lightweight M2M Overview(A new standard using lots of IETF specs including DTLS
CoAP Block Observe Resource Directory SenMLhellip)
Zach ShelbyCoRE WG IETF-86 Orlando
OMA Lightweight M2Mbull Open Mobile Alliance is well known for Device Management (DM)bull OMA Lightweight M2M is a new standard from the alliance
ndash Focused on constrained Cellular and sensor network M2M devicesndash Driven by leading operators and vendors
bull Scopendash Interfaces protocol amp security between Device and Serverndash Object and Resource modelndash Bootstrap Device Access Control Connectivity and Firmware Objects
bull Draft Specifications are availablendash httpmemberopenmobileallianceorgftpPublic_documentsDM
LightweightM2MPermanent_documentsOMA-TS-LightweightM2M-V1_0_0-20130301-Dzip
bull Timelinendash Requirements and Architecture completed 3Q2012ndash Spec ready for Consistency Review 2Q2013ndash Candidate Approval expected 3Q2013
2 CoRE WG IETF-86 Orlando
Architecture
3
Scope of LWM2M
CoRE WG IETF-86 Orlando
Object Model
bull A Client has one or more Object Instancesbull An Object is a collection of Resourcesbull A Resource is an atomic piece of information
ndash Read Written or Executed
bull Resources can have multiple instancesbull Objects and Resources are identified by a
16-bit Integer Instances by an 8-bit Integerbull ObjectsResources are accessed with
simple URIs Object IDObject InstanceResource ID
eg 1213
4 CoRE WG IETF-86 Orlando
CoRE WG IETF-86 Orlando
CoRE Resource Directory
draft-shelby-core-resource-directory-05
Z Shelby C Bormann S Krco
Backgroundbull Not a new concept
ndash think web search engine or any link directorybull Defines the interfaces to a Resource Directorybull Based on Web Linking framework and the CoRE Link Formatbull Generic REST design for use over HTTP and CoAPbull Used by OMA Lightweight M2Mbull Has already been deployed
ndash In traffic monitoring systemsndash In street lighting systemsndash For vehicular asset trackingndash By a major Cellular M2M operator
Changes since -04
bull Restricted Update to parameter updatesbull Added pagination support for the Lookup interfacebull Changed rt= to et= for the registration amp update
interfacebull Added group support
Group Management
bull RD now includes group management featuresbull New Group Function Set
ndash Register a groupbull Group name domain multicast address endpoint members
ndash Remove a groupbull Group lookup using the Lookup Function Set
ndash List registered groupsndash Find the members of a groupndash Find groups with certain endpoints or resources
Registering a Group
EP RD
| |
| - POST rd-groupgp=lights ltgtep=node1 --gt |
| |
| |
| lt---- 201 Created Location rd-group12 ---- |
| |
Req POST coaprdexamplecomrd-groupgp=lights
Payload
ltgtep=node1
ltgtep=node2
Res 201 Created
Location rd-group12
Looking up Group Members
Client RD
| |
| ----- GET rd-lookupepgp=lights1 ----------------------gt |
| |
| |
| lt-- 205 Content ltrdgtd=domain1ltrdgtd=domain2 --------- |
| |
Req GET rd-lookupepgp=lights1
Res 205 Content
ltcoaphostportgtep=node1
ltcoaphostportgtep=node2rdquo
Things for the futurebull Support for JSON representation of Web Links
ndash httptoolsietforgiddraft-bormann-core-links-json-02txtbull Registry for RD registration query parameters
ndash Already OMA Lightweight has defined some new onesbull More examples
Group 3 ldquonew workrdquo(continued)
109
drar-shy‐greevenbosch-shy‐core-shy‐profile-shy‐descripon-shy‐01Bert13 GreevenboschJeroen13 Hoebeke
Isam13 IshaqFloris13 Van13 den13 Abeele
Descripon
bull JSON13 format13 for13 signalling13 the13 servers13 capabilies
bull Signalling13 of13 supported13 opons13 media13 types13 and13 block13 sizendash Other13 items13 can13 be13 added
bull Filtering13 on13 specific13 fields13 through13 URI-shy‐Querybull Link13 hqpdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐profile-shy‐descripon
well-shy‐knownprofile
bull To13 acquire13 profile13 data13 of13 resources13 on13 a13 parcular13 service13 the13 well-shy‐knownprofile13 URI-shy‐path13 is13 introduced
bull For13 example13 to13 get13 all13 informaon13 from13 sensors13 served13 by13 wwwexampleorg13 we13 can13 do13 a13 GET13 to13 coapwwwexampleorgwell-shy‐knownprofile
bull Filtering13 on13 parcular13 resources13 is13 done13 through13 URI-shy‐Queries
Format
bull Currently13 the13 following13 fields13 are13 definedndash ldquopathrdquo13 contains13 the13 URI-shy‐path13 associated13 with13 a13 resource
ndash ldquooprdquo13 a13 numerical13 list13 of13 supported13 opon13 numbers
ndash ldquocfrdquo13 a13 numerical13 list13 of13 supported13 content-shy‐format13 numbers
ndash ldquob1srdquo13 ldquob2srdquo13 supported13 block13 sizes13 for13 Block113 and13 Block213 respecvely
Examplebull On13 the13 right13 is13 an13 example13 of13 a13 camera13 sensor13 at13 coapwwwexampleorgcam13 that13 supports13 the13 Uri-shy‐Host13 (3)13 ETag13 (4)13 Uri-shy‐Port13 (7)13 Uri-shy‐Path13 (11)13 Content-shy‐Format13 (12)13 Token13 (19)13 Block213 (23)13 and13 Proxy-shy‐Uri13 (35)13 opons
bull The13 supported13 content13 formats13 are13 textplain13 (0)13 applicaon13 link-shy‐format13 (40)13 and13 applicaonjson13 (50)
bull The13 supported13 Block213 can13 use13 25613 or13 51213 byte13 blocks
Req13 GET13 coapwwwexampleorgwell-shy‐knownprofile13 Res13 20513 Content13 (applicationjson)13 13 13 13 profile13 13 13 13 13 13 13 13 pathcam13 13 13 13 op[3471112192335]13 13 13 13 13 cf[04050]13 13 13 13 13 b2s[45]13 13 13 13
Filtering13 through13 use13 of13 URI-shy‐Query
bull Filtering13 can13 be13 done13 through13 the13 URI-shy‐Querybull Query13 format13 N=V
ndash N13 is13 a13 profile13 fieldndash V13 is13 the13 desired13 value
bull Examplesndash To13 find13 resources13 that13 support13 content13 format13 ldquoapplicaonjsonrdquo
13 GET13 wwwexampleorgwell-shy‐knownprofilecf=50ndash To13 get13 informaon13 about13 the13 camera
13 GET13 wwwexampleorgwell-shy‐knownprofilepath=cam
Open13 issues
bull Which13 other13 profile13 data13 needs13 signallingndash Content-shy‐type13 for13 different13 methods
bull Fix13 the13 order13 in13 which13 the13 profile13 fields13 must13 appearndash Non-shy‐fixed13 order13 easier13 extensible
bull Inheritance13 of13 a13 profile13 descriponbull Extend13 usage13 to13 signal13 the13 client13 profilebull Integraon13 with13 link13 format
Thank13 youQuesons
drar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval-shy‐00
Bert13 Greevenbosch
Descripon
bull The13 ldquoMinimumRequestInterval13 opon13 can13 be13 used13 to13 indicate13 the13 minimum13 me13 between13 two13 requests13 in13 a13 transacon
bull Originally13 intended13 for13 Block13 but13 also13 usable13 for13 other13 transaconsndash Example13 browsing13 a13 server
bull The13 goal13 is13 to13 reduce13 the13 server13 load13 and13 network13 traffic
bull Link13 hqpsdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval
Usage
bull The13 client13 keeps13 the13 server13 informed13 about13 its13 request13 speed13 through13 inclusion13 of13 the13 ldquoMinimumRequestIntervalrdquo13 opon
bull In13 responses13 the13 server13 fixes13 the13 minimum13 request13 interval13 through13 the13 same13 opon
bull The13 client13 obeys13 the13 speed13 indicated13 by13 the13 server
bull The13 client13 can13 send13 slower13 but13 not13 faster
Advantages
bull The13 server13 has13 means13 to13 limit13 the13 amount13 of13 incoming13 traffic
bull The13 server13 can13 prevent13 to13 become13 overloaded13 with13 too13 many13 tasks
bull The13 server13 does13 not13 need13 arficially13 slow13 down13 the13 client13 by13 sending13 late13 ACKsndash No13 need13 to13 keep13 track13 of13 delayed13 ACKsndash The13 server13 can13 perform13 other13 tasks13 instead
bull Reduced13 network13 traffic
Thank13 youQuesons
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-links-json-02txt
123
RFC 6690 (link-format) documents are somewhat foreign to many web app developerssect would prefer to have them in JSON format
There is no standard way to represent link-format documents in applicationssect but everyone knows how to handle JSON
Define a standard JSON translation for link-format
Itrsquos
not
rock
et
scien
ce
ltsensorsgtct=40title=Sensor Index ltsensorstempgtrt=temperature-cif=sensor ltsensorslightgtrt=light-luxif=sensor lthttpwwwexamplecomsensorst123gt anchor=sensorstemprel=describedby lttgtanchor=sensorstemprel=alternate [hrefsensorsct40titleSensor Index hrefsensorstemprttemperature-cifsensor hrefsensorslightrtlight-luxifsensor hrefhttpwwwexamplecomsensorst123 anchorsensorstempreldescribedby hreftanchorsensorstemprelalternate]
124
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-ipsec-for-coap-00txt
IPsec definitions for CoAP Mostly placeholder at this time Who has implementation experience with this
125
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-cross-reverse-convention-00txt
This draft has two lines of payload(based on a WGLC comment by Cullen Jennings)
coap12344567foobara=3
httpwwwproxycomwellknowncore-translate1234_4567foobara=3
Is that a useful convention to have
126
Insert CI slides here
127
128
0
5
10
15
20
25
30
35
40
10 20 30 40 50 60 70
good
put (
pps)
pps
Goodput vs pps (Econotags)
goodput
[Khattak preliminary]
Congestion Control
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-cocoa-00txt
ldquoadvancedrdquo cc (The draft is just a first shot) Others may have better ideas
129
Insert post-WGLC discussion slides here
130
Stop Continue Start
131
An Agile Retrospective
http6lowappnet coreIETF86 2013-03-12-13
Stop
132
Endless new CoAP optionssect instead use RESTful as much as possible
Move general security lifecycle out Looking at theoretical problems
http6lowappnet coreIETF86 2013-03-12-13
Continue
Interops Running code Look at real-world examples and deployments Solve their actual problems
sect Unilateral enhancements eg higher performance congestion control
sect Transports (SMS hellip)sect Make Web linking and Directories more and more usefulsect RESTful Design Paradigms for real-world problems
133
http6lowappnet coreIETF86 2013-03-12-13
Start
Further push into the (browser) web world (HTML5 browser security)
Specific supporting worksect SenMLsect URI work (dev URN hellip)sect Security Processes (next slide)
Spin outsect (We donrsquot really get to decide where this is done)
134
http6lowappnet coreIETF86 2013-03-12-13
Security
Integrate Application Network Group Keyingsect Tunnel-free setup
Donrsquot redo what has been done alreadysect ZigBee IP is finesect But what about other scenarios
Simple REST interfaces for working with keying materials and authorizationsect Start with defining objectives
Object Security for Constrained Nodes135
Re-chartering CoREWhat do we want to do now that wersquore grown up
Zach ShelbyCoRE WG IETF-86 Orlando
What is the scope
bull So we have a protocol and Web Linking what next
bull Keep with what we know besthellip1 Enhancements around CoAP2 New transports for CoAP3 New representations for Web Links4 General application layer solutions
CoRE WG IETF-86 Orlando 2
Enhancements around CoAP
bull Advanced congestion control
CoRE WG IETF-86 Orlando 3
New Transports for CoAP
bull Infrastructure for CoAP over foondash httptoolsietforgiddraft-silverajan-core-
coap-alternative-transports-01txtbull CoAP over SMS
ndash httptoolsietforgiddraft-becker-core-coap-sms-gprs-03txt
ndash OMA Lightweightbull CoAP over TCP
ndash httptoolsietforgiddraft-li-core-coap-payload-length-option-01txt
CoRE WG IETF-86 Orlando 4
New support for Web Links
bull JSON Web Linksndash httptoolsietforgiddraft-bormann-core-links-
json-02txt
2332010 CoRE WG IETF-77 Anaheim 5
General application layer solutions
bull Resource Directoryndash httptoolsietforgiddraft-shelby-core-
resource-directory-05txtndash OMA Lightweight
2332010 CoRE WG IETF-77 Anaheim 6
Definitions (12)
n Cross-Protocol Proxy (or Cross Proxy) is a proxy performing a cross- protocol mapping in the context of this document a HTTP-CoAP (HC) mapping A Cross-Protocol Proxy can behave as a Forward Proxy Reverse Proxy or Interception Proxy n Note In this document we focus on the Reverse Proxy mode of the
Cross-Protocol Proxy
n Forward Proxy a message forwarding agent that is selected by the client usually via local configuration rules to receive requests for some type(s) of absolute URI and to attempt to satisfy those requests via translation to the protocol indicated by the absolute URI The user decides (is willing to) use the proxy as the forwardingdereferencing agent for a predefined subset of the URI space
Definitions (22)
n Reverse Proxy a receiving agent that acts as a layer above some other server(s) and translates the received requests to the underlying servers protocol It behaves as an origin (HTTP) server on its connection towards the (HTTP) client and as a (CoAP) client on its connection towards the (CoAP) origin server The (HTTP) client uses the origin-form [I-Dietf-httpbis-p1-messaging] as a request- target URI
n Reverse and Forward proxies are technically very similar with main differences being that the former appears to a client as an origin server while the latter does not and that clients may be unaware they are communicating with a proxy
Reverse Cross-Protocol Proxy Deployment Scenario
HTTP-CoAP Response Code Mapping
Implementation Experience
n Direct experience from the draft authorsn Squid HTTP-CoAP mapping module
n University of Padovan httptelecomdeiunipditiotn Both Forward and Interception operation supported
n HTTP-CoAP proxy based on EvCoAPn KoanLogic University of Bologna and Salvatore
Loreto (as individual)n httpsgithubcomkoanlogicwebthingstreemasterbridgesw
libevcoapn The document is open to input from other implementations
Next Steps
n Does the WG recommend adoptionn Intended status Informational Best Practicen Purpose Reduce arbitrary variation between proxy
implementations thereby increasing interoperability
Backup
HTTP to CoAP URI Mapping Options (12)
n Embedded Mapping n In an embedded mapping approach the HTTP URI has embedded
inside it the authority and path part of the CoAP URI n Example The CoAP resource nodecoapsomethingnetfoo can
be accessed by an HTTP client by inserting in the request httphc-proxysomethingnetcoapnodecoapsomethingnetfoo The Cross-Protocol Proxy then maps the URI to coapnodecoapsomethingnetfoo
HTTP to CoAP URI Mapping Options (22)
n Homogeneous Mapping n In a homogeneous mapping approach only the scheme portion of the URI
needs to be mapped The rest of the URI (ie authority path etc) remains unchanged
n Example The CoAP resource coapnodecoapsomethingnetfoo can be accessed by an HTTP client by requesting httpnodecoapsomethingnetfoo The Cross-Protocol Proxy receiving the request is responsible to map the URI to coapnodecoapsomethingnetfoo
n Background info n The assumption in this case is that the HTTP client would be able to
successfully resolve nodecoapsomethingnet using DNS infrastructure to return the IP address of the HC proxy Most likely this would be through a two step DNS lookup where the first DNS lookup would resolve somethingnet using public DNS infrastructure
n Then the second DNS lookup on the subdomain coap and the host node would typically be resolved by a DNS server operated by the owner of domain somethingnet So this domain owner can manage its own internal node names and subdomain allocation which would correspond to the CoAP namespace
Group 3 ldquonew workrdquo
39
Transport of CoAP over SMS USSD and GPRSdraft-becker-core-coap-sms-gprs-03
Markus Becker Kepeng LiKoojana Kuladinithi Thomas Poumltsch
CoRE WG IETF-86 Orlando
1 10
ScenariosI In M2M communication IP connectivity is not alwayssupported by the constrained end-points
I Power savingI Coverage (GPRS 3G LTE)
I SMS and USSD based communication is almost alwayssupported
210
Changes from draft-01 to draft-03 (1)
I Added possible CONNONACK interactions Section 5
I Option name changed from Reply-To- to Response-To-Section 16 and Section 101
I Added URI schemeEg coap+tel+15105550101well-knowncore Section 11
I Added possible M2M proxy scenarios Section 14
3 10
Changes from draft-01 to draft-03 (2)
I Added reference to bormann-coap-misc for other SMSencoding Section 71
I Updated requirements on Uri-Host and Uri-Port forcoap+tel Section 10
I Added security considerations Transport and ObjectSecurity Section 15
I Chose CoAP option numbers and updated the optionnumber table to meet draft-ietf-core-coap-10 Table 1
I Added an IANA registration for the URI scheme coap+telSection 162
4 10
Feedback Split coap+tel into coap+smsand coap+ussd
I How else to differ the various transports in the URII Or is the transport to use decided by the implementationI See alsodraft-silverajan-core-coap-alternative-transports-01
5 10
Feedback Response-To-Scheme option
I Should there be a Response-To-Scheme optionadditionally to Response-To-Uri-Host andResponse-To-Uri-Path
I So that a CoAP end-point which receives a request by CoAPover non-IP transport can be instructed to also use thenon-IP transport for the response
I This would imply to add aResponse-To-Telephone-Subscriber and more options forother transports that have other URI schemes than coapand coaps
6 10
Feedback Selection of Transport by Client
I When a server is reachable by various transports howdoes a client decide which transport to use
I Client-side application congurationI Leave it to a proxy which uses cellular network lookupfunctions
7 10
Feedback Potential Threats
I Trigger expensive short messagesI Redirect trac to other addressesI More threats
I Are the security measures in the draft adequateI Whitelisting on serverI Relying on cellular network security (dedicated M2M APNs)I Object security on CoAP payload
8 10
Feedback Message Exchanges
I Figures 11-18 show possible message exchanges whenclient and server have two addresses
I With NON Not using CoAP retransmission capabilityI ACK on different transportI Additional (costly) message on Transport AI Request with Content
I Which ones are allowedI Which ones are meaningful
9 10
Next steps
I Rene Uri schemeI Response-To-Scheme optionI Selection of Message ExchangeI Rene Proxying
10 10
CoAP13 Communicaon13 with13 Alternave13 Transports
Bill Silverajan and Teemu SavolainenCore WG IETF 86 Orlando
031113
Objecves13 (In13 Scope)
bull Unambiguous13 representaon13 of13 transport13 to13 be13 used13 by13 CoAP
bull Details13 how13 the13 transport13 can13 carry13 CoAP13 packet
bull Focus13 is13 on13 what13 CoAP13 communicaons13 requirements13 are
bull Allow13 CoAP13 mechanisms13 to13 exploit13 cross-shy‐layer13 opmisaons
51
031113
Non13 Goals13 (Not13 in13 scope)
bull Applicaon-shy‐level13 QoS13 requirementsbull Real-shy‐me13 constraintsbull Ordering13 reliability13 congeson13 controlbull Applicaon13 and13 network13 adaptaonbull Mobility13 and13 readdressing13 supportbull Network13 protocol13 (eg13 IPsec)13 configuraon
52
031113
Use13 Cases
bull NAT13 and13 Firewall13 traversal13 with13 TCPbull Delay13 Tolerant13 Networkingbull Non-shy‐IP13 Low13 Energy13 Protocols
53
031113
Related13 Work
bull OMA13 Lightweight13 M2M13 Protocolbull CoAP13 over13 SMSGPRSUSSD
54
031113
What13 does13 the13 work13 entail
bull The13 ability13 to13 specify13 end13 point13 idenfiers13 and13 URIs13 to13 reflect13 which13 transport13 CoAP13 can13 use
bull The13 ability13 to13 register13 to13 resource13 directories13 resource13 types13 reflecng13 types13 of13 transport13 available
bull Ability13 for13 mul-shy‐transport13 nodes13 to13 select13 transport13 to13 use13 without13 significant13 alteraon13 to13 CoAP13 packet13 structure
55
031113
Points13 to13 consider
bull Requirements13 for13 transport13 layer13 protocol13 to13 carry13 CoAP13 packets
bull Representaon13 of13 URI13 scheme13 for13 generic13 transport13 protocols
bull Opon13 extensions13 for13 CoAP13 to13 express13 available13 transports
bull Mapping13 and13 message13 sizebull Security13 consideraons
56
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
URI13 =13 scheme13 13 13 authority13 path-shy‐abempty13 [13 query13 ]
bull Within13 the13 scheme13 namebull In13 the13 URI13 pathbull As13 a13 query13 component
57
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
bull Within13 the13 scheme13 namendash coap+tel+15105550101well-shy‐knowncorendash coap+tcpexamplecom5683temperaturendash coap+blel2cap[1234567890AB]4pulse
bull Easy13 URI13 parsing13 for13 transport13 type13 and13 idenfier
bull Each13 new13 scheme13 name13 requires13 IANA13 registraon
58
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
bull In13 the13 URI13 pathndash coaphostexamplecomtransport=tcpwell-shy‐knowncorert=core-shy‐rd
bull Easy13 adopon13 of13 new13 (and13 experimental)13 CoAP13 transports13 without13 IANA13 registraon
bull Caveat13 Uri-shy‐Path13 opon13 is13 a13 Crical13 CoAP13 opon13 see13 secon13 54113 of13 I-shy‐Diep-shy‐core-shy‐coap
59
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
bull As13 a13 URI13 query13 componentndash coaphostexamplecomwell-shy‐knowncorert=core-shy‐rdq=tcp
bull Also13 easy13 to13 adopt13 new13 (and13 experimental)13 CoAP13 transports13 without13 IANA13 registraon
bull Caveat13 Uri-shy‐Query13 opon13 is13 a13 Crical13 CoAP13 opon13 see13 secon13 54113 of13 I-shy‐Diep-shy‐core-shy‐coap
60
031113
URI13 Representaons13 for13 CoAPNon13 standard13 ways
bull Transport13 in13 the13 URI13 authority13 componentndash coaphost[port][transport]13 instead13 of13 coaphost[port]
bull Transport13 as13 a13 service13 URLndash servicecoaptcphostexamplecomwell-shy‐knowncorert=core-shy‐rd
bull Above13 two13 ways13 break13 exisng13 compability13 (although13 both13 are13 based13 on13 valid13 IANA13 URI13 registraons)
61
031113
URI13 Representaons13 for13 CoAPMiscellaneous13 Consideraons
bull Ensure13 that13 transport13 is13 defined13 unambiguously13 (eg13 L2CAP13 used13 by13 both13 BLE13 and13 standard13 Bluetooth13 so13 avoid13 rdquocoap+l2caprdquo13 or13 rdquotransport=l2caprdquo13 or13 rdquoq=l2caprdquondash Can13 be13 done13 as13 WG13 consensusndash Namespace13 approach13 eg13 rdquocoap+blel2caprdquo13 or13 rdquoq=blel2caprdquo
bull Allow13 end-shy‐points13 to13 use13 CoAP13 Resource13 Directory13 to13 register13 alternave13 transports13 and13 idenfiers13 and13 provide13 periodic13 updatesndash Register13 rdquocore-shy‐transportrdquo13 resource13 type
62
031113
Transport13 Consideraons
bull Uniqueness13 of13 end-shy‐point13 idenficaonbull Communicaon13 support13 Unidireconal13 Bidireconal13 1N13 (broadcast13 mulcast13 anycast)13 messaging
bull Binary13 encoding13 Network13 byte13 orderingbull MTU13 correlaon13 with13 CoAP13 PDU13 sizebull Transport13 latency
63
031113
Security13 Consideraons
bull Drar13 does13 not13 introduce13 new13 security13 requirements13 by13 itself
bull There13 may13 be13 privacy13 issues13 if13 nodes13 use13 telephone13 numbers13 or13 MAC13 addresses13 as13 public13 end13 point13 idenfiers
64
Akbar Rahman
IETF 86 March 2013 httpwwwietforgiddraft-rahman-core-sleepy-02txt
Enhanced Sleepy Node Support for CoAP
Introduction
It is expected that in CoAP networks there will be a certain portion of devices that are sleepy and which may occasionally go into a sleep mode (ie go into a low power state to conserve power) and subsequently have reduced CoAP protocol communication ability
This I-D proposes a minimal and efficient mechanism building on the Resource Directory concept (which will be integrated into a CoAP Proxy) to enhance sleepy node support in CoAP networks
Main Question from IETF-85 (Atlanta)
What performance benefit does the proposed Sleepy Node support solution give in a network that already has standard CoAP caching enabled
Sleepy Node Performance Analysis
Experimental Network
1-5 clients
Both Sleepy and Non-
Sleepy servers
Sleepy Node Performance Analysis Network Setup
CoAPSleepyServer(s)
CoAPSleepAwareReverseProxy
CoAP
Client(s)
Request
Response
Sleep9AwareCoREResourceDirectoryCapability
PublishedSleepParameters
Sleep9AwareCoAPStoreandForwardCapability Response
Request
SleepAwareCoAP503ResponseCapability
CoAPCachingCapability
bull Server supports publishing sleep parameters to proxy bull Eg Irsquom going to be asleep for X seconds
bull Proxy supports sleep-awareness capabilities bull Proxy also supports caching capability based off of maxAge bull Protocol flow similar to approach of Figure 1 (Synchronous RD Based Sleep
Tracking) of I-D
Proxy capabilities can be selectively enableddisabled
Proxy ndash Server Interface
Client ndash Proxy Interface
CoAP Sleep-Aware Reverse Proxy Features CoRE Sleep-aware Resource Directory
Support storing published sleep parameters from CoAP servers sleepState (AWAKE ASLEEP) sleepDuration
Sleep-aware CoAP 503 Response Capability If CoAP request to a sleeping server is received proxy returns a
lsquo503 Retry-Afterrsquo response to client 503 contains a timestamp indicating when the sever will wake back up
(timestamp delivered in CoAP maxAge option) Sleep-aware CoAP Store-and-Forward Capability
If CoAP request to a sleeping server is received proxy stores request until server wakes up and then forwards it
Caching capability Cache GET responses from server if maxAge option is present
(this is not a sleep aware feature)
Goals of Performance Analysis
For networks having sleepy servers provide measurements to quantify the impact that CoAP sleep-awareness capabilities can have
See if sleep-awareness capabilities can
provide additional benefits even when CoAP caching is used
Overview of Performance Analysis Performed The analysis was broken up into a set of test scenarios Each test scenario used a different combination of the following
variables Client issued GET requests Server was configured as a sleepy or non-sleepy server Proxy caching of GET responses was enabled or disabled Proxy sleep-aware 503 response capability was enabled or disabled Proxy store-and-forward capability was enabled or disabled maxAge in GET responses ndash Two values were tested 60sec and 5sec of Clients ndash Two values were used ndash 1 client and 5 clients
For comparison purposes the following were held constant across all test scenarios Client issued a fixed number of requests (100) across all test scenarios Client used a delay between each GET request (35sec) to better exercise
proxyrsquos caching and sleep-awareness capabilities For sleepy server test scenarios the server slept 60 sec awake for 3 sec
Format of Results The following results were collected for each
test scenario
Breakdown of the and types of transactions occurring between clientproxyserver
ldquoGETrdquo ndash Test Scenario Results
GET ndash Description of Test Scenarios
TestScenarios-GET
Scenario
CoAPSleepyServerSe7ngs CoAPSleepAwareReverseProxySe7ngs CoAPClientSe7ngs
SleepDuragton(sec)
AwakeDuragton(sec)
maxAge(sec) Caching SleepAwareSAF+
503NumberofClients
NumberofGETs
DelayBetweenClient
Requests(sec)
1a 0 Always 60 Enabled Disabled 1 100 35
1b 60 3 60 Enabled Disabled 1 100 35
1c 60 3 60 Enabled Enabled 1 100 35
2a 0 Always 60 Enabled Disabled 5 100 35
2b 60 3 60 Enabled Disabled 5 100 35
2c 60 3 60 Enabled Enabled 5 100 35
3a 0 Always 5 Enabled Disabled 5 100 35
3b 60 3 5 Enabled Disabled 5 100 35
3c 60 3 5 Enabled Enabled 5 100 35
ldquoGETrdquo ndash Test Scenario 1 Results
maxAge = 60 and 1 Client
GET ndash Scenario 1 ClientProxy Interface Transaction Mix
Scenarios 1a - Non-Sleepy Server Caching Proxy maxAge = 60sec 1b- Sleepy Server Caching Proxy maxAge = 60sec 1c - Sleepy Server Sleep Aware Proxy maxAge = 60sec
Sleep Aware Proxy has better performance for sleepy servers
0
100
200
300
400
500
600
700
1a 1b 1c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
GET ndash Scenario 1 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
Scenarios 1a - Non-Sleepy Server Caching Proxy maxAge = 60sec 1b- Sleepy Server Caching Proxy maxAge = 60sec 1c - Sleepy Server Sleep Aware Proxy maxAge = 60sec
0
100
200
300
400
500
600
700
800
1a 1b 1c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
ldquoGETrdquo ndash Test Scenario 2 Results
maxAge = 60 and 5 Clients
GET ndash Scenario 2 ClientProxy Interface Transaction Mix
Sleep Aware Proxy has slightly better performance for sleepy servers
0
200
400
600
800
1000
1200
1400
2a 2b 2c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
Scenarios 2a - Non-Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2b- Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2c - Sleepy Server Sleep Aware Proxy maxAge = 60sec 5 Clients
See ldquoExperimental Artifactsrdquo Note 1
GET ndash Scenario 2 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has slightly better performance for sleepy servers
0
50
100
150
200
250
300
350
400
2a 2b 2c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
Scenarios 2a - Non-Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2b- Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2c - Sleepy Server Sleep Aware Proxy maxAge = 60sec 5 Clients
See ldquoExperimental Artifactsrdquo Note 2
Experimental Artifacts Note 1
Currently in the experiment the sleep aware proxy checks the cached state of a resource before putting a request into its Store-and-forward queue while a server is sleeping Once in the queue the proxy unconditionally forwards the queued requests to the server once it wakes up This is not the most efficient setup and can easily be improved If the proxy instead checks its cache again before forwarding each queued request it may not need to forward the request to the server For example if there are two queued GET requests in the proxyrsquos queue that address the same resource Only the first request needs to be sent to the server the second request can use the cached response from the first request
Note 2 Currently in the experiment the sleepy server sends a sleepState PUT request to the
proxy each time it goes to sleep This is not the most efficient setup and can easily be improved For example if the server assumes that the proxy can keep track of its ONOFF cycles with its internal timers (eg as per Fig 1 of I-D) then the number of messages from the sleepy server dramatically goes down
ldquoGETrdquo ndash Test Scenario 3 Results
maxAge = 5 and 5 Clients
GET ndash Scenario 3 ClientProxy Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
Scenarios 3a - Non-Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3b- Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3c - Sleepy Server Sleep Aware Proxy maxAge = 5sec 5 Clients
0
500
1000
1500
2000
2500
3000
3500
4000
4500
5000
3a 3b 3c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
GET ndash Scenario 3 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
0
1000
2000
3000
4000
5000
6000
7000
3a 3b 3c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
Scenarios 3a - Non-Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3b- Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3c - Sleepy Server Sleep Aware Proxy maxAge = 5sec 5 Clients
Conclusions
Conclusions These results show that sleep-aware CoAP
proxy features can significantly optimize communication with sleepy servers in most scenarios
These results also show that sleep-
awareness capabilities can provide additional benefits above and beyond CoAP caching in most scenarios
Backup
Current CoAP Support of Sleepy Node (12)
CoAP proxies can use a previously cached response to service a new GET request for a sleepy origin server (as in HTTP) But if no valid cache then proxy has to attempt to
retrieve and may fail if origin server is sleeping [I-Dietf-core-coap]
Clients can discover list of resources from RD (GET rd-lookuphellip) for sleepy servers But attempt to GET resource from sleepy origin server
may fail if origin server is sleeping [IDietf-core-link-format amp IDshelby-core-resource-
directory]
Current CoAP Support of Sleepy Node (22)
Lower layer support for sleepy nodes in most wireless technologies (eg WiFi ZigBee) But limited to MAC packet scheduling for sleepy nodes
and not aware of specific needs of IP applications (like CoAP)
Proposal ndash RD Based Sleep Tracking (14)
The current CoAP approach to support sleepy nodes can be significantly improved by introducing RD based mechanisms for a CoAP client to determine whether A targeted resource is located on a sleepy server A sleepy server is currently in sleep mode or not
There is any associated caching Proxy (possibly the RD itself) for a sleepy server
Proposal ndash RD Based Sleep Tracking (24)
We define the following new RD attributes to characterize the properties of a sleepy node SleepState - Indicates whether the node is currently in
sleep mode or not (ie Sleeping or Awake) SleepDuration - Indicates the maximum duration of time
that the node stays in sleep mode TimeSleeping - Indicates the length of time the node
has been sleeping (ie if Sleep State = Sleeping) NextSleep - Indicates the next time the node will go to
sleep (ie if Sleep State = Awake)
CachingProxy ndash Indicates the caching proxy of the sleepy node (ie the RD itself or another node)
Proposal ndash RD Based Sleep Tracking (34)
These attributes are all server (node) level and are new parameters added to the RD URI Template Variables
Finally we also define a new lookup-type (ss) for the RD lookup interface specified in [I-Dshelby-core-resource-directory] This new lookup-type supports looking up the
ldquoSleepStaterdquo (ss) of a specified end-point
Proposal ndash RD Based Sleep Tracking (44)
The three time based parameters (SleepDuration TimeSleeping NextSleep) can be based on either an absolute network time (for a time synchronized network) or a relative local time (measured at the local node)
Following the approach of [I-Dietf-core-link-format] and [I-Dshelby-core-resource-directory] sleep parameters for sleepy servers can be stored by the server in the RD and accessed by all interested clients
Examples of using these parameters in a synchronous or asynchronous manner are shown in the I-D
http6lowappnet coreIETF86 2013-03-12-13
We assume people have read the drafts
Meetings serve to advance difficult issues by making good use of face-to-face communications
Note Well Be aware of the IPR principles according to RFC 3979 and its updates
uumlBlue sheetsuumlScribe(s)
96
drar-shy‐iep-shy‐core-shy‐coapsubmiqed13 to13 IESG
2013-shy‐03-shy‐13
97
OMA Lightweight M2M Overview(A new standard using lots of IETF specs including DTLS
CoAP Block Observe Resource Directory SenMLhellip)
Zach ShelbyCoRE WG IETF-86 Orlando
OMA Lightweight M2Mbull Open Mobile Alliance is well known for Device Management (DM)bull OMA Lightweight M2M is a new standard from the alliance
ndash Focused on constrained Cellular and sensor network M2M devicesndash Driven by leading operators and vendors
bull Scopendash Interfaces protocol amp security between Device and Serverndash Object and Resource modelndash Bootstrap Device Access Control Connectivity and Firmware Objects
bull Draft Specifications are availablendash httpmemberopenmobileallianceorgftpPublic_documentsDM
LightweightM2MPermanent_documentsOMA-TS-LightweightM2M-V1_0_0-20130301-Dzip
bull Timelinendash Requirements and Architecture completed 3Q2012ndash Spec ready for Consistency Review 2Q2013ndash Candidate Approval expected 3Q2013
2 CoRE WG IETF-86 Orlando
Architecture
3
Scope of LWM2M
CoRE WG IETF-86 Orlando
Object Model
bull A Client has one or more Object Instancesbull An Object is a collection of Resourcesbull A Resource is an atomic piece of information
ndash Read Written or Executed
bull Resources can have multiple instancesbull Objects and Resources are identified by a
16-bit Integer Instances by an 8-bit Integerbull ObjectsResources are accessed with
simple URIs Object IDObject InstanceResource ID
eg 1213
4 CoRE WG IETF-86 Orlando
CoRE WG IETF-86 Orlando
CoRE Resource Directory
draft-shelby-core-resource-directory-05
Z Shelby C Bormann S Krco
Backgroundbull Not a new concept
ndash think web search engine or any link directorybull Defines the interfaces to a Resource Directorybull Based on Web Linking framework and the CoRE Link Formatbull Generic REST design for use over HTTP and CoAPbull Used by OMA Lightweight M2Mbull Has already been deployed
ndash In traffic monitoring systemsndash In street lighting systemsndash For vehicular asset trackingndash By a major Cellular M2M operator
Changes since -04
bull Restricted Update to parameter updatesbull Added pagination support for the Lookup interfacebull Changed rt= to et= for the registration amp update
interfacebull Added group support
Group Management
bull RD now includes group management featuresbull New Group Function Set
ndash Register a groupbull Group name domain multicast address endpoint members
ndash Remove a groupbull Group lookup using the Lookup Function Set
ndash List registered groupsndash Find the members of a groupndash Find groups with certain endpoints or resources
Registering a Group
EP RD
| |
| - POST rd-groupgp=lights ltgtep=node1 --gt |
| |
| |
| lt---- 201 Created Location rd-group12 ---- |
| |
Req POST coaprdexamplecomrd-groupgp=lights
Payload
ltgtep=node1
ltgtep=node2
Res 201 Created
Location rd-group12
Looking up Group Members
Client RD
| |
| ----- GET rd-lookupepgp=lights1 ----------------------gt |
| |
| |
| lt-- 205 Content ltrdgtd=domain1ltrdgtd=domain2 --------- |
| |
Req GET rd-lookupepgp=lights1
Res 205 Content
ltcoaphostportgtep=node1
ltcoaphostportgtep=node2rdquo
Things for the futurebull Support for JSON representation of Web Links
ndash httptoolsietforgiddraft-bormann-core-links-json-02txtbull Registry for RD registration query parameters
ndash Already OMA Lightweight has defined some new onesbull More examples
Group 3 ldquonew workrdquo(continued)
109
drar-shy‐greevenbosch-shy‐core-shy‐profile-shy‐descripon-shy‐01Bert13 GreevenboschJeroen13 Hoebeke
Isam13 IshaqFloris13 Van13 den13 Abeele
Descripon
bull JSON13 format13 for13 signalling13 the13 servers13 capabilies
bull Signalling13 of13 supported13 opons13 media13 types13 and13 block13 sizendash Other13 items13 can13 be13 added
bull Filtering13 on13 specific13 fields13 through13 URI-shy‐Querybull Link13 hqpdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐profile-shy‐descripon
well-shy‐knownprofile
bull To13 acquire13 profile13 data13 of13 resources13 on13 a13 parcular13 service13 the13 well-shy‐knownprofile13 URI-shy‐path13 is13 introduced
bull For13 example13 to13 get13 all13 informaon13 from13 sensors13 served13 by13 wwwexampleorg13 we13 can13 do13 a13 GET13 to13 coapwwwexampleorgwell-shy‐knownprofile
bull Filtering13 on13 parcular13 resources13 is13 done13 through13 URI-shy‐Queries
Format
bull Currently13 the13 following13 fields13 are13 definedndash ldquopathrdquo13 contains13 the13 URI-shy‐path13 associated13 with13 a13 resource
ndash ldquooprdquo13 a13 numerical13 list13 of13 supported13 opon13 numbers
ndash ldquocfrdquo13 a13 numerical13 list13 of13 supported13 content-shy‐format13 numbers
ndash ldquob1srdquo13 ldquob2srdquo13 supported13 block13 sizes13 for13 Block113 and13 Block213 respecvely
Examplebull On13 the13 right13 is13 an13 example13 of13 a13 camera13 sensor13 at13 coapwwwexampleorgcam13 that13 supports13 the13 Uri-shy‐Host13 (3)13 ETag13 (4)13 Uri-shy‐Port13 (7)13 Uri-shy‐Path13 (11)13 Content-shy‐Format13 (12)13 Token13 (19)13 Block213 (23)13 and13 Proxy-shy‐Uri13 (35)13 opons
bull The13 supported13 content13 formats13 are13 textplain13 (0)13 applicaon13 link-shy‐format13 (40)13 and13 applicaonjson13 (50)
bull The13 supported13 Block213 can13 use13 25613 or13 51213 byte13 blocks
Req13 GET13 coapwwwexampleorgwell-shy‐knownprofile13 Res13 20513 Content13 (applicationjson)13 13 13 13 profile13 13 13 13 13 13 13 13 pathcam13 13 13 13 op[3471112192335]13 13 13 13 13 cf[04050]13 13 13 13 13 b2s[45]13 13 13 13
Filtering13 through13 use13 of13 URI-shy‐Query
bull Filtering13 can13 be13 done13 through13 the13 URI-shy‐Querybull Query13 format13 N=V
ndash N13 is13 a13 profile13 fieldndash V13 is13 the13 desired13 value
bull Examplesndash To13 find13 resources13 that13 support13 content13 format13 ldquoapplicaonjsonrdquo
13 GET13 wwwexampleorgwell-shy‐knownprofilecf=50ndash To13 get13 informaon13 about13 the13 camera
13 GET13 wwwexampleorgwell-shy‐knownprofilepath=cam
Open13 issues
bull Which13 other13 profile13 data13 needs13 signallingndash Content-shy‐type13 for13 different13 methods
bull Fix13 the13 order13 in13 which13 the13 profile13 fields13 must13 appearndash Non-shy‐fixed13 order13 easier13 extensible
bull Inheritance13 of13 a13 profile13 descriponbull Extend13 usage13 to13 signal13 the13 client13 profilebull Integraon13 with13 link13 format
Thank13 youQuesons
drar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval-shy‐00
Bert13 Greevenbosch
Descripon
bull The13 ldquoMinimumRequestInterval13 opon13 can13 be13 used13 to13 indicate13 the13 minimum13 me13 between13 two13 requests13 in13 a13 transacon
bull Originally13 intended13 for13 Block13 but13 also13 usable13 for13 other13 transaconsndash Example13 browsing13 a13 server
bull The13 goal13 is13 to13 reduce13 the13 server13 load13 and13 network13 traffic
bull Link13 hqpsdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval
Usage
bull The13 client13 keeps13 the13 server13 informed13 about13 its13 request13 speed13 through13 inclusion13 of13 the13 ldquoMinimumRequestIntervalrdquo13 opon
bull In13 responses13 the13 server13 fixes13 the13 minimum13 request13 interval13 through13 the13 same13 opon
bull The13 client13 obeys13 the13 speed13 indicated13 by13 the13 server
bull The13 client13 can13 send13 slower13 but13 not13 faster
Advantages
bull The13 server13 has13 means13 to13 limit13 the13 amount13 of13 incoming13 traffic
bull The13 server13 can13 prevent13 to13 become13 overloaded13 with13 too13 many13 tasks
bull The13 server13 does13 not13 need13 arficially13 slow13 down13 the13 client13 by13 sending13 late13 ACKsndash No13 need13 to13 keep13 track13 of13 delayed13 ACKsndash The13 server13 can13 perform13 other13 tasks13 instead
bull Reduced13 network13 traffic
Thank13 youQuesons
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-links-json-02txt
123
RFC 6690 (link-format) documents are somewhat foreign to many web app developerssect would prefer to have them in JSON format
There is no standard way to represent link-format documents in applicationssect but everyone knows how to handle JSON
Define a standard JSON translation for link-format
Itrsquos
not
rock
et
scien
ce
ltsensorsgtct=40title=Sensor Index ltsensorstempgtrt=temperature-cif=sensor ltsensorslightgtrt=light-luxif=sensor lthttpwwwexamplecomsensorst123gt anchor=sensorstemprel=describedby lttgtanchor=sensorstemprel=alternate [hrefsensorsct40titleSensor Index hrefsensorstemprttemperature-cifsensor hrefsensorslightrtlight-luxifsensor hrefhttpwwwexamplecomsensorst123 anchorsensorstempreldescribedby hreftanchorsensorstemprelalternate]
124
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-ipsec-for-coap-00txt
IPsec definitions for CoAP Mostly placeholder at this time Who has implementation experience with this
125
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-cross-reverse-convention-00txt
This draft has two lines of payload(based on a WGLC comment by Cullen Jennings)
coap12344567foobara=3
httpwwwproxycomwellknowncore-translate1234_4567foobara=3
Is that a useful convention to have
126
Insert CI slides here
127
128
0
5
10
15
20
25
30
35
40
10 20 30 40 50 60 70
good
put (
pps)
pps
Goodput vs pps (Econotags)
goodput
[Khattak preliminary]
Congestion Control
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-cocoa-00txt
ldquoadvancedrdquo cc (The draft is just a first shot) Others may have better ideas
129
Insert post-WGLC discussion slides here
130
Stop Continue Start
131
An Agile Retrospective
http6lowappnet coreIETF86 2013-03-12-13
Stop
132
Endless new CoAP optionssect instead use RESTful as much as possible
Move general security lifecycle out Looking at theoretical problems
http6lowappnet coreIETF86 2013-03-12-13
Continue
Interops Running code Look at real-world examples and deployments Solve their actual problems
sect Unilateral enhancements eg higher performance congestion control
sect Transports (SMS hellip)sect Make Web linking and Directories more and more usefulsect RESTful Design Paradigms for real-world problems
133
http6lowappnet coreIETF86 2013-03-12-13
Start
Further push into the (browser) web world (HTML5 browser security)
Specific supporting worksect SenMLsect URI work (dev URN hellip)sect Security Processes (next slide)
Spin outsect (We donrsquot really get to decide where this is done)
134
http6lowappnet coreIETF86 2013-03-12-13
Security
Integrate Application Network Group Keyingsect Tunnel-free setup
Donrsquot redo what has been done alreadysect ZigBee IP is finesect But what about other scenarios
Simple REST interfaces for working with keying materials and authorizationsect Start with defining objectives
Object Security for Constrained Nodes135
Re-chartering CoREWhat do we want to do now that wersquore grown up
Zach ShelbyCoRE WG IETF-86 Orlando
What is the scope
bull So we have a protocol and Web Linking what next
bull Keep with what we know besthellip1 Enhancements around CoAP2 New transports for CoAP3 New representations for Web Links4 General application layer solutions
CoRE WG IETF-86 Orlando 2
Enhancements around CoAP
bull Advanced congestion control
CoRE WG IETF-86 Orlando 3
New Transports for CoAP
bull Infrastructure for CoAP over foondash httptoolsietforgiddraft-silverajan-core-
coap-alternative-transports-01txtbull CoAP over SMS
ndash httptoolsietforgiddraft-becker-core-coap-sms-gprs-03txt
ndash OMA Lightweightbull CoAP over TCP
ndash httptoolsietforgiddraft-li-core-coap-payload-length-option-01txt
CoRE WG IETF-86 Orlando 4
New support for Web Links
bull JSON Web Linksndash httptoolsietforgiddraft-bormann-core-links-
json-02txt
2332010 CoRE WG IETF-77 Anaheim 5
General application layer solutions
bull Resource Directoryndash httptoolsietforgiddraft-shelby-core-
resource-directory-05txtndash OMA Lightweight
2332010 CoRE WG IETF-77 Anaheim 6
Definitions (22)
n Reverse Proxy a receiving agent that acts as a layer above some other server(s) and translates the received requests to the underlying servers protocol It behaves as an origin (HTTP) server on its connection towards the (HTTP) client and as a (CoAP) client on its connection towards the (CoAP) origin server The (HTTP) client uses the origin-form [I-Dietf-httpbis-p1-messaging] as a request- target URI
n Reverse and Forward proxies are technically very similar with main differences being that the former appears to a client as an origin server while the latter does not and that clients may be unaware they are communicating with a proxy
Reverse Cross-Protocol Proxy Deployment Scenario
HTTP-CoAP Response Code Mapping
Implementation Experience
n Direct experience from the draft authorsn Squid HTTP-CoAP mapping module
n University of Padovan httptelecomdeiunipditiotn Both Forward and Interception operation supported
n HTTP-CoAP proxy based on EvCoAPn KoanLogic University of Bologna and Salvatore
Loreto (as individual)n httpsgithubcomkoanlogicwebthingstreemasterbridgesw
libevcoapn The document is open to input from other implementations
Next Steps
n Does the WG recommend adoptionn Intended status Informational Best Practicen Purpose Reduce arbitrary variation between proxy
implementations thereby increasing interoperability
Backup
HTTP to CoAP URI Mapping Options (12)
n Embedded Mapping n In an embedded mapping approach the HTTP URI has embedded
inside it the authority and path part of the CoAP URI n Example The CoAP resource nodecoapsomethingnetfoo can
be accessed by an HTTP client by inserting in the request httphc-proxysomethingnetcoapnodecoapsomethingnetfoo The Cross-Protocol Proxy then maps the URI to coapnodecoapsomethingnetfoo
HTTP to CoAP URI Mapping Options (22)
n Homogeneous Mapping n In a homogeneous mapping approach only the scheme portion of the URI
needs to be mapped The rest of the URI (ie authority path etc) remains unchanged
n Example The CoAP resource coapnodecoapsomethingnetfoo can be accessed by an HTTP client by requesting httpnodecoapsomethingnetfoo The Cross-Protocol Proxy receiving the request is responsible to map the URI to coapnodecoapsomethingnetfoo
n Background info n The assumption in this case is that the HTTP client would be able to
successfully resolve nodecoapsomethingnet using DNS infrastructure to return the IP address of the HC proxy Most likely this would be through a two step DNS lookup where the first DNS lookup would resolve somethingnet using public DNS infrastructure
n Then the second DNS lookup on the subdomain coap and the host node would typically be resolved by a DNS server operated by the owner of domain somethingnet So this domain owner can manage its own internal node names and subdomain allocation which would correspond to the CoAP namespace
Group 3 ldquonew workrdquo
39
Transport of CoAP over SMS USSD and GPRSdraft-becker-core-coap-sms-gprs-03
Markus Becker Kepeng LiKoojana Kuladinithi Thomas Poumltsch
CoRE WG IETF-86 Orlando
1 10
ScenariosI In M2M communication IP connectivity is not alwayssupported by the constrained end-points
I Power savingI Coverage (GPRS 3G LTE)
I SMS and USSD based communication is almost alwayssupported
210
Changes from draft-01 to draft-03 (1)
I Added possible CONNONACK interactions Section 5
I Option name changed from Reply-To- to Response-To-Section 16 and Section 101
I Added URI schemeEg coap+tel+15105550101well-knowncore Section 11
I Added possible M2M proxy scenarios Section 14
3 10
Changes from draft-01 to draft-03 (2)
I Added reference to bormann-coap-misc for other SMSencoding Section 71
I Updated requirements on Uri-Host and Uri-Port forcoap+tel Section 10
I Added security considerations Transport and ObjectSecurity Section 15
I Chose CoAP option numbers and updated the optionnumber table to meet draft-ietf-core-coap-10 Table 1
I Added an IANA registration for the URI scheme coap+telSection 162
4 10
Feedback Split coap+tel into coap+smsand coap+ussd
I How else to differ the various transports in the URII Or is the transport to use decided by the implementationI See alsodraft-silverajan-core-coap-alternative-transports-01
5 10
Feedback Response-To-Scheme option
I Should there be a Response-To-Scheme optionadditionally to Response-To-Uri-Host andResponse-To-Uri-Path
I So that a CoAP end-point which receives a request by CoAPover non-IP transport can be instructed to also use thenon-IP transport for the response
I This would imply to add aResponse-To-Telephone-Subscriber and more options forother transports that have other URI schemes than coapand coaps
6 10
Feedback Selection of Transport by Client
I When a server is reachable by various transports howdoes a client decide which transport to use
I Client-side application congurationI Leave it to a proxy which uses cellular network lookupfunctions
7 10
Feedback Potential Threats
I Trigger expensive short messagesI Redirect trac to other addressesI More threats
I Are the security measures in the draft adequateI Whitelisting on serverI Relying on cellular network security (dedicated M2M APNs)I Object security on CoAP payload
8 10
Feedback Message Exchanges
I Figures 11-18 show possible message exchanges whenclient and server have two addresses
I With NON Not using CoAP retransmission capabilityI ACK on different transportI Additional (costly) message on Transport AI Request with Content
I Which ones are allowedI Which ones are meaningful
9 10
Next steps
I Rene Uri schemeI Response-To-Scheme optionI Selection of Message ExchangeI Rene Proxying
10 10
CoAP13 Communicaon13 with13 Alternave13 Transports
Bill Silverajan and Teemu SavolainenCore WG IETF 86 Orlando
031113
Objecves13 (In13 Scope)
bull Unambiguous13 representaon13 of13 transport13 to13 be13 used13 by13 CoAP
bull Details13 how13 the13 transport13 can13 carry13 CoAP13 packet
bull Focus13 is13 on13 what13 CoAP13 communicaons13 requirements13 are
bull Allow13 CoAP13 mechanisms13 to13 exploit13 cross-shy‐layer13 opmisaons
51
031113
Non13 Goals13 (Not13 in13 scope)
bull Applicaon-shy‐level13 QoS13 requirementsbull Real-shy‐me13 constraintsbull Ordering13 reliability13 congeson13 controlbull Applicaon13 and13 network13 adaptaonbull Mobility13 and13 readdressing13 supportbull Network13 protocol13 (eg13 IPsec)13 configuraon
52
031113
Use13 Cases
bull NAT13 and13 Firewall13 traversal13 with13 TCPbull Delay13 Tolerant13 Networkingbull Non-shy‐IP13 Low13 Energy13 Protocols
53
031113
Related13 Work
bull OMA13 Lightweight13 M2M13 Protocolbull CoAP13 over13 SMSGPRSUSSD
54
031113
What13 does13 the13 work13 entail
bull The13 ability13 to13 specify13 end13 point13 idenfiers13 and13 URIs13 to13 reflect13 which13 transport13 CoAP13 can13 use
bull The13 ability13 to13 register13 to13 resource13 directories13 resource13 types13 reflecng13 types13 of13 transport13 available
bull Ability13 for13 mul-shy‐transport13 nodes13 to13 select13 transport13 to13 use13 without13 significant13 alteraon13 to13 CoAP13 packet13 structure
55
031113
Points13 to13 consider
bull Requirements13 for13 transport13 layer13 protocol13 to13 carry13 CoAP13 packets
bull Representaon13 of13 URI13 scheme13 for13 generic13 transport13 protocols
bull Opon13 extensions13 for13 CoAP13 to13 express13 available13 transports
bull Mapping13 and13 message13 sizebull Security13 consideraons
56
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
URI13 =13 scheme13 13 13 authority13 path-shy‐abempty13 [13 query13 ]
bull Within13 the13 scheme13 namebull In13 the13 URI13 pathbull As13 a13 query13 component
57
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
bull Within13 the13 scheme13 namendash coap+tel+15105550101well-shy‐knowncorendash coap+tcpexamplecom5683temperaturendash coap+blel2cap[1234567890AB]4pulse
bull Easy13 URI13 parsing13 for13 transport13 type13 and13 idenfier
bull Each13 new13 scheme13 name13 requires13 IANA13 registraon
58
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
bull In13 the13 URI13 pathndash coaphostexamplecomtransport=tcpwell-shy‐knowncorert=core-shy‐rd
bull Easy13 adopon13 of13 new13 (and13 experimental)13 CoAP13 transports13 without13 IANA13 registraon
bull Caveat13 Uri-shy‐Path13 opon13 is13 a13 Crical13 CoAP13 opon13 see13 secon13 54113 of13 I-shy‐Diep-shy‐core-shy‐coap
59
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
bull As13 a13 URI13 query13 componentndash coaphostexamplecomwell-shy‐knowncorert=core-shy‐rdq=tcp
bull Also13 easy13 to13 adopt13 new13 (and13 experimental)13 CoAP13 transports13 without13 IANA13 registraon
bull Caveat13 Uri-shy‐Query13 opon13 is13 a13 Crical13 CoAP13 opon13 see13 secon13 54113 of13 I-shy‐Diep-shy‐core-shy‐coap
60
031113
URI13 Representaons13 for13 CoAPNon13 standard13 ways
bull Transport13 in13 the13 URI13 authority13 componentndash coaphost[port][transport]13 instead13 of13 coaphost[port]
bull Transport13 as13 a13 service13 URLndash servicecoaptcphostexamplecomwell-shy‐knowncorert=core-shy‐rd
bull Above13 two13 ways13 break13 exisng13 compability13 (although13 both13 are13 based13 on13 valid13 IANA13 URI13 registraons)
61
031113
URI13 Representaons13 for13 CoAPMiscellaneous13 Consideraons
bull Ensure13 that13 transport13 is13 defined13 unambiguously13 (eg13 L2CAP13 used13 by13 both13 BLE13 and13 standard13 Bluetooth13 so13 avoid13 rdquocoap+l2caprdquo13 or13 rdquotransport=l2caprdquo13 or13 rdquoq=l2caprdquondash Can13 be13 done13 as13 WG13 consensusndash Namespace13 approach13 eg13 rdquocoap+blel2caprdquo13 or13 rdquoq=blel2caprdquo
bull Allow13 end-shy‐points13 to13 use13 CoAP13 Resource13 Directory13 to13 register13 alternave13 transports13 and13 idenfiers13 and13 provide13 periodic13 updatesndash Register13 rdquocore-shy‐transportrdquo13 resource13 type
62
031113
Transport13 Consideraons
bull Uniqueness13 of13 end-shy‐point13 idenficaonbull Communicaon13 support13 Unidireconal13 Bidireconal13 1N13 (broadcast13 mulcast13 anycast)13 messaging
bull Binary13 encoding13 Network13 byte13 orderingbull MTU13 correlaon13 with13 CoAP13 PDU13 sizebull Transport13 latency
63
031113
Security13 Consideraons
bull Drar13 does13 not13 introduce13 new13 security13 requirements13 by13 itself
bull There13 may13 be13 privacy13 issues13 if13 nodes13 use13 telephone13 numbers13 or13 MAC13 addresses13 as13 public13 end13 point13 idenfiers
64
Akbar Rahman
IETF 86 March 2013 httpwwwietforgiddraft-rahman-core-sleepy-02txt
Enhanced Sleepy Node Support for CoAP
Introduction
It is expected that in CoAP networks there will be a certain portion of devices that are sleepy and which may occasionally go into a sleep mode (ie go into a low power state to conserve power) and subsequently have reduced CoAP protocol communication ability
This I-D proposes a minimal and efficient mechanism building on the Resource Directory concept (which will be integrated into a CoAP Proxy) to enhance sleepy node support in CoAP networks
Main Question from IETF-85 (Atlanta)
What performance benefit does the proposed Sleepy Node support solution give in a network that already has standard CoAP caching enabled
Sleepy Node Performance Analysis
Experimental Network
1-5 clients
Both Sleepy and Non-
Sleepy servers
Sleepy Node Performance Analysis Network Setup
CoAPSleepyServer(s)
CoAPSleepAwareReverseProxy
CoAP
Client(s)
Request
Response
Sleep9AwareCoREResourceDirectoryCapability
PublishedSleepParameters
Sleep9AwareCoAPStoreandForwardCapability Response
Request
SleepAwareCoAP503ResponseCapability
CoAPCachingCapability
bull Server supports publishing sleep parameters to proxy bull Eg Irsquom going to be asleep for X seconds
bull Proxy supports sleep-awareness capabilities bull Proxy also supports caching capability based off of maxAge bull Protocol flow similar to approach of Figure 1 (Synchronous RD Based Sleep
Tracking) of I-D
Proxy capabilities can be selectively enableddisabled
Proxy ndash Server Interface
Client ndash Proxy Interface
CoAP Sleep-Aware Reverse Proxy Features CoRE Sleep-aware Resource Directory
Support storing published sleep parameters from CoAP servers sleepState (AWAKE ASLEEP) sleepDuration
Sleep-aware CoAP 503 Response Capability If CoAP request to a sleeping server is received proxy returns a
lsquo503 Retry-Afterrsquo response to client 503 contains a timestamp indicating when the sever will wake back up
(timestamp delivered in CoAP maxAge option) Sleep-aware CoAP Store-and-Forward Capability
If CoAP request to a sleeping server is received proxy stores request until server wakes up and then forwards it
Caching capability Cache GET responses from server if maxAge option is present
(this is not a sleep aware feature)
Goals of Performance Analysis
For networks having sleepy servers provide measurements to quantify the impact that CoAP sleep-awareness capabilities can have
See if sleep-awareness capabilities can
provide additional benefits even when CoAP caching is used
Overview of Performance Analysis Performed The analysis was broken up into a set of test scenarios Each test scenario used a different combination of the following
variables Client issued GET requests Server was configured as a sleepy or non-sleepy server Proxy caching of GET responses was enabled or disabled Proxy sleep-aware 503 response capability was enabled or disabled Proxy store-and-forward capability was enabled or disabled maxAge in GET responses ndash Two values were tested 60sec and 5sec of Clients ndash Two values were used ndash 1 client and 5 clients
For comparison purposes the following were held constant across all test scenarios Client issued a fixed number of requests (100) across all test scenarios Client used a delay between each GET request (35sec) to better exercise
proxyrsquos caching and sleep-awareness capabilities For sleepy server test scenarios the server slept 60 sec awake for 3 sec
Format of Results The following results were collected for each
test scenario
Breakdown of the and types of transactions occurring between clientproxyserver
ldquoGETrdquo ndash Test Scenario Results
GET ndash Description of Test Scenarios
TestScenarios-GET
Scenario
CoAPSleepyServerSe7ngs CoAPSleepAwareReverseProxySe7ngs CoAPClientSe7ngs
SleepDuragton(sec)
AwakeDuragton(sec)
maxAge(sec) Caching SleepAwareSAF+
503NumberofClients
NumberofGETs
DelayBetweenClient
Requests(sec)
1a 0 Always 60 Enabled Disabled 1 100 35
1b 60 3 60 Enabled Disabled 1 100 35
1c 60 3 60 Enabled Enabled 1 100 35
2a 0 Always 60 Enabled Disabled 5 100 35
2b 60 3 60 Enabled Disabled 5 100 35
2c 60 3 60 Enabled Enabled 5 100 35
3a 0 Always 5 Enabled Disabled 5 100 35
3b 60 3 5 Enabled Disabled 5 100 35
3c 60 3 5 Enabled Enabled 5 100 35
ldquoGETrdquo ndash Test Scenario 1 Results
maxAge = 60 and 1 Client
GET ndash Scenario 1 ClientProxy Interface Transaction Mix
Scenarios 1a - Non-Sleepy Server Caching Proxy maxAge = 60sec 1b- Sleepy Server Caching Proxy maxAge = 60sec 1c - Sleepy Server Sleep Aware Proxy maxAge = 60sec
Sleep Aware Proxy has better performance for sleepy servers
0
100
200
300
400
500
600
700
1a 1b 1c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
GET ndash Scenario 1 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
Scenarios 1a - Non-Sleepy Server Caching Proxy maxAge = 60sec 1b- Sleepy Server Caching Proxy maxAge = 60sec 1c - Sleepy Server Sleep Aware Proxy maxAge = 60sec
0
100
200
300
400
500
600
700
800
1a 1b 1c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
ldquoGETrdquo ndash Test Scenario 2 Results
maxAge = 60 and 5 Clients
GET ndash Scenario 2 ClientProxy Interface Transaction Mix
Sleep Aware Proxy has slightly better performance for sleepy servers
0
200
400
600
800
1000
1200
1400
2a 2b 2c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
Scenarios 2a - Non-Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2b- Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2c - Sleepy Server Sleep Aware Proxy maxAge = 60sec 5 Clients
See ldquoExperimental Artifactsrdquo Note 1
GET ndash Scenario 2 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has slightly better performance for sleepy servers
0
50
100
150
200
250
300
350
400
2a 2b 2c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
Scenarios 2a - Non-Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2b- Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2c - Sleepy Server Sleep Aware Proxy maxAge = 60sec 5 Clients
See ldquoExperimental Artifactsrdquo Note 2
Experimental Artifacts Note 1
Currently in the experiment the sleep aware proxy checks the cached state of a resource before putting a request into its Store-and-forward queue while a server is sleeping Once in the queue the proxy unconditionally forwards the queued requests to the server once it wakes up This is not the most efficient setup and can easily be improved If the proxy instead checks its cache again before forwarding each queued request it may not need to forward the request to the server For example if there are two queued GET requests in the proxyrsquos queue that address the same resource Only the first request needs to be sent to the server the second request can use the cached response from the first request
Note 2 Currently in the experiment the sleepy server sends a sleepState PUT request to the
proxy each time it goes to sleep This is not the most efficient setup and can easily be improved For example if the server assumes that the proxy can keep track of its ONOFF cycles with its internal timers (eg as per Fig 1 of I-D) then the number of messages from the sleepy server dramatically goes down
ldquoGETrdquo ndash Test Scenario 3 Results
maxAge = 5 and 5 Clients
GET ndash Scenario 3 ClientProxy Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
Scenarios 3a - Non-Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3b- Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3c - Sleepy Server Sleep Aware Proxy maxAge = 5sec 5 Clients
0
500
1000
1500
2000
2500
3000
3500
4000
4500
5000
3a 3b 3c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
GET ndash Scenario 3 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
0
1000
2000
3000
4000
5000
6000
7000
3a 3b 3c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
Scenarios 3a - Non-Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3b- Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3c - Sleepy Server Sleep Aware Proxy maxAge = 5sec 5 Clients
Conclusions
Conclusions These results show that sleep-aware CoAP
proxy features can significantly optimize communication with sleepy servers in most scenarios
These results also show that sleep-
awareness capabilities can provide additional benefits above and beyond CoAP caching in most scenarios
Backup
Current CoAP Support of Sleepy Node (12)
CoAP proxies can use a previously cached response to service a new GET request for a sleepy origin server (as in HTTP) But if no valid cache then proxy has to attempt to
retrieve and may fail if origin server is sleeping [I-Dietf-core-coap]
Clients can discover list of resources from RD (GET rd-lookuphellip) for sleepy servers But attempt to GET resource from sleepy origin server
may fail if origin server is sleeping [IDietf-core-link-format amp IDshelby-core-resource-
directory]
Current CoAP Support of Sleepy Node (22)
Lower layer support for sleepy nodes in most wireless technologies (eg WiFi ZigBee) But limited to MAC packet scheduling for sleepy nodes
and not aware of specific needs of IP applications (like CoAP)
Proposal ndash RD Based Sleep Tracking (14)
The current CoAP approach to support sleepy nodes can be significantly improved by introducing RD based mechanisms for a CoAP client to determine whether A targeted resource is located on a sleepy server A sleepy server is currently in sleep mode or not
There is any associated caching Proxy (possibly the RD itself) for a sleepy server
Proposal ndash RD Based Sleep Tracking (24)
We define the following new RD attributes to characterize the properties of a sleepy node SleepState - Indicates whether the node is currently in
sleep mode or not (ie Sleeping or Awake) SleepDuration - Indicates the maximum duration of time
that the node stays in sleep mode TimeSleeping - Indicates the length of time the node
has been sleeping (ie if Sleep State = Sleeping) NextSleep - Indicates the next time the node will go to
sleep (ie if Sleep State = Awake)
CachingProxy ndash Indicates the caching proxy of the sleepy node (ie the RD itself or another node)
Proposal ndash RD Based Sleep Tracking (34)
These attributes are all server (node) level and are new parameters added to the RD URI Template Variables
Finally we also define a new lookup-type (ss) for the RD lookup interface specified in [I-Dshelby-core-resource-directory] This new lookup-type supports looking up the
ldquoSleepStaterdquo (ss) of a specified end-point
Proposal ndash RD Based Sleep Tracking (44)
The three time based parameters (SleepDuration TimeSleeping NextSleep) can be based on either an absolute network time (for a time synchronized network) or a relative local time (measured at the local node)
Following the approach of [I-Dietf-core-link-format] and [I-Dshelby-core-resource-directory] sleep parameters for sleepy servers can be stored by the server in the RD and accessed by all interested clients
Examples of using these parameters in a synchronous or asynchronous manner are shown in the I-D
http6lowappnet coreIETF86 2013-03-12-13
We assume people have read the drafts
Meetings serve to advance difficult issues by making good use of face-to-face communications
Note Well Be aware of the IPR principles according to RFC 3979 and its updates
uumlBlue sheetsuumlScribe(s)
96
drar-shy‐iep-shy‐core-shy‐coapsubmiqed13 to13 IESG
2013-shy‐03-shy‐13
97
OMA Lightweight M2M Overview(A new standard using lots of IETF specs including DTLS
CoAP Block Observe Resource Directory SenMLhellip)
Zach ShelbyCoRE WG IETF-86 Orlando
OMA Lightweight M2Mbull Open Mobile Alliance is well known for Device Management (DM)bull OMA Lightweight M2M is a new standard from the alliance
ndash Focused on constrained Cellular and sensor network M2M devicesndash Driven by leading operators and vendors
bull Scopendash Interfaces protocol amp security between Device and Serverndash Object and Resource modelndash Bootstrap Device Access Control Connectivity and Firmware Objects
bull Draft Specifications are availablendash httpmemberopenmobileallianceorgftpPublic_documentsDM
LightweightM2MPermanent_documentsOMA-TS-LightweightM2M-V1_0_0-20130301-Dzip
bull Timelinendash Requirements and Architecture completed 3Q2012ndash Spec ready for Consistency Review 2Q2013ndash Candidate Approval expected 3Q2013
2 CoRE WG IETF-86 Orlando
Architecture
3
Scope of LWM2M
CoRE WG IETF-86 Orlando
Object Model
bull A Client has one or more Object Instancesbull An Object is a collection of Resourcesbull A Resource is an atomic piece of information
ndash Read Written or Executed
bull Resources can have multiple instancesbull Objects and Resources are identified by a
16-bit Integer Instances by an 8-bit Integerbull ObjectsResources are accessed with
simple URIs Object IDObject InstanceResource ID
eg 1213
4 CoRE WG IETF-86 Orlando
CoRE WG IETF-86 Orlando
CoRE Resource Directory
draft-shelby-core-resource-directory-05
Z Shelby C Bormann S Krco
Backgroundbull Not a new concept
ndash think web search engine or any link directorybull Defines the interfaces to a Resource Directorybull Based on Web Linking framework and the CoRE Link Formatbull Generic REST design for use over HTTP and CoAPbull Used by OMA Lightweight M2Mbull Has already been deployed
ndash In traffic monitoring systemsndash In street lighting systemsndash For vehicular asset trackingndash By a major Cellular M2M operator
Changes since -04
bull Restricted Update to parameter updatesbull Added pagination support for the Lookup interfacebull Changed rt= to et= for the registration amp update
interfacebull Added group support
Group Management
bull RD now includes group management featuresbull New Group Function Set
ndash Register a groupbull Group name domain multicast address endpoint members
ndash Remove a groupbull Group lookup using the Lookup Function Set
ndash List registered groupsndash Find the members of a groupndash Find groups with certain endpoints or resources
Registering a Group
EP RD
| |
| - POST rd-groupgp=lights ltgtep=node1 --gt |
| |
| |
| lt---- 201 Created Location rd-group12 ---- |
| |
Req POST coaprdexamplecomrd-groupgp=lights
Payload
ltgtep=node1
ltgtep=node2
Res 201 Created
Location rd-group12
Looking up Group Members
Client RD
| |
| ----- GET rd-lookupepgp=lights1 ----------------------gt |
| |
| |
| lt-- 205 Content ltrdgtd=domain1ltrdgtd=domain2 --------- |
| |
Req GET rd-lookupepgp=lights1
Res 205 Content
ltcoaphostportgtep=node1
ltcoaphostportgtep=node2rdquo
Things for the futurebull Support for JSON representation of Web Links
ndash httptoolsietforgiddraft-bormann-core-links-json-02txtbull Registry for RD registration query parameters
ndash Already OMA Lightweight has defined some new onesbull More examples
Group 3 ldquonew workrdquo(continued)
109
drar-shy‐greevenbosch-shy‐core-shy‐profile-shy‐descripon-shy‐01Bert13 GreevenboschJeroen13 Hoebeke
Isam13 IshaqFloris13 Van13 den13 Abeele
Descripon
bull JSON13 format13 for13 signalling13 the13 servers13 capabilies
bull Signalling13 of13 supported13 opons13 media13 types13 and13 block13 sizendash Other13 items13 can13 be13 added
bull Filtering13 on13 specific13 fields13 through13 URI-shy‐Querybull Link13 hqpdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐profile-shy‐descripon
well-shy‐knownprofile
bull To13 acquire13 profile13 data13 of13 resources13 on13 a13 parcular13 service13 the13 well-shy‐knownprofile13 URI-shy‐path13 is13 introduced
bull For13 example13 to13 get13 all13 informaon13 from13 sensors13 served13 by13 wwwexampleorg13 we13 can13 do13 a13 GET13 to13 coapwwwexampleorgwell-shy‐knownprofile
bull Filtering13 on13 parcular13 resources13 is13 done13 through13 URI-shy‐Queries
Format
bull Currently13 the13 following13 fields13 are13 definedndash ldquopathrdquo13 contains13 the13 URI-shy‐path13 associated13 with13 a13 resource
ndash ldquooprdquo13 a13 numerical13 list13 of13 supported13 opon13 numbers
ndash ldquocfrdquo13 a13 numerical13 list13 of13 supported13 content-shy‐format13 numbers
ndash ldquob1srdquo13 ldquob2srdquo13 supported13 block13 sizes13 for13 Block113 and13 Block213 respecvely
Examplebull On13 the13 right13 is13 an13 example13 of13 a13 camera13 sensor13 at13 coapwwwexampleorgcam13 that13 supports13 the13 Uri-shy‐Host13 (3)13 ETag13 (4)13 Uri-shy‐Port13 (7)13 Uri-shy‐Path13 (11)13 Content-shy‐Format13 (12)13 Token13 (19)13 Block213 (23)13 and13 Proxy-shy‐Uri13 (35)13 opons
bull The13 supported13 content13 formats13 are13 textplain13 (0)13 applicaon13 link-shy‐format13 (40)13 and13 applicaonjson13 (50)
bull The13 supported13 Block213 can13 use13 25613 or13 51213 byte13 blocks
Req13 GET13 coapwwwexampleorgwell-shy‐knownprofile13 Res13 20513 Content13 (applicationjson)13 13 13 13 profile13 13 13 13 13 13 13 13 pathcam13 13 13 13 op[3471112192335]13 13 13 13 13 cf[04050]13 13 13 13 13 b2s[45]13 13 13 13
Filtering13 through13 use13 of13 URI-shy‐Query
bull Filtering13 can13 be13 done13 through13 the13 URI-shy‐Querybull Query13 format13 N=V
ndash N13 is13 a13 profile13 fieldndash V13 is13 the13 desired13 value
bull Examplesndash To13 find13 resources13 that13 support13 content13 format13 ldquoapplicaonjsonrdquo
13 GET13 wwwexampleorgwell-shy‐knownprofilecf=50ndash To13 get13 informaon13 about13 the13 camera
13 GET13 wwwexampleorgwell-shy‐knownprofilepath=cam
Open13 issues
bull Which13 other13 profile13 data13 needs13 signallingndash Content-shy‐type13 for13 different13 methods
bull Fix13 the13 order13 in13 which13 the13 profile13 fields13 must13 appearndash Non-shy‐fixed13 order13 easier13 extensible
bull Inheritance13 of13 a13 profile13 descriponbull Extend13 usage13 to13 signal13 the13 client13 profilebull Integraon13 with13 link13 format
Thank13 youQuesons
drar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval-shy‐00
Bert13 Greevenbosch
Descripon
bull The13 ldquoMinimumRequestInterval13 opon13 can13 be13 used13 to13 indicate13 the13 minimum13 me13 between13 two13 requests13 in13 a13 transacon
bull Originally13 intended13 for13 Block13 but13 also13 usable13 for13 other13 transaconsndash Example13 browsing13 a13 server
bull The13 goal13 is13 to13 reduce13 the13 server13 load13 and13 network13 traffic
bull Link13 hqpsdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval
Usage
bull The13 client13 keeps13 the13 server13 informed13 about13 its13 request13 speed13 through13 inclusion13 of13 the13 ldquoMinimumRequestIntervalrdquo13 opon
bull In13 responses13 the13 server13 fixes13 the13 minimum13 request13 interval13 through13 the13 same13 opon
bull The13 client13 obeys13 the13 speed13 indicated13 by13 the13 server
bull The13 client13 can13 send13 slower13 but13 not13 faster
Advantages
bull The13 server13 has13 means13 to13 limit13 the13 amount13 of13 incoming13 traffic
bull The13 server13 can13 prevent13 to13 become13 overloaded13 with13 too13 many13 tasks
bull The13 server13 does13 not13 need13 arficially13 slow13 down13 the13 client13 by13 sending13 late13 ACKsndash No13 need13 to13 keep13 track13 of13 delayed13 ACKsndash The13 server13 can13 perform13 other13 tasks13 instead
bull Reduced13 network13 traffic
Thank13 youQuesons
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-links-json-02txt
123
RFC 6690 (link-format) documents are somewhat foreign to many web app developerssect would prefer to have them in JSON format
There is no standard way to represent link-format documents in applicationssect but everyone knows how to handle JSON
Define a standard JSON translation for link-format
Itrsquos
not
rock
et
scien
ce
ltsensorsgtct=40title=Sensor Index ltsensorstempgtrt=temperature-cif=sensor ltsensorslightgtrt=light-luxif=sensor lthttpwwwexamplecomsensorst123gt anchor=sensorstemprel=describedby lttgtanchor=sensorstemprel=alternate [hrefsensorsct40titleSensor Index hrefsensorstemprttemperature-cifsensor hrefsensorslightrtlight-luxifsensor hrefhttpwwwexamplecomsensorst123 anchorsensorstempreldescribedby hreftanchorsensorstemprelalternate]
124
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-ipsec-for-coap-00txt
IPsec definitions for CoAP Mostly placeholder at this time Who has implementation experience with this
125
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-cross-reverse-convention-00txt
This draft has two lines of payload(based on a WGLC comment by Cullen Jennings)
coap12344567foobara=3
httpwwwproxycomwellknowncore-translate1234_4567foobara=3
Is that a useful convention to have
126
Insert CI slides here
127
128
0
5
10
15
20
25
30
35
40
10 20 30 40 50 60 70
good
put (
pps)
pps
Goodput vs pps (Econotags)
goodput
[Khattak preliminary]
Congestion Control
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-cocoa-00txt
ldquoadvancedrdquo cc (The draft is just a first shot) Others may have better ideas
129
Insert post-WGLC discussion slides here
130
Stop Continue Start
131
An Agile Retrospective
http6lowappnet coreIETF86 2013-03-12-13
Stop
132
Endless new CoAP optionssect instead use RESTful as much as possible
Move general security lifecycle out Looking at theoretical problems
http6lowappnet coreIETF86 2013-03-12-13
Continue
Interops Running code Look at real-world examples and deployments Solve their actual problems
sect Unilateral enhancements eg higher performance congestion control
sect Transports (SMS hellip)sect Make Web linking and Directories more and more usefulsect RESTful Design Paradigms for real-world problems
133
http6lowappnet coreIETF86 2013-03-12-13
Start
Further push into the (browser) web world (HTML5 browser security)
Specific supporting worksect SenMLsect URI work (dev URN hellip)sect Security Processes (next slide)
Spin outsect (We donrsquot really get to decide where this is done)
134
http6lowappnet coreIETF86 2013-03-12-13
Security
Integrate Application Network Group Keyingsect Tunnel-free setup
Donrsquot redo what has been done alreadysect ZigBee IP is finesect But what about other scenarios
Simple REST interfaces for working with keying materials and authorizationsect Start with defining objectives
Object Security for Constrained Nodes135
Re-chartering CoREWhat do we want to do now that wersquore grown up
Zach ShelbyCoRE WG IETF-86 Orlando
What is the scope
bull So we have a protocol and Web Linking what next
bull Keep with what we know besthellip1 Enhancements around CoAP2 New transports for CoAP3 New representations for Web Links4 General application layer solutions
CoRE WG IETF-86 Orlando 2
Enhancements around CoAP
bull Advanced congestion control
CoRE WG IETF-86 Orlando 3
New Transports for CoAP
bull Infrastructure for CoAP over foondash httptoolsietforgiddraft-silverajan-core-
coap-alternative-transports-01txtbull CoAP over SMS
ndash httptoolsietforgiddraft-becker-core-coap-sms-gprs-03txt
ndash OMA Lightweightbull CoAP over TCP
ndash httptoolsietforgiddraft-li-core-coap-payload-length-option-01txt
CoRE WG IETF-86 Orlando 4
New support for Web Links
bull JSON Web Linksndash httptoolsietforgiddraft-bormann-core-links-
json-02txt
2332010 CoRE WG IETF-77 Anaheim 5
General application layer solutions
bull Resource Directoryndash httptoolsietforgiddraft-shelby-core-
resource-directory-05txtndash OMA Lightweight
2332010 CoRE WG IETF-77 Anaheim 6
Reverse Cross-Protocol Proxy Deployment Scenario
HTTP-CoAP Response Code Mapping
Implementation Experience
n Direct experience from the draft authorsn Squid HTTP-CoAP mapping module
n University of Padovan httptelecomdeiunipditiotn Both Forward and Interception operation supported
n HTTP-CoAP proxy based on EvCoAPn KoanLogic University of Bologna and Salvatore
Loreto (as individual)n httpsgithubcomkoanlogicwebthingstreemasterbridgesw
libevcoapn The document is open to input from other implementations
Next Steps
n Does the WG recommend adoptionn Intended status Informational Best Practicen Purpose Reduce arbitrary variation between proxy
implementations thereby increasing interoperability
Backup
HTTP to CoAP URI Mapping Options (12)
n Embedded Mapping n In an embedded mapping approach the HTTP URI has embedded
inside it the authority and path part of the CoAP URI n Example The CoAP resource nodecoapsomethingnetfoo can
be accessed by an HTTP client by inserting in the request httphc-proxysomethingnetcoapnodecoapsomethingnetfoo The Cross-Protocol Proxy then maps the URI to coapnodecoapsomethingnetfoo
HTTP to CoAP URI Mapping Options (22)
n Homogeneous Mapping n In a homogeneous mapping approach only the scheme portion of the URI
needs to be mapped The rest of the URI (ie authority path etc) remains unchanged
n Example The CoAP resource coapnodecoapsomethingnetfoo can be accessed by an HTTP client by requesting httpnodecoapsomethingnetfoo The Cross-Protocol Proxy receiving the request is responsible to map the URI to coapnodecoapsomethingnetfoo
n Background info n The assumption in this case is that the HTTP client would be able to
successfully resolve nodecoapsomethingnet using DNS infrastructure to return the IP address of the HC proxy Most likely this would be through a two step DNS lookup where the first DNS lookup would resolve somethingnet using public DNS infrastructure
n Then the second DNS lookup on the subdomain coap and the host node would typically be resolved by a DNS server operated by the owner of domain somethingnet So this domain owner can manage its own internal node names and subdomain allocation which would correspond to the CoAP namespace
Group 3 ldquonew workrdquo
39
Transport of CoAP over SMS USSD and GPRSdraft-becker-core-coap-sms-gprs-03
Markus Becker Kepeng LiKoojana Kuladinithi Thomas Poumltsch
CoRE WG IETF-86 Orlando
1 10
ScenariosI In M2M communication IP connectivity is not alwayssupported by the constrained end-points
I Power savingI Coverage (GPRS 3G LTE)
I SMS and USSD based communication is almost alwayssupported
210
Changes from draft-01 to draft-03 (1)
I Added possible CONNONACK interactions Section 5
I Option name changed from Reply-To- to Response-To-Section 16 and Section 101
I Added URI schemeEg coap+tel+15105550101well-knowncore Section 11
I Added possible M2M proxy scenarios Section 14
3 10
Changes from draft-01 to draft-03 (2)
I Added reference to bormann-coap-misc for other SMSencoding Section 71
I Updated requirements on Uri-Host and Uri-Port forcoap+tel Section 10
I Added security considerations Transport and ObjectSecurity Section 15
I Chose CoAP option numbers and updated the optionnumber table to meet draft-ietf-core-coap-10 Table 1
I Added an IANA registration for the URI scheme coap+telSection 162
4 10
Feedback Split coap+tel into coap+smsand coap+ussd
I How else to differ the various transports in the URII Or is the transport to use decided by the implementationI See alsodraft-silverajan-core-coap-alternative-transports-01
5 10
Feedback Response-To-Scheme option
I Should there be a Response-To-Scheme optionadditionally to Response-To-Uri-Host andResponse-To-Uri-Path
I So that a CoAP end-point which receives a request by CoAPover non-IP transport can be instructed to also use thenon-IP transport for the response
I This would imply to add aResponse-To-Telephone-Subscriber and more options forother transports that have other URI schemes than coapand coaps
6 10
Feedback Selection of Transport by Client
I When a server is reachable by various transports howdoes a client decide which transport to use
I Client-side application congurationI Leave it to a proxy which uses cellular network lookupfunctions
7 10
Feedback Potential Threats
I Trigger expensive short messagesI Redirect trac to other addressesI More threats
I Are the security measures in the draft adequateI Whitelisting on serverI Relying on cellular network security (dedicated M2M APNs)I Object security on CoAP payload
8 10
Feedback Message Exchanges
I Figures 11-18 show possible message exchanges whenclient and server have two addresses
I With NON Not using CoAP retransmission capabilityI ACK on different transportI Additional (costly) message on Transport AI Request with Content
I Which ones are allowedI Which ones are meaningful
9 10
Next steps
I Rene Uri schemeI Response-To-Scheme optionI Selection of Message ExchangeI Rene Proxying
10 10
CoAP13 Communicaon13 with13 Alternave13 Transports
Bill Silverajan and Teemu SavolainenCore WG IETF 86 Orlando
031113
Objecves13 (In13 Scope)
bull Unambiguous13 representaon13 of13 transport13 to13 be13 used13 by13 CoAP
bull Details13 how13 the13 transport13 can13 carry13 CoAP13 packet
bull Focus13 is13 on13 what13 CoAP13 communicaons13 requirements13 are
bull Allow13 CoAP13 mechanisms13 to13 exploit13 cross-shy‐layer13 opmisaons
51
031113
Non13 Goals13 (Not13 in13 scope)
bull Applicaon-shy‐level13 QoS13 requirementsbull Real-shy‐me13 constraintsbull Ordering13 reliability13 congeson13 controlbull Applicaon13 and13 network13 adaptaonbull Mobility13 and13 readdressing13 supportbull Network13 protocol13 (eg13 IPsec)13 configuraon
52
031113
Use13 Cases
bull NAT13 and13 Firewall13 traversal13 with13 TCPbull Delay13 Tolerant13 Networkingbull Non-shy‐IP13 Low13 Energy13 Protocols
53
031113
Related13 Work
bull OMA13 Lightweight13 M2M13 Protocolbull CoAP13 over13 SMSGPRSUSSD
54
031113
What13 does13 the13 work13 entail
bull The13 ability13 to13 specify13 end13 point13 idenfiers13 and13 URIs13 to13 reflect13 which13 transport13 CoAP13 can13 use
bull The13 ability13 to13 register13 to13 resource13 directories13 resource13 types13 reflecng13 types13 of13 transport13 available
bull Ability13 for13 mul-shy‐transport13 nodes13 to13 select13 transport13 to13 use13 without13 significant13 alteraon13 to13 CoAP13 packet13 structure
55
031113
Points13 to13 consider
bull Requirements13 for13 transport13 layer13 protocol13 to13 carry13 CoAP13 packets
bull Representaon13 of13 URI13 scheme13 for13 generic13 transport13 protocols
bull Opon13 extensions13 for13 CoAP13 to13 express13 available13 transports
bull Mapping13 and13 message13 sizebull Security13 consideraons
56
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
URI13 =13 scheme13 13 13 authority13 path-shy‐abempty13 [13 query13 ]
bull Within13 the13 scheme13 namebull In13 the13 URI13 pathbull As13 a13 query13 component
57
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
bull Within13 the13 scheme13 namendash coap+tel+15105550101well-shy‐knowncorendash coap+tcpexamplecom5683temperaturendash coap+blel2cap[1234567890AB]4pulse
bull Easy13 URI13 parsing13 for13 transport13 type13 and13 idenfier
bull Each13 new13 scheme13 name13 requires13 IANA13 registraon
58
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
bull In13 the13 URI13 pathndash coaphostexamplecomtransport=tcpwell-shy‐knowncorert=core-shy‐rd
bull Easy13 adopon13 of13 new13 (and13 experimental)13 CoAP13 transports13 without13 IANA13 registraon
bull Caveat13 Uri-shy‐Path13 opon13 is13 a13 Crical13 CoAP13 opon13 see13 secon13 54113 of13 I-shy‐Diep-shy‐core-shy‐coap
59
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
bull As13 a13 URI13 query13 componentndash coaphostexamplecomwell-shy‐knowncorert=core-shy‐rdq=tcp
bull Also13 easy13 to13 adopt13 new13 (and13 experimental)13 CoAP13 transports13 without13 IANA13 registraon
bull Caveat13 Uri-shy‐Query13 opon13 is13 a13 Crical13 CoAP13 opon13 see13 secon13 54113 of13 I-shy‐Diep-shy‐core-shy‐coap
60
031113
URI13 Representaons13 for13 CoAPNon13 standard13 ways
bull Transport13 in13 the13 URI13 authority13 componentndash coaphost[port][transport]13 instead13 of13 coaphost[port]
bull Transport13 as13 a13 service13 URLndash servicecoaptcphostexamplecomwell-shy‐knowncorert=core-shy‐rd
bull Above13 two13 ways13 break13 exisng13 compability13 (although13 both13 are13 based13 on13 valid13 IANA13 URI13 registraons)
61
031113
URI13 Representaons13 for13 CoAPMiscellaneous13 Consideraons
bull Ensure13 that13 transport13 is13 defined13 unambiguously13 (eg13 L2CAP13 used13 by13 both13 BLE13 and13 standard13 Bluetooth13 so13 avoid13 rdquocoap+l2caprdquo13 or13 rdquotransport=l2caprdquo13 or13 rdquoq=l2caprdquondash Can13 be13 done13 as13 WG13 consensusndash Namespace13 approach13 eg13 rdquocoap+blel2caprdquo13 or13 rdquoq=blel2caprdquo
bull Allow13 end-shy‐points13 to13 use13 CoAP13 Resource13 Directory13 to13 register13 alternave13 transports13 and13 idenfiers13 and13 provide13 periodic13 updatesndash Register13 rdquocore-shy‐transportrdquo13 resource13 type
62
031113
Transport13 Consideraons
bull Uniqueness13 of13 end-shy‐point13 idenficaonbull Communicaon13 support13 Unidireconal13 Bidireconal13 1N13 (broadcast13 mulcast13 anycast)13 messaging
bull Binary13 encoding13 Network13 byte13 orderingbull MTU13 correlaon13 with13 CoAP13 PDU13 sizebull Transport13 latency
63
031113
Security13 Consideraons
bull Drar13 does13 not13 introduce13 new13 security13 requirements13 by13 itself
bull There13 may13 be13 privacy13 issues13 if13 nodes13 use13 telephone13 numbers13 or13 MAC13 addresses13 as13 public13 end13 point13 idenfiers
64
Akbar Rahman
IETF 86 March 2013 httpwwwietforgiddraft-rahman-core-sleepy-02txt
Enhanced Sleepy Node Support for CoAP
Introduction
It is expected that in CoAP networks there will be a certain portion of devices that are sleepy and which may occasionally go into a sleep mode (ie go into a low power state to conserve power) and subsequently have reduced CoAP protocol communication ability
This I-D proposes a minimal and efficient mechanism building on the Resource Directory concept (which will be integrated into a CoAP Proxy) to enhance sleepy node support in CoAP networks
Main Question from IETF-85 (Atlanta)
What performance benefit does the proposed Sleepy Node support solution give in a network that already has standard CoAP caching enabled
Sleepy Node Performance Analysis
Experimental Network
1-5 clients
Both Sleepy and Non-
Sleepy servers
Sleepy Node Performance Analysis Network Setup
CoAPSleepyServer(s)
CoAPSleepAwareReverseProxy
CoAP
Client(s)
Request
Response
Sleep9AwareCoREResourceDirectoryCapability
PublishedSleepParameters
Sleep9AwareCoAPStoreandForwardCapability Response
Request
SleepAwareCoAP503ResponseCapability
CoAPCachingCapability
bull Server supports publishing sleep parameters to proxy bull Eg Irsquom going to be asleep for X seconds
bull Proxy supports sleep-awareness capabilities bull Proxy also supports caching capability based off of maxAge bull Protocol flow similar to approach of Figure 1 (Synchronous RD Based Sleep
Tracking) of I-D
Proxy capabilities can be selectively enableddisabled
Proxy ndash Server Interface
Client ndash Proxy Interface
CoAP Sleep-Aware Reverse Proxy Features CoRE Sleep-aware Resource Directory
Support storing published sleep parameters from CoAP servers sleepState (AWAKE ASLEEP) sleepDuration
Sleep-aware CoAP 503 Response Capability If CoAP request to a sleeping server is received proxy returns a
lsquo503 Retry-Afterrsquo response to client 503 contains a timestamp indicating when the sever will wake back up
(timestamp delivered in CoAP maxAge option) Sleep-aware CoAP Store-and-Forward Capability
If CoAP request to a sleeping server is received proxy stores request until server wakes up and then forwards it
Caching capability Cache GET responses from server if maxAge option is present
(this is not a sleep aware feature)
Goals of Performance Analysis
For networks having sleepy servers provide measurements to quantify the impact that CoAP sleep-awareness capabilities can have
See if sleep-awareness capabilities can
provide additional benefits even when CoAP caching is used
Overview of Performance Analysis Performed The analysis was broken up into a set of test scenarios Each test scenario used a different combination of the following
variables Client issued GET requests Server was configured as a sleepy or non-sleepy server Proxy caching of GET responses was enabled or disabled Proxy sleep-aware 503 response capability was enabled or disabled Proxy store-and-forward capability was enabled or disabled maxAge in GET responses ndash Two values were tested 60sec and 5sec of Clients ndash Two values were used ndash 1 client and 5 clients
For comparison purposes the following were held constant across all test scenarios Client issued a fixed number of requests (100) across all test scenarios Client used a delay between each GET request (35sec) to better exercise
proxyrsquos caching and sleep-awareness capabilities For sleepy server test scenarios the server slept 60 sec awake for 3 sec
Format of Results The following results were collected for each
test scenario
Breakdown of the and types of transactions occurring between clientproxyserver
ldquoGETrdquo ndash Test Scenario Results
GET ndash Description of Test Scenarios
TestScenarios-GET
Scenario
CoAPSleepyServerSe7ngs CoAPSleepAwareReverseProxySe7ngs CoAPClientSe7ngs
SleepDuragton(sec)
AwakeDuragton(sec)
maxAge(sec) Caching SleepAwareSAF+
503NumberofClients
NumberofGETs
DelayBetweenClient
Requests(sec)
1a 0 Always 60 Enabled Disabled 1 100 35
1b 60 3 60 Enabled Disabled 1 100 35
1c 60 3 60 Enabled Enabled 1 100 35
2a 0 Always 60 Enabled Disabled 5 100 35
2b 60 3 60 Enabled Disabled 5 100 35
2c 60 3 60 Enabled Enabled 5 100 35
3a 0 Always 5 Enabled Disabled 5 100 35
3b 60 3 5 Enabled Disabled 5 100 35
3c 60 3 5 Enabled Enabled 5 100 35
ldquoGETrdquo ndash Test Scenario 1 Results
maxAge = 60 and 1 Client
GET ndash Scenario 1 ClientProxy Interface Transaction Mix
Scenarios 1a - Non-Sleepy Server Caching Proxy maxAge = 60sec 1b- Sleepy Server Caching Proxy maxAge = 60sec 1c - Sleepy Server Sleep Aware Proxy maxAge = 60sec
Sleep Aware Proxy has better performance for sleepy servers
0
100
200
300
400
500
600
700
1a 1b 1c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
GET ndash Scenario 1 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
Scenarios 1a - Non-Sleepy Server Caching Proxy maxAge = 60sec 1b- Sleepy Server Caching Proxy maxAge = 60sec 1c - Sleepy Server Sleep Aware Proxy maxAge = 60sec
0
100
200
300
400
500
600
700
800
1a 1b 1c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
ldquoGETrdquo ndash Test Scenario 2 Results
maxAge = 60 and 5 Clients
GET ndash Scenario 2 ClientProxy Interface Transaction Mix
Sleep Aware Proxy has slightly better performance for sleepy servers
0
200
400
600
800
1000
1200
1400
2a 2b 2c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
Scenarios 2a - Non-Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2b- Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2c - Sleepy Server Sleep Aware Proxy maxAge = 60sec 5 Clients
See ldquoExperimental Artifactsrdquo Note 1
GET ndash Scenario 2 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has slightly better performance for sleepy servers
0
50
100
150
200
250
300
350
400
2a 2b 2c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
Scenarios 2a - Non-Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2b- Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2c - Sleepy Server Sleep Aware Proxy maxAge = 60sec 5 Clients
See ldquoExperimental Artifactsrdquo Note 2
Experimental Artifacts Note 1
Currently in the experiment the sleep aware proxy checks the cached state of a resource before putting a request into its Store-and-forward queue while a server is sleeping Once in the queue the proxy unconditionally forwards the queued requests to the server once it wakes up This is not the most efficient setup and can easily be improved If the proxy instead checks its cache again before forwarding each queued request it may not need to forward the request to the server For example if there are two queued GET requests in the proxyrsquos queue that address the same resource Only the first request needs to be sent to the server the second request can use the cached response from the first request
Note 2 Currently in the experiment the sleepy server sends a sleepState PUT request to the
proxy each time it goes to sleep This is not the most efficient setup and can easily be improved For example if the server assumes that the proxy can keep track of its ONOFF cycles with its internal timers (eg as per Fig 1 of I-D) then the number of messages from the sleepy server dramatically goes down
ldquoGETrdquo ndash Test Scenario 3 Results
maxAge = 5 and 5 Clients
GET ndash Scenario 3 ClientProxy Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
Scenarios 3a - Non-Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3b- Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3c - Sleepy Server Sleep Aware Proxy maxAge = 5sec 5 Clients
0
500
1000
1500
2000
2500
3000
3500
4000
4500
5000
3a 3b 3c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
GET ndash Scenario 3 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
0
1000
2000
3000
4000
5000
6000
7000
3a 3b 3c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
Scenarios 3a - Non-Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3b- Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3c - Sleepy Server Sleep Aware Proxy maxAge = 5sec 5 Clients
Conclusions
Conclusions These results show that sleep-aware CoAP
proxy features can significantly optimize communication with sleepy servers in most scenarios
These results also show that sleep-
awareness capabilities can provide additional benefits above and beyond CoAP caching in most scenarios
Backup
Current CoAP Support of Sleepy Node (12)
CoAP proxies can use a previously cached response to service a new GET request for a sleepy origin server (as in HTTP) But if no valid cache then proxy has to attempt to
retrieve and may fail if origin server is sleeping [I-Dietf-core-coap]
Clients can discover list of resources from RD (GET rd-lookuphellip) for sleepy servers But attempt to GET resource from sleepy origin server
may fail if origin server is sleeping [IDietf-core-link-format amp IDshelby-core-resource-
directory]
Current CoAP Support of Sleepy Node (22)
Lower layer support for sleepy nodes in most wireless technologies (eg WiFi ZigBee) But limited to MAC packet scheduling for sleepy nodes
and not aware of specific needs of IP applications (like CoAP)
Proposal ndash RD Based Sleep Tracking (14)
The current CoAP approach to support sleepy nodes can be significantly improved by introducing RD based mechanisms for a CoAP client to determine whether A targeted resource is located on a sleepy server A sleepy server is currently in sleep mode or not
There is any associated caching Proxy (possibly the RD itself) for a sleepy server
Proposal ndash RD Based Sleep Tracking (24)
We define the following new RD attributes to characterize the properties of a sleepy node SleepState - Indicates whether the node is currently in
sleep mode or not (ie Sleeping or Awake) SleepDuration - Indicates the maximum duration of time
that the node stays in sleep mode TimeSleeping - Indicates the length of time the node
has been sleeping (ie if Sleep State = Sleeping) NextSleep - Indicates the next time the node will go to
sleep (ie if Sleep State = Awake)
CachingProxy ndash Indicates the caching proxy of the sleepy node (ie the RD itself or another node)
Proposal ndash RD Based Sleep Tracking (34)
These attributes are all server (node) level and are new parameters added to the RD URI Template Variables
Finally we also define a new lookup-type (ss) for the RD lookup interface specified in [I-Dshelby-core-resource-directory] This new lookup-type supports looking up the
ldquoSleepStaterdquo (ss) of a specified end-point
Proposal ndash RD Based Sleep Tracking (44)
The three time based parameters (SleepDuration TimeSleeping NextSleep) can be based on either an absolute network time (for a time synchronized network) or a relative local time (measured at the local node)
Following the approach of [I-Dietf-core-link-format] and [I-Dshelby-core-resource-directory] sleep parameters for sleepy servers can be stored by the server in the RD and accessed by all interested clients
Examples of using these parameters in a synchronous or asynchronous manner are shown in the I-D
http6lowappnet coreIETF86 2013-03-12-13
We assume people have read the drafts
Meetings serve to advance difficult issues by making good use of face-to-face communications
Note Well Be aware of the IPR principles according to RFC 3979 and its updates
uumlBlue sheetsuumlScribe(s)
96
drar-shy‐iep-shy‐core-shy‐coapsubmiqed13 to13 IESG
2013-shy‐03-shy‐13
97
OMA Lightweight M2M Overview(A new standard using lots of IETF specs including DTLS
CoAP Block Observe Resource Directory SenMLhellip)
Zach ShelbyCoRE WG IETF-86 Orlando
OMA Lightweight M2Mbull Open Mobile Alliance is well known for Device Management (DM)bull OMA Lightweight M2M is a new standard from the alliance
ndash Focused on constrained Cellular and sensor network M2M devicesndash Driven by leading operators and vendors
bull Scopendash Interfaces protocol amp security between Device and Serverndash Object and Resource modelndash Bootstrap Device Access Control Connectivity and Firmware Objects
bull Draft Specifications are availablendash httpmemberopenmobileallianceorgftpPublic_documentsDM
LightweightM2MPermanent_documentsOMA-TS-LightweightM2M-V1_0_0-20130301-Dzip
bull Timelinendash Requirements and Architecture completed 3Q2012ndash Spec ready for Consistency Review 2Q2013ndash Candidate Approval expected 3Q2013
2 CoRE WG IETF-86 Orlando
Architecture
3
Scope of LWM2M
CoRE WG IETF-86 Orlando
Object Model
bull A Client has one or more Object Instancesbull An Object is a collection of Resourcesbull A Resource is an atomic piece of information
ndash Read Written or Executed
bull Resources can have multiple instancesbull Objects and Resources are identified by a
16-bit Integer Instances by an 8-bit Integerbull ObjectsResources are accessed with
simple URIs Object IDObject InstanceResource ID
eg 1213
4 CoRE WG IETF-86 Orlando
CoRE WG IETF-86 Orlando
CoRE Resource Directory
draft-shelby-core-resource-directory-05
Z Shelby C Bormann S Krco
Backgroundbull Not a new concept
ndash think web search engine or any link directorybull Defines the interfaces to a Resource Directorybull Based on Web Linking framework and the CoRE Link Formatbull Generic REST design for use over HTTP and CoAPbull Used by OMA Lightweight M2Mbull Has already been deployed
ndash In traffic monitoring systemsndash In street lighting systemsndash For vehicular asset trackingndash By a major Cellular M2M operator
Changes since -04
bull Restricted Update to parameter updatesbull Added pagination support for the Lookup interfacebull Changed rt= to et= for the registration amp update
interfacebull Added group support
Group Management
bull RD now includes group management featuresbull New Group Function Set
ndash Register a groupbull Group name domain multicast address endpoint members
ndash Remove a groupbull Group lookup using the Lookup Function Set
ndash List registered groupsndash Find the members of a groupndash Find groups with certain endpoints or resources
Registering a Group
EP RD
| |
| - POST rd-groupgp=lights ltgtep=node1 --gt |
| |
| |
| lt---- 201 Created Location rd-group12 ---- |
| |
Req POST coaprdexamplecomrd-groupgp=lights
Payload
ltgtep=node1
ltgtep=node2
Res 201 Created
Location rd-group12
Looking up Group Members
Client RD
| |
| ----- GET rd-lookupepgp=lights1 ----------------------gt |
| |
| |
| lt-- 205 Content ltrdgtd=domain1ltrdgtd=domain2 --------- |
| |
Req GET rd-lookupepgp=lights1
Res 205 Content
ltcoaphostportgtep=node1
ltcoaphostportgtep=node2rdquo
Things for the futurebull Support for JSON representation of Web Links
ndash httptoolsietforgiddraft-bormann-core-links-json-02txtbull Registry for RD registration query parameters
ndash Already OMA Lightweight has defined some new onesbull More examples
Group 3 ldquonew workrdquo(continued)
109
drar-shy‐greevenbosch-shy‐core-shy‐profile-shy‐descripon-shy‐01Bert13 GreevenboschJeroen13 Hoebeke
Isam13 IshaqFloris13 Van13 den13 Abeele
Descripon
bull JSON13 format13 for13 signalling13 the13 servers13 capabilies
bull Signalling13 of13 supported13 opons13 media13 types13 and13 block13 sizendash Other13 items13 can13 be13 added
bull Filtering13 on13 specific13 fields13 through13 URI-shy‐Querybull Link13 hqpdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐profile-shy‐descripon
well-shy‐knownprofile
bull To13 acquire13 profile13 data13 of13 resources13 on13 a13 parcular13 service13 the13 well-shy‐knownprofile13 URI-shy‐path13 is13 introduced
bull For13 example13 to13 get13 all13 informaon13 from13 sensors13 served13 by13 wwwexampleorg13 we13 can13 do13 a13 GET13 to13 coapwwwexampleorgwell-shy‐knownprofile
bull Filtering13 on13 parcular13 resources13 is13 done13 through13 URI-shy‐Queries
Format
bull Currently13 the13 following13 fields13 are13 definedndash ldquopathrdquo13 contains13 the13 URI-shy‐path13 associated13 with13 a13 resource
ndash ldquooprdquo13 a13 numerical13 list13 of13 supported13 opon13 numbers
ndash ldquocfrdquo13 a13 numerical13 list13 of13 supported13 content-shy‐format13 numbers
ndash ldquob1srdquo13 ldquob2srdquo13 supported13 block13 sizes13 for13 Block113 and13 Block213 respecvely
Examplebull On13 the13 right13 is13 an13 example13 of13 a13 camera13 sensor13 at13 coapwwwexampleorgcam13 that13 supports13 the13 Uri-shy‐Host13 (3)13 ETag13 (4)13 Uri-shy‐Port13 (7)13 Uri-shy‐Path13 (11)13 Content-shy‐Format13 (12)13 Token13 (19)13 Block213 (23)13 and13 Proxy-shy‐Uri13 (35)13 opons
bull The13 supported13 content13 formats13 are13 textplain13 (0)13 applicaon13 link-shy‐format13 (40)13 and13 applicaonjson13 (50)
bull The13 supported13 Block213 can13 use13 25613 or13 51213 byte13 blocks
Req13 GET13 coapwwwexampleorgwell-shy‐knownprofile13 Res13 20513 Content13 (applicationjson)13 13 13 13 profile13 13 13 13 13 13 13 13 pathcam13 13 13 13 op[3471112192335]13 13 13 13 13 cf[04050]13 13 13 13 13 b2s[45]13 13 13 13
Filtering13 through13 use13 of13 URI-shy‐Query
bull Filtering13 can13 be13 done13 through13 the13 URI-shy‐Querybull Query13 format13 N=V
ndash N13 is13 a13 profile13 fieldndash V13 is13 the13 desired13 value
bull Examplesndash To13 find13 resources13 that13 support13 content13 format13 ldquoapplicaonjsonrdquo
13 GET13 wwwexampleorgwell-shy‐knownprofilecf=50ndash To13 get13 informaon13 about13 the13 camera
13 GET13 wwwexampleorgwell-shy‐knownprofilepath=cam
Open13 issues
bull Which13 other13 profile13 data13 needs13 signallingndash Content-shy‐type13 for13 different13 methods
bull Fix13 the13 order13 in13 which13 the13 profile13 fields13 must13 appearndash Non-shy‐fixed13 order13 easier13 extensible
bull Inheritance13 of13 a13 profile13 descriponbull Extend13 usage13 to13 signal13 the13 client13 profilebull Integraon13 with13 link13 format
Thank13 youQuesons
drar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval-shy‐00
Bert13 Greevenbosch
Descripon
bull The13 ldquoMinimumRequestInterval13 opon13 can13 be13 used13 to13 indicate13 the13 minimum13 me13 between13 two13 requests13 in13 a13 transacon
bull Originally13 intended13 for13 Block13 but13 also13 usable13 for13 other13 transaconsndash Example13 browsing13 a13 server
bull The13 goal13 is13 to13 reduce13 the13 server13 load13 and13 network13 traffic
bull Link13 hqpsdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval
Usage
bull The13 client13 keeps13 the13 server13 informed13 about13 its13 request13 speed13 through13 inclusion13 of13 the13 ldquoMinimumRequestIntervalrdquo13 opon
bull In13 responses13 the13 server13 fixes13 the13 minimum13 request13 interval13 through13 the13 same13 opon
bull The13 client13 obeys13 the13 speed13 indicated13 by13 the13 server
bull The13 client13 can13 send13 slower13 but13 not13 faster
Advantages
bull The13 server13 has13 means13 to13 limit13 the13 amount13 of13 incoming13 traffic
bull The13 server13 can13 prevent13 to13 become13 overloaded13 with13 too13 many13 tasks
bull The13 server13 does13 not13 need13 arficially13 slow13 down13 the13 client13 by13 sending13 late13 ACKsndash No13 need13 to13 keep13 track13 of13 delayed13 ACKsndash The13 server13 can13 perform13 other13 tasks13 instead
bull Reduced13 network13 traffic
Thank13 youQuesons
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-links-json-02txt
123
RFC 6690 (link-format) documents are somewhat foreign to many web app developerssect would prefer to have them in JSON format
There is no standard way to represent link-format documents in applicationssect but everyone knows how to handle JSON
Define a standard JSON translation for link-format
Itrsquos
not
rock
et
scien
ce
ltsensorsgtct=40title=Sensor Index ltsensorstempgtrt=temperature-cif=sensor ltsensorslightgtrt=light-luxif=sensor lthttpwwwexamplecomsensorst123gt anchor=sensorstemprel=describedby lttgtanchor=sensorstemprel=alternate [hrefsensorsct40titleSensor Index hrefsensorstemprttemperature-cifsensor hrefsensorslightrtlight-luxifsensor hrefhttpwwwexamplecomsensorst123 anchorsensorstempreldescribedby hreftanchorsensorstemprelalternate]
124
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-ipsec-for-coap-00txt
IPsec definitions for CoAP Mostly placeholder at this time Who has implementation experience with this
125
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-cross-reverse-convention-00txt
This draft has two lines of payload(based on a WGLC comment by Cullen Jennings)
coap12344567foobara=3
httpwwwproxycomwellknowncore-translate1234_4567foobara=3
Is that a useful convention to have
126
Insert CI slides here
127
128
0
5
10
15
20
25
30
35
40
10 20 30 40 50 60 70
good
put (
pps)
pps
Goodput vs pps (Econotags)
goodput
[Khattak preliminary]
Congestion Control
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-cocoa-00txt
ldquoadvancedrdquo cc (The draft is just a first shot) Others may have better ideas
129
Insert post-WGLC discussion slides here
130
Stop Continue Start
131
An Agile Retrospective
http6lowappnet coreIETF86 2013-03-12-13
Stop
132
Endless new CoAP optionssect instead use RESTful as much as possible
Move general security lifecycle out Looking at theoretical problems
http6lowappnet coreIETF86 2013-03-12-13
Continue
Interops Running code Look at real-world examples and deployments Solve their actual problems
sect Unilateral enhancements eg higher performance congestion control
sect Transports (SMS hellip)sect Make Web linking and Directories more and more usefulsect RESTful Design Paradigms for real-world problems
133
http6lowappnet coreIETF86 2013-03-12-13
Start
Further push into the (browser) web world (HTML5 browser security)
Specific supporting worksect SenMLsect URI work (dev URN hellip)sect Security Processes (next slide)
Spin outsect (We donrsquot really get to decide where this is done)
134
http6lowappnet coreIETF86 2013-03-12-13
Security
Integrate Application Network Group Keyingsect Tunnel-free setup
Donrsquot redo what has been done alreadysect ZigBee IP is finesect But what about other scenarios
Simple REST interfaces for working with keying materials and authorizationsect Start with defining objectives
Object Security for Constrained Nodes135
Re-chartering CoREWhat do we want to do now that wersquore grown up
Zach ShelbyCoRE WG IETF-86 Orlando
What is the scope
bull So we have a protocol and Web Linking what next
bull Keep with what we know besthellip1 Enhancements around CoAP2 New transports for CoAP3 New representations for Web Links4 General application layer solutions
CoRE WG IETF-86 Orlando 2
Enhancements around CoAP
bull Advanced congestion control
CoRE WG IETF-86 Orlando 3
New Transports for CoAP
bull Infrastructure for CoAP over foondash httptoolsietforgiddraft-silverajan-core-
coap-alternative-transports-01txtbull CoAP over SMS
ndash httptoolsietforgiddraft-becker-core-coap-sms-gprs-03txt
ndash OMA Lightweightbull CoAP over TCP
ndash httptoolsietforgiddraft-li-core-coap-payload-length-option-01txt
CoRE WG IETF-86 Orlando 4
New support for Web Links
bull JSON Web Linksndash httptoolsietforgiddraft-bormann-core-links-
json-02txt
2332010 CoRE WG IETF-77 Anaheim 5
General application layer solutions
bull Resource Directoryndash httptoolsietforgiddraft-shelby-core-
resource-directory-05txtndash OMA Lightweight
2332010 CoRE WG IETF-77 Anaheim 6
HTTP-CoAP Response Code Mapping
Implementation Experience
n Direct experience from the draft authorsn Squid HTTP-CoAP mapping module
n University of Padovan httptelecomdeiunipditiotn Both Forward and Interception operation supported
n HTTP-CoAP proxy based on EvCoAPn KoanLogic University of Bologna and Salvatore
Loreto (as individual)n httpsgithubcomkoanlogicwebthingstreemasterbridgesw
libevcoapn The document is open to input from other implementations
Next Steps
n Does the WG recommend adoptionn Intended status Informational Best Practicen Purpose Reduce arbitrary variation between proxy
implementations thereby increasing interoperability
Backup
HTTP to CoAP URI Mapping Options (12)
n Embedded Mapping n In an embedded mapping approach the HTTP URI has embedded
inside it the authority and path part of the CoAP URI n Example The CoAP resource nodecoapsomethingnetfoo can
be accessed by an HTTP client by inserting in the request httphc-proxysomethingnetcoapnodecoapsomethingnetfoo The Cross-Protocol Proxy then maps the URI to coapnodecoapsomethingnetfoo
HTTP to CoAP URI Mapping Options (22)
n Homogeneous Mapping n In a homogeneous mapping approach only the scheme portion of the URI
needs to be mapped The rest of the URI (ie authority path etc) remains unchanged
n Example The CoAP resource coapnodecoapsomethingnetfoo can be accessed by an HTTP client by requesting httpnodecoapsomethingnetfoo The Cross-Protocol Proxy receiving the request is responsible to map the URI to coapnodecoapsomethingnetfoo
n Background info n The assumption in this case is that the HTTP client would be able to
successfully resolve nodecoapsomethingnet using DNS infrastructure to return the IP address of the HC proxy Most likely this would be through a two step DNS lookup where the first DNS lookup would resolve somethingnet using public DNS infrastructure
n Then the second DNS lookup on the subdomain coap and the host node would typically be resolved by a DNS server operated by the owner of domain somethingnet So this domain owner can manage its own internal node names and subdomain allocation which would correspond to the CoAP namespace
Group 3 ldquonew workrdquo
39
Transport of CoAP over SMS USSD and GPRSdraft-becker-core-coap-sms-gprs-03
Markus Becker Kepeng LiKoojana Kuladinithi Thomas Poumltsch
CoRE WG IETF-86 Orlando
1 10
ScenariosI In M2M communication IP connectivity is not alwayssupported by the constrained end-points
I Power savingI Coverage (GPRS 3G LTE)
I SMS and USSD based communication is almost alwayssupported
210
Changes from draft-01 to draft-03 (1)
I Added possible CONNONACK interactions Section 5
I Option name changed from Reply-To- to Response-To-Section 16 and Section 101
I Added URI schemeEg coap+tel+15105550101well-knowncore Section 11
I Added possible M2M proxy scenarios Section 14
3 10
Changes from draft-01 to draft-03 (2)
I Added reference to bormann-coap-misc for other SMSencoding Section 71
I Updated requirements on Uri-Host and Uri-Port forcoap+tel Section 10
I Added security considerations Transport and ObjectSecurity Section 15
I Chose CoAP option numbers and updated the optionnumber table to meet draft-ietf-core-coap-10 Table 1
I Added an IANA registration for the URI scheme coap+telSection 162
4 10
Feedback Split coap+tel into coap+smsand coap+ussd
I How else to differ the various transports in the URII Or is the transport to use decided by the implementationI See alsodraft-silverajan-core-coap-alternative-transports-01
5 10
Feedback Response-To-Scheme option
I Should there be a Response-To-Scheme optionadditionally to Response-To-Uri-Host andResponse-To-Uri-Path
I So that a CoAP end-point which receives a request by CoAPover non-IP transport can be instructed to also use thenon-IP transport for the response
I This would imply to add aResponse-To-Telephone-Subscriber and more options forother transports that have other URI schemes than coapand coaps
6 10
Feedback Selection of Transport by Client
I When a server is reachable by various transports howdoes a client decide which transport to use
I Client-side application congurationI Leave it to a proxy which uses cellular network lookupfunctions
7 10
Feedback Potential Threats
I Trigger expensive short messagesI Redirect trac to other addressesI More threats
I Are the security measures in the draft adequateI Whitelisting on serverI Relying on cellular network security (dedicated M2M APNs)I Object security on CoAP payload
8 10
Feedback Message Exchanges
I Figures 11-18 show possible message exchanges whenclient and server have two addresses
I With NON Not using CoAP retransmission capabilityI ACK on different transportI Additional (costly) message on Transport AI Request with Content
I Which ones are allowedI Which ones are meaningful
9 10
Next steps
I Rene Uri schemeI Response-To-Scheme optionI Selection of Message ExchangeI Rene Proxying
10 10
CoAP13 Communicaon13 with13 Alternave13 Transports
Bill Silverajan and Teemu SavolainenCore WG IETF 86 Orlando
031113
Objecves13 (In13 Scope)
bull Unambiguous13 representaon13 of13 transport13 to13 be13 used13 by13 CoAP
bull Details13 how13 the13 transport13 can13 carry13 CoAP13 packet
bull Focus13 is13 on13 what13 CoAP13 communicaons13 requirements13 are
bull Allow13 CoAP13 mechanisms13 to13 exploit13 cross-shy‐layer13 opmisaons
51
031113
Non13 Goals13 (Not13 in13 scope)
bull Applicaon-shy‐level13 QoS13 requirementsbull Real-shy‐me13 constraintsbull Ordering13 reliability13 congeson13 controlbull Applicaon13 and13 network13 adaptaonbull Mobility13 and13 readdressing13 supportbull Network13 protocol13 (eg13 IPsec)13 configuraon
52
031113
Use13 Cases
bull NAT13 and13 Firewall13 traversal13 with13 TCPbull Delay13 Tolerant13 Networkingbull Non-shy‐IP13 Low13 Energy13 Protocols
53
031113
Related13 Work
bull OMA13 Lightweight13 M2M13 Protocolbull CoAP13 over13 SMSGPRSUSSD
54
031113
What13 does13 the13 work13 entail
bull The13 ability13 to13 specify13 end13 point13 idenfiers13 and13 URIs13 to13 reflect13 which13 transport13 CoAP13 can13 use
bull The13 ability13 to13 register13 to13 resource13 directories13 resource13 types13 reflecng13 types13 of13 transport13 available
bull Ability13 for13 mul-shy‐transport13 nodes13 to13 select13 transport13 to13 use13 without13 significant13 alteraon13 to13 CoAP13 packet13 structure
55
031113
Points13 to13 consider
bull Requirements13 for13 transport13 layer13 protocol13 to13 carry13 CoAP13 packets
bull Representaon13 of13 URI13 scheme13 for13 generic13 transport13 protocols
bull Opon13 extensions13 for13 CoAP13 to13 express13 available13 transports
bull Mapping13 and13 message13 sizebull Security13 consideraons
56
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
URI13 =13 scheme13 13 13 authority13 path-shy‐abempty13 [13 query13 ]
bull Within13 the13 scheme13 namebull In13 the13 URI13 pathbull As13 a13 query13 component
57
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
bull Within13 the13 scheme13 namendash coap+tel+15105550101well-shy‐knowncorendash coap+tcpexamplecom5683temperaturendash coap+blel2cap[1234567890AB]4pulse
bull Easy13 URI13 parsing13 for13 transport13 type13 and13 idenfier
bull Each13 new13 scheme13 name13 requires13 IANA13 registraon
58
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
bull In13 the13 URI13 pathndash coaphostexamplecomtransport=tcpwell-shy‐knowncorert=core-shy‐rd
bull Easy13 adopon13 of13 new13 (and13 experimental)13 CoAP13 transports13 without13 IANA13 registraon
bull Caveat13 Uri-shy‐Path13 opon13 is13 a13 Crical13 CoAP13 opon13 see13 secon13 54113 of13 I-shy‐Diep-shy‐core-shy‐coap
59
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
bull As13 a13 URI13 query13 componentndash coaphostexamplecomwell-shy‐knowncorert=core-shy‐rdq=tcp
bull Also13 easy13 to13 adopt13 new13 (and13 experimental)13 CoAP13 transports13 without13 IANA13 registraon
bull Caveat13 Uri-shy‐Query13 opon13 is13 a13 Crical13 CoAP13 opon13 see13 secon13 54113 of13 I-shy‐Diep-shy‐core-shy‐coap
60
031113
URI13 Representaons13 for13 CoAPNon13 standard13 ways
bull Transport13 in13 the13 URI13 authority13 componentndash coaphost[port][transport]13 instead13 of13 coaphost[port]
bull Transport13 as13 a13 service13 URLndash servicecoaptcphostexamplecomwell-shy‐knowncorert=core-shy‐rd
bull Above13 two13 ways13 break13 exisng13 compability13 (although13 both13 are13 based13 on13 valid13 IANA13 URI13 registraons)
61
031113
URI13 Representaons13 for13 CoAPMiscellaneous13 Consideraons
bull Ensure13 that13 transport13 is13 defined13 unambiguously13 (eg13 L2CAP13 used13 by13 both13 BLE13 and13 standard13 Bluetooth13 so13 avoid13 rdquocoap+l2caprdquo13 or13 rdquotransport=l2caprdquo13 or13 rdquoq=l2caprdquondash Can13 be13 done13 as13 WG13 consensusndash Namespace13 approach13 eg13 rdquocoap+blel2caprdquo13 or13 rdquoq=blel2caprdquo
bull Allow13 end-shy‐points13 to13 use13 CoAP13 Resource13 Directory13 to13 register13 alternave13 transports13 and13 idenfiers13 and13 provide13 periodic13 updatesndash Register13 rdquocore-shy‐transportrdquo13 resource13 type
62
031113
Transport13 Consideraons
bull Uniqueness13 of13 end-shy‐point13 idenficaonbull Communicaon13 support13 Unidireconal13 Bidireconal13 1N13 (broadcast13 mulcast13 anycast)13 messaging
bull Binary13 encoding13 Network13 byte13 orderingbull MTU13 correlaon13 with13 CoAP13 PDU13 sizebull Transport13 latency
63
031113
Security13 Consideraons
bull Drar13 does13 not13 introduce13 new13 security13 requirements13 by13 itself
bull There13 may13 be13 privacy13 issues13 if13 nodes13 use13 telephone13 numbers13 or13 MAC13 addresses13 as13 public13 end13 point13 idenfiers
64
Akbar Rahman
IETF 86 March 2013 httpwwwietforgiddraft-rahman-core-sleepy-02txt
Enhanced Sleepy Node Support for CoAP
Introduction
It is expected that in CoAP networks there will be a certain portion of devices that are sleepy and which may occasionally go into a sleep mode (ie go into a low power state to conserve power) and subsequently have reduced CoAP protocol communication ability
This I-D proposes a minimal and efficient mechanism building on the Resource Directory concept (which will be integrated into a CoAP Proxy) to enhance sleepy node support in CoAP networks
Main Question from IETF-85 (Atlanta)
What performance benefit does the proposed Sleepy Node support solution give in a network that already has standard CoAP caching enabled
Sleepy Node Performance Analysis
Experimental Network
1-5 clients
Both Sleepy and Non-
Sleepy servers
Sleepy Node Performance Analysis Network Setup
CoAPSleepyServer(s)
CoAPSleepAwareReverseProxy
CoAP
Client(s)
Request
Response
Sleep9AwareCoREResourceDirectoryCapability
PublishedSleepParameters
Sleep9AwareCoAPStoreandForwardCapability Response
Request
SleepAwareCoAP503ResponseCapability
CoAPCachingCapability
bull Server supports publishing sleep parameters to proxy bull Eg Irsquom going to be asleep for X seconds
bull Proxy supports sleep-awareness capabilities bull Proxy also supports caching capability based off of maxAge bull Protocol flow similar to approach of Figure 1 (Synchronous RD Based Sleep
Tracking) of I-D
Proxy capabilities can be selectively enableddisabled
Proxy ndash Server Interface
Client ndash Proxy Interface
CoAP Sleep-Aware Reverse Proxy Features CoRE Sleep-aware Resource Directory
Support storing published sleep parameters from CoAP servers sleepState (AWAKE ASLEEP) sleepDuration
Sleep-aware CoAP 503 Response Capability If CoAP request to a sleeping server is received proxy returns a
lsquo503 Retry-Afterrsquo response to client 503 contains a timestamp indicating when the sever will wake back up
(timestamp delivered in CoAP maxAge option) Sleep-aware CoAP Store-and-Forward Capability
If CoAP request to a sleeping server is received proxy stores request until server wakes up and then forwards it
Caching capability Cache GET responses from server if maxAge option is present
(this is not a sleep aware feature)
Goals of Performance Analysis
For networks having sleepy servers provide measurements to quantify the impact that CoAP sleep-awareness capabilities can have
See if sleep-awareness capabilities can
provide additional benefits even when CoAP caching is used
Overview of Performance Analysis Performed The analysis was broken up into a set of test scenarios Each test scenario used a different combination of the following
variables Client issued GET requests Server was configured as a sleepy or non-sleepy server Proxy caching of GET responses was enabled or disabled Proxy sleep-aware 503 response capability was enabled or disabled Proxy store-and-forward capability was enabled or disabled maxAge in GET responses ndash Two values were tested 60sec and 5sec of Clients ndash Two values were used ndash 1 client and 5 clients
For comparison purposes the following were held constant across all test scenarios Client issued a fixed number of requests (100) across all test scenarios Client used a delay between each GET request (35sec) to better exercise
proxyrsquos caching and sleep-awareness capabilities For sleepy server test scenarios the server slept 60 sec awake for 3 sec
Format of Results The following results were collected for each
test scenario
Breakdown of the and types of transactions occurring between clientproxyserver
ldquoGETrdquo ndash Test Scenario Results
GET ndash Description of Test Scenarios
TestScenarios-GET
Scenario
CoAPSleepyServerSe7ngs CoAPSleepAwareReverseProxySe7ngs CoAPClientSe7ngs
SleepDuragton(sec)
AwakeDuragton(sec)
maxAge(sec) Caching SleepAwareSAF+
503NumberofClients
NumberofGETs
DelayBetweenClient
Requests(sec)
1a 0 Always 60 Enabled Disabled 1 100 35
1b 60 3 60 Enabled Disabled 1 100 35
1c 60 3 60 Enabled Enabled 1 100 35
2a 0 Always 60 Enabled Disabled 5 100 35
2b 60 3 60 Enabled Disabled 5 100 35
2c 60 3 60 Enabled Enabled 5 100 35
3a 0 Always 5 Enabled Disabled 5 100 35
3b 60 3 5 Enabled Disabled 5 100 35
3c 60 3 5 Enabled Enabled 5 100 35
ldquoGETrdquo ndash Test Scenario 1 Results
maxAge = 60 and 1 Client
GET ndash Scenario 1 ClientProxy Interface Transaction Mix
Scenarios 1a - Non-Sleepy Server Caching Proxy maxAge = 60sec 1b- Sleepy Server Caching Proxy maxAge = 60sec 1c - Sleepy Server Sleep Aware Proxy maxAge = 60sec
Sleep Aware Proxy has better performance for sleepy servers
0
100
200
300
400
500
600
700
1a 1b 1c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
GET ndash Scenario 1 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
Scenarios 1a - Non-Sleepy Server Caching Proxy maxAge = 60sec 1b- Sleepy Server Caching Proxy maxAge = 60sec 1c - Sleepy Server Sleep Aware Proxy maxAge = 60sec
0
100
200
300
400
500
600
700
800
1a 1b 1c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
ldquoGETrdquo ndash Test Scenario 2 Results
maxAge = 60 and 5 Clients
GET ndash Scenario 2 ClientProxy Interface Transaction Mix
Sleep Aware Proxy has slightly better performance for sleepy servers
0
200
400
600
800
1000
1200
1400
2a 2b 2c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
Scenarios 2a - Non-Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2b- Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2c - Sleepy Server Sleep Aware Proxy maxAge = 60sec 5 Clients
See ldquoExperimental Artifactsrdquo Note 1
GET ndash Scenario 2 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has slightly better performance for sleepy servers
0
50
100
150
200
250
300
350
400
2a 2b 2c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
Scenarios 2a - Non-Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2b- Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2c - Sleepy Server Sleep Aware Proxy maxAge = 60sec 5 Clients
See ldquoExperimental Artifactsrdquo Note 2
Experimental Artifacts Note 1
Currently in the experiment the sleep aware proxy checks the cached state of a resource before putting a request into its Store-and-forward queue while a server is sleeping Once in the queue the proxy unconditionally forwards the queued requests to the server once it wakes up This is not the most efficient setup and can easily be improved If the proxy instead checks its cache again before forwarding each queued request it may not need to forward the request to the server For example if there are two queued GET requests in the proxyrsquos queue that address the same resource Only the first request needs to be sent to the server the second request can use the cached response from the first request
Note 2 Currently in the experiment the sleepy server sends a sleepState PUT request to the
proxy each time it goes to sleep This is not the most efficient setup and can easily be improved For example if the server assumes that the proxy can keep track of its ONOFF cycles with its internal timers (eg as per Fig 1 of I-D) then the number of messages from the sleepy server dramatically goes down
ldquoGETrdquo ndash Test Scenario 3 Results
maxAge = 5 and 5 Clients
GET ndash Scenario 3 ClientProxy Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
Scenarios 3a - Non-Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3b- Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3c - Sleepy Server Sleep Aware Proxy maxAge = 5sec 5 Clients
0
500
1000
1500
2000
2500
3000
3500
4000
4500
5000
3a 3b 3c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
GET ndash Scenario 3 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
0
1000
2000
3000
4000
5000
6000
7000
3a 3b 3c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
Scenarios 3a - Non-Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3b- Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3c - Sleepy Server Sleep Aware Proxy maxAge = 5sec 5 Clients
Conclusions
Conclusions These results show that sleep-aware CoAP
proxy features can significantly optimize communication with sleepy servers in most scenarios
These results also show that sleep-
awareness capabilities can provide additional benefits above and beyond CoAP caching in most scenarios
Backup
Current CoAP Support of Sleepy Node (12)
CoAP proxies can use a previously cached response to service a new GET request for a sleepy origin server (as in HTTP) But if no valid cache then proxy has to attempt to
retrieve and may fail if origin server is sleeping [I-Dietf-core-coap]
Clients can discover list of resources from RD (GET rd-lookuphellip) for sleepy servers But attempt to GET resource from sleepy origin server
may fail if origin server is sleeping [IDietf-core-link-format amp IDshelby-core-resource-
directory]
Current CoAP Support of Sleepy Node (22)
Lower layer support for sleepy nodes in most wireless technologies (eg WiFi ZigBee) But limited to MAC packet scheduling for sleepy nodes
and not aware of specific needs of IP applications (like CoAP)
Proposal ndash RD Based Sleep Tracking (14)
The current CoAP approach to support sleepy nodes can be significantly improved by introducing RD based mechanisms for a CoAP client to determine whether A targeted resource is located on a sleepy server A sleepy server is currently in sleep mode or not
There is any associated caching Proxy (possibly the RD itself) for a sleepy server
Proposal ndash RD Based Sleep Tracking (24)
We define the following new RD attributes to characterize the properties of a sleepy node SleepState - Indicates whether the node is currently in
sleep mode or not (ie Sleeping or Awake) SleepDuration - Indicates the maximum duration of time
that the node stays in sleep mode TimeSleeping - Indicates the length of time the node
has been sleeping (ie if Sleep State = Sleeping) NextSleep - Indicates the next time the node will go to
sleep (ie if Sleep State = Awake)
CachingProxy ndash Indicates the caching proxy of the sleepy node (ie the RD itself or another node)
Proposal ndash RD Based Sleep Tracking (34)
These attributes are all server (node) level and are new parameters added to the RD URI Template Variables
Finally we also define a new lookup-type (ss) for the RD lookup interface specified in [I-Dshelby-core-resource-directory] This new lookup-type supports looking up the
ldquoSleepStaterdquo (ss) of a specified end-point
Proposal ndash RD Based Sleep Tracking (44)
The three time based parameters (SleepDuration TimeSleeping NextSleep) can be based on either an absolute network time (for a time synchronized network) or a relative local time (measured at the local node)
Following the approach of [I-Dietf-core-link-format] and [I-Dshelby-core-resource-directory] sleep parameters for sleepy servers can be stored by the server in the RD and accessed by all interested clients
Examples of using these parameters in a synchronous or asynchronous manner are shown in the I-D
http6lowappnet coreIETF86 2013-03-12-13
We assume people have read the drafts
Meetings serve to advance difficult issues by making good use of face-to-face communications
Note Well Be aware of the IPR principles according to RFC 3979 and its updates
uumlBlue sheetsuumlScribe(s)
96
drar-shy‐iep-shy‐core-shy‐coapsubmiqed13 to13 IESG
2013-shy‐03-shy‐13
97
OMA Lightweight M2M Overview(A new standard using lots of IETF specs including DTLS
CoAP Block Observe Resource Directory SenMLhellip)
Zach ShelbyCoRE WG IETF-86 Orlando
OMA Lightweight M2Mbull Open Mobile Alliance is well known for Device Management (DM)bull OMA Lightweight M2M is a new standard from the alliance
ndash Focused on constrained Cellular and sensor network M2M devicesndash Driven by leading operators and vendors
bull Scopendash Interfaces protocol amp security between Device and Serverndash Object and Resource modelndash Bootstrap Device Access Control Connectivity and Firmware Objects
bull Draft Specifications are availablendash httpmemberopenmobileallianceorgftpPublic_documentsDM
LightweightM2MPermanent_documentsOMA-TS-LightweightM2M-V1_0_0-20130301-Dzip
bull Timelinendash Requirements and Architecture completed 3Q2012ndash Spec ready for Consistency Review 2Q2013ndash Candidate Approval expected 3Q2013
2 CoRE WG IETF-86 Orlando
Architecture
3
Scope of LWM2M
CoRE WG IETF-86 Orlando
Object Model
bull A Client has one or more Object Instancesbull An Object is a collection of Resourcesbull A Resource is an atomic piece of information
ndash Read Written or Executed
bull Resources can have multiple instancesbull Objects and Resources are identified by a
16-bit Integer Instances by an 8-bit Integerbull ObjectsResources are accessed with
simple URIs Object IDObject InstanceResource ID
eg 1213
4 CoRE WG IETF-86 Orlando
CoRE WG IETF-86 Orlando
CoRE Resource Directory
draft-shelby-core-resource-directory-05
Z Shelby C Bormann S Krco
Backgroundbull Not a new concept
ndash think web search engine or any link directorybull Defines the interfaces to a Resource Directorybull Based on Web Linking framework and the CoRE Link Formatbull Generic REST design for use over HTTP and CoAPbull Used by OMA Lightweight M2Mbull Has already been deployed
ndash In traffic monitoring systemsndash In street lighting systemsndash For vehicular asset trackingndash By a major Cellular M2M operator
Changes since -04
bull Restricted Update to parameter updatesbull Added pagination support for the Lookup interfacebull Changed rt= to et= for the registration amp update
interfacebull Added group support
Group Management
bull RD now includes group management featuresbull New Group Function Set
ndash Register a groupbull Group name domain multicast address endpoint members
ndash Remove a groupbull Group lookup using the Lookup Function Set
ndash List registered groupsndash Find the members of a groupndash Find groups with certain endpoints or resources
Registering a Group
EP RD
| |
| - POST rd-groupgp=lights ltgtep=node1 --gt |
| |
| |
| lt---- 201 Created Location rd-group12 ---- |
| |
Req POST coaprdexamplecomrd-groupgp=lights
Payload
ltgtep=node1
ltgtep=node2
Res 201 Created
Location rd-group12
Looking up Group Members
Client RD
| |
| ----- GET rd-lookupepgp=lights1 ----------------------gt |
| |
| |
| lt-- 205 Content ltrdgtd=domain1ltrdgtd=domain2 --------- |
| |
Req GET rd-lookupepgp=lights1
Res 205 Content
ltcoaphostportgtep=node1
ltcoaphostportgtep=node2rdquo
Things for the futurebull Support for JSON representation of Web Links
ndash httptoolsietforgiddraft-bormann-core-links-json-02txtbull Registry for RD registration query parameters
ndash Already OMA Lightweight has defined some new onesbull More examples
Group 3 ldquonew workrdquo(continued)
109
drar-shy‐greevenbosch-shy‐core-shy‐profile-shy‐descripon-shy‐01Bert13 GreevenboschJeroen13 Hoebeke
Isam13 IshaqFloris13 Van13 den13 Abeele
Descripon
bull JSON13 format13 for13 signalling13 the13 servers13 capabilies
bull Signalling13 of13 supported13 opons13 media13 types13 and13 block13 sizendash Other13 items13 can13 be13 added
bull Filtering13 on13 specific13 fields13 through13 URI-shy‐Querybull Link13 hqpdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐profile-shy‐descripon
well-shy‐knownprofile
bull To13 acquire13 profile13 data13 of13 resources13 on13 a13 parcular13 service13 the13 well-shy‐knownprofile13 URI-shy‐path13 is13 introduced
bull For13 example13 to13 get13 all13 informaon13 from13 sensors13 served13 by13 wwwexampleorg13 we13 can13 do13 a13 GET13 to13 coapwwwexampleorgwell-shy‐knownprofile
bull Filtering13 on13 parcular13 resources13 is13 done13 through13 URI-shy‐Queries
Format
bull Currently13 the13 following13 fields13 are13 definedndash ldquopathrdquo13 contains13 the13 URI-shy‐path13 associated13 with13 a13 resource
ndash ldquooprdquo13 a13 numerical13 list13 of13 supported13 opon13 numbers
ndash ldquocfrdquo13 a13 numerical13 list13 of13 supported13 content-shy‐format13 numbers
ndash ldquob1srdquo13 ldquob2srdquo13 supported13 block13 sizes13 for13 Block113 and13 Block213 respecvely
Examplebull On13 the13 right13 is13 an13 example13 of13 a13 camera13 sensor13 at13 coapwwwexampleorgcam13 that13 supports13 the13 Uri-shy‐Host13 (3)13 ETag13 (4)13 Uri-shy‐Port13 (7)13 Uri-shy‐Path13 (11)13 Content-shy‐Format13 (12)13 Token13 (19)13 Block213 (23)13 and13 Proxy-shy‐Uri13 (35)13 opons
bull The13 supported13 content13 formats13 are13 textplain13 (0)13 applicaon13 link-shy‐format13 (40)13 and13 applicaonjson13 (50)
bull The13 supported13 Block213 can13 use13 25613 or13 51213 byte13 blocks
Req13 GET13 coapwwwexampleorgwell-shy‐knownprofile13 Res13 20513 Content13 (applicationjson)13 13 13 13 profile13 13 13 13 13 13 13 13 pathcam13 13 13 13 op[3471112192335]13 13 13 13 13 cf[04050]13 13 13 13 13 b2s[45]13 13 13 13
Filtering13 through13 use13 of13 URI-shy‐Query
bull Filtering13 can13 be13 done13 through13 the13 URI-shy‐Querybull Query13 format13 N=V
ndash N13 is13 a13 profile13 fieldndash V13 is13 the13 desired13 value
bull Examplesndash To13 find13 resources13 that13 support13 content13 format13 ldquoapplicaonjsonrdquo
13 GET13 wwwexampleorgwell-shy‐knownprofilecf=50ndash To13 get13 informaon13 about13 the13 camera
13 GET13 wwwexampleorgwell-shy‐knownprofilepath=cam
Open13 issues
bull Which13 other13 profile13 data13 needs13 signallingndash Content-shy‐type13 for13 different13 methods
bull Fix13 the13 order13 in13 which13 the13 profile13 fields13 must13 appearndash Non-shy‐fixed13 order13 easier13 extensible
bull Inheritance13 of13 a13 profile13 descriponbull Extend13 usage13 to13 signal13 the13 client13 profilebull Integraon13 with13 link13 format
Thank13 youQuesons
drar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval-shy‐00
Bert13 Greevenbosch
Descripon
bull The13 ldquoMinimumRequestInterval13 opon13 can13 be13 used13 to13 indicate13 the13 minimum13 me13 between13 two13 requests13 in13 a13 transacon
bull Originally13 intended13 for13 Block13 but13 also13 usable13 for13 other13 transaconsndash Example13 browsing13 a13 server
bull The13 goal13 is13 to13 reduce13 the13 server13 load13 and13 network13 traffic
bull Link13 hqpsdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval
Usage
bull The13 client13 keeps13 the13 server13 informed13 about13 its13 request13 speed13 through13 inclusion13 of13 the13 ldquoMinimumRequestIntervalrdquo13 opon
bull In13 responses13 the13 server13 fixes13 the13 minimum13 request13 interval13 through13 the13 same13 opon
bull The13 client13 obeys13 the13 speed13 indicated13 by13 the13 server
bull The13 client13 can13 send13 slower13 but13 not13 faster
Advantages
bull The13 server13 has13 means13 to13 limit13 the13 amount13 of13 incoming13 traffic
bull The13 server13 can13 prevent13 to13 become13 overloaded13 with13 too13 many13 tasks
bull The13 server13 does13 not13 need13 arficially13 slow13 down13 the13 client13 by13 sending13 late13 ACKsndash No13 need13 to13 keep13 track13 of13 delayed13 ACKsndash The13 server13 can13 perform13 other13 tasks13 instead
bull Reduced13 network13 traffic
Thank13 youQuesons
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-links-json-02txt
123
RFC 6690 (link-format) documents are somewhat foreign to many web app developerssect would prefer to have them in JSON format
There is no standard way to represent link-format documents in applicationssect but everyone knows how to handle JSON
Define a standard JSON translation for link-format
Itrsquos
not
rock
et
scien
ce
ltsensorsgtct=40title=Sensor Index ltsensorstempgtrt=temperature-cif=sensor ltsensorslightgtrt=light-luxif=sensor lthttpwwwexamplecomsensorst123gt anchor=sensorstemprel=describedby lttgtanchor=sensorstemprel=alternate [hrefsensorsct40titleSensor Index hrefsensorstemprttemperature-cifsensor hrefsensorslightrtlight-luxifsensor hrefhttpwwwexamplecomsensorst123 anchorsensorstempreldescribedby hreftanchorsensorstemprelalternate]
124
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-ipsec-for-coap-00txt
IPsec definitions for CoAP Mostly placeholder at this time Who has implementation experience with this
125
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-cross-reverse-convention-00txt
This draft has two lines of payload(based on a WGLC comment by Cullen Jennings)
coap12344567foobara=3
httpwwwproxycomwellknowncore-translate1234_4567foobara=3
Is that a useful convention to have
126
Insert CI slides here
127
128
0
5
10
15
20
25
30
35
40
10 20 30 40 50 60 70
good
put (
pps)
pps
Goodput vs pps (Econotags)
goodput
[Khattak preliminary]
Congestion Control
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-cocoa-00txt
ldquoadvancedrdquo cc (The draft is just a first shot) Others may have better ideas
129
Insert post-WGLC discussion slides here
130
Stop Continue Start
131
An Agile Retrospective
http6lowappnet coreIETF86 2013-03-12-13
Stop
132
Endless new CoAP optionssect instead use RESTful as much as possible
Move general security lifecycle out Looking at theoretical problems
http6lowappnet coreIETF86 2013-03-12-13
Continue
Interops Running code Look at real-world examples and deployments Solve their actual problems
sect Unilateral enhancements eg higher performance congestion control
sect Transports (SMS hellip)sect Make Web linking and Directories more and more usefulsect RESTful Design Paradigms for real-world problems
133
http6lowappnet coreIETF86 2013-03-12-13
Start
Further push into the (browser) web world (HTML5 browser security)
Specific supporting worksect SenMLsect URI work (dev URN hellip)sect Security Processes (next slide)
Spin outsect (We donrsquot really get to decide where this is done)
134
http6lowappnet coreIETF86 2013-03-12-13
Security
Integrate Application Network Group Keyingsect Tunnel-free setup
Donrsquot redo what has been done alreadysect ZigBee IP is finesect But what about other scenarios
Simple REST interfaces for working with keying materials and authorizationsect Start with defining objectives
Object Security for Constrained Nodes135
Re-chartering CoREWhat do we want to do now that wersquore grown up
Zach ShelbyCoRE WG IETF-86 Orlando
What is the scope
bull So we have a protocol and Web Linking what next
bull Keep with what we know besthellip1 Enhancements around CoAP2 New transports for CoAP3 New representations for Web Links4 General application layer solutions
CoRE WG IETF-86 Orlando 2
Enhancements around CoAP
bull Advanced congestion control
CoRE WG IETF-86 Orlando 3
New Transports for CoAP
bull Infrastructure for CoAP over foondash httptoolsietforgiddraft-silverajan-core-
coap-alternative-transports-01txtbull CoAP over SMS
ndash httptoolsietforgiddraft-becker-core-coap-sms-gprs-03txt
ndash OMA Lightweightbull CoAP over TCP
ndash httptoolsietforgiddraft-li-core-coap-payload-length-option-01txt
CoRE WG IETF-86 Orlando 4
New support for Web Links
bull JSON Web Linksndash httptoolsietforgiddraft-bormann-core-links-
json-02txt
2332010 CoRE WG IETF-77 Anaheim 5
General application layer solutions
bull Resource Directoryndash httptoolsietforgiddraft-shelby-core-
resource-directory-05txtndash OMA Lightweight
2332010 CoRE WG IETF-77 Anaheim 6
Implementation Experience
n Direct experience from the draft authorsn Squid HTTP-CoAP mapping module
n University of Padovan httptelecomdeiunipditiotn Both Forward and Interception operation supported
n HTTP-CoAP proxy based on EvCoAPn KoanLogic University of Bologna and Salvatore
Loreto (as individual)n httpsgithubcomkoanlogicwebthingstreemasterbridgesw
libevcoapn The document is open to input from other implementations
Next Steps
n Does the WG recommend adoptionn Intended status Informational Best Practicen Purpose Reduce arbitrary variation between proxy
implementations thereby increasing interoperability
Backup
HTTP to CoAP URI Mapping Options (12)
n Embedded Mapping n In an embedded mapping approach the HTTP URI has embedded
inside it the authority and path part of the CoAP URI n Example The CoAP resource nodecoapsomethingnetfoo can
be accessed by an HTTP client by inserting in the request httphc-proxysomethingnetcoapnodecoapsomethingnetfoo The Cross-Protocol Proxy then maps the URI to coapnodecoapsomethingnetfoo
HTTP to CoAP URI Mapping Options (22)
n Homogeneous Mapping n In a homogeneous mapping approach only the scheme portion of the URI
needs to be mapped The rest of the URI (ie authority path etc) remains unchanged
n Example The CoAP resource coapnodecoapsomethingnetfoo can be accessed by an HTTP client by requesting httpnodecoapsomethingnetfoo The Cross-Protocol Proxy receiving the request is responsible to map the URI to coapnodecoapsomethingnetfoo
n Background info n The assumption in this case is that the HTTP client would be able to
successfully resolve nodecoapsomethingnet using DNS infrastructure to return the IP address of the HC proxy Most likely this would be through a two step DNS lookup where the first DNS lookup would resolve somethingnet using public DNS infrastructure
n Then the second DNS lookup on the subdomain coap and the host node would typically be resolved by a DNS server operated by the owner of domain somethingnet So this domain owner can manage its own internal node names and subdomain allocation which would correspond to the CoAP namespace
Group 3 ldquonew workrdquo
39
Transport of CoAP over SMS USSD and GPRSdraft-becker-core-coap-sms-gprs-03
Markus Becker Kepeng LiKoojana Kuladinithi Thomas Poumltsch
CoRE WG IETF-86 Orlando
1 10
ScenariosI In M2M communication IP connectivity is not alwayssupported by the constrained end-points
I Power savingI Coverage (GPRS 3G LTE)
I SMS and USSD based communication is almost alwayssupported
210
Changes from draft-01 to draft-03 (1)
I Added possible CONNONACK interactions Section 5
I Option name changed from Reply-To- to Response-To-Section 16 and Section 101
I Added URI schemeEg coap+tel+15105550101well-knowncore Section 11
I Added possible M2M proxy scenarios Section 14
3 10
Changes from draft-01 to draft-03 (2)
I Added reference to bormann-coap-misc for other SMSencoding Section 71
I Updated requirements on Uri-Host and Uri-Port forcoap+tel Section 10
I Added security considerations Transport and ObjectSecurity Section 15
I Chose CoAP option numbers and updated the optionnumber table to meet draft-ietf-core-coap-10 Table 1
I Added an IANA registration for the URI scheme coap+telSection 162
4 10
Feedback Split coap+tel into coap+smsand coap+ussd
I How else to differ the various transports in the URII Or is the transport to use decided by the implementationI See alsodraft-silverajan-core-coap-alternative-transports-01
5 10
Feedback Response-To-Scheme option
I Should there be a Response-To-Scheme optionadditionally to Response-To-Uri-Host andResponse-To-Uri-Path
I So that a CoAP end-point which receives a request by CoAPover non-IP transport can be instructed to also use thenon-IP transport for the response
I This would imply to add aResponse-To-Telephone-Subscriber and more options forother transports that have other URI schemes than coapand coaps
6 10
Feedback Selection of Transport by Client
I When a server is reachable by various transports howdoes a client decide which transport to use
I Client-side application congurationI Leave it to a proxy which uses cellular network lookupfunctions
7 10
Feedback Potential Threats
I Trigger expensive short messagesI Redirect trac to other addressesI More threats
I Are the security measures in the draft adequateI Whitelisting on serverI Relying on cellular network security (dedicated M2M APNs)I Object security on CoAP payload
8 10
Feedback Message Exchanges
I Figures 11-18 show possible message exchanges whenclient and server have two addresses
I With NON Not using CoAP retransmission capabilityI ACK on different transportI Additional (costly) message on Transport AI Request with Content
I Which ones are allowedI Which ones are meaningful
9 10
Next steps
I Rene Uri schemeI Response-To-Scheme optionI Selection of Message ExchangeI Rene Proxying
10 10
CoAP13 Communicaon13 with13 Alternave13 Transports
Bill Silverajan and Teemu SavolainenCore WG IETF 86 Orlando
031113
Objecves13 (In13 Scope)
bull Unambiguous13 representaon13 of13 transport13 to13 be13 used13 by13 CoAP
bull Details13 how13 the13 transport13 can13 carry13 CoAP13 packet
bull Focus13 is13 on13 what13 CoAP13 communicaons13 requirements13 are
bull Allow13 CoAP13 mechanisms13 to13 exploit13 cross-shy‐layer13 opmisaons
51
031113
Non13 Goals13 (Not13 in13 scope)
bull Applicaon-shy‐level13 QoS13 requirementsbull Real-shy‐me13 constraintsbull Ordering13 reliability13 congeson13 controlbull Applicaon13 and13 network13 adaptaonbull Mobility13 and13 readdressing13 supportbull Network13 protocol13 (eg13 IPsec)13 configuraon
52
031113
Use13 Cases
bull NAT13 and13 Firewall13 traversal13 with13 TCPbull Delay13 Tolerant13 Networkingbull Non-shy‐IP13 Low13 Energy13 Protocols
53
031113
Related13 Work
bull OMA13 Lightweight13 M2M13 Protocolbull CoAP13 over13 SMSGPRSUSSD
54
031113
What13 does13 the13 work13 entail
bull The13 ability13 to13 specify13 end13 point13 idenfiers13 and13 URIs13 to13 reflect13 which13 transport13 CoAP13 can13 use
bull The13 ability13 to13 register13 to13 resource13 directories13 resource13 types13 reflecng13 types13 of13 transport13 available
bull Ability13 for13 mul-shy‐transport13 nodes13 to13 select13 transport13 to13 use13 without13 significant13 alteraon13 to13 CoAP13 packet13 structure
55
031113
Points13 to13 consider
bull Requirements13 for13 transport13 layer13 protocol13 to13 carry13 CoAP13 packets
bull Representaon13 of13 URI13 scheme13 for13 generic13 transport13 protocols
bull Opon13 extensions13 for13 CoAP13 to13 express13 available13 transports
bull Mapping13 and13 message13 sizebull Security13 consideraons
56
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
URI13 =13 scheme13 13 13 authority13 path-shy‐abempty13 [13 query13 ]
bull Within13 the13 scheme13 namebull In13 the13 URI13 pathbull As13 a13 query13 component
57
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
bull Within13 the13 scheme13 namendash coap+tel+15105550101well-shy‐knowncorendash coap+tcpexamplecom5683temperaturendash coap+blel2cap[1234567890AB]4pulse
bull Easy13 URI13 parsing13 for13 transport13 type13 and13 idenfier
bull Each13 new13 scheme13 name13 requires13 IANA13 registraon
58
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
bull In13 the13 URI13 pathndash coaphostexamplecomtransport=tcpwell-shy‐knowncorert=core-shy‐rd
bull Easy13 adopon13 of13 new13 (and13 experimental)13 CoAP13 transports13 without13 IANA13 registraon
bull Caveat13 Uri-shy‐Path13 opon13 is13 a13 Crical13 CoAP13 opon13 see13 secon13 54113 of13 I-shy‐Diep-shy‐core-shy‐coap
59
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
bull As13 a13 URI13 query13 componentndash coaphostexamplecomwell-shy‐knowncorert=core-shy‐rdq=tcp
bull Also13 easy13 to13 adopt13 new13 (and13 experimental)13 CoAP13 transports13 without13 IANA13 registraon
bull Caveat13 Uri-shy‐Query13 opon13 is13 a13 Crical13 CoAP13 opon13 see13 secon13 54113 of13 I-shy‐Diep-shy‐core-shy‐coap
60
031113
URI13 Representaons13 for13 CoAPNon13 standard13 ways
bull Transport13 in13 the13 URI13 authority13 componentndash coaphost[port][transport]13 instead13 of13 coaphost[port]
bull Transport13 as13 a13 service13 URLndash servicecoaptcphostexamplecomwell-shy‐knowncorert=core-shy‐rd
bull Above13 two13 ways13 break13 exisng13 compability13 (although13 both13 are13 based13 on13 valid13 IANA13 URI13 registraons)
61
031113
URI13 Representaons13 for13 CoAPMiscellaneous13 Consideraons
bull Ensure13 that13 transport13 is13 defined13 unambiguously13 (eg13 L2CAP13 used13 by13 both13 BLE13 and13 standard13 Bluetooth13 so13 avoid13 rdquocoap+l2caprdquo13 or13 rdquotransport=l2caprdquo13 or13 rdquoq=l2caprdquondash Can13 be13 done13 as13 WG13 consensusndash Namespace13 approach13 eg13 rdquocoap+blel2caprdquo13 or13 rdquoq=blel2caprdquo
bull Allow13 end-shy‐points13 to13 use13 CoAP13 Resource13 Directory13 to13 register13 alternave13 transports13 and13 idenfiers13 and13 provide13 periodic13 updatesndash Register13 rdquocore-shy‐transportrdquo13 resource13 type
62
031113
Transport13 Consideraons
bull Uniqueness13 of13 end-shy‐point13 idenficaonbull Communicaon13 support13 Unidireconal13 Bidireconal13 1N13 (broadcast13 mulcast13 anycast)13 messaging
bull Binary13 encoding13 Network13 byte13 orderingbull MTU13 correlaon13 with13 CoAP13 PDU13 sizebull Transport13 latency
63
031113
Security13 Consideraons
bull Drar13 does13 not13 introduce13 new13 security13 requirements13 by13 itself
bull There13 may13 be13 privacy13 issues13 if13 nodes13 use13 telephone13 numbers13 or13 MAC13 addresses13 as13 public13 end13 point13 idenfiers
64
Akbar Rahman
IETF 86 March 2013 httpwwwietforgiddraft-rahman-core-sleepy-02txt
Enhanced Sleepy Node Support for CoAP
Introduction
It is expected that in CoAP networks there will be a certain portion of devices that are sleepy and which may occasionally go into a sleep mode (ie go into a low power state to conserve power) and subsequently have reduced CoAP protocol communication ability
This I-D proposes a minimal and efficient mechanism building on the Resource Directory concept (which will be integrated into a CoAP Proxy) to enhance sleepy node support in CoAP networks
Main Question from IETF-85 (Atlanta)
What performance benefit does the proposed Sleepy Node support solution give in a network that already has standard CoAP caching enabled
Sleepy Node Performance Analysis
Experimental Network
1-5 clients
Both Sleepy and Non-
Sleepy servers
Sleepy Node Performance Analysis Network Setup
CoAPSleepyServer(s)
CoAPSleepAwareReverseProxy
CoAP
Client(s)
Request
Response
Sleep9AwareCoREResourceDirectoryCapability
PublishedSleepParameters
Sleep9AwareCoAPStoreandForwardCapability Response
Request
SleepAwareCoAP503ResponseCapability
CoAPCachingCapability
bull Server supports publishing sleep parameters to proxy bull Eg Irsquom going to be asleep for X seconds
bull Proxy supports sleep-awareness capabilities bull Proxy also supports caching capability based off of maxAge bull Protocol flow similar to approach of Figure 1 (Synchronous RD Based Sleep
Tracking) of I-D
Proxy capabilities can be selectively enableddisabled
Proxy ndash Server Interface
Client ndash Proxy Interface
CoAP Sleep-Aware Reverse Proxy Features CoRE Sleep-aware Resource Directory
Support storing published sleep parameters from CoAP servers sleepState (AWAKE ASLEEP) sleepDuration
Sleep-aware CoAP 503 Response Capability If CoAP request to a sleeping server is received proxy returns a
lsquo503 Retry-Afterrsquo response to client 503 contains a timestamp indicating when the sever will wake back up
(timestamp delivered in CoAP maxAge option) Sleep-aware CoAP Store-and-Forward Capability
If CoAP request to a sleeping server is received proxy stores request until server wakes up and then forwards it
Caching capability Cache GET responses from server if maxAge option is present
(this is not a sleep aware feature)
Goals of Performance Analysis
For networks having sleepy servers provide measurements to quantify the impact that CoAP sleep-awareness capabilities can have
See if sleep-awareness capabilities can
provide additional benefits even when CoAP caching is used
Overview of Performance Analysis Performed The analysis was broken up into a set of test scenarios Each test scenario used a different combination of the following
variables Client issued GET requests Server was configured as a sleepy or non-sleepy server Proxy caching of GET responses was enabled or disabled Proxy sleep-aware 503 response capability was enabled or disabled Proxy store-and-forward capability was enabled or disabled maxAge in GET responses ndash Two values were tested 60sec and 5sec of Clients ndash Two values were used ndash 1 client and 5 clients
For comparison purposes the following were held constant across all test scenarios Client issued a fixed number of requests (100) across all test scenarios Client used a delay between each GET request (35sec) to better exercise
proxyrsquos caching and sleep-awareness capabilities For sleepy server test scenarios the server slept 60 sec awake for 3 sec
Format of Results The following results were collected for each
test scenario
Breakdown of the and types of transactions occurring between clientproxyserver
ldquoGETrdquo ndash Test Scenario Results
GET ndash Description of Test Scenarios
TestScenarios-GET
Scenario
CoAPSleepyServerSe7ngs CoAPSleepAwareReverseProxySe7ngs CoAPClientSe7ngs
SleepDuragton(sec)
AwakeDuragton(sec)
maxAge(sec) Caching SleepAwareSAF+
503NumberofClients
NumberofGETs
DelayBetweenClient
Requests(sec)
1a 0 Always 60 Enabled Disabled 1 100 35
1b 60 3 60 Enabled Disabled 1 100 35
1c 60 3 60 Enabled Enabled 1 100 35
2a 0 Always 60 Enabled Disabled 5 100 35
2b 60 3 60 Enabled Disabled 5 100 35
2c 60 3 60 Enabled Enabled 5 100 35
3a 0 Always 5 Enabled Disabled 5 100 35
3b 60 3 5 Enabled Disabled 5 100 35
3c 60 3 5 Enabled Enabled 5 100 35
ldquoGETrdquo ndash Test Scenario 1 Results
maxAge = 60 and 1 Client
GET ndash Scenario 1 ClientProxy Interface Transaction Mix
Scenarios 1a - Non-Sleepy Server Caching Proxy maxAge = 60sec 1b- Sleepy Server Caching Proxy maxAge = 60sec 1c - Sleepy Server Sleep Aware Proxy maxAge = 60sec
Sleep Aware Proxy has better performance for sleepy servers
0
100
200
300
400
500
600
700
1a 1b 1c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
GET ndash Scenario 1 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
Scenarios 1a - Non-Sleepy Server Caching Proxy maxAge = 60sec 1b- Sleepy Server Caching Proxy maxAge = 60sec 1c - Sleepy Server Sleep Aware Proxy maxAge = 60sec
0
100
200
300
400
500
600
700
800
1a 1b 1c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
ldquoGETrdquo ndash Test Scenario 2 Results
maxAge = 60 and 5 Clients
GET ndash Scenario 2 ClientProxy Interface Transaction Mix
Sleep Aware Proxy has slightly better performance for sleepy servers
0
200
400
600
800
1000
1200
1400
2a 2b 2c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
Scenarios 2a - Non-Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2b- Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2c - Sleepy Server Sleep Aware Proxy maxAge = 60sec 5 Clients
See ldquoExperimental Artifactsrdquo Note 1
GET ndash Scenario 2 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has slightly better performance for sleepy servers
0
50
100
150
200
250
300
350
400
2a 2b 2c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
Scenarios 2a - Non-Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2b- Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2c - Sleepy Server Sleep Aware Proxy maxAge = 60sec 5 Clients
See ldquoExperimental Artifactsrdquo Note 2
Experimental Artifacts Note 1
Currently in the experiment the sleep aware proxy checks the cached state of a resource before putting a request into its Store-and-forward queue while a server is sleeping Once in the queue the proxy unconditionally forwards the queued requests to the server once it wakes up This is not the most efficient setup and can easily be improved If the proxy instead checks its cache again before forwarding each queued request it may not need to forward the request to the server For example if there are two queued GET requests in the proxyrsquos queue that address the same resource Only the first request needs to be sent to the server the second request can use the cached response from the first request
Note 2 Currently in the experiment the sleepy server sends a sleepState PUT request to the
proxy each time it goes to sleep This is not the most efficient setup and can easily be improved For example if the server assumes that the proxy can keep track of its ONOFF cycles with its internal timers (eg as per Fig 1 of I-D) then the number of messages from the sleepy server dramatically goes down
ldquoGETrdquo ndash Test Scenario 3 Results
maxAge = 5 and 5 Clients
GET ndash Scenario 3 ClientProxy Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
Scenarios 3a - Non-Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3b- Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3c - Sleepy Server Sleep Aware Proxy maxAge = 5sec 5 Clients
0
500
1000
1500
2000
2500
3000
3500
4000
4500
5000
3a 3b 3c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
GET ndash Scenario 3 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
0
1000
2000
3000
4000
5000
6000
7000
3a 3b 3c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
Scenarios 3a - Non-Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3b- Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3c - Sleepy Server Sleep Aware Proxy maxAge = 5sec 5 Clients
Conclusions
Conclusions These results show that sleep-aware CoAP
proxy features can significantly optimize communication with sleepy servers in most scenarios
These results also show that sleep-
awareness capabilities can provide additional benefits above and beyond CoAP caching in most scenarios
Backup
Current CoAP Support of Sleepy Node (12)
CoAP proxies can use a previously cached response to service a new GET request for a sleepy origin server (as in HTTP) But if no valid cache then proxy has to attempt to
retrieve and may fail if origin server is sleeping [I-Dietf-core-coap]
Clients can discover list of resources from RD (GET rd-lookuphellip) for sleepy servers But attempt to GET resource from sleepy origin server
may fail if origin server is sleeping [IDietf-core-link-format amp IDshelby-core-resource-
directory]
Current CoAP Support of Sleepy Node (22)
Lower layer support for sleepy nodes in most wireless technologies (eg WiFi ZigBee) But limited to MAC packet scheduling for sleepy nodes
and not aware of specific needs of IP applications (like CoAP)
Proposal ndash RD Based Sleep Tracking (14)
The current CoAP approach to support sleepy nodes can be significantly improved by introducing RD based mechanisms for a CoAP client to determine whether A targeted resource is located on a sleepy server A sleepy server is currently in sleep mode or not
There is any associated caching Proxy (possibly the RD itself) for a sleepy server
Proposal ndash RD Based Sleep Tracking (24)
We define the following new RD attributes to characterize the properties of a sleepy node SleepState - Indicates whether the node is currently in
sleep mode or not (ie Sleeping or Awake) SleepDuration - Indicates the maximum duration of time
that the node stays in sleep mode TimeSleeping - Indicates the length of time the node
has been sleeping (ie if Sleep State = Sleeping) NextSleep - Indicates the next time the node will go to
sleep (ie if Sleep State = Awake)
CachingProxy ndash Indicates the caching proxy of the sleepy node (ie the RD itself or another node)
Proposal ndash RD Based Sleep Tracking (34)
These attributes are all server (node) level and are new parameters added to the RD URI Template Variables
Finally we also define a new lookup-type (ss) for the RD lookup interface specified in [I-Dshelby-core-resource-directory] This new lookup-type supports looking up the
ldquoSleepStaterdquo (ss) of a specified end-point
Proposal ndash RD Based Sleep Tracking (44)
The three time based parameters (SleepDuration TimeSleeping NextSleep) can be based on either an absolute network time (for a time synchronized network) or a relative local time (measured at the local node)
Following the approach of [I-Dietf-core-link-format] and [I-Dshelby-core-resource-directory] sleep parameters for sleepy servers can be stored by the server in the RD and accessed by all interested clients
Examples of using these parameters in a synchronous or asynchronous manner are shown in the I-D
http6lowappnet coreIETF86 2013-03-12-13
We assume people have read the drafts
Meetings serve to advance difficult issues by making good use of face-to-face communications
Note Well Be aware of the IPR principles according to RFC 3979 and its updates
uumlBlue sheetsuumlScribe(s)
96
drar-shy‐iep-shy‐core-shy‐coapsubmiqed13 to13 IESG
2013-shy‐03-shy‐13
97
OMA Lightweight M2M Overview(A new standard using lots of IETF specs including DTLS
CoAP Block Observe Resource Directory SenMLhellip)
Zach ShelbyCoRE WG IETF-86 Orlando
OMA Lightweight M2Mbull Open Mobile Alliance is well known for Device Management (DM)bull OMA Lightweight M2M is a new standard from the alliance
ndash Focused on constrained Cellular and sensor network M2M devicesndash Driven by leading operators and vendors
bull Scopendash Interfaces protocol amp security between Device and Serverndash Object and Resource modelndash Bootstrap Device Access Control Connectivity and Firmware Objects
bull Draft Specifications are availablendash httpmemberopenmobileallianceorgftpPublic_documentsDM
LightweightM2MPermanent_documentsOMA-TS-LightweightM2M-V1_0_0-20130301-Dzip
bull Timelinendash Requirements and Architecture completed 3Q2012ndash Spec ready for Consistency Review 2Q2013ndash Candidate Approval expected 3Q2013
2 CoRE WG IETF-86 Orlando
Architecture
3
Scope of LWM2M
CoRE WG IETF-86 Orlando
Object Model
bull A Client has one or more Object Instancesbull An Object is a collection of Resourcesbull A Resource is an atomic piece of information
ndash Read Written or Executed
bull Resources can have multiple instancesbull Objects and Resources are identified by a
16-bit Integer Instances by an 8-bit Integerbull ObjectsResources are accessed with
simple URIs Object IDObject InstanceResource ID
eg 1213
4 CoRE WG IETF-86 Orlando
CoRE WG IETF-86 Orlando
CoRE Resource Directory
draft-shelby-core-resource-directory-05
Z Shelby C Bormann S Krco
Backgroundbull Not a new concept
ndash think web search engine or any link directorybull Defines the interfaces to a Resource Directorybull Based on Web Linking framework and the CoRE Link Formatbull Generic REST design for use over HTTP and CoAPbull Used by OMA Lightweight M2Mbull Has already been deployed
ndash In traffic monitoring systemsndash In street lighting systemsndash For vehicular asset trackingndash By a major Cellular M2M operator
Changes since -04
bull Restricted Update to parameter updatesbull Added pagination support for the Lookup interfacebull Changed rt= to et= for the registration amp update
interfacebull Added group support
Group Management
bull RD now includes group management featuresbull New Group Function Set
ndash Register a groupbull Group name domain multicast address endpoint members
ndash Remove a groupbull Group lookup using the Lookup Function Set
ndash List registered groupsndash Find the members of a groupndash Find groups with certain endpoints or resources
Registering a Group
EP RD
| |
| - POST rd-groupgp=lights ltgtep=node1 --gt |
| |
| |
| lt---- 201 Created Location rd-group12 ---- |
| |
Req POST coaprdexamplecomrd-groupgp=lights
Payload
ltgtep=node1
ltgtep=node2
Res 201 Created
Location rd-group12
Looking up Group Members
Client RD
| |
| ----- GET rd-lookupepgp=lights1 ----------------------gt |
| |
| |
| lt-- 205 Content ltrdgtd=domain1ltrdgtd=domain2 --------- |
| |
Req GET rd-lookupepgp=lights1
Res 205 Content
ltcoaphostportgtep=node1
ltcoaphostportgtep=node2rdquo
Things for the futurebull Support for JSON representation of Web Links
ndash httptoolsietforgiddraft-bormann-core-links-json-02txtbull Registry for RD registration query parameters
ndash Already OMA Lightweight has defined some new onesbull More examples
Group 3 ldquonew workrdquo(continued)
109
drar-shy‐greevenbosch-shy‐core-shy‐profile-shy‐descripon-shy‐01Bert13 GreevenboschJeroen13 Hoebeke
Isam13 IshaqFloris13 Van13 den13 Abeele
Descripon
bull JSON13 format13 for13 signalling13 the13 servers13 capabilies
bull Signalling13 of13 supported13 opons13 media13 types13 and13 block13 sizendash Other13 items13 can13 be13 added
bull Filtering13 on13 specific13 fields13 through13 URI-shy‐Querybull Link13 hqpdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐profile-shy‐descripon
well-shy‐knownprofile
bull To13 acquire13 profile13 data13 of13 resources13 on13 a13 parcular13 service13 the13 well-shy‐knownprofile13 URI-shy‐path13 is13 introduced
bull For13 example13 to13 get13 all13 informaon13 from13 sensors13 served13 by13 wwwexampleorg13 we13 can13 do13 a13 GET13 to13 coapwwwexampleorgwell-shy‐knownprofile
bull Filtering13 on13 parcular13 resources13 is13 done13 through13 URI-shy‐Queries
Format
bull Currently13 the13 following13 fields13 are13 definedndash ldquopathrdquo13 contains13 the13 URI-shy‐path13 associated13 with13 a13 resource
ndash ldquooprdquo13 a13 numerical13 list13 of13 supported13 opon13 numbers
ndash ldquocfrdquo13 a13 numerical13 list13 of13 supported13 content-shy‐format13 numbers
ndash ldquob1srdquo13 ldquob2srdquo13 supported13 block13 sizes13 for13 Block113 and13 Block213 respecvely
Examplebull On13 the13 right13 is13 an13 example13 of13 a13 camera13 sensor13 at13 coapwwwexampleorgcam13 that13 supports13 the13 Uri-shy‐Host13 (3)13 ETag13 (4)13 Uri-shy‐Port13 (7)13 Uri-shy‐Path13 (11)13 Content-shy‐Format13 (12)13 Token13 (19)13 Block213 (23)13 and13 Proxy-shy‐Uri13 (35)13 opons
bull The13 supported13 content13 formats13 are13 textplain13 (0)13 applicaon13 link-shy‐format13 (40)13 and13 applicaonjson13 (50)
bull The13 supported13 Block213 can13 use13 25613 or13 51213 byte13 blocks
Req13 GET13 coapwwwexampleorgwell-shy‐knownprofile13 Res13 20513 Content13 (applicationjson)13 13 13 13 profile13 13 13 13 13 13 13 13 pathcam13 13 13 13 op[3471112192335]13 13 13 13 13 cf[04050]13 13 13 13 13 b2s[45]13 13 13 13
Filtering13 through13 use13 of13 URI-shy‐Query
bull Filtering13 can13 be13 done13 through13 the13 URI-shy‐Querybull Query13 format13 N=V
ndash N13 is13 a13 profile13 fieldndash V13 is13 the13 desired13 value
bull Examplesndash To13 find13 resources13 that13 support13 content13 format13 ldquoapplicaonjsonrdquo
13 GET13 wwwexampleorgwell-shy‐knownprofilecf=50ndash To13 get13 informaon13 about13 the13 camera
13 GET13 wwwexampleorgwell-shy‐knownprofilepath=cam
Open13 issues
bull Which13 other13 profile13 data13 needs13 signallingndash Content-shy‐type13 for13 different13 methods
bull Fix13 the13 order13 in13 which13 the13 profile13 fields13 must13 appearndash Non-shy‐fixed13 order13 easier13 extensible
bull Inheritance13 of13 a13 profile13 descriponbull Extend13 usage13 to13 signal13 the13 client13 profilebull Integraon13 with13 link13 format
Thank13 youQuesons
drar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval-shy‐00
Bert13 Greevenbosch
Descripon
bull The13 ldquoMinimumRequestInterval13 opon13 can13 be13 used13 to13 indicate13 the13 minimum13 me13 between13 two13 requests13 in13 a13 transacon
bull Originally13 intended13 for13 Block13 but13 also13 usable13 for13 other13 transaconsndash Example13 browsing13 a13 server
bull The13 goal13 is13 to13 reduce13 the13 server13 load13 and13 network13 traffic
bull Link13 hqpsdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval
Usage
bull The13 client13 keeps13 the13 server13 informed13 about13 its13 request13 speed13 through13 inclusion13 of13 the13 ldquoMinimumRequestIntervalrdquo13 opon
bull In13 responses13 the13 server13 fixes13 the13 minimum13 request13 interval13 through13 the13 same13 opon
bull The13 client13 obeys13 the13 speed13 indicated13 by13 the13 server
bull The13 client13 can13 send13 slower13 but13 not13 faster
Advantages
bull The13 server13 has13 means13 to13 limit13 the13 amount13 of13 incoming13 traffic
bull The13 server13 can13 prevent13 to13 become13 overloaded13 with13 too13 many13 tasks
bull The13 server13 does13 not13 need13 arficially13 slow13 down13 the13 client13 by13 sending13 late13 ACKsndash No13 need13 to13 keep13 track13 of13 delayed13 ACKsndash The13 server13 can13 perform13 other13 tasks13 instead
bull Reduced13 network13 traffic
Thank13 youQuesons
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-links-json-02txt
123
RFC 6690 (link-format) documents are somewhat foreign to many web app developerssect would prefer to have them in JSON format
There is no standard way to represent link-format documents in applicationssect but everyone knows how to handle JSON
Define a standard JSON translation for link-format
Itrsquos
not
rock
et
scien
ce
ltsensorsgtct=40title=Sensor Index ltsensorstempgtrt=temperature-cif=sensor ltsensorslightgtrt=light-luxif=sensor lthttpwwwexamplecomsensorst123gt anchor=sensorstemprel=describedby lttgtanchor=sensorstemprel=alternate [hrefsensorsct40titleSensor Index hrefsensorstemprttemperature-cifsensor hrefsensorslightrtlight-luxifsensor hrefhttpwwwexamplecomsensorst123 anchorsensorstempreldescribedby hreftanchorsensorstemprelalternate]
124
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-ipsec-for-coap-00txt
IPsec definitions for CoAP Mostly placeholder at this time Who has implementation experience with this
125
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-cross-reverse-convention-00txt
This draft has two lines of payload(based on a WGLC comment by Cullen Jennings)
coap12344567foobara=3
httpwwwproxycomwellknowncore-translate1234_4567foobara=3
Is that a useful convention to have
126
Insert CI slides here
127
128
0
5
10
15
20
25
30
35
40
10 20 30 40 50 60 70
good
put (
pps)
pps
Goodput vs pps (Econotags)
goodput
[Khattak preliminary]
Congestion Control
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-cocoa-00txt
ldquoadvancedrdquo cc (The draft is just a first shot) Others may have better ideas
129
Insert post-WGLC discussion slides here
130
Stop Continue Start
131
An Agile Retrospective
http6lowappnet coreIETF86 2013-03-12-13
Stop
132
Endless new CoAP optionssect instead use RESTful as much as possible
Move general security lifecycle out Looking at theoretical problems
http6lowappnet coreIETF86 2013-03-12-13
Continue
Interops Running code Look at real-world examples and deployments Solve their actual problems
sect Unilateral enhancements eg higher performance congestion control
sect Transports (SMS hellip)sect Make Web linking and Directories more and more usefulsect RESTful Design Paradigms for real-world problems
133
http6lowappnet coreIETF86 2013-03-12-13
Start
Further push into the (browser) web world (HTML5 browser security)
Specific supporting worksect SenMLsect URI work (dev URN hellip)sect Security Processes (next slide)
Spin outsect (We donrsquot really get to decide where this is done)
134
http6lowappnet coreIETF86 2013-03-12-13
Security
Integrate Application Network Group Keyingsect Tunnel-free setup
Donrsquot redo what has been done alreadysect ZigBee IP is finesect But what about other scenarios
Simple REST interfaces for working with keying materials and authorizationsect Start with defining objectives
Object Security for Constrained Nodes135
Re-chartering CoREWhat do we want to do now that wersquore grown up
Zach ShelbyCoRE WG IETF-86 Orlando
What is the scope
bull So we have a protocol and Web Linking what next
bull Keep with what we know besthellip1 Enhancements around CoAP2 New transports for CoAP3 New representations for Web Links4 General application layer solutions
CoRE WG IETF-86 Orlando 2
Enhancements around CoAP
bull Advanced congestion control
CoRE WG IETF-86 Orlando 3
New Transports for CoAP
bull Infrastructure for CoAP over foondash httptoolsietforgiddraft-silverajan-core-
coap-alternative-transports-01txtbull CoAP over SMS
ndash httptoolsietforgiddraft-becker-core-coap-sms-gprs-03txt
ndash OMA Lightweightbull CoAP over TCP
ndash httptoolsietforgiddraft-li-core-coap-payload-length-option-01txt
CoRE WG IETF-86 Orlando 4
New support for Web Links
bull JSON Web Linksndash httptoolsietforgiddraft-bormann-core-links-
json-02txt
2332010 CoRE WG IETF-77 Anaheim 5
General application layer solutions
bull Resource Directoryndash httptoolsietforgiddraft-shelby-core-
resource-directory-05txtndash OMA Lightweight
2332010 CoRE WG IETF-77 Anaheim 6
Next Steps
n Does the WG recommend adoptionn Intended status Informational Best Practicen Purpose Reduce arbitrary variation between proxy
implementations thereby increasing interoperability
Backup
HTTP to CoAP URI Mapping Options (12)
n Embedded Mapping n In an embedded mapping approach the HTTP URI has embedded
inside it the authority and path part of the CoAP URI n Example The CoAP resource nodecoapsomethingnetfoo can
be accessed by an HTTP client by inserting in the request httphc-proxysomethingnetcoapnodecoapsomethingnetfoo The Cross-Protocol Proxy then maps the URI to coapnodecoapsomethingnetfoo
HTTP to CoAP URI Mapping Options (22)
n Homogeneous Mapping n In a homogeneous mapping approach only the scheme portion of the URI
needs to be mapped The rest of the URI (ie authority path etc) remains unchanged
n Example The CoAP resource coapnodecoapsomethingnetfoo can be accessed by an HTTP client by requesting httpnodecoapsomethingnetfoo The Cross-Protocol Proxy receiving the request is responsible to map the URI to coapnodecoapsomethingnetfoo
n Background info n The assumption in this case is that the HTTP client would be able to
successfully resolve nodecoapsomethingnet using DNS infrastructure to return the IP address of the HC proxy Most likely this would be through a two step DNS lookup where the first DNS lookup would resolve somethingnet using public DNS infrastructure
n Then the second DNS lookup on the subdomain coap and the host node would typically be resolved by a DNS server operated by the owner of domain somethingnet So this domain owner can manage its own internal node names and subdomain allocation which would correspond to the CoAP namespace
Group 3 ldquonew workrdquo
39
Transport of CoAP over SMS USSD and GPRSdraft-becker-core-coap-sms-gprs-03
Markus Becker Kepeng LiKoojana Kuladinithi Thomas Poumltsch
CoRE WG IETF-86 Orlando
1 10
ScenariosI In M2M communication IP connectivity is not alwayssupported by the constrained end-points
I Power savingI Coverage (GPRS 3G LTE)
I SMS and USSD based communication is almost alwayssupported
210
Changes from draft-01 to draft-03 (1)
I Added possible CONNONACK interactions Section 5
I Option name changed from Reply-To- to Response-To-Section 16 and Section 101
I Added URI schemeEg coap+tel+15105550101well-knowncore Section 11
I Added possible M2M proxy scenarios Section 14
3 10
Changes from draft-01 to draft-03 (2)
I Added reference to bormann-coap-misc for other SMSencoding Section 71
I Updated requirements on Uri-Host and Uri-Port forcoap+tel Section 10
I Added security considerations Transport and ObjectSecurity Section 15
I Chose CoAP option numbers and updated the optionnumber table to meet draft-ietf-core-coap-10 Table 1
I Added an IANA registration for the URI scheme coap+telSection 162
4 10
Feedback Split coap+tel into coap+smsand coap+ussd
I How else to differ the various transports in the URII Or is the transport to use decided by the implementationI See alsodraft-silverajan-core-coap-alternative-transports-01
5 10
Feedback Response-To-Scheme option
I Should there be a Response-To-Scheme optionadditionally to Response-To-Uri-Host andResponse-To-Uri-Path
I So that a CoAP end-point which receives a request by CoAPover non-IP transport can be instructed to also use thenon-IP transport for the response
I This would imply to add aResponse-To-Telephone-Subscriber and more options forother transports that have other URI schemes than coapand coaps
6 10
Feedback Selection of Transport by Client
I When a server is reachable by various transports howdoes a client decide which transport to use
I Client-side application congurationI Leave it to a proxy which uses cellular network lookupfunctions
7 10
Feedback Potential Threats
I Trigger expensive short messagesI Redirect trac to other addressesI More threats
I Are the security measures in the draft adequateI Whitelisting on serverI Relying on cellular network security (dedicated M2M APNs)I Object security on CoAP payload
8 10
Feedback Message Exchanges
I Figures 11-18 show possible message exchanges whenclient and server have two addresses
I With NON Not using CoAP retransmission capabilityI ACK on different transportI Additional (costly) message on Transport AI Request with Content
I Which ones are allowedI Which ones are meaningful
9 10
Next steps
I Rene Uri schemeI Response-To-Scheme optionI Selection of Message ExchangeI Rene Proxying
10 10
CoAP13 Communicaon13 with13 Alternave13 Transports
Bill Silverajan and Teemu SavolainenCore WG IETF 86 Orlando
031113
Objecves13 (In13 Scope)
bull Unambiguous13 representaon13 of13 transport13 to13 be13 used13 by13 CoAP
bull Details13 how13 the13 transport13 can13 carry13 CoAP13 packet
bull Focus13 is13 on13 what13 CoAP13 communicaons13 requirements13 are
bull Allow13 CoAP13 mechanisms13 to13 exploit13 cross-shy‐layer13 opmisaons
51
031113
Non13 Goals13 (Not13 in13 scope)
bull Applicaon-shy‐level13 QoS13 requirementsbull Real-shy‐me13 constraintsbull Ordering13 reliability13 congeson13 controlbull Applicaon13 and13 network13 adaptaonbull Mobility13 and13 readdressing13 supportbull Network13 protocol13 (eg13 IPsec)13 configuraon
52
031113
Use13 Cases
bull NAT13 and13 Firewall13 traversal13 with13 TCPbull Delay13 Tolerant13 Networkingbull Non-shy‐IP13 Low13 Energy13 Protocols
53
031113
Related13 Work
bull OMA13 Lightweight13 M2M13 Protocolbull CoAP13 over13 SMSGPRSUSSD
54
031113
What13 does13 the13 work13 entail
bull The13 ability13 to13 specify13 end13 point13 idenfiers13 and13 URIs13 to13 reflect13 which13 transport13 CoAP13 can13 use
bull The13 ability13 to13 register13 to13 resource13 directories13 resource13 types13 reflecng13 types13 of13 transport13 available
bull Ability13 for13 mul-shy‐transport13 nodes13 to13 select13 transport13 to13 use13 without13 significant13 alteraon13 to13 CoAP13 packet13 structure
55
031113
Points13 to13 consider
bull Requirements13 for13 transport13 layer13 protocol13 to13 carry13 CoAP13 packets
bull Representaon13 of13 URI13 scheme13 for13 generic13 transport13 protocols
bull Opon13 extensions13 for13 CoAP13 to13 express13 available13 transports
bull Mapping13 and13 message13 sizebull Security13 consideraons
56
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
URI13 =13 scheme13 13 13 authority13 path-shy‐abempty13 [13 query13 ]
bull Within13 the13 scheme13 namebull In13 the13 URI13 pathbull As13 a13 query13 component
57
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
bull Within13 the13 scheme13 namendash coap+tel+15105550101well-shy‐knowncorendash coap+tcpexamplecom5683temperaturendash coap+blel2cap[1234567890AB]4pulse
bull Easy13 URI13 parsing13 for13 transport13 type13 and13 idenfier
bull Each13 new13 scheme13 name13 requires13 IANA13 registraon
58
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
bull In13 the13 URI13 pathndash coaphostexamplecomtransport=tcpwell-shy‐knowncorert=core-shy‐rd
bull Easy13 adopon13 of13 new13 (and13 experimental)13 CoAP13 transports13 without13 IANA13 registraon
bull Caveat13 Uri-shy‐Path13 opon13 is13 a13 Crical13 CoAP13 opon13 see13 secon13 54113 of13 I-shy‐Diep-shy‐core-shy‐coap
59
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
bull As13 a13 URI13 query13 componentndash coaphostexamplecomwell-shy‐knowncorert=core-shy‐rdq=tcp
bull Also13 easy13 to13 adopt13 new13 (and13 experimental)13 CoAP13 transports13 without13 IANA13 registraon
bull Caveat13 Uri-shy‐Query13 opon13 is13 a13 Crical13 CoAP13 opon13 see13 secon13 54113 of13 I-shy‐Diep-shy‐core-shy‐coap
60
031113
URI13 Representaons13 for13 CoAPNon13 standard13 ways
bull Transport13 in13 the13 URI13 authority13 componentndash coaphost[port][transport]13 instead13 of13 coaphost[port]
bull Transport13 as13 a13 service13 URLndash servicecoaptcphostexamplecomwell-shy‐knowncorert=core-shy‐rd
bull Above13 two13 ways13 break13 exisng13 compability13 (although13 both13 are13 based13 on13 valid13 IANA13 URI13 registraons)
61
031113
URI13 Representaons13 for13 CoAPMiscellaneous13 Consideraons
bull Ensure13 that13 transport13 is13 defined13 unambiguously13 (eg13 L2CAP13 used13 by13 both13 BLE13 and13 standard13 Bluetooth13 so13 avoid13 rdquocoap+l2caprdquo13 or13 rdquotransport=l2caprdquo13 or13 rdquoq=l2caprdquondash Can13 be13 done13 as13 WG13 consensusndash Namespace13 approach13 eg13 rdquocoap+blel2caprdquo13 or13 rdquoq=blel2caprdquo
bull Allow13 end-shy‐points13 to13 use13 CoAP13 Resource13 Directory13 to13 register13 alternave13 transports13 and13 idenfiers13 and13 provide13 periodic13 updatesndash Register13 rdquocore-shy‐transportrdquo13 resource13 type
62
031113
Transport13 Consideraons
bull Uniqueness13 of13 end-shy‐point13 idenficaonbull Communicaon13 support13 Unidireconal13 Bidireconal13 1N13 (broadcast13 mulcast13 anycast)13 messaging
bull Binary13 encoding13 Network13 byte13 orderingbull MTU13 correlaon13 with13 CoAP13 PDU13 sizebull Transport13 latency
63
031113
Security13 Consideraons
bull Drar13 does13 not13 introduce13 new13 security13 requirements13 by13 itself
bull There13 may13 be13 privacy13 issues13 if13 nodes13 use13 telephone13 numbers13 or13 MAC13 addresses13 as13 public13 end13 point13 idenfiers
64
Akbar Rahman
IETF 86 March 2013 httpwwwietforgiddraft-rahman-core-sleepy-02txt
Enhanced Sleepy Node Support for CoAP
Introduction
It is expected that in CoAP networks there will be a certain portion of devices that are sleepy and which may occasionally go into a sleep mode (ie go into a low power state to conserve power) and subsequently have reduced CoAP protocol communication ability
This I-D proposes a minimal and efficient mechanism building on the Resource Directory concept (which will be integrated into a CoAP Proxy) to enhance sleepy node support in CoAP networks
Main Question from IETF-85 (Atlanta)
What performance benefit does the proposed Sleepy Node support solution give in a network that already has standard CoAP caching enabled
Sleepy Node Performance Analysis
Experimental Network
1-5 clients
Both Sleepy and Non-
Sleepy servers
Sleepy Node Performance Analysis Network Setup
CoAPSleepyServer(s)
CoAPSleepAwareReverseProxy
CoAP
Client(s)
Request
Response
Sleep9AwareCoREResourceDirectoryCapability
PublishedSleepParameters
Sleep9AwareCoAPStoreandForwardCapability Response
Request
SleepAwareCoAP503ResponseCapability
CoAPCachingCapability
bull Server supports publishing sleep parameters to proxy bull Eg Irsquom going to be asleep for X seconds
bull Proxy supports sleep-awareness capabilities bull Proxy also supports caching capability based off of maxAge bull Protocol flow similar to approach of Figure 1 (Synchronous RD Based Sleep
Tracking) of I-D
Proxy capabilities can be selectively enableddisabled
Proxy ndash Server Interface
Client ndash Proxy Interface
CoAP Sleep-Aware Reverse Proxy Features CoRE Sleep-aware Resource Directory
Support storing published sleep parameters from CoAP servers sleepState (AWAKE ASLEEP) sleepDuration
Sleep-aware CoAP 503 Response Capability If CoAP request to a sleeping server is received proxy returns a
lsquo503 Retry-Afterrsquo response to client 503 contains a timestamp indicating when the sever will wake back up
(timestamp delivered in CoAP maxAge option) Sleep-aware CoAP Store-and-Forward Capability
If CoAP request to a sleeping server is received proxy stores request until server wakes up and then forwards it
Caching capability Cache GET responses from server if maxAge option is present
(this is not a sleep aware feature)
Goals of Performance Analysis
For networks having sleepy servers provide measurements to quantify the impact that CoAP sleep-awareness capabilities can have
See if sleep-awareness capabilities can
provide additional benefits even when CoAP caching is used
Overview of Performance Analysis Performed The analysis was broken up into a set of test scenarios Each test scenario used a different combination of the following
variables Client issued GET requests Server was configured as a sleepy or non-sleepy server Proxy caching of GET responses was enabled or disabled Proxy sleep-aware 503 response capability was enabled or disabled Proxy store-and-forward capability was enabled or disabled maxAge in GET responses ndash Two values were tested 60sec and 5sec of Clients ndash Two values were used ndash 1 client and 5 clients
For comparison purposes the following were held constant across all test scenarios Client issued a fixed number of requests (100) across all test scenarios Client used a delay between each GET request (35sec) to better exercise
proxyrsquos caching and sleep-awareness capabilities For sleepy server test scenarios the server slept 60 sec awake for 3 sec
Format of Results The following results were collected for each
test scenario
Breakdown of the and types of transactions occurring between clientproxyserver
ldquoGETrdquo ndash Test Scenario Results
GET ndash Description of Test Scenarios
TestScenarios-GET
Scenario
CoAPSleepyServerSe7ngs CoAPSleepAwareReverseProxySe7ngs CoAPClientSe7ngs
SleepDuragton(sec)
AwakeDuragton(sec)
maxAge(sec) Caching SleepAwareSAF+
503NumberofClients
NumberofGETs
DelayBetweenClient
Requests(sec)
1a 0 Always 60 Enabled Disabled 1 100 35
1b 60 3 60 Enabled Disabled 1 100 35
1c 60 3 60 Enabled Enabled 1 100 35
2a 0 Always 60 Enabled Disabled 5 100 35
2b 60 3 60 Enabled Disabled 5 100 35
2c 60 3 60 Enabled Enabled 5 100 35
3a 0 Always 5 Enabled Disabled 5 100 35
3b 60 3 5 Enabled Disabled 5 100 35
3c 60 3 5 Enabled Enabled 5 100 35
ldquoGETrdquo ndash Test Scenario 1 Results
maxAge = 60 and 1 Client
GET ndash Scenario 1 ClientProxy Interface Transaction Mix
Scenarios 1a - Non-Sleepy Server Caching Proxy maxAge = 60sec 1b- Sleepy Server Caching Proxy maxAge = 60sec 1c - Sleepy Server Sleep Aware Proxy maxAge = 60sec
Sleep Aware Proxy has better performance for sleepy servers
0
100
200
300
400
500
600
700
1a 1b 1c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
GET ndash Scenario 1 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
Scenarios 1a - Non-Sleepy Server Caching Proxy maxAge = 60sec 1b- Sleepy Server Caching Proxy maxAge = 60sec 1c - Sleepy Server Sleep Aware Proxy maxAge = 60sec
0
100
200
300
400
500
600
700
800
1a 1b 1c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
ldquoGETrdquo ndash Test Scenario 2 Results
maxAge = 60 and 5 Clients
GET ndash Scenario 2 ClientProxy Interface Transaction Mix
Sleep Aware Proxy has slightly better performance for sleepy servers
0
200
400
600
800
1000
1200
1400
2a 2b 2c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
Scenarios 2a - Non-Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2b- Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2c - Sleepy Server Sleep Aware Proxy maxAge = 60sec 5 Clients
See ldquoExperimental Artifactsrdquo Note 1
GET ndash Scenario 2 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has slightly better performance for sleepy servers
0
50
100
150
200
250
300
350
400
2a 2b 2c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
Scenarios 2a - Non-Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2b- Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2c - Sleepy Server Sleep Aware Proxy maxAge = 60sec 5 Clients
See ldquoExperimental Artifactsrdquo Note 2
Experimental Artifacts Note 1
Currently in the experiment the sleep aware proxy checks the cached state of a resource before putting a request into its Store-and-forward queue while a server is sleeping Once in the queue the proxy unconditionally forwards the queued requests to the server once it wakes up This is not the most efficient setup and can easily be improved If the proxy instead checks its cache again before forwarding each queued request it may not need to forward the request to the server For example if there are two queued GET requests in the proxyrsquos queue that address the same resource Only the first request needs to be sent to the server the second request can use the cached response from the first request
Note 2 Currently in the experiment the sleepy server sends a sleepState PUT request to the
proxy each time it goes to sleep This is not the most efficient setup and can easily be improved For example if the server assumes that the proxy can keep track of its ONOFF cycles with its internal timers (eg as per Fig 1 of I-D) then the number of messages from the sleepy server dramatically goes down
ldquoGETrdquo ndash Test Scenario 3 Results
maxAge = 5 and 5 Clients
GET ndash Scenario 3 ClientProxy Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
Scenarios 3a - Non-Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3b- Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3c - Sleepy Server Sleep Aware Proxy maxAge = 5sec 5 Clients
0
500
1000
1500
2000
2500
3000
3500
4000
4500
5000
3a 3b 3c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
GET ndash Scenario 3 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
0
1000
2000
3000
4000
5000
6000
7000
3a 3b 3c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
Scenarios 3a - Non-Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3b- Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3c - Sleepy Server Sleep Aware Proxy maxAge = 5sec 5 Clients
Conclusions
Conclusions These results show that sleep-aware CoAP
proxy features can significantly optimize communication with sleepy servers in most scenarios
These results also show that sleep-
awareness capabilities can provide additional benefits above and beyond CoAP caching in most scenarios
Backup
Current CoAP Support of Sleepy Node (12)
CoAP proxies can use a previously cached response to service a new GET request for a sleepy origin server (as in HTTP) But if no valid cache then proxy has to attempt to
retrieve and may fail if origin server is sleeping [I-Dietf-core-coap]
Clients can discover list of resources from RD (GET rd-lookuphellip) for sleepy servers But attempt to GET resource from sleepy origin server
may fail if origin server is sleeping [IDietf-core-link-format amp IDshelby-core-resource-
directory]
Current CoAP Support of Sleepy Node (22)
Lower layer support for sleepy nodes in most wireless technologies (eg WiFi ZigBee) But limited to MAC packet scheduling for sleepy nodes
and not aware of specific needs of IP applications (like CoAP)
Proposal ndash RD Based Sleep Tracking (14)
The current CoAP approach to support sleepy nodes can be significantly improved by introducing RD based mechanisms for a CoAP client to determine whether A targeted resource is located on a sleepy server A sleepy server is currently in sleep mode or not
There is any associated caching Proxy (possibly the RD itself) for a sleepy server
Proposal ndash RD Based Sleep Tracking (24)
We define the following new RD attributes to characterize the properties of a sleepy node SleepState - Indicates whether the node is currently in
sleep mode or not (ie Sleeping or Awake) SleepDuration - Indicates the maximum duration of time
that the node stays in sleep mode TimeSleeping - Indicates the length of time the node
has been sleeping (ie if Sleep State = Sleeping) NextSleep - Indicates the next time the node will go to
sleep (ie if Sleep State = Awake)
CachingProxy ndash Indicates the caching proxy of the sleepy node (ie the RD itself or another node)
Proposal ndash RD Based Sleep Tracking (34)
These attributes are all server (node) level and are new parameters added to the RD URI Template Variables
Finally we also define a new lookup-type (ss) for the RD lookup interface specified in [I-Dshelby-core-resource-directory] This new lookup-type supports looking up the
ldquoSleepStaterdquo (ss) of a specified end-point
Proposal ndash RD Based Sleep Tracking (44)
The three time based parameters (SleepDuration TimeSleeping NextSleep) can be based on either an absolute network time (for a time synchronized network) or a relative local time (measured at the local node)
Following the approach of [I-Dietf-core-link-format] and [I-Dshelby-core-resource-directory] sleep parameters for sleepy servers can be stored by the server in the RD and accessed by all interested clients
Examples of using these parameters in a synchronous or asynchronous manner are shown in the I-D
http6lowappnet coreIETF86 2013-03-12-13
We assume people have read the drafts
Meetings serve to advance difficult issues by making good use of face-to-face communications
Note Well Be aware of the IPR principles according to RFC 3979 and its updates
uumlBlue sheetsuumlScribe(s)
96
drar-shy‐iep-shy‐core-shy‐coapsubmiqed13 to13 IESG
2013-shy‐03-shy‐13
97
OMA Lightweight M2M Overview(A new standard using lots of IETF specs including DTLS
CoAP Block Observe Resource Directory SenMLhellip)
Zach ShelbyCoRE WG IETF-86 Orlando
OMA Lightweight M2Mbull Open Mobile Alliance is well known for Device Management (DM)bull OMA Lightweight M2M is a new standard from the alliance
ndash Focused on constrained Cellular and sensor network M2M devicesndash Driven by leading operators and vendors
bull Scopendash Interfaces protocol amp security between Device and Serverndash Object and Resource modelndash Bootstrap Device Access Control Connectivity and Firmware Objects
bull Draft Specifications are availablendash httpmemberopenmobileallianceorgftpPublic_documentsDM
LightweightM2MPermanent_documentsOMA-TS-LightweightM2M-V1_0_0-20130301-Dzip
bull Timelinendash Requirements and Architecture completed 3Q2012ndash Spec ready for Consistency Review 2Q2013ndash Candidate Approval expected 3Q2013
2 CoRE WG IETF-86 Orlando
Architecture
3
Scope of LWM2M
CoRE WG IETF-86 Orlando
Object Model
bull A Client has one or more Object Instancesbull An Object is a collection of Resourcesbull A Resource is an atomic piece of information
ndash Read Written or Executed
bull Resources can have multiple instancesbull Objects and Resources are identified by a
16-bit Integer Instances by an 8-bit Integerbull ObjectsResources are accessed with
simple URIs Object IDObject InstanceResource ID
eg 1213
4 CoRE WG IETF-86 Orlando
CoRE WG IETF-86 Orlando
CoRE Resource Directory
draft-shelby-core-resource-directory-05
Z Shelby C Bormann S Krco
Backgroundbull Not a new concept
ndash think web search engine or any link directorybull Defines the interfaces to a Resource Directorybull Based on Web Linking framework and the CoRE Link Formatbull Generic REST design for use over HTTP and CoAPbull Used by OMA Lightweight M2Mbull Has already been deployed
ndash In traffic monitoring systemsndash In street lighting systemsndash For vehicular asset trackingndash By a major Cellular M2M operator
Changes since -04
bull Restricted Update to parameter updatesbull Added pagination support for the Lookup interfacebull Changed rt= to et= for the registration amp update
interfacebull Added group support
Group Management
bull RD now includes group management featuresbull New Group Function Set
ndash Register a groupbull Group name domain multicast address endpoint members
ndash Remove a groupbull Group lookup using the Lookup Function Set
ndash List registered groupsndash Find the members of a groupndash Find groups with certain endpoints or resources
Registering a Group
EP RD
| |
| - POST rd-groupgp=lights ltgtep=node1 --gt |
| |
| |
| lt---- 201 Created Location rd-group12 ---- |
| |
Req POST coaprdexamplecomrd-groupgp=lights
Payload
ltgtep=node1
ltgtep=node2
Res 201 Created
Location rd-group12
Looking up Group Members
Client RD
| |
| ----- GET rd-lookupepgp=lights1 ----------------------gt |
| |
| |
| lt-- 205 Content ltrdgtd=domain1ltrdgtd=domain2 --------- |
| |
Req GET rd-lookupepgp=lights1
Res 205 Content
ltcoaphostportgtep=node1
ltcoaphostportgtep=node2rdquo
Things for the futurebull Support for JSON representation of Web Links
ndash httptoolsietforgiddraft-bormann-core-links-json-02txtbull Registry for RD registration query parameters
ndash Already OMA Lightweight has defined some new onesbull More examples
Group 3 ldquonew workrdquo(continued)
109
drar-shy‐greevenbosch-shy‐core-shy‐profile-shy‐descripon-shy‐01Bert13 GreevenboschJeroen13 Hoebeke
Isam13 IshaqFloris13 Van13 den13 Abeele
Descripon
bull JSON13 format13 for13 signalling13 the13 servers13 capabilies
bull Signalling13 of13 supported13 opons13 media13 types13 and13 block13 sizendash Other13 items13 can13 be13 added
bull Filtering13 on13 specific13 fields13 through13 URI-shy‐Querybull Link13 hqpdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐profile-shy‐descripon
well-shy‐knownprofile
bull To13 acquire13 profile13 data13 of13 resources13 on13 a13 parcular13 service13 the13 well-shy‐knownprofile13 URI-shy‐path13 is13 introduced
bull For13 example13 to13 get13 all13 informaon13 from13 sensors13 served13 by13 wwwexampleorg13 we13 can13 do13 a13 GET13 to13 coapwwwexampleorgwell-shy‐knownprofile
bull Filtering13 on13 parcular13 resources13 is13 done13 through13 URI-shy‐Queries
Format
bull Currently13 the13 following13 fields13 are13 definedndash ldquopathrdquo13 contains13 the13 URI-shy‐path13 associated13 with13 a13 resource
ndash ldquooprdquo13 a13 numerical13 list13 of13 supported13 opon13 numbers
ndash ldquocfrdquo13 a13 numerical13 list13 of13 supported13 content-shy‐format13 numbers
ndash ldquob1srdquo13 ldquob2srdquo13 supported13 block13 sizes13 for13 Block113 and13 Block213 respecvely
Examplebull On13 the13 right13 is13 an13 example13 of13 a13 camera13 sensor13 at13 coapwwwexampleorgcam13 that13 supports13 the13 Uri-shy‐Host13 (3)13 ETag13 (4)13 Uri-shy‐Port13 (7)13 Uri-shy‐Path13 (11)13 Content-shy‐Format13 (12)13 Token13 (19)13 Block213 (23)13 and13 Proxy-shy‐Uri13 (35)13 opons
bull The13 supported13 content13 formats13 are13 textplain13 (0)13 applicaon13 link-shy‐format13 (40)13 and13 applicaonjson13 (50)
bull The13 supported13 Block213 can13 use13 25613 or13 51213 byte13 blocks
Req13 GET13 coapwwwexampleorgwell-shy‐knownprofile13 Res13 20513 Content13 (applicationjson)13 13 13 13 profile13 13 13 13 13 13 13 13 pathcam13 13 13 13 op[3471112192335]13 13 13 13 13 cf[04050]13 13 13 13 13 b2s[45]13 13 13 13
Filtering13 through13 use13 of13 URI-shy‐Query
bull Filtering13 can13 be13 done13 through13 the13 URI-shy‐Querybull Query13 format13 N=V
ndash N13 is13 a13 profile13 fieldndash V13 is13 the13 desired13 value
bull Examplesndash To13 find13 resources13 that13 support13 content13 format13 ldquoapplicaonjsonrdquo
13 GET13 wwwexampleorgwell-shy‐knownprofilecf=50ndash To13 get13 informaon13 about13 the13 camera
13 GET13 wwwexampleorgwell-shy‐knownprofilepath=cam
Open13 issues
bull Which13 other13 profile13 data13 needs13 signallingndash Content-shy‐type13 for13 different13 methods
bull Fix13 the13 order13 in13 which13 the13 profile13 fields13 must13 appearndash Non-shy‐fixed13 order13 easier13 extensible
bull Inheritance13 of13 a13 profile13 descriponbull Extend13 usage13 to13 signal13 the13 client13 profilebull Integraon13 with13 link13 format
Thank13 youQuesons
drar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval-shy‐00
Bert13 Greevenbosch
Descripon
bull The13 ldquoMinimumRequestInterval13 opon13 can13 be13 used13 to13 indicate13 the13 minimum13 me13 between13 two13 requests13 in13 a13 transacon
bull Originally13 intended13 for13 Block13 but13 also13 usable13 for13 other13 transaconsndash Example13 browsing13 a13 server
bull The13 goal13 is13 to13 reduce13 the13 server13 load13 and13 network13 traffic
bull Link13 hqpsdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval
Usage
bull The13 client13 keeps13 the13 server13 informed13 about13 its13 request13 speed13 through13 inclusion13 of13 the13 ldquoMinimumRequestIntervalrdquo13 opon
bull In13 responses13 the13 server13 fixes13 the13 minimum13 request13 interval13 through13 the13 same13 opon
bull The13 client13 obeys13 the13 speed13 indicated13 by13 the13 server
bull The13 client13 can13 send13 slower13 but13 not13 faster
Advantages
bull The13 server13 has13 means13 to13 limit13 the13 amount13 of13 incoming13 traffic
bull The13 server13 can13 prevent13 to13 become13 overloaded13 with13 too13 many13 tasks
bull The13 server13 does13 not13 need13 arficially13 slow13 down13 the13 client13 by13 sending13 late13 ACKsndash No13 need13 to13 keep13 track13 of13 delayed13 ACKsndash The13 server13 can13 perform13 other13 tasks13 instead
bull Reduced13 network13 traffic
Thank13 youQuesons
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-links-json-02txt
123
RFC 6690 (link-format) documents are somewhat foreign to many web app developerssect would prefer to have them in JSON format
There is no standard way to represent link-format documents in applicationssect but everyone knows how to handle JSON
Define a standard JSON translation for link-format
Itrsquos
not
rock
et
scien
ce
ltsensorsgtct=40title=Sensor Index ltsensorstempgtrt=temperature-cif=sensor ltsensorslightgtrt=light-luxif=sensor lthttpwwwexamplecomsensorst123gt anchor=sensorstemprel=describedby lttgtanchor=sensorstemprel=alternate [hrefsensorsct40titleSensor Index hrefsensorstemprttemperature-cifsensor hrefsensorslightrtlight-luxifsensor hrefhttpwwwexamplecomsensorst123 anchorsensorstempreldescribedby hreftanchorsensorstemprelalternate]
124
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-ipsec-for-coap-00txt
IPsec definitions for CoAP Mostly placeholder at this time Who has implementation experience with this
125
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-cross-reverse-convention-00txt
This draft has two lines of payload(based on a WGLC comment by Cullen Jennings)
coap12344567foobara=3
httpwwwproxycomwellknowncore-translate1234_4567foobara=3
Is that a useful convention to have
126
Insert CI slides here
127
128
0
5
10
15
20
25
30
35
40
10 20 30 40 50 60 70
good
put (
pps)
pps
Goodput vs pps (Econotags)
goodput
[Khattak preliminary]
Congestion Control
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-cocoa-00txt
ldquoadvancedrdquo cc (The draft is just a first shot) Others may have better ideas
129
Insert post-WGLC discussion slides here
130
Stop Continue Start
131
An Agile Retrospective
http6lowappnet coreIETF86 2013-03-12-13
Stop
132
Endless new CoAP optionssect instead use RESTful as much as possible
Move general security lifecycle out Looking at theoretical problems
http6lowappnet coreIETF86 2013-03-12-13
Continue
Interops Running code Look at real-world examples and deployments Solve their actual problems
sect Unilateral enhancements eg higher performance congestion control
sect Transports (SMS hellip)sect Make Web linking and Directories more and more usefulsect RESTful Design Paradigms for real-world problems
133
http6lowappnet coreIETF86 2013-03-12-13
Start
Further push into the (browser) web world (HTML5 browser security)
Specific supporting worksect SenMLsect URI work (dev URN hellip)sect Security Processes (next slide)
Spin outsect (We donrsquot really get to decide where this is done)
134
http6lowappnet coreIETF86 2013-03-12-13
Security
Integrate Application Network Group Keyingsect Tunnel-free setup
Donrsquot redo what has been done alreadysect ZigBee IP is finesect But what about other scenarios
Simple REST interfaces for working with keying materials and authorizationsect Start with defining objectives
Object Security for Constrained Nodes135
Re-chartering CoREWhat do we want to do now that wersquore grown up
Zach ShelbyCoRE WG IETF-86 Orlando
What is the scope
bull So we have a protocol and Web Linking what next
bull Keep with what we know besthellip1 Enhancements around CoAP2 New transports for CoAP3 New representations for Web Links4 General application layer solutions
CoRE WG IETF-86 Orlando 2
Enhancements around CoAP
bull Advanced congestion control
CoRE WG IETF-86 Orlando 3
New Transports for CoAP
bull Infrastructure for CoAP over foondash httptoolsietforgiddraft-silverajan-core-
coap-alternative-transports-01txtbull CoAP over SMS
ndash httptoolsietforgiddraft-becker-core-coap-sms-gprs-03txt
ndash OMA Lightweightbull CoAP over TCP
ndash httptoolsietforgiddraft-li-core-coap-payload-length-option-01txt
CoRE WG IETF-86 Orlando 4
New support for Web Links
bull JSON Web Linksndash httptoolsietforgiddraft-bormann-core-links-
json-02txt
2332010 CoRE WG IETF-77 Anaheim 5
General application layer solutions
bull Resource Directoryndash httptoolsietforgiddraft-shelby-core-
resource-directory-05txtndash OMA Lightweight
2332010 CoRE WG IETF-77 Anaheim 6
Backup
HTTP to CoAP URI Mapping Options (12)
n Embedded Mapping n In an embedded mapping approach the HTTP URI has embedded
inside it the authority and path part of the CoAP URI n Example The CoAP resource nodecoapsomethingnetfoo can
be accessed by an HTTP client by inserting in the request httphc-proxysomethingnetcoapnodecoapsomethingnetfoo The Cross-Protocol Proxy then maps the URI to coapnodecoapsomethingnetfoo
HTTP to CoAP URI Mapping Options (22)
n Homogeneous Mapping n In a homogeneous mapping approach only the scheme portion of the URI
needs to be mapped The rest of the URI (ie authority path etc) remains unchanged
n Example The CoAP resource coapnodecoapsomethingnetfoo can be accessed by an HTTP client by requesting httpnodecoapsomethingnetfoo The Cross-Protocol Proxy receiving the request is responsible to map the URI to coapnodecoapsomethingnetfoo
n Background info n The assumption in this case is that the HTTP client would be able to
successfully resolve nodecoapsomethingnet using DNS infrastructure to return the IP address of the HC proxy Most likely this would be through a two step DNS lookup where the first DNS lookup would resolve somethingnet using public DNS infrastructure
n Then the second DNS lookup on the subdomain coap and the host node would typically be resolved by a DNS server operated by the owner of domain somethingnet So this domain owner can manage its own internal node names and subdomain allocation which would correspond to the CoAP namespace
Group 3 ldquonew workrdquo
39
Transport of CoAP over SMS USSD and GPRSdraft-becker-core-coap-sms-gprs-03
Markus Becker Kepeng LiKoojana Kuladinithi Thomas Poumltsch
CoRE WG IETF-86 Orlando
1 10
ScenariosI In M2M communication IP connectivity is not alwayssupported by the constrained end-points
I Power savingI Coverage (GPRS 3G LTE)
I SMS and USSD based communication is almost alwayssupported
210
Changes from draft-01 to draft-03 (1)
I Added possible CONNONACK interactions Section 5
I Option name changed from Reply-To- to Response-To-Section 16 and Section 101
I Added URI schemeEg coap+tel+15105550101well-knowncore Section 11
I Added possible M2M proxy scenarios Section 14
3 10
Changes from draft-01 to draft-03 (2)
I Added reference to bormann-coap-misc for other SMSencoding Section 71
I Updated requirements on Uri-Host and Uri-Port forcoap+tel Section 10
I Added security considerations Transport and ObjectSecurity Section 15
I Chose CoAP option numbers and updated the optionnumber table to meet draft-ietf-core-coap-10 Table 1
I Added an IANA registration for the URI scheme coap+telSection 162
4 10
Feedback Split coap+tel into coap+smsand coap+ussd
I How else to differ the various transports in the URII Or is the transport to use decided by the implementationI See alsodraft-silverajan-core-coap-alternative-transports-01
5 10
Feedback Response-To-Scheme option
I Should there be a Response-To-Scheme optionadditionally to Response-To-Uri-Host andResponse-To-Uri-Path
I So that a CoAP end-point which receives a request by CoAPover non-IP transport can be instructed to also use thenon-IP transport for the response
I This would imply to add aResponse-To-Telephone-Subscriber and more options forother transports that have other URI schemes than coapand coaps
6 10
Feedback Selection of Transport by Client
I When a server is reachable by various transports howdoes a client decide which transport to use
I Client-side application congurationI Leave it to a proxy which uses cellular network lookupfunctions
7 10
Feedback Potential Threats
I Trigger expensive short messagesI Redirect trac to other addressesI More threats
I Are the security measures in the draft adequateI Whitelisting on serverI Relying on cellular network security (dedicated M2M APNs)I Object security on CoAP payload
8 10
Feedback Message Exchanges
I Figures 11-18 show possible message exchanges whenclient and server have two addresses
I With NON Not using CoAP retransmission capabilityI ACK on different transportI Additional (costly) message on Transport AI Request with Content
I Which ones are allowedI Which ones are meaningful
9 10
Next steps
I Rene Uri schemeI Response-To-Scheme optionI Selection of Message ExchangeI Rene Proxying
10 10
CoAP13 Communicaon13 with13 Alternave13 Transports
Bill Silverajan and Teemu SavolainenCore WG IETF 86 Orlando
031113
Objecves13 (In13 Scope)
bull Unambiguous13 representaon13 of13 transport13 to13 be13 used13 by13 CoAP
bull Details13 how13 the13 transport13 can13 carry13 CoAP13 packet
bull Focus13 is13 on13 what13 CoAP13 communicaons13 requirements13 are
bull Allow13 CoAP13 mechanisms13 to13 exploit13 cross-shy‐layer13 opmisaons
51
031113
Non13 Goals13 (Not13 in13 scope)
bull Applicaon-shy‐level13 QoS13 requirementsbull Real-shy‐me13 constraintsbull Ordering13 reliability13 congeson13 controlbull Applicaon13 and13 network13 adaptaonbull Mobility13 and13 readdressing13 supportbull Network13 protocol13 (eg13 IPsec)13 configuraon
52
031113
Use13 Cases
bull NAT13 and13 Firewall13 traversal13 with13 TCPbull Delay13 Tolerant13 Networkingbull Non-shy‐IP13 Low13 Energy13 Protocols
53
031113
Related13 Work
bull OMA13 Lightweight13 M2M13 Protocolbull CoAP13 over13 SMSGPRSUSSD
54
031113
What13 does13 the13 work13 entail
bull The13 ability13 to13 specify13 end13 point13 idenfiers13 and13 URIs13 to13 reflect13 which13 transport13 CoAP13 can13 use
bull The13 ability13 to13 register13 to13 resource13 directories13 resource13 types13 reflecng13 types13 of13 transport13 available
bull Ability13 for13 mul-shy‐transport13 nodes13 to13 select13 transport13 to13 use13 without13 significant13 alteraon13 to13 CoAP13 packet13 structure
55
031113
Points13 to13 consider
bull Requirements13 for13 transport13 layer13 protocol13 to13 carry13 CoAP13 packets
bull Representaon13 of13 URI13 scheme13 for13 generic13 transport13 protocols
bull Opon13 extensions13 for13 CoAP13 to13 express13 available13 transports
bull Mapping13 and13 message13 sizebull Security13 consideraons
56
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
URI13 =13 scheme13 13 13 authority13 path-shy‐abempty13 [13 query13 ]
bull Within13 the13 scheme13 namebull In13 the13 URI13 pathbull As13 a13 query13 component
57
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
bull Within13 the13 scheme13 namendash coap+tel+15105550101well-shy‐knowncorendash coap+tcpexamplecom5683temperaturendash coap+blel2cap[1234567890AB]4pulse
bull Easy13 URI13 parsing13 for13 transport13 type13 and13 idenfier
bull Each13 new13 scheme13 name13 requires13 IANA13 registraon
58
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
bull In13 the13 URI13 pathndash coaphostexamplecomtransport=tcpwell-shy‐knowncorert=core-shy‐rd
bull Easy13 adopon13 of13 new13 (and13 experimental)13 CoAP13 transports13 without13 IANA13 registraon
bull Caveat13 Uri-shy‐Path13 opon13 is13 a13 Crical13 CoAP13 opon13 see13 secon13 54113 of13 I-shy‐Diep-shy‐core-shy‐coap
59
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
bull As13 a13 URI13 query13 componentndash coaphostexamplecomwell-shy‐knowncorert=core-shy‐rdq=tcp
bull Also13 easy13 to13 adopt13 new13 (and13 experimental)13 CoAP13 transports13 without13 IANA13 registraon
bull Caveat13 Uri-shy‐Query13 opon13 is13 a13 Crical13 CoAP13 opon13 see13 secon13 54113 of13 I-shy‐Diep-shy‐core-shy‐coap
60
031113
URI13 Representaons13 for13 CoAPNon13 standard13 ways
bull Transport13 in13 the13 URI13 authority13 componentndash coaphost[port][transport]13 instead13 of13 coaphost[port]
bull Transport13 as13 a13 service13 URLndash servicecoaptcphostexamplecomwell-shy‐knowncorert=core-shy‐rd
bull Above13 two13 ways13 break13 exisng13 compability13 (although13 both13 are13 based13 on13 valid13 IANA13 URI13 registraons)
61
031113
URI13 Representaons13 for13 CoAPMiscellaneous13 Consideraons
bull Ensure13 that13 transport13 is13 defined13 unambiguously13 (eg13 L2CAP13 used13 by13 both13 BLE13 and13 standard13 Bluetooth13 so13 avoid13 rdquocoap+l2caprdquo13 or13 rdquotransport=l2caprdquo13 or13 rdquoq=l2caprdquondash Can13 be13 done13 as13 WG13 consensusndash Namespace13 approach13 eg13 rdquocoap+blel2caprdquo13 or13 rdquoq=blel2caprdquo
bull Allow13 end-shy‐points13 to13 use13 CoAP13 Resource13 Directory13 to13 register13 alternave13 transports13 and13 idenfiers13 and13 provide13 periodic13 updatesndash Register13 rdquocore-shy‐transportrdquo13 resource13 type
62
031113
Transport13 Consideraons
bull Uniqueness13 of13 end-shy‐point13 idenficaonbull Communicaon13 support13 Unidireconal13 Bidireconal13 1N13 (broadcast13 mulcast13 anycast)13 messaging
bull Binary13 encoding13 Network13 byte13 orderingbull MTU13 correlaon13 with13 CoAP13 PDU13 sizebull Transport13 latency
63
031113
Security13 Consideraons
bull Drar13 does13 not13 introduce13 new13 security13 requirements13 by13 itself
bull There13 may13 be13 privacy13 issues13 if13 nodes13 use13 telephone13 numbers13 or13 MAC13 addresses13 as13 public13 end13 point13 idenfiers
64
Akbar Rahman
IETF 86 March 2013 httpwwwietforgiddraft-rahman-core-sleepy-02txt
Enhanced Sleepy Node Support for CoAP
Introduction
It is expected that in CoAP networks there will be a certain portion of devices that are sleepy and which may occasionally go into a sleep mode (ie go into a low power state to conserve power) and subsequently have reduced CoAP protocol communication ability
This I-D proposes a minimal and efficient mechanism building on the Resource Directory concept (which will be integrated into a CoAP Proxy) to enhance sleepy node support in CoAP networks
Main Question from IETF-85 (Atlanta)
What performance benefit does the proposed Sleepy Node support solution give in a network that already has standard CoAP caching enabled
Sleepy Node Performance Analysis
Experimental Network
1-5 clients
Both Sleepy and Non-
Sleepy servers
Sleepy Node Performance Analysis Network Setup
CoAPSleepyServer(s)
CoAPSleepAwareReverseProxy
CoAP
Client(s)
Request
Response
Sleep9AwareCoREResourceDirectoryCapability
PublishedSleepParameters
Sleep9AwareCoAPStoreandForwardCapability Response
Request
SleepAwareCoAP503ResponseCapability
CoAPCachingCapability
bull Server supports publishing sleep parameters to proxy bull Eg Irsquom going to be asleep for X seconds
bull Proxy supports sleep-awareness capabilities bull Proxy also supports caching capability based off of maxAge bull Protocol flow similar to approach of Figure 1 (Synchronous RD Based Sleep
Tracking) of I-D
Proxy capabilities can be selectively enableddisabled
Proxy ndash Server Interface
Client ndash Proxy Interface
CoAP Sleep-Aware Reverse Proxy Features CoRE Sleep-aware Resource Directory
Support storing published sleep parameters from CoAP servers sleepState (AWAKE ASLEEP) sleepDuration
Sleep-aware CoAP 503 Response Capability If CoAP request to a sleeping server is received proxy returns a
lsquo503 Retry-Afterrsquo response to client 503 contains a timestamp indicating when the sever will wake back up
(timestamp delivered in CoAP maxAge option) Sleep-aware CoAP Store-and-Forward Capability
If CoAP request to a sleeping server is received proxy stores request until server wakes up and then forwards it
Caching capability Cache GET responses from server if maxAge option is present
(this is not a sleep aware feature)
Goals of Performance Analysis
For networks having sleepy servers provide measurements to quantify the impact that CoAP sleep-awareness capabilities can have
See if sleep-awareness capabilities can
provide additional benefits even when CoAP caching is used
Overview of Performance Analysis Performed The analysis was broken up into a set of test scenarios Each test scenario used a different combination of the following
variables Client issued GET requests Server was configured as a sleepy or non-sleepy server Proxy caching of GET responses was enabled or disabled Proxy sleep-aware 503 response capability was enabled or disabled Proxy store-and-forward capability was enabled or disabled maxAge in GET responses ndash Two values were tested 60sec and 5sec of Clients ndash Two values were used ndash 1 client and 5 clients
For comparison purposes the following were held constant across all test scenarios Client issued a fixed number of requests (100) across all test scenarios Client used a delay between each GET request (35sec) to better exercise
proxyrsquos caching and sleep-awareness capabilities For sleepy server test scenarios the server slept 60 sec awake for 3 sec
Format of Results The following results were collected for each
test scenario
Breakdown of the and types of transactions occurring between clientproxyserver
ldquoGETrdquo ndash Test Scenario Results
GET ndash Description of Test Scenarios
TestScenarios-GET
Scenario
CoAPSleepyServerSe7ngs CoAPSleepAwareReverseProxySe7ngs CoAPClientSe7ngs
SleepDuragton(sec)
AwakeDuragton(sec)
maxAge(sec) Caching SleepAwareSAF+
503NumberofClients
NumberofGETs
DelayBetweenClient
Requests(sec)
1a 0 Always 60 Enabled Disabled 1 100 35
1b 60 3 60 Enabled Disabled 1 100 35
1c 60 3 60 Enabled Enabled 1 100 35
2a 0 Always 60 Enabled Disabled 5 100 35
2b 60 3 60 Enabled Disabled 5 100 35
2c 60 3 60 Enabled Enabled 5 100 35
3a 0 Always 5 Enabled Disabled 5 100 35
3b 60 3 5 Enabled Disabled 5 100 35
3c 60 3 5 Enabled Enabled 5 100 35
ldquoGETrdquo ndash Test Scenario 1 Results
maxAge = 60 and 1 Client
GET ndash Scenario 1 ClientProxy Interface Transaction Mix
Scenarios 1a - Non-Sleepy Server Caching Proxy maxAge = 60sec 1b- Sleepy Server Caching Proxy maxAge = 60sec 1c - Sleepy Server Sleep Aware Proxy maxAge = 60sec
Sleep Aware Proxy has better performance for sleepy servers
0
100
200
300
400
500
600
700
1a 1b 1c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
GET ndash Scenario 1 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
Scenarios 1a - Non-Sleepy Server Caching Proxy maxAge = 60sec 1b- Sleepy Server Caching Proxy maxAge = 60sec 1c - Sleepy Server Sleep Aware Proxy maxAge = 60sec
0
100
200
300
400
500
600
700
800
1a 1b 1c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
ldquoGETrdquo ndash Test Scenario 2 Results
maxAge = 60 and 5 Clients
GET ndash Scenario 2 ClientProxy Interface Transaction Mix
Sleep Aware Proxy has slightly better performance for sleepy servers
0
200
400
600
800
1000
1200
1400
2a 2b 2c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
Scenarios 2a - Non-Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2b- Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2c - Sleepy Server Sleep Aware Proxy maxAge = 60sec 5 Clients
See ldquoExperimental Artifactsrdquo Note 1
GET ndash Scenario 2 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has slightly better performance for sleepy servers
0
50
100
150
200
250
300
350
400
2a 2b 2c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
Scenarios 2a - Non-Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2b- Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2c - Sleepy Server Sleep Aware Proxy maxAge = 60sec 5 Clients
See ldquoExperimental Artifactsrdquo Note 2
Experimental Artifacts Note 1
Currently in the experiment the sleep aware proxy checks the cached state of a resource before putting a request into its Store-and-forward queue while a server is sleeping Once in the queue the proxy unconditionally forwards the queued requests to the server once it wakes up This is not the most efficient setup and can easily be improved If the proxy instead checks its cache again before forwarding each queued request it may not need to forward the request to the server For example if there are two queued GET requests in the proxyrsquos queue that address the same resource Only the first request needs to be sent to the server the second request can use the cached response from the first request
Note 2 Currently in the experiment the sleepy server sends a sleepState PUT request to the
proxy each time it goes to sleep This is not the most efficient setup and can easily be improved For example if the server assumes that the proxy can keep track of its ONOFF cycles with its internal timers (eg as per Fig 1 of I-D) then the number of messages from the sleepy server dramatically goes down
ldquoGETrdquo ndash Test Scenario 3 Results
maxAge = 5 and 5 Clients
GET ndash Scenario 3 ClientProxy Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
Scenarios 3a - Non-Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3b- Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3c - Sleepy Server Sleep Aware Proxy maxAge = 5sec 5 Clients
0
500
1000
1500
2000
2500
3000
3500
4000
4500
5000
3a 3b 3c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
GET ndash Scenario 3 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
0
1000
2000
3000
4000
5000
6000
7000
3a 3b 3c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
Scenarios 3a - Non-Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3b- Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3c - Sleepy Server Sleep Aware Proxy maxAge = 5sec 5 Clients
Conclusions
Conclusions These results show that sleep-aware CoAP
proxy features can significantly optimize communication with sleepy servers in most scenarios
These results also show that sleep-
awareness capabilities can provide additional benefits above and beyond CoAP caching in most scenarios
Backup
Current CoAP Support of Sleepy Node (12)
CoAP proxies can use a previously cached response to service a new GET request for a sleepy origin server (as in HTTP) But if no valid cache then proxy has to attempt to
retrieve and may fail if origin server is sleeping [I-Dietf-core-coap]
Clients can discover list of resources from RD (GET rd-lookuphellip) for sleepy servers But attempt to GET resource from sleepy origin server
may fail if origin server is sleeping [IDietf-core-link-format amp IDshelby-core-resource-
directory]
Current CoAP Support of Sleepy Node (22)
Lower layer support for sleepy nodes in most wireless technologies (eg WiFi ZigBee) But limited to MAC packet scheduling for sleepy nodes
and not aware of specific needs of IP applications (like CoAP)
Proposal ndash RD Based Sleep Tracking (14)
The current CoAP approach to support sleepy nodes can be significantly improved by introducing RD based mechanisms for a CoAP client to determine whether A targeted resource is located on a sleepy server A sleepy server is currently in sleep mode or not
There is any associated caching Proxy (possibly the RD itself) for a sleepy server
Proposal ndash RD Based Sleep Tracking (24)
We define the following new RD attributes to characterize the properties of a sleepy node SleepState - Indicates whether the node is currently in
sleep mode or not (ie Sleeping or Awake) SleepDuration - Indicates the maximum duration of time
that the node stays in sleep mode TimeSleeping - Indicates the length of time the node
has been sleeping (ie if Sleep State = Sleeping) NextSleep - Indicates the next time the node will go to
sleep (ie if Sleep State = Awake)
CachingProxy ndash Indicates the caching proxy of the sleepy node (ie the RD itself or another node)
Proposal ndash RD Based Sleep Tracking (34)
These attributes are all server (node) level and are new parameters added to the RD URI Template Variables
Finally we also define a new lookup-type (ss) for the RD lookup interface specified in [I-Dshelby-core-resource-directory] This new lookup-type supports looking up the
ldquoSleepStaterdquo (ss) of a specified end-point
Proposal ndash RD Based Sleep Tracking (44)
The three time based parameters (SleepDuration TimeSleeping NextSleep) can be based on either an absolute network time (for a time synchronized network) or a relative local time (measured at the local node)
Following the approach of [I-Dietf-core-link-format] and [I-Dshelby-core-resource-directory] sleep parameters for sleepy servers can be stored by the server in the RD and accessed by all interested clients
Examples of using these parameters in a synchronous or asynchronous manner are shown in the I-D
http6lowappnet coreIETF86 2013-03-12-13
We assume people have read the drafts
Meetings serve to advance difficult issues by making good use of face-to-face communications
Note Well Be aware of the IPR principles according to RFC 3979 and its updates
uumlBlue sheetsuumlScribe(s)
96
drar-shy‐iep-shy‐core-shy‐coapsubmiqed13 to13 IESG
2013-shy‐03-shy‐13
97
OMA Lightweight M2M Overview(A new standard using lots of IETF specs including DTLS
CoAP Block Observe Resource Directory SenMLhellip)
Zach ShelbyCoRE WG IETF-86 Orlando
OMA Lightweight M2Mbull Open Mobile Alliance is well known for Device Management (DM)bull OMA Lightweight M2M is a new standard from the alliance
ndash Focused on constrained Cellular and sensor network M2M devicesndash Driven by leading operators and vendors
bull Scopendash Interfaces protocol amp security between Device and Serverndash Object and Resource modelndash Bootstrap Device Access Control Connectivity and Firmware Objects
bull Draft Specifications are availablendash httpmemberopenmobileallianceorgftpPublic_documentsDM
LightweightM2MPermanent_documentsOMA-TS-LightweightM2M-V1_0_0-20130301-Dzip
bull Timelinendash Requirements and Architecture completed 3Q2012ndash Spec ready for Consistency Review 2Q2013ndash Candidate Approval expected 3Q2013
2 CoRE WG IETF-86 Orlando
Architecture
3
Scope of LWM2M
CoRE WG IETF-86 Orlando
Object Model
bull A Client has one or more Object Instancesbull An Object is a collection of Resourcesbull A Resource is an atomic piece of information
ndash Read Written or Executed
bull Resources can have multiple instancesbull Objects and Resources are identified by a
16-bit Integer Instances by an 8-bit Integerbull ObjectsResources are accessed with
simple URIs Object IDObject InstanceResource ID
eg 1213
4 CoRE WG IETF-86 Orlando
CoRE WG IETF-86 Orlando
CoRE Resource Directory
draft-shelby-core-resource-directory-05
Z Shelby C Bormann S Krco
Backgroundbull Not a new concept
ndash think web search engine or any link directorybull Defines the interfaces to a Resource Directorybull Based on Web Linking framework and the CoRE Link Formatbull Generic REST design for use over HTTP and CoAPbull Used by OMA Lightweight M2Mbull Has already been deployed
ndash In traffic monitoring systemsndash In street lighting systemsndash For vehicular asset trackingndash By a major Cellular M2M operator
Changes since -04
bull Restricted Update to parameter updatesbull Added pagination support for the Lookup interfacebull Changed rt= to et= for the registration amp update
interfacebull Added group support
Group Management
bull RD now includes group management featuresbull New Group Function Set
ndash Register a groupbull Group name domain multicast address endpoint members
ndash Remove a groupbull Group lookup using the Lookup Function Set
ndash List registered groupsndash Find the members of a groupndash Find groups with certain endpoints or resources
Registering a Group
EP RD
| |
| - POST rd-groupgp=lights ltgtep=node1 --gt |
| |
| |
| lt---- 201 Created Location rd-group12 ---- |
| |
Req POST coaprdexamplecomrd-groupgp=lights
Payload
ltgtep=node1
ltgtep=node2
Res 201 Created
Location rd-group12
Looking up Group Members
Client RD
| |
| ----- GET rd-lookupepgp=lights1 ----------------------gt |
| |
| |
| lt-- 205 Content ltrdgtd=domain1ltrdgtd=domain2 --------- |
| |
Req GET rd-lookupepgp=lights1
Res 205 Content
ltcoaphostportgtep=node1
ltcoaphostportgtep=node2rdquo
Things for the futurebull Support for JSON representation of Web Links
ndash httptoolsietforgiddraft-bormann-core-links-json-02txtbull Registry for RD registration query parameters
ndash Already OMA Lightweight has defined some new onesbull More examples
Group 3 ldquonew workrdquo(continued)
109
drar-shy‐greevenbosch-shy‐core-shy‐profile-shy‐descripon-shy‐01Bert13 GreevenboschJeroen13 Hoebeke
Isam13 IshaqFloris13 Van13 den13 Abeele
Descripon
bull JSON13 format13 for13 signalling13 the13 servers13 capabilies
bull Signalling13 of13 supported13 opons13 media13 types13 and13 block13 sizendash Other13 items13 can13 be13 added
bull Filtering13 on13 specific13 fields13 through13 URI-shy‐Querybull Link13 hqpdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐profile-shy‐descripon
well-shy‐knownprofile
bull To13 acquire13 profile13 data13 of13 resources13 on13 a13 parcular13 service13 the13 well-shy‐knownprofile13 URI-shy‐path13 is13 introduced
bull For13 example13 to13 get13 all13 informaon13 from13 sensors13 served13 by13 wwwexampleorg13 we13 can13 do13 a13 GET13 to13 coapwwwexampleorgwell-shy‐knownprofile
bull Filtering13 on13 parcular13 resources13 is13 done13 through13 URI-shy‐Queries
Format
bull Currently13 the13 following13 fields13 are13 definedndash ldquopathrdquo13 contains13 the13 URI-shy‐path13 associated13 with13 a13 resource
ndash ldquooprdquo13 a13 numerical13 list13 of13 supported13 opon13 numbers
ndash ldquocfrdquo13 a13 numerical13 list13 of13 supported13 content-shy‐format13 numbers
ndash ldquob1srdquo13 ldquob2srdquo13 supported13 block13 sizes13 for13 Block113 and13 Block213 respecvely
Examplebull On13 the13 right13 is13 an13 example13 of13 a13 camera13 sensor13 at13 coapwwwexampleorgcam13 that13 supports13 the13 Uri-shy‐Host13 (3)13 ETag13 (4)13 Uri-shy‐Port13 (7)13 Uri-shy‐Path13 (11)13 Content-shy‐Format13 (12)13 Token13 (19)13 Block213 (23)13 and13 Proxy-shy‐Uri13 (35)13 opons
bull The13 supported13 content13 formats13 are13 textplain13 (0)13 applicaon13 link-shy‐format13 (40)13 and13 applicaonjson13 (50)
bull The13 supported13 Block213 can13 use13 25613 or13 51213 byte13 blocks
Req13 GET13 coapwwwexampleorgwell-shy‐knownprofile13 Res13 20513 Content13 (applicationjson)13 13 13 13 profile13 13 13 13 13 13 13 13 pathcam13 13 13 13 op[3471112192335]13 13 13 13 13 cf[04050]13 13 13 13 13 b2s[45]13 13 13 13
Filtering13 through13 use13 of13 URI-shy‐Query
bull Filtering13 can13 be13 done13 through13 the13 URI-shy‐Querybull Query13 format13 N=V
ndash N13 is13 a13 profile13 fieldndash V13 is13 the13 desired13 value
bull Examplesndash To13 find13 resources13 that13 support13 content13 format13 ldquoapplicaonjsonrdquo
13 GET13 wwwexampleorgwell-shy‐knownprofilecf=50ndash To13 get13 informaon13 about13 the13 camera
13 GET13 wwwexampleorgwell-shy‐knownprofilepath=cam
Open13 issues
bull Which13 other13 profile13 data13 needs13 signallingndash Content-shy‐type13 for13 different13 methods
bull Fix13 the13 order13 in13 which13 the13 profile13 fields13 must13 appearndash Non-shy‐fixed13 order13 easier13 extensible
bull Inheritance13 of13 a13 profile13 descriponbull Extend13 usage13 to13 signal13 the13 client13 profilebull Integraon13 with13 link13 format
Thank13 youQuesons
drar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval-shy‐00
Bert13 Greevenbosch
Descripon
bull The13 ldquoMinimumRequestInterval13 opon13 can13 be13 used13 to13 indicate13 the13 minimum13 me13 between13 two13 requests13 in13 a13 transacon
bull Originally13 intended13 for13 Block13 but13 also13 usable13 for13 other13 transaconsndash Example13 browsing13 a13 server
bull The13 goal13 is13 to13 reduce13 the13 server13 load13 and13 network13 traffic
bull Link13 hqpsdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval
Usage
bull The13 client13 keeps13 the13 server13 informed13 about13 its13 request13 speed13 through13 inclusion13 of13 the13 ldquoMinimumRequestIntervalrdquo13 opon
bull In13 responses13 the13 server13 fixes13 the13 minimum13 request13 interval13 through13 the13 same13 opon
bull The13 client13 obeys13 the13 speed13 indicated13 by13 the13 server
bull The13 client13 can13 send13 slower13 but13 not13 faster
Advantages
bull The13 server13 has13 means13 to13 limit13 the13 amount13 of13 incoming13 traffic
bull The13 server13 can13 prevent13 to13 become13 overloaded13 with13 too13 many13 tasks
bull The13 server13 does13 not13 need13 arficially13 slow13 down13 the13 client13 by13 sending13 late13 ACKsndash No13 need13 to13 keep13 track13 of13 delayed13 ACKsndash The13 server13 can13 perform13 other13 tasks13 instead
bull Reduced13 network13 traffic
Thank13 youQuesons
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-links-json-02txt
123
RFC 6690 (link-format) documents are somewhat foreign to many web app developerssect would prefer to have them in JSON format
There is no standard way to represent link-format documents in applicationssect but everyone knows how to handle JSON
Define a standard JSON translation for link-format
Itrsquos
not
rock
et
scien
ce
ltsensorsgtct=40title=Sensor Index ltsensorstempgtrt=temperature-cif=sensor ltsensorslightgtrt=light-luxif=sensor lthttpwwwexamplecomsensorst123gt anchor=sensorstemprel=describedby lttgtanchor=sensorstemprel=alternate [hrefsensorsct40titleSensor Index hrefsensorstemprttemperature-cifsensor hrefsensorslightrtlight-luxifsensor hrefhttpwwwexamplecomsensorst123 anchorsensorstempreldescribedby hreftanchorsensorstemprelalternate]
124
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-ipsec-for-coap-00txt
IPsec definitions for CoAP Mostly placeholder at this time Who has implementation experience with this
125
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-cross-reverse-convention-00txt
This draft has two lines of payload(based on a WGLC comment by Cullen Jennings)
coap12344567foobara=3
httpwwwproxycomwellknowncore-translate1234_4567foobara=3
Is that a useful convention to have
126
Insert CI slides here
127
128
0
5
10
15
20
25
30
35
40
10 20 30 40 50 60 70
good
put (
pps)
pps
Goodput vs pps (Econotags)
goodput
[Khattak preliminary]
Congestion Control
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-cocoa-00txt
ldquoadvancedrdquo cc (The draft is just a first shot) Others may have better ideas
129
Insert post-WGLC discussion slides here
130
Stop Continue Start
131
An Agile Retrospective
http6lowappnet coreIETF86 2013-03-12-13
Stop
132
Endless new CoAP optionssect instead use RESTful as much as possible
Move general security lifecycle out Looking at theoretical problems
http6lowappnet coreIETF86 2013-03-12-13
Continue
Interops Running code Look at real-world examples and deployments Solve their actual problems
sect Unilateral enhancements eg higher performance congestion control
sect Transports (SMS hellip)sect Make Web linking and Directories more and more usefulsect RESTful Design Paradigms for real-world problems
133
http6lowappnet coreIETF86 2013-03-12-13
Start
Further push into the (browser) web world (HTML5 browser security)
Specific supporting worksect SenMLsect URI work (dev URN hellip)sect Security Processes (next slide)
Spin outsect (We donrsquot really get to decide where this is done)
134
http6lowappnet coreIETF86 2013-03-12-13
Security
Integrate Application Network Group Keyingsect Tunnel-free setup
Donrsquot redo what has been done alreadysect ZigBee IP is finesect But what about other scenarios
Simple REST interfaces for working with keying materials and authorizationsect Start with defining objectives
Object Security for Constrained Nodes135
Re-chartering CoREWhat do we want to do now that wersquore grown up
Zach ShelbyCoRE WG IETF-86 Orlando
What is the scope
bull So we have a protocol and Web Linking what next
bull Keep with what we know besthellip1 Enhancements around CoAP2 New transports for CoAP3 New representations for Web Links4 General application layer solutions
CoRE WG IETF-86 Orlando 2
Enhancements around CoAP
bull Advanced congestion control
CoRE WG IETF-86 Orlando 3
New Transports for CoAP
bull Infrastructure for CoAP over foondash httptoolsietforgiddraft-silverajan-core-
coap-alternative-transports-01txtbull CoAP over SMS
ndash httptoolsietforgiddraft-becker-core-coap-sms-gprs-03txt
ndash OMA Lightweightbull CoAP over TCP
ndash httptoolsietforgiddraft-li-core-coap-payload-length-option-01txt
CoRE WG IETF-86 Orlando 4
New support for Web Links
bull JSON Web Linksndash httptoolsietforgiddraft-bormann-core-links-
json-02txt
2332010 CoRE WG IETF-77 Anaheim 5
General application layer solutions
bull Resource Directoryndash httptoolsietforgiddraft-shelby-core-
resource-directory-05txtndash OMA Lightweight
2332010 CoRE WG IETF-77 Anaheim 6
HTTP to CoAP URI Mapping Options (12)
n Embedded Mapping n In an embedded mapping approach the HTTP URI has embedded
inside it the authority and path part of the CoAP URI n Example The CoAP resource nodecoapsomethingnetfoo can
be accessed by an HTTP client by inserting in the request httphc-proxysomethingnetcoapnodecoapsomethingnetfoo The Cross-Protocol Proxy then maps the URI to coapnodecoapsomethingnetfoo
HTTP to CoAP URI Mapping Options (22)
n Homogeneous Mapping n In a homogeneous mapping approach only the scheme portion of the URI
needs to be mapped The rest of the URI (ie authority path etc) remains unchanged
n Example The CoAP resource coapnodecoapsomethingnetfoo can be accessed by an HTTP client by requesting httpnodecoapsomethingnetfoo The Cross-Protocol Proxy receiving the request is responsible to map the URI to coapnodecoapsomethingnetfoo
n Background info n The assumption in this case is that the HTTP client would be able to
successfully resolve nodecoapsomethingnet using DNS infrastructure to return the IP address of the HC proxy Most likely this would be through a two step DNS lookup where the first DNS lookup would resolve somethingnet using public DNS infrastructure
n Then the second DNS lookup on the subdomain coap and the host node would typically be resolved by a DNS server operated by the owner of domain somethingnet So this domain owner can manage its own internal node names and subdomain allocation which would correspond to the CoAP namespace
Group 3 ldquonew workrdquo
39
Transport of CoAP over SMS USSD and GPRSdraft-becker-core-coap-sms-gprs-03
Markus Becker Kepeng LiKoojana Kuladinithi Thomas Poumltsch
CoRE WG IETF-86 Orlando
1 10
ScenariosI In M2M communication IP connectivity is not alwayssupported by the constrained end-points
I Power savingI Coverage (GPRS 3G LTE)
I SMS and USSD based communication is almost alwayssupported
210
Changes from draft-01 to draft-03 (1)
I Added possible CONNONACK interactions Section 5
I Option name changed from Reply-To- to Response-To-Section 16 and Section 101
I Added URI schemeEg coap+tel+15105550101well-knowncore Section 11
I Added possible M2M proxy scenarios Section 14
3 10
Changes from draft-01 to draft-03 (2)
I Added reference to bormann-coap-misc for other SMSencoding Section 71
I Updated requirements on Uri-Host and Uri-Port forcoap+tel Section 10
I Added security considerations Transport and ObjectSecurity Section 15
I Chose CoAP option numbers and updated the optionnumber table to meet draft-ietf-core-coap-10 Table 1
I Added an IANA registration for the URI scheme coap+telSection 162
4 10
Feedback Split coap+tel into coap+smsand coap+ussd
I How else to differ the various transports in the URII Or is the transport to use decided by the implementationI See alsodraft-silverajan-core-coap-alternative-transports-01
5 10
Feedback Response-To-Scheme option
I Should there be a Response-To-Scheme optionadditionally to Response-To-Uri-Host andResponse-To-Uri-Path
I So that a CoAP end-point which receives a request by CoAPover non-IP transport can be instructed to also use thenon-IP transport for the response
I This would imply to add aResponse-To-Telephone-Subscriber and more options forother transports that have other URI schemes than coapand coaps
6 10
Feedback Selection of Transport by Client
I When a server is reachable by various transports howdoes a client decide which transport to use
I Client-side application congurationI Leave it to a proxy which uses cellular network lookupfunctions
7 10
Feedback Potential Threats
I Trigger expensive short messagesI Redirect trac to other addressesI More threats
I Are the security measures in the draft adequateI Whitelisting on serverI Relying on cellular network security (dedicated M2M APNs)I Object security on CoAP payload
8 10
Feedback Message Exchanges
I Figures 11-18 show possible message exchanges whenclient and server have two addresses
I With NON Not using CoAP retransmission capabilityI ACK on different transportI Additional (costly) message on Transport AI Request with Content
I Which ones are allowedI Which ones are meaningful
9 10
Next steps
I Rene Uri schemeI Response-To-Scheme optionI Selection of Message ExchangeI Rene Proxying
10 10
CoAP13 Communicaon13 with13 Alternave13 Transports
Bill Silverajan and Teemu SavolainenCore WG IETF 86 Orlando
031113
Objecves13 (In13 Scope)
bull Unambiguous13 representaon13 of13 transport13 to13 be13 used13 by13 CoAP
bull Details13 how13 the13 transport13 can13 carry13 CoAP13 packet
bull Focus13 is13 on13 what13 CoAP13 communicaons13 requirements13 are
bull Allow13 CoAP13 mechanisms13 to13 exploit13 cross-shy‐layer13 opmisaons
51
031113
Non13 Goals13 (Not13 in13 scope)
bull Applicaon-shy‐level13 QoS13 requirementsbull Real-shy‐me13 constraintsbull Ordering13 reliability13 congeson13 controlbull Applicaon13 and13 network13 adaptaonbull Mobility13 and13 readdressing13 supportbull Network13 protocol13 (eg13 IPsec)13 configuraon
52
031113
Use13 Cases
bull NAT13 and13 Firewall13 traversal13 with13 TCPbull Delay13 Tolerant13 Networkingbull Non-shy‐IP13 Low13 Energy13 Protocols
53
031113
Related13 Work
bull OMA13 Lightweight13 M2M13 Protocolbull CoAP13 over13 SMSGPRSUSSD
54
031113
What13 does13 the13 work13 entail
bull The13 ability13 to13 specify13 end13 point13 idenfiers13 and13 URIs13 to13 reflect13 which13 transport13 CoAP13 can13 use
bull The13 ability13 to13 register13 to13 resource13 directories13 resource13 types13 reflecng13 types13 of13 transport13 available
bull Ability13 for13 mul-shy‐transport13 nodes13 to13 select13 transport13 to13 use13 without13 significant13 alteraon13 to13 CoAP13 packet13 structure
55
031113
Points13 to13 consider
bull Requirements13 for13 transport13 layer13 protocol13 to13 carry13 CoAP13 packets
bull Representaon13 of13 URI13 scheme13 for13 generic13 transport13 protocols
bull Opon13 extensions13 for13 CoAP13 to13 express13 available13 transports
bull Mapping13 and13 message13 sizebull Security13 consideraons
56
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
URI13 =13 scheme13 13 13 authority13 path-shy‐abempty13 [13 query13 ]
bull Within13 the13 scheme13 namebull In13 the13 URI13 pathbull As13 a13 query13 component
57
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
bull Within13 the13 scheme13 namendash coap+tel+15105550101well-shy‐knowncorendash coap+tcpexamplecom5683temperaturendash coap+blel2cap[1234567890AB]4pulse
bull Easy13 URI13 parsing13 for13 transport13 type13 and13 idenfier
bull Each13 new13 scheme13 name13 requires13 IANA13 registraon
58
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
bull In13 the13 URI13 pathndash coaphostexamplecomtransport=tcpwell-shy‐knowncorert=core-shy‐rd
bull Easy13 adopon13 of13 new13 (and13 experimental)13 CoAP13 transports13 without13 IANA13 registraon
bull Caveat13 Uri-shy‐Path13 opon13 is13 a13 Crical13 CoAP13 opon13 see13 secon13 54113 of13 I-shy‐Diep-shy‐core-shy‐coap
59
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
bull As13 a13 URI13 query13 componentndash coaphostexamplecomwell-shy‐knowncorert=core-shy‐rdq=tcp
bull Also13 easy13 to13 adopt13 new13 (and13 experimental)13 CoAP13 transports13 without13 IANA13 registraon
bull Caveat13 Uri-shy‐Query13 opon13 is13 a13 Crical13 CoAP13 opon13 see13 secon13 54113 of13 I-shy‐Diep-shy‐core-shy‐coap
60
031113
URI13 Representaons13 for13 CoAPNon13 standard13 ways
bull Transport13 in13 the13 URI13 authority13 componentndash coaphost[port][transport]13 instead13 of13 coaphost[port]
bull Transport13 as13 a13 service13 URLndash servicecoaptcphostexamplecomwell-shy‐knowncorert=core-shy‐rd
bull Above13 two13 ways13 break13 exisng13 compability13 (although13 both13 are13 based13 on13 valid13 IANA13 URI13 registraons)
61
031113
URI13 Representaons13 for13 CoAPMiscellaneous13 Consideraons
bull Ensure13 that13 transport13 is13 defined13 unambiguously13 (eg13 L2CAP13 used13 by13 both13 BLE13 and13 standard13 Bluetooth13 so13 avoid13 rdquocoap+l2caprdquo13 or13 rdquotransport=l2caprdquo13 or13 rdquoq=l2caprdquondash Can13 be13 done13 as13 WG13 consensusndash Namespace13 approach13 eg13 rdquocoap+blel2caprdquo13 or13 rdquoq=blel2caprdquo
bull Allow13 end-shy‐points13 to13 use13 CoAP13 Resource13 Directory13 to13 register13 alternave13 transports13 and13 idenfiers13 and13 provide13 periodic13 updatesndash Register13 rdquocore-shy‐transportrdquo13 resource13 type
62
031113
Transport13 Consideraons
bull Uniqueness13 of13 end-shy‐point13 idenficaonbull Communicaon13 support13 Unidireconal13 Bidireconal13 1N13 (broadcast13 mulcast13 anycast)13 messaging
bull Binary13 encoding13 Network13 byte13 orderingbull MTU13 correlaon13 with13 CoAP13 PDU13 sizebull Transport13 latency
63
031113
Security13 Consideraons
bull Drar13 does13 not13 introduce13 new13 security13 requirements13 by13 itself
bull There13 may13 be13 privacy13 issues13 if13 nodes13 use13 telephone13 numbers13 or13 MAC13 addresses13 as13 public13 end13 point13 idenfiers
64
Akbar Rahman
IETF 86 March 2013 httpwwwietforgiddraft-rahman-core-sleepy-02txt
Enhanced Sleepy Node Support for CoAP
Introduction
It is expected that in CoAP networks there will be a certain portion of devices that are sleepy and which may occasionally go into a sleep mode (ie go into a low power state to conserve power) and subsequently have reduced CoAP protocol communication ability
This I-D proposes a minimal and efficient mechanism building on the Resource Directory concept (which will be integrated into a CoAP Proxy) to enhance sleepy node support in CoAP networks
Main Question from IETF-85 (Atlanta)
What performance benefit does the proposed Sleepy Node support solution give in a network that already has standard CoAP caching enabled
Sleepy Node Performance Analysis
Experimental Network
1-5 clients
Both Sleepy and Non-
Sleepy servers
Sleepy Node Performance Analysis Network Setup
CoAPSleepyServer(s)
CoAPSleepAwareReverseProxy
CoAP
Client(s)
Request
Response
Sleep9AwareCoREResourceDirectoryCapability
PublishedSleepParameters
Sleep9AwareCoAPStoreandForwardCapability Response
Request
SleepAwareCoAP503ResponseCapability
CoAPCachingCapability
bull Server supports publishing sleep parameters to proxy bull Eg Irsquom going to be asleep for X seconds
bull Proxy supports sleep-awareness capabilities bull Proxy also supports caching capability based off of maxAge bull Protocol flow similar to approach of Figure 1 (Synchronous RD Based Sleep
Tracking) of I-D
Proxy capabilities can be selectively enableddisabled
Proxy ndash Server Interface
Client ndash Proxy Interface
CoAP Sleep-Aware Reverse Proxy Features CoRE Sleep-aware Resource Directory
Support storing published sleep parameters from CoAP servers sleepState (AWAKE ASLEEP) sleepDuration
Sleep-aware CoAP 503 Response Capability If CoAP request to a sleeping server is received proxy returns a
lsquo503 Retry-Afterrsquo response to client 503 contains a timestamp indicating when the sever will wake back up
(timestamp delivered in CoAP maxAge option) Sleep-aware CoAP Store-and-Forward Capability
If CoAP request to a sleeping server is received proxy stores request until server wakes up and then forwards it
Caching capability Cache GET responses from server if maxAge option is present
(this is not a sleep aware feature)
Goals of Performance Analysis
For networks having sleepy servers provide measurements to quantify the impact that CoAP sleep-awareness capabilities can have
See if sleep-awareness capabilities can
provide additional benefits even when CoAP caching is used
Overview of Performance Analysis Performed The analysis was broken up into a set of test scenarios Each test scenario used a different combination of the following
variables Client issued GET requests Server was configured as a sleepy or non-sleepy server Proxy caching of GET responses was enabled or disabled Proxy sleep-aware 503 response capability was enabled or disabled Proxy store-and-forward capability was enabled or disabled maxAge in GET responses ndash Two values were tested 60sec and 5sec of Clients ndash Two values were used ndash 1 client and 5 clients
For comparison purposes the following were held constant across all test scenarios Client issued a fixed number of requests (100) across all test scenarios Client used a delay between each GET request (35sec) to better exercise
proxyrsquos caching and sleep-awareness capabilities For sleepy server test scenarios the server slept 60 sec awake for 3 sec
Format of Results The following results were collected for each
test scenario
Breakdown of the and types of transactions occurring between clientproxyserver
ldquoGETrdquo ndash Test Scenario Results
GET ndash Description of Test Scenarios
TestScenarios-GET
Scenario
CoAPSleepyServerSe7ngs CoAPSleepAwareReverseProxySe7ngs CoAPClientSe7ngs
SleepDuragton(sec)
AwakeDuragton(sec)
maxAge(sec) Caching SleepAwareSAF+
503NumberofClients
NumberofGETs
DelayBetweenClient
Requests(sec)
1a 0 Always 60 Enabled Disabled 1 100 35
1b 60 3 60 Enabled Disabled 1 100 35
1c 60 3 60 Enabled Enabled 1 100 35
2a 0 Always 60 Enabled Disabled 5 100 35
2b 60 3 60 Enabled Disabled 5 100 35
2c 60 3 60 Enabled Enabled 5 100 35
3a 0 Always 5 Enabled Disabled 5 100 35
3b 60 3 5 Enabled Disabled 5 100 35
3c 60 3 5 Enabled Enabled 5 100 35
ldquoGETrdquo ndash Test Scenario 1 Results
maxAge = 60 and 1 Client
GET ndash Scenario 1 ClientProxy Interface Transaction Mix
Scenarios 1a - Non-Sleepy Server Caching Proxy maxAge = 60sec 1b- Sleepy Server Caching Proxy maxAge = 60sec 1c - Sleepy Server Sleep Aware Proxy maxAge = 60sec
Sleep Aware Proxy has better performance for sleepy servers
0
100
200
300
400
500
600
700
1a 1b 1c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
GET ndash Scenario 1 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
Scenarios 1a - Non-Sleepy Server Caching Proxy maxAge = 60sec 1b- Sleepy Server Caching Proxy maxAge = 60sec 1c - Sleepy Server Sleep Aware Proxy maxAge = 60sec
0
100
200
300
400
500
600
700
800
1a 1b 1c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
ldquoGETrdquo ndash Test Scenario 2 Results
maxAge = 60 and 5 Clients
GET ndash Scenario 2 ClientProxy Interface Transaction Mix
Sleep Aware Proxy has slightly better performance for sleepy servers
0
200
400
600
800
1000
1200
1400
2a 2b 2c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
Scenarios 2a - Non-Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2b- Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2c - Sleepy Server Sleep Aware Proxy maxAge = 60sec 5 Clients
See ldquoExperimental Artifactsrdquo Note 1
GET ndash Scenario 2 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has slightly better performance for sleepy servers
0
50
100
150
200
250
300
350
400
2a 2b 2c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
Scenarios 2a - Non-Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2b- Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2c - Sleepy Server Sleep Aware Proxy maxAge = 60sec 5 Clients
See ldquoExperimental Artifactsrdquo Note 2
Experimental Artifacts Note 1
Currently in the experiment the sleep aware proxy checks the cached state of a resource before putting a request into its Store-and-forward queue while a server is sleeping Once in the queue the proxy unconditionally forwards the queued requests to the server once it wakes up This is not the most efficient setup and can easily be improved If the proxy instead checks its cache again before forwarding each queued request it may not need to forward the request to the server For example if there are two queued GET requests in the proxyrsquos queue that address the same resource Only the first request needs to be sent to the server the second request can use the cached response from the first request
Note 2 Currently in the experiment the sleepy server sends a sleepState PUT request to the
proxy each time it goes to sleep This is not the most efficient setup and can easily be improved For example if the server assumes that the proxy can keep track of its ONOFF cycles with its internal timers (eg as per Fig 1 of I-D) then the number of messages from the sleepy server dramatically goes down
ldquoGETrdquo ndash Test Scenario 3 Results
maxAge = 5 and 5 Clients
GET ndash Scenario 3 ClientProxy Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
Scenarios 3a - Non-Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3b- Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3c - Sleepy Server Sleep Aware Proxy maxAge = 5sec 5 Clients
0
500
1000
1500
2000
2500
3000
3500
4000
4500
5000
3a 3b 3c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
GET ndash Scenario 3 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
0
1000
2000
3000
4000
5000
6000
7000
3a 3b 3c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
Scenarios 3a - Non-Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3b- Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3c - Sleepy Server Sleep Aware Proxy maxAge = 5sec 5 Clients
Conclusions
Conclusions These results show that sleep-aware CoAP
proxy features can significantly optimize communication with sleepy servers in most scenarios
These results also show that sleep-
awareness capabilities can provide additional benefits above and beyond CoAP caching in most scenarios
Backup
Current CoAP Support of Sleepy Node (12)
CoAP proxies can use a previously cached response to service a new GET request for a sleepy origin server (as in HTTP) But if no valid cache then proxy has to attempt to
retrieve and may fail if origin server is sleeping [I-Dietf-core-coap]
Clients can discover list of resources from RD (GET rd-lookuphellip) for sleepy servers But attempt to GET resource from sleepy origin server
may fail if origin server is sleeping [IDietf-core-link-format amp IDshelby-core-resource-
directory]
Current CoAP Support of Sleepy Node (22)
Lower layer support for sleepy nodes in most wireless technologies (eg WiFi ZigBee) But limited to MAC packet scheduling for sleepy nodes
and not aware of specific needs of IP applications (like CoAP)
Proposal ndash RD Based Sleep Tracking (14)
The current CoAP approach to support sleepy nodes can be significantly improved by introducing RD based mechanisms for a CoAP client to determine whether A targeted resource is located on a sleepy server A sleepy server is currently in sleep mode or not
There is any associated caching Proxy (possibly the RD itself) for a sleepy server
Proposal ndash RD Based Sleep Tracking (24)
We define the following new RD attributes to characterize the properties of a sleepy node SleepState - Indicates whether the node is currently in
sleep mode or not (ie Sleeping or Awake) SleepDuration - Indicates the maximum duration of time
that the node stays in sleep mode TimeSleeping - Indicates the length of time the node
has been sleeping (ie if Sleep State = Sleeping) NextSleep - Indicates the next time the node will go to
sleep (ie if Sleep State = Awake)
CachingProxy ndash Indicates the caching proxy of the sleepy node (ie the RD itself or another node)
Proposal ndash RD Based Sleep Tracking (34)
These attributes are all server (node) level and are new parameters added to the RD URI Template Variables
Finally we also define a new lookup-type (ss) for the RD lookup interface specified in [I-Dshelby-core-resource-directory] This new lookup-type supports looking up the
ldquoSleepStaterdquo (ss) of a specified end-point
Proposal ndash RD Based Sleep Tracking (44)
The three time based parameters (SleepDuration TimeSleeping NextSleep) can be based on either an absolute network time (for a time synchronized network) or a relative local time (measured at the local node)
Following the approach of [I-Dietf-core-link-format] and [I-Dshelby-core-resource-directory] sleep parameters for sleepy servers can be stored by the server in the RD and accessed by all interested clients
Examples of using these parameters in a synchronous or asynchronous manner are shown in the I-D
http6lowappnet coreIETF86 2013-03-12-13
We assume people have read the drafts
Meetings serve to advance difficult issues by making good use of face-to-face communications
Note Well Be aware of the IPR principles according to RFC 3979 and its updates
uumlBlue sheetsuumlScribe(s)
96
drar-shy‐iep-shy‐core-shy‐coapsubmiqed13 to13 IESG
2013-shy‐03-shy‐13
97
OMA Lightweight M2M Overview(A new standard using lots of IETF specs including DTLS
CoAP Block Observe Resource Directory SenMLhellip)
Zach ShelbyCoRE WG IETF-86 Orlando
OMA Lightweight M2Mbull Open Mobile Alliance is well known for Device Management (DM)bull OMA Lightweight M2M is a new standard from the alliance
ndash Focused on constrained Cellular and sensor network M2M devicesndash Driven by leading operators and vendors
bull Scopendash Interfaces protocol amp security between Device and Serverndash Object and Resource modelndash Bootstrap Device Access Control Connectivity and Firmware Objects
bull Draft Specifications are availablendash httpmemberopenmobileallianceorgftpPublic_documentsDM
LightweightM2MPermanent_documentsOMA-TS-LightweightM2M-V1_0_0-20130301-Dzip
bull Timelinendash Requirements and Architecture completed 3Q2012ndash Spec ready for Consistency Review 2Q2013ndash Candidate Approval expected 3Q2013
2 CoRE WG IETF-86 Orlando
Architecture
3
Scope of LWM2M
CoRE WG IETF-86 Orlando
Object Model
bull A Client has one or more Object Instancesbull An Object is a collection of Resourcesbull A Resource is an atomic piece of information
ndash Read Written or Executed
bull Resources can have multiple instancesbull Objects and Resources are identified by a
16-bit Integer Instances by an 8-bit Integerbull ObjectsResources are accessed with
simple URIs Object IDObject InstanceResource ID
eg 1213
4 CoRE WG IETF-86 Orlando
CoRE WG IETF-86 Orlando
CoRE Resource Directory
draft-shelby-core-resource-directory-05
Z Shelby C Bormann S Krco
Backgroundbull Not a new concept
ndash think web search engine or any link directorybull Defines the interfaces to a Resource Directorybull Based on Web Linking framework and the CoRE Link Formatbull Generic REST design for use over HTTP and CoAPbull Used by OMA Lightweight M2Mbull Has already been deployed
ndash In traffic monitoring systemsndash In street lighting systemsndash For vehicular asset trackingndash By a major Cellular M2M operator
Changes since -04
bull Restricted Update to parameter updatesbull Added pagination support for the Lookup interfacebull Changed rt= to et= for the registration amp update
interfacebull Added group support
Group Management
bull RD now includes group management featuresbull New Group Function Set
ndash Register a groupbull Group name domain multicast address endpoint members
ndash Remove a groupbull Group lookup using the Lookup Function Set
ndash List registered groupsndash Find the members of a groupndash Find groups with certain endpoints or resources
Registering a Group
EP RD
| |
| - POST rd-groupgp=lights ltgtep=node1 --gt |
| |
| |
| lt---- 201 Created Location rd-group12 ---- |
| |
Req POST coaprdexamplecomrd-groupgp=lights
Payload
ltgtep=node1
ltgtep=node2
Res 201 Created
Location rd-group12
Looking up Group Members
Client RD
| |
| ----- GET rd-lookupepgp=lights1 ----------------------gt |
| |
| |
| lt-- 205 Content ltrdgtd=domain1ltrdgtd=domain2 --------- |
| |
Req GET rd-lookupepgp=lights1
Res 205 Content
ltcoaphostportgtep=node1
ltcoaphostportgtep=node2rdquo
Things for the futurebull Support for JSON representation of Web Links
ndash httptoolsietforgiddraft-bormann-core-links-json-02txtbull Registry for RD registration query parameters
ndash Already OMA Lightweight has defined some new onesbull More examples
Group 3 ldquonew workrdquo(continued)
109
drar-shy‐greevenbosch-shy‐core-shy‐profile-shy‐descripon-shy‐01Bert13 GreevenboschJeroen13 Hoebeke
Isam13 IshaqFloris13 Van13 den13 Abeele
Descripon
bull JSON13 format13 for13 signalling13 the13 servers13 capabilies
bull Signalling13 of13 supported13 opons13 media13 types13 and13 block13 sizendash Other13 items13 can13 be13 added
bull Filtering13 on13 specific13 fields13 through13 URI-shy‐Querybull Link13 hqpdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐profile-shy‐descripon
well-shy‐knownprofile
bull To13 acquire13 profile13 data13 of13 resources13 on13 a13 parcular13 service13 the13 well-shy‐knownprofile13 URI-shy‐path13 is13 introduced
bull For13 example13 to13 get13 all13 informaon13 from13 sensors13 served13 by13 wwwexampleorg13 we13 can13 do13 a13 GET13 to13 coapwwwexampleorgwell-shy‐knownprofile
bull Filtering13 on13 parcular13 resources13 is13 done13 through13 URI-shy‐Queries
Format
bull Currently13 the13 following13 fields13 are13 definedndash ldquopathrdquo13 contains13 the13 URI-shy‐path13 associated13 with13 a13 resource
ndash ldquooprdquo13 a13 numerical13 list13 of13 supported13 opon13 numbers
ndash ldquocfrdquo13 a13 numerical13 list13 of13 supported13 content-shy‐format13 numbers
ndash ldquob1srdquo13 ldquob2srdquo13 supported13 block13 sizes13 for13 Block113 and13 Block213 respecvely
Examplebull On13 the13 right13 is13 an13 example13 of13 a13 camera13 sensor13 at13 coapwwwexampleorgcam13 that13 supports13 the13 Uri-shy‐Host13 (3)13 ETag13 (4)13 Uri-shy‐Port13 (7)13 Uri-shy‐Path13 (11)13 Content-shy‐Format13 (12)13 Token13 (19)13 Block213 (23)13 and13 Proxy-shy‐Uri13 (35)13 opons
bull The13 supported13 content13 formats13 are13 textplain13 (0)13 applicaon13 link-shy‐format13 (40)13 and13 applicaonjson13 (50)
bull The13 supported13 Block213 can13 use13 25613 or13 51213 byte13 blocks
Req13 GET13 coapwwwexampleorgwell-shy‐knownprofile13 Res13 20513 Content13 (applicationjson)13 13 13 13 profile13 13 13 13 13 13 13 13 pathcam13 13 13 13 op[3471112192335]13 13 13 13 13 cf[04050]13 13 13 13 13 b2s[45]13 13 13 13
Filtering13 through13 use13 of13 URI-shy‐Query
bull Filtering13 can13 be13 done13 through13 the13 URI-shy‐Querybull Query13 format13 N=V
ndash N13 is13 a13 profile13 fieldndash V13 is13 the13 desired13 value
bull Examplesndash To13 find13 resources13 that13 support13 content13 format13 ldquoapplicaonjsonrdquo
13 GET13 wwwexampleorgwell-shy‐knownprofilecf=50ndash To13 get13 informaon13 about13 the13 camera
13 GET13 wwwexampleorgwell-shy‐knownprofilepath=cam
Open13 issues
bull Which13 other13 profile13 data13 needs13 signallingndash Content-shy‐type13 for13 different13 methods
bull Fix13 the13 order13 in13 which13 the13 profile13 fields13 must13 appearndash Non-shy‐fixed13 order13 easier13 extensible
bull Inheritance13 of13 a13 profile13 descriponbull Extend13 usage13 to13 signal13 the13 client13 profilebull Integraon13 with13 link13 format
Thank13 youQuesons
drar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval-shy‐00
Bert13 Greevenbosch
Descripon
bull The13 ldquoMinimumRequestInterval13 opon13 can13 be13 used13 to13 indicate13 the13 minimum13 me13 between13 two13 requests13 in13 a13 transacon
bull Originally13 intended13 for13 Block13 but13 also13 usable13 for13 other13 transaconsndash Example13 browsing13 a13 server
bull The13 goal13 is13 to13 reduce13 the13 server13 load13 and13 network13 traffic
bull Link13 hqpsdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval
Usage
bull The13 client13 keeps13 the13 server13 informed13 about13 its13 request13 speed13 through13 inclusion13 of13 the13 ldquoMinimumRequestIntervalrdquo13 opon
bull In13 responses13 the13 server13 fixes13 the13 minimum13 request13 interval13 through13 the13 same13 opon
bull The13 client13 obeys13 the13 speed13 indicated13 by13 the13 server
bull The13 client13 can13 send13 slower13 but13 not13 faster
Advantages
bull The13 server13 has13 means13 to13 limit13 the13 amount13 of13 incoming13 traffic
bull The13 server13 can13 prevent13 to13 become13 overloaded13 with13 too13 many13 tasks
bull The13 server13 does13 not13 need13 arficially13 slow13 down13 the13 client13 by13 sending13 late13 ACKsndash No13 need13 to13 keep13 track13 of13 delayed13 ACKsndash The13 server13 can13 perform13 other13 tasks13 instead
bull Reduced13 network13 traffic
Thank13 youQuesons
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-links-json-02txt
123
RFC 6690 (link-format) documents are somewhat foreign to many web app developerssect would prefer to have them in JSON format
There is no standard way to represent link-format documents in applicationssect but everyone knows how to handle JSON
Define a standard JSON translation for link-format
Itrsquos
not
rock
et
scien
ce
ltsensorsgtct=40title=Sensor Index ltsensorstempgtrt=temperature-cif=sensor ltsensorslightgtrt=light-luxif=sensor lthttpwwwexamplecomsensorst123gt anchor=sensorstemprel=describedby lttgtanchor=sensorstemprel=alternate [hrefsensorsct40titleSensor Index hrefsensorstemprttemperature-cifsensor hrefsensorslightrtlight-luxifsensor hrefhttpwwwexamplecomsensorst123 anchorsensorstempreldescribedby hreftanchorsensorstemprelalternate]
124
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-ipsec-for-coap-00txt
IPsec definitions for CoAP Mostly placeholder at this time Who has implementation experience with this
125
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-cross-reverse-convention-00txt
This draft has two lines of payload(based on a WGLC comment by Cullen Jennings)
coap12344567foobara=3
httpwwwproxycomwellknowncore-translate1234_4567foobara=3
Is that a useful convention to have
126
Insert CI slides here
127
128
0
5
10
15
20
25
30
35
40
10 20 30 40 50 60 70
good
put (
pps)
pps
Goodput vs pps (Econotags)
goodput
[Khattak preliminary]
Congestion Control
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-cocoa-00txt
ldquoadvancedrdquo cc (The draft is just a first shot) Others may have better ideas
129
Insert post-WGLC discussion slides here
130
Stop Continue Start
131
An Agile Retrospective
http6lowappnet coreIETF86 2013-03-12-13
Stop
132
Endless new CoAP optionssect instead use RESTful as much as possible
Move general security lifecycle out Looking at theoretical problems
http6lowappnet coreIETF86 2013-03-12-13
Continue
Interops Running code Look at real-world examples and deployments Solve their actual problems
sect Unilateral enhancements eg higher performance congestion control
sect Transports (SMS hellip)sect Make Web linking and Directories more and more usefulsect RESTful Design Paradigms for real-world problems
133
http6lowappnet coreIETF86 2013-03-12-13
Start
Further push into the (browser) web world (HTML5 browser security)
Specific supporting worksect SenMLsect URI work (dev URN hellip)sect Security Processes (next slide)
Spin outsect (We donrsquot really get to decide where this is done)
134
http6lowappnet coreIETF86 2013-03-12-13
Security
Integrate Application Network Group Keyingsect Tunnel-free setup
Donrsquot redo what has been done alreadysect ZigBee IP is finesect But what about other scenarios
Simple REST interfaces for working with keying materials and authorizationsect Start with defining objectives
Object Security for Constrained Nodes135
Re-chartering CoREWhat do we want to do now that wersquore grown up
Zach ShelbyCoRE WG IETF-86 Orlando
What is the scope
bull So we have a protocol and Web Linking what next
bull Keep with what we know besthellip1 Enhancements around CoAP2 New transports for CoAP3 New representations for Web Links4 General application layer solutions
CoRE WG IETF-86 Orlando 2
Enhancements around CoAP
bull Advanced congestion control
CoRE WG IETF-86 Orlando 3
New Transports for CoAP
bull Infrastructure for CoAP over foondash httptoolsietforgiddraft-silverajan-core-
coap-alternative-transports-01txtbull CoAP over SMS
ndash httptoolsietforgiddraft-becker-core-coap-sms-gprs-03txt
ndash OMA Lightweightbull CoAP over TCP
ndash httptoolsietforgiddraft-li-core-coap-payload-length-option-01txt
CoRE WG IETF-86 Orlando 4
New support for Web Links
bull JSON Web Linksndash httptoolsietforgiddraft-bormann-core-links-
json-02txt
2332010 CoRE WG IETF-77 Anaheim 5
General application layer solutions
bull Resource Directoryndash httptoolsietforgiddraft-shelby-core-
resource-directory-05txtndash OMA Lightweight
2332010 CoRE WG IETF-77 Anaheim 6
HTTP to CoAP URI Mapping Options (22)
n Homogeneous Mapping n In a homogeneous mapping approach only the scheme portion of the URI
needs to be mapped The rest of the URI (ie authority path etc) remains unchanged
n Example The CoAP resource coapnodecoapsomethingnetfoo can be accessed by an HTTP client by requesting httpnodecoapsomethingnetfoo The Cross-Protocol Proxy receiving the request is responsible to map the URI to coapnodecoapsomethingnetfoo
n Background info n The assumption in this case is that the HTTP client would be able to
successfully resolve nodecoapsomethingnet using DNS infrastructure to return the IP address of the HC proxy Most likely this would be through a two step DNS lookup where the first DNS lookup would resolve somethingnet using public DNS infrastructure
n Then the second DNS lookup on the subdomain coap and the host node would typically be resolved by a DNS server operated by the owner of domain somethingnet So this domain owner can manage its own internal node names and subdomain allocation which would correspond to the CoAP namespace
Group 3 ldquonew workrdquo
39
Transport of CoAP over SMS USSD and GPRSdraft-becker-core-coap-sms-gprs-03
Markus Becker Kepeng LiKoojana Kuladinithi Thomas Poumltsch
CoRE WG IETF-86 Orlando
1 10
ScenariosI In M2M communication IP connectivity is not alwayssupported by the constrained end-points
I Power savingI Coverage (GPRS 3G LTE)
I SMS and USSD based communication is almost alwayssupported
210
Changes from draft-01 to draft-03 (1)
I Added possible CONNONACK interactions Section 5
I Option name changed from Reply-To- to Response-To-Section 16 and Section 101
I Added URI schemeEg coap+tel+15105550101well-knowncore Section 11
I Added possible M2M proxy scenarios Section 14
3 10
Changes from draft-01 to draft-03 (2)
I Added reference to bormann-coap-misc for other SMSencoding Section 71
I Updated requirements on Uri-Host and Uri-Port forcoap+tel Section 10
I Added security considerations Transport and ObjectSecurity Section 15
I Chose CoAP option numbers and updated the optionnumber table to meet draft-ietf-core-coap-10 Table 1
I Added an IANA registration for the URI scheme coap+telSection 162
4 10
Feedback Split coap+tel into coap+smsand coap+ussd
I How else to differ the various transports in the URII Or is the transport to use decided by the implementationI See alsodraft-silverajan-core-coap-alternative-transports-01
5 10
Feedback Response-To-Scheme option
I Should there be a Response-To-Scheme optionadditionally to Response-To-Uri-Host andResponse-To-Uri-Path
I So that a CoAP end-point which receives a request by CoAPover non-IP transport can be instructed to also use thenon-IP transport for the response
I This would imply to add aResponse-To-Telephone-Subscriber and more options forother transports that have other URI schemes than coapand coaps
6 10
Feedback Selection of Transport by Client
I When a server is reachable by various transports howdoes a client decide which transport to use
I Client-side application congurationI Leave it to a proxy which uses cellular network lookupfunctions
7 10
Feedback Potential Threats
I Trigger expensive short messagesI Redirect trac to other addressesI More threats
I Are the security measures in the draft adequateI Whitelisting on serverI Relying on cellular network security (dedicated M2M APNs)I Object security on CoAP payload
8 10
Feedback Message Exchanges
I Figures 11-18 show possible message exchanges whenclient and server have two addresses
I With NON Not using CoAP retransmission capabilityI ACK on different transportI Additional (costly) message on Transport AI Request with Content
I Which ones are allowedI Which ones are meaningful
9 10
Next steps
I Rene Uri schemeI Response-To-Scheme optionI Selection of Message ExchangeI Rene Proxying
10 10
CoAP13 Communicaon13 with13 Alternave13 Transports
Bill Silverajan and Teemu SavolainenCore WG IETF 86 Orlando
031113
Objecves13 (In13 Scope)
bull Unambiguous13 representaon13 of13 transport13 to13 be13 used13 by13 CoAP
bull Details13 how13 the13 transport13 can13 carry13 CoAP13 packet
bull Focus13 is13 on13 what13 CoAP13 communicaons13 requirements13 are
bull Allow13 CoAP13 mechanisms13 to13 exploit13 cross-shy‐layer13 opmisaons
51
031113
Non13 Goals13 (Not13 in13 scope)
bull Applicaon-shy‐level13 QoS13 requirementsbull Real-shy‐me13 constraintsbull Ordering13 reliability13 congeson13 controlbull Applicaon13 and13 network13 adaptaonbull Mobility13 and13 readdressing13 supportbull Network13 protocol13 (eg13 IPsec)13 configuraon
52
031113
Use13 Cases
bull NAT13 and13 Firewall13 traversal13 with13 TCPbull Delay13 Tolerant13 Networkingbull Non-shy‐IP13 Low13 Energy13 Protocols
53
031113
Related13 Work
bull OMA13 Lightweight13 M2M13 Protocolbull CoAP13 over13 SMSGPRSUSSD
54
031113
What13 does13 the13 work13 entail
bull The13 ability13 to13 specify13 end13 point13 idenfiers13 and13 URIs13 to13 reflect13 which13 transport13 CoAP13 can13 use
bull The13 ability13 to13 register13 to13 resource13 directories13 resource13 types13 reflecng13 types13 of13 transport13 available
bull Ability13 for13 mul-shy‐transport13 nodes13 to13 select13 transport13 to13 use13 without13 significant13 alteraon13 to13 CoAP13 packet13 structure
55
031113
Points13 to13 consider
bull Requirements13 for13 transport13 layer13 protocol13 to13 carry13 CoAP13 packets
bull Representaon13 of13 URI13 scheme13 for13 generic13 transport13 protocols
bull Opon13 extensions13 for13 CoAP13 to13 express13 available13 transports
bull Mapping13 and13 message13 sizebull Security13 consideraons
56
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
URI13 =13 scheme13 13 13 authority13 path-shy‐abempty13 [13 query13 ]
bull Within13 the13 scheme13 namebull In13 the13 URI13 pathbull As13 a13 query13 component
57
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
bull Within13 the13 scheme13 namendash coap+tel+15105550101well-shy‐knowncorendash coap+tcpexamplecom5683temperaturendash coap+blel2cap[1234567890AB]4pulse
bull Easy13 URI13 parsing13 for13 transport13 type13 and13 idenfier
bull Each13 new13 scheme13 name13 requires13 IANA13 registraon
58
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
bull In13 the13 URI13 pathndash coaphostexamplecomtransport=tcpwell-shy‐knowncorert=core-shy‐rd
bull Easy13 adopon13 of13 new13 (and13 experimental)13 CoAP13 transports13 without13 IANA13 registraon
bull Caveat13 Uri-shy‐Path13 opon13 is13 a13 Crical13 CoAP13 opon13 see13 secon13 54113 of13 I-shy‐Diep-shy‐core-shy‐coap
59
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
bull As13 a13 URI13 query13 componentndash coaphostexamplecomwell-shy‐knowncorert=core-shy‐rdq=tcp
bull Also13 easy13 to13 adopt13 new13 (and13 experimental)13 CoAP13 transports13 without13 IANA13 registraon
bull Caveat13 Uri-shy‐Query13 opon13 is13 a13 Crical13 CoAP13 opon13 see13 secon13 54113 of13 I-shy‐Diep-shy‐core-shy‐coap
60
031113
URI13 Representaons13 for13 CoAPNon13 standard13 ways
bull Transport13 in13 the13 URI13 authority13 componentndash coaphost[port][transport]13 instead13 of13 coaphost[port]
bull Transport13 as13 a13 service13 URLndash servicecoaptcphostexamplecomwell-shy‐knowncorert=core-shy‐rd
bull Above13 two13 ways13 break13 exisng13 compability13 (although13 both13 are13 based13 on13 valid13 IANA13 URI13 registraons)
61
031113
URI13 Representaons13 for13 CoAPMiscellaneous13 Consideraons
bull Ensure13 that13 transport13 is13 defined13 unambiguously13 (eg13 L2CAP13 used13 by13 both13 BLE13 and13 standard13 Bluetooth13 so13 avoid13 rdquocoap+l2caprdquo13 or13 rdquotransport=l2caprdquo13 or13 rdquoq=l2caprdquondash Can13 be13 done13 as13 WG13 consensusndash Namespace13 approach13 eg13 rdquocoap+blel2caprdquo13 or13 rdquoq=blel2caprdquo
bull Allow13 end-shy‐points13 to13 use13 CoAP13 Resource13 Directory13 to13 register13 alternave13 transports13 and13 idenfiers13 and13 provide13 periodic13 updatesndash Register13 rdquocore-shy‐transportrdquo13 resource13 type
62
031113
Transport13 Consideraons
bull Uniqueness13 of13 end-shy‐point13 idenficaonbull Communicaon13 support13 Unidireconal13 Bidireconal13 1N13 (broadcast13 mulcast13 anycast)13 messaging
bull Binary13 encoding13 Network13 byte13 orderingbull MTU13 correlaon13 with13 CoAP13 PDU13 sizebull Transport13 latency
63
031113
Security13 Consideraons
bull Drar13 does13 not13 introduce13 new13 security13 requirements13 by13 itself
bull There13 may13 be13 privacy13 issues13 if13 nodes13 use13 telephone13 numbers13 or13 MAC13 addresses13 as13 public13 end13 point13 idenfiers
64
Akbar Rahman
IETF 86 March 2013 httpwwwietforgiddraft-rahman-core-sleepy-02txt
Enhanced Sleepy Node Support for CoAP
Introduction
It is expected that in CoAP networks there will be a certain portion of devices that are sleepy and which may occasionally go into a sleep mode (ie go into a low power state to conserve power) and subsequently have reduced CoAP protocol communication ability
This I-D proposes a minimal and efficient mechanism building on the Resource Directory concept (which will be integrated into a CoAP Proxy) to enhance sleepy node support in CoAP networks
Main Question from IETF-85 (Atlanta)
What performance benefit does the proposed Sleepy Node support solution give in a network that already has standard CoAP caching enabled
Sleepy Node Performance Analysis
Experimental Network
1-5 clients
Both Sleepy and Non-
Sleepy servers
Sleepy Node Performance Analysis Network Setup
CoAPSleepyServer(s)
CoAPSleepAwareReverseProxy
CoAP
Client(s)
Request
Response
Sleep9AwareCoREResourceDirectoryCapability
PublishedSleepParameters
Sleep9AwareCoAPStoreandForwardCapability Response
Request
SleepAwareCoAP503ResponseCapability
CoAPCachingCapability
bull Server supports publishing sleep parameters to proxy bull Eg Irsquom going to be asleep for X seconds
bull Proxy supports sleep-awareness capabilities bull Proxy also supports caching capability based off of maxAge bull Protocol flow similar to approach of Figure 1 (Synchronous RD Based Sleep
Tracking) of I-D
Proxy capabilities can be selectively enableddisabled
Proxy ndash Server Interface
Client ndash Proxy Interface
CoAP Sleep-Aware Reverse Proxy Features CoRE Sleep-aware Resource Directory
Support storing published sleep parameters from CoAP servers sleepState (AWAKE ASLEEP) sleepDuration
Sleep-aware CoAP 503 Response Capability If CoAP request to a sleeping server is received proxy returns a
lsquo503 Retry-Afterrsquo response to client 503 contains a timestamp indicating when the sever will wake back up
(timestamp delivered in CoAP maxAge option) Sleep-aware CoAP Store-and-Forward Capability
If CoAP request to a sleeping server is received proxy stores request until server wakes up and then forwards it
Caching capability Cache GET responses from server if maxAge option is present
(this is not a sleep aware feature)
Goals of Performance Analysis
For networks having sleepy servers provide measurements to quantify the impact that CoAP sleep-awareness capabilities can have
See if sleep-awareness capabilities can
provide additional benefits even when CoAP caching is used
Overview of Performance Analysis Performed The analysis was broken up into a set of test scenarios Each test scenario used a different combination of the following
variables Client issued GET requests Server was configured as a sleepy or non-sleepy server Proxy caching of GET responses was enabled or disabled Proxy sleep-aware 503 response capability was enabled or disabled Proxy store-and-forward capability was enabled or disabled maxAge in GET responses ndash Two values were tested 60sec and 5sec of Clients ndash Two values were used ndash 1 client and 5 clients
For comparison purposes the following were held constant across all test scenarios Client issued a fixed number of requests (100) across all test scenarios Client used a delay between each GET request (35sec) to better exercise
proxyrsquos caching and sleep-awareness capabilities For sleepy server test scenarios the server slept 60 sec awake for 3 sec
Format of Results The following results were collected for each
test scenario
Breakdown of the and types of transactions occurring between clientproxyserver
ldquoGETrdquo ndash Test Scenario Results
GET ndash Description of Test Scenarios
TestScenarios-GET
Scenario
CoAPSleepyServerSe7ngs CoAPSleepAwareReverseProxySe7ngs CoAPClientSe7ngs
SleepDuragton(sec)
AwakeDuragton(sec)
maxAge(sec) Caching SleepAwareSAF+
503NumberofClients
NumberofGETs
DelayBetweenClient
Requests(sec)
1a 0 Always 60 Enabled Disabled 1 100 35
1b 60 3 60 Enabled Disabled 1 100 35
1c 60 3 60 Enabled Enabled 1 100 35
2a 0 Always 60 Enabled Disabled 5 100 35
2b 60 3 60 Enabled Disabled 5 100 35
2c 60 3 60 Enabled Enabled 5 100 35
3a 0 Always 5 Enabled Disabled 5 100 35
3b 60 3 5 Enabled Disabled 5 100 35
3c 60 3 5 Enabled Enabled 5 100 35
ldquoGETrdquo ndash Test Scenario 1 Results
maxAge = 60 and 1 Client
GET ndash Scenario 1 ClientProxy Interface Transaction Mix
Scenarios 1a - Non-Sleepy Server Caching Proxy maxAge = 60sec 1b- Sleepy Server Caching Proxy maxAge = 60sec 1c - Sleepy Server Sleep Aware Proxy maxAge = 60sec
Sleep Aware Proxy has better performance for sleepy servers
0
100
200
300
400
500
600
700
1a 1b 1c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
GET ndash Scenario 1 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
Scenarios 1a - Non-Sleepy Server Caching Proxy maxAge = 60sec 1b- Sleepy Server Caching Proxy maxAge = 60sec 1c - Sleepy Server Sleep Aware Proxy maxAge = 60sec
0
100
200
300
400
500
600
700
800
1a 1b 1c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
ldquoGETrdquo ndash Test Scenario 2 Results
maxAge = 60 and 5 Clients
GET ndash Scenario 2 ClientProxy Interface Transaction Mix
Sleep Aware Proxy has slightly better performance for sleepy servers
0
200
400
600
800
1000
1200
1400
2a 2b 2c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
Scenarios 2a - Non-Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2b- Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2c - Sleepy Server Sleep Aware Proxy maxAge = 60sec 5 Clients
See ldquoExperimental Artifactsrdquo Note 1
GET ndash Scenario 2 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has slightly better performance for sleepy servers
0
50
100
150
200
250
300
350
400
2a 2b 2c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
Scenarios 2a - Non-Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2b- Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2c - Sleepy Server Sleep Aware Proxy maxAge = 60sec 5 Clients
See ldquoExperimental Artifactsrdquo Note 2
Experimental Artifacts Note 1
Currently in the experiment the sleep aware proxy checks the cached state of a resource before putting a request into its Store-and-forward queue while a server is sleeping Once in the queue the proxy unconditionally forwards the queued requests to the server once it wakes up This is not the most efficient setup and can easily be improved If the proxy instead checks its cache again before forwarding each queued request it may not need to forward the request to the server For example if there are two queued GET requests in the proxyrsquos queue that address the same resource Only the first request needs to be sent to the server the second request can use the cached response from the first request
Note 2 Currently in the experiment the sleepy server sends a sleepState PUT request to the
proxy each time it goes to sleep This is not the most efficient setup and can easily be improved For example if the server assumes that the proxy can keep track of its ONOFF cycles with its internal timers (eg as per Fig 1 of I-D) then the number of messages from the sleepy server dramatically goes down
ldquoGETrdquo ndash Test Scenario 3 Results
maxAge = 5 and 5 Clients
GET ndash Scenario 3 ClientProxy Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
Scenarios 3a - Non-Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3b- Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3c - Sleepy Server Sleep Aware Proxy maxAge = 5sec 5 Clients
0
500
1000
1500
2000
2500
3000
3500
4000
4500
5000
3a 3b 3c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
GET ndash Scenario 3 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
0
1000
2000
3000
4000
5000
6000
7000
3a 3b 3c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
Scenarios 3a - Non-Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3b- Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3c - Sleepy Server Sleep Aware Proxy maxAge = 5sec 5 Clients
Conclusions
Conclusions These results show that sleep-aware CoAP
proxy features can significantly optimize communication with sleepy servers in most scenarios
These results also show that sleep-
awareness capabilities can provide additional benefits above and beyond CoAP caching in most scenarios
Backup
Current CoAP Support of Sleepy Node (12)
CoAP proxies can use a previously cached response to service a new GET request for a sleepy origin server (as in HTTP) But if no valid cache then proxy has to attempt to
retrieve and may fail if origin server is sleeping [I-Dietf-core-coap]
Clients can discover list of resources from RD (GET rd-lookuphellip) for sleepy servers But attempt to GET resource from sleepy origin server
may fail if origin server is sleeping [IDietf-core-link-format amp IDshelby-core-resource-
directory]
Current CoAP Support of Sleepy Node (22)
Lower layer support for sleepy nodes in most wireless technologies (eg WiFi ZigBee) But limited to MAC packet scheduling for sleepy nodes
and not aware of specific needs of IP applications (like CoAP)
Proposal ndash RD Based Sleep Tracking (14)
The current CoAP approach to support sleepy nodes can be significantly improved by introducing RD based mechanisms for a CoAP client to determine whether A targeted resource is located on a sleepy server A sleepy server is currently in sleep mode or not
There is any associated caching Proxy (possibly the RD itself) for a sleepy server
Proposal ndash RD Based Sleep Tracking (24)
We define the following new RD attributes to characterize the properties of a sleepy node SleepState - Indicates whether the node is currently in
sleep mode or not (ie Sleeping or Awake) SleepDuration - Indicates the maximum duration of time
that the node stays in sleep mode TimeSleeping - Indicates the length of time the node
has been sleeping (ie if Sleep State = Sleeping) NextSleep - Indicates the next time the node will go to
sleep (ie if Sleep State = Awake)
CachingProxy ndash Indicates the caching proxy of the sleepy node (ie the RD itself or another node)
Proposal ndash RD Based Sleep Tracking (34)
These attributes are all server (node) level and are new parameters added to the RD URI Template Variables
Finally we also define a new lookup-type (ss) for the RD lookup interface specified in [I-Dshelby-core-resource-directory] This new lookup-type supports looking up the
ldquoSleepStaterdquo (ss) of a specified end-point
Proposal ndash RD Based Sleep Tracking (44)
The three time based parameters (SleepDuration TimeSleeping NextSleep) can be based on either an absolute network time (for a time synchronized network) or a relative local time (measured at the local node)
Following the approach of [I-Dietf-core-link-format] and [I-Dshelby-core-resource-directory] sleep parameters for sleepy servers can be stored by the server in the RD and accessed by all interested clients
Examples of using these parameters in a synchronous or asynchronous manner are shown in the I-D
http6lowappnet coreIETF86 2013-03-12-13
We assume people have read the drafts
Meetings serve to advance difficult issues by making good use of face-to-face communications
Note Well Be aware of the IPR principles according to RFC 3979 and its updates
uumlBlue sheetsuumlScribe(s)
96
drar-shy‐iep-shy‐core-shy‐coapsubmiqed13 to13 IESG
2013-shy‐03-shy‐13
97
OMA Lightweight M2M Overview(A new standard using lots of IETF specs including DTLS
CoAP Block Observe Resource Directory SenMLhellip)
Zach ShelbyCoRE WG IETF-86 Orlando
OMA Lightweight M2Mbull Open Mobile Alliance is well known for Device Management (DM)bull OMA Lightweight M2M is a new standard from the alliance
ndash Focused on constrained Cellular and sensor network M2M devicesndash Driven by leading operators and vendors
bull Scopendash Interfaces protocol amp security between Device and Serverndash Object and Resource modelndash Bootstrap Device Access Control Connectivity and Firmware Objects
bull Draft Specifications are availablendash httpmemberopenmobileallianceorgftpPublic_documentsDM
LightweightM2MPermanent_documentsOMA-TS-LightweightM2M-V1_0_0-20130301-Dzip
bull Timelinendash Requirements and Architecture completed 3Q2012ndash Spec ready for Consistency Review 2Q2013ndash Candidate Approval expected 3Q2013
2 CoRE WG IETF-86 Orlando
Architecture
3
Scope of LWM2M
CoRE WG IETF-86 Orlando
Object Model
bull A Client has one or more Object Instancesbull An Object is a collection of Resourcesbull A Resource is an atomic piece of information
ndash Read Written or Executed
bull Resources can have multiple instancesbull Objects and Resources are identified by a
16-bit Integer Instances by an 8-bit Integerbull ObjectsResources are accessed with
simple URIs Object IDObject InstanceResource ID
eg 1213
4 CoRE WG IETF-86 Orlando
CoRE WG IETF-86 Orlando
CoRE Resource Directory
draft-shelby-core-resource-directory-05
Z Shelby C Bormann S Krco
Backgroundbull Not a new concept
ndash think web search engine or any link directorybull Defines the interfaces to a Resource Directorybull Based on Web Linking framework and the CoRE Link Formatbull Generic REST design for use over HTTP and CoAPbull Used by OMA Lightweight M2Mbull Has already been deployed
ndash In traffic monitoring systemsndash In street lighting systemsndash For vehicular asset trackingndash By a major Cellular M2M operator
Changes since -04
bull Restricted Update to parameter updatesbull Added pagination support for the Lookup interfacebull Changed rt= to et= for the registration amp update
interfacebull Added group support
Group Management
bull RD now includes group management featuresbull New Group Function Set
ndash Register a groupbull Group name domain multicast address endpoint members
ndash Remove a groupbull Group lookup using the Lookup Function Set
ndash List registered groupsndash Find the members of a groupndash Find groups with certain endpoints or resources
Registering a Group
EP RD
| |
| - POST rd-groupgp=lights ltgtep=node1 --gt |
| |
| |
| lt---- 201 Created Location rd-group12 ---- |
| |
Req POST coaprdexamplecomrd-groupgp=lights
Payload
ltgtep=node1
ltgtep=node2
Res 201 Created
Location rd-group12
Looking up Group Members
Client RD
| |
| ----- GET rd-lookupepgp=lights1 ----------------------gt |
| |
| |
| lt-- 205 Content ltrdgtd=domain1ltrdgtd=domain2 --------- |
| |
Req GET rd-lookupepgp=lights1
Res 205 Content
ltcoaphostportgtep=node1
ltcoaphostportgtep=node2rdquo
Things for the futurebull Support for JSON representation of Web Links
ndash httptoolsietforgiddraft-bormann-core-links-json-02txtbull Registry for RD registration query parameters
ndash Already OMA Lightweight has defined some new onesbull More examples
Group 3 ldquonew workrdquo(continued)
109
drar-shy‐greevenbosch-shy‐core-shy‐profile-shy‐descripon-shy‐01Bert13 GreevenboschJeroen13 Hoebeke
Isam13 IshaqFloris13 Van13 den13 Abeele
Descripon
bull JSON13 format13 for13 signalling13 the13 servers13 capabilies
bull Signalling13 of13 supported13 opons13 media13 types13 and13 block13 sizendash Other13 items13 can13 be13 added
bull Filtering13 on13 specific13 fields13 through13 URI-shy‐Querybull Link13 hqpdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐profile-shy‐descripon
well-shy‐knownprofile
bull To13 acquire13 profile13 data13 of13 resources13 on13 a13 parcular13 service13 the13 well-shy‐knownprofile13 URI-shy‐path13 is13 introduced
bull For13 example13 to13 get13 all13 informaon13 from13 sensors13 served13 by13 wwwexampleorg13 we13 can13 do13 a13 GET13 to13 coapwwwexampleorgwell-shy‐knownprofile
bull Filtering13 on13 parcular13 resources13 is13 done13 through13 URI-shy‐Queries
Format
bull Currently13 the13 following13 fields13 are13 definedndash ldquopathrdquo13 contains13 the13 URI-shy‐path13 associated13 with13 a13 resource
ndash ldquooprdquo13 a13 numerical13 list13 of13 supported13 opon13 numbers
ndash ldquocfrdquo13 a13 numerical13 list13 of13 supported13 content-shy‐format13 numbers
ndash ldquob1srdquo13 ldquob2srdquo13 supported13 block13 sizes13 for13 Block113 and13 Block213 respecvely
Examplebull On13 the13 right13 is13 an13 example13 of13 a13 camera13 sensor13 at13 coapwwwexampleorgcam13 that13 supports13 the13 Uri-shy‐Host13 (3)13 ETag13 (4)13 Uri-shy‐Port13 (7)13 Uri-shy‐Path13 (11)13 Content-shy‐Format13 (12)13 Token13 (19)13 Block213 (23)13 and13 Proxy-shy‐Uri13 (35)13 opons
bull The13 supported13 content13 formats13 are13 textplain13 (0)13 applicaon13 link-shy‐format13 (40)13 and13 applicaonjson13 (50)
bull The13 supported13 Block213 can13 use13 25613 or13 51213 byte13 blocks
Req13 GET13 coapwwwexampleorgwell-shy‐knownprofile13 Res13 20513 Content13 (applicationjson)13 13 13 13 profile13 13 13 13 13 13 13 13 pathcam13 13 13 13 op[3471112192335]13 13 13 13 13 cf[04050]13 13 13 13 13 b2s[45]13 13 13 13
Filtering13 through13 use13 of13 URI-shy‐Query
bull Filtering13 can13 be13 done13 through13 the13 URI-shy‐Querybull Query13 format13 N=V
ndash N13 is13 a13 profile13 fieldndash V13 is13 the13 desired13 value
bull Examplesndash To13 find13 resources13 that13 support13 content13 format13 ldquoapplicaonjsonrdquo
13 GET13 wwwexampleorgwell-shy‐knownprofilecf=50ndash To13 get13 informaon13 about13 the13 camera
13 GET13 wwwexampleorgwell-shy‐knownprofilepath=cam
Open13 issues
bull Which13 other13 profile13 data13 needs13 signallingndash Content-shy‐type13 for13 different13 methods
bull Fix13 the13 order13 in13 which13 the13 profile13 fields13 must13 appearndash Non-shy‐fixed13 order13 easier13 extensible
bull Inheritance13 of13 a13 profile13 descriponbull Extend13 usage13 to13 signal13 the13 client13 profilebull Integraon13 with13 link13 format
Thank13 youQuesons
drar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval-shy‐00
Bert13 Greevenbosch
Descripon
bull The13 ldquoMinimumRequestInterval13 opon13 can13 be13 used13 to13 indicate13 the13 minimum13 me13 between13 two13 requests13 in13 a13 transacon
bull Originally13 intended13 for13 Block13 but13 also13 usable13 for13 other13 transaconsndash Example13 browsing13 a13 server
bull The13 goal13 is13 to13 reduce13 the13 server13 load13 and13 network13 traffic
bull Link13 hqpsdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval
Usage
bull The13 client13 keeps13 the13 server13 informed13 about13 its13 request13 speed13 through13 inclusion13 of13 the13 ldquoMinimumRequestIntervalrdquo13 opon
bull In13 responses13 the13 server13 fixes13 the13 minimum13 request13 interval13 through13 the13 same13 opon
bull The13 client13 obeys13 the13 speed13 indicated13 by13 the13 server
bull The13 client13 can13 send13 slower13 but13 not13 faster
Advantages
bull The13 server13 has13 means13 to13 limit13 the13 amount13 of13 incoming13 traffic
bull The13 server13 can13 prevent13 to13 become13 overloaded13 with13 too13 many13 tasks
bull The13 server13 does13 not13 need13 arficially13 slow13 down13 the13 client13 by13 sending13 late13 ACKsndash No13 need13 to13 keep13 track13 of13 delayed13 ACKsndash The13 server13 can13 perform13 other13 tasks13 instead
bull Reduced13 network13 traffic
Thank13 youQuesons
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-links-json-02txt
123
RFC 6690 (link-format) documents are somewhat foreign to many web app developerssect would prefer to have them in JSON format
There is no standard way to represent link-format documents in applicationssect but everyone knows how to handle JSON
Define a standard JSON translation for link-format
Itrsquos
not
rock
et
scien
ce
ltsensorsgtct=40title=Sensor Index ltsensorstempgtrt=temperature-cif=sensor ltsensorslightgtrt=light-luxif=sensor lthttpwwwexamplecomsensorst123gt anchor=sensorstemprel=describedby lttgtanchor=sensorstemprel=alternate [hrefsensorsct40titleSensor Index hrefsensorstemprttemperature-cifsensor hrefsensorslightrtlight-luxifsensor hrefhttpwwwexamplecomsensorst123 anchorsensorstempreldescribedby hreftanchorsensorstemprelalternate]
124
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-ipsec-for-coap-00txt
IPsec definitions for CoAP Mostly placeholder at this time Who has implementation experience with this
125
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-cross-reverse-convention-00txt
This draft has two lines of payload(based on a WGLC comment by Cullen Jennings)
coap12344567foobara=3
httpwwwproxycomwellknowncore-translate1234_4567foobara=3
Is that a useful convention to have
126
Insert CI slides here
127
128
0
5
10
15
20
25
30
35
40
10 20 30 40 50 60 70
good
put (
pps)
pps
Goodput vs pps (Econotags)
goodput
[Khattak preliminary]
Congestion Control
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-cocoa-00txt
ldquoadvancedrdquo cc (The draft is just a first shot) Others may have better ideas
129
Insert post-WGLC discussion slides here
130
Stop Continue Start
131
An Agile Retrospective
http6lowappnet coreIETF86 2013-03-12-13
Stop
132
Endless new CoAP optionssect instead use RESTful as much as possible
Move general security lifecycle out Looking at theoretical problems
http6lowappnet coreIETF86 2013-03-12-13
Continue
Interops Running code Look at real-world examples and deployments Solve their actual problems
sect Unilateral enhancements eg higher performance congestion control
sect Transports (SMS hellip)sect Make Web linking and Directories more and more usefulsect RESTful Design Paradigms for real-world problems
133
http6lowappnet coreIETF86 2013-03-12-13
Start
Further push into the (browser) web world (HTML5 browser security)
Specific supporting worksect SenMLsect URI work (dev URN hellip)sect Security Processes (next slide)
Spin outsect (We donrsquot really get to decide where this is done)
134
http6lowappnet coreIETF86 2013-03-12-13
Security
Integrate Application Network Group Keyingsect Tunnel-free setup
Donrsquot redo what has been done alreadysect ZigBee IP is finesect But what about other scenarios
Simple REST interfaces for working with keying materials and authorizationsect Start with defining objectives
Object Security for Constrained Nodes135
Re-chartering CoREWhat do we want to do now that wersquore grown up
Zach ShelbyCoRE WG IETF-86 Orlando
What is the scope
bull So we have a protocol and Web Linking what next
bull Keep with what we know besthellip1 Enhancements around CoAP2 New transports for CoAP3 New representations for Web Links4 General application layer solutions
CoRE WG IETF-86 Orlando 2
Enhancements around CoAP
bull Advanced congestion control
CoRE WG IETF-86 Orlando 3
New Transports for CoAP
bull Infrastructure for CoAP over foondash httptoolsietforgiddraft-silverajan-core-
coap-alternative-transports-01txtbull CoAP over SMS
ndash httptoolsietforgiddraft-becker-core-coap-sms-gprs-03txt
ndash OMA Lightweightbull CoAP over TCP
ndash httptoolsietforgiddraft-li-core-coap-payload-length-option-01txt
CoRE WG IETF-86 Orlando 4
New support for Web Links
bull JSON Web Linksndash httptoolsietforgiddraft-bormann-core-links-
json-02txt
2332010 CoRE WG IETF-77 Anaheim 5
General application layer solutions
bull Resource Directoryndash httptoolsietforgiddraft-shelby-core-
resource-directory-05txtndash OMA Lightweight
2332010 CoRE WG IETF-77 Anaheim 6
Group 3 ldquonew workrdquo
39
Transport of CoAP over SMS USSD and GPRSdraft-becker-core-coap-sms-gprs-03
Markus Becker Kepeng LiKoojana Kuladinithi Thomas Poumltsch
CoRE WG IETF-86 Orlando
1 10
ScenariosI In M2M communication IP connectivity is not alwayssupported by the constrained end-points
I Power savingI Coverage (GPRS 3G LTE)
I SMS and USSD based communication is almost alwayssupported
210
Changes from draft-01 to draft-03 (1)
I Added possible CONNONACK interactions Section 5
I Option name changed from Reply-To- to Response-To-Section 16 and Section 101
I Added URI schemeEg coap+tel+15105550101well-knowncore Section 11
I Added possible M2M proxy scenarios Section 14
3 10
Changes from draft-01 to draft-03 (2)
I Added reference to bormann-coap-misc for other SMSencoding Section 71
I Updated requirements on Uri-Host and Uri-Port forcoap+tel Section 10
I Added security considerations Transport and ObjectSecurity Section 15
I Chose CoAP option numbers and updated the optionnumber table to meet draft-ietf-core-coap-10 Table 1
I Added an IANA registration for the URI scheme coap+telSection 162
4 10
Feedback Split coap+tel into coap+smsand coap+ussd
I How else to differ the various transports in the URII Or is the transport to use decided by the implementationI See alsodraft-silverajan-core-coap-alternative-transports-01
5 10
Feedback Response-To-Scheme option
I Should there be a Response-To-Scheme optionadditionally to Response-To-Uri-Host andResponse-To-Uri-Path
I So that a CoAP end-point which receives a request by CoAPover non-IP transport can be instructed to also use thenon-IP transport for the response
I This would imply to add aResponse-To-Telephone-Subscriber and more options forother transports that have other URI schemes than coapand coaps
6 10
Feedback Selection of Transport by Client
I When a server is reachable by various transports howdoes a client decide which transport to use
I Client-side application congurationI Leave it to a proxy which uses cellular network lookupfunctions
7 10
Feedback Potential Threats
I Trigger expensive short messagesI Redirect trac to other addressesI More threats
I Are the security measures in the draft adequateI Whitelisting on serverI Relying on cellular network security (dedicated M2M APNs)I Object security on CoAP payload
8 10
Feedback Message Exchanges
I Figures 11-18 show possible message exchanges whenclient and server have two addresses
I With NON Not using CoAP retransmission capabilityI ACK on different transportI Additional (costly) message on Transport AI Request with Content
I Which ones are allowedI Which ones are meaningful
9 10
Next steps
I Rene Uri schemeI Response-To-Scheme optionI Selection of Message ExchangeI Rene Proxying
10 10
CoAP13 Communicaon13 with13 Alternave13 Transports
Bill Silverajan and Teemu SavolainenCore WG IETF 86 Orlando
031113
Objecves13 (In13 Scope)
bull Unambiguous13 representaon13 of13 transport13 to13 be13 used13 by13 CoAP
bull Details13 how13 the13 transport13 can13 carry13 CoAP13 packet
bull Focus13 is13 on13 what13 CoAP13 communicaons13 requirements13 are
bull Allow13 CoAP13 mechanisms13 to13 exploit13 cross-shy‐layer13 opmisaons
51
031113
Non13 Goals13 (Not13 in13 scope)
bull Applicaon-shy‐level13 QoS13 requirementsbull Real-shy‐me13 constraintsbull Ordering13 reliability13 congeson13 controlbull Applicaon13 and13 network13 adaptaonbull Mobility13 and13 readdressing13 supportbull Network13 protocol13 (eg13 IPsec)13 configuraon
52
031113
Use13 Cases
bull NAT13 and13 Firewall13 traversal13 with13 TCPbull Delay13 Tolerant13 Networkingbull Non-shy‐IP13 Low13 Energy13 Protocols
53
031113
Related13 Work
bull OMA13 Lightweight13 M2M13 Protocolbull CoAP13 over13 SMSGPRSUSSD
54
031113
What13 does13 the13 work13 entail
bull The13 ability13 to13 specify13 end13 point13 idenfiers13 and13 URIs13 to13 reflect13 which13 transport13 CoAP13 can13 use
bull The13 ability13 to13 register13 to13 resource13 directories13 resource13 types13 reflecng13 types13 of13 transport13 available
bull Ability13 for13 mul-shy‐transport13 nodes13 to13 select13 transport13 to13 use13 without13 significant13 alteraon13 to13 CoAP13 packet13 structure
55
031113
Points13 to13 consider
bull Requirements13 for13 transport13 layer13 protocol13 to13 carry13 CoAP13 packets
bull Representaon13 of13 URI13 scheme13 for13 generic13 transport13 protocols
bull Opon13 extensions13 for13 CoAP13 to13 express13 available13 transports
bull Mapping13 and13 message13 sizebull Security13 consideraons
56
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
URI13 =13 scheme13 13 13 authority13 path-shy‐abempty13 [13 query13 ]
bull Within13 the13 scheme13 namebull In13 the13 URI13 pathbull As13 a13 query13 component
57
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
bull Within13 the13 scheme13 namendash coap+tel+15105550101well-shy‐knowncorendash coap+tcpexamplecom5683temperaturendash coap+blel2cap[1234567890AB]4pulse
bull Easy13 URI13 parsing13 for13 transport13 type13 and13 idenfier
bull Each13 new13 scheme13 name13 requires13 IANA13 registraon
58
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
bull In13 the13 URI13 pathndash coaphostexamplecomtransport=tcpwell-shy‐knowncorert=core-shy‐rd
bull Easy13 adopon13 of13 new13 (and13 experimental)13 CoAP13 transports13 without13 IANA13 registraon
bull Caveat13 Uri-shy‐Path13 opon13 is13 a13 Crical13 CoAP13 opon13 see13 secon13 54113 of13 I-shy‐Diep-shy‐core-shy‐coap
59
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
bull As13 a13 URI13 query13 componentndash coaphostexamplecomwell-shy‐knowncorert=core-shy‐rdq=tcp
bull Also13 easy13 to13 adopt13 new13 (and13 experimental)13 CoAP13 transports13 without13 IANA13 registraon
bull Caveat13 Uri-shy‐Query13 opon13 is13 a13 Crical13 CoAP13 opon13 see13 secon13 54113 of13 I-shy‐Diep-shy‐core-shy‐coap
60
031113
URI13 Representaons13 for13 CoAPNon13 standard13 ways
bull Transport13 in13 the13 URI13 authority13 componentndash coaphost[port][transport]13 instead13 of13 coaphost[port]
bull Transport13 as13 a13 service13 URLndash servicecoaptcphostexamplecomwell-shy‐knowncorert=core-shy‐rd
bull Above13 two13 ways13 break13 exisng13 compability13 (although13 both13 are13 based13 on13 valid13 IANA13 URI13 registraons)
61
031113
URI13 Representaons13 for13 CoAPMiscellaneous13 Consideraons
bull Ensure13 that13 transport13 is13 defined13 unambiguously13 (eg13 L2CAP13 used13 by13 both13 BLE13 and13 standard13 Bluetooth13 so13 avoid13 rdquocoap+l2caprdquo13 or13 rdquotransport=l2caprdquo13 or13 rdquoq=l2caprdquondash Can13 be13 done13 as13 WG13 consensusndash Namespace13 approach13 eg13 rdquocoap+blel2caprdquo13 or13 rdquoq=blel2caprdquo
bull Allow13 end-shy‐points13 to13 use13 CoAP13 Resource13 Directory13 to13 register13 alternave13 transports13 and13 idenfiers13 and13 provide13 periodic13 updatesndash Register13 rdquocore-shy‐transportrdquo13 resource13 type
62
031113
Transport13 Consideraons
bull Uniqueness13 of13 end-shy‐point13 idenficaonbull Communicaon13 support13 Unidireconal13 Bidireconal13 1N13 (broadcast13 mulcast13 anycast)13 messaging
bull Binary13 encoding13 Network13 byte13 orderingbull MTU13 correlaon13 with13 CoAP13 PDU13 sizebull Transport13 latency
63
031113
Security13 Consideraons
bull Drar13 does13 not13 introduce13 new13 security13 requirements13 by13 itself
bull There13 may13 be13 privacy13 issues13 if13 nodes13 use13 telephone13 numbers13 or13 MAC13 addresses13 as13 public13 end13 point13 idenfiers
64
Akbar Rahman
IETF 86 March 2013 httpwwwietforgiddraft-rahman-core-sleepy-02txt
Enhanced Sleepy Node Support for CoAP
Introduction
It is expected that in CoAP networks there will be a certain portion of devices that are sleepy and which may occasionally go into a sleep mode (ie go into a low power state to conserve power) and subsequently have reduced CoAP protocol communication ability
This I-D proposes a minimal and efficient mechanism building on the Resource Directory concept (which will be integrated into a CoAP Proxy) to enhance sleepy node support in CoAP networks
Main Question from IETF-85 (Atlanta)
What performance benefit does the proposed Sleepy Node support solution give in a network that already has standard CoAP caching enabled
Sleepy Node Performance Analysis
Experimental Network
1-5 clients
Both Sleepy and Non-
Sleepy servers
Sleepy Node Performance Analysis Network Setup
CoAPSleepyServer(s)
CoAPSleepAwareReverseProxy
CoAP
Client(s)
Request
Response
Sleep9AwareCoREResourceDirectoryCapability
PublishedSleepParameters
Sleep9AwareCoAPStoreandForwardCapability Response
Request
SleepAwareCoAP503ResponseCapability
CoAPCachingCapability
bull Server supports publishing sleep parameters to proxy bull Eg Irsquom going to be asleep for X seconds
bull Proxy supports sleep-awareness capabilities bull Proxy also supports caching capability based off of maxAge bull Protocol flow similar to approach of Figure 1 (Synchronous RD Based Sleep
Tracking) of I-D
Proxy capabilities can be selectively enableddisabled
Proxy ndash Server Interface
Client ndash Proxy Interface
CoAP Sleep-Aware Reverse Proxy Features CoRE Sleep-aware Resource Directory
Support storing published sleep parameters from CoAP servers sleepState (AWAKE ASLEEP) sleepDuration
Sleep-aware CoAP 503 Response Capability If CoAP request to a sleeping server is received proxy returns a
lsquo503 Retry-Afterrsquo response to client 503 contains a timestamp indicating when the sever will wake back up
(timestamp delivered in CoAP maxAge option) Sleep-aware CoAP Store-and-Forward Capability
If CoAP request to a sleeping server is received proxy stores request until server wakes up and then forwards it
Caching capability Cache GET responses from server if maxAge option is present
(this is not a sleep aware feature)
Goals of Performance Analysis
For networks having sleepy servers provide measurements to quantify the impact that CoAP sleep-awareness capabilities can have
See if sleep-awareness capabilities can
provide additional benefits even when CoAP caching is used
Overview of Performance Analysis Performed The analysis was broken up into a set of test scenarios Each test scenario used a different combination of the following
variables Client issued GET requests Server was configured as a sleepy or non-sleepy server Proxy caching of GET responses was enabled or disabled Proxy sleep-aware 503 response capability was enabled or disabled Proxy store-and-forward capability was enabled or disabled maxAge in GET responses ndash Two values were tested 60sec and 5sec of Clients ndash Two values were used ndash 1 client and 5 clients
For comparison purposes the following were held constant across all test scenarios Client issued a fixed number of requests (100) across all test scenarios Client used a delay between each GET request (35sec) to better exercise
proxyrsquos caching and sleep-awareness capabilities For sleepy server test scenarios the server slept 60 sec awake for 3 sec
Format of Results The following results were collected for each
test scenario
Breakdown of the and types of transactions occurring between clientproxyserver
ldquoGETrdquo ndash Test Scenario Results
GET ndash Description of Test Scenarios
TestScenarios-GET
Scenario
CoAPSleepyServerSe7ngs CoAPSleepAwareReverseProxySe7ngs CoAPClientSe7ngs
SleepDuragton(sec)
AwakeDuragton(sec)
maxAge(sec) Caching SleepAwareSAF+
503NumberofClients
NumberofGETs
DelayBetweenClient
Requests(sec)
1a 0 Always 60 Enabled Disabled 1 100 35
1b 60 3 60 Enabled Disabled 1 100 35
1c 60 3 60 Enabled Enabled 1 100 35
2a 0 Always 60 Enabled Disabled 5 100 35
2b 60 3 60 Enabled Disabled 5 100 35
2c 60 3 60 Enabled Enabled 5 100 35
3a 0 Always 5 Enabled Disabled 5 100 35
3b 60 3 5 Enabled Disabled 5 100 35
3c 60 3 5 Enabled Enabled 5 100 35
ldquoGETrdquo ndash Test Scenario 1 Results
maxAge = 60 and 1 Client
GET ndash Scenario 1 ClientProxy Interface Transaction Mix
Scenarios 1a - Non-Sleepy Server Caching Proxy maxAge = 60sec 1b- Sleepy Server Caching Proxy maxAge = 60sec 1c - Sleepy Server Sleep Aware Proxy maxAge = 60sec
Sleep Aware Proxy has better performance for sleepy servers
0
100
200
300
400
500
600
700
1a 1b 1c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
GET ndash Scenario 1 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
Scenarios 1a - Non-Sleepy Server Caching Proxy maxAge = 60sec 1b- Sleepy Server Caching Proxy maxAge = 60sec 1c - Sleepy Server Sleep Aware Proxy maxAge = 60sec
0
100
200
300
400
500
600
700
800
1a 1b 1c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
ldquoGETrdquo ndash Test Scenario 2 Results
maxAge = 60 and 5 Clients
GET ndash Scenario 2 ClientProxy Interface Transaction Mix
Sleep Aware Proxy has slightly better performance for sleepy servers
0
200
400
600
800
1000
1200
1400
2a 2b 2c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
Scenarios 2a - Non-Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2b- Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2c - Sleepy Server Sleep Aware Proxy maxAge = 60sec 5 Clients
See ldquoExperimental Artifactsrdquo Note 1
GET ndash Scenario 2 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has slightly better performance for sleepy servers
0
50
100
150
200
250
300
350
400
2a 2b 2c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
Scenarios 2a - Non-Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2b- Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2c - Sleepy Server Sleep Aware Proxy maxAge = 60sec 5 Clients
See ldquoExperimental Artifactsrdquo Note 2
Experimental Artifacts Note 1
Currently in the experiment the sleep aware proxy checks the cached state of a resource before putting a request into its Store-and-forward queue while a server is sleeping Once in the queue the proxy unconditionally forwards the queued requests to the server once it wakes up This is not the most efficient setup and can easily be improved If the proxy instead checks its cache again before forwarding each queued request it may not need to forward the request to the server For example if there are two queued GET requests in the proxyrsquos queue that address the same resource Only the first request needs to be sent to the server the second request can use the cached response from the first request
Note 2 Currently in the experiment the sleepy server sends a sleepState PUT request to the
proxy each time it goes to sleep This is not the most efficient setup and can easily be improved For example if the server assumes that the proxy can keep track of its ONOFF cycles with its internal timers (eg as per Fig 1 of I-D) then the number of messages from the sleepy server dramatically goes down
ldquoGETrdquo ndash Test Scenario 3 Results
maxAge = 5 and 5 Clients
GET ndash Scenario 3 ClientProxy Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
Scenarios 3a - Non-Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3b- Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3c - Sleepy Server Sleep Aware Proxy maxAge = 5sec 5 Clients
0
500
1000
1500
2000
2500
3000
3500
4000
4500
5000
3a 3b 3c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
GET ndash Scenario 3 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
0
1000
2000
3000
4000
5000
6000
7000
3a 3b 3c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
Scenarios 3a - Non-Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3b- Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3c - Sleepy Server Sleep Aware Proxy maxAge = 5sec 5 Clients
Conclusions
Conclusions These results show that sleep-aware CoAP
proxy features can significantly optimize communication with sleepy servers in most scenarios
These results also show that sleep-
awareness capabilities can provide additional benefits above and beyond CoAP caching in most scenarios
Backup
Current CoAP Support of Sleepy Node (12)
CoAP proxies can use a previously cached response to service a new GET request for a sleepy origin server (as in HTTP) But if no valid cache then proxy has to attempt to
retrieve and may fail if origin server is sleeping [I-Dietf-core-coap]
Clients can discover list of resources from RD (GET rd-lookuphellip) for sleepy servers But attempt to GET resource from sleepy origin server
may fail if origin server is sleeping [IDietf-core-link-format amp IDshelby-core-resource-
directory]
Current CoAP Support of Sleepy Node (22)
Lower layer support for sleepy nodes in most wireless technologies (eg WiFi ZigBee) But limited to MAC packet scheduling for sleepy nodes
and not aware of specific needs of IP applications (like CoAP)
Proposal ndash RD Based Sleep Tracking (14)
The current CoAP approach to support sleepy nodes can be significantly improved by introducing RD based mechanisms for a CoAP client to determine whether A targeted resource is located on a sleepy server A sleepy server is currently in sleep mode or not
There is any associated caching Proxy (possibly the RD itself) for a sleepy server
Proposal ndash RD Based Sleep Tracking (24)
We define the following new RD attributes to characterize the properties of a sleepy node SleepState - Indicates whether the node is currently in
sleep mode or not (ie Sleeping or Awake) SleepDuration - Indicates the maximum duration of time
that the node stays in sleep mode TimeSleeping - Indicates the length of time the node
has been sleeping (ie if Sleep State = Sleeping) NextSleep - Indicates the next time the node will go to
sleep (ie if Sleep State = Awake)
CachingProxy ndash Indicates the caching proxy of the sleepy node (ie the RD itself or another node)
Proposal ndash RD Based Sleep Tracking (34)
These attributes are all server (node) level and are new parameters added to the RD URI Template Variables
Finally we also define a new lookup-type (ss) for the RD lookup interface specified in [I-Dshelby-core-resource-directory] This new lookup-type supports looking up the
ldquoSleepStaterdquo (ss) of a specified end-point
Proposal ndash RD Based Sleep Tracking (44)
The three time based parameters (SleepDuration TimeSleeping NextSleep) can be based on either an absolute network time (for a time synchronized network) or a relative local time (measured at the local node)
Following the approach of [I-Dietf-core-link-format] and [I-Dshelby-core-resource-directory] sleep parameters for sleepy servers can be stored by the server in the RD and accessed by all interested clients
Examples of using these parameters in a synchronous or asynchronous manner are shown in the I-D
http6lowappnet coreIETF86 2013-03-12-13
We assume people have read the drafts
Meetings serve to advance difficult issues by making good use of face-to-face communications
Note Well Be aware of the IPR principles according to RFC 3979 and its updates
uumlBlue sheetsuumlScribe(s)
96
drar-shy‐iep-shy‐core-shy‐coapsubmiqed13 to13 IESG
2013-shy‐03-shy‐13
97
OMA Lightweight M2M Overview(A new standard using lots of IETF specs including DTLS
CoAP Block Observe Resource Directory SenMLhellip)
Zach ShelbyCoRE WG IETF-86 Orlando
OMA Lightweight M2Mbull Open Mobile Alliance is well known for Device Management (DM)bull OMA Lightweight M2M is a new standard from the alliance
ndash Focused on constrained Cellular and sensor network M2M devicesndash Driven by leading operators and vendors
bull Scopendash Interfaces protocol amp security between Device and Serverndash Object and Resource modelndash Bootstrap Device Access Control Connectivity and Firmware Objects
bull Draft Specifications are availablendash httpmemberopenmobileallianceorgftpPublic_documentsDM
LightweightM2MPermanent_documentsOMA-TS-LightweightM2M-V1_0_0-20130301-Dzip
bull Timelinendash Requirements and Architecture completed 3Q2012ndash Spec ready for Consistency Review 2Q2013ndash Candidate Approval expected 3Q2013
2 CoRE WG IETF-86 Orlando
Architecture
3
Scope of LWM2M
CoRE WG IETF-86 Orlando
Object Model
bull A Client has one or more Object Instancesbull An Object is a collection of Resourcesbull A Resource is an atomic piece of information
ndash Read Written or Executed
bull Resources can have multiple instancesbull Objects and Resources are identified by a
16-bit Integer Instances by an 8-bit Integerbull ObjectsResources are accessed with
simple URIs Object IDObject InstanceResource ID
eg 1213
4 CoRE WG IETF-86 Orlando
CoRE WG IETF-86 Orlando
CoRE Resource Directory
draft-shelby-core-resource-directory-05
Z Shelby C Bormann S Krco
Backgroundbull Not a new concept
ndash think web search engine or any link directorybull Defines the interfaces to a Resource Directorybull Based on Web Linking framework and the CoRE Link Formatbull Generic REST design for use over HTTP and CoAPbull Used by OMA Lightweight M2Mbull Has already been deployed
ndash In traffic monitoring systemsndash In street lighting systemsndash For vehicular asset trackingndash By a major Cellular M2M operator
Changes since -04
bull Restricted Update to parameter updatesbull Added pagination support for the Lookup interfacebull Changed rt= to et= for the registration amp update
interfacebull Added group support
Group Management
bull RD now includes group management featuresbull New Group Function Set
ndash Register a groupbull Group name domain multicast address endpoint members
ndash Remove a groupbull Group lookup using the Lookup Function Set
ndash List registered groupsndash Find the members of a groupndash Find groups with certain endpoints or resources
Registering a Group
EP RD
| |
| - POST rd-groupgp=lights ltgtep=node1 --gt |
| |
| |
| lt---- 201 Created Location rd-group12 ---- |
| |
Req POST coaprdexamplecomrd-groupgp=lights
Payload
ltgtep=node1
ltgtep=node2
Res 201 Created
Location rd-group12
Looking up Group Members
Client RD
| |
| ----- GET rd-lookupepgp=lights1 ----------------------gt |
| |
| |
| lt-- 205 Content ltrdgtd=domain1ltrdgtd=domain2 --------- |
| |
Req GET rd-lookupepgp=lights1
Res 205 Content
ltcoaphostportgtep=node1
ltcoaphostportgtep=node2rdquo
Things for the futurebull Support for JSON representation of Web Links
ndash httptoolsietforgiddraft-bormann-core-links-json-02txtbull Registry for RD registration query parameters
ndash Already OMA Lightweight has defined some new onesbull More examples
Group 3 ldquonew workrdquo(continued)
109
drar-shy‐greevenbosch-shy‐core-shy‐profile-shy‐descripon-shy‐01Bert13 GreevenboschJeroen13 Hoebeke
Isam13 IshaqFloris13 Van13 den13 Abeele
Descripon
bull JSON13 format13 for13 signalling13 the13 servers13 capabilies
bull Signalling13 of13 supported13 opons13 media13 types13 and13 block13 sizendash Other13 items13 can13 be13 added
bull Filtering13 on13 specific13 fields13 through13 URI-shy‐Querybull Link13 hqpdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐profile-shy‐descripon
well-shy‐knownprofile
bull To13 acquire13 profile13 data13 of13 resources13 on13 a13 parcular13 service13 the13 well-shy‐knownprofile13 URI-shy‐path13 is13 introduced
bull For13 example13 to13 get13 all13 informaon13 from13 sensors13 served13 by13 wwwexampleorg13 we13 can13 do13 a13 GET13 to13 coapwwwexampleorgwell-shy‐knownprofile
bull Filtering13 on13 parcular13 resources13 is13 done13 through13 URI-shy‐Queries
Format
bull Currently13 the13 following13 fields13 are13 definedndash ldquopathrdquo13 contains13 the13 URI-shy‐path13 associated13 with13 a13 resource
ndash ldquooprdquo13 a13 numerical13 list13 of13 supported13 opon13 numbers
ndash ldquocfrdquo13 a13 numerical13 list13 of13 supported13 content-shy‐format13 numbers
ndash ldquob1srdquo13 ldquob2srdquo13 supported13 block13 sizes13 for13 Block113 and13 Block213 respecvely
Examplebull On13 the13 right13 is13 an13 example13 of13 a13 camera13 sensor13 at13 coapwwwexampleorgcam13 that13 supports13 the13 Uri-shy‐Host13 (3)13 ETag13 (4)13 Uri-shy‐Port13 (7)13 Uri-shy‐Path13 (11)13 Content-shy‐Format13 (12)13 Token13 (19)13 Block213 (23)13 and13 Proxy-shy‐Uri13 (35)13 opons
bull The13 supported13 content13 formats13 are13 textplain13 (0)13 applicaon13 link-shy‐format13 (40)13 and13 applicaonjson13 (50)
bull The13 supported13 Block213 can13 use13 25613 or13 51213 byte13 blocks
Req13 GET13 coapwwwexampleorgwell-shy‐knownprofile13 Res13 20513 Content13 (applicationjson)13 13 13 13 profile13 13 13 13 13 13 13 13 pathcam13 13 13 13 op[3471112192335]13 13 13 13 13 cf[04050]13 13 13 13 13 b2s[45]13 13 13 13
Filtering13 through13 use13 of13 URI-shy‐Query
bull Filtering13 can13 be13 done13 through13 the13 URI-shy‐Querybull Query13 format13 N=V
ndash N13 is13 a13 profile13 fieldndash V13 is13 the13 desired13 value
bull Examplesndash To13 find13 resources13 that13 support13 content13 format13 ldquoapplicaonjsonrdquo
13 GET13 wwwexampleorgwell-shy‐knownprofilecf=50ndash To13 get13 informaon13 about13 the13 camera
13 GET13 wwwexampleorgwell-shy‐knownprofilepath=cam
Open13 issues
bull Which13 other13 profile13 data13 needs13 signallingndash Content-shy‐type13 for13 different13 methods
bull Fix13 the13 order13 in13 which13 the13 profile13 fields13 must13 appearndash Non-shy‐fixed13 order13 easier13 extensible
bull Inheritance13 of13 a13 profile13 descriponbull Extend13 usage13 to13 signal13 the13 client13 profilebull Integraon13 with13 link13 format
Thank13 youQuesons
drar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval-shy‐00
Bert13 Greevenbosch
Descripon
bull The13 ldquoMinimumRequestInterval13 opon13 can13 be13 used13 to13 indicate13 the13 minimum13 me13 between13 two13 requests13 in13 a13 transacon
bull Originally13 intended13 for13 Block13 but13 also13 usable13 for13 other13 transaconsndash Example13 browsing13 a13 server
bull The13 goal13 is13 to13 reduce13 the13 server13 load13 and13 network13 traffic
bull Link13 hqpsdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval
Usage
bull The13 client13 keeps13 the13 server13 informed13 about13 its13 request13 speed13 through13 inclusion13 of13 the13 ldquoMinimumRequestIntervalrdquo13 opon
bull In13 responses13 the13 server13 fixes13 the13 minimum13 request13 interval13 through13 the13 same13 opon
bull The13 client13 obeys13 the13 speed13 indicated13 by13 the13 server
bull The13 client13 can13 send13 slower13 but13 not13 faster
Advantages
bull The13 server13 has13 means13 to13 limit13 the13 amount13 of13 incoming13 traffic
bull The13 server13 can13 prevent13 to13 become13 overloaded13 with13 too13 many13 tasks
bull The13 server13 does13 not13 need13 arficially13 slow13 down13 the13 client13 by13 sending13 late13 ACKsndash No13 need13 to13 keep13 track13 of13 delayed13 ACKsndash The13 server13 can13 perform13 other13 tasks13 instead
bull Reduced13 network13 traffic
Thank13 youQuesons
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-links-json-02txt
123
RFC 6690 (link-format) documents are somewhat foreign to many web app developerssect would prefer to have them in JSON format
There is no standard way to represent link-format documents in applicationssect but everyone knows how to handle JSON
Define a standard JSON translation for link-format
Itrsquos
not
rock
et
scien
ce
ltsensorsgtct=40title=Sensor Index ltsensorstempgtrt=temperature-cif=sensor ltsensorslightgtrt=light-luxif=sensor lthttpwwwexamplecomsensorst123gt anchor=sensorstemprel=describedby lttgtanchor=sensorstemprel=alternate [hrefsensorsct40titleSensor Index hrefsensorstemprttemperature-cifsensor hrefsensorslightrtlight-luxifsensor hrefhttpwwwexamplecomsensorst123 anchorsensorstempreldescribedby hreftanchorsensorstemprelalternate]
124
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-ipsec-for-coap-00txt
IPsec definitions for CoAP Mostly placeholder at this time Who has implementation experience with this
125
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-cross-reverse-convention-00txt
This draft has two lines of payload(based on a WGLC comment by Cullen Jennings)
coap12344567foobara=3
httpwwwproxycomwellknowncore-translate1234_4567foobara=3
Is that a useful convention to have
126
Insert CI slides here
127
128
0
5
10
15
20
25
30
35
40
10 20 30 40 50 60 70
good
put (
pps)
pps
Goodput vs pps (Econotags)
goodput
[Khattak preliminary]
Congestion Control
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-cocoa-00txt
ldquoadvancedrdquo cc (The draft is just a first shot) Others may have better ideas
129
Insert post-WGLC discussion slides here
130
Stop Continue Start
131
An Agile Retrospective
http6lowappnet coreIETF86 2013-03-12-13
Stop
132
Endless new CoAP optionssect instead use RESTful as much as possible
Move general security lifecycle out Looking at theoretical problems
http6lowappnet coreIETF86 2013-03-12-13
Continue
Interops Running code Look at real-world examples and deployments Solve their actual problems
sect Unilateral enhancements eg higher performance congestion control
sect Transports (SMS hellip)sect Make Web linking and Directories more and more usefulsect RESTful Design Paradigms for real-world problems
133
http6lowappnet coreIETF86 2013-03-12-13
Start
Further push into the (browser) web world (HTML5 browser security)
Specific supporting worksect SenMLsect URI work (dev URN hellip)sect Security Processes (next slide)
Spin outsect (We donrsquot really get to decide where this is done)
134
http6lowappnet coreIETF86 2013-03-12-13
Security
Integrate Application Network Group Keyingsect Tunnel-free setup
Donrsquot redo what has been done alreadysect ZigBee IP is finesect But what about other scenarios
Simple REST interfaces for working with keying materials and authorizationsect Start with defining objectives
Object Security for Constrained Nodes135
Re-chartering CoREWhat do we want to do now that wersquore grown up
Zach ShelbyCoRE WG IETF-86 Orlando
What is the scope
bull So we have a protocol and Web Linking what next
bull Keep with what we know besthellip1 Enhancements around CoAP2 New transports for CoAP3 New representations for Web Links4 General application layer solutions
CoRE WG IETF-86 Orlando 2
Enhancements around CoAP
bull Advanced congestion control
CoRE WG IETF-86 Orlando 3
New Transports for CoAP
bull Infrastructure for CoAP over foondash httptoolsietforgiddraft-silverajan-core-
coap-alternative-transports-01txtbull CoAP over SMS
ndash httptoolsietforgiddraft-becker-core-coap-sms-gprs-03txt
ndash OMA Lightweightbull CoAP over TCP
ndash httptoolsietforgiddraft-li-core-coap-payload-length-option-01txt
CoRE WG IETF-86 Orlando 4
New support for Web Links
bull JSON Web Linksndash httptoolsietforgiddraft-bormann-core-links-
json-02txt
2332010 CoRE WG IETF-77 Anaheim 5
General application layer solutions
bull Resource Directoryndash httptoolsietforgiddraft-shelby-core-
resource-directory-05txtndash OMA Lightweight
2332010 CoRE WG IETF-77 Anaheim 6
Transport of CoAP over SMS USSD and GPRSdraft-becker-core-coap-sms-gprs-03
Markus Becker Kepeng LiKoojana Kuladinithi Thomas Poumltsch
CoRE WG IETF-86 Orlando
1 10
ScenariosI In M2M communication IP connectivity is not alwayssupported by the constrained end-points
I Power savingI Coverage (GPRS 3G LTE)
I SMS and USSD based communication is almost alwayssupported
210
Changes from draft-01 to draft-03 (1)
I Added possible CONNONACK interactions Section 5
I Option name changed from Reply-To- to Response-To-Section 16 and Section 101
I Added URI schemeEg coap+tel+15105550101well-knowncore Section 11
I Added possible M2M proxy scenarios Section 14
3 10
Changes from draft-01 to draft-03 (2)
I Added reference to bormann-coap-misc for other SMSencoding Section 71
I Updated requirements on Uri-Host and Uri-Port forcoap+tel Section 10
I Added security considerations Transport and ObjectSecurity Section 15
I Chose CoAP option numbers and updated the optionnumber table to meet draft-ietf-core-coap-10 Table 1
I Added an IANA registration for the URI scheme coap+telSection 162
4 10
Feedback Split coap+tel into coap+smsand coap+ussd
I How else to differ the various transports in the URII Or is the transport to use decided by the implementationI See alsodraft-silverajan-core-coap-alternative-transports-01
5 10
Feedback Response-To-Scheme option
I Should there be a Response-To-Scheme optionadditionally to Response-To-Uri-Host andResponse-To-Uri-Path
I So that a CoAP end-point which receives a request by CoAPover non-IP transport can be instructed to also use thenon-IP transport for the response
I This would imply to add aResponse-To-Telephone-Subscriber and more options forother transports that have other URI schemes than coapand coaps
6 10
Feedback Selection of Transport by Client
I When a server is reachable by various transports howdoes a client decide which transport to use
I Client-side application congurationI Leave it to a proxy which uses cellular network lookupfunctions
7 10
Feedback Potential Threats
I Trigger expensive short messagesI Redirect trac to other addressesI More threats
I Are the security measures in the draft adequateI Whitelisting on serverI Relying on cellular network security (dedicated M2M APNs)I Object security on CoAP payload
8 10
Feedback Message Exchanges
I Figures 11-18 show possible message exchanges whenclient and server have two addresses
I With NON Not using CoAP retransmission capabilityI ACK on different transportI Additional (costly) message on Transport AI Request with Content
I Which ones are allowedI Which ones are meaningful
9 10
Next steps
I Rene Uri schemeI Response-To-Scheme optionI Selection of Message ExchangeI Rene Proxying
10 10
CoAP13 Communicaon13 with13 Alternave13 Transports
Bill Silverajan and Teemu SavolainenCore WG IETF 86 Orlando
031113
Objecves13 (In13 Scope)
bull Unambiguous13 representaon13 of13 transport13 to13 be13 used13 by13 CoAP
bull Details13 how13 the13 transport13 can13 carry13 CoAP13 packet
bull Focus13 is13 on13 what13 CoAP13 communicaons13 requirements13 are
bull Allow13 CoAP13 mechanisms13 to13 exploit13 cross-shy‐layer13 opmisaons
51
031113
Non13 Goals13 (Not13 in13 scope)
bull Applicaon-shy‐level13 QoS13 requirementsbull Real-shy‐me13 constraintsbull Ordering13 reliability13 congeson13 controlbull Applicaon13 and13 network13 adaptaonbull Mobility13 and13 readdressing13 supportbull Network13 protocol13 (eg13 IPsec)13 configuraon
52
031113
Use13 Cases
bull NAT13 and13 Firewall13 traversal13 with13 TCPbull Delay13 Tolerant13 Networkingbull Non-shy‐IP13 Low13 Energy13 Protocols
53
031113
Related13 Work
bull OMA13 Lightweight13 M2M13 Protocolbull CoAP13 over13 SMSGPRSUSSD
54
031113
What13 does13 the13 work13 entail
bull The13 ability13 to13 specify13 end13 point13 idenfiers13 and13 URIs13 to13 reflect13 which13 transport13 CoAP13 can13 use
bull The13 ability13 to13 register13 to13 resource13 directories13 resource13 types13 reflecng13 types13 of13 transport13 available
bull Ability13 for13 mul-shy‐transport13 nodes13 to13 select13 transport13 to13 use13 without13 significant13 alteraon13 to13 CoAP13 packet13 structure
55
031113
Points13 to13 consider
bull Requirements13 for13 transport13 layer13 protocol13 to13 carry13 CoAP13 packets
bull Representaon13 of13 URI13 scheme13 for13 generic13 transport13 protocols
bull Opon13 extensions13 for13 CoAP13 to13 express13 available13 transports
bull Mapping13 and13 message13 sizebull Security13 consideraons
56
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
URI13 =13 scheme13 13 13 authority13 path-shy‐abempty13 [13 query13 ]
bull Within13 the13 scheme13 namebull In13 the13 URI13 pathbull As13 a13 query13 component
57
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
bull Within13 the13 scheme13 namendash coap+tel+15105550101well-shy‐knowncorendash coap+tcpexamplecom5683temperaturendash coap+blel2cap[1234567890AB]4pulse
bull Easy13 URI13 parsing13 for13 transport13 type13 and13 idenfier
bull Each13 new13 scheme13 name13 requires13 IANA13 registraon
58
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
bull In13 the13 URI13 pathndash coaphostexamplecomtransport=tcpwell-shy‐knowncorert=core-shy‐rd
bull Easy13 adopon13 of13 new13 (and13 experimental)13 CoAP13 transports13 without13 IANA13 registraon
bull Caveat13 Uri-shy‐Path13 opon13 is13 a13 Crical13 CoAP13 opon13 see13 secon13 54113 of13 I-shy‐Diep-shy‐core-shy‐coap
59
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
bull As13 a13 URI13 query13 componentndash coaphostexamplecomwell-shy‐knowncorert=core-shy‐rdq=tcp
bull Also13 easy13 to13 adopt13 new13 (and13 experimental)13 CoAP13 transports13 without13 IANA13 registraon
bull Caveat13 Uri-shy‐Query13 opon13 is13 a13 Crical13 CoAP13 opon13 see13 secon13 54113 of13 I-shy‐Diep-shy‐core-shy‐coap
60
031113
URI13 Representaons13 for13 CoAPNon13 standard13 ways
bull Transport13 in13 the13 URI13 authority13 componentndash coaphost[port][transport]13 instead13 of13 coaphost[port]
bull Transport13 as13 a13 service13 URLndash servicecoaptcphostexamplecomwell-shy‐knowncorert=core-shy‐rd
bull Above13 two13 ways13 break13 exisng13 compability13 (although13 both13 are13 based13 on13 valid13 IANA13 URI13 registraons)
61
031113
URI13 Representaons13 for13 CoAPMiscellaneous13 Consideraons
bull Ensure13 that13 transport13 is13 defined13 unambiguously13 (eg13 L2CAP13 used13 by13 both13 BLE13 and13 standard13 Bluetooth13 so13 avoid13 rdquocoap+l2caprdquo13 or13 rdquotransport=l2caprdquo13 or13 rdquoq=l2caprdquondash Can13 be13 done13 as13 WG13 consensusndash Namespace13 approach13 eg13 rdquocoap+blel2caprdquo13 or13 rdquoq=blel2caprdquo
bull Allow13 end-shy‐points13 to13 use13 CoAP13 Resource13 Directory13 to13 register13 alternave13 transports13 and13 idenfiers13 and13 provide13 periodic13 updatesndash Register13 rdquocore-shy‐transportrdquo13 resource13 type
62
031113
Transport13 Consideraons
bull Uniqueness13 of13 end-shy‐point13 idenficaonbull Communicaon13 support13 Unidireconal13 Bidireconal13 1N13 (broadcast13 mulcast13 anycast)13 messaging
bull Binary13 encoding13 Network13 byte13 orderingbull MTU13 correlaon13 with13 CoAP13 PDU13 sizebull Transport13 latency
63
031113
Security13 Consideraons
bull Drar13 does13 not13 introduce13 new13 security13 requirements13 by13 itself
bull There13 may13 be13 privacy13 issues13 if13 nodes13 use13 telephone13 numbers13 or13 MAC13 addresses13 as13 public13 end13 point13 idenfiers
64
Akbar Rahman
IETF 86 March 2013 httpwwwietforgiddraft-rahman-core-sleepy-02txt
Enhanced Sleepy Node Support for CoAP
Introduction
It is expected that in CoAP networks there will be a certain portion of devices that are sleepy and which may occasionally go into a sleep mode (ie go into a low power state to conserve power) and subsequently have reduced CoAP protocol communication ability
This I-D proposes a minimal and efficient mechanism building on the Resource Directory concept (which will be integrated into a CoAP Proxy) to enhance sleepy node support in CoAP networks
Main Question from IETF-85 (Atlanta)
What performance benefit does the proposed Sleepy Node support solution give in a network that already has standard CoAP caching enabled
Sleepy Node Performance Analysis
Experimental Network
1-5 clients
Both Sleepy and Non-
Sleepy servers
Sleepy Node Performance Analysis Network Setup
CoAPSleepyServer(s)
CoAPSleepAwareReverseProxy
CoAP
Client(s)
Request
Response
Sleep9AwareCoREResourceDirectoryCapability
PublishedSleepParameters
Sleep9AwareCoAPStoreandForwardCapability Response
Request
SleepAwareCoAP503ResponseCapability
CoAPCachingCapability
bull Server supports publishing sleep parameters to proxy bull Eg Irsquom going to be asleep for X seconds
bull Proxy supports sleep-awareness capabilities bull Proxy also supports caching capability based off of maxAge bull Protocol flow similar to approach of Figure 1 (Synchronous RD Based Sleep
Tracking) of I-D
Proxy capabilities can be selectively enableddisabled
Proxy ndash Server Interface
Client ndash Proxy Interface
CoAP Sleep-Aware Reverse Proxy Features CoRE Sleep-aware Resource Directory
Support storing published sleep parameters from CoAP servers sleepState (AWAKE ASLEEP) sleepDuration
Sleep-aware CoAP 503 Response Capability If CoAP request to a sleeping server is received proxy returns a
lsquo503 Retry-Afterrsquo response to client 503 contains a timestamp indicating when the sever will wake back up
(timestamp delivered in CoAP maxAge option) Sleep-aware CoAP Store-and-Forward Capability
If CoAP request to a sleeping server is received proxy stores request until server wakes up and then forwards it
Caching capability Cache GET responses from server if maxAge option is present
(this is not a sleep aware feature)
Goals of Performance Analysis
For networks having sleepy servers provide measurements to quantify the impact that CoAP sleep-awareness capabilities can have
See if sleep-awareness capabilities can
provide additional benefits even when CoAP caching is used
Overview of Performance Analysis Performed The analysis was broken up into a set of test scenarios Each test scenario used a different combination of the following
variables Client issued GET requests Server was configured as a sleepy or non-sleepy server Proxy caching of GET responses was enabled or disabled Proxy sleep-aware 503 response capability was enabled or disabled Proxy store-and-forward capability was enabled or disabled maxAge in GET responses ndash Two values were tested 60sec and 5sec of Clients ndash Two values were used ndash 1 client and 5 clients
For comparison purposes the following were held constant across all test scenarios Client issued a fixed number of requests (100) across all test scenarios Client used a delay between each GET request (35sec) to better exercise
proxyrsquos caching and sleep-awareness capabilities For sleepy server test scenarios the server slept 60 sec awake for 3 sec
Format of Results The following results were collected for each
test scenario
Breakdown of the and types of transactions occurring between clientproxyserver
ldquoGETrdquo ndash Test Scenario Results
GET ndash Description of Test Scenarios
TestScenarios-GET
Scenario
CoAPSleepyServerSe7ngs CoAPSleepAwareReverseProxySe7ngs CoAPClientSe7ngs
SleepDuragton(sec)
AwakeDuragton(sec)
maxAge(sec) Caching SleepAwareSAF+
503NumberofClients
NumberofGETs
DelayBetweenClient
Requests(sec)
1a 0 Always 60 Enabled Disabled 1 100 35
1b 60 3 60 Enabled Disabled 1 100 35
1c 60 3 60 Enabled Enabled 1 100 35
2a 0 Always 60 Enabled Disabled 5 100 35
2b 60 3 60 Enabled Disabled 5 100 35
2c 60 3 60 Enabled Enabled 5 100 35
3a 0 Always 5 Enabled Disabled 5 100 35
3b 60 3 5 Enabled Disabled 5 100 35
3c 60 3 5 Enabled Enabled 5 100 35
ldquoGETrdquo ndash Test Scenario 1 Results
maxAge = 60 and 1 Client
GET ndash Scenario 1 ClientProxy Interface Transaction Mix
Scenarios 1a - Non-Sleepy Server Caching Proxy maxAge = 60sec 1b- Sleepy Server Caching Proxy maxAge = 60sec 1c - Sleepy Server Sleep Aware Proxy maxAge = 60sec
Sleep Aware Proxy has better performance for sleepy servers
0
100
200
300
400
500
600
700
1a 1b 1c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
GET ndash Scenario 1 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
Scenarios 1a - Non-Sleepy Server Caching Proxy maxAge = 60sec 1b- Sleepy Server Caching Proxy maxAge = 60sec 1c - Sleepy Server Sleep Aware Proxy maxAge = 60sec
0
100
200
300
400
500
600
700
800
1a 1b 1c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
ldquoGETrdquo ndash Test Scenario 2 Results
maxAge = 60 and 5 Clients
GET ndash Scenario 2 ClientProxy Interface Transaction Mix
Sleep Aware Proxy has slightly better performance for sleepy servers
0
200
400
600
800
1000
1200
1400
2a 2b 2c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
Scenarios 2a - Non-Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2b- Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2c - Sleepy Server Sleep Aware Proxy maxAge = 60sec 5 Clients
See ldquoExperimental Artifactsrdquo Note 1
GET ndash Scenario 2 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has slightly better performance for sleepy servers
0
50
100
150
200
250
300
350
400
2a 2b 2c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
Scenarios 2a - Non-Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2b- Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2c - Sleepy Server Sleep Aware Proxy maxAge = 60sec 5 Clients
See ldquoExperimental Artifactsrdquo Note 2
Experimental Artifacts Note 1
Currently in the experiment the sleep aware proxy checks the cached state of a resource before putting a request into its Store-and-forward queue while a server is sleeping Once in the queue the proxy unconditionally forwards the queued requests to the server once it wakes up This is not the most efficient setup and can easily be improved If the proxy instead checks its cache again before forwarding each queued request it may not need to forward the request to the server For example if there are two queued GET requests in the proxyrsquos queue that address the same resource Only the first request needs to be sent to the server the second request can use the cached response from the first request
Note 2 Currently in the experiment the sleepy server sends a sleepState PUT request to the
proxy each time it goes to sleep This is not the most efficient setup and can easily be improved For example if the server assumes that the proxy can keep track of its ONOFF cycles with its internal timers (eg as per Fig 1 of I-D) then the number of messages from the sleepy server dramatically goes down
ldquoGETrdquo ndash Test Scenario 3 Results
maxAge = 5 and 5 Clients
GET ndash Scenario 3 ClientProxy Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
Scenarios 3a - Non-Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3b- Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3c - Sleepy Server Sleep Aware Proxy maxAge = 5sec 5 Clients
0
500
1000
1500
2000
2500
3000
3500
4000
4500
5000
3a 3b 3c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
GET ndash Scenario 3 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
0
1000
2000
3000
4000
5000
6000
7000
3a 3b 3c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
Scenarios 3a - Non-Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3b- Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3c - Sleepy Server Sleep Aware Proxy maxAge = 5sec 5 Clients
Conclusions
Conclusions These results show that sleep-aware CoAP
proxy features can significantly optimize communication with sleepy servers in most scenarios
These results also show that sleep-
awareness capabilities can provide additional benefits above and beyond CoAP caching in most scenarios
Backup
Current CoAP Support of Sleepy Node (12)
CoAP proxies can use a previously cached response to service a new GET request for a sleepy origin server (as in HTTP) But if no valid cache then proxy has to attempt to
retrieve and may fail if origin server is sleeping [I-Dietf-core-coap]
Clients can discover list of resources from RD (GET rd-lookuphellip) for sleepy servers But attempt to GET resource from sleepy origin server
may fail if origin server is sleeping [IDietf-core-link-format amp IDshelby-core-resource-
directory]
Current CoAP Support of Sleepy Node (22)
Lower layer support for sleepy nodes in most wireless technologies (eg WiFi ZigBee) But limited to MAC packet scheduling for sleepy nodes
and not aware of specific needs of IP applications (like CoAP)
Proposal ndash RD Based Sleep Tracking (14)
The current CoAP approach to support sleepy nodes can be significantly improved by introducing RD based mechanisms for a CoAP client to determine whether A targeted resource is located on a sleepy server A sleepy server is currently in sleep mode or not
There is any associated caching Proxy (possibly the RD itself) for a sleepy server
Proposal ndash RD Based Sleep Tracking (24)
We define the following new RD attributes to characterize the properties of a sleepy node SleepState - Indicates whether the node is currently in
sleep mode or not (ie Sleeping or Awake) SleepDuration - Indicates the maximum duration of time
that the node stays in sleep mode TimeSleeping - Indicates the length of time the node
has been sleeping (ie if Sleep State = Sleeping) NextSleep - Indicates the next time the node will go to
sleep (ie if Sleep State = Awake)
CachingProxy ndash Indicates the caching proxy of the sleepy node (ie the RD itself or another node)
Proposal ndash RD Based Sleep Tracking (34)
These attributes are all server (node) level and are new parameters added to the RD URI Template Variables
Finally we also define a new lookup-type (ss) for the RD lookup interface specified in [I-Dshelby-core-resource-directory] This new lookup-type supports looking up the
ldquoSleepStaterdquo (ss) of a specified end-point
Proposal ndash RD Based Sleep Tracking (44)
The three time based parameters (SleepDuration TimeSleeping NextSleep) can be based on either an absolute network time (for a time synchronized network) or a relative local time (measured at the local node)
Following the approach of [I-Dietf-core-link-format] and [I-Dshelby-core-resource-directory] sleep parameters for sleepy servers can be stored by the server in the RD and accessed by all interested clients
Examples of using these parameters in a synchronous or asynchronous manner are shown in the I-D
http6lowappnet coreIETF86 2013-03-12-13
We assume people have read the drafts
Meetings serve to advance difficult issues by making good use of face-to-face communications
Note Well Be aware of the IPR principles according to RFC 3979 and its updates
uumlBlue sheetsuumlScribe(s)
96
drar-shy‐iep-shy‐core-shy‐coapsubmiqed13 to13 IESG
2013-shy‐03-shy‐13
97
OMA Lightweight M2M Overview(A new standard using lots of IETF specs including DTLS
CoAP Block Observe Resource Directory SenMLhellip)
Zach ShelbyCoRE WG IETF-86 Orlando
OMA Lightweight M2Mbull Open Mobile Alliance is well known for Device Management (DM)bull OMA Lightweight M2M is a new standard from the alliance
ndash Focused on constrained Cellular and sensor network M2M devicesndash Driven by leading operators and vendors
bull Scopendash Interfaces protocol amp security between Device and Serverndash Object and Resource modelndash Bootstrap Device Access Control Connectivity and Firmware Objects
bull Draft Specifications are availablendash httpmemberopenmobileallianceorgftpPublic_documentsDM
LightweightM2MPermanent_documentsOMA-TS-LightweightM2M-V1_0_0-20130301-Dzip
bull Timelinendash Requirements and Architecture completed 3Q2012ndash Spec ready for Consistency Review 2Q2013ndash Candidate Approval expected 3Q2013
2 CoRE WG IETF-86 Orlando
Architecture
3
Scope of LWM2M
CoRE WG IETF-86 Orlando
Object Model
bull A Client has one or more Object Instancesbull An Object is a collection of Resourcesbull A Resource is an atomic piece of information
ndash Read Written or Executed
bull Resources can have multiple instancesbull Objects and Resources are identified by a
16-bit Integer Instances by an 8-bit Integerbull ObjectsResources are accessed with
simple URIs Object IDObject InstanceResource ID
eg 1213
4 CoRE WG IETF-86 Orlando
CoRE WG IETF-86 Orlando
CoRE Resource Directory
draft-shelby-core-resource-directory-05
Z Shelby C Bormann S Krco
Backgroundbull Not a new concept
ndash think web search engine or any link directorybull Defines the interfaces to a Resource Directorybull Based on Web Linking framework and the CoRE Link Formatbull Generic REST design for use over HTTP and CoAPbull Used by OMA Lightweight M2Mbull Has already been deployed
ndash In traffic monitoring systemsndash In street lighting systemsndash For vehicular asset trackingndash By a major Cellular M2M operator
Changes since -04
bull Restricted Update to parameter updatesbull Added pagination support for the Lookup interfacebull Changed rt= to et= for the registration amp update
interfacebull Added group support
Group Management
bull RD now includes group management featuresbull New Group Function Set
ndash Register a groupbull Group name domain multicast address endpoint members
ndash Remove a groupbull Group lookup using the Lookup Function Set
ndash List registered groupsndash Find the members of a groupndash Find groups with certain endpoints or resources
Registering a Group
EP RD
| |
| - POST rd-groupgp=lights ltgtep=node1 --gt |
| |
| |
| lt---- 201 Created Location rd-group12 ---- |
| |
Req POST coaprdexamplecomrd-groupgp=lights
Payload
ltgtep=node1
ltgtep=node2
Res 201 Created
Location rd-group12
Looking up Group Members
Client RD
| |
| ----- GET rd-lookupepgp=lights1 ----------------------gt |
| |
| |
| lt-- 205 Content ltrdgtd=domain1ltrdgtd=domain2 --------- |
| |
Req GET rd-lookupepgp=lights1
Res 205 Content
ltcoaphostportgtep=node1
ltcoaphostportgtep=node2rdquo
Things for the futurebull Support for JSON representation of Web Links
ndash httptoolsietforgiddraft-bormann-core-links-json-02txtbull Registry for RD registration query parameters
ndash Already OMA Lightweight has defined some new onesbull More examples
Group 3 ldquonew workrdquo(continued)
109
drar-shy‐greevenbosch-shy‐core-shy‐profile-shy‐descripon-shy‐01Bert13 GreevenboschJeroen13 Hoebeke
Isam13 IshaqFloris13 Van13 den13 Abeele
Descripon
bull JSON13 format13 for13 signalling13 the13 servers13 capabilies
bull Signalling13 of13 supported13 opons13 media13 types13 and13 block13 sizendash Other13 items13 can13 be13 added
bull Filtering13 on13 specific13 fields13 through13 URI-shy‐Querybull Link13 hqpdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐profile-shy‐descripon
well-shy‐knownprofile
bull To13 acquire13 profile13 data13 of13 resources13 on13 a13 parcular13 service13 the13 well-shy‐knownprofile13 URI-shy‐path13 is13 introduced
bull For13 example13 to13 get13 all13 informaon13 from13 sensors13 served13 by13 wwwexampleorg13 we13 can13 do13 a13 GET13 to13 coapwwwexampleorgwell-shy‐knownprofile
bull Filtering13 on13 parcular13 resources13 is13 done13 through13 URI-shy‐Queries
Format
bull Currently13 the13 following13 fields13 are13 definedndash ldquopathrdquo13 contains13 the13 URI-shy‐path13 associated13 with13 a13 resource
ndash ldquooprdquo13 a13 numerical13 list13 of13 supported13 opon13 numbers
ndash ldquocfrdquo13 a13 numerical13 list13 of13 supported13 content-shy‐format13 numbers
ndash ldquob1srdquo13 ldquob2srdquo13 supported13 block13 sizes13 for13 Block113 and13 Block213 respecvely
Examplebull On13 the13 right13 is13 an13 example13 of13 a13 camera13 sensor13 at13 coapwwwexampleorgcam13 that13 supports13 the13 Uri-shy‐Host13 (3)13 ETag13 (4)13 Uri-shy‐Port13 (7)13 Uri-shy‐Path13 (11)13 Content-shy‐Format13 (12)13 Token13 (19)13 Block213 (23)13 and13 Proxy-shy‐Uri13 (35)13 opons
bull The13 supported13 content13 formats13 are13 textplain13 (0)13 applicaon13 link-shy‐format13 (40)13 and13 applicaonjson13 (50)
bull The13 supported13 Block213 can13 use13 25613 or13 51213 byte13 blocks
Req13 GET13 coapwwwexampleorgwell-shy‐knownprofile13 Res13 20513 Content13 (applicationjson)13 13 13 13 profile13 13 13 13 13 13 13 13 pathcam13 13 13 13 op[3471112192335]13 13 13 13 13 cf[04050]13 13 13 13 13 b2s[45]13 13 13 13
Filtering13 through13 use13 of13 URI-shy‐Query
bull Filtering13 can13 be13 done13 through13 the13 URI-shy‐Querybull Query13 format13 N=V
ndash N13 is13 a13 profile13 fieldndash V13 is13 the13 desired13 value
bull Examplesndash To13 find13 resources13 that13 support13 content13 format13 ldquoapplicaonjsonrdquo
13 GET13 wwwexampleorgwell-shy‐knownprofilecf=50ndash To13 get13 informaon13 about13 the13 camera
13 GET13 wwwexampleorgwell-shy‐knownprofilepath=cam
Open13 issues
bull Which13 other13 profile13 data13 needs13 signallingndash Content-shy‐type13 for13 different13 methods
bull Fix13 the13 order13 in13 which13 the13 profile13 fields13 must13 appearndash Non-shy‐fixed13 order13 easier13 extensible
bull Inheritance13 of13 a13 profile13 descriponbull Extend13 usage13 to13 signal13 the13 client13 profilebull Integraon13 with13 link13 format
Thank13 youQuesons
drar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval-shy‐00
Bert13 Greevenbosch
Descripon
bull The13 ldquoMinimumRequestInterval13 opon13 can13 be13 used13 to13 indicate13 the13 minimum13 me13 between13 two13 requests13 in13 a13 transacon
bull Originally13 intended13 for13 Block13 but13 also13 usable13 for13 other13 transaconsndash Example13 browsing13 a13 server
bull The13 goal13 is13 to13 reduce13 the13 server13 load13 and13 network13 traffic
bull Link13 hqpsdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval
Usage
bull The13 client13 keeps13 the13 server13 informed13 about13 its13 request13 speed13 through13 inclusion13 of13 the13 ldquoMinimumRequestIntervalrdquo13 opon
bull In13 responses13 the13 server13 fixes13 the13 minimum13 request13 interval13 through13 the13 same13 opon
bull The13 client13 obeys13 the13 speed13 indicated13 by13 the13 server
bull The13 client13 can13 send13 slower13 but13 not13 faster
Advantages
bull The13 server13 has13 means13 to13 limit13 the13 amount13 of13 incoming13 traffic
bull The13 server13 can13 prevent13 to13 become13 overloaded13 with13 too13 many13 tasks
bull The13 server13 does13 not13 need13 arficially13 slow13 down13 the13 client13 by13 sending13 late13 ACKsndash No13 need13 to13 keep13 track13 of13 delayed13 ACKsndash The13 server13 can13 perform13 other13 tasks13 instead
bull Reduced13 network13 traffic
Thank13 youQuesons
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-links-json-02txt
123
RFC 6690 (link-format) documents are somewhat foreign to many web app developerssect would prefer to have them in JSON format
There is no standard way to represent link-format documents in applicationssect but everyone knows how to handle JSON
Define a standard JSON translation for link-format
Itrsquos
not
rock
et
scien
ce
ltsensorsgtct=40title=Sensor Index ltsensorstempgtrt=temperature-cif=sensor ltsensorslightgtrt=light-luxif=sensor lthttpwwwexamplecomsensorst123gt anchor=sensorstemprel=describedby lttgtanchor=sensorstemprel=alternate [hrefsensorsct40titleSensor Index hrefsensorstemprttemperature-cifsensor hrefsensorslightrtlight-luxifsensor hrefhttpwwwexamplecomsensorst123 anchorsensorstempreldescribedby hreftanchorsensorstemprelalternate]
124
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-ipsec-for-coap-00txt
IPsec definitions for CoAP Mostly placeholder at this time Who has implementation experience with this
125
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-cross-reverse-convention-00txt
This draft has two lines of payload(based on a WGLC comment by Cullen Jennings)
coap12344567foobara=3
httpwwwproxycomwellknowncore-translate1234_4567foobara=3
Is that a useful convention to have
126
Insert CI slides here
127
128
0
5
10
15
20
25
30
35
40
10 20 30 40 50 60 70
good
put (
pps)
pps
Goodput vs pps (Econotags)
goodput
[Khattak preliminary]
Congestion Control
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-cocoa-00txt
ldquoadvancedrdquo cc (The draft is just a first shot) Others may have better ideas
129
Insert post-WGLC discussion slides here
130
Stop Continue Start
131
An Agile Retrospective
http6lowappnet coreIETF86 2013-03-12-13
Stop
132
Endless new CoAP optionssect instead use RESTful as much as possible
Move general security lifecycle out Looking at theoretical problems
http6lowappnet coreIETF86 2013-03-12-13
Continue
Interops Running code Look at real-world examples and deployments Solve their actual problems
sect Unilateral enhancements eg higher performance congestion control
sect Transports (SMS hellip)sect Make Web linking and Directories more and more usefulsect RESTful Design Paradigms for real-world problems
133
http6lowappnet coreIETF86 2013-03-12-13
Start
Further push into the (browser) web world (HTML5 browser security)
Specific supporting worksect SenMLsect URI work (dev URN hellip)sect Security Processes (next slide)
Spin outsect (We donrsquot really get to decide where this is done)
134
http6lowappnet coreIETF86 2013-03-12-13
Security
Integrate Application Network Group Keyingsect Tunnel-free setup
Donrsquot redo what has been done alreadysect ZigBee IP is finesect But what about other scenarios
Simple REST interfaces for working with keying materials and authorizationsect Start with defining objectives
Object Security for Constrained Nodes135
Re-chartering CoREWhat do we want to do now that wersquore grown up
Zach ShelbyCoRE WG IETF-86 Orlando
What is the scope
bull So we have a protocol and Web Linking what next
bull Keep with what we know besthellip1 Enhancements around CoAP2 New transports for CoAP3 New representations for Web Links4 General application layer solutions
CoRE WG IETF-86 Orlando 2
Enhancements around CoAP
bull Advanced congestion control
CoRE WG IETF-86 Orlando 3
New Transports for CoAP
bull Infrastructure for CoAP over foondash httptoolsietforgiddraft-silverajan-core-
coap-alternative-transports-01txtbull CoAP over SMS
ndash httptoolsietforgiddraft-becker-core-coap-sms-gprs-03txt
ndash OMA Lightweightbull CoAP over TCP
ndash httptoolsietforgiddraft-li-core-coap-payload-length-option-01txt
CoRE WG IETF-86 Orlando 4
New support for Web Links
bull JSON Web Linksndash httptoolsietforgiddraft-bormann-core-links-
json-02txt
2332010 CoRE WG IETF-77 Anaheim 5
General application layer solutions
bull Resource Directoryndash httptoolsietforgiddraft-shelby-core-
resource-directory-05txtndash OMA Lightweight
2332010 CoRE WG IETF-77 Anaheim 6
ScenariosI In M2M communication IP connectivity is not alwayssupported by the constrained end-points
I Power savingI Coverage (GPRS 3G LTE)
I SMS and USSD based communication is almost alwayssupported
210
Changes from draft-01 to draft-03 (1)
I Added possible CONNONACK interactions Section 5
I Option name changed from Reply-To- to Response-To-Section 16 and Section 101
I Added URI schemeEg coap+tel+15105550101well-knowncore Section 11
I Added possible M2M proxy scenarios Section 14
3 10
Changes from draft-01 to draft-03 (2)
I Added reference to bormann-coap-misc for other SMSencoding Section 71
I Updated requirements on Uri-Host and Uri-Port forcoap+tel Section 10
I Added security considerations Transport and ObjectSecurity Section 15
I Chose CoAP option numbers and updated the optionnumber table to meet draft-ietf-core-coap-10 Table 1
I Added an IANA registration for the URI scheme coap+telSection 162
4 10
Feedback Split coap+tel into coap+smsand coap+ussd
I How else to differ the various transports in the URII Or is the transport to use decided by the implementationI See alsodraft-silverajan-core-coap-alternative-transports-01
5 10
Feedback Response-To-Scheme option
I Should there be a Response-To-Scheme optionadditionally to Response-To-Uri-Host andResponse-To-Uri-Path
I So that a CoAP end-point which receives a request by CoAPover non-IP transport can be instructed to also use thenon-IP transport for the response
I This would imply to add aResponse-To-Telephone-Subscriber and more options forother transports that have other URI schemes than coapand coaps
6 10
Feedback Selection of Transport by Client
I When a server is reachable by various transports howdoes a client decide which transport to use
I Client-side application congurationI Leave it to a proxy which uses cellular network lookupfunctions
7 10
Feedback Potential Threats
I Trigger expensive short messagesI Redirect trac to other addressesI More threats
I Are the security measures in the draft adequateI Whitelisting on serverI Relying on cellular network security (dedicated M2M APNs)I Object security on CoAP payload
8 10
Feedback Message Exchanges
I Figures 11-18 show possible message exchanges whenclient and server have two addresses
I With NON Not using CoAP retransmission capabilityI ACK on different transportI Additional (costly) message on Transport AI Request with Content
I Which ones are allowedI Which ones are meaningful
9 10
Next steps
I Rene Uri schemeI Response-To-Scheme optionI Selection of Message ExchangeI Rene Proxying
10 10
CoAP13 Communicaon13 with13 Alternave13 Transports
Bill Silverajan and Teemu SavolainenCore WG IETF 86 Orlando
031113
Objecves13 (In13 Scope)
bull Unambiguous13 representaon13 of13 transport13 to13 be13 used13 by13 CoAP
bull Details13 how13 the13 transport13 can13 carry13 CoAP13 packet
bull Focus13 is13 on13 what13 CoAP13 communicaons13 requirements13 are
bull Allow13 CoAP13 mechanisms13 to13 exploit13 cross-shy‐layer13 opmisaons
51
031113
Non13 Goals13 (Not13 in13 scope)
bull Applicaon-shy‐level13 QoS13 requirementsbull Real-shy‐me13 constraintsbull Ordering13 reliability13 congeson13 controlbull Applicaon13 and13 network13 adaptaonbull Mobility13 and13 readdressing13 supportbull Network13 protocol13 (eg13 IPsec)13 configuraon
52
031113
Use13 Cases
bull NAT13 and13 Firewall13 traversal13 with13 TCPbull Delay13 Tolerant13 Networkingbull Non-shy‐IP13 Low13 Energy13 Protocols
53
031113
Related13 Work
bull OMA13 Lightweight13 M2M13 Protocolbull CoAP13 over13 SMSGPRSUSSD
54
031113
What13 does13 the13 work13 entail
bull The13 ability13 to13 specify13 end13 point13 idenfiers13 and13 URIs13 to13 reflect13 which13 transport13 CoAP13 can13 use
bull The13 ability13 to13 register13 to13 resource13 directories13 resource13 types13 reflecng13 types13 of13 transport13 available
bull Ability13 for13 mul-shy‐transport13 nodes13 to13 select13 transport13 to13 use13 without13 significant13 alteraon13 to13 CoAP13 packet13 structure
55
031113
Points13 to13 consider
bull Requirements13 for13 transport13 layer13 protocol13 to13 carry13 CoAP13 packets
bull Representaon13 of13 URI13 scheme13 for13 generic13 transport13 protocols
bull Opon13 extensions13 for13 CoAP13 to13 express13 available13 transports
bull Mapping13 and13 message13 sizebull Security13 consideraons
56
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
URI13 =13 scheme13 13 13 authority13 path-shy‐abempty13 [13 query13 ]
bull Within13 the13 scheme13 namebull In13 the13 URI13 pathbull As13 a13 query13 component
57
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
bull Within13 the13 scheme13 namendash coap+tel+15105550101well-shy‐knowncorendash coap+tcpexamplecom5683temperaturendash coap+blel2cap[1234567890AB]4pulse
bull Easy13 URI13 parsing13 for13 transport13 type13 and13 idenfier
bull Each13 new13 scheme13 name13 requires13 IANA13 registraon
58
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
bull In13 the13 URI13 pathndash coaphostexamplecomtransport=tcpwell-shy‐knowncorert=core-shy‐rd
bull Easy13 adopon13 of13 new13 (and13 experimental)13 CoAP13 transports13 without13 IANA13 registraon
bull Caveat13 Uri-shy‐Path13 opon13 is13 a13 Crical13 CoAP13 opon13 see13 secon13 54113 of13 I-shy‐Diep-shy‐core-shy‐coap
59
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
bull As13 a13 URI13 query13 componentndash coaphostexamplecomwell-shy‐knowncorert=core-shy‐rdq=tcp
bull Also13 easy13 to13 adopt13 new13 (and13 experimental)13 CoAP13 transports13 without13 IANA13 registraon
bull Caveat13 Uri-shy‐Query13 opon13 is13 a13 Crical13 CoAP13 opon13 see13 secon13 54113 of13 I-shy‐Diep-shy‐core-shy‐coap
60
031113
URI13 Representaons13 for13 CoAPNon13 standard13 ways
bull Transport13 in13 the13 URI13 authority13 componentndash coaphost[port][transport]13 instead13 of13 coaphost[port]
bull Transport13 as13 a13 service13 URLndash servicecoaptcphostexamplecomwell-shy‐knowncorert=core-shy‐rd
bull Above13 two13 ways13 break13 exisng13 compability13 (although13 both13 are13 based13 on13 valid13 IANA13 URI13 registraons)
61
031113
URI13 Representaons13 for13 CoAPMiscellaneous13 Consideraons
bull Ensure13 that13 transport13 is13 defined13 unambiguously13 (eg13 L2CAP13 used13 by13 both13 BLE13 and13 standard13 Bluetooth13 so13 avoid13 rdquocoap+l2caprdquo13 or13 rdquotransport=l2caprdquo13 or13 rdquoq=l2caprdquondash Can13 be13 done13 as13 WG13 consensusndash Namespace13 approach13 eg13 rdquocoap+blel2caprdquo13 or13 rdquoq=blel2caprdquo
bull Allow13 end-shy‐points13 to13 use13 CoAP13 Resource13 Directory13 to13 register13 alternave13 transports13 and13 idenfiers13 and13 provide13 periodic13 updatesndash Register13 rdquocore-shy‐transportrdquo13 resource13 type
62
031113
Transport13 Consideraons
bull Uniqueness13 of13 end-shy‐point13 idenficaonbull Communicaon13 support13 Unidireconal13 Bidireconal13 1N13 (broadcast13 mulcast13 anycast)13 messaging
bull Binary13 encoding13 Network13 byte13 orderingbull MTU13 correlaon13 with13 CoAP13 PDU13 sizebull Transport13 latency
63
031113
Security13 Consideraons
bull Drar13 does13 not13 introduce13 new13 security13 requirements13 by13 itself
bull There13 may13 be13 privacy13 issues13 if13 nodes13 use13 telephone13 numbers13 or13 MAC13 addresses13 as13 public13 end13 point13 idenfiers
64
Akbar Rahman
IETF 86 March 2013 httpwwwietforgiddraft-rahman-core-sleepy-02txt
Enhanced Sleepy Node Support for CoAP
Introduction
It is expected that in CoAP networks there will be a certain portion of devices that are sleepy and which may occasionally go into a sleep mode (ie go into a low power state to conserve power) and subsequently have reduced CoAP protocol communication ability
This I-D proposes a minimal and efficient mechanism building on the Resource Directory concept (which will be integrated into a CoAP Proxy) to enhance sleepy node support in CoAP networks
Main Question from IETF-85 (Atlanta)
What performance benefit does the proposed Sleepy Node support solution give in a network that already has standard CoAP caching enabled
Sleepy Node Performance Analysis
Experimental Network
1-5 clients
Both Sleepy and Non-
Sleepy servers
Sleepy Node Performance Analysis Network Setup
CoAPSleepyServer(s)
CoAPSleepAwareReverseProxy
CoAP
Client(s)
Request
Response
Sleep9AwareCoREResourceDirectoryCapability
PublishedSleepParameters
Sleep9AwareCoAPStoreandForwardCapability Response
Request
SleepAwareCoAP503ResponseCapability
CoAPCachingCapability
bull Server supports publishing sleep parameters to proxy bull Eg Irsquom going to be asleep for X seconds
bull Proxy supports sleep-awareness capabilities bull Proxy also supports caching capability based off of maxAge bull Protocol flow similar to approach of Figure 1 (Synchronous RD Based Sleep
Tracking) of I-D
Proxy capabilities can be selectively enableddisabled
Proxy ndash Server Interface
Client ndash Proxy Interface
CoAP Sleep-Aware Reverse Proxy Features CoRE Sleep-aware Resource Directory
Support storing published sleep parameters from CoAP servers sleepState (AWAKE ASLEEP) sleepDuration
Sleep-aware CoAP 503 Response Capability If CoAP request to a sleeping server is received proxy returns a
lsquo503 Retry-Afterrsquo response to client 503 contains a timestamp indicating when the sever will wake back up
(timestamp delivered in CoAP maxAge option) Sleep-aware CoAP Store-and-Forward Capability
If CoAP request to a sleeping server is received proxy stores request until server wakes up and then forwards it
Caching capability Cache GET responses from server if maxAge option is present
(this is not a sleep aware feature)
Goals of Performance Analysis
For networks having sleepy servers provide measurements to quantify the impact that CoAP sleep-awareness capabilities can have
See if sleep-awareness capabilities can
provide additional benefits even when CoAP caching is used
Overview of Performance Analysis Performed The analysis was broken up into a set of test scenarios Each test scenario used a different combination of the following
variables Client issued GET requests Server was configured as a sleepy or non-sleepy server Proxy caching of GET responses was enabled or disabled Proxy sleep-aware 503 response capability was enabled or disabled Proxy store-and-forward capability was enabled or disabled maxAge in GET responses ndash Two values were tested 60sec and 5sec of Clients ndash Two values were used ndash 1 client and 5 clients
For comparison purposes the following were held constant across all test scenarios Client issued a fixed number of requests (100) across all test scenarios Client used a delay between each GET request (35sec) to better exercise
proxyrsquos caching and sleep-awareness capabilities For sleepy server test scenarios the server slept 60 sec awake for 3 sec
Format of Results The following results were collected for each
test scenario
Breakdown of the and types of transactions occurring between clientproxyserver
ldquoGETrdquo ndash Test Scenario Results
GET ndash Description of Test Scenarios
TestScenarios-GET
Scenario
CoAPSleepyServerSe7ngs CoAPSleepAwareReverseProxySe7ngs CoAPClientSe7ngs
SleepDuragton(sec)
AwakeDuragton(sec)
maxAge(sec) Caching SleepAwareSAF+
503NumberofClients
NumberofGETs
DelayBetweenClient
Requests(sec)
1a 0 Always 60 Enabled Disabled 1 100 35
1b 60 3 60 Enabled Disabled 1 100 35
1c 60 3 60 Enabled Enabled 1 100 35
2a 0 Always 60 Enabled Disabled 5 100 35
2b 60 3 60 Enabled Disabled 5 100 35
2c 60 3 60 Enabled Enabled 5 100 35
3a 0 Always 5 Enabled Disabled 5 100 35
3b 60 3 5 Enabled Disabled 5 100 35
3c 60 3 5 Enabled Enabled 5 100 35
ldquoGETrdquo ndash Test Scenario 1 Results
maxAge = 60 and 1 Client
GET ndash Scenario 1 ClientProxy Interface Transaction Mix
Scenarios 1a - Non-Sleepy Server Caching Proxy maxAge = 60sec 1b- Sleepy Server Caching Proxy maxAge = 60sec 1c - Sleepy Server Sleep Aware Proxy maxAge = 60sec
Sleep Aware Proxy has better performance for sleepy servers
0
100
200
300
400
500
600
700
1a 1b 1c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
GET ndash Scenario 1 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
Scenarios 1a - Non-Sleepy Server Caching Proxy maxAge = 60sec 1b- Sleepy Server Caching Proxy maxAge = 60sec 1c - Sleepy Server Sleep Aware Proxy maxAge = 60sec
0
100
200
300
400
500
600
700
800
1a 1b 1c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
ldquoGETrdquo ndash Test Scenario 2 Results
maxAge = 60 and 5 Clients
GET ndash Scenario 2 ClientProxy Interface Transaction Mix
Sleep Aware Proxy has slightly better performance for sleepy servers
0
200
400
600
800
1000
1200
1400
2a 2b 2c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
Scenarios 2a - Non-Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2b- Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2c - Sleepy Server Sleep Aware Proxy maxAge = 60sec 5 Clients
See ldquoExperimental Artifactsrdquo Note 1
GET ndash Scenario 2 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has slightly better performance for sleepy servers
0
50
100
150
200
250
300
350
400
2a 2b 2c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
Scenarios 2a - Non-Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2b- Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2c - Sleepy Server Sleep Aware Proxy maxAge = 60sec 5 Clients
See ldquoExperimental Artifactsrdquo Note 2
Experimental Artifacts Note 1
Currently in the experiment the sleep aware proxy checks the cached state of a resource before putting a request into its Store-and-forward queue while a server is sleeping Once in the queue the proxy unconditionally forwards the queued requests to the server once it wakes up This is not the most efficient setup and can easily be improved If the proxy instead checks its cache again before forwarding each queued request it may not need to forward the request to the server For example if there are two queued GET requests in the proxyrsquos queue that address the same resource Only the first request needs to be sent to the server the second request can use the cached response from the first request
Note 2 Currently in the experiment the sleepy server sends a sleepState PUT request to the
proxy each time it goes to sleep This is not the most efficient setup and can easily be improved For example if the server assumes that the proxy can keep track of its ONOFF cycles with its internal timers (eg as per Fig 1 of I-D) then the number of messages from the sleepy server dramatically goes down
ldquoGETrdquo ndash Test Scenario 3 Results
maxAge = 5 and 5 Clients
GET ndash Scenario 3 ClientProxy Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
Scenarios 3a - Non-Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3b- Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3c - Sleepy Server Sleep Aware Proxy maxAge = 5sec 5 Clients
0
500
1000
1500
2000
2500
3000
3500
4000
4500
5000
3a 3b 3c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
GET ndash Scenario 3 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
0
1000
2000
3000
4000
5000
6000
7000
3a 3b 3c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
Scenarios 3a - Non-Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3b- Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3c - Sleepy Server Sleep Aware Proxy maxAge = 5sec 5 Clients
Conclusions
Conclusions These results show that sleep-aware CoAP
proxy features can significantly optimize communication with sleepy servers in most scenarios
These results also show that sleep-
awareness capabilities can provide additional benefits above and beyond CoAP caching in most scenarios
Backup
Current CoAP Support of Sleepy Node (12)
CoAP proxies can use a previously cached response to service a new GET request for a sleepy origin server (as in HTTP) But if no valid cache then proxy has to attempt to
retrieve and may fail if origin server is sleeping [I-Dietf-core-coap]
Clients can discover list of resources from RD (GET rd-lookuphellip) for sleepy servers But attempt to GET resource from sleepy origin server
may fail if origin server is sleeping [IDietf-core-link-format amp IDshelby-core-resource-
directory]
Current CoAP Support of Sleepy Node (22)
Lower layer support for sleepy nodes in most wireless technologies (eg WiFi ZigBee) But limited to MAC packet scheduling for sleepy nodes
and not aware of specific needs of IP applications (like CoAP)
Proposal ndash RD Based Sleep Tracking (14)
The current CoAP approach to support sleepy nodes can be significantly improved by introducing RD based mechanisms for a CoAP client to determine whether A targeted resource is located on a sleepy server A sleepy server is currently in sleep mode or not
There is any associated caching Proxy (possibly the RD itself) for a sleepy server
Proposal ndash RD Based Sleep Tracking (24)
We define the following new RD attributes to characterize the properties of a sleepy node SleepState - Indicates whether the node is currently in
sleep mode or not (ie Sleeping or Awake) SleepDuration - Indicates the maximum duration of time
that the node stays in sleep mode TimeSleeping - Indicates the length of time the node
has been sleeping (ie if Sleep State = Sleeping) NextSleep - Indicates the next time the node will go to
sleep (ie if Sleep State = Awake)
CachingProxy ndash Indicates the caching proxy of the sleepy node (ie the RD itself or another node)
Proposal ndash RD Based Sleep Tracking (34)
These attributes are all server (node) level and are new parameters added to the RD URI Template Variables
Finally we also define a new lookup-type (ss) for the RD lookup interface specified in [I-Dshelby-core-resource-directory] This new lookup-type supports looking up the
ldquoSleepStaterdquo (ss) of a specified end-point
Proposal ndash RD Based Sleep Tracking (44)
The three time based parameters (SleepDuration TimeSleeping NextSleep) can be based on either an absolute network time (for a time synchronized network) or a relative local time (measured at the local node)
Following the approach of [I-Dietf-core-link-format] and [I-Dshelby-core-resource-directory] sleep parameters for sleepy servers can be stored by the server in the RD and accessed by all interested clients
Examples of using these parameters in a synchronous or asynchronous manner are shown in the I-D
http6lowappnet coreIETF86 2013-03-12-13
We assume people have read the drafts
Meetings serve to advance difficult issues by making good use of face-to-face communications
Note Well Be aware of the IPR principles according to RFC 3979 and its updates
uumlBlue sheetsuumlScribe(s)
96
drar-shy‐iep-shy‐core-shy‐coapsubmiqed13 to13 IESG
2013-shy‐03-shy‐13
97
OMA Lightweight M2M Overview(A new standard using lots of IETF specs including DTLS
CoAP Block Observe Resource Directory SenMLhellip)
Zach ShelbyCoRE WG IETF-86 Orlando
OMA Lightweight M2Mbull Open Mobile Alliance is well known for Device Management (DM)bull OMA Lightweight M2M is a new standard from the alliance
ndash Focused on constrained Cellular and sensor network M2M devicesndash Driven by leading operators and vendors
bull Scopendash Interfaces protocol amp security between Device and Serverndash Object and Resource modelndash Bootstrap Device Access Control Connectivity and Firmware Objects
bull Draft Specifications are availablendash httpmemberopenmobileallianceorgftpPublic_documentsDM
LightweightM2MPermanent_documentsOMA-TS-LightweightM2M-V1_0_0-20130301-Dzip
bull Timelinendash Requirements and Architecture completed 3Q2012ndash Spec ready for Consistency Review 2Q2013ndash Candidate Approval expected 3Q2013
2 CoRE WG IETF-86 Orlando
Architecture
3
Scope of LWM2M
CoRE WG IETF-86 Orlando
Object Model
bull A Client has one or more Object Instancesbull An Object is a collection of Resourcesbull A Resource is an atomic piece of information
ndash Read Written or Executed
bull Resources can have multiple instancesbull Objects and Resources are identified by a
16-bit Integer Instances by an 8-bit Integerbull ObjectsResources are accessed with
simple URIs Object IDObject InstanceResource ID
eg 1213
4 CoRE WG IETF-86 Orlando
CoRE WG IETF-86 Orlando
CoRE Resource Directory
draft-shelby-core-resource-directory-05
Z Shelby C Bormann S Krco
Backgroundbull Not a new concept
ndash think web search engine or any link directorybull Defines the interfaces to a Resource Directorybull Based on Web Linking framework and the CoRE Link Formatbull Generic REST design for use over HTTP and CoAPbull Used by OMA Lightweight M2Mbull Has already been deployed
ndash In traffic monitoring systemsndash In street lighting systemsndash For vehicular asset trackingndash By a major Cellular M2M operator
Changes since -04
bull Restricted Update to parameter updatesbull Added pagination support for the Lookup interfacebull Changed rt= to et= for the registration amp update
interfacebull Added group support
Group Management
bull RD now includes group management featuresbull New Group Function Set
ndash Register a groupbull Group name domain multicast address endpoint members
ndash Remove a groupbull Group lookup using the Lookup Function Set
ndash List registered groupsndash Find the members of a groupndash Find groups with certain endpoints or resources
Registering a Group
EP RD
| |
| - POST rd-groupgp=lights ltgtep=node1 --gt |
| |
| |
| lt---- 201 Created Location rd-group12 ---- |
| |
Req POST coaprdexamplecomrd-groupgp=lights
Payload
ltgtep=node1
ltgtep=node2
Res 201 Created
Location rd-group12
Looking up Group Members
Client RD
| |
| ----- GET rd-lookupepgp=lights1 ----------------------gt |
| |
| |
| lt-- 205 Content ltrdgtd=domain1ltrdgtd=domain2 --------- |
| |
Req GET rd-lookupepgp=lights1
Res 205 Content
ltcoaphostportgtep=node1
ltcoaphostportgtep=node2rdquo
Things for the futurebull Support for JSON representation of Web Links
ndash httptoolsietforgiddraft-bormann-core-links-json-02txtbull Registry for RD registration query parameters
ndash Already OMA Lightweight has defined some new onesbull More examples
Group 3 ldquonew workrdquo(continued)
109
drar-shy‐greevenbosch-shy‐core-shy‐profile-shy‐descripon-shy‐01Bert13 GreevenboschJeroen13 Hoebeke
Isam13 IshaqFloris13 Van13 den13 Abeele
Descripon
bull JSON13 format13 for13 signalling13 the13 servers13 capabilies
bull Signalling13 of13 supported13 opons13 media13 types13 and13 block13 sizendash Other13 items13 can13 be13 added
bull Filtering13 on13 specific13 fields13 through13 URI-shy‐Querybull Link13 hqpdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐profile-shy‐descripon
well-shy‐knownprofile
bull To13 acquire13 profile13 data13 of13 resources13 on13 a13 parcular13 service13 the13 well-shy‐knownprofile13 URI-shy‐path13 is13 introduced
bull For13 example13 to13 get13 all13 informaon13 from13 sensors13 served13 by13 wwwexampleorg13 we13 can13 do13 a13 GET13 to13 coapwwwexampleorgwell-shy‐knownprofile
bull Filtering13 on13 parcular13 resources13 is13 done13 through13 URI-shy‐Queries
Format
bull Currently13 the13 following13 fields13 are13 definedndash ldquopathrdquo13 contains13 the13 URI-shy‐path13 associated13 with13 a13 resource
ndash ldquooprdquo13 a13 numerical13 list13 of13 supported13 opon13 numbers
ndash ldquocfrdquo13 a13 numerical13 list13 of13 supported13 content-shy‐format13 numbers
ndash ldquob1srdquo13 ldquob2srdquo13 supported13 block13 sizes13 for13 Block113 and13 Block213 respecvely
Examplebull On13 the13 right13 is13 an13 example13 of13 a13 camera13 sensor13 at13 coapwwwexampleorgcam13 that13 supports13 the13 Uri-shy‐Host13 (3)13 ETag13 (4)13 Uri-shy‐Port13 (7)13 Uri-shy‐Path13 (11)13 Content-shy‐Format13 (12)13 Token13 (19)13 Block213 (23)13 and13 Proxy-shy‐Uri13 (35)13 opons
bull The13 supported13 content13 formats13 are13 textplain13 (0)13 applicaon13 link-shy‐format13 (40)13 and13 applicaonjson13 (50)
bull The13 supported13 Block213 can13 use13 25613 or13 51213 byte13 blocks
Req13 GET13 coapwwwexampleorgwell-shy‐knownprofile13 Res13 20513 Content13 (applicationjson)13 13 13 13 profile13 13 13 13 13 13 13 13 pathcam13 13 13 13 op[3471112192335]13 13 13 13 13 cf[04050]13 13 13 13 13 b2s[45]13 13 13 13
Filtering13 through13 use13 of13 URI-shy‐Query
bull Filtering13 can13 be13 done13 through13 the13 URI-shy‐Querybull Query13 format13 N=V
ndash N13 is13 a13 profile13 fieldndash V13 is13 the13 desired13 value
bull Examplesndash To13 find13 resources13 that13 support13 content13 format13 ldquoapplicaonjsonrdquo
13 GET13 wwwexampleorgwell-shy‐knownprofilecf=50ndash To13 get13 informaon13 about13 the13 camera
13 GET13 wwwexampleorgwell-shy‐knownprofilepath=cam
Open13 issues
bull Which13 other13 profile13 data13 needs13 signallingndash Content-shy‐type13 for13 different13 methods
bull Fix13 the13 order13 in13 which13 the13 profile13 fields13 must13 appearndash Non-shy‐fixed13 order13 easier13 extensible
bull Inheritance13 of13 a13 profile13 descriponbull Extend13 usage13 to13 signal13 the13 client13 profilebull Integraon13 with13 link13 format
Thank13 youQuesons
drar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval-shy‐00
Bert13 Greevenbosch
Descripon
bull The13 ldquoMinimumRequestInterval13 opon13 can13 be13 used13 to13 indicate13 the13 minimum13 me13 between13 two13 requests13 in13 a13 transacon
bull Originally13 intended13 for13 Block13 but13 also13 usable13 for13 other13 transaconsndash Example13 browsing13 a13 server
bull The13 goal13 is13 to13 reduce13 the13 server13 load13 and13 network13 traffic
bull Link13 hqpsdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval
Usage
bull The13 client13 keeps13 the13 server13 informed13 about13 its13 request13 speed13 through13 inclusion13 of13 the13 ldquoMinimumRequestIntervalrdquo13 opon
bull In13 responses13 the13 server13 fixes13 the13 minimum13 request13 interval13 through13 the13 same13 opon
bull The13 client13 obeys13 the13 speed13 indicated13 by13 the13 server
bull The13 client13 can13 send13 slower13 but13 not13 faster
Advantages
bull The13 server13 has13 means13 to13 limit13 the13 amount13 of13 incoming13 traffic
bull The13 server13 can13 prevent13 to13 become13 overloaded13 with13 too13 many13 tasks
bull The13 server13 does13 not13 need13 arficially13 slow13 down13 the13 client13 by13 sending13 late13 ACKsndash No13 need13 to13 keep13 track13 of13 delayed13 ACKsndash The13 server13 can13 perform13 other13 tasks13 instead
bull Reduced13 network13 traffic
Thank13 youQuesons
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-links-json-02txt
123
RFC 6690 (link-format) documents are somewhat foreign to many web app developerssect would prefer to have them in JSON format
There is no standard way to represent link-format documents in applicationssect but everyone knows how to handle JSON
Define a standard JSON translation for link-format
Itrsquos
not
rock
et
scien
ce
ltsensorsgtct=40title=Sensor Index ltsensorstempgtrt=temperature-cif=sensor ltsensorslightgtrt=light-luxif=sensor lthttpwwwexamplecomsensorst123gt anchor=sensorstemprel=describedby lttgtanchor=sensorstemprel=alternate [hrefsensorsct40titleSensor Index hrefsensorstemprttemperature-cifsensor hrefsensorslightrtlight-luxifsensor hrefhttpwwwexamplecomsensorst123 anchorsensorstempreldescribedby hreftanchorsensorstemprelalternate]
124
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-ipsec-for-coap-00txt
IPsec definitions for CoAP Mostly placeholder at this time Who has implementation experience with this
125
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-cross-reverse-convention-00txt
This draft has two lines of payload(based on a WGLC comment by Cullen Jennings)
coap12344567foobara=3
httpwwwproxycomwellknowncore-translate1234_4567foobara=3
Is that a useful convention to have
126
Insert CI slides here
127
128
0
5
10
15
20
25
30
35
40
10 20 30 40 50 60 70
good
put (
pps)
pps
Goodput vs pps (Econotags)
goodput
[Khattak preliminary]
Congestion Control
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-cocoa-00txt
ldquoadvancedrdquo cc (The draft is just a first shot) Others may have better ideas
129
Insert post-WGLC discussion slides here
130
Stop Continue Start
131
An Agile Retrospective
http6lowappnet coreIETF86 2013-03-12-13
Stop
132
Endless new CoAP optionssect instead use RESTful as much as possible
Move general security lifecycle out Looking at theoretical problems
http6lowappnet coreIETF86 2013-03-12-13
Continue
Interops Running code Look at real-world examples and deployments Solve their actual problems
sect Unilateral enhancements eg higher performance congestion control
sect Transports (SMS hellip)sect Make Web linking and Directories more and more usefulsect RESTful Design Paradigms for real-world problems
133
http6lowappnet coreIETF86 2013-03-12-13
Start
Further push into the (browser) web world (HTML5 browser security)
Specific supporting worksect SenMLsect URI work (dev URN hellip)sect Security Processes (next slide)
Spin outsect (We donrsquot really get to decide where this is done)
134
http6lowappnet coreIETF86 2013-03-12-13
Security
Integrate Application Network Group Keyingsect Tunnel-free setup
Donrsquot redo what has been done alreadysect ZigBee IP is finesect But what about other scenarios
Simple REST interfaces for working with keying materials and authorizationsect Start with defining objectives
Object Security for Constrained Nodes135
Re-chartering CoREWhat do we want to do now that wersquore grown up
Zach ShelbyCoRE WG IETF-86 Orlando
What is the scope
bull So we have a protocol and Web Linking what next
bull Keep with what we know besthellip1 Enhancements around CoAP2 New transports for CoAP3 New representations for Web Links4 General application layer solutions
CoRE WG IETF-86 Orlando 2
Enhancements around CoAP
bull Advanced congestion control
CoRE WG IETF-86 Orlando 3
New Transports for CoAP
bull Infrastructure for CoAP over foondash httptoolsietforgiddraft-silverajan-core-
coap-alternative-transports-01txtbull CoAP over SMS
ndash httptoolsietforgiddraft-becker-core-coap-sms-gprs-03txt
ndash OMA Lightweightbull CoAP over TCP
ndash httptoolsietforgiddraft-li-core-coap-payload-length-option-01txt
CoRE WG IETF-86 Orlando 4
New support for Web Links
bull JSON Web Linksndash httptoolsietforgiddraft-bormann-core-links-
json-02txt
2332010 CoRE WG IETF-77 Anaheim 5
General application layer solutions
bull Resource Directoryndash httptoolsietforgiddraft-shelby-core-
resource-directory-05txtndash OMA Lightweight
2332010 CoRE WG IETF-77 Anaheim 6
Changes from draft-01 to draft-03 (1)
I Added possible CONNONACK interactions Section 5
I Option name changed from Reply-To- to Response-To-Section 16 and Section 101
I Added URI schemeEg coap+tel+15105550101well-knowncore Section 11
I Added possible M2M proxy scenarios Section 14
3 10
Changes from draft-01 to draft-03 (2)
I Added reference to bormann-coap-misc for other SMSencoding Section 71
I Updated requirements on Uri-Host and Uri-Port forcoap+tel Section 10
I Added security considerations Transport and ObjectSecurity Section 15
I Chose CoAP option numbers and updated the optionnumber table to meet draft-ietf-core-coap-10 Table 1
I Added an IANA registration for the URI scheme coap+telSection 162
4 10
Feedback Split coap+tel into coap+smsand coap+ussd
I How else to differ the various transports in the URII Or is the transport to use decided by the implementationI See alsodraft-silverajan-core-coap-alternative-transports-01
5 10
Feedback Response-To-Scheme option
I Should there be a Response-To-Scheme optionadditionally to Response-To-Uri-Host andResponse-To-Uri-Path
I So that a CoAP end-point which receives a request by CoAPover non-IP transport can be instructed to also use thenon-IP transport for the response
I This would imply to add aResponse-To-Telephone-Subscriber and more options forother transports that have other URI schemes than coapand coaps
6 10
Feedback Selection of Transport by Client
I When a server is reachable by various transports howdoes a client decide which transport to use
I Client-side application congurationI Leave it to a proxy which uses cellular network lookupfunctions
7 10
Feedback Potential Threats
I Trigger expensive short messagesI Redirect trac to other addressesI More threats
I Are the security measures in the draft adequateI Whitelisting on serverI Relying on cellular network security (dedicated M2M APNs)I Object security on CoAP payload
8 10
Feedback Message Exchanges
I Figures 11-18 show possible message exchanges whenclient and server have two addresses
I With NON Not using CoAP retransmission capabilityI ACK on different transportI Additional (costly) message on Transport AI Request with Content
I Which ones are allowedI Which ones are meaningful
9 10
Next steps
I Rene Uri schemeI Response-To-Scheme optionI Selection of Message ExchangeI Rene Proxying
10 10
CoAP13 Communicaon13 with13 Alternave13 Transports
Bill Silverajan and Teemu SavolainenCore WG IETF 86 Orlando
031113
Objecves13 (In13 Scope)
bull Unambiguous13 representaon13 of13 transport13 to13 be13 used13 by13 CoAP
bull Details13 how13 the13 transport13 can13 carry13 CoAP13 packet
bull Focus13 is13 on13 what13 CoAP13 communicaons13 requirements13 are
bull Allow13 CoAP13 mechanisms13 to13 exploit13 cross-shy‐layer13 opmisaons
51
031113
Non13 Goals13 (Not13 in13 scope)
bull Applicaon-shy‐level13 QoS13 requirementsbull Real-shy‐me13 constraintsbull Ordering13 reliability13 congeson13 controlbull Applicaon13 and13 network13 adaptaonbull Mobility13 and13 readdressing13 supportbull Network13 protocol13 (eg13 IPsec)13 configuraon
52
031113
Use13 Cases
bull NAT13 and13 Firewall13 traversal13 with13 TCPbull Delay13 Tolerant13 Networkingbull Non-shy‐IP13 Low13 Energy13 Protocols
53
031113
Related13 Work
bull OMA13 Lightweight13 M2M13 Protocolbull CoAP13 over13 SMSGPRSUSSD
54
031113
What13 does13 the13 work13 entail
bull The13 ability13 to13 specify13 end13 point13 idenfiers13 and13 URIs13 to13 reflect13 which13 transport13 CoAP13 can13 use
bull The13 ability13 to13 register13 to13 resource13 directories13 resource13 types13 reflecng13 types13 of13 transport13 available
bull Ability13 for13 mul-shy‐transport13 nodes13 to13 select13 transport13 to13 use13 without13 significant13 alteraon13 to13 CoAP13 packet13 structure
55
031113
Points13 to13 consider
bull Requirements13 for13 transport13 layer13 protocol13 to13 carry13 CoAP13 packets
bull Representaon13 of13 URI13 scheme13 for13 generic13 transport13 protocols
bull Opon13 extensions13 for13 CoAP13 to13 express13 available13 transports
bull Mapping13 and13 message13 sizebull Security13 consideraons
56
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
URI13 =13 scheme13 13 13 authority13 path-shy‐abempty13 [13 query13 ]
bull Within13 the13 scheme13 namebull In13 the13 URI13 pathbull As13 a13 query13 component
57
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
bull Within13 the13 scheme13 namendash coap+tel+15105550101well-shy‐knowncorendash coap+tcpexamplecom5683temperaturendash coap+blel2cap[1234567890AB]4pulse
bull Easy13 URI13 parsing13 for13 transport13 type13 and13 idenfier
bull Each13 new13 scheme13 name13 requires13 IANA13 registraon
58
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
bull In13 the13 URI13 pathndash coaphostexamplecomtransport=tcpwell-shy‐knowncorert=core-shy‐rd
bull Easy13 adopon13 of13 new13 (and13 experimental)13 CoAP13 transports13 without13 IANA13 registraon
bull Caveat13 Uri-shy‐Path13 opon13 is13 a13 Crical13 CoAP13 opon13 see13 secon13 54113 of13 I-shy‐Diep-shy‐core-shy‐coap
59
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
bull As13 a13 URI13 query13 componentndash coaphostexamplecomwell-shy‐knowncorert=core-shy‐rdq=tcp
bull Also13 easy13 to13 adopt13 new13 (and13 experimental)13 CoAP13 transports13 without13 IANA13 registraon
bull Caveat13 Uri-shy‐Query13 opon13 is13 a13 Crical13 CoAP13 opon13 see13 secon13 54113 of13 I-shy‐Diep-shy‐core-shy‐coap
60
031113
URI13 Representaons13 for13 CoAPNon13 standard13 ways
bull Transport13 in13 the13 URI13 authority13 componentndash coaphost[port][transport]13 instead13 of13 coaphost[port]
bull Transport13 as13 a13 service13 URLndash servicecoaptcphostexamplecomwell-shy‐knowncorert=core-shy‐rd
bull Above13 two13 ways13 break13 exisng13 compability13 (although13 both13 are13 based13 on13 valid13 IANA13 URI13 registraons)
61
031113
URI13 Representaons13 for13 CoAPMiscellaneous13 Consideraons
bull Ensure13 that13 transport13 is13 defined13 unambiguously13 (eg13 L2CAP13 used13 by13 both13 BLE13 and13 standard13 Bluetooth13 so13 avoid13 rdquocoap+l2caprdquo13 or13 rdquotransport=l2caprdquo13 or13 rdquoq=l2caprdquondash Can13 be13 done13 as13 WG13 consensusndash Namespace13 approach13 eg13 rdquocoap+blel2caprdquo13 or13 rdquoq=blel2caprdquo
bull Allow13 end-shy‐points13 to13 use13 CoAP13 Resource13 Directory13 to13 register13 alternave13 transports13 and13 idenfiers13 and13 provide13 periodic13 updatesndash Register13 rdquocore-shy‐transportrdquo13 resource13 type
62
031113
Transport13 Consideraons
bull Uniqueness13 of13 end-shy‐point13 idenficaonbull Communicaon13 support13 Unidireconal13 Bidireconal13 1N13 (broadcast13 mulcast13 anycast)13 messaging
bull Binary13 encoding13 Network13 byte13 orderingbull MTU13 correlaon13 with13 CoAP13 PDU13 sizebull Transport13 latency
63
031113
Security13 Consideraons
bull Drar13 does13 not13 introduce13 new13 security13 requirements13 by13 itself
bull There13 may13 be13 privacy13 issues13 if13 nodes13 use13 telephone13 numbers13 or13 MAC13 addresses13 as13 public13 end13 point13 idenfiers
64
Akbar Rahman
IETF 86 March 2013 httpwwwietforgiddraft-rahman-core-sleepy-02txt
Enhanced Sleepy Node Support for CoAP
Introduction
It is expected that in CoAP networks there will be a certain portion of devices that are sleepy and which may occasionally go into a sleep mode (ie go into a low power state to conserve power) and subsequently have reduced CoAP protocol communication ability
This I-D proposes a minimal and efficient mechanism building on the Resource Directory concept (which will be integrated into a CoAP Proxy) to enhance sleepy node support in CoAP networks
Main Question from IETF-85 (Atlanta)
What performance benefit does the proposed Sleepy Node support solution give in a network that already has standard CoAP caching enabled
Sleepy Node Performance Analysis
Experimental Network
1-5 clients
Both Sleepy and Non-
Sleepy servers
Sleepy Node Performance Analysis Network Setup
CoAPSleepyServer(s)
CoAPSleepAwareReverseProxy
CoAP
Client(s)
Request
Response
Sleep9AwareCoREResourceDirectoryCapability
PublishedSleepParameters
Sleep9AwareCoAPStoreandForwardCapability Response
Request
SleepAwareCoAP503ResponseCapability
CoAPCachingCapability
bull Server supports publishing sleep parameters to proxy bull Eg Irsquom going to be asleep for X seconds
bull Proxy supports sleep-awareness capabilities bull Proxy also supports caching capability based off of maxAge bull Protocol flow similar to approach of Figure 1 (Synchronous RD Based Sleep
Tracking) of I-D
Proxy capabilities can be selectively enableddisabled
Proxy ndash Server Interface
Client ndash Proxy Interface
CoAP Sleep-Aware Reverse Proxy Features CoRE Sleep-aware Resource Directory
Support storing published sleep parameters from CoAP servers sleepState (AWAKE ASLEEP) sleepDuration
Sleep-aware CoAP 503 Response Capability If CoAP request to a sleeping server is received proxy returns a
lsquo503 Retry-Afterrsquo response to client 503 contains a timestamp indicating when the sever will wake back up
(timestamp delivered in CoAP maxAge option) Sleep-aware CoAP Store-and-Forward Capability
If CoAP request to a sleeping server is received proxy stores request until server wakes up and then forwards it
Caching capability Cache GET responses from server if maxAge option is present
(this is not a sleep aware feature)
Goals of Performance Analysis
For networks having sleepy servers provide measurements to quantify the impact that CoAP sleep-awareness capabilities can have
See if sleep-awareness capabilities can
provide additional benefits even when CoAP caching is used
Overview of Performance Analysis Performed The analysis was broken up into a set of test scenarios Each test scenario used a different combination of the following
variables Client issued GET requests Server was configured as a sleepy or non-sleepy server Proxy caching of GET responses was enabled or disabled Proxy sleep-aware 503 response capability was enabled or disabled Proxy store-and-forward capability was enabled or disabled maxAge in GET responses ndash Two values were tested 60sec and 5sec of Clients ndash Two values were used ndash 1 client and 5 clients
For comparison purposes the following were held constant across all test scenarios Client issued a fixed number of requests (100) across all test scenarios Client used a delay between each GET request (35sec) to better exercise
proxyrsquos caching and sleep-awareness capabilities For sleepy server test scenarios the server slept 60 sec awake for 3 sec
Format of Results The following results were collected for each
test scenario
Breakdown of the and types of transactions occurring between clientproxyserver
ldquoGETrdquo ndash Test Scenario Results
GET ndash Description of Test Scenarios
TestScenarios-GET
Scenario
CoAPSleepyServerSe7ngs CoAPSleepAwareReverseProxySe7ngs CoAPClientSe7ngs
SleepDuragton(sec)
AwakeDuragton(sec)
maxAge(sec) Caching SleepAwareSAF+
503NumberofClients
NumberofGETs
DelayBetweenClient
Requests(sec)
1a 0 Always 60 Enabled Disabled 1 100 35
1b 60 3 60 Enabled Disabled 1 100 35
1c 60 3 60 Enabled Enabled 1 100 35
2a 0 Always 60 Enabled Disabled 5 100 35
2b 60 3 60 Enabled Disabled 5 100 35
2c 60 3 60 Enabled Enabled 5 100 35
3a 0 Always 5 Enabled Disabled 5 100 35
3b 60 3 5 Enabled Disabled 5 100 35
3c 60 3 5 Enabled Enabled 5 100 35
ldquoGETrdquo ndash Test Scenario 1 Results
maxAge = 60 and 1 Client
GET ndash Scenario 1 ClientProxy Interface Transaction Mix
Scenarios 1a - Non-Sleepy Server Caching Proxy maxAge = 60sec 1b- Sleepy Server Caching Proxy maxAge = 60sec 1c - Sleepy Server Sleep Aware Proxy maxAge = 60sec
Sleep Aware Proxy has better performance for sleepy servers
0
100
200
300
400
500
600
700
1a 1b 1c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
GET ndash Scenario 1 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
Scenarios 1a - Non-Sleepy Server Caching Proxy maxAge = 60sec 1b- Sleepy Server Caching Proxy maxAge = 60sec 1c - Sleepy Server Sleep Aware Proxy maxAge = 60sec
0
100
200
300
400
500
600
700
800
1a 1b 1c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
ldquoGETrdquo ndash Test Scenario 2 Results
maxAge = 60 and 5 Clients
GET ndash Scenario 2 ClientProxy Interface Transaction Mix
Sleep Aware Proxy has slightly better performance for sleepy servers
0
200
400
600
800
1000
1200
1400
2a 2b 2c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
Scenarios 2a - Non-Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2b- Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2c - Sleepy Server Sleep Aware Proxy maxAge = 60sec 5 Clients
See ldquoExperimental Artifactsrdquo Note 1
GET ndash Scenario 2 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has slightly better performance for sleepy servers
0
50
100
150
200
250
300
350
400
2a 2b 2c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
Scenarios 2a - Non-Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2b- Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2c - Sleepy Server Sleep Aware Proxy maxAge = 60sec 5 Clients
See ldquoExperimental Artifactsrdquo Note 2
Experimental Artifacts Note 1
Currently in the experiment the sleep aware proxy checks the cached state of a resource before putting a request into its Store-and-forward queue while a server is sleeping Once in the queue the proxy unconditionally forwards the queued requests to the server once it wakes up This is not the most efficient setup and can easily be improved If the proxy instead checks its cache again before forwarding each queued request it may not need to forward the request to the server For example if there are two queued GET requests in the proxyrsquos queue that address the same resource Only the first request needs to be sent to the server the second request can use the cached response from the first request
Note 2 Currently in the experiment the sleepy server sends a sleepState PUT request to the
proxy each time it goes to sleep This is not the most efficient setup and can easily be improved For example if the server assumes that the proxy can keep track of its ONOFF cycles with its internal timers (eg as per Fig 1 of I-D) then the number of messages from the sleepy server dramatically goes down
ldquoGETrdquo ndash Test Scenario 3 Results
maxAge = 5 and 5 Clients
GET ndash Scenario 3 ClientProxy Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
Scenarios 3a - Non-Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3b- Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3c - Sleepy Server Sleep Aware Proxy maxAge = 5sec 5 Clients
0
500
1000
1500
2000
2500
3000
3500
4000
4500
5000
3a 3b 3c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
GET ndash Scenario 3 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
0
1000
2000
3000
4000
5000
6000
7000
3a 3b 3c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
Scenarios 3a - Non-Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3b- Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3c - Sleepy Server Sleep Aware Proxy maxAge = 5sec 5 Clients
Conclusions
Conclusions These results show that sleep-aware CoAP
proxy features can significantly optimize communication with sleepy servers in most scenarios
These results also show that sleep-
awareness capabilities can provide additional benefits above and beyond CoAP caching in most scenarios
Backup
Current CoAP Support of Sleepy Node (12)
CoAP proxies can use a previously cached response to service a new GET request for a sleepy origin server (as in HTTP) But if no valid cache then proxy has to attempt to
retrieve and may fail if origin server is sleeping [I-Dietf-core-coap]
Clients can discover list of resources from RD (GET rd-lookuphellip) for sleepy servers But attempt to GET resource from sleepy origin server
may fail if origin server is sleeping [IDietf-core-link-format amp IDshelby-core-resource-
directory]
Current CoAP Support of Sleepy Node (22)
Lower layer support for sleepy nodes in most wireless technologies (eg WiFi ZigBee) But limited to MAC packet scheduling for sleepy nodes
and not aware of specific needs of IP applications (like CoAP)
Proposal ndash RD Based Sleep Tracking (14)
The current CoAP approach to support sleepy nodes can be significantly improved by introducing RD based mechanisms for a CoAP client to determine whether A targeted resource is located on a sleepy server A sleepy server is currently in sleep mode or not
There is any associated caching Proxy (possibly the RD itself) for a sleepy server
Proposal ndash RD Based Sleep Tracking (24)
We define the following new RD attributes to characterize the properties of a sleepy node SleepState - Indicates whether the node is currently in
sleep mode or not (ie Sleeping or Awake) SleepDuration - Indicates the maximum duration of time
that the node stays in sleep mode TimeSleeping - Indicates the length of time the node
has been sleeping (ie if Sleep State = Sleeping) NextSleep - Indicates the next time the node will go to
sleep (ie if Sleep State = Awake)
CachingProxy ndash Indicates the caching proxy of the sleepy node (ie the RD itself or another node)
Proposal ndash RD Based Sleep Tracking (34)
These attributes are all server (node) level and are new parameters added to the RD URI Template Variables
Finally we also define a new lookup-type (ss) for the RD lookup interface specified in [I-Dshelby-core-resource-directory] This new lookup-type supports looking up the
ldquoSleepStaterdquo (ss) of a specified end-point
Proposal ndash RD Based Sleep Tracking (44)
The three time based parameters (SleepDuration TimeSleeping NextSleep) can be based on either an absolute network time (for a time synchronized network) or a relative local time (measured at the local node)
Following the approach of [I-Dietf-core-link-format] and [I-Dshelby-core-resource-directory] sleep parameters for sleepy servers can be stored by the server in the RD and accessed by all interested clients
Examples of using these parameters in a synchronous or asynchronous manner are shown in the I-D
http6lowappnet coreIETF86 2013-03-12-13
We assume people have read the drafts
Meetings serve to advance difficult issues by making good use of face-to-face communications
Note Well Be aware of the IPR principles according to RFC 3979 and its updates
uumlBlue sheetsuumlScribe(s)
96
drar-shy‐iep-shy‐core-shy‐coapsubmiqed13 to13 IESG
2013-shy‐03-shy‐13
97
OMA Lightweight M2M Overview(A new standard using lots of IETF specs including DTLS
CoAP Block Observe Resource Directory SenMLhellip)
Zach ShelbyCoRE WG IETF-86 Orlando
OMA Lightweight M2Mbull Open Mobile Alliance is well known for Device Management (DM)bull OMA Lightweight M2M is a new standard from the alliance
ndash Focused on constrained Cellular and sensor network M2M devicesndash Driven by leading operators and vendors
bull Scopendash Interfaces protocol amp security between Device and Serverndash Object and Resource modelndash Bootstrap Device Access Control Connectivity and Firmware Objects
bull Draft Specifications are availablendash httpmemberopenmobileallianceorgftpPublic_documentsDM
LightweightM2MPermanent_documentsOMA-TS-LightweightM2M-V1_0_0-20130301-Dzip
bull Timelinendash Requirements and Architecture completed 3Q2012ndash Spec ready for Consistency Review 2Q2013ndash Candidate Approval expected 3Q2013
2 CoRE WG IETF-86 Orlando
Architecture
3
Scope of LWM2M
CoRE WG IETF-86 Orlando
Object Model
bull A Client has one or more Object Instancesbull An Object is a collection of Resourcesbull A Resource is an atomic piece of information
ndash Read Written or Executed
bull Resources can have multiple instancesbull Objects and Resources are identified by a
16-bit Integer Instances by an 8-bit Integerbull ObjectsResources are accessed with
simple URIs Object IDObject InstanceResource ID
eg 1213
4 CoRE WG IETF-86 Orlando
CoRE WG IETF-86 Orlando
CoRE Resource Directory
draft-shelby-core-resource-directory-05
Z Shelby C Bormann S Krco
Backgroundbull Not a new concept
ndash think web search engine or any link directorybull Defines the interfaces to a Resource Directorybull Based on Web Linking framework and the CoRE Link Formatbull Generic REST design for use over HTTP and CoAPbull Used by OMA Lightweight M2Mbull Has already been deployed
ndash In traffic monitoring systemsndash In street lighting systemsndash For vehicular asset trackingndash By a major Cellular M2M operator
Changes since -04
bull Restricted Update to parameter updatesbull Added pagination support for the Lookup interfacebull Changed rt= to et= for the registration amp update
interfacebull Added group support
Group Management
bull RD now includes group management featuresbull New Group Function Set
ndash Register a groupbull Group name domain multicast address endpoint members
ndash Remove a groupbull Group lookup using the Lookup Function Set
ndash List registered groupsndash Find the members of a groupndash Find groups with certain endpoints or resources
Registering a Group
EP RD
| |
| - POST rd-groupgp=lights ltgtep=node1 --gt |
| |
| |
| lt---- 201 Created Location rd-group12 ---- |
| |
Req POST coaprdexamplecomrd-groupgp=lights
Payload
ltgtep=node1
ltgtep=node2
Res 201 Created
Location rd-group12
Looking up Group Members
Client RD
| |
| ----- GET rd-lookupepgp=lights1 ----------------------gt |
| |
| |
| lt-- 205 Content ltrdgtd=domain1ltrdgtd=domain2 --------- |
| |
Req GET rd-lookupepgp=lights1
Res 205 Content
ltcoaphostportgtep=node1
ltcoaphostportgtep=node2rdquo
Things for the futurebull Support for JSON representation of Web Links
ndash httptoolsietforgiddraft-bormann-core-links-json-02txtbull Registry for RD registration query parameters
ndash Already OMA Lightweight has defined some new onesbull More examples
Group 3 ldquonew workrdquo(continued)
109
drar-shy‐greevenbosch-shy‐core-shy‐profile-shy‐descripon-shy‐01Bert13 GreevenboschJeroen13 Hoebeke
Isam13 IshaqFloris13 Van13 den13 Abeele
Descripon
bull JSON13 format13 for13 signalling13 the13 servers13 capabilies
bull Signalling13 of13 supported13 opons13 media13 types13 and13 block13 sizendash Other13 items13 can13 be13 added
bull Filtering13 on13 specific13 fields13 through13 URI-shy‐Querybull Link13 hqpdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐profile-shy‐descripon
well-shy‐knownprofile
bull To13 acquire13 profile13 data13 of13 resources13 on13 a13 parcular13 service13 the13 well-shy‐knownprofile13 URI-shy‐path13 is13 introduced
bull For13 example13 to13 get13 all13 informaon13 from13 sensors13 served13 by13 wwwexampleorg13 we13 can13 do13 a13 GET13 to13 coapwwwexampleorgwell-shy‐knownprofile
bull Filtering13 on13 parcular13 resources13 is13 done13 through13 URI-shy‐Queries
Format
bull Currently13 the13 following13 fields13 are13 definedndash ldquopathrdquo13 contains13 the13 URI-shy‐path13 associated13 with13 a13 resource
ndash ldquooprdquo13 a13 numerical13 list13 of13 supported13 opon13 numbers
ndash ldquocfrdquo13 a13 numerical13 list13 of13 supported13 content-shy‐format13 numbers
ndash ldquob1srdquo13 ldquob2srdquo13 supported13 block13 sizes13 for13 Block113 and13 Block213 respecvely
Examplebull On13 the13 right13 is13 an13 example13 of13 a13 camera13 sensor13 at13 coapwwwexampleorgcam13 that13 supports13 the13 Uri-shy‐Host13 (3)13 ETag13 (4)13 Uri-shy‐Port13 (7)13 Uri-shy‐Path13 (11)13 Content-shy‐Format13 (12)13 Token13 (19)13 Block213 (23)13 and13 Proxy-shy‐Uri13 (35)13 opons
bull The13 supported13 content13 formats13 are13 textplain13 (0)13 applicaon13 link-shy‐format13 (40)13 and13 applicaonjson13 (50)
bull The13 supported13 Block213 can13 use13 25613 or13 51213 byte13 blocks
Req13 GET13 coapwwwexampleorgwell-shy‐knownprofile13 Res13 20513 Content13 (applicationjson)13 13 13 13 profile13 13 13 13 13 13 13 13 pathcam13 13 13 13 op[3471112192335]13 13 13 13 13 cf[04050]13 13 13 13 13 b2s[45]13 13 13 13
Filtering13 through13 use13 of13 URI-shy‐Query
bull Filtering13 can13 be13 done13 through13 the13 URI-shy‐Querybull Query13 format13 N=V
ndash N13 is13 a13 profile13 fieldndash V13 is13 the13 desired13 value
bull Examplesndash To13 find13 resources13 that13 support13 content13 format13 ldquoapplicaonjsonrdquo
13 GET13 wwwexampleorgwell-shy‐knownprofilecf=50ndash To13 get13 informaon13 about13 the13 camera
13 GET13 wwwexampleorgwell-shy‐knownprofilepath=cam
Open13 issues
bull Which13 other13 profile13 data13 needs13 signallingndash Content-shy‐type13 for13 different13 methods
bull Fix13 the13 order13 in13 which13 the13 profile13 fields13 must13 appearndash Non-shy‐fixed13 order13 easier13 extensible
bull Inheritance13 of13 a13 profile13 descriponbull Extend13 usage13 to13 signal13 the13 client13 profilebull Integraon13 with13 link13 format
Thank13 youQuesons
drar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval-shy‐00
Bert13 Greevenbosch
Descripon
bull The13 ldquoMinimumRequestInterval13 opon13 can13 be13 used13 to13 indicate13 the13 minimum13 me13 between13 two13 requests13 in13 a13 transacon
bull Originally13 intended13 for13 Block13 but13 also13 usable13 for13 other13 transaconsndash Example13 browsing13 a13 server
bull The13 goal13 is13 to13 reduce13 the13 server13 load13 and13 network13 traffic
bull Link13 hqpsdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval
Usage
bull The13 client13 keeps13 the13 server13 informed13 about13 its13 request13 speed13 through13 inclusion13 of13 the13 ldquoMinimumRequestIntervalrdquo13 opon
bull In13 responses13 the13 server13 fixes13 the13 minimum13 request13 interval13 through13 the13 same13 opon
bull The13 client13 obeys13 the13 speed13 indicated13 by13 the13 server
bull The13 client13 can13 send13 slower13 but13 not13 faster
Advantages
bull The13 server13 has13 means13 to13 limit13 the13 amount13 of13 incoming13 traffic
bull The13 server13 can13 prevent13 to13 become13 overloaded13 with13 too13 many13 tasks
bull The13 server13 does13 not13 need13 arficially13 slow13 down13 the13 client13 by13 sending13 late13 ACKsndash No13 need13 to13 keep13 track13 of13 delayed13 ACKsndash The13 server13 can13 perform13 other13 tasks13 instead
bull Reduced13 network13 traffic
Thank13 youQuesons
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-links-json-02txt
123
RFC 6690 (link-format) documents are somewhat foreign to many web app developerssect would prefer to have them in JSON format
There is no standard way to represent link-format documents in applicationssect but everyone knows how to handle JSON
Define a standard JSON translation for link-format
Itrsquos
not
rock
et
scien
ce
ltsensorsgtct=40title=Sensor Index ltsensorstempgtrt=temperature-cif=sensor ltsensorslightgtrt=light-luxif=sensor lthttpwwwexamplecomsensorst123gt anchor=sensorstemprel=describedby lttgtanchor=sensorstemprel=alternate [hrefsensorsct40titleSensor Index hrefsensorstemprttemperature-cifsensor hrefsensorslightrtlight-luxifsensor hrefhttpwwwexamplecomsensorst123 anchorsensorstempreldescribedby hreftanchorsensorstemprelalternate]
124
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-ipsec-for-coap-00txt
IPsec definitions for CoAP Mostly placeholder at this time Who has implementation experience with this
125
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-cross-reverse-convention-00txt
This draft has two lines of payload(based on a WGLC comment by Cullen Jennings)
coap12344567foobara=3
httpwwwproxycomwellknowncore-translate1234_4567foobara=3
Is that a useful convention to have
126
Insert CI slides here
127
128
0
5
10
15
20
25
30
35
40
10 20 30 40 50 60 70
good
put (
pps)
pps
Goodput vs pps (Econotags)
goodput
[Khattak preliminary]
Congestion Control
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-cocoa-00txt
ldquoadvancedrdquo cc (The draft is just a first shot) Others may have better ideas
129
Insert post-WGLC discussion slides here
130
Stop Continue Start
131
An Agile Retrospective
http6lowappnet coreIETF86 2013-03-12-13
Stop
132
Endless new CoAP optionssect instead use RESTful as much as possible
Move general security lifecycle out Looking at theoretical problems
http6lowappnet coreIETF86 2013-03-12-13
Continue
Interops Running code Look at real-world examples and deployments Solve their actual problems
sect Unilateral enhancements eg higher performance congestion control
sect Transports (SMS hellip)sect Make Web linking and Directories more and more usefulsect RESTful Design Paradigms for real-world problems
133
http6lowappnet coreIETF86 2013-03-12-13
Start
Further push into the (browser) web world (HTML5 browser security)
Specific supporting worksect SenMLsect URI work (dev URN hellip)sect Security Processes (next slide)
Spin outsect (We donrsquot really get to decide where this is done)
134
http6lowappnet coreIETF86 2013-03-12-13
Security
Integrate Application Network Group Keyingsect Tunnel-free setup
Donrsquot redo what has been done alreadysect ZigBee IP is finesect But what about other scenarios
Simple REST interfaces for working with keying materials and authorizationsect Start with defining objectives
Object Security for Constrained Nodes135
Re-chartering CoREWhat do we want to do now that wersquore grown up
Zach ShelbyCoRE WG IETF-86 Orlando
What is the scope
bull So we have a protocol and Web Linking what next
bull Keep with what we know besthellip1 Enhancements around CoAP2 New transports for CoAP3 New representations for Web Links4 General application layer solutions
CoRE WG IETF-86 Orlando 2
Enhancements around CoAP
bull Advanced congestion control
CoRE WG IETF-86 Orlando 3
New Transports for CoAP
bull Infrastructure for CoAP over foondash httptoolsietforgiddraft-silverajan-core-
coap-alternative-transports-01txtbull CoAP over SMS
ndash httptoolsietforgiddraft-becker-core-coap-sms-gprs-03txt
ndash OMA Lightweightbull CoAP over TCP
ndash httptoolsietforgiddraft-li-core-coap-payload-length-option-01txt
CoRE WG IETF-86 Orlando 4
New support for Web Links
bull JSON Web Linksndash httptoolsietforgiddraft-bormann-core-links-
json-02txt
2332010 CoRE WG IETF-77 Anaheim 5
General application layer solutions
bull Resource Directoryndash httptoolsietforgiddraft-shelby-core-
resource-directory-05txtndash OMA Lightweight
2332010 CoRE WG IETF-77 Anaheim 6
Changes from draft-01 to draft-03 (2)
I Added reference to bormann-coap-misc for other SMSencoding Section 71
I Updated requirements on Uri-Host and Uri-Port forcoap+tel Section 10
I Added security considerations Transport and ObjectSecurity Section 15
I Chose CoAP option numbers and updated the optionnumber table to meet draft-ietf-core-coap-10 Table 1
I Added an IANA registration for the URI scheme coap+telSection 162
4 10
Feedback Split coap+tel into coap+smsand coap+ussd
I How else to differ the various transports in the URII Or is the transport to use decided by the implementationI See alsodraft-silverajan-core-coap-alternative-transports-01
5 10
Feedback Response-To-Scheme option
I Should there be a Response-To-Scheme optionadditionally to Response-To-Uri-Host andResponse-To-Uri-Path
I So that a CoAP end-point which receives a request by CoAPover non-IP transport can be instructed to also use thenon-IP transport for the response
I This would imply to add aResponse-To-Telephone-Subscriber and more options forother transports that have other URI schemes than coapand coaps
6 10
Feedback Selection of Transport by Client
I When a server is reachable by various transports howdoes a client decide which transport to use
I Client-side application congurationI Leave it to a proxy which uses cellular network lookupfunctions
7 10
Feedback Potential Threats
I Trigger expensive short messagesI Redirect trac to other addressesI More threats
I Are the security measures in the draft adequateI Whitelisting on serverI Relying on cellular network security (dedicated M2M APNs)I Object security on CoAP payload
8 10
Feedback Message Exchanges
I Figures 11-18 show possible message exchanges whenclient and server have two addresses
I With NON Not using CoAP retransmission capabilityI ACK on different transportI Additional (costly) message on Transport AI Request with Content
I Which ones are allowedI Which ones are meaningful
9 10
Next steps
I Rene Uri schemeI Response-To-Scheme optionI Selection of Message ExchangeI Rene Proxying
10 10
CoAP13 Communicaon13 with13 Alternave13 Transports
Bill Silverajan and Teemu SavolainenCore WG IETF 86 Orlando
031113
Objecves13 (In13 Scope)
bull Unambiguous13 representaon13 of13 transport13 to13 be13 used13 by13 CoAP
bull Details13 how13 the13 transport13 can13 carry13 CoAP13 packet
bull Focus13 is13 on13 what13 CoAP13 communicaons13 requirements13 are
bull Allow13 CoAP13 mechanisms13 to13 exploit13 cross-shy‐layer13 opmisaons
51
031113
Non13 Goals13 (Not13 in13 scope)
bull Applicaon-shy‐level13 QoS13 requirementsbull Real-shy‐me13 constraintsbull Ordering13 reliability13 congeson13 controlbull Applicaon13 and13 network13 adaptaonbull Mobility13 and13 readdressing13 supportbull Network13 protocol13 (eg13 IPsec)13 configuraon
52
031113
Use13 Cases
bull NAT13 and13 Firewall13 traversal13 with13 TCPbull Delay13 Tolerant13 Networkingbull Non-shy‐IP13 Low13 Energy13 Protocols
53
031113
Related13 Work
bull OMA13 Lightweight13 M2M13 Protocolbull CoAP13 over13 SMSGPRSUSSD
54
031113
What13 does13 the13 work13 entail
bull The13 ability13 to13 specify13 end13 point13 idenfiers13 and13 URIs13 to13 reflect13 which13 transport13 CoAP13 can13 use
bull The13 ability13 to13 register13 to13 resource13 directories13 resource13 types13 reflecng13 types13 of13 transport13 available
bull Ability13 for13 mul-shy‐transport13 nodes13 to13 select13 transport13 to13 use13 without13 significant13 alteraon13 to13 CoAP13 packet13 structure
55
031113
Points13 to13 consider
bull Requirements13 for13 transport13 layer13 protocol13 to13 carry13 CoAP13 packets
bull Representaon13 of13 URI13 scheme13 for13 generic13 transport13 protocols
bull Opon13 extensions13 for13 CoAP13 to13 express13 available13 transports
bull Mapping13 and13 message13 sizebull Security13 consideraons
56
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
URI13 =13 scheme13 13 13 authority13 path-shy‐abempty13 [13 query13 ]
bull Within13 the13 scheme13 namebull In13 the13 URI13 pathbull As13 a13 query13 component
57
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
bull Within13 the13 scheme13 namendash coap+tel+15105550101well-shy‐knowncorendash coap+tcpexamplecom5683temperaturendash coap+blel2cap[1234567890AB]4pulse
bull Easy13 URI13 parsing13 for13 transport13 type13 and13 idenfier
bull Each13 new13 scheme13 name13 requires13 IANA13 registraon
58
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
bull In13 the13 URI13 pathndash coaphostexamplecomtransport=tcpwell-shy‐knowncorert=core-shy‐rd
bull Easy13 adopon13 of13 new13 (and13 experimental)13 CoAP13 transports13 without13 IANA13 registraon
bull Caveat13 Uri-shy‐Path13 opon13 is13 a13 Crical13 CoAP13 opon13 see13 secon13 54113 of13 I-shy‐Diep-shy‐core-shy‐coap
59
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
bull As13 a13 URI13 query13 componentndash coaphostexamplecomwell-shy‐knowncorert=core-shy‐rdq=tcp
bull Also13 easy13 to13 adopt13 new13 (and13 experimental)13 CoAP13 transports13 without13 IANA13 registraon
bull Caveat13 Uri-shy‐Query13 opon13 is13 a13 Crical13 CoAP13 opon13 see13 secon13 54113 of13 I-shy‐Diep-shy‐core-shy‐coap
60
031113
URI13 Representaons13 for13 CoAPNon13 standard13 ways
bull Transport13 in13 the13 URI13 authority13 componentndash coaphost[port][transport]13 instead13 of13 coaphost[port]
bull Transport13 as13 a13 service13 URLndash servicecoaptcphostexamplecomwell-shy‐knowncorert=core-shy‐rd
bull Above13 two13 ways13 break13 exisng13 compability13 (although13 both13 are13 based13 on13 valid13 IANA13 URI13 registraons)
61
031113
URI13 Representaons13 for13 CoAPMiscellaneous13 Consideraons
bull Ensure13 that13 transport13 is13 defined13 unambiguously13 (eg13 L2CAP13 used13 by13 both13 BLE13 and13 standard13 Bluetooth13 so13 avoid13 rdquocoap+l2caprdquo13 or13 rdquotransport=l2caprdquo13 or13 rdquoq=l2caprdquondash Can13 be13 done13 as13 WG13 consensusndash Namespace13 approach13 eg13 rdquocoap+blel2caprdquo13 or13 rdquoq=blel2caprdquo
bull Allow13 end-shy‐points13 to13 use13 CoAP13 Resource13 Directory13 to13 register13 alternave13 transports13 and13 idenfiers13 and13 provide13 periodic13 updatesndash Register13 rdquocore-shy‐transportrdquo13 resource13 type
62
031113
Transport13 Consideraons
bull Uniqueness13 of13 end-shy‐point13 idenficaonbull Communicaon13 support13 Unidireconal13 Bidireconal13 1N13 (broadcast13 mulcast13 anycast)13 messaging
bull Binary13 encoding13 Network13 byte13 orderingbull MTU13 correlaon13 with13 CoAP13 PDU13 sizebull Transport13 latency
63
031113
Security13 Consideraons
bull Drar13 does13 not13 introduce13 new13 security13 requirements13 by13 itself
bull There13 may13 be13 privacy13 issues13 if13 nodes13 use13 telephone13 numbers13 or13 MAC13 addresses13 as13 public13 end13 point13 idenfiers
64
Akbar Rahman
IETF 86 March 2013 httpwwwietforgiddraft-rahman-core-sleepy-02txt
Enhanced Sleepy Node Support for CoAP
Introduction
It is expected that in CoAP networks there will be a certain portion of devices that are sleepy and which may occasionally go into a sleep mode (ie go into a low power state to conserve power) and subsequently have reduced CoAP protocol communication ability
This I-D proposes a minimal and efficient mechanism building on the Resource Directory concept (which will be integrated into a CoAP Proxy) to enhance sleepy node support in CoAP networks
Main Question from IETF-85 (Atlanta)
What performance benefit does the proposed Sleepy Node support solution give in a network that already has standard CoAP caching enabled
Sleepy Node Performance Analysis
Experimental Network
1-5 clients
Both Sleepy and Non-
Sleepy servers
Sleepy Node Performance Analysis Network Setup
CoAPSleepyServer(s)
CoAPSleepAwareReverseProxy
CoAP
Client(s)
Request
Response
Sleep9AwareCoREResourceDirectoryCapability
PublishedSleepParameters
Sleep9AwareCoAPStoreandForwardCapability Response
Request
SleepAwareCoAP503ResponseCapability
CoAPCachingCapability
bull Server supports publishing sleep parameters to proxy bull Eg Irsquom going to be asleep for X seconds
bull Proxy supports sleep-awareness capabilities bull Proxy also supports caching capability based off of maxAge bull Protocol flow similar to approach of Figure 1 (Synchronous RD Based Sleep
Tracking) of I-D
Proxy capabilities can be selectively enableddisabled
Proxy ndash Server Interface
Client ndash Proxy Interface
CoAP Sleep-Aware Reverse Proxy Features CoRE Sleep-aware Resource Directory
Support storing published sleep parameters from CoAP servers sleepState (AWAKE ASLEEP) sleepDuration
Sleep-aware CoAP 503 Response Capability If CoAP request to a sleeping server is received proxy returns a
lsquo503 Retry-Afterrsquo response to client 503 contains a timestamp indicating when the sever will wake back up
(timestamp delivered in CoAP maxAge option) Sleep-aware CoAP Store-and-Forward Capability
If CoAP request to a sleeping server is received proxy stores request until server wakes up and then forwards it
Caching capability Cache GET responses from server if maxAge option is present
(this is not a sleep aware feature)
Goals of Performance Analysis
For networks having sleepy servers provide measurements to quantify the impact that CoAP sleep-awareness capabilities can have
See if sleep-awareness capabilities can
provide additional benefits even when CoAP caching is used
Overview of Performance Analysis Performed The analysis was broken up into a set of test scenarios Each test scenario used a different combination of the following
variables Client issued GET requests Server was configured as a sleepy or non-sleepy server Proxy caching of GET responses was enabled or disabled Proxy sleep-aware 503 response capability was enabled or disabled Proxy store-and-forward capability was enabled or disabled maxAge in GET responses ndash Two values were tested 60sec and 5sec of Clients ndash Two values were used ndash 1 client and 5 clients
For comparison purposes the following were held constant across all test scenarios Client issued a fixed number of requests (100) across all test scenarios Client used a delay between each GET request (35sec) to better exercise
proxyrsquos caching and sleep-awareness capabilities For sleepy server test scenarios the server slept 60 sec awake for 3 sec
Format of Results The following results were collected for each
test scenario
Breakdown of the and types of transactions occurring between clientproxyserver
ldquoGETrdquo ndash Test Scenario Results
GET ndash Description of Test Scenarios
TestScenarios-GET
Scenario
CoAPSleepyServerSe7ngs CoAPSleepAwareReverseProxySe7ngs CoAPClientSe7ngs
SleepDuragton(sec)
AwakeDuragton(sec)
maxAge(sec) Caching SleepAwareSAF+
503NumberofClients
NumberofGETs
DelayBetweenClient
Requests(sec)
1a 0 Always 60 Enabled Disabled 1 100 35
1b 60 3 60 Enabled Disabled 1 100 35
1c 60 3 60 Enabled Enabled 1 100 35
2a 0 Always 60 Enabled Disabled 5 100 35
2b 60 3 60 Enabled Disabled 5 100 35
2c 60 3 60 Enabled Enabled 5 100 35
3a 0 Always 5 Enabled Disabled 5 100 35
3b 60 3 5 Enabled Disabled 5 100 35
3c 60 3 5 Enabled Enabled 5 100 35
ldquoGETrdquo ndash Test Scenario 1 Results
maxAge = 60 and 1 Client
GET ndash Scenario 1 ClientProxy Interface Transaction Mix
Scenarios 1a - Non-Sleepy Server Caching Proxy maxAge = 60sec 1b- Sleepy Server Caching Proxy maxAge = 60sec 1c - Sleepy Server Sleep Aware Proxy maxAge = 60sec
Sleep Aware Proxy has better performance for sleepy servers
0
100
200
300
400
500
600
700
1a 1b 1c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
GET ndash Scenario 1 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
Scenarios 1a - Non-Sleepy Server Caching Proxy maxAge = 60sec 1b- Sleepy Server Caching Proxy maxAge = 60sec 1c - Sleepy Server Sleep Aware Proxy maxAge = 60sec
0
100
200
300
400
500
600
700
800
1a 1b 1c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
ldquoGETrdquo ndash Test Scenario 2 Results
maxAge = 60 and 5 Clients
GET ndash Scenario 2 ClientProxy Interface Transaction Mix
Sleep Aware Proxy has slightly better performance for sleepy servers
0
200
400
600
800
1000
1200
1400
2a 2b 2c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
Scenarios 2a - Non-Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2b- Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2c - Sleepy Server Sleep Aware Proxy maxAge = 60sec 5 Clients
See ldquoExperimental Artifactsrdquo Note 1
GET ndash Scenario 2 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has slightly better performance for sleepy servers
0
50
100
150
200
250
300
350
400
2a 2b 2c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
Scenarios 2a - Non-Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2b- Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2c - Sleepy Server Sleep Aware Proxy maxAge = 60sec 5 Clients
See ldquoExperimental Artifactsrdquo Note 2
Experimental Artifacts Note 1
Currently in the experiment the sleep aware proxy checks the cached state of a resource before putting a request into its Store-and-forward queue while a server is sleeping Once in the queue the proxy unconditionally forwards the queued requests to the server once it wakes up This is not the most efficient setup and can easily be improved If the proxy instead checks its cache again before forwarding each queued request it may not need to forward the request to the server For example if there are two queued GET requests in the proxyrsquos queue that address the same resource Only the first request needs to be sent to the server the second request can use the cached response from the first request
Note 2 Currently in the experiment the sleepy server sends a sleepState PUT request to the
proxy each time it goes to sleep This is not the most efficient setup and can easily be improved For example if the server assumes that the proxy can keep track of its ONOFF cycles with its internal timers (eg as per Fig 1 of I-D) then the number of messages from the sleepy server dramatically goes down
ldquoGETrdquo ndash Test Scenario 3 Results
maxAge = 5 and 5 Clients
GET ndash Scenario 3 ClientProxy Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
Scenarios 3a - Non-Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3b- Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3c - Sleepy Server Sleep Aware Proxy maxAge = 5sec 5 Clients
0
500
1000
1500
2000
2500
3000
3500
4000
4500
5000
3a 3b 3c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
GET ndash Scenario 3 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
0
1000
2000
3000
4000
5000
6000
7000
3a 3b 3c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
Scenarios 3a - Non-Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3b- Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3c - Sleepy Server Sleep Aware Proxy maxAge = 5sec 5 Clients
Conclusions
Conclusions These results show that sleep-aware CoAP
proxy features can significantly optimize communication with sleepy servers in most scenarios
These results also show that sleep-
awareness capabilities can provide additional benefits above and beyond CoAP caching in most scenarios
Backup
Current CoAP Support of Sleepy Node (12)
CoAP proxies can use a previously cached response to service a new GET request for a sleepy origin server (as in HTTP) But if no valid cache then proxy has to attempt to
retrieve and may fail if origin server is sleeping [I-Dietf-core-coap]
Clients can discover list of resources from RD (GET rd-lookuphellip) for sleepy servers But attempt to GET resource from sleepy origin server
may fail if origin server is sleeping [IDietf-core-link-format amp IDshelby-core-resource-
directory]
Current CoAP Support of Sleepy Node (22)
Lower layer support for sleepy nodes in most wireless technologies (eg WiFi ZigBee) But limited to MAC packet scheduling for sleepy nodes
and not aware of specific needs of IP applications (like CoAP)
Proposal ndash RD Based Sleep Tracking (14)
The current CoAP approach to support sleepy nodes can be significantly improved by introducing RD based mechanisms for a CoAP client to determine whether A targeted resource is located on a sleepy server A sleepy server is currently in sleep mode or not
There is any associated caching Proxy (possibly the RD itself) for a sleepy server
Proposal ndash RD Based Sleep Tracking (24)
We define the following new RD attributes to characterize the properties of a sleepy node SleepState - Indicates whether the node is currently in
sleep mode or not (ie Sleeping or Awake) SleepDuration - Indicates the maximum duration of time
that the node stays in sleep mode TimeSleeping - Indicates the length of time the node
has been sleeping (ie if Sleep State = Sleeping) NextSleep - Indicates the next time the node will go to
sleep (ie if Sleep State = Awake)
CachingProxy ndash Indicates the caching proxy of the sleepy node (ie the RD itself or another node)
Proposal ndash RD Based Sleep Tracking (34)
These attributes are all server (node) level and are new parameters added to the RD URI Template Variables
Finally we also define a new lookup-type (ss) for the RD lookup interface specified in [I-Dshelby-core-resource-directory] This new lookup-type supports looking up the
ldquoSleepStaterdquo (ss) of a specified end-point
Proposal ndash RD Based Sleep Tracking (44)
The three time based parameters (SleepDuration TimeSleeping NextSleep) can be based on either an absolute network time (for a time synchronized network) or a relative local time (measured at the local node)
Following the approach of [I-Dietf-core-link-format] and [I-Dshelby-core-resource-directory] sleep parameters for sleepy servers can be stored by the server in the RD and accessed by all interested clients
Examples of using these parameters in a synchronous or asynchronous manner are shown in the I-D
http6lowappnet coreIETF86 2013-03-12-13
We assume people have read the drafts
Meetings serve to advance difficult issues by making good use of face-to-face communications
Note Well Be aware of the IPR principles according to RFC 3979 and its updates
uumlBlue sheetsuumlScribe(s)
96
drar-shy‐iep-shy‐core-shy‐coapsubmiqed13 to13 IESG
2013-shy‐03-shy‐13
97
OMA Lightweight M2M Overview(A new standard using lots of IETF specs including DTLS
CoAP Block Observe Resource Directory SenMLhellip)
Zach ShelbyCoRE WG IETF-86 Orlando
OMA Lightweight M2Mbull Open Mobile Alliance is well known for Device Management (DM)bull OMA Lightweight M2M is a new standard from the alliance
ndash Focused on constrained Cellular and sensor network M2M devicesndash Driven by leading operators and vendors
bull Scopendash Interfaces protocol amp security between Device and Serverndash Object and Resource modelndash Bootstrap Device Access Control Connectivity and Firmware Objects
bull Draft Specifications are availablendash httpmemberopenmobileallianceorgftpPublic_documentsDM
LightweightM2MPermanent_documentsOMA-TS-LightweightM2M-V1_0_0-20130301-Dzip
bull Timelinendash Requirements and Architecture completed 3Q2012ndash Spec ready for Consistency Review 2Q2013ndash Candidate Approval expected 3Q2013
2 CoRE WG IETF-86 Orlando
Architecture
3
Scope of LWM2M
CoRE WG IETF-86 Orlando
Object Model
bull A Client has one or more Object Instancesbull An Object is a collection of Resourcesbull A Resource is an atomic piece of information
ndash Read Written or Executed
bull Resources can have multiple instancesbull Objects and Resources are identified by a
16-bit Integer Instances by an 8-bit Integerbull ObjectsResources are accessed with
simple URIs Object IDObject InstanceResource ID
eg 1213
4 CoRE WG IETF-86 Orlando
CoRE WG IETF-86 Orlando
CoRE Resource Directory
draft-shelby-core-resource-directory-05
Z Shelby C Bormann S Krco
Backgroundbull Not a new concept
ndash think web search engine or any link directorybull Defines the interfaces to a Resource Directorybull Based on Web Linking framework and the CoRE Link Formatbull Generic REST design for use over HTTP and CoAPbull Used by OMA Lightweight M2Mbull Has already been deployed
ndash In traffic monitoring systemsndash In street lighting systemsndash For vehicular asset trackingndash By a major Cellular M2M operator
Changes since -04
bull Restricted Update to parameter updatesbull Added pagination support for the Lookup interfacebull Changed rt= to et= for the registration amp update
interfacebull Added group support
Group Management
bull RD now includes group management featuresbull New Group Function Set
ndash Register a groupbull Group name domain multicast address endpoint members
ndash Remove a groupbull Group lookup using the Lookup Function Set
ndash List registered groupsndash Find the members of a groupndash Find groups with certain endpoints or resources
Registering a Group
EP RD
| |
| - POST rd-groupgp=lights ltgtep=node1 --gt |
| |
| |
| lt---- 201 Created Location rd-group12 ---- |
| |
Req POST coaprdexamplecomrd-groupgp=lights
Payload
ltgtep=node1
ltgtep=node2
Res 201 Created
Location rd-group12
Looking up Group Members
Client RD
| |
| ----- GET rd-lookupepgp=lights1 ----------------------gt |
| |
| |
| lt-- 205 Content ltrdgtd=domain1ltrdgtd=domain2 --------- |
| |
Req GET rd-lookupepgp=lights1
Res 205 Content
ltcoaphostportgtep=node1
ltcoaphostportgtep=node2rdquo
Things for the futurebull Support for JSON representation of Web Links
ndash httptoolsietforgiddraft-bormann-core-links-json-02txtbull Registry for RD registration query parameters
ndash Already OMA Lightweight has defined some new onesbull More examples
Group 3 ldquonew workrdquo(continued)
109
drar-shy‐greevenbosch-shy‐core-shy‐profile-shy‐descripon-shy‐01Bert13 GreevenboschJeroen13 Hoebeke
Isam13 IshaqFloris13 Van13 den13 Abeele
Descripon
bull JSON13 format13 for13 signalling13 the13 servers13 capabilies
bull Signalling13 of13 supported13 opons13 media13 types13 and13 block13 sizendash Other13 items13 can13 be13 added
bull Filtering13 on13 specific13 fields13 through13 URI-shy‐Querybull Link13 hqpdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐profile-shy‐descripon
well-shy‐knownprofile
bull To13 acquire13 profile13 data13 of13 resources13 on13 a13 parcular13 service13 the13 well-shy‐knownprofile13 URI-shy‐path13 is13 introduced
bull For13 example13 to13 get13 all13 informaon13 from13 sensors13 served13 by13 wwwexampleorg13 we13 can13 do13 a13 GET13 to13 coapwwwexampleorgwell-shy‐knownprofile
bull Filtering13 on13 parcular13 resources13 is13 done13 through13 URI-shy‐Queries
Format
bull Currently13 the13 following13 fields13 are13 definedndash ldquopathrdquo13 contains13 the13 URI-shy‐path13 associated13 with13 a13 resource
ndash ldquooprdquo13 a13 numerical13 list13 of13 supported13 opon13 numbers
ndash ldquocfrdquo13 a13 numerical13 list13 of13 supported13 content-shy‐format13 numbers
ndash ldquob1srdquo13 ldquob2srdquo13 supported13 block13 sizes13 for13 Block113 and13 Block213 respecvely
Examplebull On13 the13 right13 is13 an13 example13 of13 a13 camera13 sensor13 at13 coapwwwexampleorgcam13 that13 supports13 the13 Uri-shy‐Host13 (3)13 ETag13 (4)13 Uri-shy‐Port13 (7)13 Uri-shy‐Path13 (11)13 Content-shy‐Format13 (12)13 Token13 (19)13 Block213 (23)13 and13 Proxy-shy‐Uri13 (35)13 opons
bull The13 supported13 content13 formats13 are13 textplain13 (0)13 applicaon13 link-shy‐format13 (40)13 and13 applicaonjson13 (50)
bull The13 supported13 Block213 can13 use13 25613 or13 51213 byte13 blocks
Req13 GET13 coapwwwexampleorgwell-shy‐knownprofile13 Res13 20513 Content13 (applicationjson)13 13 13 13 profile13 13 13 13 13 13 13 13 pathcam13 13 13 13 op[3471112192335]13 13 13 13 13 cf[04050]13 13 13 13 13 b2s[45]13 13 13 13
Filtering13 through13 use13 of13 URI-shy‐Query
bull Filtering13 can13 be13 done13 through13 the13 URI-shy‐Querybull Query13 format13 N=V
ndash N13 is13 a13 profile13 fieldndash V13 is13 the13 desired13 value
bull Examplesndash To13 find13 resources13 that13 support13 content13 format13 ldquoapplicaonjsonrdquo
13 GET13 wwwexampleorgwell-shy‐knownprofilecf=50ndash To13 get13 informaon13 about13 the13 camera
13 GET13 wwwexampleorgwell-shy‐knownprofilepath=cam
Open13 issues
bull Which13 other13 profile13 data13 needs13 signallingndash Content-shy‐type13 for13 different13 methods
bull Fix13 the13 order13 in13 which13 the13 profile13 fields13 must13 appearndash Non-shy‐fixed13 order13 easier13 extensible
bull Inheritance13 of13 a13 profile13 descriponbull Extend13 usage13 to13 signal13 the13 client13 profilebull Integraon13 with13 link13 format
Thank13 youQuesons
drar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval-shy‐00
Bert13 Greevenbosch
Descripon
bull The13 ldquoMinimumRequestInterval13 opon13 can13 be13 used13 to13 indicate13 the13 minimum13 me13 between13 two13 requests13 in13 a13 transacon
bull Originally13 intended13 for13 Block13 but13 also13 usable13 for13 other13 transaconsndash Example13 browsing13 a13 server
bull The13 goal13 is13 to13 reduce13 the13 server13 load13 and13 network13 traffic
bull Link13 hqpsdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval
Usage
bull The13 client13 keeps13 the13 server13 informed13 about13 its13 request13 speed13 through13 inclusion13 of13 the13 ldquoMinimumRequestIntervalrdquo13 opon
bull In13 responses13 the13 server13 fixes13 the13 minimum13 request13 interval13 through13 the13 same13 opon
bull The13 client13 obeys13 the13 speed13 indicated13 by13 the13 server
bull The13 client13 can13 send13 slower13 but13 not13 faster
Advantages
bull The13 server13 has13 means13 to13 limit13 the13 amount13 of13 incoming13 traffic
bull The13 server13 can13 prevent13 to13 become13 overloaded13 with13 too13 many13 tasks
bull The13 server13 does13 not13 need13 arficially13 slow13 down13 the13 client13 by13 sending13 late13 ACKsndash No13 need13 to13 keep13 track13 of13 delayed13 ACKsndash The13 server13 can13 perform13 other13 tasks13 instead
bull Reduced13 network13 traffic
Thank13 youQuesons
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-links-json-02txt
123
RFC 6690 (link-format) documents are somewhat foreign to many web app developerssect would prefer to have them in JSON format
There is no standard way to represent link-format documents in applicationssect but everyone knows how to handle JSON
Define a standard JSON translation for link-format
Itrsquos
not
rock
et
scien
ce
ltsensorsgtct=40title=Sensor Index ltsensorstempgtrt=temperature-cif=sensor ltsensorslightgtrt=light-luxif=sensor lthttpwwwexamplecomsensorst123gt anchor=sensorstemprel=describedby lttgtanchor=sensorstemprel=alternate [hrefsensorsct40titleSensor Index hrefsensorstemprttemperature-cifsensor hrefsensorslightrtlight-luxifsensor hrefhttpwwwexamplecomsensorst123 anchorsensorstempreldescribedby hreftanchorsensorstemprelalternate]
124
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-ipsec-for-coap-00txt
IPsec definitions for CoAP Mostly placeholder at this time Who has implementation experience with this
125
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-cross-reverse-convention-00txt
This draft has two lines of payload(based on a WGLC comment by Cullen Jennings)
coap12344567foobara=3
httpwwwproxycomwellknowncore-translate1234_4567foobara=3
Is that a useful convention to have
126
Insert CI slides here
127
128
0
5
10
15
20
25
30
35
40
10 20 30 40 50 60 70
good
put (
pps)
pps
Goodput vs pps (Econotags)
goodput
[Khattak preliminary]
Congestion Control
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-cocoa-00txt
ldquoadvancedrdquo cc (The draft is just a first shot) Others may have better ideas
129
Insert post-WGLC discussion slides here
130
Stop Continue Start
131
An Agile Retrospective
http6lowappnet coreIETF86 2013-03-12-13
Stop
132
Endless new CoAP optionssect instead use RESTful as much as possible
Move general security lifecycle out Looking at theoretical problems
http6lowappnet coreIETF86 2013-03-12-13
Continue
Interops Running code Look at real-world examples and deployments Solve their actual problems
sect Unilateral enhancements eg higher performance congestion control
sect Transports (SMS hellip)sect Make Web linking and Directories more and more usefulsect RESTful Design Paradigms for real-world problems
133
http6lowappnet coreIETF86 2013-03-12-13
Start
Further push into the (browser) web world (HTML5 browser security)
Specific supporting worksect SenMLsect URI work (dev URN hellip)sect Security Processes (next slide)
Spin outsect (We donrsquot really get to decide where this is done)
134
http6lowappnet coreIETF86 2013-03-12-13
Security
Integrate Application Network Group Keyingsect Tunnel-free setup
Donrsquot redo what has been done alreadysect ZigBee IP is finesect But what about other scenarios
Simple REST interfaces for working with keying materials and authorizationsect Start with defining objectives
Object Security for Constrained Nodes135
Re-chartering CoREWhat do we want to do now that wersquore grown up
Zach ShelbyCoRE WG IETF-86 Orlando
What is the scope
bull So we have a protocol and Web Linking what next
bull Keep with what we know besthellip1 Enhancements around CoAP2 New transports for CoAP3 New representations for Web Links4 General application layer solutions
CoRE WG IETF-86 Orlando 2
Enhancements around CoAP
bull Advanced congestion control
CoRE WG IETF-86 Orlando 3
New Transports for CoAP
bull Infrastructure for CoAP over foondash httptoolsietforgiddraft-silverajan-core-
coap-alternative-transports-01txtbull CoAP over SMS
ndash httptoolsietforgiddraft-becker-core-coap-sms-gprs-03txt
ndash OMA Lightweightbull CoAP over TCP
ndash httptoolsietforgiddraft-li-core-coap-payload-length-option-01txt
CoRE WG IETF-86 Orlando 4
New support for Web Links
bull JSON Web Linksndash httptoolsietforgiddraft-bormann-core-links-
json-02txt
2332010 CoRE WG IETF-77 Anaheim 5
General application layer solutions
bull Resource Directoryndash httptoolsietforgiddraft-shelby-core-
resource-directory-05txtndash OMA Lightweight
2332010 CoRE WG IETF-77 Anaheim 6
Feedback Split coap+tel into coap+smsand coap+ussd
I How else to differ the various transports in the URII Or is the transport to use decided by the implementationI See alsodraft-silverajan-core-coap-alternative-transports-01
5 10
Feedback Response-To-Scheme option
I Should there be a Response-To-Scheme optionadditionally to Response-To-Uri-Host andResponse-To-Uri-Path
I So that a CoAP end-point which receives a request by CoAPover non-IP transport can be instructed to also use thenon-IP transport for the response
I This would imply to add aResponse-To-Telephone-Subscriber and more options forother transports that have other URI schemes than coapand coaps
6 10
Feedback Selection of Transport by Client
I When a server is reachable by various transports howdoes a client decide which transport to use
I Client-side application congurationI Leave it to a proxy which uses cellular network lookupfunctions
7 10
Feedback Potential Threats
I Trigger expensive short messagesI Redirect trac to other addressesI More threats
I Are the security measures in the draft adequateI Whitelisting on serverI Relying on cellular network security (dedicated M2M APNs)I Object security on CoAP payload
8 10
Feedback Message Exchanges
I Figures 11-18 show possible message exchanges whenclient and server have two addresses
I With NON Not using CoAP retransmission capabilityI ACK on different transportI Additional (costly) message on Transport AI Request with Content
I Which ones are allowedI Which ones are meaningful
9 10
Next steps
I Rene Uri schemeI Response-To-Scheme optionI Selection of Message ExchangeI Rene Proxying
10 10
CoAP13 Communicaon13 with13 Alternave13 Transports
Bill Silverajan and Teemu SavolainenCore WG IETF 86 Orlando
031113
Objecves13 (In13 Scope)
bull Unambiguous13 representaon13 of13 transport13 to13 be13 used13 by13 CoAP
bull Details13 how13 the13 transport13 can13 carry13 CoAP13 packet
bull Focus13 is13 on13 what13 CoAP13 communicaons13 requirements13 are
bull Allow13 CoAP13 mechanisms13 to13 exploit13 cross-shy‐layer13 opmisaons
51
031113
Non13 Goals13 (Not13 in13 scope)
bull Applicaon-shy‐level13 QoS13 requirementsbull Real-shy‐me13 constraintsbull Ordering13 reliability13 congeson13 controlbull Applicaon13 and13 network13 adaptaonbull Mobility13 and13 readdressing13 supportbull Network13 protocol13 (eg13 IPsec)13 configuraon
52
031113
Use13 Cases
bull NAT13 and13 Firewall13 traversal13 with13 TCPbull Delay13 Tolerant13 Networkingbull Non-shy‐IP13 Low13 Energy13 Protocols
53
031113
Related13 Work
bull OMA13 Lightweight13 M2M13 Protocolbull CoAP13 over13 SMSGPRSUSSD
54
031113
What13 does13 the13 work13 entail
bull The13 ability13 to13 specify13 end13 point13 idenfiers13 and13 URIs13 to13 reflect13 which13 transport13 CoAP13 can13 use
bull The13 ability13 to13 register13 to13 resource13 directories13 resource13 types13 reflecng13 types13 of13 transport13 available
bull Ability13 for13 mul-shy‐transport13 nodes13 to13 select13 transport13 to13 use13 without13 significant13 alteraon13 to13 CoAP13 packet13 structure
55
031113
Points13 to13 consider
bull Requirements13 for13 transport13 layer13 protocol13 to13 carry13 CoAP13 packets
bull Representaon13 of13 URI13 scheme13 for13 generic13 transport13 protocols
bull Opon13 extensions13 for13 CoAP13 to13 express13 available13 transports
bull Mapping13 and13 message13 sizebull Security13 consideraons
56
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
URI13 =13 scheme13 13 13 authority13 path-shy‐abempty13 [13 query13 ]
bull Within13 the13 scheme13 namebull In13 the13 URI13 pathbull As13 a13 query13 component
57
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
bull Within13 the13 scheme13 namendash coap+tel+15105550101well-shy‐knowncorendash coap+tcpexamplecom5683temperaturendash coap+blel2cap[1234567890AB]4pulse
bull Easy13 URI13 parsing13 for13 transport13 type13 and13 idenfier
bull Each13 new13 scheme13 name13 requires13 IANA13 registraon
58
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
bull In13 the13 URI13 pathndash coaphostexamplecomtransport=tcpwell-shy‐knowncorert=core-shy‐rd
bull Easy13 adopon13 of13 new13 (and13 experimental)13 CoAP13 transports13 without13 IANA13 registraon
bull Caveat13 Uri-shy‐Path13 opon13 is13 a13 Crical13 CoAP13 opon13 see13 secon13 54113 of13 I-shy‐Diep-shy‐core-shy‐coap
59
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
bull As13 a13 URI13 query13 componentndash coaphostexamplecomwell-shy‐knowncorert=core-shy‐rdq=tcp
bull Also13 easy13 to13 adopt13 new13 (and13 experimental)13 CoAP13 transports13 without13 IANA13 registraon
bull Caveat13 Uri-shy‐Query13 opon13 is13 a13 Crical13 CoAP13 opon13 see13 secon13 54113 of13 I-shy‐Diep-shy‐core-shy‐coap
60
031113
URI13 Representaons13 for13 CoAPNon13 standard13 ways
bull Transport13 in13 the13 URI13 authority13 componentndash coaphost[port][transport]13 instead13 of13 coaphost[port]
bull Transport13 as13 a13 service13 URLndash servicecoaptcphostexamplecomwell-shy‐knowncorert=core-shy‐rd
bull Above13 two13 ways13 break13 exisng13 compability13 (although13 both13 are13 based13 on13 valid13 IANA13 URI13 registraons)
61
031113
URI13 Representaons13 for13 CoAPMiscellaneous13 Consideraons
bull Ensure13 that13 transport13 is13 defined13 unambiguously13 (eg13 L2CAP13 used13 by13 both13 BLE13 and13 standard13 Bluetooth13 so13 avoid13 rdquocoap+l2caprdquo13 or13 rdquotransport=l2caprdquo13 or13 rdquoq=l2caprdquondash Can13 be13 done13 as13 WG13 consensusndash Namespace13 approach13 eg13 rdquocoap+blel2caprdquo13 or13 rdquoq=blel2caprdquo
bull Allow13 end-shy‐points13 to13 use13 CoAP13 Resource13 Directory13 to13 register13 alternave13 transports13 and13 idenfiers13 and13 provide13 periodic13 updatesndash Register13 rdquocore-shy‐transportrdquo13 resource13 type
62
031113
Transport13 Consideraons
bull Uniqueness13 of13 end-shy‐point13 idenficaonbull Communicaon13 support13 Unidireconal13 Bidireconal13 1N13 (broadcast13 mulcast13 anycast)13 messaging
bull Binary13 encoding13 Network13 byte13 orderingbull MTU13 correlaon13 with13 CoAP13 PDU13 sizebull Transport13 latency
63
031113
Security13 Consideraons
bull Drar13 does13 not13 introduce13 new13 security13 requirements13 by13 itself
bull There13 may13 be13 privacy13 issues13 if13 nodes13 use13 telephone13 numbers13 or13 MAC13 addresses13 as13 public13 end13 point13 idenfiers
64
Akbar Rahman
IETF 86 March 2013 httpwwwietforgiddraft-rahman-core-sleepy-02txt
Enhanced Sleepy Node Support for CoAP
Introduction
It is expected that in CoAP networks there will be a certain portion of devices that are sleepy and which may occasionally go into a sleep mode (ie go into a low power state to conserve power) and subsequently have reduced CoAP protocol communication ability
This I-D proposes a minimal and efficient mechanism building on the Resource Directory concept (which will be integrated into a CoAP Proxy) to enhance sleepy node support in CoAP networks
Main Question from IETF-85 (Atlanta)
What performance benefit does the proposed Sleepy Node support solution give in a network that already has standard CoAP caching enabled
Sleepy Node Performance Analysis
Experimental Network
1-5 clients
Both Sleepy and Non-
Sleepy servers
Sleepy Node Performance Analysis Network Setup
CoAPSleepyServer(s)
CoAPSleepAwareReverseProxy
CoAP
Client(s)
Request
Response
Sleep9AwareCoREResourceDirectoryCapability
PublishedSleepParameters
Sleep9AwareCoAPStoreandForwardCapability Response
Request
SleepAwareCoAP503ResponseCapability
CoAPCachingCapability
bull Server supports publishing sleep parameters to proxy bull Eg Irsquom going to be asleep for X seconds
bull Proxy supports sleep-awareness capabilities bull Proxy also supports caching capability based off of maxAge bull Protocol flow similar to approach of Figure 1 (Synchronous RD Based Sleep
Tracking) of I-D
Proxy capabilities can be selectively enableddisabled
Proxy ndash Server Interface
Client ndash Proxy Interface
CoAP Sleep-Aware Reverse Proxy Features CoRE Sleep-aware Resource Directory
Support storing published sleep parameters from CoAP servers sleepState (AWAKE ASLEEP) sleepDuration
Sleep-aware CoAP 503 Response Capability If CoAP request to a sleeping server is received proxy returns a
lsquo503 Retry-Afterrsquo response to client 503 contains a timestamp indicating when the sever will wake back up
(timestamp delivered in CoAP maxAge option) Sleep-aware CoAP Store-and-Forward Capability
If CoAP request to a sleeping server is received proxy stores request until server wakes up and then forwards it
Caching capability Cache GET responses from server if maxAge option is present
(this is not a sleep aware feature)
Goals of Performance Analysis
For networks having sleepy servers provide measurements to quantify the impact that CoAP sleep-awareness capabilities can have
See if sleep-awareness capabilities can
provide additional benefits even when CoAP caching is used
Overview of Performance Analysis Performed The analysis was broken up into a set of test scenarios Each test scenario used a different combination of the following
variables Client issued GET requests Server was configured as a sleepy or non-sleepy server Proxy caching of GET responses was enabled or disabled Proxy sleep-aware 503 response capability was enabled or disabled Proxy store-and-forward capability was enabled or disabled maxAge in GET responses ndash Two values were tested 60sec and 5sec of Clients ndash Two values were used ndash 1 client and 5 clients
For comparison purposes the following were held constant across all test scenarios Client issued a fixed number of requests (100) across all test scenarios Client used a delay between each GET request (35sec) to better exercise
proxyrsquos caching and sleep-awareness capabilities For sleepy server test scenarios the server slept 60 sec awake for 3 sec
Format of Results The following results were collected for each
test scenario
Breakdown of the and types of transactions occurring between clientproxyserver
ldquoGETrdquo ndash Test Scenario Results
GET ndash Description of Test Scenarios
TestScenarios-GET
Scenario
CoAPSleepyServerSe7ngs CoAPSleepAwareReverseProxySe7ngs CoAPClientSe7ngs
SleepDuragton(sec)
AwakeDuragton(sec)
maxAge(sec) Caching SleepAwareSAF+
503NumberofClients
NumberofGETs
DelayBetweenClient
Requests(sec)
1a 0 Always 60 Enabled Disabled 1 100 35
1b 60 3 60 Enabled Disabled 1 100 35
1c 60 3 60 Enabled Enabled 1 100 35
2a 0 Always 60 Enabled Disabled 5 100 35
2b 60 3 60 Enabled Disabled 5 100 35
2c 60 3 60 Enabled Enabled 5 100 35
3a 0 Always 5 Enabled Disabled 5 100 35
3b 60 3 5 Enabled Disabled 5 100 35
3c 60 3 5 Enabled Enabled 5 100 35
ldquoGETrdquo ndash Test Scenario 1 Results
maxAge = 60 and 1 Client
GET ndash Scenario 1 ClientProxy Interface Transaction Mix
Scenarios 1a - Non-Sleepy Server Caching Proxy maxAge = 60sec 1b- Sleepy Server Caching Proxy maxAge = 60sec 1c - Sleepy Server Sleep Aware Proxy maxAge = 60sec
Sleep Aware Proxy has better performance for sleepy servers
0
100
200
300
400
500
600
700
1a 1b 1c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
GET ndash Scenario 1 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
Scenarios 1a - Non-Sleepy Server Caching Proxy maxAge = 60sec 1b- Sleepy Server Caching Proxy maxAge = 60sec 1c - Sleepy Server Sleep Aware Proxy maxAge = 60sec
0
100
200
300
400
500
600
700
800
1a 1b 1c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
ldquoGETrdquo ndash Test Scenario 2 Results
maxAge = 60 and 5 Clients
GET ndash Scenario 2 ClientProxy Interface Transaction Mix
Sleep Aware Proxy has slightly better performance for sleepy servers
0
200
400
600
800
1000
1200
1400
2a 2b 2c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
Scenarios 2a - Non-Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2b- Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2c - Sleepy Server Sleep Aware Proxy maxAge = 60sec 5 Clients
See ldquoExperimental Artifactsrdquo Note 1
GET ndash Scenario 2 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has slightly better performance for sleepy servers
0
50
100
150
200
250
300
350
400
2a 2b 2c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
Scenarios 2a - Non-Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2b- Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2c - Sleepy Server Sleep Aware Proxy maxAge = 60sec 5 Clients
See ldquoExperimental Artifactsrdquo Note 2
Experimental Artifacts Note 1
Currently in the experiment the sleep aware proxy checks the cached state of a resource before putting a request into its Store-and-forward queue while a server is sleeping Once in the queue the proxy unconditionally forwards the queued requests to the server once it wakes up This is not the most efficient setup and can easily be improved If the proxy instead checks its cache again before forwarding each queued request it may not need to forward the request to the server For example if there are two queued GET requests in the proxyrsquos queue that address the same resource Only the first request needs to be sent to the server the second request can use the cached response from the first request
Note 2 Currently in the experiment the sleepy server sends a sleepState PUT request to the
proxy each time it goes to sleep This is not the most efficient setup and can easily be improved For example if the server assumes that the proxy can keep track of its ONOFF cycles with its internal timers (eg as per Fig 1 of I-D) then the number of messages from the sleepy server dramatically goes down
ldquoGETrdquo ndash Test Scenario 3 Results
maxAge = 5 and 5 Clients
GET ndash Scenario 3 ClientProxy Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
Scenarios 3a - Non-Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3b- Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3c - Sleepy Server Sleep Aware Proxy maxAge = 5sec 5 Clients
0
500
1000
1500
2000
2500
3000
3500
4000
4500
5000
3a 3b 3c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
GET ndash Scenario 3 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
0
1000
2000
3000
4000
5000
6000
7000
3a 3b 3c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
Scenarios 3a - Non-Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3b- Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3c - Sleepy Server Sleep Aware Proxy maxAge = 5sec 5 Clients
Conclusions
Conclusions These results show that sleep-aware CoAP
proxy features can significantly optimize communication with sleepy servers in most scenarios
These results also show that sleep-
awareness capabilities can provide additional benefits above and beyond CoAP caching in most scenarios
Backup
Current CoAP Support of Sleepy Node (12)
CoAP proxies can use a previously cached response to service a new GET request for a sleepy origin server (as in HTTP) But if no valid cache then proxy has to attempt to
retrieve and may fail if origin server is sleeping [I-Dietf-core-coap]
Clients can discover list of resources from RD (GET rd-lookuphellip) for sleepy servers But attempt to GET resource from sleepy origin server
may fail if origin server is sleeping [IDietf-core-link-format amp IDshelby-core-resource-
directory]
Current CoAP Support of Sleepy Node (22)
Lower layer support for sleepy nodes in most wireless technologies (eg WiFi ZigBee) But limited to MAC packet scheduling for sleepy nodes
and not aware of specific needs of IP applications (like CoAP)
Proposal ndash RD Based Sleep Tracking (14)
The current CoAP approach to support sleepy nodes can be significantly improved by introducing RD based mechanisms for a CoAP client to determine whether A targeted resource is located on a sleepy server A sleepy server is currently in sleep mode or not
There is any associated caching Proxy (possibly the RD itself) for a sleepy server
Proposal ndash RD Based Sleep Tracking (24)
We define the following new RD attributes to characterize the properties of a sleepy node SleepState - Indicates whether the node is currently in
sleep mode or not (ie Sleeping or Awake) SleepDuration - Indicates the maximum duration of time
that the node stays in sleep mode TimeSleeping - Indicates the length of time the node
has been sleeping (ie if Sleep State = Sleeping) NextSleep - Indicates the next time the node will go to
sleep (ie if Sleep State = Awake)
CachingProxy ndash Indicates the caching proxy of the sleepy node (ie the RD itself or another node)
Proposal ndash RD Based Sleep Tracking (34)
These attributes are all server (node) level and are new parameters added to the RD URI Template Variables
Finally we also define a new lookup-type (ss) for the RD lookup interface specified in [I-Dshelby-core-resource-directory] This new lookup-type supports looking up the
ldquoSleepStaterdquo (ss) of a specified end-point
Proposal ndash RD Based Sleep Tracking (44)
The three time based parameters (SleepDuration TimeSleeping NextSleep) can be based on either an absolute network time (for a time synchronized network) or a relative local time (measured at the local node)
Following the approach of [I-Dietf-core-link-format] and [I-Dshelby-core-resource-directory] sleep parameters for sleepy servers can be stored by the server in the RD and accessed by all interested clients
Examples of using these parameters in a synchronous or asynchronous manner are shown in the I-D
http6lowappnet coreIETF86 2013-03-12-13
We assume people have read the drafts
Meetings serve to advance difficult issues by making good use of face-to-face communications
Note Well Be aware of the IPR principles according to RFC 3979 and its updates
uumlBlue sheetsuumlScribe(s)
96
drar-shy‐iep-shy‐core-shy‐coapsubmiqed13 to13 IESG
2013-shy‐03-shy‐13
97
OMA Lightweight M2M Overview(A new standard using lots of IETF specs including DTLS
CoAP Block Observe Resource Directory SenMLhellip)
Zach ShelbyCoRE WG IETF-86 Orlando
OMA Lightweight M2Mbull Open Mobile Alliance is well known for Device Management (DM)bull OMA Lightweight M2M is a new standard from the alliance
ndash Focused on constrained Cellular and sensor network M2M devicesndash Driven by leading operators and vendors
bull Scopendash Interfaces protocol amp security between Device and Serverndash Object and Resource modelndash Bootstrap Device Access Control Connectivity and Firmware Objects
bull Draft Specifications are availablendash httpmemberopenmobileallianceorgftpPublic_documentsDM
LightweightM2MPermanent_documentsOMA-TS-LightweightM2M-V1_0_0-20130301-Dzip
bull Timelinendash Requirements and Architecture completed 3Q2012ndash Spec ready for Consistency Review 2Q2013ndash Candidate Approval expected 3Q2013
2 CoRE WG IETF-86 Orlando
Architecture
3
Scope of LWM2M
CoRE WG IETF-86 Orlando
Object Model
bull A Client has one or more Object Instancesbull An Object is a collection of Resourcesbull A Resource is an atomic piece of information
ndash Read Written or Executed
bull Resources can have multiple instancesbull Objects and Resources are identified by a
16-bit Integer Instances by an 8-bit Integerbull ObjectsResources are accessed with
simple URIs Object IDObject InstanceResource ID
eg 1213
4 CoRE WG IETF-86 Orlando
CoRE WG IETF-86 Orlando
CoRE Resource Directory
draft-shelby-core-resource-directory-05
Z Shelby C Bormann S Krco
Backgroundbull Not a new concept
ndash think web search engine or any link directorybull Defines the interfaces to a Resource Directorybull Based on Web Linking framework and the CoRE Link Formatbull Generic REST design for use over HTTP and CoAPbull Used by OMA Lightweight M2Mbull Has already been deployed
ndash In traffic monitoring systemsndash In street lighting systemsndash For vehicular asset trackingndash By a major Cellular M2M operator
Changes since -04
bull Restricted Update to parameter updatesbull Added pagination support for the Lookup interfacebull Changed rt= to et= for the registration amp update
interfacebull Added group support
Group Management
bull RD now includes group management featuresbull New Group Function Set
ndash Register a groupbull Group name domain multicast address endpoint members
ndash Remove a groupbull Group lookup using the Lookup Function Set
ndash List registered groupsndash Find the members of a groupndash Find groups with certain endpoints or resources
Registering a Group
EP RD
| |
| - POST rd-groupgp=lights ltgtep=node1 --gt |
| |
| |
| lt---- 201 Created Location rd-group12 ---- |
| |
Req POST coaprdexamplecomrd-groupgp=lights
Payload
ltgtep=node1
ltgtep=node2
Res 201 Created
Location rd-group12
Looking up Group Members
Client RD
| |
| ----- GET rd-lookupepgp=lights1 ----------------------gt |
| |
| |
| lt-- 205 Content ltrdgtd=domain1ltrdgtd=domain2 --------- |
| |
Req GET rd-lookupepgp=lights1
Res 205 Content
ltcoaphostportgtep=node1
ltcoaphostportgtep=node2rdquo
Things for the futurebull Support for JSON representation of Web Links
ndash httptoolsietforgiddraft-bormann-core-links-json-02txtbull Registry for RD registration query parameters
ndash Already OMA Lightweight has defined some new onesbull More examples
Group 3 ldquonew workrdquo(continued)
109
drar-shy‐greevenbosch-shy‐core-shy‐profile-shy‐descripon-shy‐01Bert13 GreevenboschJeroen13 Hoebeke
Isam13 IshaqFloris13 Van13 den13 Abeele
Descripon
bull JSON13 format13 for13 signalling13 the13 servers13 capabilies
bull Signalling13 of13 supported13 opons13 media13 types13 and13 block13 sizendash Other13 items13 can13 be13 added
bull Filtering13 on13 specific13 fields13 through13 URI-shy‐Querybull Link13 hqpdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐profile-shy‐descripon
well-shy‐knownprofile
bull To13 acquire13 profile13 data13 of13 resources13 on13 a13 parcular13 service13 the13 well-shy‐knownprofile13 URI-shy‐path13 is13 introduced
bull For13 example13 to13 get13 all13 informaon13 from13 sensors13 served13 by13 wwwexampleorg13 we13 can13 do13 a13 GET13 to13 coapwwwexampleorgwell-shy‐knownprofile
bull Filtering13 on13 parcular13 resources13 is13 done13 through13 URI-shy‐Queries
Format
bull Currently13 the13 following13 fields13 are13 definedndash ldquopathrdquo13 contains13 the13 URI-shy‐path13 associated13 with13 a13 resource
ndash ldquooprdquo13 a13 numerical13 list13 of13 supported13 opon13 numbers
ndash ldquocfrdquo13 a13 numerical13 list13 of13 supported13 content-shy‐format13 numbers
ndash ldquob1srdquo13 ldquob2srdquo13 supported13 block13 sizes13 for13 Block113 and13 Block213 respecvely
Examplebull On13 the13 right13 is13 an13 example13 of13 a13 camera13 sensor13 at13 coapwwwexampleorgcam13 that13 supports13 the13 Uri-shy‐Host13 (3)13 ETag13 (4)13 Uri-shy‐Port13 (7)13 Uri-shy‐Path13 (11)13 Content-shy‐Format13 (12)13 Token13 (19)13 Block213 (23)13 and13 Proxy-shy‐Uri13 (35)13 opons
bull The13 supported13 content13 formats13 are13 textplain13 (0)13 applicaon13 link-shy‐format13 (40)13 and13 applicaonjson13 (50)
bull The13 supported13 Block213 can13 use13 25613 or13 51213 byte13 blocks
Req13 GET13 coapwwwexampleorgwell-shy‐knownprofile13 Res13 20513 Content13 (applicationjson)13 13 13 13 profile13 13 13 13 13 13 13 13 pathcam13 13 13 13 op[3471112192335]13 13 13 13 13 cf[04050]13 13 13 13 13 b2s[45]13 13 13 13
Filtering13 through13 use13 of13 URI-shy‐Query
bull Filtering13 can13 be13 done13 through13 the13 URI-shy‐Querybull Query13 format13 N=V
ndash N13 is13 a13 profile13 fieldndash V13 is13 the13 desired13 value
bull Examplesndash To13 find13 resources13 that13 support13 content13 format13 ldquoapplicaonjsonrdquo
13 GET13 wwwexampleorgwell-shy‐knownprofilecf=50ndash To13 get13 informaon13 about13 the13 camera
13 GET13 wwwexampleorgwell-shy‐knownprofilepath=cam
Open13 issues
bull Which13 other13 profile13 data13 needs13 signallingndash Content-shy‐type13 for13 different13 methods
bull Fix13 the13 order13 in13 which13 the13 profile13 fields13 must13 appearndash Non-shy‐fixed13 order13 easier13 extensible
bull Inheritance13 of13 a13 profile13 descriponbull Extend13 usage13 to13 signal13 the13 client13 profilebull Integraon13 with13 link13 format
Thank13 youQuesons
drar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval-shy‐00
Bert13 Greevenbosch
Descripon
bull The13 ldquoMinimumRequestInterval13 opon13 can13 be13 used13 to13 indicate13 the13 minimum13 me13 between13 two13 requests13 in13 a13 transacon
bull Originally13 intended13 for13 Block13 but13 also13 usable13 for13 other13 transaconsndash Example13 browsing13 a13 server
bull The13 goal13 is13 to13 reduce13 the13 server13 load13 and13 network13 traffic
bull Link13 hqpsdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval
Usage
bull The13 client13 keeps13 the13 server13 informed13 about13 its13 request13 speed13 through13 inclusion13 of13 the13 ldquoMinimumRequestIntervalrdquo13 opon
bull In13 responses13 the13 server13 fixes13 the13 minimum13 request13 interval13 through13 the13 same13 opon
bull The13 client13 obeys13 the13 speed13 indicated13 by13 the13 server
bull The13 client13 can13 send13 slower13 but13 not13 faster
Advantages
bull The13 server13 has13 means13 to13 limit13 the13 amount13 of13 incoming13 traffic
bull The13 server13 can13 prevent13 to13 become13 overloaded13 with13 too13 many13 tasks
bull The13 server13 does13 not13 need13 arficially13 slow13 down13 the13 client13 by13 sending13 late13 ACKsndash No13 need13 to13 keep13 track13 of13 delayed13 ACKsndash The13 server13 can13 perform13 other13 tasks13 instead
bull Reduced13 network13 traffic
Thank13 youQuesons
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-links-json-02txt
123
RFC 6690 (link-format) documents are somewhat foreign to many web app developerssect would prefer to have them in JSON format
There is no standard way to represent link-format documents in applicationssect but everyone knows how to handle JSON
Define a standard JSON translation for link-format
Itrsquos
not
rock
et
scien
ce
ltsensorsgtct=40title=Sensor Index ltsensorstempgtrt=temperature-cif=sensor ltsensorslightgtrt=light-luxif=sensor lthttpwwwexamplecomsensorst123gt anchor=sensorstemprel=describedby lttgtanchor=sensorstemprel=alternate [hrefsensorsct40titleSensor Index hrefsensorstemprttemperature-cifsensor hrefsensorslightrtlight-luxifsensor hrefhttpwwwexamplecomsensorst123 anchorsensorstempreldescribedby hreftanchorsensorstemprelalternate]
124
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-ipsec-for-coap-00txt
IPsec definitions for CoAP Mostly placeholder at this time Who has implementation experience with this
125
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-cross-reverse-convention-00txt
This draft has two lines of payload(based on a WGLC comment by Cullen Jennings)
coap12344567foobara=3
httpwwwproxycomwellknowncore-translate1234_4567foobara=3
Is that a useful convention to have
126
Insert CI slides here
127
128
0
5
10
15
20
25
30
35
40
10 20 30 40 50 60 70
good
put (
pps)
pps
Goodput vs pps (Econotags)
goodput
[Khattak preliminary]
Congestion Control
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-cocoa-00txt
ldquoadvancedrdquo cc (The draft is just a first shot) Others may have better ideas
129
Insert post-WGLC discussion slides here
130
Stop Continue Start
131
An Agile Retrospective
http6lowappnet coreIETF86 2013-03-12-13
Stop
132
Endless new CoAP optionssect instead use RESTful as much as possible
Move general security lifecycle out Looking at theoretical problems
http6lowappnet coreIETF86 2013-03-12-13
Continue
Interops Running code Look at real-world examples and deployments Solve their actual problems
sect Unilateral enhancements eg higher performance congestion control
sect Transports (SMS hellip)sect Make Web linking and Directories more and more usefulsect RESTful Design Paradigms for real-world problems
133
http6lowappnet coreIETF86 2013-03-12-13
Start
Further push into the (browser) web world (HTML5 browser security)
Specific supporting worksect SenMLsect URI work (dev URN hellip)sect Security Processes (next slide)
Spin outsect (We donrsquot really get to decide where this is done)
134
http6lowappnet coreIETF86 2013-03-12-13
Security
Integrate Application Network Group Keyingsect Tunnel-free setup
Donrsquot redo what has been done alreadysect ZigBee IP is finesect But what about other scenarios
Simple REST interfaces for working with keying materials and authorizationsect Start with defining objectives
Object Security for Constrained Nodes135
Re-chartering CoREWhat do we want to do now that wersquore grown up
Zach ShelbyCoRE WG IETF-86 Orlando
What is the scope
bull So we have a protocol and Web Linking what next
bull Keep with what we know besthellip1 Enhancements around CoAP2 New transports for CoAP3 New representations for Web Links4 General application layer solutions
CoRE WG IETF-86 Orlando 2
Enhancements around CoAP
bull Advanced congestion control
CoRE WG IETF-86 Orlando 3
New Transports for CoAP
bull Infrastructure for CoAP over foondash httptoolsietforgiddraft-silverajan-core-
coap-alternative-transports-01txtbull CoAP over SMS
ndash httptoolsietforgiddraft-becker-core-coap-sms-gprs-03txt
ndash OMA Lightweightbull CoAP over TCP
ndash httptoolsietforgiddraft-li-core-coap-payload-length-option-01txt
CoRE WG IETF-86 Orlando 4
New support for Web Links
bull JSON Web Linksndash httptoolsietforgiddraft-bormann-core-links-
json-02txt
2332010 CoRE WG IETF-77 Anaheim 5
General application layer solutions
bull Resource Directoryndash httptoolsietforgiddraft-shelby-core-
resource-directory-05txtndash OMA Lightweight
2332010 CoRE WG IETF-77 Anaheim 6
Feedback Response-To-Scheme option
I Should there be a Response-To-Scheme optionadditionally to Response-To-Uri-Host andResponse-To-Uri-Path
I So that a CoAP end-point which receives a request by CoAPover non-IP transport can be instructed to also use thenon-IP transport for the response
I This would imply to add aResponse-To-Telephone-Subscriber and more options forother transports that have other URI schemes than coapand coaps
6 10
Feedback Selection of Transport by Client
I When a server is reachable by various transports howdoes a client decide which transport to use
I Client-side application congurationI Leave it to a proxy which uses cellular network lookupfunctions
7 10
Feedback Potential Threats
I Trigger expensive short messagesI Redirect trac to other addressesI More threats
I Are the security measures in the draft adequateI Whitelisting on serverI Relying on cellular network security (dedicated M2M APNs)I Object security on CoAP payload
8 10
Feedback Message Exchanges
I Figures 11-18 show possible message exchanges whenclient and server have two addresses
I With NON Not using CoAP retransmission capabilityI ACK on different transportI Additional (costly) message on Transport AI Request with Content
I Which ones are allowedI Which ones are meaningful
9 10
Next steps
I Rene Uri schemeI Response-To-Scheme optionI Selection of Message ExchangeI Rene Proxying
10 10
CoAP13 Communicaon13 with13 Alternave13 Transports
Bill Silverajan and Teemu SavolainenCore WG IETF 86 Orlando
031113
Objecves13 (In13 Scope)
bull Unambiguous13 representaon13 of13 transport13 to13 be13 used13 by13 CoAP
bull Details13 how13 the13 transport13 can13 carry13 CoAP13 packet
bull Focus13 is13 on13 what13 CoAP13 communicaons13 requirements13 are
bull Allow13 CoAP13 mechanisms13 to13 exploit13 cross-shy‐layer13 opmisaons
51
031113
Non13 Goals13 (Not13 in13 scope)
bull Applicaon-shy‐level13 QoS13 requirementsbull Real-shy‐me13 constraintsbull Ordering13 reliability13 congeson13 controlbull Applicaon13 and13 network13 adaptaonbull Mobility13 and13 readdressing13 supportbull Network13 protocol13 (eg13 IPsec)13 configuraon
52
031113
Use13 Cases
bull NAT13 and13 Firewall13 traversal13 with13 TCPbull Delay13 Tolerant13 Networkingbull Non-shy‐IP13 Low13 Energy13 Protocols
53
031113
Related13 Work
bull OMA13 Lightweight13 M2M13 Protocolbull CoAP13 over13 SMSGPRSUSSD
54
031113
What13 does13 the13 work13 entail
bull The13 ability13 to13 specify13 end13 point13 idenfiers13 and13 URIs13 to13 reflect13 which13 transport13 CoAP13 can13 use
bull The13 ability13 to13 register13 to13 resource13 directories13 resource13 types13 reflecng13 types13 of13 transport13 available
bull Ability13 for13 mul-shy‐transport13 nodes13 to13 select13 transport13 to13 use13 without13 significant13 alteraon13 to13 CoAP13 packet13 structure
55
031113
Points13 to13 consider
bull Requirements13 for13 transport13 layer13 protocol13 to13 carry13 CoAP13 packets
bull Representaon13 of13 URI13 scheme13 for13 generic13 transport13 protocols
bull Opon13 extensions13 for13 CoAP13 to13 express13 available13 transports
bull Mapping13 and13 message13 sizebull Security13 consideraons
56
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
URI13 =13 scheme13 13 13 authority13 path-shy‐abempty13 [13 query13 ]
bull Within13 the13 scheme13 namebull In13 the13 URI13 pathbull As13 a13 query13 component
57
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
bull Within13 the13 scheme13 namendash coap+tel+15105550101well-shy‐knowncorendash coap+tcpexamplecom5683temperaturendash coap+blel2cap[1234567890AB]4pulse
bull Easy13 URI13 parsing13 for13 transport13 type13 and13 idenfier
bull Each13 new13 scheme13 name13 requires13 IANA13 registraon
58
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
bull In13 the13 URI13 pathndash coaphostexamplecomtransport=tcpwell-shy‐knowncorert=core-shy‐rd
bull Easy13 adopon13 of13 new13 (and13 experimental)13 CoAP13 transports13 without13 IANA13 registraon
bull Caveat13 Uri-shy‐Path13 opon13 is13 a13 Crical13 CoAP13 opon13 see13 secon13 54113 of13 I-shy‐Diep-shy‐core-shy‐coap
59
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
bull As13 a13 URI13 query13 componentndash coaphostexamplecomwell-shy‐knowncorert=core-shy‐rdq=tcp
bull Also13 easy13 to13 adopt13 new13 (and13 experimental)13 CoAP13 transports13 without13 IANA13 registraon
bull Caveat13 Uri-shy‐Query13 opon13 is13 a13 Crical13 CoAP13 opon13 see13 secon13 54113 of13 I-shy‐Diep-shy‐core-shy‐coap
60
031113
URI13 Representaons13 for13 CoAPNon13 standard13 ways
bull Transport13 in13 the13 URI13 authority13 componentndash coaphost[port][transport]13 instead13 of13 coaphost[port]
bull Transport13 as13 a13 service13 URLndash servicecoaptcphostexamplecomwell-shy‐knowncorert=core-shy‐rd
bull Above13 two13 ways13 break13 exisng13 compability13 (although13 both13 are13 based13 on13 valid13 IANA13 URI13 registraons)
61
031113
URI13 Representaons13 for13 CoAPMiscellaneous13 Consideraons
bull Ensure13 that13 transport13 is13 defined13 unambiguously13 (eg13 L2CAP13 used13 by13 both13 BLE13 and13 standard13 Bluetooth13 so13 avoid13 rdquocoap+l2caprdquo13 or13 rdquotransport=l2caprdquo13 or13 rdquoq=l2caprdquondash Can13 be13 done13 as13 WG13 consensusndash Namespace13 approach13 eg13 rdquocoap+blel2caprdquo13 or13 rdquoq=blel2caprdquo
bull Allow13 end-shy‐points13 to13 use13 CoAP13 Resource13 Directory13 to13 register13 alternave13 transports13 and13 idenfiers13 and13 provide13 periodic13 updatesndash Register13 rdquocore-shy‐transportrdquo13 resource13 type
62
031113
Transport13 Consideraons
bull Uniqueness13 of13 end-shy‐point13 idenficaonbull Communicaon13 support13 Unidireconal13 Bidireconal13 1N13 (broadcast13 mulcast13 anycast)13 messaging
bull Binary13 encoding13 Network13 byte13 orderingbull MTU13 correlaon13 with13 CoAP13 PDU13 sizebull Transport13 latency
63
031113
Security13 Consideraons
bull Drar13 does13 not13 introduce13 new13 security13 requirements13 by13 itself
bull There13 may13 be13 privacy13 issues13 if13 nodes13 use13 telephone13 numbers13 or13 MAC13 addresses13 as13 public13 end13 point13 idenfiers
64
Akbar Rahman
IETF 86 March 2013 httpwwwietforgiddraft-rahman-core-sleepy-02txt
Enhanced Sleepy Node Support for CoAP
Introduction
It is expected that in CoAP networks there will be a certain portion of devices that are sleepy and which may occasionally go into a sleep mode (ie go into a low power state to conserve power) and subsequently have reduced CoAP protocol communication ability
This I-D proposes a minimal and efficient mechanism building on the Resource Directory concept (which will be integrated into a CoAP Proxy) to enhance sleepy node support in CoAP networks
Main Question from IETF-85 (Atlanta)
What performance benefit does the proposed Sleepy Node support solution give in a network that already has standard CoAP caching enabled
Sleepy Node Performance Analysis
Experimental Network
1-5 clients
Both Sleepy and Non-
Sleepy servers
Sleepy Node Performance Analysis Network Setup
CoAPSleepyServer(s)
CoAPSleepAwareReverseProxy
CoAP
Client(s)
Request
Response
Sleep9AwareCoREResourceDirectoryCapability
PublishedSleepParameters
Sleep9AwareCoAPStoreandForwardCapability Response
Request
SleepAwareCoAP503ResponseCapability
CoAPCachingCapability
bull Server supports publishing sleep parameters to proxy bull Eg Irsquom going to be asleep for X seconds
bull Proxy supports sleep-awareness capabilities bull Proxy also supports caching capability based off of maxAge bull Protocol flow similar to approach of Figure 1 (Synchronous RD Based Sleep
Tracking) of I-D
Proxy capabilities can be selectively enableddisabled
Proxy ndash Server Interface
Client ndash Proxy Interface
CoAP Sleep-Aware Reverse Proxy Features CoRE Sleep-aware Resource Directory
Support storing published sleep parameters from CoAP servers sleepState (AWAKE ASLEEP) sleepDuration
Sleep-aware CoAP 503 Response Capability If CoAP request to a sleeping server is received proxy returns a
lsquo503 Retry-Afterrsquo response to client 503 contains a timestamp indicating when the sever will wake back up
(timestamp delivered in CoAP maxAge option) Sleep-aware CoAP Store-and-Forward Capability
If CoAP request to a sleeping server is received proxy stores request until server wakes up and then forwards it
Caching capability Cache GET responses from server if maxAge option is present
(this is not a sleep aware feature)
Goals of Performance Analysis
For networks having sleepy servers provide measurements to quantify the impact that CoAP sleep-awareness capabilities can have
See if sleep-awareness capabilities can
provide additional benefits even when CoAP caching is used
Overview of Performance Analysis Performed The analysis was broken up into a set of test scenarios Each test scenario used a different combination of the following
variables Client issued GET requests Server was configured as a sleepy or non-sleepy server Proxy caching of GET responses was enabled or disabled Proxy sleep-aware 503 response capability was enabled or disabled Proxy store-and-forward capability was enabled or disabled maxAge in GET responses ndash Two values were tested 60sec and 5sec of Clients ndash Two values were used ndash 1 client and 5 clients
For comparison purposes the following were held constant across all test scenarios Client issued a fixed number of requests (100) across all test scenarios Client used a delay between each GET request (35sec) to better exercise
proxyrsquos caching and sleep-awareness capabilities For sleepy server test scenarios the server slept 60 sec awake for 3 sec
Format of Results The following results were collected for each
test scenario
Breakdown of the and types of transactions occurring between clientproxyserver
ldquoGETrdquo ndash Test Scenario Results
GET ndash Description of Test Scenarios
TestScenarios-GET
Scenario
CoAPSleepyServerSe7ngs CoAPSleepAwareReverseProxySe7ngs CoAPClientSe7ngs
SleepDuragton(sec)
AwakeDuragton(sec)
maxAge(sec) Caching SleepAwareSAF+
503NumberofClients
NumberofGETs
DelayBetweenClient
Requests(sec)
1a 0 Always 60 Enabled Disabled 1 100 35
1b 60 3 60 Enabled Disabled 1 100 35
1c 60 3 60 Enabled Enabled 1 100 35
2a 0 Always 60 Enabled Disabled 5 100 35
2b 60 3 60 Enabled Disabled 5 100 35
2c 60 3 60 Enabled Enabled 5 100 35
3a 0 Always 5 Enabled Disabled 5 100 35
3b 60 3 5 Enabled Disabled 5 100 35
3c 60 3 5 Enabled Enabled 5 100 35
ldquoGETrdquo ndash Test Scenario 1 Results
maxAge = 60 and 1 Client
GET ndash Scenario 1 ClientProxy Interface Transaction Mix
Scenarios 1a - Non-Sleepy Server Caching Proxy maxAge = 60sec 1b- Sleepy Server Caching Proxy maxAge = 60sec 1c - Sleepy Server Sleep Aware Proxy maxAge = 60sec
Sleep Aware Proxy has better performance for sleepy servers
0
100
200
300
400
500
600
700
1a 1b 1c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
GET ndash Scenario 1 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
Scenarios 1a - Non-Sleepy Server Caching Proxy maxAge = 60sec 1b- Sleepy Server Caching Proxy maxAge = 60sec 1c - Sleepy Server Sleep Aware Proxy maxAge = 60sec
0
100
200
300
400
500
600
700
800
1a 1b 1c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
ldquoGETrdquo ndash Test Scenario 2 Results
maxAge = 60 and 5 Clients
GET ndash Scenario 2 ClientProxy Interface Transaction Mix
Sleep Aware Proxy has slightly better performance for sleepy servers
0
200
400
600
800
1000
1200
1400
2a 2b 2c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
Scenarios 2a - Non-Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2b- Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2c - Sleepy Server Sleep Aware Proxy maxAge = 60sec 5 Clients
See ldquoExperimental Artifactsrdquo Note 1
GET ndash Scenario 2 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has slightly better performance for sleepy servers
0
50
100
150
200
250
300
350
400
2a 2b 2c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
Scenarios 2a - Non-Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2b- Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2c - Sleepy Server Sleep Aware Proxy maxAge = 60sec 5 Clients
See ldquoExperimental Artifactsrdquo Note 2
Experimental Artifacts Note 1
Currently in the experiment the sleep aware proxy checks the cached state of a resource before putting a request into its Store-and-forward queue while a server is sleeping Once in the queue the proxy unconditionally forwards the queued requests to the server once it wakes up This is not the most efficient setup and can easily be improved If the proxy instead checks its cache again before forwarding each queued request it may not need to forward the request to the server For example if there are two queued GET requests in the proxyrsquos queue that address the same resource Only the first request needs to be sent to the server the second request can use the cached response from the first request
Note 2 Currently in the experiment the sleepy server sends a sleepState PUT request to the
proxy each time it goes to sleep This is not the most efficient setup and can easily be improved For example if the server assumes that the proxy can keep track of its ONOFF cycles with its internal timers (eg as per Fig 1 of I-D) then the number of messages from the sleepy server dramatically goes down
ldquoGETrdquo ndash Test Scenario 3 Results
maxAge = 5 and 5 Clients
GET ndash Scenario 3 ClientProxy Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
Scenarios 3a - Non-Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3b- Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3c - Sleepy Server Sleep Aware Proxy maxAge = 5sec 5 Clients
0
500
1000
1500
2000
2500
3000
3500
4000
4500
5000
3a 3b 3c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
GET ndash Scenario 3 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
0
1000
2000
3000
4000
5000
6000
7000
3a 3b 3c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
Scenarios 3a - Non-Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3b- Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3c - Sleepy Server Sleep Aware Proxy maxAge = 5sec 5 Clients
Conclusions
Conclusions These results show that sleep-aware CoAP
proxy features can significantly optimize communication with sleepy servers in most scenarios
These results also show that sleep-
awareness capabilities can provide additional benefits above and beyond CoAP caching in most scenarios
Backup
Current CoAP Support of Sleepy Node (12)
CoAP proxies can use a previously cached response to service a new GET request for a sleepy origin server (as in HTTP) But if no valid cache then proxy has to attempt to
retrieve and may fail if origin server is sleeping [I-Dietf-core-coap]
Clients can discover list of resources from RD (GET rd-lookuphellip) for sleepy servers But attempt to GET resource from sleepy origin server
may fail if origin server is sleeping [IDietf-core-link-format amp IDshelby-core-resource-
directory]
Current CoAP Support of Sleepy Node (22)
Lower layer support for sleepy nodes in most wireless technologies (eg WiFi ZigBee) But limited to MAC packet scheduling for sleepy nodes
and not aware of specific needs of IP applications (like CoAP)
Proposal ndash RD Based Sleep Tracking (14)
The current CoAP approach to support sleepy nodes can be significantly improved by introducing RD based mechanisms for a CoAP client to determine whether A targeted resource is located on a sleepy server A sleepy server is currently in sleep mode or not
There is any associated caching Proxy (possibly the RD itself) for a sleepy server
Proposal ndash RD Based Sleep Tracking (24)
We define the following new RD attributes to characterize the properties of a sleepy node SleepState - Indicates whether the node is currently in
sleep mode or not (ie Sleeping or Awake) SleepDuration - Indicates the maximum duration of time
that the node stays in sleep mode TimeSleeping - Indicates the length of time the node
has been sleeping (ie if Sleep State = Sleeping) NextSleep - Indicates the next time the node will go to
sleep (ie if Sleep State = Awake)
CachingProxy ndash Indicates the caching proxy of the sleepy node (ie the RD itself or another node)
Proposal ndash RD Based Sleep Tracking (34)
These attributes are all server (node) level and are new parameters added to the RD URI Template Variables
Finally we also define a new lookup-type (ss) for the RD lookup interface specified in [I-Dshelby-core-resource-directory] This new lookup-type supports looking up the
ldquoSleepStaterdquo (ss) of a specified end-point
Proposal ndash RD Based Sleep Tracking (44)
The three time based parameters (SleepDuration TimeSleeping NextSleep) can be based on either an absolute network time (for a time synchronized network) or a relative local time (measured at the local node)
Following the approach of [I-Dietf-core-link-format] and [I-Dshelby-core-resource-directory] sleep parameters for sleepy servers can be stored by the server in the RD and accessed by all interested clients
Examples of using these parameters in a synchronous or asynchronous manner are shown in the I-D
http6lowappnet coreIETF86 2013-03-12-13
We assume people have read the drafts
Meetings serve to advance difficult issues by making good use of face-to-face communications
Note Well Be aware of the IPR principles according to RFC 3979 and its updates
uumlBlue sheetsuumlScribe(s)
96
drar-shy‐iep-shy‐core-shy‐coapsubmiqed13 to13 IESG
2013-shy‐03-shy‐13
97
OMA Lightweight M2M Overview(A new standard using lots of IETF specs including DTLS
CoAP Block Observe Resource Directory SenMLhellip)
Zach ShelbyCoRE WG IETF-86 Orlando
OMA Lightweight M2Mbull Open Mobile Alliance is well known for Device Management (DM)bull OMA Lightweight M2M is a new standard from the alliance
ndash Focused on constrained Cellular and sensor network M2M devicesndash Driven by leading operators and vendors
bull Scopendash Interfaces protocol amp security between Device and Serverndash Object and Resource modelndash Bootstrap Device Access Control Connectivity and Firmware Objects
bull Draft Specifications are availablendash httpmemberopenmobileallianceorgftpPublic_documentsDM
LightweightM2MPermanent_documentsOMA-TS-LightweightM2M-V1_0_0-20130301-Dzip
bull Timelinendash Requirements and Architecture completed 3Q2012ndash Spec ready for Consistency Review 2Q2013ndash Candidate Approval expected 3Q2013
2 CoRE WG IETF-86 Orlando
Architecture
3
Scope of LWM2M
CoRE WG IETF-86 Orlando
Object Model
bull A Client has one or more Object Instancesbull An Object is a collection of Resourcesbull A Resource is an atomic piece of information
ndash Read Written or Executed
bull Resources can have multiple instancesbull Objects and Resources are identified by a
16-bit Integer Instances by an 8-bit Integerbull ObjectsResources are accessed with
simple URIs Object IDObject InstanceResource ID
eg 1213
4 CoRE WG IETF-86 Orlando
CoRE WG IETF-86 Orlando
CoRE Resource Directory
draft-shelby-core-resource-directory-05
Z Shelby C Bormann S Krco
Backgroundbull Not a new concept
ndash think web search engine or any link directorybull Defines the interfaces to a Resource Directorybull Based on Web Linking framework and the CoRE Link Formatbull Generic REST design for use over HTTP and CoAPbull Used by OMA Lightweight M2Mbull Has already been deployed
ndash In traffic monitoring systemsndash In street lighting systemsndash For vehicular asset trackingndash By a major Cellular M2M operator
Changes since -04
bull Restricted Update to parameter updatesbull Added pagination support for the Lookup interfacebull Changed rt= to et= for the registration amp update
interfacebull Added group support
Group Management
bull RD now includes group management featuresbull New Group Function Set
ndash Register a groupbull Group name domain multicast address endpoint members
ndash Remove a groupbull Group lookup using the Lookup Function Set
ndash List registered groupsndash Find the members of a groupndash Find groups with certain endpoints or resources
Registering a Group
EP RD
| |
| - POST rd-groupgp=lights ltgtep=node1 --gt |
| |
| |
| lt---- 201 Created Location rd-group12 ---- |
| |
Req POST coaprdexamplecomrd-groupgp=lights
Payload
ltgtep=node1
ltgtep=node2
Res 201 Created
Location rd-group12
Looking up Group Members
Client RD
| |
| ----- GET rd-lookupepgp=lights1 ----------------------gt |
| |
| |
| lt-- 205 Content ltrdgtd=domain1ltrdgtd=domain2 --------- |
| |
Req GET rd-lookupepgp=lights1
Res 205 Content
ltcoaphostportgtep=node1
ltcoaphostportgtep=node2rdquo
Things for the futurebull Support for JSON representation of Web Links
ndash httptoolsietforgiddraft-bormann-core-links-json-02txtbull Registry for RD registration query parameters
ndash Already OMA Lightweight has defined some new onesbull More examples
Group 3 ldquonew workrdquo(continued)
109
drar-shy‐greevenbosch-shy‐core-shy‐profile-shy‐descripon-shy‐01Bert13 GreevenboschJeroen13 Hoebeke
Isam13 IshaqFloris13 Van13 den13 Abeele
Descripon
bull JSON13 format13 for13 signalling13 the13 servers13 capabilies
bull Signalling13 of13 supported13 opons13 media13 types13 and13 block13 sizendash Other13 items13 can13 be13 added
bull Filtering13 on13 specific13 fields13 through13 URI-shy‐Querybull Link13 hqpdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐profile-shy‐descripon
well-shy‐knownprofile
bull To13 acquire13 profile13 data13 of13 resources13 on13 a13 parcular13 service13 the13 well-shy‐knownprofile13 URI-shy‐path13 is13 introduced
bull For13 example13 to13 get13 all13 informaon13 from13 sensors13 served13 by13 wwwexampleorg13 we13 can13 do13 a13 GET13 to13 coapwwwexampleorgwell-shy‐knownprofile
bull Filtering13 on13 parcular13 resources13 is13 done13 through13 URI-shy‐Queries
Format
bull Currently13 the13 following13 fields13 are13 definedndash ldquopathrdquo13 contains13 the13 URI-shy‐path13 associated13 with13 a13 resource
ndash ldquooprdquo13 a13 numerical13 list13 of13 supported13 opon13 numbers
ndash ldquocfrdquo13 a13 numerical13 list13 of13 supported13 content-shy‐format13 numbers
ndash ldquob1srdquo13 ldquob2srdquo13 supported13 block13 sizes13 for13 Block113 and13 Block213 respecvely
Examplebull On13 the13 right13 is13 an13 example13 of13 a13 camera13 sensor13 at13 coapwwwexampleorgcam13 that13 supports13 the13 Uri-shy‐Host13 (3)13 ETag13 (4)13 Uri-shy‐Port13 (7)13 Uri-shy‐Path13 (11)13 Content-shy‐Format13 (12)13 Token13 (19)13 Block213 (23)13 and13 Proxy-shy‐Uri13 (35)13 opons
bull The13 supported13 content13 formats13 are13 textplain13 (0)13 applicaon13 link-shy‐format13 (40)13 and13 applicaonjson13 (50)
bull The13 supported13 Block213 can13 use13 25613 or13 51213 byte13 blocks
Req13 GET13 coapwwwexampleorgwell-shy‐knownprofile13 Res13 20513 Content13 (applicationjson)13 13 13 13 profile13 13 13 13 13 13 13 13 pathcam13 13 13 13 op[3471112192335]13 13 13 13 13 cf[04050]13 13 13 13 13 b2s[45]13 13 13 13
Filtering13 through13 use13 of13 URI-shy‐Query
bull Filtering13 can13 be13 done13 through13 the13 URI-shy‐Querybull Query13 format13 N=V
ndash N13 is13 a13 profile13 fieldndash V13 is13 the13 desired13 value
bull Examplesndash To13 find13 resources13 that13 support13 content13 format13 ldquoapplicaonjsonrdquo
13 GET13 wwwexampleorgwell-shy‐knownprofilecf=50ndash To13 get13 informaon13 about13 the13 camera
13 GET13 wwwexampleorgwell-shy‐knownprofilepath=cam
Open13 issues
bull Which13 other13 profile13 data13 needs13 signallingndash Content-shy‐type13 for13 different13 methods
bull Fix13 the13 order13 in13 which13 the13 profile13 fields13 must13 appearndash Non-shy‐fixed13 order13 easier13 extensible
bull Inheritance13 of13 a13 profile13 descriponbull Extend13 usage13 to13 signal13 the13 client13 profilebull Integraon13 with13 link13 format
Thank13 youQuesons
drar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval-shy‐00
Bert13 Greevenbosch
Descripon
bull The13 ldquoMinimumRequestInterval13 opon13 can13 be13 used13 to13 indicate13 the13 minimum13 me13 between13 two13 requests13 in13 a13 transacon
bull Originally13 intended13 for13 Block13 but13 also13 usable13 for13 other13 transaconsndash Example13 browsing13 a13 server
bull The13 goal13 is13 to13 reduce13 the13 server13 load13 and13 network13 traffic
bull Link13 hqpsdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval
Usage
bull The13 client13 keeps13 the13 server13 informed13 about13 its13 request13 speed13 through13 inclusion13 of13 the13 ldquoMinimumRequestIntervalrdquo13 opon
bull In13 responses13 the13 server13 fixes13 the13 minimum13 request13 interval13 through13 the13 same13 opon
bull The13 client13 obeys13 the13 speed13 indicated13 by13 the13 server
bull The13 client13 can13 send13 slower13 but13 not13 faster
Advantages
bull The13 server13 has13 means13 to13 limit13 the13 amount13 of13 incoming13 traffic
bull The13 server13 can13 prevent13 to13 become13 overloaded13 with13 too13 many13 tasks
bull The13 server13 does13 not13 need13 arficially13 slow13 down13 the13 client13 by13 sending13 late13 ACKsndash No13 need13 to13 keep13 track13 of13 delayed13 ACKsndash The13 server13 can13 perform13 other13 tasks13 instead
bull Reduced13 network13 traffic
Thank13 youQuesons
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-links-json-02txt
123
RFC 6690 (link-format) documents are somewhat foreign to many web app developerssect would prefer to have them in JSON format
There is no standard way to represent link-format documents in applicationssect but everyone knows how to handle JSON
Define a standard JSON translation for link-format
Itrsquos
not
rock
et
scien
ce
ltsensorsgtct=40title=Sensor Index ltsensorstempgtrt=temperature-cif=sensor ltsensorslightgtrt=light-luxif=sensor lthttpwwwexamplecomsensorst123gt anchor=sensorstemprel=describedby lttgtanchor=sensorstemprel=alternate [hrefsensorsct40titleSensor Index hrefsensorstemprttemperature-cifsensor hrefsensorslightrtlight-luxifsensor hrefhttpwwwexamplecomsensorst123 anchorsensorstempreldescribedby hreftanchorsensorstemprelalternate]
124
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-ipsec-for-coap-00txt
IPsec definitions for CoAP Mostly placeholder at this time Who has implementation experience with this
125
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-cross-reverse-convention-00txt
This draft has two lines of payload(based on a WGLC comment by Cullen Jennings)
coap12344567foobara=3
httpwwwproxycomwellknowncore-translate1234_4567foobara=3
Is that a useful convention to have
126
Insert CI slides here
127
128
0
5
10
15
20
25
30
35
40
10 20 30 40 50 60 70
good
put (
pps)
pps
Goodput vs pps (Econotags)
goodput
[Khattak preliminary]
Congestion Control
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-cocoa-00txt
ldquoadvancedrdquo cc (The draft is just a first shot) Others may have better ideas
129
Insert post-WGLC discussion slides here
130
Stop Continue Start
131
An Agile Retrospective
http6lowappnet coreIETF86 2013-03-12-13
Stop
132
Endless new CoAP optionssect instead use RESTful as much as possible
Move general security lifecycle out Looking at theoretical problems
http6lowappnet coreIETF86 2013-03-12-13
Continue
Interops Running code Look at real-world examples and deployments Solve their actual problems
sect Unilateral enhancements eg higher performance congestion control
sect Transports (SMS hellip)sect Make Web linking and Directories more and more usefulsect RESTful Design Paradigms for real-world problems
133
http6lowappnet coreIETF86 2013-03-12-13
Start
Further push into the (browser) web world (HTML5 browser security)
Specific supporting worksect SenMLsect URI work (dev URN hellip)sect Security Processes (next slide)
Spin outsect (We donrsquot really get to decide where this is done)
134
http6lowappnet coreIETF86 2013-03-12-13
Security
Integrate Application Network Group Keyingsect Tunnel-free setup
Donrsquot redo what has been done alreadysect ZigBee IP is finesect But what about other scenarios
Simple REST interfaces for working with keying materials and authorizationsect Start with defining objectives
Object Security for Constrained Nodes135
Re-chartering CoREWhat do we want to do now that wersquore grown up
Zach ShelbyCoRE WG IETF-86 Orlando
What is the scope
bull So we have a protocol and Web Linking what next
bull Keep with what we know besthellip1 Enhancements around CoAP2 New transports for CoAP3 New representations for Web Links4 General application layer solutions
CoRE WG IETF-86 Orlando 2
Enhancements around CoAP
bull Advanced congestion control
CoRE WG IETF-86 Orlando 3
New Transports for CoAP
bull Infrastructure for CoAP over foondash httptoolsietforgiddraft-silverajan-core-
coap-alternative-transports-01txtbull CoAP over SMS
ndash httptoolsietforgiddraft-becker-core-coap-sms-gprs-03txt
ndash OMA Lightweightbull CoAP over TCP
ndash httptoolsietforgiddraft-li-core-coap-payload-length-option-01txt
CoRE WG IETF-86 Orlando 4
New support for Web Links
bull JSON Web Linksndash httptoolsietforgiddraft-bormann-core-links-
json-02txt
2332010 CoRE WG IETF-77 Anaheim 5
General application layer solutions
bull Resource Directoryndash httptoolsietforgiddraft-shelby-core-
resource-directory-05txtndash OMA Lightweight
2332010 CoRE WG IETF-77 Anaheim 6
Feedback Selection of Transport by Client
I When a server is reachable by various transports howdoes a client decide which transport to use
I Client-side application congurationI Leave it to a proxy which uses cellular network lookupfunctions
7 10
Feedback Potential Threats
I Trigger expensive short messagesI Redirect trac to other addressesI More threats
I Are the security measures in the draft adequateI Whitelisting on serverI Relying on cellular network security (dedicated M2M APNs)I Object security on CoAP payload
8 10
Feedback Message Exchanges
I Figures 11-18 show possible message exchanges whenclient and server have two addresses
I With NON Not using CoAP retransmission capabilityI ACK on different transportI Additional (costly) message on Transport AI Request with Content
I Which ones are allowedI Which ones are meaningful
9 10
Next steps
I Rene Uri schemeI Response-To-Scheme optionI Selection of Message ExchangeI Rene Proxying
10 10
CoAP13 Communicaon13 with13 Alternave13 Transports
Bill Silverajan and Teemu SavolainenCore WG IETF 86 Orlando
031113
Objecves13 (In13 Scope)
bull Unambiguous13 representaon13 of13 transport13 to13 be13 used13 by13 CoAP
bull Details13 how13 the13 transport13 can13 carry13 CoAP13 packet
bull Focus13 is13 on13 what13 CoAP13 communicaons13 requirements13 are
bull Allow13 CoAP13 mechanisms13 to13 exploit13 cross-shy‐layer13 opmisaons
51
031113
Non13 Goals13 (Not13 in13 scope)
bull Applicaon-shy‐level13 QoS13 requirementsbull Real-shy‐me13 constraintsbull Ordering13 reliability13 congeson13 controlbull Applicaon13 and13 network13 adaptaonbull Mobility13 and13 readdressing13 supportbull Network13 protocol13 (eg13 IPsec)13 configuraon
52
031113
Use13 Cases
bull NAT13 and13 Firewall13 traversal13 with13 TCPbull Delay13 Tolerant13 Networkingbull Non-shy‐IP13 Low13 Energy13 Protocols
53
031113
Related13 Work
bull OMA13 Lightweight13 M2M13 Protocolbull CoAP13 over13 SMSGPRSUSSD
54
031113
What13 does13 the13 work13 entail
bull The13 ability13 to13 specify13 end13 point13 idenfiers13 and13 URIs13 to13 reflect13 which13 transport13 CoAP13 can13 use
bull The13 ability13 to13 register13 to13 resource13 directories13 resource13 types13 reflecng13 types13 of13 transport13 available
bull Ability13 for13 mul-shy‐transport13 nodes13 to13 select13 transport13 to13 use13 without13 significant13 alteraon13 to13 CoAP13 packet13 structure
55
031113
Points13 to13 consider
bull Requirements13 for13 transport13 layer13 protocol13 to13 carry13 CoAP13 packets
bull Representaon13 of13 URI13 scheme13 for13 generic13 transport13 protocols
bull Opon13 extensions13 for13 CoAP13 to13 express13 available13 transports
bull Mapping13 and13 message13 sizebull Security13 consideraons
56
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
URI13 =13 scheme13 13 13 authority13 path-shy‐abempty13 [13 query13 ]
bull Within13 the13 scheme13 namebull In13 the13 URI13 pathbull As13 a13 query13 component
57
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
bull Within13 the13 scheme13 namendash coap+tel+15105550101well-shy‐knowncorendash coap+tcpexamplecom5683temperaturendash coap+blel2cap[1234567890AB]4pulse
bull Easy13 URI13 parsing13 for13 transport13 type13 and13 idenfier
bull Each13 new13 scheme13 name13 requires13 IANA13 registraon
58
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
bull In13 the13 URI13 pathndash coaphostexamplecomtransport=tcpwell-shy‐knowncorert=core-shy‐rd
bull Easy13 adopon13 of13 new13 (and13 experimental)13 CoAP13 transports13 without13 IANA13 registraon
bull Caveat13 Uri-shy‐Path13 opon13 is13 a13 Crical13 CoAP13 opon13 see13 secon13 54113 of13 I-shy‐Diep-shy‐core-shy‐coap
59
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
bull As13 a13 URI13 query13 componentndash coaphostexamplecomwell-shy‐knowncorert=core-shy‐rdq=tcp
bull Also13 easy13 to13 adopt13 new13 (and13 experimental)13 CoAP13 transports13 without13 IANA13 registraon
bull Caveat13 Uri-shy‐Query13 opon13 is13 a13 Crical13 CoAP13 opon13 see13 secon13 54113 of13 I-shy‐Diep-shy‐core-shy‐coap
60
031113
URI13 Representaons13 for13 CoAPNon13 standard13 ways
bull Transport13 in13 the13 URI13 authority13 componentndash coaphost[port][transport]13 instead13 of13 coaphost[port]
bull Transport13 as13 a13 service13 URLndash servicecoaptcphostexamplecomwell-shy‐knowncorert=core-shy‐rd
bull Above13 two13 ways13 break13 exisng13 compability13 (although13 both13 are13 based13 on13 valid13 IANA13 URI13 registraons)
61
031113
URI13 Representaons13 for13 CoAPMiscellaneous13 Consideraons
bull Ensure13 that13 transport13 is13 defined13 unambiguously13 (eg13 L2CAP13 used13 by13 both13 BLE13 and13 standard13 Bluetooth13 so13 avoid13 rdquocoap+l2caprdquo13 or13 rdquotransport=l2caprdquo13 or13 rdquoq=l2caprdquondash Can13 be13 done13 as13 WG13 consensusndash Namespace13 approach13 eg13 rdquocoap+blel2caprdquo13 or13 rdquoq=blel2caprdquo
bull Allow13 end-shy‐points13 to13 use13 CoAP13 Resource13 Directory13 to13 register13 alternave13 transports13 and13 idenfiers13 and13 provide13 periodic13 updatesndash Register13 rdquocore-shy‐transportrdquo13 resource13 type
62
031113
Transport13 Consideraons
bull Uniqueness13 of13 end-shy‐point13 idenficaonbull Communicaon13 support13 Unidireconal13 Bidireconal13 1N13 (broadcast13 mulcast13 anycast)13 messaging
bull Binary13 encoding13 Network13 byte13 orderingbull MTU13 correlaon13 with13 CoAP13 PDU13 sizebull Transport13 latency
63
031113
Security13 Consideraons
bull Drar13 does13 not13 introduce13 new13 security13 requirements13 by13 itself
bull There13 may13 be13 privacy13 issues13 if13 nodes13 use13 telephone13 numbers13 or13 MAC13 addresses13 as13 public13 end13 point13 idenfiers
64
Akbar Rahman
IETF 86 March 2013 httpwwwietforgiddraft-rahman-core-sleepy-02txt
Enhanced Sleepy Node Support for CoAP
Introduction
It is expected that in CoAP networks there will be a certain portion of devices that are sleepy and which may occasionally go into a sleep mode (ie go into a low power state to conserve power) and subsequently have reduced CoAP protocol communication ability
This I-D proposes a minimal and efficient mechanism building on the Resource Directory concept (which will be integrated into a CoAP Proxy) to enhance sleepy node support in CoAP networks
Main Question from IETF-85 (Atlanta)
What performance benefit does the proposed Sleepy Node support solution give in a network that already has standard CoAP caching enabled
Sleepy Node Performance Analysis
Experimental Network
1-5 clients
Both Sleepy and Non-
Sleepy servers
Sleepy Node Performance Analysis Network Setup
CoAPSleepyServer(s)
CoAPSleepAwareReverseProxy
CoAP
Client(s)
Request
Response
Sleep9AwareCoREResourceDirectoryCapability
PublishedSleepParameters
Sleep9AwareCoAPStoreandForwardCapability Response
Request
SleepAwareCoAP503ResponseCapability
CoAPCachingCapability
bull Server supports publishing sleep parameters to proxy bull Eg Irsquom going to be asleep for X seconds
bull Proxy supports sleep-awareness capabilities bull Proxy also supports caching capability based off of maxAge bull Protocol flow similar to approach of Figure 1 (Synchronous RD Based Sleep
Tracking) of I-D
Proxy capabilities can be selectively enableddisabled
Proxy ndash Server Interface
Client ndash Proxy Interface
CoAP Sleep-Aware Reverse Proxy Features CoRE Sleep-aware Resource Directory
Support storing published sleep parameters from CoAP servers sleepState (AWAKE ASLEEP) sleepDuration
Sleep-aware CoAP 503 Response Capability If CoAP request to a sleeping server is received proxy returns a
lsquo503 Retry-Afterrsquo response to client 503 contains a timestamp indicating when the sever will wake back up
(timestamp delivered in CoAP maxAge option) Sleep-aware CoAP Store-and-Forward Capability
If CoAP request to a sleeping server is received proxy stores request until server wakes up and then forwards it
Caching capability Cache GET responses from server if maxAge option is present
(this is not a sleep aware feature)
Goals of Performance Analysis
For networks having sleepy servers provide measurements to quantify the impact that CoAP sleep-awareness capabilities can have
See if sleep-awareness capabilities can
provide additional benefits even when CoAP caching is used
Overview of Performance Analysis Performed The analysis was broken up into a set of test scenarios Each test scenario used a different combination of the following
variables Client issued GET requests Server was configured as a sleepy or non-sleepy server Proxy caching of GET responses was enabled or disabled Proxy sleep-aware 503 response capability was enabled or disabled Proxy store-and-forward capability was enabled or disabled maxAge in GET responses ndash Two values were tested 60sec and 5sec of Clients ndash Two values were used ndash 1 client and 5 clients
For comparison purposes the following were held constant across all test scenarios Client issued a fixed number of requests (100) across all test scenarios Client used a delay between each GET request (35sec) to better exercise
proxyrsquos caching and sleep-awareness capabilities For sleepy server test scenarios the server slept 60 sec awake for 3 sec
Format of Results The following results were collected for each
test scenario
Breakdown of the and types of transactions occurring between clientproxyserver
ldquoGETrdquo ndash Test Scenario Results
GET ndash Description of Test Scenarios
TestScenarios-GET
Scenario
CoAPSleepyServerSe7ngs CoAPSleepAwareReverseProxySe7ngs CoAPClientSe7ngs
SleepDuragton(sec)
AwakeDuragton(sec)
maxAge(sec) Caching SleepAwareSAF+
503NumberofClients
NumberofGETs
DelayBetweenClient
Requests(sec)
1a 0 Always 60 Enabled Disabled 1 100 35
1b 60 3 60 Enabled Disabled 1 100 35
1c 60 3 60 Enabled Enabled 1 100 35
2a 0 Always 60 Enabled Disabled 5 100 35
2b 60 3 60 Enabled Disabled 5 100 35
2c 60 3 60 Enabled Enabled 5 100 35
3a 0 Always 5 Enabled Disabled 5 100 35
3b 60 3 5 Enabled Disabled 5 100 35
3c 60 3 5 Enabled Enabled 5 100 35
ldquoGETrdquo ndash Test Scenario 1 Results
maxAge = 60 and 1 Client
GET ndash Scenario 1 ClientProxy Interface Transaction Mix
Scenarios 1a - Non-Sleepy Server Caching Proxy maxAge = 60sec 1b- Sleepy Server Caching Proxy maxAge = 60sec 1c - Sleepy Server Sleep Aware Proxy maxAge = 60sec
Sleep Aware Proxy has better performance for sleepy servers
0
100
200
300
400
500
600
700
1a 1b 1c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
GET ndash Scenario 1 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
Scenarios 1a - Non-Sleepy Server Caching Proxy maxAge = 60sec 1b- Sleepy Server Caching Proxy maxAge = 60sec 1c - Sleepy Server Sleep Aware Proxy maxAge = 60sec
0
100
200
300
400
500
600
700
800
1a 1b 1c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
ldquoGETrdquo ndash Test Scenario 2 Results
maxAge = 60 and 5 Clients
GET ndash Scenario 2 ClientProxy Interface Transaction Mix
Sleep Aware Proxy has slightly better performance for sleepy servers
0
200
400
600
800
1000
1200
1400
2a 2b 2c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
Scenarios 2a - Non-Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2b- Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2c - Sleepy Server Sleep Aware Proxy maxAge = 60sec 5 Clients
See ldquoExperimental Artifactsrdquo Note 1
GET ndash Scenario 2 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has slightly better performance for sleepy servers
0
50
100
150
200
250
300
350
400
2a 2b 2c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
Scenarios 2a - Non-Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2b- Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2c - Sleepy Server Sleep Aware Proxy maxAge = 60sec 5 Clients
See ldquoExperimental Artifactsrdquo Note 2
Experimental Artifacts Note 1
Currently in the experiment the sleep aware proxy checks the cached state of a resource before putting a request into its Store-and-forward queue while a server is sleeping Once in the queue the proxy unconditionally forwards the queued requests to the server once it wakes up This is not the most efficient setup and can easily be improved If the proxy instead checks its cache again before forwarding each queued request it may not need to forward the request to the server For example if there are two queued GET requests in the proxyrsquos queue that address the same resource Only the first request needs to be sent to the server the second request can use the cached response from the first request
Note 2 Currently in the experiment the sleepy server sends a sleepState PUT request to the
proxy each time it goes to sleep This is not the most efficient setup and can easily be improved For example if the server assumes that the proxy can keep track of its ONOFF cycles with its internal timers (eg as per Fig 1 of I-D) then the number of messages from the sleepy server dramatically goes down
ldquoGETrdquo ndash Test Scenario 3 Results
maxAge = 5 and 5 Clients
GET ndash Scenario 3 ClientProxy Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
Scenarios 3a - Non-Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3b- Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3c - Sleepy Server Sleep Aware Proxy maxAge = 5sec 5 Clients
0
500
1000
1500
2000
2500
3000
3500
4000
4500
5000
3a 3b 3c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
GET ndash Scenario 3 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
0
1000
2000
3000
4000
5000
6000
7000
3a 3b 3c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
Scenarios 3a - Non-Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3b- Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3c - Sleepy Server Sleep Aware Proxy maxAge = 5sec 5 Clients
Conclusions
Conclusions These results show that sleep-aware CoAP
proxy features can significantly optimize communication with sleepy servers in most scenarios
These results also show that sleep-
awareness capabilities can provide additional benefits above and beyond CoAP caching in most scenarios
Backup
Current CoAP Support of Sleepy Node (12)
CoAP proxies can use a previously cached response to service a new GET request for a sleepy origin server (as in HTTP) But if no valid cache then proxy has to attempt to
retrieve and may fail if origin server is sleeping [I-Dietf-core-coap]
Clients can discover list of resources from RD (GET rd-lookuphellip) for sleepy servers But attempt to GET resource from sleepy origin server
may fail if origin server is sleeping [IDietf-core-link-format amp IDshelby-core-resource-
directory]
Current CoAP Support of Sleepy Node (22)
Lower layer support for sleepy nodes in most wireless technologies (eg WiFi ZigBee) But limited to MAC packet scheduling for sleepy nodes
and not aware of specific needs of IP applications (like CoAP)
Proposal ndash RD Based Sleep Tracking (14)
The current CoAP approach to support sleepy nodes can be significantly improved by introducing RD based mechanisms for a CoAP client to determine whether A targeted resource is located on a sleepy server A sleepy server is currently in sleep mode or not
There is any associated caching Proxy (possibly the RD itself) for a sleepy server
Proposal ndash RD Based Sleep Tracking (24)
We define the following new RD attributes to characterize the properties of a sleepy node SleepState - Indicates whether the node is currently in
sleep mode or not (ie Sleeping or Awake) SleepDuration - Indicates the maximum duration of time
that the node stays in sleep mode TimeSleeping - Indicates the length of time the node
has been sleeping (ie if Sleep State = Sleeping) NextSleep - Indicates the next time the node will go to
sleep (ie if Sleep State = Awake)
CachingProxy ndash Indicates the caching proxy of the sleepy node (ie the RD itself or another node)
Proposal ndash RD Based Sleep Tracking (34)
These attributes are all server (node) level and are new parameters added to the RD URI Template Variables
Finally we also define a new lookup-type (ss) for the RD lookup interface specified in [I-Dshelby-core-resource-directory] This new lookup-type supports looking up the
ldquoSleepStaterdquo (ss) of a specified end-point
Proposal ndash RD Based Sleep Tracking (44)
The three time based parameters (SleepDuration TimeSleeping NextSleep) can be based on either an absolute network time (for a time synchronized network) or a relative local time (measured at the local node)
Following the approach of [I-Dietf-core-link-format] and [I-Dshelby-core-resource-directory] sleep parameters for sleepy servers can be stored by the server in the RD and accessed by all interested clients
Examples of using these parameters in a synchronous or asynchronous manner are shown in the I-D
http6lowappnet coreIETF86 2013-03-12-13
We assume people have read the drafts
Meetings serve to advance difficult issues by making good use of face-to-face communications
Note Well Be aware of the IPR principles according to RFC 3979 and its updates
uumlBlue sheetsuumlScribe(s)
96
drar-shy‐iep-shy‐core-shy‐coapsubmiqed13 to13 IESG
2013-shy‐03-shy‐13
97
OMA Lightweight M2M Overview(A new standard using lots of IETF specs including DTLS
CoAP Block Observe Resource Directory SenMLhellip)
Zach ShelbyCoRE WG IETF-86 Orlando
OMA Lightweight M2Mbull Open Mobile Alliance is well known for Device Management (DM)bull OMA Lightweight M2M is a new standard from the alliance
ndash Focused on constrained Cellular and sensor network M2M devicesndash Driven by leading operators and vendors
bull Scopendash Interfaces protocol amp security between Device and Serverndash Object and Resource modelndash Bootstrap Device Access Control Connectivity and Firmware Objects
bull Draft Specifications are availablendash httpmemberopenmobileallianceorgftpPublic_documentsDM
LightweightM2MPermanent_documentsOMA-TS-LightweightM2M-V1_0_0-20130301-Dzip
bull Timelinendash Requirements and Architecture completed 3Q2012ndash Spec ready for Consistency Review 2Q2013ndash Candidate Approval expected 3Q2013
2 CoRE WG IETF-86 Orlando
Architecture
3
Scope of LWM2M
CoRE WG IETF-86 Orlando
Object Model
bull A Client has one or more Object Instancesbull An Object is a collection of Resourcesbull A Resource is an atomic piece of information
ndash Read Written or Executed
bull Resources can have multiple instancesbull Objects and Resources are identified by a
16-bit Integer Instances by an 8-bit Integerbull ObjectsResources are accessed with
simple URIs Object IDObject InstanceResource ID
eg 1213
4 CoRE WG IETF-86 Orlando
CoRE WG IETF-86 Orlando
CoRE Resource Directory
draft-shelby-core-resource-directory-05
Z Shelby C Bormann S Krco
Backgroundbull Not a new concept
ndash think web search engine or any link directorybull Defines the interfaces to a Resource Directorybull Based on Web Linking framework and the CoRE Link Formatbull Generic REST design for use over HTTP and CoAPbull Used by OMA Lightweight M2Mbull Has already been deployed
ndash In traffic monitoring systemsndash In street lighting systemsndash For vehicular asset trackingndash By a major Cellular M2M operator
Changes since -04
bull Restricted Update to parameter updatesbull Added pagination support for the Lookup interfacebull Changed rt= to et= for the registration amp update
interfacebull Added group support
Group Management
bull RD now includes group management featuresbull New Group Function Set
ndash Register a groupbull Group name domain multicast address endpoint members
ndash Remove a groupbull Group lookup using the Lookup Function Set
ndash List registered groupsndash Find the members of a groupndash Find groups with certain endpoints or resources
Registering a Group
EP RD
| |
| - POST rd-groupgp=lights ltgtep=node1 --gt |
| |
| |
| lt---- 201 Created Location rd-group12 ---- |
| |
Req POST coaprdexamplecomrd-groupgp=lights
Payload
ltgtep=node1
ltgtep=node2
Res 201 Created
Location rd-group12
Looking up Group Members
Client RD
| |
| ----- GET rd-lookupepgp=lights1 ----------------------gt |
| |
| |
| lt-- 205 Content ltrdgtd=domain1ltrdgtd=domain2 --------- |
| |
Req GET rd-lookupepgp=lights1
Res 205 Content
ltcoaphostportgtep=node1
ltcoaphostportgtep=node2rdquo
Things for the futurebull Support for JSON representation of Web Links
ndash httptoolsietforgiddraft-bormann-core-links-json-02txtbull Registry for RD registration query parameters
ndash Already OMA Lightweight has defined some new onesbull More examples
Group 3 ldquonew workrdquo(continued)
109
drar-shy‐greevenbosch-shy‐core-shy‐profile-shy‐descripon-shy‐01Bert13 GreevenboschJeroen13 Hoebeke
Isam13 IshaqFloris13 Van13 den13 Abeele
Descripon
bull JSON13 format13 for13 signalling13 the13 servers13 capabilies
bull Signalling13 of13 supported13 opons13 media13 types13 and13 block13 sizendash Other13 items13 can13 be13 added
bull Filtering13 on13 specific13 fields13 through13 URI-shy‐Querybull Link13 hqpdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐profile-shy‐descripon
well-shy‐knownprofile
bull To13 acquire13 profile13 data13 of13 resources13 on13 a13 parcular13 service13 the13 well-shy‐knownprofile13 URI-shy‐path13 is13 introduced
bull For13 example13 to13 get13 all13 informaon13 from13 sensors13 served13 by13 wwwexampleorg13 we13 can13 do13 a13 GET13 to13 coapwwwexampleorgwell-shy‐knownprofile
bull Filtering13 on13 parcular13 resources13 is13 done13 through13 URI-shy‐Queries
Format
bull Currently13 the13 following13 fields13 are13 definedndash ldquopathrdquo13 contains13 the13 URI-shy‐path13 associated13 with13 a13 resource
ndash ldquooprdquo13 a13 numerical13 list13 of13 supported13 opon13 numbers
ndash ldquocfrdquo13 a13 numerical13 list13 of13 supported13 content-shy‐format13 numbers
ndash ldquob1srdquo13 ldquob2srdquo13 supported13 block13 sizes13 for13 Block113 and13 Block213 respecvely
Examplebull On13 the13 right13 is13 an13 example13 of13 a13 camera13 sensor13 at13 coapwwwexampleorgcam13 that13 supports13 the13 Uri-shy‐Host13 (3)13 ETag13 (4)13 Uri-shy‐Port13 (7)13 Uri-shy‐Path13 (11)13 Content-shy‐Format13 (12)13 Token13 (19)13 Block213 (23)13 and13 Proxy-shy‐Uri13 (35)13 opons
bull The13 supported13 content13 formats13 are13 textplain13 (0)13 applicaon13 link-shy‐format13 (40)13 and13 applicaonjson13 (50)
bull The13 supported13 Block213 can13 use13 25613 or13 51213 byte13 blocks
Req13 GET13 coapwwwexampleorgwell-shy‐knownprofile13 Res13 20513 Content13 (applicationjson)13 13 13 13 profile13 13 13 13 13 13 13 13 pathcam13 13 13 13 op[3471112192335]13 13 13 13 13 cf[04050]13 13 13 13 13 b2s[45]13 13 13 13
Filtering13 through13 use13 of13 URI-shy‐Query
bull Filtering13 can13 be13 done13 through13 the13 URI-shy‐Querybull Query13 format13 N=V
ndash N13 is13 a13 profile13 fieldndash V13 is13 the13 desired13 value
bull Examplesndash To13 find13 resources13 that13 support13 content13 format13 ldquoapplicaonjsonrdquo
13 GET13 wwwexampleorgwell-shy‐knownprofilecf=50ndash To13 get13 informaon13 about13 the13 camera
13 GET13 wwwexampleorgwell-shy‐knownprofilepath=cam
Open13 issues
bull Which13 other13 profile13 data13 needs13 signallingndash Content-shy‐type13 for13 different13 methods
bull Fix13 the13 order13 in13 which13 the13 profile13 fields13 must13 appearndash Non-shy‐fixed13 order13 easier13 extensible
bull Inheritance13 of13 a13 profile13 descriponbull Extend13 usage13 to13 signal13 the13 client13 profilebull Integraon13 with13 link13 format
Thank13 youQuesons
drar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval-shy‐00
Bert13 Greevenbosch
Descripon
bull The13 ldquoMinimumRequestInterval13 opon13 can13 be13 used13 to13 indicate13 the13 minimum13 me13 between13 two13 requests13 in13 a13 transacon
bull Originally13 intended13 for13 Block13 but13 also13 usable13 for13 other13 transaconsndash Example13 browsing13 a13 server
bull The13 goal13 is13 to13 reduce13 the13 server13 load13 and13 network13 traffic
bull Link13 hqpsdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval
Usage
bull The13 client13 keeps13 the13 server13 informed13 about13 its13 request13 speed13 through13 inclusion13 of13 the13 ldquoMinimumRequestIntervalrdquo13 opon
bull In13 responses13 the13 server13 fixes13 the13 minimum13 request13 interval13 through13 the13 same13 opon
bull The13 client13 obeys13 the13 speed13 indicated13 by13 the13 server
bull The13 client13 can13 send13 slower13 but13 not13 faster
Advantages
bull The13 server13 has13 means13 to13 limit13 the13 amount13 of13 incoming13 traffic
bull The13 server13 can13 prevent13 to13 become13 overloaded13 with13 too13 many13 tasks
bull The13 server13 does13 not13 need13 arficially13 slow13 down13 the13 client13 by13 sending13 late13 ACKsndash No13 need13 to13 keep13 track13 of13 delayed13 ACKsndash The13 server13 can13 perform13 other13 tasks13 instead
bull Reduced13 network13 traffic
Thank13 youQuesons
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-links-json-02txt
123
RFC 6690 (link-format) documents are somewhat foreign to many web app developerssect would prefer to have them in JSON format
There is no standard way to represent link-format documents in applicationssect but everyone knows how to handle JSON
Define a standard JSON translation for link-format
Itrsquos
not
rock
et
scien
ce
ltsensorsgtct=40title=Sensor Index ltsensorstempgtrt=temperature-cif=sensor ltsensorslightgtrt=light-luxif=sensor lthttpwwwexamplecomsensorst123gt anchor=sensorstemprel=describedby lttgtanchor=sensorstemprel=alternate [hrefsensorsct40titleSensor Index hrefsensorstemprttemperature-cifsensor hrefsensorslightrtlight-luxifsensor hrefhttpwwwexamplecomsensorst123 anchorsensorstempreldescribedby hreftanchorsensorstemprelalternate]
124
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-ipsec-for-coap-00txt
IPsec definitions for CoAP Mostly placeholder at this time Who has implementation experience with this
125
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-cross-reverse-convention-00txt
This draft has two lines of payload(based on a WGLC comment by Cullen Jennings)
coap12344567foobara=3
httpwwwproxycomwellknowncore-translate1234_4567foobara=3
Is that a useful convention to have
126
Insert CI slides here
127
128
0
5
10
15
20
25
30
35
40
10 20 30 40 50 60 70
good
put (
pps)
pps
Goodput vs pps (Econotags)
goodput
[Khattak preliminary]
Congestion Control
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-cocoa-00txt
ldquoadvancedrdquo cc (The draft is just a first shot) Others may have better ideas
129
Insert post-WGLC discussion slides here
130
Stop Continue Start
131
An Agile Retrospective
http6lowappnet coreIETF86 2013-03-12-13
Stop
132
Endless new CoAP optionssect instead use RESTful as much as possible
Move general security lifecycle out Looking at theoretical problems
http6lowappnet coreIETF86 2013-03-12-13
Continue
Interops Running code Look at real-world examples and deployments Solve their actual problems
sect Unilateral enhancements eg higher performance congestion control
sect Transports (SMS hellip)sect Make Web linking and Directories more and more usefulsect RESTful Design Paradigms for real-world problems
133
http6lowappnet coreIETF86 2013-03-12-13
Start
Further push into the (browser) web world (HTML5 browser security)
Specific supporting worksect SenMLsect URI work (dev URN hellip)sect Security Processes (next slide)
Spin outsect (We donrsquot really get to decide where this is done)
134
http6lowappnet coreIETF86 2013-03-12-13
Security
Integrate Application Network Group Keyingsect Tunnel-free setup
Donrsquot redo what has been done alreadysect ZigBee IP is finesect But what about other scenarios
Simple REST interfaces for working with keying materials and authorizationsect Start with defining objectives
Object Security for Constrained Nodes135
Re-chartering CoREWhat do we want to do now that wersquore grown up
Zach ShelbyCoRE WG IETF-86 Orlando
What is the scope
bull So we have a protocol and Web Linking what next
bull Keep with what we know besthellip1 Enhancements around CoAP2 New transports for CoAP3 New representations for Web Links4 General application layer solutions
CoRE WG IETF-86 Orlando 2
Enhancements around CoAP
bull Advanced congestion control
CoRE WG IETF-86 Orlando 3
New Transports for CoAP
bull Infrastructure for CoAP over foondash httptoolsietforgiddraft-silverajan-core-
coap-alternative-transports-01txtbull CoAP over SMS
ndash httptoolsietforgiddraft-becker-core-coap-sms-gprs-03txt
ndash OMA Lightweightbull CoAP over TCP
ndash httptoolsietforgiddraft-li-core-coap-payload-length-option-01txt
CoRE WG IETF-86 Orlando 4
New support for Web Links
bull JSON Web Linksndash httptoolsietforgiddraft-bormann-core-links-
json-02txt
2332010 CoRE WG IETF-77 Anaheim 5
General application layer solutions
bull Resource Directoryndash httptoolsietforgiddraft-shelby-core-
resource-directory-05txtndash OMA Lightweight
2332010 CoRE WG IETF-77 Anaheim 6
Feedback Potential Threats
I Trigger expensive short messagesI Redirect trac to other addressesI More threats
I Are the security measures in the draft adequateI Whitelisting on serverI Relying on cellular network security (dedicated M2M APNs)I Object security on CoAP payload
8 10
Feedback Message Exchanges
I Figures 11-18 show possible message exchanges whenclient and server have two addresses
I With NON Not using CoAP retransmission capabilityI ACK on different transportI Additional (costly) message on Transport AI Request with Content
I Which ones are allowedI Which ones are meaningful
9 10
Next steps
I Rene Uri schemeI Response-To-Scheme optionI Selection of Message ExchangeI Rene Proxying
10 10
CoAP13 Communicaon13 with13 Alternave13 Transports
Bill Silverajan and Teemu SavolainenCore WG IETF 86 Orlando
031113
Objecves13 (In13 Scope)
bull Unambiguous13 representaon13 of13 transport13 to13 be13 used13 by13 CoAP
bull Details13 how13 the13 transport13 can13 carry13 CoAP13 packet
bull Focus13 is13 on13 what13 CoAP13 communicaons13 requirements13 are
bull Allow13 CoAP13 mechanisms13 to13 exploit13 cross-shy‐layer13 opmisaons
51
031113
Non13 Goals13 (Not13 in13 scope)
bull Applicaon-shy‐level13 QoS13 requirementsbull Real-shy‐me13 constraintsbull Ordering13 reliability13 congeson13 controlbull Applicaon13 and13 network13 adaptaonbull Mobility13 and13 readdressing13 supportbull Network13 protocol13 (eg13 IPsec)13 configuraon
52
031113
Use13 Cases
bull NAT13 and13 Firewall13 traversal13 with13 TCPbull Delay13 Tolerant13 Networkingbull Non-shy‐IP13 Low13 Energy13 Protocols
53
031113
Related13 Work
bull OMA13 Lightweight13 M2M13 Protocolbull CoAP13 over13 SMSGPRSUSSD
54
031113
What13 does13 the13 work13 entail
bull The13 ability13 to13 specify13 end13 point13 idenfiers13 and13 URIs13 to13 reflect13 which13 transport13 CoAP13 can13 use
bull The13 ability13 to13 register13 to13 resource13 directories13 resource13 types13 reflecng13 types13 of13 transport13 available
bull Ability13 for13 mul-shy‐transport13 nodes13 to13 select13 transport13 to13 use13 without13 significant13 alteraon13 to13 CoAP13 packet13 structure
55
031113
Points13 to13 consider
bull Requirements13 for13 transport13 layer13 protocol13 to13 carry13 CoAP13 packets
bull Representaon13 of13 URI13 scheme13 for13 generic13 transport13 protocols
bull Opon13 extensions13 for13 CoAP13 to13 express13 available13 transports
bull Mapping13 and13 message13 sizebull Security13 consideraons
56
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
URI13 =13 scheme13 13 13 authority13 path-shy‐abempty13 [13 query13 ]
bull Within13 the13 scheme13 namebull In13 the13 URI13 pathbull As13 a13 query13 component
57
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
bull Within13 the13 scheme13 namendash coap+tel+15105550101well-shy‐knowncorendash coap+tcpexamplecom5683temperaturendash coap+blel2cap[1234567890AB]4pulse
bull Easy13 URI13 parsing13 for13 transport13 type13 and13 idenfier
bull Each13 new13 scheme13 name13 requires13 IANA13 registraon
58
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
bull In13 the13 URI13 pathndash coaphostexamplecomtransport=tcpwell-shy‐knowncorert=core-shy‐rd
bull Easy13 adopon13 of13 new13 (and13 experimental)13 CoAP13 transports13 without13 IANA13 registraon
bull Caveat13 Uri-shy‐Path13 opon13 is13 a13 Crical13 CoAP13 opon13 see13 secon13 54113 of13 I-shy‐Diep-shy‐core-shy‐coap
59
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
bull As13 a13 URI13 query13 componentndash coaphostexamplecomwell-shy‐knowncorert=core-shy‐rdq=tcp
bull Also13 easy13 to13 adopt13 new13 (and13 experimental)13 CoAP13 transports13 without13 IANA13 registraon
bull Caveat13 Uri-shy‐Query13 opon13 is13 a13 Crical13 CoAP13 opon13 see13 secon13 54113 of13 I-shy‐Diep-shy‐core-shy‐coap
60
031113
URI13 Representaons13 for13 CoAPNon13 standard13 ways
bull Transport13 in13 the13 URI13 authority13 componentndash coaphost[port][transport]13 instead13 of13 coaphost[port]
bull Transport13 as13 a13 service13 URLndash servicecoaptcphostexamplecomwell-shy‐knowncorert=core-shy‐rd
bull Above13 two13 ways13 break13 exisng13 compability13 (although13 both13 are13 based13 on13 valid13 IANA13 URI13 registraons)
61
031113
URI13 Representaons13 for13 CoAPMiscellaneous13 Consideraons
bull Ensure13 that13 transport13 is13 defined13 unambiguously13 (eg13 L2CAP13 used13 by13 both13 BLE13 and13 standard13 Bluetooth13 so13 avoid13 rdquocoap+l2caprdquo13 or13 rdquotransport=l2caprdquo13 or13 rdquoq=l2caprdquondash Can13 be13 done13 as13 WG13 consensusndash Namespace13 approach13 eg13 rdquocoap+blel2caprdquo13 or13 rdquoq=blel2caprdquo
bull Allow13 end-shy‐points13 to13 use13 CoAP13 Resource13 Directory13 to13 register13 alternave13 transports13 and13 idenfiers13 and13 provide13 periodic13 updatesndash Register13 rdquocore-shy‐transportrdquo13 resource13 type
62
031113
Transport13 Consideraons
bull Uniqueness13 of13 end-shy‐point13 idenficaonbull Communicaon13 support13 Unidireconal13 Bidireconal13 1N13 (broadcast13 mulcast13 anycast)13 messaging
bull Binary13 encoding13 Network13 byte13 orderingbull MTU13 correlaon13 with13 CoAP13 PDU13 sizebull Transport13 latency
63
031113
Security13 Consideraons
bull Drar13 does13 not13 introduce13 new13 security13 requirements13 by13 itself
bull There13 may13 be13 privacy13 issues13 if13 nodes13 use13 telephone13 numbers13 or13 MAC13 addresses13 as13 public13 end13 point13 idenfiers
64
Akbar Rahman
IETF 86 March 2013 httpwwwietforgiddraft-rahman-core-sleepy-02txt
Enhanced Sleepy Node Support for CoAP
Introduction
It is expected that in CoAP networks there will be a certain portion of devices that are sleepy and which may occasionally go into a sleep mode (ie go into a low power state to conserve power) and subsequently have reduced CoAP protocol communication ability
This I-D proposes a minimal and efficient mechanism building on the Resource Directory concept (which will be integrated into a CoAP Proxy) to enhance sleepy node support in CoAP networks
Main Question from IETF-85 (Atlanta)
What performance benefit does the proposed Sleepy Node support solution give in a network that already has standard CoAP caching enabled
Sleepy Node Performance Analysis
Experimental Network
1-5 clients
Both Sleepy and Non-
Sleepy servers
Sleepy Node Performance Analysis Network Setup
CoAPSleepyServer(s)
CoAPSleepAwareReverseProxy
CoAP
Client(s)
Request
Response
Sleep9AwareCoREResourceDirectoryCapability
PublishedSleepParameters
Sleep9AwareCoAPStoreandForwardCapability Response
Request
SleepAwareCoAP503ResponseCapability
CoAPCachingCapability
bull Server supports publishing sleep parameters to proxy bull Eg Irsquom going to be asleep for X seconds
bull Proxy supports sleep-awareness capabilities bull Proxy also supports caching capability based off of maxAge bull Protocol flow similar to approach of Figure 1 (Synchronous RD Based Sleep
Tracking) of I-D
Proxy capabilities can be selectively enableddisabled
Proxy ndash Server Interface
Client ndash Proxy Interface
CoAP Sleep-Aware Reverse Proxy Features CoRE Sleep-aware Resource Directory
Support storing published sleep parameters from CoAP servers sleepState (AWAKE ASLEEP) sleepDuration
Sleep-aware CoAP 503 Response Capability If CoAP request to a sleeping server is received proxy returns a
lsquo503 Retry-Afterrsquo response to client 503 contains a timestamp indicating when the sever will wake back up
(timestamp delivered in CoAP maxAge option) Sleep-aware CoAP Store-and-Forward Capability
If CoAP request to a sleeping server is received proxy stores request until server wakes up and then forwards it
Caching capability Cache GET responses from server if maxAge option is present
(this is not a sleep aware feature)
Goals of Performance Analysis
For networks having sleepy servers provide measurements to quantify the impact that CoAP sleep-awareness capabilities can have
See if sleep-awareness capabilities can
provide additional benefits even when CoAP caching is used
Overview of Performance Analysis Performed The analysis was broken up into a set of test scenarios Each test scenario used a different combination of the following
variables Client issued GET requests Server was configured as a sleepy or non-sleepy server Proxy caching of GET responses was enabled or disabled Proxy sleep-aware 503 response capability was enabled or disabled Proxy store-and-forward capability was enabled or disabled maxAge in GET responses ndash Two values were tested 60sec and 5sec of Clients ndash Two values were used ndash 1 client and 5 clients
For comparison purposes the following were held constant across all test scenarios Client issued a fixed number of requests (100) across all test scenarios Client used a delay between each GET request (35sec) to better exercise
proxyrsquos caching and sleep-awareness capabilities For sleepy server test scenarios the server slept 60 sec awake for 3 sec
Format of Results The following results were collected for each
test scenario
Breakdown of the and types of transactions occurring between clientproxyserver
ldquoGETrdquo ndash Test Scenario Results
GET ndash Description of Test Scenarios
TestScenarios-GET
Scenario
CoAPSleepyServerSe7ngs CoAPSleepAwareReverseProxySe7ngs CoAPClientSe7ngs
SleepDuragton(sec)
AwakeDuragton(sec)
maxAge(sec) Caching SleepAwareSAF+
503NumberofClients
NumberofGETs
DelayBetweenClient
Requests(sec)
1a 0 Always 60 Enabled Disabled 1 100 35
1b 60 3 60 Enabled Disabled 1 100 35
1c 60 3 60 Enabled Enabled 1 100 35
2a 0 Always 60 Enabled Disabled 5 100 35
2b 60 3 60 Enabled Disabled 5 100 35
2c 60 3 60 Enabled Enabled 5 100 35
3a 0 Always 5 Enabled Disabled 5 100 35
3b 60 3 5 Enabled Disabled 5 100 35
3c 60 3 5 Enabled Enabled 5 100 35
ldquoGETrdquo ndash Test Scenario 1 Results
maxAge = 60 and 1 Client
GET ndash Scenario 1 ClientProxy Interface Transaction Mix
Scenarios 1a - Non-Sleepy Server Caching Proxy maxAge = 60sec 1b- Sleepy Server Caching Proxy maxAge = 60sec 1c - Sleepy Server Sleep Aware Proxy maxAge = 60sec
Sleep Aware Proxy has better performance for sleepy servers
0
100
200
300
400
500
600
700
1a 1b 1c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
GET ndash Scenario 1 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
Scenarios 1a - Non-Sleepy Server Caching Proxy maxAge = 60sec 1b- Sleepy Server Caching Proxy maxAge = 60sec 1c - Sleepy Server Sleep Aware Proxy maxAge = 60sec
0
100
200
300
400
500
600
700
800
1a 1b 1c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
ldquoGETrdquo ndash Test Scenario 2 Results
maxAge = 60 and 5 Clients
GET ndash Scenario 2 ClientProxy Interface Transaction Mix
Sleep Aware Proxy has slightly better performance for sleepy servers
0
200
400
600
800
1000
1200
1400
2a 2b 2c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
Scenarios 2a - Non-Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2b- Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2c - Sleepy Server Sleep Aware Proxy maxAge = 60sec 5 Clients
See ldquoExperimental Artifactsrdquo Note 1
GET ndash Scenario 2 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has slightly better performance for sleepy servers
0
50
100
150
200
250
300
350
400
2a 2b 2c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
Scenarios 2a - Non-Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2b- Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2c - Sleepy Server Sleep Aware Proxy maxAge = 60sec 5 Clients
See ldquoExperimental Artifactsrdquo Note 2
Experimental Artifacts Note 1
Currently in the experiment the sleep aware proxy checks the cached state of a resource before putting a request into its Store-and-forward queue while a server is sleeping Once in the queue the proxy unconditionally forwards the queued requests to the server once it wakes up This is not the most efficient setup and can easily be improved If the proxy instead checks its cache again before forwarding each queued request it may not need to forward the request to the server For example if there are two queued GET requests in the proxyrsquos queue that address the same resource Only the first request needs to be sent to the server the second request can use the cached response from the first request
Note 2 Currently in the experiment the sleepy server sends a sleepState PUT request to the
proxy each time it goes to sleep This is not the most efficient setup and can easily be improved For example if the server assumes that the proxy can keep track of its ONOFF cycles with its internal timers (eg as per Fig 1 of I-D) then the number of messages from the sleepy server dramatically goes down
ldquoGETrdquo ndash Test Scenario 3 Results
maxAge = 5 and 5 Clients
GET ndash Scenario 3 ClientProxy Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
Scenarios 3a - Non-Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3b- Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3c - Sleepy Server Sleep Aware Proxy maxAge = 5sec 5 Clients
0
500
1000
1500
2000
2500
3000
3500
4000
4500
5000
3a 3b 3c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
GET ndash Scenario 3 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
0
1000
2000
3000
4000
5000
6000
7000
3a 3b 3c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
Scenarios 3a - Non-Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3b- Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3c - Sleepy Server Sleep Aware Proxy maxAge = 5sec 5 Clients
Conclusions
Conclusions These results show that sleep-aware CoAP
proxy features can significantly optimize communication with sleepy servers in most scenarios
These results also show that sleep-
awareness capabilities can provide additional benefits above and beyond CoAP caching in most scenarios
Backup
Current CoAP Support of Sleepy Node (12)
CoAP proxies can use a previously cached response to service a new GET request for a sleepy origin server (as in HTTP) But if no valid cache then proxy has to attempt to
retrieve and may fail if origin server is sleeping [I-Dietf-core-coap]
Clients can discover list of resources from RD (GET rd-lookuphellip) for sleepy servers But attempt to GET resource from sleepy origin server
may fail if origin server is sleeping [IDietf-core-link-format amp IDshelby-core-resource-
directory]
Current CoAP Support of Sleepy Node (22)
Lower layer support for sleepy nodes in most wireless technologies (eg WiFi ZigBee) But limited to MAC packet scheduling for sleepy nodes
and not aware of specific needs of IP applications (like CoAP)
Proposal ndash RD Based Sleep Tracking (14)
The current CoAP approach to support sleepy nodes can be significantly improved by introducing RD based mechanisms for a CoAP client to determine whether A targeted resource is located on a sleepy server A sleepy server is currently in sleep mode or not
There is any associated caching Proxy (possibly the RD itself) for a sleepy server
Proposal ndash RD Based Sleep Tracking (24)
We define the following new RD attributes to characterize the properties of a sleepy node SleepState - Indicates whether the node is currently in
sleep mode or not (ie Sleeping or Awake) SleepDuration - Indicates the maximum duration of time
that the node stays in sleep mode TimeSleeping - Indicates the length of time the node
has been sleeping (ie if Sleep State = Sleeping) NextSleep - Indicates the next time the node will go to
sleep (ie if Sleep State = Awake)
CachingProxy ndash Indicates the caching proxy of the sleepy node (ie the RD itself or another node)
Proposal ndash RD Based Sleep Tracking (34)
These attributes are all server (node) level and are new parameters added to the RD URI Template Variables
Finally we also define a new lookup-type (ss) for the RD lookup interface specified in [I-Dshelby-core-resource-directory] This new lookup-type supports looking up the
ldquoSleepStaterdquo (ss) of a specified end-point
Proposal ndash RD Based Sleep Tracking (44)
The three time based parameters (SleepDuration TimeSleeping NextSleep) can be based on either an absolute network time (for a time synchronized network) or a relative local time (measured at the local node)
Following the approach of [I-Dietf-core-link-format] and [I-Dshelby-core-resource-directory] sleep parameters for sleepy servers can be stored by the server in the RD and accessed by all interested clients
Examples of using these parameters in a synchronous or asynchronous manner are shown in the I-D
http6lowappnet coreIETF86 2013-03-12-13
We assume people have read the drafts
Meetings serve to advance difficult issues by making good use of face-to-face communications
Note Well Be aware of the IPR principles according to RFC 3979 and its updates
uumlBlue sheetsuumlScribe(s)
96
drar-shy‐iep-shy‐core-shy‐coapsubmiqed13 to13 IESG
2013-shy‐03-shy‐13
97
OMA Lightweight M2M Overview(A new standard using lots of IETF specs including DTLS
CoAP Block Observe Resource Directory SenMLhellip)
Zach ShelbyCoRE WG IETF-86 Orlando
OMA Lightweight M2Mbull Open Mobile Alliance is well known for Device Management (DM)bull OMA Lightweight M2M is a new standard from the alliance
ndash Focused on constrained Cellular and sensor network M2M devicesndash Driven by leading operators and vendors
bull Scopendash Interfaces protocol amp security between Device and Serverndash Object and Resource modelndash Bootstrap Device Access Control Connectivity and Firmware Objects
bull Draft Specifications are availablendash httpmemberopenmobileallianceorgftpPublic_documentsDM
LightweightM2MPermanent_documentsOMA-TS-LightweightM2M-V1_0_0-20130301-Dzip
bull Timelinendash Requirements and Architecture completed 3Q2012ndash Spec ready for Consistency Review 2Q2013ndash Candidate Approval expected 3Q2013
2 CoRE WG IETF-86 Orlando
Architecture
3
Scope of LWM2M
CoRE WG IETF-86 Orlando
Object Model
bull A Client has one or more Object Instancesbull An Object is a collection of Resourcesbull A Resource is an atomic piece of information
ndash Read Written or Executed
bull Resources can have multiple instancesbull Objects and Resources are identified by a
16-bit Integer Instances by an 8-bit Integerbull ObjectsResources are accessed with
simple URIs Object IDObject InstanceResource ID
eg 1213
4 CoRE WG IETF-86 Orlando
CoRE WG IETF-86 Orlando
CoRE Resource Directory
draft-shelby-core-resource-directory-05
Z Shelby C Bormann S Krco
Backgroundbull Not a new concept
ndash think web search engine or any link directorybull Defines the interfaces to a Resource Directorybull Based on Web Linking framework and the CoRE Link Formatbull Generic REST design for use over HTTP and CoAPbull Used by OMA Lightweight M2Mbull Has already been deployed
ndash In traffic monitoring systemsndash In street lighting systemsndash For vehicular asset trackingndash By a major Cellular M2M operator
Changes since -04
bull Restricted Update to parameter updatesbull Added pagination support for the Lookup interfacebull Changed rt= to et= for the registration amp update
interfacebull Added group support
Group Management
bull RD now includes group management featuresbull New Group Function Set
ndash Register a groupbull Group name domain multicast address endpoint members
ndash Remove a groupbull Group lookup using the Lookup Function Set
ndash List registered groupsndash Find the members of a groupndash Find groups with certain endpoints or resources
Registering a Group
EP RD
| |
| - POST rd-groupgp=lights ltgtep=node1 --gt |
| |
| |
| lt---- 201 Created Location rd-group12 ---- |
| |
Req POST coaprdexamplecomrd-groupgp=lights
Payload
ltgtep=node1
ltgtep=node2
Res 201 Created
Location rd-group12
Looking up Group Members
Client RD
| |
| ----- GET rd-lookupepgp=lights1 ----------------------gt |
| |
| |
| lt-- 205 Content ltrdgtd=domain1ltrdgtd=domain2 --------- |
| |
Req GET rd-lookupepgp=lights1
Res 205 Content
ltcoaphostportgtep=node1
ltcoaphostportgtep=node2rdquo
Things for the futurebull Support for JSON representation of Web Links
ndash httptoolsietforgiddraft-bormann-core-links-json-02txtbull Registry for RD registration query parameters
ndash Already OMA Lightweight has defined some new onesbull More examples
Group 3 ldquonew workrdquo(continued)
109
drar-shy‐greevenbosch-shy‐core-shy‐profile-shy‐descripon-shy‐01Bert13 GreevenboschJeroen13 Hoebeke
Isam13 IshaqFloris13 Van13 den13 Abeele
Descripon
bull JSON13 format13 for13 signalling13 the13 servers13 capabilies
bull Signalling13 of13 supported13 opons13 media13 types13 and13 block13 sizendash Other13 items13 can13 be13 added
bull Filtering13 on13 specific13 fields13 through13 URI-shy‐Querybull Link13 hqpdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐profile-shy‐descripon
well-shy‐knownprofile
bull To13 acquire13 profile13 data13 of13 resources13 on13 a13 parcular13 service13 the13 well-shy‐knownprofile13 URI-shy‐path13 is13 introduced
bull For13 example13 to13 get13 all13 informaon13 from13 sensors13 served13 by13 wwwexampleorg13 we13 can13 do13 a13 GET13 to13 coapwwwexampleorgwell-shy‐knownprofile
bull Filtering13 on13 parcular13 resources13 is13 done13 through13 URI-shy‐Queries
Format
bull Currently13 the13 following13 fields13 are13 definedndash ldquopathrdquo13 contains13 the13 URI-shy‐path13 associated13 with13 a13 resource
ndash ldquooprdquo13 a13 numerical13 list13 of13 supported13 opon13 numbers
ndash ldquocfrdquo13 a13 numerical13 list13 of13 supported13 content-shy‐format13 numbers
ndash ldquob1srdquo13 ldquob2srdquo13 supported13 block13 sizes13 for13 Block113 and13 Block213 respecvely
Examplebull On13 the13 right13 is13 an13 example13 of13 a13 camera13 sensor13 at13 coapwwwexampleorgcam13 that13 supports13 the13 Uri-shy‐Host13 (3)13 ETag13 (4)13 Uri-shy‐Port13 (7)13 Uri-shy‐Path13 (11)13 Content-shy‐Format13 (12)13 Token13 (19)13 Block213 (23)13 and13 Proxy-shy‐Uri13 (35)13 opons
bull The13 supported13 content13 formats13 are13 textplain13 (0)13 applicaon13 link-shy‐format13 (40)13 and13 applicaonjson13 (50)
bull The13 supported13 Block213 can13 use13 25613 or13 51213 byte13 blocks
Req13 GET13 coapwwwexampleorgwell-shy‐knownprofile13 Res13 20513 Content13 (applicationjson)13 13 13 13 profile13 13 13 13 13 13 13 13 pathcam13 13 13 13 op[3471112192335]13 13 13 13 13 cf[04050]13 13 13 13 13 b2s[45]13 13 13 13
Filtering13 through13 use13 of13 URI-shy‐Query
bull Filtering13 can13 be13 done13 through13 the13 URI-shy‐Querybull Query13 format13 N=V
ndash N13 is13 a13 profile13 fieldndash V13 is13 the13 desired13 value
bull Examplesndash To13 find13 resources13 that13 support13 content13 format13 ldquoapplicaonjsonrdquo
13 GET13 wwwexampleorgwell-shy‐knownprofilecf=50ndash To13 get13 informaon13 about13 the13 camera
13 GET13 wwwexampleorgwell-shy‐knownprofilepath=cam
Open13 issues
bull Which13 other13 profile13 data13 needs13 signallingndash Content-shy‐type13 for13 different13 methods
bull Fix13 the13 order13 in13 which13 the13 profile13 fields13 must13 appearndash Non-shy‐fixed13 order13 easier13 extensible
bull Inheritance13 of13 a13 profile13 descriponbull Extend13 usage13 to13 signal13 the13 client13 profilebull Integraon13 with13 link13 format
Thank13 youQuesons
drar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval-shy‐00
Bert13 Greevenbosch
Descripon
bull The13 ldquoMinimumRequestInterval13 opon13 can13 be13 used13 to13 indicate13 the13 minimum13 me13 between13 two13 requests13 in13 a13 transacon
bull Originally13 intended13 for13 Block13 but13 also13 usable13 for13 other13 transaconsndash Example13 browsing13 a13 server
bull The13 goal13 is13 to13 reduce13 the13 server13 load13 and13 network13 traffic
bull Link13 hqpsdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval
Usage
bull The13 client13 keeps13 the13 server13 informed13 about13 its13 request13 speed13 through13 inclusion13 of13 the13 ldquoMinimumRequestIntervalrdquo13 opon
bull In13 responses13 the13 server13 fixes13 the13 minimum13 request13 interval13 through13 the13 same13 opon
bull The13 client13 obeys13 the13 speed13 indicated13 by13 the13 server
bull The13 client13 can13 send13 slower13 but13 not13 faster
Advantages
bull The13 server13 has13 means13 to13 limit13 the13 amount13 of13 incoming13 traffic
bull The13 server13 can13 prevent13 to13 become13 overloaded13 with13 too13 many13 tasks
bull The13 server13 does13 not13 need13 arficially13 slow13 down13 the13 client13 by13 sending13 late13 ACKsndash No13 need13 to13 keep13 track13 of13 delayed13 ACKsndash The13 server13 can13 perform13 other13 tasks13 instead
bull Reduced13 network13 traffic
Thank13 youQuesons
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-links-json-02txt
123
RFC 6690 (link-format) documents are somewhat foreign to many web app developerssect would prefer to have them in JSON format
There is no standard way to represent link-format documents in applicationssect but everyone knows how to handle JSON
Define a standard JSON translation for link-format
Itrsquos
not
rock
et
scien
ce
ltsensorsgtct=40title=Sensor Index ltsensorstempgtrt=temperature-cif=sensor ltsensorslightgtrt=light-luxif=sensor lthttpwwwexamplecomsensorst123gt anchor=sensorstemprel=describedby lttgtanchor=sensorstemprel=alternate [hrefsensorsct40titleSensor Index hrefsensorstemprttemperature-cifsensor hrefsensorslightrtlight-luxifsensor hrefhttpwwwexamplecomsensorst123 anchorsensorstempreldescribedby hreftanchorsensorstemprelalternate]
124
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-ipsec-for-coap-00txt
IPsec definitions for CoAP Mostly placeholder at this time Who has implementation experience with this
125
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-cross-reverse-convention-00txt
This draft has two lines of payload(based on a WGLC comment by Cullen Jennings)
coap12344567foobara=3
httpwwwproxycomwellknowncore-translate1234_4567foobara=3
Is that a useful convention to have
126
Insert CI slides here
127
128
0
5
10
15
20
25
30
35
40
10 20 30 40 50 60 70
good
put (
pps)
pps
Goodput vs pps (Econotags)
goodput
[Khattak preliminary]
Congestion Control
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-cocoa-00txt
ldquoadvancedrdquo cc (The draft is just a first shot) Others may have better ideas
129
Insert post-WGLC discussion slides here
130
Stop Continue Start
131
An Agile Retrospective
http6lowappnet coreIETF86 2013-03-12-13
Stop
132
Endless new CoAP optionssect instead use RESTful as much as possible
Move general security lifecycle out Looking at theoretical problems
http6lowappnet coreIETF86 2013-03-12-13
Continue
Interops Running code Look at real-world examples and deployments Solve their actual problems
sect Unilateral enhancements eg higher performance congestion control
sect Transports (SMS hellip)sect Make Web linking and Directories more and more usefulsect RESTful Design Paradigms for real-world problems
133
http6lowappnet coreIETF86 2013-03-12-13
Start
Further push into the (browser) web world (HTML5 browser security)
Specific supporting worksect SenMLsect URI work (dev URN hellip)sect Security Processes (next slide)
Spin outsect (We donrsquot really get to decide where this is done)
134
http6lowappnet coreIETF86 2013-03-12-13
Security
Integrate Application Network Group Keyingsect Tunnel-free setup
Donrsquot redo what has been done alreadysect ZigBee IP is finesect But what about other scenarios
Simple REST interfaces for working with keying materials and authorizationsect Start with defining objectives
Object Security for Constrained Nodes135
Re-chartering CoREWhat do we want to do now that wersquore grown up
Zach ShelbyCoRE WG IETF-86 Orlando
What is the scope
bull So we have a protocol and Web Linking what next
bull Keep with what we know besthellip1 Enhancements around CoAP2 New transports for CoAP3 New representations for Web Links4 General application layer solutions
CoRE WG IETF-86 Orlando 2
Enhancements around CoAP
bull Advanced congestion control
CoRE WG IETF-86 Orlando 3
New Transports for CoAP
bull Infrastructure for CoAP over foondash httptoolsietforgiddraft-silverajan-core-
coap-alternative-transports-01txtbull CoAP over SMS
ndash httptoolsietforgiddraft-becker-core-coap-sms-gprs-03txt
ndash OMA Lightweightbull CoAP over TCP
ndash httptoolsietforgiddraft-li-core-coap-payload-length-option-01txt
CoRE WG IETF-86 Orlando 4
New support for Web Links
bull JSON Web Linksndash httptoolsietforgiddraft-bormann-core-links-
json-02txt
2332010 CoRE WG IETF-77 Anaheim 5
General application layer solutions
bull Resource Directoryndash httptoolsietforgiddraft-shelby-core-
resource-directory-05txtndash OMA Lightweight
2332010 CoRE WG IETF-77 Anaheim 6
Feedback Message Exchanges
I Figures 11-18 show possible message exchanges whenclient and server have two addresses
I With NON Not using CoAP retransmission capabilityI ACK on different transportI Additional (costly) message on Transport AI Request with Content
I Which ones are allowedI Which ones are meaningful
9 10
Next steps
I Rene Uri schemeI Response-To-Scheme optionI Selection of Message ExchangeI Rene Proxying
10 10
CoAP13 Communicaon13 with13 Alternave13 Transports
Bill Silverajan and Teemu SavolainenCore WG IETF 86 Orlando
031113
Objecves13 (In13 Scope)
bull Unambiguous13 representaon13 of13 transport13 to13 be13 used13 by13 CoAP
bull Details13 how13 the13 transport13 can13 carry13 CoAP13 packet
bull Focus13 is13 on13 what13 CoAP13 communicaons13 requirements13 are
bull Allow13 CoAP13 mechanisms13 to13 exploit13 cross-shy‐layer13 opmisaons
51
031113
Non13 Goals13 (Not13 in13 scope)
bull Applicaon-shy‐level13 QoS13 requirementsbull Real-shy‐me13 constraintsbull Ordering13 reliability13 congeson13 controlbull Applicaon13 and13 network13 adaptaonbull Mobility13 and13 readdressing13 supportbull Network13 protocol13 (eg13 IPsec)13 configuraon
52
031113
Use13 Cases
bull NAT13 and13 Firewall13 traversal13 with13 TCPbull Delay13 Tolerant13 Networkingbull Non-shy‐IP13 Low13 Energy13 Protocols
53
031113
Related13 Work
bull OMA13 Lightweight13 M2M13 Protocolbull CoAP13 over13 SMSGPRSUSSD
54
031113
What13 does13 the13 work13 entail
bull The13 ability13 to13 specify13 end13 point13 idenfiers13 and13 URIs13 to13 reflect13 which13 transport13 CoAP13 can13 use
bull The13 ability13 to13 register13 to13 resource13 directories13 resource13 types13 reflecng13 types13 of13 transport13 available
bull Ability13 for13 mul-shy‐transport13 nodes13 to13 select13 transport13 to13 use13 without13 significant13 alteraon13 to13 CoAP13 packet13 structure
55
031113
Points13 to13 consider
bull Requirements13 for13 transport13 layer13 protocol13 to13 carry13 CoAP13 packets
bull Representaon13 of13 URI13 scheme13 for13 generic13 transport13 protocols
bull Opon13 extensions13 for13 CoAP13 to13 express13 available13 transports
bull Mapping13 and13 message13 sizebull Security13 consideraons
56
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
URI13 =13 scheme13 13 13 authority13 path-shy‐abempty13 [13 query13 ]
bull Within13 the13 scheme13 namebull In13 the13 URI13 pathbull As13 a13 query13 component
57
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
bull Within13 the13 scheme13 namendash coap+tel+15105550101well-shy‐knowncorendash coap+tcpexamplecom5683temperaturendash coap+blel2cap[1234567890AB]4pulse
bull Easy13 URI13 parsing13 for13 transport13 type13 and13 idenfier
bull Each13 new13 scheme13 name13 requires13 IANA13 registraon
58
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
bull In13 the13 URI13 pathndash coaphostexamplecomtransport=tcpwell-shy‐knowncorert=core-shy‐rd
bull Easy13 adopon13 of13 new13 (and13 experimental)13 CoAP13 transports13 without13 IANA13 registraon
bull Caveat13 Uri-shy‐Path13 opon13 is13 a13 Crical13 CoAP13 opon13 see13 secon13 54113 of13 I-shy‐Diep-shy‐core-shy‐coap
59
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
bull As13 a13 URI13 query13 componentndash coaphostexamplecomwell-shy‐knowncorert=core-shy‐rdq=tcp
bull Also13 easy13 to13 adopt13 new13 (and13 experimental)13 CoAP13 transports13 without13 IANA13 registraon
bull Caveat13 Uri-shy‐Query13 opon13 is13 a13 Crical13 CoAP13 opon13 see13 secon13 54113 of13 I-shy‐Diep-shy‐core-shy‐coap
60
031113
URI13 Representaons13 for13 CoAPNon13 standard13 ways
bull Transport13 in13 the13 URI13 authority13 componentndash coaphost[port][transport]13 instead13 of13 coaphost[port]
bull Transport13 as13 a13 service13 URLndash servicecoaptcphostexamplecomwell-shy‐knowncorert=core-shy‐rd
bull Above13 two13 ways13 break13 exisng13 compability13 (although13 both13 are13 based13 on13 valid13 IANA13 URI13 registraons)
61
031113
URI13 Representaons13 for13 CoAPMiscellaneous13 Consideraons
bull Ensure13 that13 transport13 is13 defined13 unambiguously13 (eg13 L2CAP13 used13 by13 both13 BLE13 and13 standard13 Bluetooth13 so13 avoid13 rdquocoap+l2caprdquo13 or13 rdquotransport=l2caprdquo13 or13 rdquoq=l2caprdquondash Can13 be13 done13 as13 WG13 consensusndash Namespace13 approach13 eg13 rdquocoap+blel2caprdquo13 or13 rdquoq=blel2caprdquo
bull Allow13 end-shy‐points13 to13 use13 CoAP13 Resource13 Directory13 to13 register13 alternave13 transports13 and13 idenfiers13 and13 provide13 periodic13 updatesndash Register13 rdquocore-shy‐transportrdquo13 resource13 type
62
031113
Transport13 Consideraons
bull Uniqueness13 of13 end-shy‐point13 idenficaonbull Communicaon13 support13 Unidireconal13 Bidireconal13 1N13 (broadcast13 mulcast13 anycast)13 messaging
bull Binary13 encoding13 Network13 byte13 orderingbull MTU13 correlaon13 with13 CoAP13 PDU13 sizebull Transport13 latency
63
031113
Security13 Consideraons
bull Drar13 does13 not13 introduce13 new13 security13 requirements13 by13 itself
bull There13 may13 be13 privacy13 issues13 if13 nodes13 use13 telephone13 numbers13 or13 MAC13 addresses13 as13 public13 end13 point13 idenfiers
64
Akbar Rahman
IETF 86 March 2013 httpwwwietforgiddraft-rahman-core-sleepy-02txt
Enhanced Sleepy Node Support for CoAP
Introduction
It is expected that in CoAP networks there will be a certain portion of devices that are sleepy and which may occasionally go into a sleep mode (ie go into a low power state to conserve power) and subsequently have reduced CoAP protocol communication ability
This I-D proposes a minimal and efficient mechanism building on the Resource Directory concept (which will be integrated into a CoAP Proxy) to enhance sleepy node support in CoAP networks
Main Question from IETF-85 (Atlanta)
What performance benefit does the proposed Sleepy Node support solution give in a network that already has standard CoAP caching enabled
Sleepy Node Performance Analysis
Experimental Network
1-5 clients
Both Sleepy and Non-
Sleepy servers
Sleepy Node Performance Analysis Network Setup
CoAPSleepyServer(s)
CoAPSleepAwareReverseProxy
CoAP
Client(s)
Request
Response
Sleep9AwareCoREResourceDirectoryCapability
PublishedSleepParameters
Sleep9AwareCoAPStoreandForwardCapability Response
Request
SleepAwareCoAP503ResponseCapability
CoAPCachingCapability
bull Server supports publishing sleep parameters to proxy bull Eg Irsquom going to be asleep for X seconds
bull Proxy supports sleep-awareness capabilities bull Proxy also supports caching capability based off of maxAge bull Protocol flow similar to approach of Figure 1 (Synchronous RD Based Sleep
Tracking) of I-D
Proxy capabilities can be selectively enableddisabled
Proxy ndash Server Interface
Client ndash Proxy Interface
CoAP Sleep-Aware Reverse Proxy Features CoRE Sleep-aware Resource Directory
Support storing published sleep parameters from CoAP servers sleepState (AWAKE ASLEEP) sleepDuration
Sleep-aware CoAP 503 Response Capability If CoAP request to a sleeping server is received proxy returns a
lsquo503 Retry-Afterrsquo response to client 503 contains a timestamp indicating when the sever will wake back up
(timestamp delivered in CoAP maxAge option) Sleep-aware CoAP Store-and-Forward Capability
If CoAP request to a sleeping server is received proxy stores request until server wakes up and then forwards it
Caching capability Cache GET responses from server if maxAge option is present
(this is not a sleep aware feature)
Goals of Performance Analysis
For networks having sleepy servers provide measurements to quantify the impact that CoAP sleep-awareness capabilities can have
See if sleep-awareness capabilities can
provide additional benefits even when CoAP caching is used
Overview of Performance Analysis Performed The analysis was broken up into a set of test scenarios Each test scenario used a different combination of the following
variables Client issued GET requests Server was configured as a sleepy or non-sleepy server Proxy caching of GET responses was enabled or disabled Proxy sleep-aware 503 response capability was enabled or disabled Proxy store-and-forward capability was enabled or disabled maxAge in GET responses ndash Two values were tested 60sec and 5sec of Clients ndash Two values were used ndash 1 client and 5 clients
For comparison purposes the following were held constant across all test scenarios Client issued a fixed number of requests (100) across all test scenarios Client used a delay between each GET request (35sec) to better exercise
proxyrsquos caching and sleep-awareness capabilities For sleepy server test scenarios the server slept 60 sec awake for 3 sec
Format of Results The following results were collected for each
test scenario
Breakdown of the and types of transactions occurring between clientproxyserver
ldquoGETrdquo ndash Test Scenario Results
GET ndash Description of Test Scenarios
TestScenarios-GET
Scenario
CoAPSleepyServerSe7ngs CoAPSleepAwareReverseProxySe7ngs CoAPClientSe7ngs
SleepDuragton(sec)
AwakeDuragton(sec)
maxAge(sec) Caching SleepAwareSAF+
503NumberofClients
NumberofGETs
DelayBetweenClient
Requests(sec)
1a 0 Always 60 Enabled Disabled 1 100 35
1b 60 3 60 Enabled Disabled 1 100 35
1c 60 3 60 Enabled Enabled 1 100 35
2a 0 Always 60 Enabled Disabled 5 100 35
2b 60 3 60 Enabled Disabled 5 100 35
2c 60 3 60 Enabled Enabled 5 100 35
3a 0 Always 5 Enabled Disabled 5 100 35
3b 60 3 5 Enabled Disabled 5 100 35
3c 60 3 5 Enabled Enabled 5 100 35
ldquoGETrdquo ndash Test Scenario 1 Results
maxAge = 60 and 1 Client
GET ndash Scenario 1 ClientProxy Interface Transaction Mix
Scenarios 1a - Non-Sleepy Server Caching Proxy maxAge = 60sec 1b- Sleepy Server Caching Proxy maxAge = 60sec 1c - Sleepy Server Sleep Aware Proxy maxAge = 60sec
Sleep Aware Proxy has better performance for sleepy servers
0
100
200
300
400
500
600
700
1a 1b 1c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
GET ndash Scenario 1 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
Scenarios 1a - Non-Sleepy Server Caching Proxy maxAge = 60sec 1b- Sleepy Server Caching Proxy maxAge = 60sec 1c - Sleepy Server Sleep Aware Proxy maxAge = 60sec
0
100
200
300
400
500
600
700
800
1a 1b 1c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
ldquoGETrdquo ndash Test Scenario 2 Results
maxAge = 60 and 5 Clients
GET ndash Scenario 2 ClientProxy Interface Transaction Mix
Sleep Aware Proxy has slightly better performance for sleepy servers
0
200
400
600
800
1000
1200
1400
2a 2b 2c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
Scenarios 2a - Non-Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2b- Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2c - Sleepy Server Sleep Aware Proxy maxAge = 60sec 5 Clients
See ldquoExperimental Artifactsrdquo Note 1
GET ndash Scenario 2 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has slightly better performance for sleepy servers
0
50
100
150
200
250
300
350
400
2a 2b 2c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
Scenarios 2a - Non-Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2b- Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2c - Sleepy Server Sleep Aware Proxy maxAge = 60sec 5 Clients
See ldquoExperimental Artifactsrdquo Note 2
Experimental Artifacts Note 1
Currently in the experiment the sleep aware proxy checks the cached state of a resource before putting a request into its Store-and-forward queue while a server is sleeping Once in the queue the proxy unconditionally forwards the queued requests to the server once it wakes up This is not the most efficient setup and can easily be improved If the proxy instead checks its cache again before forwarding each queued request it may not need to forward the request to the server For example if there are two queued GET requests in the proxyrsquos queue that address the same resource Only the first request needs to be sent to the server the second request can use the cached response from the first request
Note 2 Currently in the experiment the sleepy server sends a sleepState PUT request to the
proxy each time it goes to sleep This is not the most efficient setup and can easily be improved For example if the server assumes that the proxy can keep track of its ONOFF cycles with its internal timers (eg as per Fig 1 of I-D) then the number of messages from the sleepy server dramatically goes down
ldquoGETrdquo ndash Test Scenario 3 Results
maxAge = 5 and 5 Clients
GET ndash Scenario 3 ClientProxy Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
Scenarios 3a - Non-Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3b- Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3c - Sleepy Server Sleep Aware Proxy maxAge = 5sec 5 Clients
0
500
1000
1500
2000
2500
3000
3500
4000
4500
5000
3a 3b 3c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
GET ndash Scenario 3 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
0
1000
2000
3000
4000
5000
6000
7000
3a 3b 3c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
Scenarios 3a - Non-Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3b- Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3c - Sleepy Server Sleep Aware Proxy maxAge = 5sec 5 Clients
Conclusions
Conclusions These results show that sleep-aware CoAP
proxy features can significantly optimize communication with sleepy servers in most scenarios
These results also show that sleep-
awareness capabilities can provide additional benefits above and beyond CoAP caching in most scenarios
Backup
Current CoAP Support of Sleepy Node (12)
CoAP proxies can use a previously cached response to service a new GET request for a sleepy origin server (as in HTTP) But if no valid cache then proxy has to attempt to
retrieve and may fail if origin server is sleeping [I-Dietf-core-coap]
Clients can discover list of resources from RD (GET rd-lookuphellip) for sleepy servers But attempt to GET resource from sleepy origin server
may fail if origin server is sleeping [IDietf-core-link-format amp IDshelby-core-resource-
directory]
Current CoAP Support of Sleepy Node (22)
Lower layer support for sleepy nodes in most wireless technologies (eg WiFi ZigBee) But limited to MAC packet scheduling for sleepy nodes
and not aware of specific needs of IP applications (like CoAP)
Proposal ndash RD Based Sleep Tracking (14)
The current CoAP approach to support sleepy nodes can be significantly improved by introducing RD based mechanisms for a CoAP client to determine whether A targeted resource is located on a sleepy server A sleepy server is currently in sleep mode or not
There is any associated caching Proxy (possibly the RD itself) for a sleepy server
Proposal ndash RD Based Sleep Tracking (24)
We define the following new RD attributes to characterize the properties of a sleepy node SleepState - Indicates whether the node is currently in
sleep mode or not (ie Sleeping or Awake) SleepDuration - Indicates the maximum duration of time
that the node stays in sleep mode TimeSleeping - Indicates the length of time the node
has been sleeping (ie if Sleep State = Sleeping) NextSleep - Indicates the next time the node will go to
sleep (ie if Sleep State = Awake)
CachingProxy ndash Indicates the caching proxy of the sleepy node (ie the RD itself or another node)
Proposal ndash RD Based Sleep Tracking (34)
These attributes are all server (node) level and are new parameters added to the RD URI Template Variables
Finally we also define a new lookup-type (ss) for the RD lookup interface specified in [I-Dshelby-core-resource-directory] This new lookup-type supports looking up the
ldquoSleepStaterdquo (ss) of a specified end-point
Proposal ndash RD Based Sleep Tracking (44)
The three time based parameters (SleepDuration TimeSleeping NextSleep) can be based on either an absolute network time (for a time synchronized network) or a relative local time (measured at the local node)
Following the approach of [I-Dietf-core-link-format] and [I-Dshelby-core-resource-directory] sleep parameters for sleepy servers can be stored by the server in the RD and accessed by all interested clients
Examples of using these parameters in a synchronous or asynchronous manner are shown in the I-D
http6lowappnet coreIETF86 2013-03-12-13
We assume people have read the drafts
Meetings serve to advance difficult issues by making good use of face-to-face communications
Note Well Be aware of the IPR principles according to RFC 3979 and its updates
uumlBlue sheetsuumlScribe(s)
96
drar-shy‐iep-shy‐core-shy‐coapsubmiqed13 to13 IESG
2013-shy‐03-shy‐13
97
OMA Lightweight M2M Overview(A new standard using lots of IETF specs including DTLS
CoAP Block Observe Resource Directory SenMLhellip)
Zach ShelbyCoRE WG IETF-86 Orlando
OMA Lightweight M2Mbull Open Mobile Alliance is well known for Device Management (DM)bull OMA Lightweight M2M is a new standard from the alliance
ndash Focused on constrained Cellular and sensor network M2M devicesndash Driven by leading operators and vendors
bull Scopendash Interfaces protocol amp security between Device and Serverndash Object and Resource modelndash Bootstrap Device Access Control Connectivity and Firmware Objects
bull Draft Specifications are availablendash httpmemberopenmobileallianceorgftpPublic_documentsDM
LightweightM2MPermanent_documentsOMA-TS-LightweightM2M-V1_0_0-20130301-Dzip
bull Timelinendash Requirements and Architecture completed 3Q2012ndash Spec ready for Consistency Review 2Q2013ndash Candidate Approval expected 3Q2013
2 CoRE WG IETF-86 Orlando
Architecture
3
Scope of LWM2M
CoRE WG IETF-86 Orlando
Object Model
bull A Client has one or more Object Instancesbull An Object is a collection of Resourcesbull A Resource is an atomic piece of information
ndash Read Written or Executed
bull Resources can have multiple instancesbull Objects and Resources are identified by a
16-bit Integer Instances by an 8-bit Integerbull ObjectsResources are accessed with
simple URIs Object IDObject InstanceResource ID
eg 1213
4 CoRE WG IETF-86 Orlando
CoRE WG IETF-86 Orlando
CoRE Resource Directory
draft-shelby-core-resource-directory-05
Z Shelby C Bormann S Krco
Backgroundbull Not a new concept
ndash think web search engine or any link directorybull Defines the interfaces to a Resource Directorybull Based on Web Linking framework and the CoRE Link Formatbull Generic REST design for use over HTTP and CoAPbull Used by OMA Lightweight M2Mbull Has already been deployed
ndash In traffic monitoring systemsndash In street lighting systemsndash For vehicular asset trackingndash By a major Cellular M2M operator
Changes since -04
bull Restricted Update to parameter updatesbull Added pagination support for the Lookup interfacebull Changed rt= to et= for the registration amp update
interfacebull Added group support
Group Management
bull RD now includes group management featuresbull New Group Function Set
ndash Register a groupbull Group name domain multicast address endpoint members
ndash Remove a groupbull Group lookup using the Lookup Function Set
ndash List registered groupsndash Find the members of a groupndash Find groups with certain endpoints or resources
Registering a Group
EP RD
| |
| - POST rd-groupgp=lights ltgtep=node1 --gt |
| |
| |
| lt---- 201 Created Location rd-group12 ---- |
| |
Req POST coaprdexamplecomrd-groupgp=lights
Payload
ltgtep=node1
ltgtep=node2
Res 201 Created
Location rd-group12
Looking up Group Members
Client RD
| |
| ----- GET rd-lookupepgp=lights1 ----------------------gt |
| |
| |
| lt-- 205 Content ltrdgtd=domain1ltrdgtd=domain2 --------- |
| |
Req GET rd-lookupepgp=lights1
Res 205 Content
ltcoaphostportgtep=node1
ltcoaphostportgtep=node2rdquo
Things for the futurebull Support for JSON representation of Web Links
ndash httptoolsietforgiddraft-bormann-core-links-json-02txtbull Registry for RD registration query parameters
ndash Already OMA Lightweight has defined some new onesbull More examples
Group 3 ldquonew workrdquo(continued)
109
drar-shy‐greevenbosch-shy‐core-shy‐profile-shy‐descripon-shy‐01Bert13 GreevenboschJeroen13 Hoebeke
Isam13 IshaqFloris13 Van13 den13 Abeele
Descripon
bull JSON13 format13 for13 signalling13 the13 servers13 capabilies
bull Signalling13 of13 supported13 opons13 media13 types13 and13 block13 sizendash Other13 items13 can13 be13 added
bull Filtering13 on13 specific13 fields13 through13 URI-shy‐Querybull Link13 hqpdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐profile-shy‐descripon
well-shy‐knownprofile
bull To13 acquire13 profile13 data13 of13 resources13 on13 a13 parcular13 service13 the13 well-shy‐knownprofile13 URI-shy‐path13 is13 introduced
bull For13 example13 to13 get13 all13 informaon13 from13 sensors13 served13 by13 wwwexampleorg13 we13 can13 do13 a13 GET13 to13 coapwwwexampleorgwell-shy‐knownprofile
bull Filtering13 on13 parcular13 resources13 is13 done13 through13 URI-shy‐Queries
Format
bull Currently13 the13 following13 fields13 are13 definedndash ldquopathrdquo13 contains13 the13 URI-shy‐path13 associated13 with13 a13 resource
ndash ldquooprdquo13 a13 numerical13 list13 of13 supported13 opon13 numbers
ndash ldquocfrdquo13 a13 numerical13 list13 of13 supported13 content-shy‐format13 numbers
ndash ldquob1srdquo13 ldquob2srdquo13 supported13 block13 sizes13 for13 Block113 and13 Block213 respecvely
Examplebull On13 the13 right13 is13 an13 example13 of13 a13 camera13 sensor13 at13 coapwwwexampleorgcam13 that13 supports13 the13 Uri-shy‐Host13 (3)13 ETag13 (4)13 Uri-shy‐Port13 (7)13 Uri-shy‐Path13 (11)13 Content-shy‐Format13 (12)13 Token13 (19)13 Block213 (23)13 and13 Proxy-shy‐Uri13 (35)13 opons
bull The13 supported13 content13 formats13 are13 textplain13 (0)13 applicaon13 link-shy‐format13 (40)13 and13 applicaonjson13 (50)
bull The13 supported13 Block213 can13 use13 25613 or13 51213 byte13 blocks
Req13 GET13 coapwwwexampleorgwell-shy‐knownprofile13 Res13 20513 Content13 (applicationjson)13 13 13 13 profile13 13 13 13 13 13 13 13 pathcam13 13 13 13 op[3471112192335]13 13 13 13 13 cf[04050]13 13 13 13 13 b2s[45]13 13 13 13
Filtering13 through13 use13 of13 URI-shy‐Query
bull Filtering13 can13 be13 done13 through13 the13 URI-shy‐Querybull Query13 format13 N=V
ndash N13 is13 a13 profile13 fieldndash V13 is13 the13 desired13 value
bull Examplesndash To13 find13 resources13 that13 support13 content13 format13 ldquoapplicaonjsonrdquo
13 GET13 wwwexampleorgwell-shy‐knownprofilecf=50ndash To13 get13 informaon13 about13 the13 camera
13 GET13 wwwexampleorgwell-shy‐knownprofilepath=cam
Open13 issues
bull Which13 other13 profile13 data13 needs13 signallingndash Content-shy‐type13 for13 different13 methods
bull Fix13 the13 order13 in13 which13 the13 profile13 fields13 must13 appearndash Non-shy‐fixed13 order13 easier13 extensible
bull Inheritance13 of13 a13 profile13 descriponbull Extend13 usage13 to13 signal13 the13 client13 profilebull Integraon13 with13 link13 format
Thank13 youQuesons
drar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval-shy‐00
Bert13 Greevenbosch
Descripon
bull The13 ldquoMinimumRequestInterval13 opon13 can13 be13 used13 to13 indicate13 the13 minimum13 me13 between13 two13 requests13 in13 a13 transacon
bull Originally13 intended13 for13 Block13 but13 also13 usable13 for13 other13 transaconsndash Example13 browsing13 a13 server
bull The13 goal13 is13 to13 reduce13 the13 server13 load13 and13 network13 traffic
bull Link13 hqpsdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval
Usage
bull The13 client13 keeps13 the13 server13 informed13 about13 its13 request13 speed13 through13 inclusion13 of13 the13 ldquoMinimumRequestIntervalrdquo13 opon
bull In13 responses13 the13 server13 fixes13 the13 minimum13 request13 interval13 through13 the13 same13 opon
bull The13 client13 obeys13 the13 speed13 indicated13 by13 the13 server
bull The13 client13 can13 send13 slower13 but13 not13 faster
Advantages
bull The13 server13 has13 means13 to13 limit13 the13 amount13 of13 incoming13 traffic
bull The13 server13 can13 prevent13 to13 become13 overloaded13 with13 too13 many13 tasks
bull The13 server13 does13 not13 need13 arficially13 slow13 down13 the13 client13 by13 sending13 late13 ACKsndash No13 need13 to13 keep13 track13 of13 delayed13 ACKsndash The13 server13 can13 perform13 other13 tasks13 instead
bull Reduced13 network13 traffic
Thank13 youQuesons
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-links-json-02txt
123
RFC 6690 (link-format) documents are somewhat foreign to many web app developerssect would prefer to have them in JSON format
There is no standard way to represent link-format documents in applicationssect but everyone knows how to handle JSON
Define a standard JSON translation for link-format
Itrsquos
not
rock
et
scien
ce
ltsensorsgtct=40title=Sensor Index ltsensorstempgtrt=temperature-cif=sensor ltsensorslightgtrt=light-luxif=sensor lthttpwwwexamplecomsensorst123gt anchor=sensorstemprel=describedby lttgtanchor=sensorstemprel=alternate [hrefsensorsct40titleSensor Index hrefsensorstemprttemperature-cifsensor hrefsensorslightrtlight-luxifsensor hrefhttpwwwexamplecomsensorst123 anchorsensorstempreldescribedby hreftanchorsensorstemprelalternate]
124
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-ipsec-for-coap-00txt
IPsec definitions for CoAP Mostly placeholder at this time Who has implementation experience with this
125
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-cross-reverse-convention-00txt
This draft has two lines of payload(based on a WGLC comment by Cullen Jennings)
coap12344567foobara=3
httpwwwproxycomwellknowncore-translate1234_4567foobara=3
Is that a useful convention to have
126
Insert CI slides here
127
128
0
5
10
15
20
25
30
35
40
10 20 30 40 50 60 70
good
put (
pps)
pps
Goodput vs pps (Econotags)
goodput
[Khattak preliminary]
Congestion Control
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-cocoa-00txt
ldquoadvancedrdquo cc (The draft is just a first shot) Others may have better ideas
129
Insert post-WGLC discussion slides here
130
Stop Continue Start
131
An Agile Retrospective
http6lowappnet coreIETF86 2013-03-12-13
Stop
132
Endless new CoAP optionssect instead use RESTful as much as possible
Move general security lifecycle out Looking at theoretical problems
http6lowappnet coreIETF86 2013-03-12-13
Continue
Interops Running code Look at real-world examples and deployments Solve their actual problems
sect Unilateral enhancements eg higher performance congestion control
sect Transports (SMS hellip)sect Make Web linking and Directories more and more usefulsect RESTful Design Paradigms for real-world problems
133
http6lowappnet coreIETF86 2013-03-12-13
Start
Further push into the (browser) web world (HTML5 browser security)
Specific supporting worksect SenMLsect URI work (dev URN hellip)sect Security Processes (next slide)
Spin outsect (We donrsquot really get to decide where this is done)
134
http6lowappnet coreIETF86 2013-03-12-13
Security
Integrate Application Network Group Keyingsect Tunnel-free setup
Donrsquot redo what has been done alreadysect ZigBee IP is finesect But what about other scenarios
Simple REST interfaces for working with keying materials and authorizationsect Start with defining objectives
Object Security for Constrained Nodes135
Re-chartering CoREWhat do we want to do now that wersquore grown up
Zach ShelbyCoRE WG IETF-86 Orlando
What is the scope
bull So we have a protocol and Web Linking what next
bull Keep with what we know besthellip1 Enhancements around CoAP2 New transports for CoAP3 New representations for Web Links4 General application layer solutions
CoRE WG IETF-86 Orlando 2
Enhancements around CoAP
bull Advanced congestion control
CoRE WG IETF-86 Orlando 3
New Transports for CoAP
bull Infrastructure for CoAP over foondash httptoolsietforgiddraft-silverajan-core-
coap-alternative-transports-01txtbull CoAP over SMS
ndash httptoolsietforgiddraft-becker-core-coap-sms-gprs-03txt
ndash OMA Lightweightbull CoAP over TCP
ndash httptoolsietforgiddraft-li-core-coap-payload-length-option-01txt
CoRE WG IETF-86 Orlando 4
New support for Web Links
bull JSON Web Linksndash httptoolsietforgiddraft-bormann-core-links-
json-02txt
2332010 CoRE WG IETF-77 Anaheim 5
General application layer solutions
bull Resource Directoryndash httptoolsietforgiddraft-shelby-core-
resource-directory-05txtndash OMA Lightweight
2332010 CoRE WG IETF-77 Anaheim 6
Next steps
I Rene Uri schemeI Response-To-Scheme optionI Selection of Message ExchangeI Rene Proxying
10 10
CoAP13 Communicaon13 with13 Alternave13 Transports
Bill Silverajan and Teemu SavolainenCore WG IETF 86 Orlando
031113
Objecves13 (In13 Scope)
bull Unambiguous13 representaon13 of13 transport13 to13 be13 used13 by13 CoAP
bull Details13 how13 the13 transport13 can13 carry13 CoAP13 packet
bull Focus13 is13 on13 what13 CoAP13 communicaons13 requirements13 are
bull Allow13 CoAP13 mechanisms13 to13 exploit13 cross-shy‐layer13 opmisaons
51
031113
Non13 Goals13 (Not13 in13 scope)
bull Applicaon-shy‐level13 QoS13 requirementsbull Real-shy‐me13 constraintsbull Ordering13 reliability13 congeson13 controlbull Applicaon13 and13 network13 adaptaonbull Mobility13 and13 readdressing13 supportbull Network13 protocol13 (eg13 IPsec)13 configuraon
52
031113
Use13 Cases
bull NAT13 and13 Firewall13 traversal13 with13 TCPbull Delay13 Tolerant13 Networkingbull Non-shy‐IP13 Low13 Energy13 Protocols
53
031113
Related13 Work
bull OMA13 Lightweight13 M2M13 Protocolbull CoAP13 over13 SMSGPRSUSSD
54
031113
What13 does13 the13 work13 entail
bull The13 ability13 to13 specify13 end13 point13 idenfiers13 and13 URIs13 to13 reflect13 which13 transport13 CoAP13 can13 use
bull The13 ability13 to13 register13 to13 resource13 directories13 resource13 types13 reflecng13 types13 of13 transport13 available
bull Ability13 for13 mul-shy‐transport13 nodes13 to13 select13 transport13 to13 use13 without13 significant13 alteraon13 to13 CoAP13 packet13 structure
55
031113
Points13 to13 consider
bull Requirements13 for13 transport13 layer13 protocol13 to13 carry13 CoAP13 packets
bull Representaon13 of13 URI13 scheme13 for13 generic13 transport13 protocols
bull Opon13 extensions13 for13 CoAP13 to13 express13 available13 transports
bull Mapping13 and13 message13 sizebull Security13 consideraons
56
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
URI13 =13 scheme13 13 13 authority13 path-shy‐abempty13 [13 query13 ]
bull Within13 the13 scheme13 namebull In13 the13 URI13 pathbull As13 a13 query13 component
57
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
bull Within13 the13 scheme13 namendash coap+tel+15105550101well-shy‐knowncorendash coap+tcpexamplecom5683temperaturendash coap+blel2cap[1234567890AB]4pulse
bull Easy13 URI13 parsing13 for13 transport13 type13 and13 idenfier
bull Each13 new13 scheme13 name13 requires13 IANA13 registraon
58
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
bull In13 the13 URI13 pathndash coaphostexamplecomtransport=tcpwell-shy‐knowncorert=core-shy‐rd
bull Easy13 adopon13 of13 new13 (and13 experimental)13 CoAP13 transports13 without13 IANA13 registraon
bull Caveat13 Uri-shy‐Path13 opon13 is13 a13 Crical13 CoAP13 opon13 see13 secon13 54113 of13 I-shy‐Diep-shy‐core-shy‐coap
59
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
bull As13 a13 URI13 query13 componentndash coaphostexamplecomwell-shy‐knowncorert=core-shy‐rdq=tcp
bull Also13 easy13 to13 adopt13 new13 (and13 experimental)13 CoAP13 transports13 without13 IANA13 registraon
bull Caveat13 Uri-shy‐Query13 opon13 is13 a13 Crical13 CoAP13 opon13 see13 secon13 54113 of13 I-shy‐Diep-shy‐core-shy‐coap
60
031113
URI13 Representaons13 for13 CoAPNon13 standard13 ways
bull Transport13 in13 the13 URI13 authority13 componentndash coaphost[port][transport]13 instead13 of13 coaphost[port]
bull Transport13 as13 a13 service13 URLndash servicecoaptcphostexamplecomwell-shy‐knowncorert=core-shy‐rd
bull Above13 two13 ways13 break13 exisng13 compability13 (although13 both13 are13 based13 on13 valid13 IANA13 URI13 registraons)
61
031113
URI13 Representaons13 for13 CoAPMiscellaneous13 Consideraons
bull Ensure13 that13 transport13 is13 defined13 unambiguously13 (eg13 L2CAP13 used13 by13 both13 BLE13 and13 standard13 Bluetooth13 so13 avoid13 rdquocoap+l2caprdquo13 or13 rdquotransport=l2caprdquo13 or13 rdquoq=l2caprdquondash Can13 be13 done13 as13 WG13 consensusndash Namespace13 approach13 eg13 rdquocoap+blel2caprdquo13 or13 rdquoq=blel2caprdquo
bull Allow13 end-shy‐points13 to13 use13 CoAP13 Resource13 Directory13 to13 register13 alternave13 transports13 and13 idenfiers13 and13 provide13 periodic13 updatesndash Register13 rdquocore-shy‐transportrdquo13 resource13 type
62
031113
Transport13 Consideraons
bull Uniqueness13 of13 end-shy‐point13 idenficaonbull Communicaon13 support13 Unidireconal13 Bidireconal13 1N13 (broadcast13 mulcast13 anycast)13 messaging
bull Binary13 encoding13 Network13 byte13 orderingbull MTU13 correlaon13 with13 CoAP13 PDU13 sizebull Transport13 latency
63
031113
Security13 Consideraons
bull Drar13 does13 not13 introduce13 new13 security13 requirements13 by13 itself
bull There13 may13 be13 privacy13 issues13 if13 nodes13 use13 telephone13 numbers13 or13 MAC13 addresses13 as13 public13 end13 point13 idenfiers
64
Akbar Rahman
IETF 86 March 2013 httpwwwietforgiddraft-rahman-core-sleepy-02txt
Enhanced Sleepy Node Support for CoAP
Introduction
It is expected that in CoAP networks there will be a certain portion of devices that are sleepy and which may occasionally go into a sleep mode (ie go into a low power state to conserve power) and subsequently have reduced CoAP protocol communication ability
This I-D proposes a minimal and efficient mechanism building on the Resource Directory concept (which will be integrated into a CoAP Proxy) to enhance sleepy node support in CoAP networks
Main Question from IETF-85 (Atlanta)
What performance benefit does the proposed Sleepy Node support solution give in a network that already has standard CoAP caching enabled
Sleepy Node Performance Analysis
Experimental Network
1-5 clients
Both Sleepy and Non-
Sleepy servers
Sleepy Node Performance Analysis Network Setup
CoAPSleepyServer(s)
CoAPSleepAwareReverseProxy
CoAP
Client(s)
Request
Response
Sleep9AwareCoREResourceDirectoryCapability
PublishedSleepParameters
Sleep9AwareCoAPStoreandForwardCapability Response
Request
SleepAwareCoAP503ResponseCapability
CoAPCachingCapability
bull Server supports publishing sleep parameters to proxy bull Eg Irsquom going to be asleep for X seconds
bull Proxy supports sleep-awareness capabilities bull Proxy also supports caching capability based off of maxAge bull Protocol flow similar to approach of Figure 1 (Synchronous RD Based Sleep
Tracking) of I-D
Proxy capabilities can be selectively enableddisabled
Proxy ndash Server Interface
Client ndash Proxy Interface
CoAP Sleep-Aware Reverse Proxy Features CoRE Sleep-aware Resource Directory
Support storing published sleep parameters from CoAP servers sleepState (AWAKE ASLEEP) sleepDuration
Sleep-aware CoAP 503 Response Capability If CoAP request to a sleeping server is received proxy returns a
lsquo503 Retry-Afterrsquo response to client 503 contains a timestamp indicating when the sever will wake back up
(timestamp delivered in CoAP maxAge option) Sleep-aware CoAP Store-and-Forward Capability
If CoAP request to a sleeping server is received proxy stores request until server wakes up and then forwards it
Caching capability Cache GET responses from server if maxAge option is present
(this is not a sleep aware feature)
Goals of Performance Analysis
For networks having sleepy servers provide measurements to quantify the impact that CoAP sleep-awareness capabilities can have
See if sleep-awareness capabilities can
provide additional benefits even when CoAP caching is used
Overview of Performance Analysis Performed The analysis was broken up into a set of test scenarios Each test scenario used a different combination of the following
variables Client issued GET requests Server was configured as a sleepy or non-sleepy server Proxy caching of GET responses was enabled or disabled Proxy sleep-aware 503 response capability was enabled or disabled Proxy store-and-forward capability was enabled or disabled maxAge in GET responses ndash Two values were tested 60sec and 5sec of Clients ndash Two values were used ndash 1 client and 5 clients
For comparison purposes the following were held constant across all test scenarios Client issued a fixed number of requests (100) across all test scenarios Client used a delay between each GET request (35sec) to better exercise
proxyrsquos caching and sleep-awareness capabilities For sleepy server test scenarios the server slept 60 sec awake for 3 sec
Format of Results The following results were collected for each
test scenario
Breakdown of the and types of transactions occurring between clientproxyserver
ldquoGETrdquo ndash Test Scenario Results
GET ndash Description of Test Scenarios
TestScenarios-GET
Scenario
CoAPSleepyServerSe7ngs CoAPSleepAwareReverseProxySe7ngs CoAPClientSe7ngs
SleepDuragton(sec)
AwakeDuragton(sec)
maxAge(sec) Caching SleepAwareSAF+
503NumberofClients
NumberofGETs
DelayBetweenClient
Requests(sec)
1a 0 Always 60 Enabled Disabled 1 100 35
1b 60 3 60 Enabled Disabled 1 100 35
1c 60 3 60 Enabled Enabled 1 100 35
2a 0 Always 60 Enabled Disabled 5 100 35
2b 60 3 60 Enabled Disabled 5 100 35
2c 60 3 60 Enabled Enabled 5 100 35
3a 0 Always 5 Enabled Disabled 5 100 35
3b 60 3 5 Enabled Disabled 5 100 35
3c 60 3 5 Enabled Enabled 5 100 35
ldquoGETrdquo ndash Test Scenario 1 Results
maxAge = 60 and 1 Client
GET ndash Scenario 1 ClientProxy Interface Transaction Mix
Scenarios 1a - Non-Sleepy Server Caching Proxy maxAge = 60sec 1b- Sleepy Server Caching Proxy maxAge = 60sec 1c - Sleepy Server Sleep Aware Proxy maxAge = 60sec
Sleep Aware Proxy has better performance for sleepy servers
0
100
200
300
400
500
600
700
1a 1b 1c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
GET ndash Scenario 1 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
Scenarios 1a - Non-Sleepy Server Caching Proxy maxAge = 60sec 1b- Sleepy Server Caching Proxy maxAge = 60sec 1c - Sleepy Server Sleep Aware Proxy maxAge = 60sec
0
100
200
300
400
500
600
700
800
1a 1b 1c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
ldquoGETrdquo ndash Test Scenario 2 Results
maxAge = 60 and 5 Clients
GET ndash Scenario 2 ClientProxy Interface Transaction Mix
Sleep Aware Proxy has slightly better performance for sleepy servers
0
200
400
600
800
1000
1200
1400
2a 2b 2c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
Scenarios 2a - Non-Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2b- Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2c - Sleepy Server Sleep Aware Proxy maxAge = 60sec 5 Clients
See ldquoExperimental Artifactsrdquo Note 1
GET ndash Scenario 2 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has slightly better performance for sleepy servers
0
50
100
150
200
250
300
350
400
2a 2b 2c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
Scenarios 2a - Non-Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2b- Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2c - Sleepy Server Sleep Aware Proxy maxAge = 60sec 5 Clients
See ldquoExperimental Artifactsrdquo Note 2
Experimental Artifacts Note 1
Currently in the experiment the sleep aware proxy checks the cached state of a resource before putting a request into its Store-and-forward queue while a server is sleeping Once in the queue the proxy unconditionally forwards the queued requests to the server once it wakes up This is not the most efficient setup and can easily be improved If the proxy instead checks its cache again before forwarding each queued request it may not need to forward the request to the server For example if there are two queued GET requests in the proxyrsquos queue that address the same resource Only the first request needs to be sent to the server the second request can use the cached response from the first request
Note 2 Currently in the experiment the sleepy server sends a sleepState PUT request to the
proxy each time it goes to sleep This is not the most efficient setup and can easily be improved For example if the server assumes that the proxy can keep track of its ONOFF cycles with its internal timers (eg as per Fig 1 of I-D) then the number of messages from the sleepy server dramatically goes down
ldquoGETrdquo ndash Test Scenario 3 Results
maxAge = 5 and 5 Clients
GET ndash Scenario 3 ClientProxy Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
Scenarios 3a - Non-Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3b- Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3c - Sleepy Server Sleep Aware Proxy maxAge = 5sec 5 Clients
0
500
1000
1500
2000
2500
3000
3500
4000
4500
5000
3a 3b 3c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
GET ndash Scenario 3 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
0
1000
2000
3000
4000
5000
6000
7000
3a 3b 3c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
Scenarios 3a - Non-Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3b- Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3c - Sleepy Server Sleep Aware Proxy maxAge = 5sec 5 Clients
Conclusions
Conclusions These results show that sleep-aware CoAP
proxy features can significantly optimize communication with sleepy servers in most scenarios
These results also show that sleep-
awareness capabilities can provide additional benefits above and beyond CoAP caching in most scenarios
Backup
Current CoAP Support of Sleepy Node (12)
CoAP proxies can use a previously cached response to service a new GET request for a sleepy origin server (as in HTTP) But if no valid cache then proxy has to attempt to
retrieve and may fail if origin server is sleeping [I-Dietf-core-coap]
Clients can discover list of resources from RD (GET rd-lookuphellip) for sleepy servers But attempt to GET resource from sleepy origin server
may fail if origin server is sleeping [IDietf-core-link-format amp IDshelby-core-resource-
directory]
Current CoAP Support of Sleepy Node (22)
Lower layer support for sleepy nodes in most wireless technologies (eg WiFi ZigBee) But limited to MAC packet scheduling for sleepy nodes
and not aware of specific needs of IP applications (like CoAP)
Proposal ndash RD Based Sleep Tracking (14)
The current CoAP approach to support sleepy nodes can be significantly improved by introducing RD based mechanisms for a CoAP client to determine whether A targeted resource is located on a sleepy server A sleepy server is currently in sleep mode or not
There is any associated caching Proxy (possibly the RD itself) for a sleepy server
Proposal ndash RD Based Sleep Tracking (24)
We define the following new RD attributes to characterize the properties of a sleepy node SleepState - Indicates whether the node is currently in
sleep mode or not (ie Sleeping or Awake) SleepDuration - Indicates the maximum duration of time
that the node stays in sleep mode TimeSleeping - Indicates the length of time the node
has been sleeping (ie if Sleep State = Sleeping) NextSleep - Indicates the next time the node will go to
sleep (ie if Sleep State = Awake)
CachingProxy ndash Indicates the caching proxy of the sleepy node (ie the RD itself or another node)
Proposal ndash RD Based Sleep Tracking (34)
These attributes are all server (node) level and are new parameters added to the RD URI Template Variables
Finally we also define a new lookup-type (ss) for the RD lookup interface specified in [I-Dshelby-core-resource-directory] This new lookup-type supports looking up the
ldquoSleepStaterdquo (ss) of a specified end-point
Proposal ndash RD Based Sleep Tracking (44)
The three time based parameters (SleepDuration TimeSleeping NextSleep) can be based on either an absolute network time (for a time synchronized network) or a relative local time (measured at the local node)
Following the approach of [I-Dietf-core-link-format] and [I-Dshelby-core-resource-directory] sleep parameters for sleepy servers can be stored by the server in the RD and accessed by all interested clients
Examples of using these parameters in a synchronous or asynchronous manner are shown in the I-D
http6lowappnet coreIETF86 2013-03-12-13
We assume people have read the drafts
Meetings serve to advance difficult issues by making good use of face-to-face communications
Note Well Be aware of the IPR principles according to RFC 3979 and its updates
uumlBlue sheetsuumlScribe(s)
96
drar-shy‐iep-shy‐core-shy‐coapsubmiqed13 to13 IESG
2013-shy‐03-shy‐13
97
OMA Lightweight M2M Overview(A new standard using lots of IETF specs including DTLS
CoAP Block Observe Resource Directory SenMLhellip)
Zach ShelbyCoRE WG IETF-86 Orlando
OMA Lightweight M2Mbull Open Mobile Alliance is well known for Device Management (DM)bull OMA Lightweight M2M is a new standard from the alliance
ndash Focused on constrained Cellular and sensor network M2M devicesndash Driven by leading operators and vendors
bull Scopendash Interfaces protocol amp security between Device and Serverndash Object and Resource modelndash Bootstrap Device Access Control Connectivity and Firmware Objects
bull Draft Specifications are availablendash httpmemberopenmobileallianceorgftpPublic_documentsDM
LightweightM2MPermanent_documentsOMA-TS-LightweightM2M-V1_0_0-20130301-Dzip
bull Timelinendash Requirements and Architecture completed 3Q2012ndash Spec ready for Consistency Review 2Q2013ndash Candidate Approval expected 3Q2013
2 CoRE WG IETF-86 Orlando
Architecture
3
Scope of LWM2M
CoRE WG IETF-86 Orlando
Object Model
bull A Client has one or more Object Instancesbull An Object is a collection of Resourcesbull A Resource is an atomic piece of information
ndash Read Written or Executed
bull Resources can have multiple instancesbull Objects and Resources are identified by a
16-bit Integer Instances by an 8-bit Integerbull ObjectsResources are accessed with
simple URIs Object IDObject InstanceResource ID
eg 1213
4 CoRE WG IETF-86 Orlando
CoRE WG IETF-86 Orlando
CoRE Resource Directory
draft-shelby-core-resource-directory-05
Z Shelby C Bormann S Krco
Backgroundbull Not a new concept
ndash think web search engine or any link directorybull Defines the interfaces to a Resource Directorybull Based on Web Linking framework and the CoRE Link Formatbull Generic REST design for use over HTTP and CoAPbull Used by OMA Lightweight M2Mbull Has already been deployed
ndash In traffic monitoring systemsndash In street lighting systemsndash For vehicular asset trackingndash By a major Cellular M2M operator
Changes since -04
bull Restricted Update to parameter updatesbull Added pagination support for the Lookup interfacebull Changed rt= to et= for the registration amp update
interfacebull Added group support
Group Management
bull RD now includes group management featuresbull New Group Function Set
ndash Register a groupbull Group name domain multicast address endpoint members
ndash Remove a groupbull Group lookup using the Lookup Function Set
ndash List registered groupsndash Find the members of a groupndash Find groups with certain endpoints or resources
Registering a Group
EP RD
| |
| - POST rd-groupgp=lights ltgtep=node1 --gt |
| |
| |
| lt---- 201 Created Location rd-group12 ---- |
| |
Req POST coaprdexamplecomrd-groupgp=lights
Payload
ltgtep=node1
ltgtep=node2
Res 201 Created
Location rd-group12
Looking up Group Members
Client RD
| |
| ----- GET rd-lookupepgp=lights1 ----------------------gt |
| |
| |
| lt-- 205 Content ltrdgtd=domain1ltrdgtd=domain2 --------- |
| |
Req GET rd-lookupepgp=lights1
Res 205 Content
ltcoaphostportgtep=node1
ltcoaphostportgtep=node2rdquo
Things for the futurebull Support for JSON representation of Web Links
ndash httptoolsietforgiddraft-bormann-core-links-json-02txtbull Registry for RD registration query parameters
ndash Already OMA Lightweight has defined some new onesbull More examples
Group 3 ldquonew workrdquo(continued)
109
drar-shy‐greevenbosch-shy‐core-shy‐profile-shy‐descripon-shy‐01Bert13 GreevenboschJeroen13 Hoebeke
Isam13 IshaqFloris13 Van13 den13 Abeele
Descripon
bull JSON13 format13 for13 signalling13 the13 servers13 capabilies
bull Signalling13 of13 supported13 opons13 media13 types13 and13 block13 sizendash Other13 items13 can13 be13 added
bull Filtering13 on13 specific13 fields13 through13 URI-shy‐Querybull Link13 hqpdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐profile-shy‐descripon
well-shy‐knownprofile
bull To13 acquire13 profile13 data13 of13 resources13 on13 a13 parcular13 service13 the13 well-shy‐knownprofile13 URI-shy‐path13 is13 introduced
bull For13 example13 to13 get13 all13 informaon13 from13 sensors13 served13 by13 wwwexampleorg13 we13 can13 do13 a13 GET13 to13 coapwwwexampleorgwell-shy‐knownprofile
bull Filtering13 on13 parcular13 resources13 is13 done13 through13 URI-shy‐Queries
Format
bull Currently13 the13 following13 fields13 are13 definedndash ldquopathrdquo13 contains13 the13 URI-shy‐path13 associated13 with13 a13 resource
ndash ldquooprdquo13 a13 numerical13 list13 of13 supported13 opon13 numbers
ndash ldquocfrdquo13 a13 numerical13 list13 of13 supported13 content-shy‐format13 numbers
ndash ldquob1srdquo13 ldquob2srdquo13 supported13 block13 sizes13 for13 Block113 and13 Block213 respecvely
Examplebull On13 the13 right13 is13 an13 example13 of13 a13 camera13 sensor13 at13 coapwwwexampleorgcam13 that13 supports13 the13 Uri-shy‐Host13 (3)13 ETag13 (4)13 Uri-shy‐Port13 (7)13 Uri-shy‐Path13 (11)13 Content-shy‐Format13 (12)13 Token13 (19)13 Block213 (23)13 and13 Proxy-shy‐Uri13 (35)13 opons
bull The13 supported13 content13 formats13 are13 textplain13 (0)13 applicaon13 link-shy‐format13 (40)13 and13 applicaonjson13 (50)
bull The13 supported13 Block213 can13 use13 25613 or13 51213 byte13 blocks
Req13 GET13 coapwwwexampleorgwell-shy‐knownprofile13 Res13 20513 Content13 (applicationjson)13 13 13 13 profile13 13 13 13 13 13 13 13 pathcam13 13 13 13 op[3471112192335]13 13 13 13 13 cf[04050]13 13 13 13 13 b2s[45]13 13 13 13
Filtering13 through13 use13 of13 URI-shy‐Query
bull Filtering13 can13 be13 done13 through13 the13 URI-shy‐Querybull Query13 format13 N=V
ndash N13 is13 a13 profile13 fieldndash V13 is13 the13 desired13 value
bull Examplesndash To13 find13 resources13 that13 support13 content13 format13 ldquoapplicaonjsonrdquo
13 GET13 wwwexampleorgwell-shy‐knownprofilecf=50ndash To13 get13 informaon13 about13 the13 camera
13 GET13 wwwexampleorgwell-shy‐knownprofilepath=cam
Open13 issues
bull Which13 other13 profile13 data13 needs13 signallingndash Content-shy‐type13 for13 different13 methods
bull Fix13 the13 order13 in13 which13 the13 profile13 fields13 must13 appearndash Non-shy‐fixed13 order13 easier13 extensible
bull Inheritance13 of13 a13 profile13 descriponbull Extend13 usage13 to13 signal13 the13 client13 profilebull Integraon13 with13 link13 format
Thank13 youQuesons
drar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval-shy‐00
Bert13 Greevenbosch
Descripon
bull The13 ldquoMinimumRequestInterval13 opon13 can13 be13 used13 to13 indicate13 the13 minimum13 me13 between13 two13 requests13 in13 a13 transacon
bull Originally13 intended13 for13 Block13 but13 also13 usable13 for13 other13 transaconsndash Example13 browsing13 a13 server
bull The13 goal13 is13 to13 reduce13 the13 server13 load13 and13 network13 traffic
bull Link13 hqpsdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval
Usage
bull The13 client13 keeps13 the13 server13 informed13 about13 its13 request13 speed13 through13 inclusion13 of13 the13 ldquoMinimumRequestIntervalrdquo13 opon
bull In13 responses13 the13 server13 fixes13 the13 minimum13 request13 interval13 through13 the13 same13 opon
bull The13 client13 obeys13 the13 speed13 indicated13 by13 the13 server
bull The13 client13 can13 send13 slower13 but13 not13 faster
Advantages
bull The13 server13 has13 means13 to13 limit13 the13 amount13 of13 incoming13 traffic
bull The13 server13 can13 prevent13 to13 become13 overloaded13 with13 too13 many13 tasks
bull The13 server13 does13 not13 need13 arficially13 slow13 down13 the13 client13 by13 sending13 late13 ACKsndash No13 need13 to13 keep13 track13 of13 delayed13 ACKsndash The13 server13 can13 perform13 other13 tasks13 instead
bull Reduced13 network13 traffic
Thank13 youQuesons
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-links-json-02txt
123
RFC 6690 (link-format) documents are somewhat foreign to many web app developerssect would prefer to have them in JSON format
There is no standard way to represent link-format documents in applicationssect but everyone knows how to handle JSON
Define a standard JSON translation for link-format
Itrsquos
not
rock
et
scien
ce
ltsensorsgtct=40title=Sensor Index ltsensorstempgtrt=temperature-cif=sensor ltsensorslightgtrt=light-luxif=sensor lthttpwwwexamplecomsensorst123gt anchor=sensorstemprel=describedby lttgtanchor=sensorstemprel=alternate [hrefsensorsct40titleSensor Index hrefsensorstemprttemperature-cifsensor hrefsensorslightrtlight-luxifsensor hrefhttpwwwexamplecomsensorst123 anchorsensorstempreldescribedby hreftanchorsensorstemprelalternate]
124
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-ipsec-for-coap-00txt
IPsec definitions for CoAP Mostly placeholder at this time Who has implementation experience with this
125
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-cross-reverse-convention-00txt
This draft has two lines of payload(based on a WGLC comment by Cullen Jennings)
coap12344567foobara=3
httpwwwproxycomwellknowncore-translate1234_4567foobara=3
Is that a useful convention to have
126
Insert CI slides here
127
128
0
5
10
15
20
25
30
35
40
10 20 30 40 50 60 70
good
put (
pps)
pps
Goodput vs pps (Econotags)
goodput
[Khattak preliminary]
Congestion Control
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-cocoa-00txt
ldquoadvancedrdquo cc (The draft is just a first shot) Others may have better ideas
129
Insert post-WGLC discussion slides here
130
Stop Continue Start
131
An Agile Retrospective
http6lowappnet coreIETF86 2013-03-12-13
Stop
132
Endless new CoAP optionssect instead use RESTful as much as possible
Move general security lifecycle out Looking at theoretical problems
http6lowappnet coreIETF86 2013-03-12-13
Continue
Interops Running code Look at real-world examples and deployments Solve their actual problems
sect Unilateral enhancements eg higher performance congestion control
sect Transports (SMS hellip)sect Make Web linking and Directories more and more usefulsect RESTful Design Paradigms for real-world problems
133
http6lowappnet coreIETF86 2013-03-12-13
Start
Further push into the (browser) web world (HTML5 browser security)
Specific supporting worksect SenMLsect URI work (dev URN hellip)sect Security Processes (next slide)
Spin outsect (We donrsquot really get to decide where this is done)
134
http6lowappnet coreIETF86 2013-03-12-13
Security
Integrate Application Network Group Keyingsect Tunnel-free setup
Donrsquot redo what has been done alreadysect ZigBee IP is finesect But what about other scenarios
Simple REST interfaces for working with keying materials and authorizationsect Start with defining objectives
Object Security for Constrained Nodes135
Re-chartering CoREWhat do we want to do now that wersquore grown up
Zach ShelbyCoRE WG IETF-86 Orlando
What is the scope
bull So we have a protocol and Web Linking what next
bull Keep with what we know besthellip1 Enhancements around CoAP2 New transports for CoAP3 New representations for Web Links4 General application layer solutions
CoRE WG IETF-86 Orlando 2
Enhancements around CoAP
bull Advanced congestion control
CoRE WG IETF-86 Orlando 3
New Transports for CoAP
bull Infrastructure for CoAP over foondash httptoolsietforgiddraft-silverajan-core-
coap-alternative-transports-01txtbull CoAP over SMS
ndash httptoolsietforgiddraft-becker-core-coap-sms-gprs-03txt
ndash OMA Lightweightbull CoAP over TCP
ndash httptoolsietforgiddraft-li-core-coap-payload-length-option-01txt
CoRE WG IETF-86 Orlando 4
New support for Web Links
bull JSON Web Linksndash httptoolsietforgiddraft-bormann-core-links-
json-02txt
2332010 CoRE WG IETF-77 Anaheim 5
General application layer solutions
bull Resource Directoryndash httptoolsietforgiddraft-shelby-core-
resource-directory-05txtndash OMA Lightweight
2332010 CoRE WG IETF-77 Anaheim 6
CoAP13 Communicaon13 with13 Alternave13 Transports
Bill Silverajan and Teemu SavolainenCore WG IETF 86 Orlando
031113
Objecves13 (In13 Scope)
bull Unambiguous13 representaon13 of13 transport13 to13 be13 used13 by13 CoAP
bull Details13 how13 the13 transport13 can13 carry13 CoAP13 packet
bull Focus13 is13 on13 what13 CoAP13 communicaons13 requirements13 are
bull Allow13 CoAP13 mechanisms13 to13 exploit13 cross-shy‐layer13 opmisaons
51
031113
Non13 Goals13 (Not13 in13 scope)
bull Applicaon-shy‐level13 QoS13 requirementsbull Real-shy‐me13 constraintsbull Ordering13 reliability13 congeson13 controlbull Applicaon13 and13 network13 adaptaonbull Mobility13 and13 readdressing13 supportbull Network13 protocol13 (eg13 IPsec)13 configuraon
52
031113
Use13 Cases
bull NAT13 and13 Firewall13 traversal13 with13 TCPbull Delay13 Tolerant13 Networkingbull Non-shy‐IP13 Low13 Energy13 Protocols
53
031113
Related13 Work
bull OMA13 Lightweight13 M2M13 Protocolbull CoAP13 over13 SMSGPRSUSSD
54
031113
What13 does13 the13 work13 entail
bull The13 ability13 to13 specify13 end13 point13 idenfiers13 and13 URIs13 to13 reflect13 which13 transport13 CoAP13 can13 use
bull The13 ability13 to13 register13 to13 resource13 directories13 resource13 types13 reflecng13 types13 of13 transport13 available
bull Ability13 for13 mul-shy‐transport13 nodes13 to13 select13 transport13 to13 use13 without13 significant13 alteraon13 to13 CoAP13 packet13 structure
55
031113
Points13 to13 consider
bull Requirements13 for13 transport13 layer13 protocol13 to13 carry13 CoAP13 packets
bull Representaon13 of13 URI13 scheme13 for13 generic13 transport13 protocols
bull Opon13 extensions13 for13 CoAP13 to13 express13 available13 transports
bull Mapping13 and13 message13 sizebull Security13 consideraons
56
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
URI13 =13 scheme13 13 13 authority13 path-shy‐abempty13 [13 query13 ]
bull Within13 the13 scheme13 namebull In13 the13 URI13 pathbull As13 a13 query13 component
57
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
bull Within13 the13 scheme13 namendash coap+tel+15105550101well-shy‐knowncorendash coap+tcpexamplecom5683temperaturendash coap+blel2cap[1234567890AB]4pulse
bull Easy13 URI13 parsing13 for13 transport13 type13 and13 idenfier
bull Each13 new13 scheme13 name13 requires13 IANA13 registraon
58
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
bull In13 the13 URI13 pathndash coaphostexamplecomtransport=tcpwell-shy‐knowncorert=core-shy‐rd
bull Easy13 adopon13 of13 new13 (and13 experimental)13 CoAP13 transports13 without13 IANA13 registraon
bull Caveat13 Uri-shy‐Path13 opon13 is13 a13 Crical13 CoAP13 opon13 see13 secon13 54113 of13 I-shy‐Diep-shy‐core-shy‐coap
59
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
bull As13 a13 URI13 query13 componentndash coaphostexamplecomwell-shy‐knowncorert=core-shy‐rdq=tcp
bull Also13 easy13 to13 adopt13 new13 (and13 experimental)13 CoAP13 transports13 without13 IANA13 registraon
bull Caveat13 Uri-shy‐Query13 opon13 is13 a13 Crical13 CoAP13 opon13 see13 secon13 54113 of13 I-shy‐Diep-shy‐core-shy‐coap
60
031113
URI13 Representaons13 for13 CoAPNon13 standard13 ways
bull Transport13 in13 the13 URI13 authority13 componentndash coaphost[port][transport]13 instead13 of13 coaphost[port]
bull Transport13 as13 a13 service13 URLndash servicecoaptcphostexamplecomwell-shy‐knowncorert=core-shy‐rd
bull Above13 two13 ways13 break13 exisng13 compability13 (although13 both13 are13 based13 on13 valid13 IANA13 URI13 registraons)
61
031113
URI13 Representaons13 for13 CoAPMiscellaneous13 Consideraons
bull Ensure13 that13 transport13 is13 defined13 unambiguously13 (eg13 L2CAP13 used13 by13 both13 BLE13 and13 standard13 Bluetooth13 so13 avoid13 rdquocoap+l2caprdquo13 or13 rdquotransport=l2caprdquo13 or13 rdquoq=l2caprdquondash Can13 be13 done13 as13 WG13 consensusndash Namespace13 approach13 eg13 rdquocoap+blel2caprdquo13 or13 rdquoq=blel2caprdquo
bull Allow13 end-shy‐points13 to13 use13 CoAP13 Resource13 Directory13 to13 register13 alternave13 transports13 and13 idenfiers13 and13 provide13 periodic13 updatesndash Register13 rdquocore-shy‐transportrdquo13 resource13 type
62
031113
Transport13 Consideraons
bull Uniqueness13 of13 end-shy‐point13 idenficaonbull Communicaon13 support13 Unidireconal13 Bidireconal13 1N13 (broadcast13 mulcast13 anycast)13 messaging
bull Binary13 encoding13 Network13 byte13 orderingbull MTU13 correlaon13 with13 CoAP13 PDU13 sizebull Transport13 latency
63
031113
Security13 Consideraons
bull Drar13 does13 not13 introduce13 new13 security13 requirements13 by13 itself
bull There13 may13 be13 privacy13 issues13 if13 nodes13 use13 telephone13 numbers13 or13 MAC13 addresses13 as13 public13 end13 point13 idenfiers
64
Akbar Rahman
IETF 86 March 2013 httpwwwietforgiddraft-rahman-core-sleepy-02txt
Enhanced Sleepy Node Support for CoAP
Introduction
It is expected that in CoAP networks there will be a certain portion of devices that are sleepy and which may occasionally go into a sleep mode (ie go into a low power state to conserve power) and subsequently have reduced CoAP protocol communication ability
This I-D proposes a minimal and efficient mechanism building on the Resource Directory concept (which will be integrated into a CoAP Proxy) to enhance sleepy node support in CoAP networks
Main Question from IETF-85 (Atlanta)
What performance benefit does the proposed Sleepy Node support solution give in a network that already has standard CoAP caching enabled
Sleepy Node Performance Analysis
Experimental Network
1-5 clients
Both Sleepy and Non-
Sleepy servers
Sleepy Node Performance Analysis Network Setup
CoAPSleepyServer(s)
CoAPSleepAwareReverseProxy
CoAP
Client(s)
Request
Response
Sleep9AwareCoREResourceDirectoryCapability
PublishedSleepParameters
Sleep9AwareCoAPStoreandForwardCapability Response
Request
SleepAwareCoAP503ResponseCapability
CoAPCachingCapability
bull Server supports publishing sleep parameters to proxy bull Eg Irsquom going to be asleep for X seconds
bull Proxy supports sleep-awareness capabilities bull Proxy also supports caching capability based off of maxAge bull Protocol flow similar to approach of Figure 1 (Synchronous RD Based Sleep
Tracking) of I-D
Proxy capabilities can be selectively enableddisabled
Proxy ndash Server Interface
Client ndash Proxy Interface
CoAP Sleep-Aware Reverse Proxy Features CoRE Sleep-aware Resource Directory
Support storing published sleep parameters from CoAP servers sleepState (AWAKE ASLEEP) sleepDuration
Sleep-aware CoAP 503 Response Capability If CoAP request to a sleeping server is received proxy returns a
lsquo503 Retry-Afterrsquo response to client 503 contains a timestamp indicating when the sever will wake back up
(timestamp delivered in CoAP maxAge option) Sleep-aware CoAP Store-and-Forward Capability
If CoAP request to a sleeping server is received proxy stores request until server wakes up and then forwards it
Caching capability Cache GET responses from server if maxAge option is present
(this is not a sleep aware feature)
Goals of Performance Analysis
For networks having sleepy servers provide measurements to quantify the impact that CoAP sleep-awareness capabilities can have
See if sleep-awareness capabilities can
provide additional benefits even when CoAP caching is used
Overview of Performance Analysis Performed The analysis was broken up into a set of test scenarios Each test scenario used a different combination of the following
variables Client issued GET requests Server was configured as a sleepy or non-sleepy server Proxy caching of GET responses was enabled or disabled Proxy sleep-aware 503 response capability was enabled or disabled Proxy store-and-forward capability was enabled or disabled maxAge in GET responses ndash Two values were tested 60sec and 5sec of Clients ndash Two values were used ndash 1 client and 5 clients
For comparison purposes the following were held constant across all test scenarios Client issued a fixed number of requests (100) across all test scenarios Client used a delay between each GET request (35sec) to better exercise
proxyrsquos caching and sleep-awareness capabilities For sleepy server test scenarios the server slept 60 sec awake for 3 sec
Format of Results The following results were collected for each
test scenario
Breakdown of the and types of transactions occurring between clientproxyserver
ldquoGETrdquo ndash Test Scenario Results
GET ndash Description of Test Scenarios
TestScenarios-GET
Scenario
CoAPSleepyServerSe7ngs CoAPSleepAwareReverseProxySe7ngs CoAPClientSe7ngs
SleepDuragton(sec)
AwakeDuragton(sec)
maxAge(sec) Caching SleepAwareSAF+
503NumberofClients
NumberofGETs
DelayBetweenClient
Requests(sec)
1a 0 Always 60 Enabled Disabled 1 100 35
1b 60 3 60 Enabled Disabled 1 100 35
1c 60 3 60 Enabled Enabled 1 100 35
2a 0 Always 60 Enabled Disabled 5 100 35
2b 60 3 60 Enabled Disabled 5 100 35
2c 60 3 60 Enabled Enabled 5 100 35
3a 0 Always 5 Enabled Disabled 5 100 35
3b 60 3 5 Enabled Disabled 5 100 35
3c 60 3 5 Enabled Enabled 5 100 35
ldquoGETrdquo ndash Test Scenario 1 Results
maxAge = 60 and 1 Client
GET ndash Scenario 1 ClientProxy Interface Transaction Mix
Scenarios 1a - Non-Sleepy Server Caching Proxy maxAge = 60sec 1b- Sleepy Server Caching Proxy maxAge = 60sec 1c - Sleepy Server Sleep Aware Proxy maxAge = 60sec
Sleep Aware Proxy has better performance for sleepy servers
0
100
200
300
400
500
600
700
1a 1b 1c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
GET ndash Scenario 1 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
Scenarios 1a - Non-Sleepy Server Caching Proxy maxAge = 60sec 1b- Sleepy Server Caching Proxy maxAge = 60sec 1c - Sleepy Server Sleep Aware Proxy maxAge = 60sec
0
100
200
300
400
500
600
700
800
1a 1b 1c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
ldquoGETrdquo ndash Test Scenario 2 Results
maxAge = 60 and 5 Clients
GET ndash Scenario 2 ClientProxy Interface Transaction Mix
Sleep Aware Proxy has slightly better performance for sleepy servers
0
200
400
600
800
1000
1200
1400
2a 2b 2c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
Scenarios 2a - Non-Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2b- Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2c - Sleepy Server Sleep Aware Proxy maxAge = 60sec 5 Clients
See ldquoExperimental Artifactsrdquo Note 1
GET ndash Scenario 2 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has slightly better performance for sleepy servers
0
50
100
150
200
250
300
350
400
2a 2b 2c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
Scenarios 2a - Non-Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2b- Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2c - Sleepy Server Sleep Aware Proxy maxAge = 60sec 5 Clients
See ldquoExperimental Artifactsrdquo Note 2
Experimental Artifacts Note 1
Currently in the experiment the sleep aware proxy checks the cached state of a resource before putting a request into its Store-and-forward queue while a server is sleeping Once in the queue the proxy unconditionally forwards the queued requests to the server once it wakes up This is not the most efficient setup and can easily be improved If the proxy instead checks its cache again before forwarding each queued request it may not need to forward the request to the server For example if there are two queued GET requests in the proxyrsquos queue that address the same resource Only the first request needs to be sent to the server the second request can use the cached response from the first request
Note 2 Currently in the experiment the sleepy server sends a sleepState PUT request to the
proxy each time it goes to sleep This is not the most efficient setup and can easily be improved For example if the server assumes that the proxy can keep track of its ONOFF cycles with its internal timers (eg as per Fig 1 of I-D) then the number of messages from the sleepy server dramatically goes down
ldquoGETrdquo ndash Test Scenario 3 Results
maxAge = 5 and 5 Clients
GET ndash Scenario 3 ClientProxy Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
Scenarios 3a - Non-Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3b- Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3c - Sleepy Server Sleep Aware Proxy maxAge = 5sec 5 Clients
0
500
1000
1500
2000
2500
3000
3500
4000
4500
5000
3a 3b 3c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
GET ndash Scenario 3 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
0
1000
2000
3000
4000
5000
6000
7000
3a 3b 3c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
Scenarios 3a - Non-Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3b- Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3c - Sleepy Server Sleep Aware Proxy maxAge = 5sec 5 Clients
Conclusions
Conclusions These results show that sleep-aware CoAP
proxy features can significantly optimize communication with sleepy servers in most scenarios
These results also show that sleep-
awareness capabilities can provide additional benefits above and beyond CoAP caching in most scenarios
Backup
Current CoAP Support of Sleepy Node (12)
CoAP proxies can use a previously cached response to service a new GET request for a sleepy origin server (as in HTTP) But if no valid cache then proxy has to attempt to
retrieve and may fail if origin server is sleeping [I-Dietf-core-coap]
Clients can discover list of resources from RD (GET rd-lookuphellip) for sleepy servers But attempt to GET resource from sleepy origin server
may fail if origin server is sleeping [IDietf-core-link-format amp IDshelby-core-resource-
directory]
Current CoAP Support of Sleepy Node (22)
Lower layer support for sleepy nodes in most wireless technologies (eg WiFi ZigBee) But limited to MAC packet scheduling for sleepy nodes
and not aware of specific needs of IP applications (like CoAP)
Proposal ndash RD Based Sleep Tracking (14)
The current CoAP approach to support sleepy nodes can be significantly improved by introducing RD based mechanisms for a CoAP client to determine whether A targeted resource is located on a sleepy server A sleepy server is currently in sleep mode or not
There is any associated caching Proxy (possibly the RD itself) for a sleepy server
Proposal ndash RD Based Sleep Tracking (24)
We define the following new RD attributes to characterize the properties of a sleepy node SleepState - Indicates whether the node is currently in
sleep mode or not (ie Sleeping or Awake) SleepDuration - Indicates the maximum duration of time
that the node stays in sleep mode TimeSleeping - Indicates the length of time the node
has been sleeping (ie if Sleep State = Sleeping) NextSleep - Indicates the next time the node will go to
sleep (ie if Sleep State = Awake)
CachingProxy ndash Indicates the caching proxy of the sleepy node (ie the RD itself or another node)
Proposal ndash RD Based Sleep Tracking (34)
These attributes are all server (node) level and are new parameters added to the RD URI Template Variables
Finally we also define a new lookup-type (ss) for the RD lookup interface specified in [I-Dshelby-core-resource-directory] This new lookup-type supports looking up the
ldquoSleepStaterdquo (ss) of a specified end-point
Proposal ndash RD Based Sleep Tracking (44)
The three time based parameters (SleepDuration TimeSleeping NextSleep) can be based on either an absolute network time (for a time synchronized network) or a relative local time (measured at the local node)
Following the approach of [I-Dietf-core-link-format] and [I-Dshelby-core-resource-directory] sleep parameters for sleepy servers can be stored by the server in the RD and accessed by all interested clients
Examples of using these parameters in a synchronous or asynchronous manner are shown in the I-D
http6lowappnet coreIETF86 2013-03-12-13
We assume people have read the drafts
Meetings serve to advance difficult issues by making good use of face-to-face communications
Note Well Be aware of the IPR principles according to RFC 3979 and its updates
uumlBlue sheetsuumlScribe(s)
96
drar-shy‐iep-shy‐core-shy‐coapsubmiqed13 to13 IESG
2013-shy‐03-shy‐13
97
OMA Lightweight M2M Overview(A new standard using lots of IETF specs including DTLS
CoAP Block Observe Resource Directory SenMLhellip)
Zach ShelbyCoRE WG IETF-86 Orlando
OMA Lightweight M2Mbull Open Mobile Alliance is well known for Device Management (DM)bull OMA Lightweight M2M is a new standard from the alliance
ndash Focused on constrained Cellular and sensor network M2M devicesndash Driven by leading operators and vendors
bull Scopendash Interfaces protocol amp security between Device and Serverndash Object and Resource modelndash Bootstrap Device Access Control Connectivity and Firmware Objects
bull Draft Specifications are availablendash httpmemberopenmobileallianceorgftpPublic_documentsDM
LightweightM2MPermanent_documentsOMA-TS-LightweightM2M-V1_0_0-20130301-Dzip
bull Timelinendash Requirements and Architecture completed 3Q2012ndash Spec ready for Consistency Review 2Q2013ndash Candidate Approval expected 3Q2013
2 CoRE WG IETF-86 Orlando
Architecture
3
Scope of LWM2M
CoRE WG IETF-86 Orlando
Object Model
bull A Client has one or more Object Instancesbull An Object is a collection of Resourcesbull A Resource is an atomic piece of information
ndash Read Written or Executed
bull Resources can have multiple instancesbull Objects and Resources are identified by a
16-bit Integer Instances by an 8-bit Integerbull ObjectsResources are accessed with
simple URIs Object IDObject InstanceResource ID
eg 1213
4 CoRE WG IETF-86 Orlando
CoRE WG IETF-86 Orlando
CoRE Resource Directory
draft-shelby-core-resource-directory-05
Z Shelby C Bormann S Krco
Backgroundbull Not a new concept
ndash think web search engine or any link directorybull Defines the interfaces to a Resource Directorybull Based on Web Linking framework and the CoRE Link Formatbull Generic REST design for use over HTTP and CoAPbull Used by OMA Lightweight M2Mbull Has already been deployed
ndash In traffic monitoring systemsndash In street lighting systemsndash For vehicular asset trackingndash By a major Cellular M2M operator
Changes since -04
bull Restricted Update to parameter updatesbull Added pagination support for the Lookup interfacebull Changed rt= to et= for the registration amp update
interfacebull Added group support
Group Management
bull RD now includes group management featuresbull New Group Function Set
ndash Register a groupbull Group name domain multicast address endpoint members
ndash Remove a groupbull Group lookup using the Lookup Function Set
ndash List registered groupsndash Find the members of a groupndash Find groups with certain endpoints or resources
Registering a Group
EP RD
| |
| - POST rd-groupgp=lights ltgtep=node1 --gt |
| |
| |
| lt---- 201 Created Location rd-group12 ---- |
| |
Req POST coaprdexamplecomrd-groupgp=lights
Payload
ltgtep=node1
ltgtep=node2
Res 201 Created
Location rd-group12
Looking up Group Members
Client RD
| |
| ----- GET rd-lookupepgp=lights1 ----------------------gt |
| |
| |
| lt-- 205 Content ltrdgtd=domain1ltrdgtd=domain2 --------- |
| |
Req GET rd-lookupepgp=lights1
Res 205 Content
ltcoaphostportgtep=node1
ltcoaphostportgtep=node2rdquo
Things for the futurebull Support for JSON representation of Web Links
ndash httptoolsietforgiddraft-bormann-core-links-json-02txtbull Registry for RD registration query parameters
ndash Already OMA Lightweight has defined some new onesbull More examples
Group 3 ldquonew workrdquo(continued)
109
drar-shy‐greevenbosch-shy‐core-shy‐profile-shy‐descripon-shy‐01Bert13 GreevenboschJeroen13 Hoebeke
Isam13 IshaqFloris13 Van13 den13 Abeele
Descripon
bull JSON13 format13 for13 signalling13 the13 servers13 capabilies
bull Signalling13 of13 supported13 opons13 media13 types13 and13 block13 sizendash Other13 items13 can13 be13 added
bull Filtering13 on13 specific13 fields13 through13 URI-shy‐Querybull Link13 hqpdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐profile-shy‐descripon
well-shy‐knownprofile
bull To13 acquire13 profile13 data13 of13 resources13 on13 a13 parcular13 service13 the13 well-shy‐knownprofile13 URI-shy‐path13 is13 introduced
bull For13 example13 to13 get13 all13 informaon13 from13 sensors13 served13 by13 wwwexampleorg13 we13 can13 do13 a13 GET13 to13 coapwwwexampleorgwell-shy‐knownprofile
bull Filtering13 on13 parcular13 resources13 is13 done13 through13 URI-shy‐Queries
Format
bull Currently13 the13 following13 fields13 are13 definedndash ldquopathrdquo13 contains13 the13 URI-shy‐path13 associated13 with13 a13 resource
ndash ldquooprdquo13 a13 numerical13 list13 of13 supported13 opon13 numbers
ndash ldquocfrdquo13 a13 numerical13 list13 of13 supported13 content-shy‐format13 numbers
ndash ldquob1srdquo13 ldquob2srdquo13 supported13 block13 sizes13 for13 Block113 and13 Block213 respecvely
Examplebull On13 the13 right13 is13 an13 example13 of13 a13 camera13 sensor13 at13 coapwwwexampleorgcam13 that13 supports13 the13 Uri-shy‐Host13 (3)13 ETag13 (4)13 Uri-shy‐Port13 (7)13 Uri-shy‐Path13 (11)13 Content-shy‐Format13 (12)13 Token13 (19)13 Block213 (23)13 and13 Proxy-shy‐Uri13 (35)13 opons
bull The13 supported13 content13 formats13 are13 textplain13 (0)13 applicaon13 link-shy‐format13 (40)13 and13 applicaonjson13 (50)
bull The13 supported13 Block213 can13 use13 25613 or13 51213 byte13 blocks
Req13 GET13 coapwwwexampleorgwell-shy‐knownprofile13 Res13 20513 Content13 (applicationjson)13 13 13 13 profile13 13 13 13 13 13 13 13 pathcam13 13 13 13 op[3471112192335]13 13 13 13 13 cf[04050]13 13 13 13 13 b2s[45]13 13 13 13
Filtering13 through13 use13 of13 URI-shy‐Query
bull Filtering13 can13 be13 done13 through13 the13 URI-shy‐Querybull Query13 format13 N=V
ndash N13 is13 a13 profile13 fieldndash V13 is13 the13 desired13 value
bull Examplesndash To13 find13 resources13 that13 support13 content13 format13 ldquoapplicaonjsonrdquo
13 GET13 wwwexampleorgwell-shy‐knownprofilecf=50ndash To13 get13 informaon13 about13 the13 camera
13 GET13 wwwexampleorgwell-shy‐knownprofilepath=cam
Open13 issues
bull Which13 other13 profile13 data13 needs13 signallingndash Content-shy‐type13 for13 different13 methods
bull Fix13 the13 order13 in13 which13 the13 profile13 fields13 must13 appearndash Non-shy‐fixed13 order13 easier13 extensible
bull Inheritance13 of13 a13 profile13 descriponbull Extend13 usage13 to13 signal13 the13 client13 profilebull Integraon13 with13 link13 format
Thank13 youQuesons
drar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval-shy‐00
Bert13 Greevenbosch
Descripon
bull The13 ldquoMinimumRequestInterval13 opon13 can13 be13 used13 to13 indicate13 the13 minimum13 me13 between13 two13 requests13 in13 a13 transacon
bull Originally13 intended13 for13 Block13 but13 also13 usable13 for13 other13 transaconsndash Example13 browsing13 a13 server
bull The13 goal13 is13 to13 reduce13 the13 server13 load13 and13 network13 traffic
bull Link13 hqpsdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval
Usage
bull The13 client13 keeps13 the13 server13 informed13 about13 its13 request13 speed13 through13 inclusion13 of13 the13 ldquoMinimumRequestIntervalrdquo13 opon
bull In13 responses13 the13 server13 fixes13 the13 minimum13 request13 interval13 through13 the13 same13 opon
bull The13 client13 obeys13 the13 speed13 indicated13 by13 the13 server
bull The13 client13 can13 send13 slower13 but13 not13 faster
Advantages
bull The13 server13 has13 means13 to13 limit13 the13 amount13 of13 incoming13 traffic
bull The13 server13 can13 prevent13 to13 become13 overloaded13 with13 too13 many13 tasks
bull The13 server13 does13 not13 need13 arficially13 slow13 down13 the13 client13 by13 sending13 late13 ACKsndash No13 need13 to13 keep13 track13 of13 delayed13 ACKsndash The13 server13 can13 perform13 other13 tasks13 instead
bull Reduced13 network13 traffic
Thank13 youQuesons
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-links-json-02txt
123
RFC 6690 (link-format) documents are somewhat foreign to many web app developerssect would prefer to have them in JSON format
There is no standard way to represent link-format documents in applicationssect but everyone knows how to handle JSON
Define a standard JSON translation for link-format
Itrsquos
not
rock
et
scien
ce
ltsensorsgtct=40title=Sensor Index ltsensorstempgtrt=temperature-cif=sensor ltsensorslightgtrt=light-luxif=sensor lthttpwwwexamplecomsensorst123gt anchor=sensorstemprel=describedby lttgtanchor=sensorstemprel=alternate [hrefsensorsct40titleSensor Index hrefsensorstemprttemperature-cifsensor hrefsensorslightrtlight-luxifsensor hrefhttpwwwexamplecomsensorst123 anchorsensorstempreldescribedby hreftanchorsensorstemprelalternate]
124
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-ipsec-for-coap-00txt
IPsec definitions for CoAP Mostly placeholder at this time Who has implementation experience with this
125
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-cross-reverse-convention-00txt
This draft has two lines of payload(based on a WGLC comment by Cullen Jennings)
coap12344567foobara=3
httpwwwproxycomwellknowncore-translate1234_4567foobara=3
Is that a useful convention to have
126
Insert CI slides here
127
128
0
5
10
15
20
25
30
35
40
10 20 30 40 50 60 70
good
put (
pps)
pps
Goodput vs pps (Econotags)
goodput
[Khattak preliminary]
Congestion Control
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-cocoa-00txt
ldquoadvancedrdquo cc (The draft is just a first shot) Others may have better ideas
129
Insert post-WGLC discussion slides here
130
Stop Continue Start
131
An Agile Retrospective
http6lowappnet coreIETF86 2013-03-12-13
Stop
132
Endless new CoAP optionssect instead use RESTful as much as possible
Move general security lifecycle out Looking at theoretical problems
http6lowappnet coreIETF86 2013-03-12-13
Continue
Interops Running code Look at real-world examples and deployments Solve their actual problems
sect Unilateral enhancements eg higher performance congestion control
sect Transports (SMS hellip)sect Make Web linking and Directories more and more usefulsect RESTful Design Paradigms for real-world problems
133
http6lowappnet coreIETF86 2013-03-12-13
Start
Further push into the (browser) web world (HTML5 browser security)
Specific supporting worksect SenMLsect URI work (dev URN hellip)sect Security Processes (next slide)
Spin outsect (We donrsquot really get to decide where this is done)
134
http6lowappnet coreIETF86 2013-03-12-13
Security
Integrate Application Network Group Keyingsect Tunnel-free setup
Donrsquot redo what has been done alreadysect ZigBee IP is finesect But what about other scenarios
Simple REST interfaces for working with keying materials and authorizationsect Start with defining objectives
Object Security for Constrained Nodes135
Re-chartering CoREWhat do we want to do now that wersquore grown up
Zach ShelbyCoRE WG IETF-86 Orlando
What is the scope
bull So we have a protocol and Web Linking what next
bull Keep with what we know besthellip1 Enhancements around CoAP2 New transports for CoAP3 New representations for Web Links4 General application layer solutions
CoRE WG IETF-86 Orlando 2
Enhancements around CoAP
bull Advanced congestion control
CoRE WG IETF-86 Orlando 3
New Transports for CoAP
bull Infrastructure for CoAP over foondash httptoolsietforgiddraft-silverajan-core-
coap-alternative-transports-01txtbull CoAP over SMS
ndash httptoolsietforgiddraft-becker-core-coap-sms-gprs-03txt
ndash OMA Lightweightbull CoAP over TCP
ndash httptoolsietforgiddraft-li-core-coap-payload-length-option-01txt
CoRE WG IETF-86 Orlando 4
New support for Web Links
bull JSON Web Linksndash httptoolsietforgiddraft-bormann-core-links-
json-02txt
2332010 CoRE WG IETF-77 Anaheim 5
General application layer solutions
bull Resource Directoryndash httptoolsietforgiddraft-shelby-core-
resource-directory-05txtndash OMA Lightweight
2332010 CoRE WG IETF-77 Anaheim 6
031113
Objecves13 (In13 Scope)
bull Unambiguous13 representaon13 of13 transport13 to13 be13 used13 by13 CoAP
bull Details13 how13 the13 transport13 can13 carry13 CoAP13 packet
bull Focus13 is13 on13 what13 CoAP13 communicaons13 requirements13 are
bull Allow13 CoAP13 mechanisms13 to13 exploit13 cross-shy‐layer13 opmisaons
51
031113
Non13 Goals13 (Not13 in13 scope)
bull Applicaon-shy‐level13 QoS13 requirementsbull Real-shy‐me13 constraintsbull Ordering13 reliability13 congeson13 controlbull Applicaon13 and13 network13 adaptaonbull Mobility13 and13 readdressing13 supportbull Network13 protocol13 (eg13 IPsec)13 configuraon
52
031113
Use13 Cases
bull NAT13 and13 Firewall13 traversal13 with13 TCPbull Delay13 Tolerant13 Networkingbull Non-shy‐IP13 Low13 Energy13 Protocols
53
031113
Related13 Work
bull OMA13 Lightweight13 M2M13 Protocolbull CoAP13 over13 SMSGPRSUSSD
54
031113
What13 does13 the13 work13 entail
bull The13 ability13 to13 specify13 end13 point13 idenfiers13 and13 URIs13 to13 reflect13 which13 transport13 CoAP13 can13 use
bull The13 ability13 to13 register13 to13 resource13 directories13 resource13 types13 reflecng13 types13 of13 transport13 available
bull Ability13 for13 mul-shy‐transport13 nodes13 to13 select13 transport13 to13 use13 without13 significant13 alteraon13 to13 CoAP13 packet13 structure
55
031113
Points13 to13 consider
bull Requirements13 for13 transport13 layer13 protocol13 to13 carry13 CoAP13 packets
bull Representaon13 of13 URI13 scheme13 for13 generic13 transport13 protocols
bull Opon13 extensions13 for13 CoAP13 to13 express13 available13 transports
bull Mapping13 and13 message13 sizebull Security13 consideraons
56
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
URI13 =13 scheme13 13 13 authority13 path-shy‐abempty13 [13 query13 ]
bull Within13 the13 scheme13 namebull In13 the13 URI13 pathbull As13 a13 query13 component
57
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
bull Within13 the13 scheme13 namendash coap+tel+15105550101well-shy‐knowncorendash coap+tcpexamplecom5683temperaturendash coap+blel2cap[1234567890AB]4pulse
bull Easy13 URI13 parsing13 for13 transport13 type13 and13 idenfier
bull Each13 new13 scheme13 name13 requires13 IANA13 registraon
58
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
bull In13 the13 URI13 pathndash coaphostexamplecomtransport=tcpwell-shy‐knowncorert=core-shy‐rd
bull Easy13 adopon13 of13 new13 (and13 experimental)13 CoAP13 transports13 without13 IANA13 registraon
bull Caveat13 Uri-shy‐Path13 opon13 is13 a13 Crical13 CoAP13 opon13 see13 secon13 54113 of13 I-shy‐Diep-shy‐core-shy‐coap
59
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
bull As13 a13 URI13 query13 componentndash coaphostexamplecomwell-shy‐knowncorert=core-shy‐rdq=tcp
bull Also13 easy13 to13 adopt13 new13 (and13 experimental)13 CoAP13 transports13 without13 IANA13 registraon
bull Caveat13 Uri-shy‐Query13 opon13 is13 a13 Crical13 CoAP13 opon13 see13 secon13 54113 of13 I-shy‐Diep-shy‐core-shy‐coap
60
031113
URI13 Representaons13 for13 CoAPNon13 standard13 ways
bull Transport13 in13 the13 URI13 authority13 componentndash coaphost[port][transport]13 instead13 of13 coaphost[port]
bull Transport13 as13 a13 service13 URLndash servicecoaptcphostexamplecomwell-shy‐knowncorert=core-shy‐rd
bull Above13 two13 ways13 break13 exisng13 compability13 (although13 both13 are13 based13 on13 valid13 IANA13 URI13 registraons)
61
031113
URI13 Representaons13 for13 CoAPMiscellaneous13 Consideraons
bull Ensure13 that13 transport13 is13 defined13 unambiguously13 (eg13 L2CAP13 used13 by13 both13 BLE13 and13 standard13 Bluetooth13 so13 avoid13 rdquocoap+l2caprdquo13 or13 rdquotransport=l2caprdquo13 or13 rdquoq=l2caprdquondash Can13 be13 done13 as13 WG13 consensusndash Namespace13 approach13 eg13 rdquocoap+blel2caprdquo13 or13 rdquoq=blel2caprdquo
bull Allow13 end-shy‐points13 to13 use13 CoAP13 Resource13 Directory13 to13 register13 alternave13 transports13 and13 idenfiers13 and13 provide13 periodic13 updatesndash Register13 rdquocore-shy‐transportrdquo13 resource13 type
62
031113
Transport13 Consideraons
bull Uniqueness13 of13 end-shy‐point13 idenficaonbull Communicaon13 support13 Unidireconal13 Bidireconal13 1N13 (broadcast13 mulcast13 anycast)13 messaging
bull Binary13 encoding13 Network13 byte13 orderingbull MTU13 correlaon13 with13 CoAP13 PDU13 sizebull Transport13 latency
63
031113
Security13 Consideraons
bull Drar13 does13 not13 introduce13 new13 security13 requirements13 by13 itself
bull There13 may13 be13 privacy13 issues13 if13 nodes13 use13 telephone13 numbers13 or13 MAC13 addresses13 as13 public13 end13 point13 idenfiers
64
Akbar Rahman
IETF 86 March 2013 httpwwwietforgiddraft-rahman-core-sleepy-02txt
Enhanced Sleepy Node Support for CoAP
Introduction
It is expected that in CoAP networks there will be a certain portion of devices that are sleepy and which may occasionally go into a sleep mode (ie go into a low power state to conserve power) and subsequently have reduced CoAP protocol communication ability
This I-D proposes a minimal and efficient mechanism building on the Resource Directory concept (which will be integrated into a CoAP Proxy) to enhance sleepy node support in CoAP networks
Main Question from IETF-85 (Atlanta)
What performance benefit does the proposed Sleepy Node support solution give in a network that already has standard CoAP caching enabled
Sleepy Node Performance Analysis
Experimental Network
1-5 clients
Both Sleepy and Non-
Sleepy servers
Sleepy Node Performance Analysis Network Setup
CoAPSleepyServer(s)
CoAPSleepAwareReverseProxy
CoAP
Client(s)
Request
Response
Sleep9AwareCoREResourceDirectoryCapability
PublishedSleepParameters
Sleep9AwareCoAPStoreandForwardCapability Response
Request
SleepAwareCoAP503ResponseCapability
CoAPCachingCapability
bull Server supports publishing sleep parameters to proxy bull Eg Irsquom going to be asleep for X seconds
bull Proxy supports sleep-awareness capabilities bull Proxy also supports caching capability based off of maxAge bull Protocol flow similar to approach of Figure 1 (Synchronous RD Based Sleep
Tracking) of I-D
Proxy capabilities can be selectively enableddisabled
Proxy ndash Server Interface
Client ndash Proxy Interface
CoAP Sleep-Aware Reverse Proxy Features CoRE Sleep-aware Resource Directory
Support storing published sleep parameters from CoAP servers sleepState (AWAKE ASLEEP) sleepDuration
Sleep-aware CoAP 503 Response Capability If CoAP request to a sleeping server is received proxy returns a
lsquo503 Retry-Afterrsquo response to client 503 contains a timestamp indicating when the sever will wake back up
(timestamp delivered in CoAP maxAge option) Sleep-aware CoAP Store-and-Forward Capability
If CoAP request to a sleeping server is received proxy stores request until server wakes up and then forwards it
Caching capability Cache GET responses from server if maxAge option is present
(this is not a sleep aware feature)
Goals of Performance Analysis
For networks having sleepy servers provide measurements to quantify the impact that CoAP sleep-awareness capabilities can have
See if sleep-awareness capabilities can
provide additional benefits even when CoAP caching is used
Overview of Performance Analysis Performed The analysis was broken up into a set of test scenarios Each test scenario used a different combination of the following
variables Client issued GET requests Server was configured as a sleepy or non-sleepy server Proxy caching of GET responses was enabled or disabled Proxy sleep-aware 503 response capability was enabled or disabled Proxy store-and-forward capability was enabled or disabled maxAge in GET responses ndash Two values were tested 60sec and 5sec of Clients ndash Two values were used ndash 1 client and 5 clients
For comparison purposes the following were held constant across all test scenarios Client issued a fixed number of requests (100) across all test scenarios Client used a delay between each GET request (35sec) to better exercise
proxyrsquos caching and sleep-awareness capabilities For sleepy server test scenarios the server slept 60 sec awake for 3 sec
Format of Results The following results were collected for each
test scenario
Breakdown of the and types of transactions occurring between clientproxyserver
ldquoGETrdquo ndash Test Scenario Results
GET ndash Description of Test Scenarios
TestScenarios-GET
Scenario
CoAPSleepyServerSe7ngs CoAPSleepAwareReverseProxySe7ngs CoAPClientSe7ngs
SleepDuragton(sec)
AwakeDuragton(sec)
maxAge(sec) Caching SleepAwareSAF+
503NumberofClients
NumberofGETs
DelayBetweenClient
Requests(sec)
1a 0 Always 60 Enabled Disabled 1 100 35
1b 60 3 60 Enabled Disabled 1 100 35
1c 60 3 60 Enabled Enabled 1 100 35
2a 0 Always 60 Enabled Disabled 5 100 35
2b 60 3 60 Enabled Disabled 5 100 35
2c 60 3 60 Enabled Enabled 5 100 35
3a 0 Always 5 Enabled Disabled 5 100 35
3b 60 3 5 Enabled Disabled 5 100 35
3c 60 3 5 Enabled Enabled 5 100 35
ldquoGETrdquo ndash Test Scenario 1 Results
maxAge = 60 and 1 Client
GET ndash Scenario 1 ClientProxy Interface Transaction Mix
Scenarios 1a - Non-Sleepy Server Caching Proxy maxAge = 60sec 1b- Sleepy Server Caching Proxy maxAge = 60sec 1c - Sleepy Server Sleep Aware Proxy maxAge = 60sec
Sleep Aware Proxy has better performance for sleepy servers
0
100
200
300
400
500
600
700
1a 1b 1c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
GET ndash Scenario 1 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
Scenarios 1a - Non-Sleepy Server Caching Proxy maxAge = 60sec 1b- Sleepy Server Caching Proxy maxAge = 60sec 1c - Sleepy Server Sleep Aware Proxy maxAge = 60sec
0
100
200
300
400
500
600
700
800
1a 1b 1c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
ldquoGETrdquo ndash Test Scenario 2 Results
maxAge = 60 and 5 Clients
GET ndash Scenario 2 ClientProxy Interface Transaction Mix
Sleep Aware Proxy has slightly better performance for sleepy servers
0
200
400
600
800
1000
1200
1400
2a 2b 2c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
Scenarios 2a - Non-Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2b- Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2c - Sleepy Server Sleep Aware Proxy maxAge = 60sec 5 Clients
See ldquoExperimental Artifactsrdquo Note 1
GET ndash Scenario 2 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has slightly better performance for sleepy servers
0
50
100
150
200
250
300
350
400
2a 2b 2c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
Scenarios 2a - Non-Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2b- Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2c - Sleepy Server Sleep Aware Proxy maxAge = 60sec 5 Clients
See ldquoExperimental Artifactsrdquo Note 2
Experimental Artifacts Note 1
Currently in the experiment the sleep aware proxy checks the cached state of a resource before putting a request into its Store-and-forward queue while a server is sleeping Once in the queue the proxy unconditionally forwards the queued requests to the server once it wakes up This is not the most efficient setup and can easily be improved If the proxy instead checks its cache again before forwarding each queued request it may not need to forward the request to the server For example if there are two queued GET requests in the proxyrsquos queue that address the same resource Only the first request needs to be sent to the server the second request can use the cached response from the first request
Note 2 Currently in the experiment the sleepy server sends a sleepState PUT request to the
proxy each time it goes to sleep This is not the most efficient setup and can easily be improved For example if the server assumes that the proxy can keep track of its ONOFF cycles with its internal timers (eg as per Fig 1 of I-D) then the number of messages from the sleepy server dramatically goes down
ldquoGETrdquo ndash Test Scenario 3 Results
maxAge = 5 and 5 Clients
GET ndash Scenario 3 ClientProxy Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
Scenarios 3a - Non-Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3b- Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3c - Sleepy Server Sleep Aware Proxy maxAge = 5sec 5 Clients
0
500
1000
1500
2000
2500
3000
3500
4000
4500
5000
3a 3b 3c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
GET ndash Scenario 3 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
0
1000
2000
3000
4000
5000
6000
7000
3a 3b 3c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
Scenarios 3a - Non-Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3b- Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3c - Sleepy Server Sleep Aware Proxy maxAge = 5sec 5 Clients
Conclusions
Conclusions These results show that sleep-aware CoAP
proxy features can significantly optimize communication with sleepy servers in most scenarios
These results also show that sleep-
awareness capabilities can provide additional benefits above and beyond CoAP caching in most scenarios
Backup
Current CoAP Support of Sleepy Node (12)
CoAP proxies can use a previously cached response to service a new GET request for a sleepy origin server (as in HTTP) But if no valid cache then proxy has to attempt to
retrieve and may fail if origin server is sleeping [I-Dietf-core-coap]
Clients can discover list of resources from RD (GET rd-lookuphellip) for sleepy servers But attempt to GET resource from sleepy origin server
may fail if origin server is sleeping [IDietf-core-link-format amp IDshelby-core-resource-
directory]
Current CoAP Support of Sleepy Node (22)
Lower layer support for sleepy nodes in most wireless technologies (eg WiFi ZigBee) But limited to MAC packet scheduling for sleepy nodes
and not aware of specific needs of IP applications (like CoAP)
Proposal ndash RD Based Sleep Tracking (14)
The current CoAP approach to support sleepy nodes can be significantly improved by introducing RD based mechanisms for a CoAP client to determine whether A targeted resource is located on a sleepy server A sleepy server is currently in sleep mode or not
There is any associated caching Proxy (possibly the RD itself) for a sleepy server
Proposal ndash RD Based Sleep Tracking (24)
We define the following new RD attributes to characterize the properties of a sleepy node SleepState - Indicates whether the node is currently in
sleep mode or not (ie Sleeping or Awake) SleepDuration - Indicates the maximum duration of time
that the node stays in sleep mode TimeSleeping - Indicates the length of time the node
has been sleeping (ie if Sleep State = Sleeping) NextSleep - Indicates the next time the node will go to
sleep (ie if Sleep State = Awake)
CachingProxy ndash Indicates the caching proxy of the sleepy node (ie the RD itself or another node)
Proposal ndash RD Based Sleep Tracking (34)
These attributes are all server (node) level and are new parameters added to the RD URI Template Variables
Finally we also define a new lookup-type (ss) for the RD lookup interface specified in [I-Dshelby-core-resource-directory] This new lookup-type supports looking up the
ldquoSleepStaterdquo (ss) of a specified end-point
Proposal ndash RD Based Sleep Tracking (44)
The three time based parameters (SleepDuration TimeSleeping NextSleep) can be based on either an absolute network time (for a time synchronized network) or a relative local time (measured at the local node)
Following the approach of [I-Dietf-core-link-format] and [I-Dshelby-core-resource-directory] sleep parameters for sleepy servers can be stored by the server in the RD and accessed by all interested clients
Examples of using these parameters in a synchronous or asynchronous manner are shown in the I-D
http6lowappnet coreIETF86 2013-03-12-13
We assume people have read the drafts
Meetings serve to advance difficult issues by making good use of face-to-face communications
Note Well Be aware of the IPR principles according to RFC 3979 and its updates
uumlBlue sheetsuumlScribe(s)
96
drar-shy‐iep-shy‐core-shy‐coapsubmiqed13 to13 IESG
2013-shy‐03-shy‐13
97
OMA Lightweight M2M Overview(A new standard using lots of IETF specs including DTLS
CoAP Block Observe Resource Directory SenMLhellip)
Zach ShelbyCoRE WG IETF-86 Orlando
OMA Lightweight M2Mbull Open Mobile Alliance is well known for Device Management (DM)bull OMA Lightweight M2M is a new standard from the alliance
ndash Focused on constrained Cellular and sensor network M2M devicesndash Driven by leading operators and vendors
bull Scopendash Interfaces protocol amp security between Device and Serverndash Object and Resource modelndash Bootstrap Device Access Control Connectivity and Firmware Objects
bull Draft Specifications are availablendash httpmemberopenmobileallianceorgftpPublic_documentsDM
LightweightM2MPermanent_documentsOMA-TS-LightweightM2M-V1_0_0-20130301-Dzip
bull Timelinendash Requirements and Architecture completed 3Q2012ndash Spec ready for Consistency Review 2Q2013ndash Candidate Approval expected 3Q2013
2 CoRE WG IETF-86 Orlando
Architecture
3
Scope of LWM2M
CoRE WG IETF-86 Orlando
Object Model
bull A Client has one or more Object Instancesbull An Object is a collection of Resourcesbull A Resource is an atomic piece of information
ndash Read Written or Executed
bull Resources can have multiple instancesbull Objects and Resources are identified by a
16-bit Integer Instances by an 8-bit Integerbull ObjectsResources are accessed with
simple URIs Object IDObject InstanceResource ID
eg 1213
4 CoRE WG IETF-86 Orlando
CoRE WG IETF-86 Orlando
CoRE Resource Directory
draft-shelby-core-resource-directory-05
Z Shelby C Bormann S Krco
Backgroundbull Not a new concept
ndash think web search engine or any link directorybull Defines the interfaces to a Resource Directorybull Based on Web Linking framework and the CoRE Link Formatbull Generic REST design for use over HTTP and CoAPbull Used by OMA Lightweight M2Mbull Has already been deployed
ndash In traffic monitoring systemsndash In street lighting systemsndash For vehicular asset trackingndash By a major Cellular M2M operator
Changes since -04
bull Restricted Update to parameter updatesbull Added pagination support for the Lookup interfacebull Changed rt= to et= for the registration amp update
interfacebull Added group support
Group Management
bull RD now includes group management featuresbull New Group Function Set
ndash Register a groupbull Group name domain multicast address endpoint members
ndash Remove a groupbull Group lookup using the Lookup Function Set
ndash List registered groupsndash Find the members of a groupndash Find groups with certain endpoints or resources
Registering a Group
EP RD
| |
| - POST rd-groupgp=lights ltgtep=node1 --gt |
| |
| |
| lt---- 201 Created Location rd-group12 ---- |
| |
Req POST coaprdexamplecomrd-groupgp=lights
Payload
ltgtep=node1
ltgtep=node2
Res 201 Created
Location rd-group12
Looking up Group Members
Client RD
| |
| ----- GET rd-lookupepgp=lights1 ----------------------gt |
| |
| |
| lt-- 205 Content ltrdgtd=domain1ltrdgtd=domain2 --------- |
| |
Req GET rd-lookupepgp=lights1
Res 205 Content
ltcoaphostportgtep=node1
ltcoaphostportgtep=node2rdquo
Things for the futurebull Support for JSON representation of Web Links
ndash httptoolsietforgiddraft-bormann-core-links-json-02txtbull Registry for RD registration query parameters
ndash Already OMA Lightweight has defined some new onesbull More examples
Group 3 ldquonew workrdquo(continued)
109
drar-shy‐greevenbosch-shy‐core-shy‐profile-shy‐descripon-shy‐01Bert13 GreevenboschJeroen13 Hoebeke
Isam13 IshaqFloris13 Van13 den13 Abeele
Descripon
bull JSON13 format13 for13 signalling13 the13 servers13 capabilies
bull Signalling13 of13 supported13 opons13 media13 types13 and13 block13 sizendash Other13 items13 can13 be13 added
bull Filtering13 on13 specific13 fields13 through13 URI-shy‐Querybull Link13 hqpdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐profile-shy‐descripon
well-shy‐knownprofile
bull To13 acquire13 profile13 data13 of13 resources13 on13 a13 parcular13 service13 the13 well-shy‐knownprofile13 URI-shy‐path13 is13 introduced
bull For13 example13 to13 get13 all13 informaon13 from13 sensors13 served13 by13 wwwexampleorg13 we13 can13 do13 a13 GET13 to13 coapwwwexampleorgwell-shy‐knownprofile
bull Filtering13 on13 parcular13 resources13 is13 done13 through13 URI-shy‐Queries
Format
bull Currently13 the13 following13 fields13 are13 definedndash ldquopathrdquo13 contains13 the13 URI-shy‐path13 associated13 with13 a13 resource
ndash ldquooprdquo13 a13 numerical13 list13 of13 supported13 opon13 numbers
ndash ldquocfrdquo13 a13 numerical13 list13 of13 supported13 content-shy‐format13 numbers
ndash ldquob1srdquo13 ldquob2srdquo13 supported13 block13 sizes13 for13 Block113 and13 Block213 respecvely
Examplebull On13 the13 right13 is13 an13 example13 of13 a13 camera13 sensor13 at13 coapwwwexampleorgcam13 that13 supports13 the13 Uri-shy‐Host13 (3)13 ETag13 (4)13 Uri-shy‐Port13 (7)13 Uri-shy‐Path13 (11)13 Content-shy‐Format13 (12)13 Token13 (19)13 Block213 (23)13 and13 Proxy-shy‐Uri13 (35)13 opons
bull The13 supported13 content13 formats13 are13 textplain13 (0)13 applicaon13 link-shy‐format13 (40)13 and13 applicaonjson13 (50)
bull The13 supported13 Block213 can13 use13 25613 or13 51213 byte13 blocks
Req13 GET13 coapwwwexampleorgwell-shy‐knownprofile13 Res13 20513 Content13 (applicationjson)13 13 13 13 profile13 13 13 13 13 13 13 13 pathcam13 13 13 13 op[3471112192335]13 13 13 13 13 cf[04050]13 13 13 13 13 b2s[45]13 13 13 13
Filtering13 through13 use13 of13 URI-shy‐Query
bull Filtering13 can13 be13 done13 through13 the13 URI-shy‐Querybull Query13 format13 N=V
ndash N13 is13 a13 profile13 fieldndash V13 is13 the13 desired13 value
bull Examplesndash To13 find13 resources13 that13 support13 content13 format13 ldquoapplicaonjsonrdquo
13 GET13 wwwexampleorgwell-shy‐knownprofilecf=50ndash To13 get13 informaon13 about13 the13 camera
13 GET13 wwwexampleorgwell-shy‐knownprofilepath=cam
Open13 issues
bull Which13 other13 profile13 data13 needs13 signallingndash Content-shy‐type13 for13 different13 methods
bull Fix13 the13 order13 in13 which13 the13 profile13 fields13 must13 appearndash Non-shy‐fixed13 order13 easier13 extensible
bull Inheritance13 of13 a13 profile13 descriponbull Extend13 usage13 to13 signal13 the13 client13 profilebull Integraon13 with13 link13 format
Thank13 youQuesons
drar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval-shy‐00
Bert13 Greevenbosch
Descripon
bull The13 ldquoMinimumRequestInterval13 opon13 can13 be13 used13 to13 indicate13 the13 minimum13 me13 between13 two13 requests13 in13 a13 transacon
bull Originally13 intended13 for13 Block13 but13 also13 usable13 for13 other13 transaconsndash Example13 browsing13 a13 server
bull The13 goal13 is13 to13 reduce13 the13 server13 load13 and13 network13 traffic
bull Link13 hqpsdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval
Usage
bull The13 client13 keeps13 the13 server13 informed13 about13 its13 request13 speed13 through13 inclusion13 of13 the13 ldquoMinimumRequestIntervalrdquo13 opon
bull In13 responses13 the13 server13 fixes13 the13 minimum13 request13 interval13 through13 the13 same13 opon
bull The13 client13 obeys13 the13 speed13 indicated13 by13 the13 server
bull The13 client13 can13 send13 slower13 but13 not13 faster
Advantages
bull The13 server13 has13 means13 to13 limit13 the13 amount13 of13 incoming13 traffic
bull The13 server13 can13 prevent13 to13 become13 overloaded13 with13 too13 many13 tasks
bull The13 server13 does13 not13 need13 arficially13 slow13 down13 the13 client13 by13 sending13 late13 ACKsndash No13 need13 to13 keep13 track13 of13 delayed13 ACKsndash The13 server13 can13 perform13 other13 tasks13 instead
bull Reduced13 network13 traffic
Thank13 youQuesons
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-links-json-02txt
123
RFC 6690 (link-format) documents are somewhat foreign to many web app developerssect would prefer to have them in JSON format
There is no standard way to represent link-format documents in applicationssect but everyone knows how to handle JSON
Define a standard JSON translation for link-format
Itrsquos
not
rock
et
scien
ce
ltsensorsgtct=40title=Sensor Index ltsensorstempgtrt=temperature-cif=sensor ltsensorslightgtrt=light-luxif=sensor lthttpwwwexamplecomsensorst123gt anchor=sensorstemprel=describedby lttgtanchor=sensorstemprel=alternate [hrefsensorsct40titleSensor Index hrefsensorstemprttemperature-cifsensor hrefsensorslightrtlight-luxifsensor hrefhttpwwwexamplecomsensorst123 anchorsensorstempreldescribedby hreftanchorsensorstemprelalternate]
124
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-ipsec-for-coap-00txt
IPsec definitions for CoAP Mostly placeholder at this time Who has implementation experience with this
125
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-cross-reverse-convention-00txt
This draft has two lines of payload(based on a WGLC comment by Cullen Jennings)
coap12344567foobara=3
httpwwwproxycomwellknowncore-translate1234_4567foobara=3
Is that a useful convention to have
126
Insert CI slides here
127
128
0
5
10
15
20
25
30
35
40
10 20 30 40 50 60 70
good
put (
pps)
pps
Goodput vs pps (Econotags)
goodput
[Khattak preliminary]
Congestion Control
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-cocoa-00txt
ldquoadvancedrdquo cc (The draft is just a first shot) Others may have better ideas
129
Insert post-WGLC discussion slides here
130
Stop Continue Start
131
An Agile Retrospective
http6lowappnet coreIETF86 2013-03-12-13
Stop
132
Endless new CoAP optionssect instead use RESTful as much as possible
Move general security lifecycle out Looking at theoretical problems
http6lowappnet coreIETF86 2013-03-12-13
Continue
Interops Running code Look at real-world examples and deployments Solve their actual problems
sect Unilateral enhancements eg higher performance congestion control
sect Transports (SMS hellip)sect Make Web linking and Directories more and more usefulsect RESTful Design Paradigms for real-world problems
133
http6lowappnet coreIETF86 2013-03-12-13
Start
Further push into the (browser) web world (HTML5 browser security)
Specific supporting worksect SenMLsect URI work (dev URN hellip)sect Security Processes (next slide)
Spin outsect (We donrsquot really get to decide where this is done)
134
http6lowappnet coreIETF86 2013-03-12-13
Security
Integrate Application Network Group Keyingsect Tunnel-free setup
Donrsquot redo what has been done alreadysect ZigBee IP is finesect But what about other scenarios
Simple REST interfaces for working with keying materials and authorizationsect Start with defining objectives
Object Security for Constrained Nodes135
Re-chartering CoREWhat do we want to do now that wersquore grown up
Zach ShelbyCoRE WG IETF-86 Orlando
What is the scope
bull So we have a protocol and Web Linking what next
bull Keep with what we know besthellip1 Enhancements around CoAP2 New transports for CoAP3 New representations for Web Links4 General application layer solutions
CoRE WG IETF-86 Orlando 2
Enhancements around CoAP
bull Advanced congestion control
CoRE WG IETF-86 Orlando 3
New Transports for CoAP
bull Infrastructure for CoAP over foondash httptoolsietforgiddraft-silverajan-core-
coap-alternative-transports-01txtbull CoAP over SMS
ndash httptoolsietforgiddraft-becker-core-coap-sms-gprs-03txt
ndash OMA Lightweightbull CoAP over TCP
ndash httptoolsietforgiddraft-li-core-coap-payload-length-option-01txt
CoRE WG IETF-86 Orlando 4
New support for Web Links
bull JSON Web Linksndash httptoolsietforgiddraft-bormann-core-links-
json-02txt
2332010 CoRE WG IETF-77 Anaheim 5
General application layer solutions
bull Resource Directoryndash httptoolsietforgiddraft-shelby-core-
resource-directory-05txtndash OMA Lightweight
2332010 CoRE WG IETF-77 Anaheim 6
031113
Non13 Goals13 (Not13 in13 scope)
bull Applicaon-shy‐level13 QoS13 requirementsbull Real-shy‐me13 constraintsbull Ordering13 reliability13 congeson13 controlbull Applicaon13 and13 network13 adaptaonbull Mobility13 and13 readdressing13 supportbull Network13 protocol13 (eg13 IPsec)13 configuraon
52
031113
Use13 Cases
bull NAT13 and13 Firewall13 traversal13 with13 TCPbull Delay13 Tolerant13 Networkingbull Non-shy‐IP13 Low13 Energy13 Protocols
53
031113
Related13 Work
bull OMA13 Lightweight13 M2M13 Protocolbull CoAP13 over13 SMSGPRSUSSD
54
031113
What13 does13 the13 work13 entail
bull The13 ability13 to13 specify13 end13 point13 idenfiers13 and13 URIs13 to13 reflect13 which13 transport13 CoAP13 can13 use
bull The13 ability13 to13 register13 to13 resource13 directories13 resource13 types13 reflecng13 types13 of13 transport13 available
bull Ability13 for13 mul-shy‐transport13 nodes13 to13 select13 transport13 to13 use13 without13 significant13 alteraon13 to13 CoAP13 packet13 structure
55
031113
Points13 to13 consider
bull Requirements13 for13 transport13 layer13 protocol13 to13 carry13 CoAP13 packets
bull Representaon13 of13 URI13 scheme13 for13 generic13 transport13 protocols
bull Opon13 extensions13 for13 CoAP13 to13 express13 available13 transports
bull Mapping13 and13 message13 sizebull Security13 consideraons
56
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
URI13 =13 scheme13 13 13 authority13 path-shy‐abempty13 [13 query13 ]
bull Within13 the13 scheme13 namebull In13 the13 URI13 pathbull As13 a13 query13 component
57
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
bull Within13 the13 scheme13 namendash coap+tel+15105550101well-shy‐knowncorendash coap+tcpexamplecom5683temperaturendash coap+blel2cap[1234567890AB]4pulse
bull Easy13 URI13 parsing13 for13 transport13 type13 and13 idenfier
bull Each13 new13 scheme13 name13 requires13 IANA13 registraon
58
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
bull In13 the13 URI13 pathndash coaphostexamplecomtransport=tcpwell-shy‐knowncorert=core-shy‐rd
bull Easy13 adopon13 of13 new13 (and13 experimental)13 CoAP13 transports13 without13 IANA13 registraon
bull Caveat13 Uri-shy‐Path13 opon13 is13 a13 Crical13 CoAP13 opon13 see13 secon13 54113 of13 I-shy‐Diep-shy‐core-shy‐coap
59
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
bull As13 a13 URI13 query13 componentndash coaphostexamplecomwell-shy‐knowncorert=core-shy‐rdq=tcp
bull Also13 easy13 to13 adopt13 new13 (and13 experimental)13 CoAP13 transports13 without13 IANA13 registraon
bull Caveat13 Uri-shy‐Query13 opon13 is13 a13 Crical13 CoAP13 opon13 see13 secon13 54113 of13 I-shy‐Diep-shy‐core-shy‐coap
60
031113
URI13 Representaons13 for13 CoAPNon13 standard13 ways
bull Transport13 in13 the13 URI13 authority13 componentndash coaphost[port][transport]13 instead13 of13 coaphost[port]
bull Transport13 as13 a13 service13 URLndash servicecoaptcphostexamplecomwell-shy‐knowncorert=core-shy‐rd
bull Above13 two13 ways13 break13 exisng13 compability13 (although13 both13 are13 based13 on13 valid13 IANA13 URI13 registraons)
61
031113
URI13 Representaons13 for13 CoAPMiscellaneous13 Consideraons
bull Ensure13 that13 transport13 is13 defined13 unambiguously13 (eg13 L2CAP13 used13 by13 both13 BLE13 and13 standard13 Bluetooth13 so13 avoid13 rdquocoap+l2caprdquo13 or13 rdquotransport=l2caprdquo13 or13 rdquoq=l2caprdquondash Can13 be13 done13 as13 WG13 consensusndash Namespace13 approach13 eg13 rdquocoap+blel2caprdquo13 or13 rdquoq=blel2caprdquo
bull Allow13 end-shy‐points13 to13 use13 CoAP13 Resource13 Directory13 to13 register13 alternave13 transports13 and13 idenfiers13 and13 provide13 periodic13 updatesndash Register13 rdquocore-shy‐transportrdquo13 resource13 type
62
031113
Transport13 Consideraons
bull Uniqueness13 of13 end-shy‐point13 idenficaonbull Communicaon13 support13 Unidireconal13 Bidireconal13 1N13 (broadcast13 mulcast13 anycast)13 messaging
bull Binary13 encoding13 Network13 byte13 orderingbull MTU13 correlaon13 with13 CoAP13 PDU13 sizebull Transport13 latency
63
031113
Security13 Consideraons
bull Drar13 does13 not13 introduce13 new13 security13 requirements13 by13 itself
bull There13 may13 be13 privacy13 issues13 if13 nodes13 use13 telephone13 numbers13 or13 MAC13 addresses13 as13 public13 end13 point13 idenfiers
64
Akbar Rahman
IETF 86 March 2013 httpwwwietforgiddraft-rahman-core-sleepy-02txt
Enhanced Sleepy Node Support for CoAP
Introduction
It is expected that in CoAP networks there will be a certain portion of devices that are sleepy and which may occasionally go into a sleep mode (ie go into a low power state to conserve power) and subsequently have reduced CoAP protocol communication ability
This I-D proposes a minimal and efficient mechanism building on the Resource Directory concept (which will be integrated into a CoAP Proxy) to enhance sleepy node support in CoAP networks
Main Question from IETF-85 (Atlanta)
What performance benefit does the proposed Sleepy Node support solution give in a network that already has standard CoAP caching enabled
Sleepy Node Performance Analysis
Experimental Network
1-5 clients
Both Sleepy and Non-
Sleepy servers
Sleepy Node Performance Analysis Network Setup
CoAPSleepyServer(s)
CoAPSleepAwareReverseProxy
CoAP
Client(s)
Request
Response
Sleep9AwareCoREResourceDirectoryCapability
PublishedSleepParameters
Sleep9AwareCoAPStoreandForwardCapability Response
Request
SleepAwareCoAP503ResponseCapability
CoAPCachingCapability
bull Server supports publishing sleep parameters to proxy bull Eg Irsquom going to be asleep for X seconds
bull Proxy supports sleep-awareness capabilities bull Proxy also supports caching capability based off of maxAge bull Protocol flow similar to approach of Figure 1 (Synchronous RD Based Sleep
Tracking) of I-D
Proxy capabilities can be selectively enableddisabled
Proxy ndash Server Interface
Client ndash Proxy Interface
CoAP Sleep-Aware Reverse Proxy Features CoRE Sleep-aware Resource Directory
Support storing published sleep parameters from CoAP servers sleepState (AWAKE ASLEEP) sleepDuration
Sleep-aware CoAP 503 Response Capability If CoAP request to a sleeping server is received proxy returns a
lsquo503 Retry-Afterrsquo response to client 503 contains a timestamp indicating when the sever will wake back up
(timestamp delivered in CoAP maxAge option) Sleep-aware CoAP Store-and-Forward Capability
If CoAP request to a sleeping server is received proxy stores request until server wakes up and then forwards it
Caching capability Cache GET responses from server if maxAge option is present
(this is not a sleep aware feature)
Goals of Performance Analysis
For networks having sleepy servers provide measurements to quantify the impact that CoAP sleep-awareness capabilities can have
See if sleep-awareness capabilities can
provide additional benefits even when CoAP caching is used
Overview of Performance Analysis Performed The analysis was broken up into a set of test scenarios Each test scenario used a different combination of the following
variables Client issued GET requests Server was configured as a sleepy or non-sleepy server Proxy caching of GET responses was enabled or disabled Proxy sleep-aware 503 response capability was enabled or disabled Proxy store-and-forward capability was enabled or disabled maxAge in GET responses ndash Two values were tested 60sec and 5sec of Clients ndash Two values were used ndash 1 client and 5 clients
For comparison purposes the following were held constant across all test scenarios Client issued a fixed number of requests (100) across all test scenarios Client used a delay between each GET request (35sec) to better exercise
proxyrsquos caching and sleep-awareness capabilities For sleepy server test scenarios the server slept 60 sec awake for 3 sec
Format of Results The following results were collected for each
test scenario
Breakdown of the and types of transactions occurring between clientproxyserver
ldquoGETrdquo ndash Test Scenario Results
GET ndash Description of Test Scenarios
TestScenarios-GET
Scenario
CoAPSleepyServerSe7ngs CoAPSleepAwareReverseProxySe7ngs CoAPClientSe7ngs
SleepDuragton(sec)
AwakeDuragton(sec)
maxAge(sec) Caching SleepAwareSAF+
503NumberofClients
NumberofGETs
DelayBetweenClient
Requests(sec)
1a 0 Always 60 Enabled Disabled 1 100 35
1b 60 3 60 Enabled Disabled 1 100 35
1c 60 3 60 Enabled Enabled 1 100 35
2a 0 Always 60 Enabled Disabled 5 100 35
2b 60 3 60 Enabled Disabled 5 100 35
2c 60 3 60 Enabled Enabled 5 100 35
3a 0 Always 5 Enabled Disabled 5 100 35
3b 60 3 5 Enabled Disabled 5 100 35
3c 60 3 5 Enabled Enabled 5 100 35
ldquoGETrdquo ndash Test Scenario 1 Results
maxAge = 60 and 1 Client
GET ndash Scenario 1 ClientProxy Interface Transaction Mix
Scenarios 1a - Non-Sleepy Server Caching Proxy maxAge = 60sec 1b- Sleepy Server Caching Proxy maxAge = 60sec 1c - Sleepy Server Sleep Aware Proxy maxAge = 60sec
Sleep Aware Proxy has better performance for sleepy servers
0
100
200
300
400
500
600
700
1a 1b 1c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
GET ndash Scenario 1 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
Scenarios 1a - Non-Sleepy Server Caching Proxy maxAge = 60sec 1b- Sleepy Server Caching Proxy maxAge = 60sec 1c - Sleepy Server Sleep Aware Proxy maxAge = 60sec
0
100
200
300
400
500
600
700
800
1a 1b 1c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
ldquoGETrdquo ndash Test Scenario 2 Results
maxAge = 60 and 5 Clients
GET ndash Scenario 2 ClientProxy Interface Transaction Mix
Sleep Aware Proxy has slightly better performance for sleepy servers
0
200
400
600
800
1000
1200
1400
2a 2b 2c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
Scenarios 2a - Non-Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2b- Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2c - Sleepy Server Sleep Aware Proxy maxAge = 60sec 5 Clients
See ldquoExperimental Artifactsrdquo Note 1
GET ndash Scenario 2 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has slightly better performance for sleepy servers
0
50
100
150
200
250
300
350
400
2a 2b 2c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
Scenarios 2a - Non-Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2b- Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2c - Sleepy Server Sleep Aware Proxy maxAge = 60sec 5 Clients
See ldquoExperimental Artifactsrdquo Note 2
Experimental Artifacts Note 1
Currently in the experiment the sleep aware proxy checks the cached state of a resource before putting a request into its Store-and-forward queue while a server is sleeping Once in the queue the proxy unconditionally forwards the queued requests to the server once it wakes up This is not the most efficient setup and can easily be improved If the proxy instead checks its cache again before forwarding each queued request it may not need to forward the request to the server For example if there are two queued GET requests in the proxyrsquos queue that address the same resource Only the first request needs to be sent to the server the second request can use the cached response from the first request
Note 2 Currently in the experiment the sleepy server sends a sleepState PUT request to the
proxy each time it goes to sleep This is not the most efficient setup and can easily be improved For example if the server assumes that the proxy can keep track of its ONOFF cycles with its internal timers (eg as per Fig 1 of I-D) then the number of messages from the sleepy server dramatically goes down
ldquoGETrdquo ndash Test Scenario 3 Results
maxAge = 5 and 5 Clients
GET ndash Scenario 3 ClientProxy Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
Scenarios 3a - Non-Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3b- Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3c - Sleepy Server Sleep Aware Proxy maxAge = 5sec 5 Clients
0
500
1000
1500
2000
2500
3000
3500
4000
4500
5000
3a 3b 3c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
GET ndash Scenario 3 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
0
1000
2000
3000
4000
5000
6000
7000
3a 3b 3c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
Scenarios 3a - Non-Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3b- Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3c - Sleepy Server Sleep Aware Proxy maxAge = 5sec 5 Clients
Conclusions
Conclusions These results show that sleep-aware CoAP
proxy features can significantly optimize communication with sleepy servers in most scenarios
These results also show that sleep-
awareness capabilities can provide additional benefits above and beyond CoAP caching in most scenarios
Backup
Current CoAP Support of Sleepy Node (12)
CoAP proxies can use a previously cached response to service a new GET request for a sleepy origin server (as in HTTP) But if no valid cache then proxy has to attempt to
retrieve and may fail if origin server is sleeping [I-Dietf-core-coap]
Clients can discover list of resources from RD (GET rd-lookuphellip) for sleepy servers But attempt to GET resource from sleepy origin server
may fail if origin server is sleeping [IDietf-core-link-format amp IDshelby-core-resource-
directory]
Current CoAP Support of Sleepy Node (22)
Lower layer support for sleepy nodes in most wireless technologies (eg WiFi ZigBee) But limited to MAC packet scheduling for sleepy nodes
and not aware of specific needs of IP applications (like CoAP)
Proposal ndash RD Based Sleep Tracking (14)
The current CoAP approach to support sleepy nodes can be significantly improved by introducing RD based mechanisms for a CoAP client to determine whether A targeted resource is located on a sleepy server A sleepy server is currently in sleep mode or not
There is any associated caching Proxy (possibly the RD itself) for a sleepy server
Proposal ndash RD Based Sleep Tracking (24)
We define the following new RD attributes to characterize the properties of a sleepy node SleepState - Indicates whether the node is currently in
sleep mode or not (ie Sleeping or Awake) SleepDuration - Indicates the maximum duration of time
that the node stays in sleep mode TimeSleeping - Indicates the length of time the node
has been sleeping (ie if Sleep State = Sleeping) NextSleep - Indicates the next time the node will go to
sleep (ie if Sleep State = Awake)
CachingProxy ndash Indicates the caching proxy of the sleepy node (ie the RD itself or another node)
Proposal ndash RD Based Sleep Tracking (34)
These attributes are all server (node) level and are new parameters added to the RD URI Template Variables
Finally we also define a new lookup-type (ss) for the RD lookup interface specified in [I-Dshelby-core-resource-directory] This new lookup-type supports looking up the
ldquoSleepStaterdquo (ss) of a specified end-point
Proposal ndash RD Based Sleep Tracking (44)
The three time based parameters (SleepDuration TimeSleeping NextSleep) can be based on either an absolute network time (for a time synchronized network) or a relative local time (measured at the local node)
Following the approach of [I-Dietf-core-link-format] and [I-Dshelby-core-resource-directory] sleep parameters for sleepy servers can be stored by the server in the RD and accessed by all interested clients
Examples of using these parameters in a synchronous or asynchronous manner are shown in the I-D
http6lowappnet coreIETF86 2013-03-12-13
We assume people have read the drafts
Meetings serve to advance difficult issues by making good use of face-to-face communications
Note Well Be aware of the IPR principles according to RFC 3979 and its updates
uumlBlue sheetsuumlScribe(s)
96
drar-shy‐iep-shy‐core-shy‐coapsubmiqed13 to13 IESG
2013-shy‐03-shy‐13
97
OMA Lightweight M2M Overview(A new standard using lots of IETF specs including DTLS
CoAP Block Observe Resource Directory SenMLhellip)
Zach ShelbyCoRE WG IETF-86 Orlando
OMA Lightweight M2Mbull Open Mobile Alliance is well known for Device Management (DM)bull OMA Lightweight M2M is a new standard from the alliance
ndash Focused on constrained Cellular and sensor network M2M devicesndash Driven by leading operators and vendors
bull Scopendash Interfaces protocol amp security between Device and Serverndash Object and Resource modelndash Bootstrap Device Access Control Connectivity and Firmware Objects
bull Draft Specifications are availablendash httpmemberopenmobileallianceorgftpPublic_documentsDM
LightweightM2MPermanent_documentsOMA-TS-LightweightM2M-V1_0_0-20130301-Dzip
bull Timelinendash Requirements and Architecture completed 3Q2012ndash Spec ready for Consistency Review 2Q2013ndash Candidate Approval expected 3Q2013
2 CoRE WG IETF-86 Orlando
Architecture
3
Scope of LWM2M
CoRE WG IETF-86 Orlando
Object Model
bull A Client has one or more Object Instancesbull An Object is a collection of Resourcesbull A Resource is an atomic piece of information
ndash Read Written or Executed
bull Resources can have multiple instancesbull Objects and Resources are identified by a
16-bit Integer Instances by an 8-bit Integerbull ObjectsResources are accessed with
simple URIs Object IDObject InstanceResource ID
eg 1213
4 CoRE WG IETF-86 Orlando
CoRE WG IETF-86 Orlando
CoRE Resource Directory
draft-shelby-core-resource-directory-05
Z Shelby C Bormann S Krco
Backgroundbull Not a new concept
ndash think web search engine or any link directorybull Defines the interfaces to a Resource Directorybull Based on Web Linking framework and the CoRE Link Formatbull Generic REST design for use over HTTP and CoAPbull Used by OMA Lightweight M2Mbull Has already been deployed
ndash In traffic monitoring systemsndash In street lighting systemsndash For vehicular asset trackingndash By a major Cellular M2M operator
Changes since -04
bull Restricted Update to parameter updatesbull Added pagination support for the Lookup interfacebull Changed rt= to et= for the registration amp update
interfacebull Added group support
Group Management
bull RD now includes group management featuresbull New Group Function Set
ndash Register a groupbull Group name domain multicast address endpoint members
ndash Remove a groupbull Group lookup using the Lookup Function Set
ndash List registered groupsndash Find the members of a groupndash Find groups with certain endpoints or resources
Registering a Group
EP RD
| |
| - POST rd-groupgp=lights ltgtep=node1 --gt |
| |
| |
| lt---- 201 Created Location rd-group12 ---- |
| |
Req POST coaprdexamplecomrd-groupgp=lights
Payload
ltgtep=node1
ltgtep=node2
Res 201 Created
Location rd-group12
Looking up Group Members
Client RD
| |
| ----- GET rd-lookupepgp=lights1 ----------------------gt |
| |
| |
| lt-- 205 Content ltrdgtd=domain1ltrdgtd=domain2 --------- |
| |
Req GET rd-lookupepgp=lights1
Res 205 Content
ltcoaphostportgtep=node1
ltcoaphostportgtep=node2rdquo
Things for the futurebull Support for JSON representation of Web Links
ndash httptoolsietforgiddraft-bormann-core-links-json-02txtbull Registry for RD registration query parameters
ndash Already OMA Lightweight has defined some new onesbull More examples
Group 3 ldquonew workrdquo(continued)
109
drar-shy‐greevenbosch-shy‐core-shy‐profile-shy‐descripon-shy‐01Bert13 GreevenboschJeroen13 Hoebeke
Isam13 IshaqFloris13 Van13 den13 Abeele
Descripon
bull JSON13 format13 for13 signalling13 the13 servers13 capabilies
bull Signalling13 of13 supported13 opons13 media13 types13 and13 block13 sizendash Other13 items13 can13 be13 added
bull Filtering13 on13 specific13 fields13 through13 URI-shy‐Querybull Link13 hqpdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐profile-shy‐descripon
well-shy‐knownprofile
bull To13 acquire13 profile13 data13 of13 resources13 on13 a13 parcular13 service13 the13 well-shy‐knownprofile13 URI-shy‐path13 is13 introduced
bull For13 example13 to13 get13 all13 informaon13 from13 sensors13 served13 by13 wwwexampleorg13 we13 can13 do13 a13 GET13 to13 coapwwwexampleorgwell-shy‐knownprofile
bull Filtering13 on13 parcular13 resources13 is13 done13 through13 URI-shy‐Queries
Format
bull Currently13 the13 following13 fields13 are13 definedndash ldquopathrdquo13 contains13 the13 URI-shy‐path13 associated13 with13 a13 resource
ndash ldquooprdquo13 a13 numerical13 list13 of13 supported13 opon13 numbers
ndash ldquocfrdquo13 a13 numerical13 list13 of13 supported13 content-shy‐format13 numbers
ndash ldquob1srdquo13 ldquob2srdquo13 supported13 block13 sizes13 for13 Block113 and13 Block213 respecvely
Examplebull On13 the13 right13 is13 an13 example13 of13 a13 camera13 sensor13 at13 coapwwwexampleorgcam13 that13 supports13 the13 Uri-shy‐Host13 (3)13 ETag13 (4)13 Uri-shy‐Port13 (7)13 Uri-shy‐Path13 (11)13 Content-shy‐Format13 (12)13 Token13 (19)13 Block213 (23)13 and13 Proxy-shy‐Uri13 (35)13 opons
bull The13 supported13 content13 formats13 are13 textplain13 (0)13 applicaon13 link-shy‐format13 (40)13 and13 applicaonjson13 (50)
bull The13 supported13 Block213 can13 use13 25613 or13 51213 byte13 blocks
Req13 GET13 coapwwwexampleorgwell-shy‐knownprofile13 Res13 20513 Content13 (applicationjson)13 13 13 13 profile13 13 13 13 13 13 13 13 pathcam13 13 13 13 op[3471112192335]13 13 13 13 13 cf[04050]13 13 13 13 13 b2s[45]13 13 13 13
Filtering13 through13 use13 of13 URI-shy‐Query
bull Filtering13 can13 be13 done13 through13 the13 URI-shy‐Querybull Query13 format13 N=V
ndash N13 is13 a13 profile13 fieldndash V13 is13 the13 desired13 value
bull Examplesndash To13 find13 resources13 that13 support13 content13 format13 ldquoapplicaonjsonrdquo
13 GET13 wwwexampleorgwell-shy‐knownprofilecf=50ndash To13 get13 informaon13 about13 the13 camera
13 GET13 wwwexampleorgwell-shy‐knownprofilepath=cam
Open13 issues
bull Which13 other13 profile13 data13 needs13 signallingndash Content-shy‐type13 for13 different13 methods
bull Fix13 the13 order13 in13 which13 the13 profile13 fields13 must13 appearndash Non-shy‐fixed13 order13 easier13 extensible
bull Inheritance13 of13 a13 profile13 descriponbull Extend13 usage13 to13 signal13 the13 client13 profilebull Integraon13 with13 link13 format
Thank13 youQuesons
drar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval-shy‐00
Bert13 Greevenbosch
Descripon
bull The13 ldquoMinimumRequestInterval13 opon13 can13 be13 used13 to13 indicate13 the13 minimum13 me13 between13 two13 requests13 in13 a13 transacon
bull Originally13 intended13 for13 Block13 but13 also13 usable13 for13 other13 transaconsndash Example13 browsing13 a13 server
bull The13 goal13 is13 to13 reduce13 the13 server13 load13 and13 network13 traffic
bull Link13 hqpsdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval
Usage
bull The13 client13 keeps13 the13 server13 informed13 about13 its13 request13 speed13 through13 inclusion13 of13 the13 ldquoMinimumRequestIntervalrdquo13 opon
bull In13 responses13 the13 server13 fixes13 the13 minimum13 request13 interval13 through13 the13 same13 opon
bull The13 client13 obeys13 the13 speed13 indicated13 by13 the13 server
bull The13 client13 can13 send13 slower13 but13 not13 faster
Advantages
bull The13 server13 has13 means13 to13 limit13 the13 amount13 of13 incoming13 traffic
bull The13 server13 can13 prevent13 to13 become13 overloaded13 with13 too13 many13 tasks
bull The13 server13 does13 not13 need13 arficially13 slow13 down13 the13 client13 by13 sending13 late13 ACKsndash No13 need13 to13 keep13 track13 of13 delayed13 ACKsndash The13 server13 can13 perform13 other13 tasks13 instead
bull Reduced13 network13 traffic
Thank13 youQuesons
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-links-json-02txt
123
RFC 6690 (link-format) documents are somewhat foreign to many web app developerssect would prefer to have them in JSON format
There is no standard way to represent link-format documents in applicationssect but everyone knows how to handle JSON
Define a standard JSON translation for link-format
Itrsquos
not
rock
et
scien
ce
ltsensorsgtct=40title=Sensor Index ltsensorstempgtrt=temperature-cif=sensor ltsensorslightgtrt=light-luxif=sensor lthttpwwwexamplecomsensorst123gt anchor=sensorstemprel=describedby lttgtanchor=sensorstemprel=alternate [hrefsensorsct40titleSensor Index hrefsensorstemprttemperature-cifsensor hrefsensorslightrtlight-luxifsensor hrefhttpwwwexamplecomsensorst123 anchorsensorstempreldescribedby hreftanchorsensorstemprelalternate]
124
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-ipsec-for-coap-00txt
IPsec definitions for CoAP Mostly placeholder at this time Who has implementation experience with this
125
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-cross-reverse-convention-00txt
This draft has two lines of payload(based on a WGLC comment by Cullen Jennings)
coap12344567foobara=3
httpwwwproxycomwellknowncore-translate1234_4567foobara=3
Is that a useful convention to have
126
Insert CI slides here
127
128
0
5
10
15
20
25
30
35
40
10 20 30 40 50 60 70
good
put (
pps)
pps
Goodput vs pps (Econotags)
goodput
[Khattak preliminary]
Congestion Control
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-cocoa-00txt
ldquoadvancedrdquo cc (The draft is just a first shot) Others may have better ideas
129
Insert post-WGLC discussion slides here
130
Stop Continue Start
131
An Agile Retrospective
http6lowappnet coreIETF86 2013-03-12-13
Stop
132
Endless new CoAP optionssect instead use RESTful as much as possible
Move general security lifecycle out Looking at theoretical problems
http6lowappnet coreIETF86 2013-03-12-13
Continue
Interops Running code Look at real-world examples and deployments Solve their actual problems
sect Unilateral enhancements eg higher performance congestion control
sect Transports (SMS hellip)sect Make Web linking and Directories more and more usefulsect RESTful Design Paradigms for real-world problems
133
http6lowappnet coreIETF86 2013-03-12-13
Start
Further push into the (browser) web world (HTML5 browser security)
Specific supporting worksect SenMLsect URI work (dev URN hellip)sect Security Processes (next slide)
Spin outsect (We donrsquot really get to decide where this is done)
134
http6lowappnet coreIETF86 2013-03-12-13
Security
Integrate Application Network Group Keyingsect Tunnel-free setup
Donrsquot redo what has been done alreadysect ZigBee IP is finesect But what about other scenarios
Simple REST interfaces for working with keying materials and authorizationsect Start with defining objectives
Object Security for Constrained Nodes135
Re-chartering CoREWhat do we want to do now that wersquore grown up
Zach ShelbyCoRE WG IETF-86 Orlando
What is the scope
bull So we have a protocol and Web Linking what next
bull Keep with what we know besthellip1 Enhancements around CoAP2 New transports for CoAP3 New representations for Web Links4 General application layer solutions
CoRE WG IETF-86 Orlando 2
Enhancements around CoAP
bull Advanced congestion control
CoRE WG IETF-86 Orlando 3
New Transports for CoAP
bull Infrastructure for CoAP over foondash httptoolsietforgiddraft-silverajan-core-
coap-alternative-transports-01txtbull CoAP over SMS
ndash httptoolsietforgiddraft-becker-core-coap-sms-gprs-03txt
ndash OMA Lightweightbull CoAP over TCP
ndash httptoolsietforgiddraft-li-core-coap-payload-length-option-01txt
CoRE WG IETF-86 Orlando 4
New support for Web Links
bull JSON Web Linksndash httptoolsietforgiddraft-bormann-core-links-
json-02txt
2332010 CoRE WG IETF-77 Anaheim 5
General application layer solutions
bull Resource Directoryndash httptoolsietforgiddraft-shelby-core-
resource-directory-05txtndash OMA Lightweight
2332010 CoRE WG IETF-77 Anaheim 6
031113
Use13 Cases
bull NAT13 and13 Firewall13 traversal13 with13 TCPbull Delay13 Tolerant13 Networkingbull Non-shy‐IP13 Low13 Energy13 Protocols
53
031113
Related13 Work
bull OMA13 Lightweight13 M2M13 Protocolbull CoAP13 over13 SMSGPRSUSSD
54
031113
What13 does13 the13 work13 entail
bull The13 ability13 to13 specify13 end13 point13 idenfiers13 and13 URIs13 to13 reflect13 which13 transport13 CoAP13 can13 use
bull The13 ability13 to13 register13 to13 resource13 directories13 resource13 types13 reflecng13 types13 of13 transport13 available
bull Ability13 for13 mul-shy‐transport13 nodes13 to13 select13 transport13 to13 use13 without13 significant13 alteraon13 to13 CoAP13 packet13 structure
55
031113
Points13 to13 consider
bull Requirements13 for13 transport13 layer13 protocol13 to13 carry13 CoAP13 packets
bull Representaon13 of13 URI13 scheme13 for13 generic13 transport13 protocols
bull Opon13 extensions13 for13 CoAP13 to13 express13 available13 transports
bull Mapping13 and13 message13 sizebull Security13 consideraons
56
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
URI13 =13 scheme13 13 13 authority13 path-shy‐abempty13 [13 query13 ]
bull Within13 the13 scheme13 namebull In13 the13 URI13 pathbull As13 a13 query13 component
57
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
bull Within13 the13 scheme13 namendash coap+tel+15105550101well-shy‐knowncorendash coap+tcpexamplecom5683temperaturendash coap+blel2cap[1234567890AB]4pulse
bull Easy13 URI13 parsing13 for13 transport13 type13 and13 idenfier
bull Each13 new13 scheme13 name13 requires13 IANA13 registraon
58
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
bull In13 the13 URI13 pathndash coaphostexamplecomtransport=tcpwell-shy‐knowncorert=core-shy‐rd
bull Easy13 adopon13 of13 new13 (and13 experimental)13 CoAP13 transports13 without13 IANA13 registraon
bull Caveat13 Uri-shy‐Path13 opon13 is13 a13 Crical13 CoAP13 opon13 see13 secon13 54113 of13 I-shy‐Diep-shy‐core-shy‐coap
59
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
bull As13 a13 URI13 query13 componentndash coaphostexamplecomwell-shy‐knowncorert=core-shy‐rdq=tcp
bull Also13 easy13 to13 adopt13 new13 (and13 experimental)13 CoAP13 transports13 without13 IANA13 registraon
bull Caveat13 Uri-shy‐Query13 opon13 is13 a13 Crical13 CoAP13 opon13 see13 secon13 54113 of13 I-shy‐Diep-shy‐core-shy‐coap
60
031113
URI13 Representaons13 for13 CoAPNon13 standard13 ways
bull Transport13 in13 the13 URI13 authority13 componentndash coaphost[port][transport]13 instead13 of13 coaphost[port]
bull Transport13 as13 a13 service13 URLndash servicecoaptcphostexamplecomwell-shy‐knowncorert=core-shy‐rd
bull Above13 two13 ways13 break13 exisng13 compability13 (although13 both13 are13 based13 on13 valid13 IANA13 URI13 registraons)
61
031113
URI13 Representaons13 for13 CoAPMiscellaneous13 Consideraons
bull Ensure13 that13 transport13 is13 defined13 unambiguously13 (eg13 L2CAP13 used13 by13 both13 BLE13 and13 standard13 Bluetooth13 so13 avoid13 rdquocoap+l2caprdquo13 or13 rdquotransport=l2caprdquo13 or13 rdquoq=l2caprdquondash Can13 be13 done13 as13 WG13 consensusndash Namespace13 approach13 eg13 rdquocoap+blel2caprdquo13 or13 rdquoq=blel2caprdquo
bull Allow13 end-shy‐points13 to13 use13 CoAP13 Resource13 Directory13 to13 register13 alternave13 transports13 and13 idenfiers13 and13 provide13 periodic13 updatesndash Register13 rdquocore-shy‐transportrdquo13 resource13 type
62
031113
Transport13 Consideraons
bull Uniqueness13 of13 end-shy‐point13 idenficaonbull Communicaon13 support13 Unidireconal13 Bidireconal13 1N13 (broadcast13 mulcast13 anycast)13 messaging
bull Binary13 encoding13 Network13 byte13 orderingbull MTU13 correlaon13 with13 CoAP13 PDU13 sizebull Transport13 latency
63
031113
Security13 Consideraons
bull Drar13 does13 not13 introduce13 new13 security13 requirements13 by13 itself
bull There13 may13 be13 privacy13 issues13 if13 nodes13 use13 telephone13 numbers13 or13 MAC13 addresses13 as13 public13 end13 point13 idenfiers
64
Akbar Rahman
IETF 86 March 2013 httpwwwietforgiddraft-rahman-core-sleepy-02txt
Enhanced Sleepy Node Support for CoAP
Introduction
It is expected that in CoAP networks there will be a certain portion of devices that are sleepy and which may occasionally go into a sleep mode (ie go into a low power state to conserve power) and subsequently have reduced CoAP protocol communication ability
This I-D proposes a minimal and efficient mechanism building on the Resource Directory concept (which will be integrated into a CoAP Proxy) to enhance sleepy node support in CoAP networks
Main Question from IETF-85 (Atlanta)
What performance benefit does the proposed Sleepy Node support solution give in a network that already has standard CoAP caching enabled
Sleepy Node Performance Analysis
Experimental Network
1-5 clients
Both Sleepy and Non-
Sleepy servers
Sleepy Node Performance Analysis Network Setup
CoAPSleepyServer(s)
CoAPSleepAwareReverseProxy
CoAP
Client(s)
Request
Response
Sleep9AwareCoREResourceDirectoryCapability
PublishedSleepParameters
Sleep9AwareCoAPStoreandForwardCapability Response
Request
SleepAwareCoAP503ResponseCapability
CoAPCachingCapability
bull Server supports publishing sleep parameters to proxy bull Eg Irsquom going to be asleep for X seconds
bull Proxy supports sleep-awareness capabilities bull Proxy also supports caching capability based off of maxAge bull Protocol flow similar to approach of Figure 1 (Synchronous RD Based Sleep
Tracking) of I-D
Proxy capabilities can be selectively enableddisabled
Proxy ndash Server Interface
Client ndash Proxy Interface
CoAP Sleep-Aware Reverse Proxy Features CoRE Sleep-aware Resource Directory
Support storing published sleep parameters from CoAP servers sleepState (AWAKE ASLEEP) sleepDuration
Sleep-aware CoAP 503 Response Capability If CoAP request to a sleeping server is received proxy returns a
lsquo503 Retry-Afterrsquo response to client 503 contains a timestamp indicating when the sever will wake back up
(timestamp delivered in CoAP maxAge option) Sleep-aware CoAP Store-and-Forward Capability
If CoAP request to a sleeping server is received proxy stores request until server wakes up and then forwards it
Caching capability Cache GET responses from server if maxAge option is present
(this is not a sleep aware feature)
Goals of Performance Analysis
For networks having sleepy servers provide measurements to quantify the impact that CoAP sleep-awareness capabilities can have
See if sleep-awareness capabilities can
provide additional benefits even when CoAP caching is used
Overview of Performance Analysis Performed The analysis was broken up into a set of test scenarios Each test scenario used a different combination of the following
variables Client issued GET requests Server was configured as a sleepy or non-sleepy server Proxy caching of GET responses was enabled or disabled Proxy sleep-aware 503 response capability was enabled or disabled Proxy store-and-forward capability was enabled or disabled maxAge in GET responses ndash Two values were tested 60sec and 5sec of Clients ndash Two values were used ndash 1 client and 5 clients
For comparison purposes the following were held constant across all test scenarios Client issued a fixed number of requests (100) across all test scenarios Client used a delay between each GET request (35sec) to better exercise
proxyrsquos caching and sleep-awareness capabilities For sleepy server test scenarios the server slept 60 sec awake for 3 sec
Format of Results The following results were collected for each
test scenario
Breakdown of the and types of transactions occurring between clientproxyserver
ldquoGETrdquo ndash Test Scenario Results
GET ndash Description of Test Scenarios
TestScenarios-GET
Scenario
CoAPSleepyServerSe7ngs CoAPSleepAwareReverseProxySe7ngs CoAPClientSe7ngs
SleepDuragton(sec)
AwakeDuragton(sec)
maxAge(sec) Caching SleepAwareSAF+
503NumberofClients
NumberofGETs
DelayBetweenClient
Requests(sec)
1a 0 Always 60 Enabled Disabled 1 100 35
1b 60 3 60 Enabled Disabled 1 100 35
1c 60 3 60 Enabled Enabled 1 100 35
2a 0 Always 60 Enabled Disabled 5 100 35
2b 60 3 60 Enabled Disabled 5 100 35
2c 60 3 60 Enabled Enabled 5 100 35
3a 0 Always 5 Enabled Disabled 5 100 35
3b 60 3 5 Enabled Disabled 5 100 35
3c 60 3 5 Enabled Enabled 5 100 35
ldquoGETrdquo ndash Test Scenario 1 Results
maxAge = 60 and 1 Client
GET ndash Scenario 1 ClientProxy Interface Transaction Mix
Scenarios 1a - Non-Sleepy Server Caching Proxy maxAge = 60sec 1b- Sleepy Server Caching Proxy maxAge = 60sec 1c - Sleepy Server Sleep Aware Proxy maxAge = 60sec
Sleep Aware Proxy has better performance for sleepy servers
0
100
200
300
400
500
600
700
1a 1b 1c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
GET ndash Scenario 1 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
Scenarios 1a - Non-Sleepy Server Caching Proxy maxAge = 60sec 1b- Sleepy Server Caching Proxy maxAge = 60sec 1c - Sleepy Server Sleep Aware Proxy maxAge = 60sec
0
100
200
300
400
500
600
700
800
1a 1b 1c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
ldquoGETrdquo ndash Test Scenario 2 Results
maxAge = 60 and 5 Clients
GET ndash Scenario 2 ClientProxy Interface Transaction Mix
Sleep Aware Proxy has slightly better performance for sleepy servers
0
200
400
600
800
1000
1200
1400
2a 2b 2c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
Scenarios 2a - Non-Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2b- Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2c - Sleepy Server Sleep Aware Proxy maxAge = 60sec 5 Clients
See ldquoExperimental Artifactsrdquo Note 1
GET ndash Scenario 2 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has slightly better performance for sleepy servers
0
50
100
150
200
250
300
350
400
2a 2b 2c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
Scenarios 2a - Non-Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2b- Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2c - Sleepy Server Sleep Aware Proxy maxAge = 60sec 5 Clients
See ldquoExperimental Artifactsrdquo Note 2
Experimental Artifacts Note 1
Currently in the experiment the sleep aware proxy checks the cached state of a resource before putting a request into its Store-and-forward queue while a server is sleeping Once in the queue the proxy unconditionally forwards the queued requests to the server once it wakes up This is not the most efficient setup and can easily be improved If the proxy instead checks its cache again before forwarding each queued request it may not need to forward the request to the server For example if there are two queued GET requests in the proxyrsquos queue that address the same resource Only the first request needs to be sent to the server the second request can use the cached response from the first request
Note 2 Currently in the experiment the sleepy server sends a sleepState PUT request to the
proxy each time it goes to sleep This is not the most efficient setup and can easily be improved For example if the server assumes that the proxy can keep track of its ONOFF cycles with its internal timers (eg as per Fig 1 of I-D) then the number of messages from the sleepy server dramatically goes down
ldquoGETrdquo ndash Test Scenario 3 Results
maxAge = 5 and 5 Clients
GET ndash Scenario 3 ClientProxy Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
Scenarios 3a - Non-Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3b- Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3c - Sleepy Server Sleep Aware Proxy maxAge = 5sec 5 Clients
0
500
1000
1500
2000
2500
3000
3500
4000
4500
5000
3a 3b 3c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
GET ndash Scenario 3 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
0
1000
2000
3000
4000
5000
6000
7000
3a 3b 3c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
Scenarios 3a - Non-Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3b- Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3c - Sleepy Server Sleep Aware Proxy maxAge = 5sec 5 Clients
Conclusions
Conclusions These results show that sleep-aware CoAP
proxy features can significantly optimize communication with sleepy servers in most scenarios
These results also show that sleep-
awareness capabilities can provide additional benefits above and beyond CoAP caching in most scenarios
Backup
Current CoAP Support of Sleepy Node (12)
CoAP proxies can use a previously cached response to service a new GET request for a sleepy origin server (as in HTTP) But if no valid cache then proxy has to attempt to
retrieve and may fail if origin server is sleeping [I-Dietf-core-coap]
Clients can discover list of resources from RD (GET rd-lookuphellip) for sleepy servers But attempt to GET resource from sleepy origin server
may fail if origin server is sleeping [IDietf-core-link-format amp IDshelby-core-resource-
directory]
Current CoAP Support of Sleepy Node (22)
Lower layer support for sleepy nodes in most wireless technologies (eg WiFi ZigBee) But limited to MAC packet scheduling for sleepy nodes
and not aware of specific needs of IP applications (like CoAP)
Proposal ndash RD Based Sleep Tracking (14)
The current CoAP approach to support sleepy nodes can be significantly improved by introducing RD based mechanisms for a CoAP client to determine whether A targeted resource is located on a sleepy server A sleepy server is currently in sleep mode or not
There is any associated caching Proxy (possibly the RD itself) for a sleepy server
Proposal ndash RD Based Sleep Tracking (24)
We define the following new RD attributes to characterize the properties of a sleepy node SleepState - Indicates whether the node is currently in
sleep mode or not (ie Sleeping or Awake) SleepDuration - Indicates the maximum duration of time
that the node stays in sleep mode TimeSleeping - Indicates the length of time the node
has been sleeping (ie if Sleep State = Sleeping) NextSleep - Indicates the next time the node will go to
sleep (ie if Sleep State = Awake)
CachingProxy ndash Indicates the caching proxy of the sleepy node (ie the RD itself or another node)
Proposal ndash RD Based Sleep Tracking (34)
These attributes are all server (node) level and are new parameters added to the RD URI Template Variables
Finally we also define a new lookup-type (ss) for the RD lookup interface specified in [I-Dshelby-core-resource-directory] This new lookup-type supports looking up the
ldquoSleepStaterdquo (ss) of a specified end-point
Proposal ndash RD Based Sleep Tracking (44)
The three time based parameters (SleepDuration TimeSleeping NextSleep) can be based on either an absolute network time (for a time synchronized network) or a relative local time (measured at the local node)
Following the approach of [I-Dietf-core-link-format] and [I-Dshelby-core-resource-directory] sleep parameters for sleepy servers can be stored by the server in the RD and accessed by all interested clients
Examples of using these parameters in a synchronous or asynchronous manner are shown in the I-D
http6lowappnet coreIETF86 2013-03-12-13
We assume people have read the drafts
Meetings serve to advance difficult issues by making good use of face-to-face communications
Note Well Be aware of the IPR principles according to RFC 3979 and its updates
uumlBlue sheetsuumlScribe(s)
96
drar-shy‐iep-shy‐core-shy‐coapsubmiqed13 to13 IESG
2013-shy‐03-shy‐13
97
OMA Lightweight M2M Overview(A new standard using lots of IETF specs including DTLS
CoAP Block Observe Resource Directory SenMLhellip)
Zach ShelbyCoRE WG IETF-86 Orlando
OMA Lightweight M2Mbull Open Mobile Alliance is well known for Device Management (DM)bull OMA Lightweight M2M is a new standard from the alliance
ndash Focused on constrained Cellular and sensor network M2M devicesndash Driven by leading operators and vendors
bull Scopendash Interfaces protocol amp security between Device and Serverndash Object and Resource modelndash Bootstrap Device Access Control Connectivity and Firmware Objects
bull Draft Specifications are availablendash httpmemberopenmobileallianceorgftpPublic_documentsDM
LightweightM2MPermanent_documentsOMA-TS-LightweightM2M-V1_0_0-20130301-Dzip
bull Timelinendash Requirements and Architecture completed 3Q2012ndash Spec ready for Consistency Review 2Q2013ndash Candidate Approval expected 3Q2013
2 CoRE WG IETF-86 Orlando
Architecture
3
Scope of LWM2M
CoRE WG IETF-86 Orlando
Object Model
bull A Client has one or more Object Instancesbull An Object is a collection of Resourcesbull A Resource is an atomic piece of information
ndash Read Written or Executed
bull Resources can have multiple instancesbull Objects and Resources are identified by a
16-bit Integer Instances by an 8-bit Integerbull ObjectsResources are accessed with
simple URIs Object IDObject InstanceResource ID
eg 1213
4 CoRE WG IETF-86 Orlando
CoRE WG IETF-86 Orlando
CoRE Resource Directory
draft-shelby-core-resource-directory-05
Z Shelby C Bormann S Krco
Backgroundbull Not a new concept
ndash think web search engine or any link directorybull Defines the interfaces to a Resource Directorybull Based on Web Linking framework and the CoRE Link Formatbull Generic REST design for use over HTTP and CoAPbull Used by OMA Lightweight M2Mbull Has already been deployed
ndash In traffic monitoring systemsndash In street lighting systemsndash For vehicular asset trackingndash By a major Cellular M2M operator
Changes since -04
bull Restricted Update to parameter updatesbull Added pagination support for the Lookup interfacebull Changed rt= to et= for the registration amp update
interfacebull Added group support
Group Management
bull RD now includes group management featuresbull New Group Function Set
ndash Register a groupbull Group name domain multicast address endpoint members
ndash Remove a groupbull Group lookup using the Lookup Function Set
ndash List registered groupsndash Find the members of a groupndash Find groups with certain endpoints or resources
Registering a Group
EP RD
| |
| - POST rd-groupgp=lights ltgtep=node1 --gt |
| |
| |
| lt---- 201 Created Location rd-group12 ---- |
| |
Req POST coaprdexamplecomrd-groupgp=lights
Payload
ltgtep=node1
ltgtep=node2
Res 201 Created
Location rd-group12
Looking up Group Members
Client RD
| |
| ----- GET rd-lookupepgp=lights1 ----------------------gt |
| |
| |
| lt-- 205 Content ltrdgtd=domain1ltrdgtd=domain2 --------- |
| |
Req GET rd-lookupepgp=lights1
Res 205 Content
ltcoaphostportgtep=node1
ltcoaphostportgtep=node2rdquo
Things for the futurebull Support for JSON representation of Web Links
ndash httptoolsietforgiddraft-bormann-core-links-json-02txtbull Registry for RD registration query parameters
ndash Already OMA Lightweight has defined some new onesbull More examples
Group 3 ldquonew workrdquo(continued)
109
drar-shy‐greevenbosch-shy‐core-shy‐profile-shy‐descripon-shy‐01Bert13 GreevenboschJeroen13 Hoebeke
Isam13 IshaqFloris13 Van13 den13 Abeele
Descripon
bull JSON13 format13 for13 signalling13 the13 servers13 capabilies
bull Signalling13 of13 supported13 opons13 media13 types13 and13 block13 sizendash Other13 items13 can13 be13 added
bull Filtering13 on13 specific13 fields13 through13 URI-shy‐Querybull Link13 hqpdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐profile-shy‐descripon
well-shy‐knownprofile
bull To13 acquire13 profile13 data13 of13 resources13 on13 a13 parcular13 service13 the13 well-shy‐knownprofile13 URI-shy‐path13 is13 introduced
bull For13 example13 to13 get13 all13 informaon13 from13 sensors13 served13 by13 wwwexampleorg13 we13 can13 do13 a13 GET13 to13 coapwwwexampleorgwell-shy‐knownprofile
bull Filtering13 on13 parcular13 resources13 is13 done13 through13 URI-shy‐Queries
Format
bull Currently13 the13 following13 fields13 are13 definedndash ldquopathrdquo13 contains13 the13 URI-shy‐path13 associated13 with13 a13 resource
ndash ldquooprdquo13 a13 numerical13 list13 of13 supported13 opon13 numbers
ndash ldquocfrdquo13 a13 numerical13 list13 of13 supported13 content-shy‐format13 numbers
ndash ldquob1srdquo13 ldquob2srdquo13 supported13 block13 sizes13 for13 Block113 and13 Block213 respecvely
Examplebull On13 the13 right13 is13 an13 example13 of13 a13 camera13 sensor13 at13 coapwwwexampleorgcam13 that13 supports13 the13 Uri-shy‐Host13 (3)13 ETag13 (4)13 Uri-shy‐Port13 (7)13 Uri-shy‐Path13 (11)13 Content-shy‐Format13 (12)13 Token13 (19)13 Block213 (23)13 and13 Proxy-shy‐Uri13 (35)13 opons
bull The13 supported13 content13 formats13 are13 textplain13 (0)13 applicaon13 link-shy‐format13 (40)13 and13 applicaonjson13 (50)
bull The13 supported13 Block213 can13 use13 25613 or13 51213 byte13 blocks
Req13 GET13 coapwwwexampleorgwell-shy‐knownprofile13 Res13 20513 Content13 (applicationjson)13 13 13 13 profile13 13 13 13 13 13 13 13 pathcam13 13 13 13 op[3471112192335]13 13 13 13 13 cf[04050]13 13 13 13 13 b2s[45]13 13 13 13
Filtering13 through13 use13 of13 URI-shy‐Query
bull Filtering13 can13 be13 done13 through13 the13 URI-shy‐Querybull Query13 format13 N=V
ndash N13 is13 a13 profile13 fieldndash V13 is13 the13 desired13 value
bull Examplesndash To13 find13 resources13 that13 support13 content13 format13 ldquoapplicaonjsonrdquo
13 GET13 wwwexampleorgwell-shy‐knownprofilecf=50ndash To13 get13 informaon13 about13 the13 camera
13 GET13 wwwexampleorgwell-shy‐knownprofilepath=cam
Open13 issues
bull Which13 other13 profile13 data13 needs13 signallingndash Content-shy‐type13 for13 different13 methods
bull Fix13 the13 order13 in13 which13 the13 profile13 fields13 must13 appearndash Non-shy‐fixed13 order13 easier13 extensible
bull Inheritance13 of13 a13 profile13 descriponbull Extend13 usage13 to13 signal13 the13 client13 profilebull Integraon13 with13 link13 format
Thank13 youQuesons
drar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval-shy‐00
Bert13 Greevenbosch
Descripon
bull The13 ldquoMinimumRequestInterval13 opon13 can13 be13 used13 to13 indicate13 the13 minimum13 me13 between13 two13 requests13 in13 a13 transacon
bull Originally13 intended13 for13 Block13 but13 also13 usable13 for13 other13 transaconsndash Example13 browsing13 a13 server
bull The13 goal13 is13 to13 reduce13 the13 server13 load13 and13 network13 traffic
bull Link13 hqpsdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval
Usage
bull The13 client13 keeps13 the13 server13 informed13 about13 its13 request13 speed13 through13 inclusion13 of13 the13 ldquoMinimumRequestIntervalrdquo13 opon
bull In13 responses13 the13 server13 fixes13 the13 minimum13 request13 interval13 through13 the13 same13 opon
bull The13 client13 obeys13 the13 speed13 indicated13 by13 the13 server
bull The13 client13 can13 send13 slower13 but13 not13 faster
Advantages
bull The13 server13 has13 means13 to13 limit13 the13 amount13 of13 incoming13 traffic
bull The13 server13 can13 prevent13 to13 become13 overloaded13 with13 too13 many13 tasks
bull The13 server13 does13 not13 need13 arficially13 slow13 down13 the13 client13 by13 sending13 late13 ACKsndash No13 need13 to13 keep13 track13 of13 delayed13 ACKsndash The13 server13 can13 perform13 other13 tasks13 instead
bull Reduced13 network13 traffic
Thank13 youQuesons
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-links-json-02txt
123
RFC 6690 (link-format) documents are somewhat foreign to many web app developerssect would prefer to have them in JSON format
There is no standard way to represent link-format documents in applicationssect but everyone knows how to handle JSON
Define a standard JSON translation for link-format
Itrsquos
not
rock
et
scien
ce
ltsensorsgtct=40title=Sensor Index ltsensorstempgtrt=temperature-cif=sensor ltsensorslightgtrt=light-luxif=sensor lthttpwwwexamplecomsensorst123gt anchor=sensorstemprel=describedby lttgtanchor=sensorstemprel=alternate [hrefsensorsct40titleSensor Index hrefsensorstemprttemperature-cifsensor hrefsensorslightrtlight-luxifsensor hrefhttpwwwexamplecomsensorst123 anchorsensorstempreldescribedby hreftanchorsensorstemprelalternate]
124
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-ipsec-for-coap-00txt
IPsec definitions for CoAP Mostly placeholder at this time Who has implementation experience with this
125
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-cross-reverse-convention-00txt
This draft has two lines of payload(based on a WGLC comment by Cullen Jennings)
coap12344567foobara=3
httpwwwproxycomwellknowncore-translate1234_4567foobara=3
Is that a useful convention to have
126
Insert CI slides here
127
128
0
5
10
15
20
25
30
35
40
10 20 30 40 50 60 70
good
put (
pps)
pps
Goodput vs pps (Econotags)
goodput
[Khattak preliminary]
Congestion Control
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-cocoa-00txt
ldquoadvancedrdquo cc (The draft is just a first shot) Others may have better ideas
129
Insert post-WGLC discussion slides here
130
Stop Continue Start
131
An Agile Retrospective
http6lowappnet coreIETF86 2013-03-12-13
Stop
132
Endless new CoAP optionssect instead use RESTful as much as possible
Move general security lifecycle out Looking at theoretical problems
http6lowappnet coreIETF86 2013-03-12-13
Continue
Interops Running code Look at real-world examples and deployments Solve their actual problems
sect Unilateral enhancements eg higher performance congestion control
sect Transports (SMS hellip)sect Make Web linking and Directories more and more usefulsect RESTful Design Paradigms for real-world problems
133
http6lowappnet coreIETF86 2013-03-12-13
Start
Further push into the (browser) web world (HTML5 browser security)
Specific supporting worksect SenMLsect URI work (dev URN hellip)sect Security Processes (next slide)
Spin outsect (We donrsquot really get to decide where this is done)
134
http6lowappnet coreIETF86 2013-03-12-13
Security
Integrate Application Network Group Keyingsect Tunnel-free setup
Donrsquot redo what has been done alreadysect ZigBee IP is finesect But what about other scenarios
Simple REST interfaces for working with keying materials and authorizationsect Start with defining objectives
Object Security for Constrained Nodes135
Re-chartering CoREWhat do we want to do now that wersquore grown up
Zach ShelbyCoRE WG IETF-86 Orlando
What is the scope
bull So we have a protocol and Web Linking what next
bull Keep with what we know besthellip1 Enhancements around CoAP2 New transports for CoAP3 New representations for Web Links4 General application layer solutions
CoRE WG IETF-86 Orlando 2
Enhancements around CoAP
bull Advanced congestion control
CoRE WG IETF-86 Orlando 3
New Transports for CoAP
bull Infrastructure for CoAP over foondash httptoolsietforgiddraft-silverajan-core-
coap-alternative-transports-01txtbull CoAP over SMS
ndash httptoolsietforgiddraft-becker-core-coap-sms-gprs-03txt
ndash OMA Lightweightbull CoAP over TCP
ndash httptoolsietforgiddraft-li-core-coap-payload-length-option-01txt
CoRE WG IETF-86 Orlando 4
New support for Web Links
bull JSON Web Linksndash httptoolsietforgiddraft-bormann-core-links-
json-02txt
2332010 CoRE WG IETF-77 Anaheim 5
General application layer solutions
bull Resource Directoryndash httptoolsietforgiddraft-shelby-core-
resource-directory-05txtndash OMA Lightweight
2332010 CoRE WG IETF-77 Anaheim 6
031113
Related13 Work
bull OMA13 Lightweight13 M2M13 Protocolbull CoAP13 over13 SMSGPRSUSSD
54
031113
What13 does13 the13 work13 entail
bull The13 ability13 to13 specify13 end13 point13 idenfiers13 and13 URIs13 to13 reflect13 which13 transport13 CoAP13 can13 use
bull The13 ability13 to13 register13 to13 resource13 directories13 resource13 types13 reflecng13 types13 of13 transport13 available
bull Ability13 for13 mul-shy‐transport13 nodes13 to13 select13 transport13 to13 use13 without13 significant13 alteraon13 to13 CoAP13 packet13 structure
55
031113
Points13 to13 consider
bull Requirements13 for13 transport13 layer13 protocol13 to13 carry13 CoAP13 packets
bull Representaon13 of13 URI13 scheme13 for13 generic13 transport13 protocols
bull Opon13 extensions13 for13 CoAP13 to13 express13 available13 transports
bull Mapping13 and13 message13 sizebull Security13 consideraons
56
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
URI13 =13 scheme13 13 13 authority13 path-shy‐abempty13 [13 query13 ]
bull Within13 the13 scheme13 namebull In13 the13 URI13 pathbull As13 a13 query13 component
57
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
bull Within13 the13 scheme13 namendash coap+tel+15105550101well-shy‐knowncorendash coap+tcpexamplecom5683temperaturendash coap+blel2cap[1234567890AB]4pulse
bull Easy13 URI13 parsing13 for13 transport13 type13 and13 idenfier
bull Each13 new13 scheme13 name13 requires13 IANA13 registraon
58
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
bull In13 the13 URI13 pathndash coaphostexamplecomtransport=tcpwell-shy‐knowncorert=core-shy‐rd
bull Easy13 adopon13 of13 new13 (and13 experimental)13 CoAP13 transports13 without13 IANA13 registraon
bull Caveat13 Uri-shy‐Path13 opon13 is13 a13 Crical13 CoAP13 opon13 see13 secon13 54113 of13 I-shy‐Diep-shy‐core-shy‐coap
59
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
bull As13 a13 URI13 query13 componentndash coaphostexamplecomwell-shy‐knowncorert=core-shy‐rdq=tcp
bull Also13 easy13 to13 adopt13 new13 (and13 experimental)13 CoAP13 transports13 without13 IANA13 registraon
bull Caveat13 Uri-shy‐Query13 opon13 is13 a13 Crical13 CoAP13 opon13 see13 secon13 54113 of13 I-shy‐Diep-shy‐core-shy‐coap
60
031113
URI13 Representaons13 for13 CoAPNon13 standard13 ways
bull Transport13 in13 the13 URI13 authority13 componentndash coaphost[port][transport]13 instead13 of13 coaphost[port]
bull Transport13 as13 a13 service13 URLndash servicecoaptcphostexamplecomwell-shy‐knowncorert=core-shy‐rd
bull Above13 two13 ways13 break13 exisng13 compability13 (although13 both13 are13 based13 on13 valid13 IANA13 URI13 registraons)
61
031113
URI13 Representaons13 for13 CoAPMiscellaneous13 Consideraons
bull Ensure13 that13 transport13 is13 defined13 unambiguously13 (eg13 L2CAP13 used13 by13 both13 BLE13 and13 standard13 Bluetooth13 so13 avoid13 rdquocoap+l2caprdquo13 or13 rdquotransport=l2caprdquo13 or13 rdquoq=l2caprdquondash Can13 be13 done13 as13 WG13 consensusndash Namespace13 approach13 eg13 rdquocoap+blel2caprdquo13 or13 rdquoq=blel2caprdquo
bull Allow13 end-shy‐points13 to13 use13 CoAP13 Resource13 Directory13 to13 register13 alternave13 transports13 and13 idenfiers13 and13 provide13 periodic13 updatesndash Register13 rdquocore-shy‐transportrdquo13 resource13 type
62
031113
Transport13 Consideraons
bull Uniqueness13 of13 end-shy‐point13 idenficaonbull Communicaon13 support13 Unidireconal13 Bidireconal13 1N13 (broadcast13 mulcast13 anycast)13 messaging
bull Binary13 encoding13 Network13 byte13 orderingbull MTU13 correlaon13 with13 CoAP13 PDU13 sizebull Transport13 latency
63
031113
Security13 Consideraons
bull Drar13 does13 not13 introduce13 new13 security13 requirements13 by13 itself
bull There13 may13 be13 privacy13 issues13 if13 nodes13 use13 telephone13 numbers13 or13 MAC13 addresses13 as13 public13 end13 point13 idenfiers
64
Akbar Rahman
IETF 86 March 2013 httpwwwietforgiddraft-rahman-core-sleepy-02txt
Enhanced Sleepy Node Support for CoAP
Introduction
It is expected that in CoAP networks there will be a certain portion of devices that are sleepy and which may occasionally go into a sleep mode (ie go into a low power state to conserve power) and subsequently have reduced CoAP protocol communication ability
This I-D proposes a minimal and efficient mechanism building on the Resource Directory concept (which will be integrated into a CoAP Proxy) to enhance sleepy node support in CoAP networks
Main Question from IETF-85 (Atlanta)
What performance benefit does the proposed Sleepy Node support solution give in a network that already has standard CoAP caching enabled
Sleepy Node Performance Analysis
Experimental Network
1-5 clients
Both Sleepy and Non-
Sleepy servers
Sleepy Node Performance Analysis Network Setup
CoAPSleepyServer(s)
CoAPSleepAwareReverseProxy
CoAP
Client(s)
Request
Response
Sleep9AwareCoREResourceDirectoryCapability
PublishedSleepParameters
Sleep9AwareCoAPStoreandForwardCapability Response
Request
SleepAwareCoAP503ResponseCapability
CoAPCachingCapability
bull Server supports publishing sleep parameters to proxy bull Eg Irsquom going to be asleep for X seconds
bull Proxy supports sleep-awareness capabilities bull Proxy also supports caching capability based off of maxAge bull Protocol flow similar to approach of Figure 1 (Synchronous RD Based Sleep
Tracking) of I-D
Proxy capabilities can be selectively enableddisabled
Proxy ndash Server Interface
Client ndash Proxy Interface
CoAP Sleep-Aware Reverse Proxy Features CoRE Sleep-aware Resource Directory
Support storing published sleep parameters from CoAP servers sleepState (AWAKE ASLEEP) sleepDuration
Sleep-aware CoAP 503 Response Capability If CoAP request to a sleeping server is received proxy returns a
lsquo503 Retry-Afterrsquo response to client 503 contains a timestamp indicating when the sever will wake back up
(timestamp delivered in CoAP maxAge option) Sleep-aware CoAP Store-and-Forward Capability
If CoAP request to a sleeping server is received proxy stores request until server wakes up and then forwards it
Caching capability Cache GET responses from server if maxAge option is present
(this is not a sleep aware feature)
Goals of Performance Analysis
For networks having sleepy servers provide measurements to quantify the impact that CoAP sleep-awareness capabilities can have
See if sleep-awareness capabilities can
provide additional benefits even when CoAP caching is used
Overview of Performance Analysis Performed The analysis was broken up into a set of test scenarios Each test scenario used a different combination of the following
variables Client issued GET requests Server was configured as a sleepy or non-sleepy server Proxy caching of GET responses was enabled or disabled Proxy sleep-aware 503 response capability was enabled or disabled Proxy store-and-forward capability was enabled or disabled maxAge in GET responses ndash Two values were tested 60sec and 5sec of Clients ndash Two values were used ndash 1 client and 5 clients
For comparison purposes the following were held constant across all test scenarios Client issued a fixed number of requests (100) across all test scenarios Client used a delay between each GET request (35sec) to better exercise
proxyrsquos caching and sleep-awareness capabilities For sleepy server test scenarios the server slept 60 sec awake for 3 sec
Format of Results The following results were collected for each
test scenario
Breakdown of the and types of transactions occurring between clientproxyserver
ldquoGETrdquo ndash Test Scenario Results
GET ndash Description of Test Scenarios
TestScenarios-GET
Scenario
CoAPSleepyServerSe7ngs CoAPSleepAwareReverseProxySe7ngs CoAPClientSe7ngs
SleepDuragton(sec)
AwakeDuragton(sec)
maxAge(sec) Caching SleepAwareSAF+
503NumberofClients
NumberofGETs
DelayBetweenClient
Requests(sec)
1a 0 Always 60 Enabled Disabled 1 100 35
1b 60 3 60 Enabled Disabled 1 100 35
1c 60 3 60 Enabled Enabled 1 100 35
2a 0 Always 60 Enabled Disabled 5 100 35
2b 60 3 60 Enabled Disabled 5 100 35
2c 60 3 60 Enabled Enabled 5 100 35
3a 0 Always 5 Enabled Disabled 5 100 35
3b 60 3 5 Enabled Disabled 5 100 35
3c 60 3 5 Enabled Enabled 5 100 35
ldquoGETrdquo ndash Test Scenario 1 Results
maxAge = 60 and 1 Client
GET ndash Scenario 1 ClientProxy Interface Transaction Mix
Scenarios 1a - Non-Sleepy Server Caching Proxy maxAge = 60sec 1b- Sleepy Server Caching Proxy maxAge = 60sec 1c - Sleepy Server Sleep Aware Proxy maxAge = 60sec
Sleep Aware Proxy has better performance for sleepy servers
0
100
200
300
400
500
600
700
1a 1b 1c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
GET ndash Scenario 1 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
Scenarios 1a - Non-Sleepy Server Caching Proxy maxAge = 60sec 1b- Sleepy Server Caching Proxy maxAge = 60sec 1c - Sleepy Server Sleep Aware Proxy maxAge = 60sec
0
100
200
300
400
500
600
700
800
1a 1b 1c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
ldquoGETrdquo ndash Test Scenario 2 Results
maxAge = 60 and 5 Clients
GET ndash Scenario 2 ClientProxy Interface Transaction Mix
Sleep Aware Proxy has slightly better performance for sleepy servers
0
200
400
600
800
1000
1200
1400
2a 2b 2c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
Scenarios 2a - Non-Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2b- Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2c - Sleepy Server Sleep Aware Proxy maxAge = 60sec 5 Clients
See ldquoExperimental Artifactsrdquo Note 1
GET ndash Scenario 2 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has slightly better performance for sleepy servers
0
50
100
150
200
250
300
350
400
2a 2b 2c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
Scenarios 2a - Non-Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2b- Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2c - Sleepy Server Sleep Aware Proxy maxAge = 60sec 5 Clients
See ldquoExperimental Artifactsrdquo Note 2
Experimental Artifacts Note 1
Currently in the experiment the sleep aware proxy checks the cached state of a resource before putting a request into its Store-and-forward queue while a server is sleeping Once in the queue the proxy unconditionally forwards the queued requests to the server once it wakes up This is not the most efficient setup and can easily be improved If the proxy instead checks its cache again before forwarding each queued request it may not need to forward the request to the server For example if there are two queued GET requests in the proxyrsquos queue that address the same resource Only the first request needs to be sent to the server the second request can use the cached response from the first request
Note 2 Currently in the experiment the sleepy server sends a sleepState PUT request to the
proxy each time it goes to sleep This is not the most efficient setup and can easily be improved For example if the server assumes that the proxy can keep track of its ONOFF cycles with its internal timers (eg as per Fig 1 of I-D) then the number of messages from the sleepy server dramatically goes down
ldquoGETrdquo ndash Test Scenario 3 Results
maxAge = 5 and 5 Clients
GET ndash Scenario 3 ClientProxy Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
Scenarios 3a - Non-Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3b- Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3c - Sleepy Server Sleep Aware Proxy maxAge = 5sec 5 Clients
0
500
1000
1500
2000
2500
3000
3500
4000
4500
5000
3a 3b 3c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
GET ndash Scenario 3 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
0
1000
2000
3000
4000
5000
6000
7000
3a 3b 3c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
Scenarios 3a - Non-Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3b- Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3c - Sleepy Server Sleep Aware Proxy maxAge = 5sec 5 Clients
Conclusions
Conclusions These results show that sleep-aware CoAP
proxy features can significantly optimize communication with sleepy servers in most scenarios
These results also show that sleep-
awareness capabilities can provide additional benefits above and beyond CoAP caching in most scenarios
Backup
Current CoAP Support of Sleepy Node (12)
CoAP proxies can use a previously cached response to service a new GET request for a sleepy origin server (as in HTTP) But if no valid cache then proxy has to attempt to
retrieve and may fail if origin server is sleeping [I-Dietf-core-coap]
Clients can discover list of resources from RD (GET rd-lookuphellip) for sleepy servers But attempt to GET resource from sleepy origin server
may fail if origin server is sleeping [IDietf-core-link-format amp IDshelby-core-resource-
directory]
Current CoAP Support of Sleepy Node (22)
Lower layer support for sleepy nodes in most wireless technologies (eg WiFi ZigBee) But limited to MAC packet scheduling for sleepy nodes
and not aware of specific needs of IP applications (like CoAP)
Proposal ndash RD Based Sleep Tracking (14)
The current CoAP approach to support sleepy nodes can be significantly improved by introducing RD based mechanisms for a CoAP client to determine whether A targeted resource is located on a sleepy server A sleepy server is currently in sleep mode or not
There is any associated caching Proxy (possibly the RD itself) for a sleepy server
Proposal ndash RD Based Sleep Tracking (24)
We define the following new RD attributes to characterize the properties of a sleepy node SleepState - Indicates whether the node is currently in
sleep mode or not (ie Sleeping or Awake) SleepDuration - Indicates the maximum duration of time
that the node stays in sleep mode TimeSleeping - Indicates the length of time the node
has been sleeping (ie if Sleep State = Sleeping) NextSleep - Indicates the next time the node will go to
sleep (ie if Sleep State = Awake)
CachingProxy ndash Indicates the caching proxy of the sleepy node (ie the RD itself or another node)
Proposal ndash RD Based Sleep Tracking (34)
These attributes are all server (node) level and are new parameters added to the RD URI Template Variables
Finally we also define a new lookup-type (ss) for the RD lookup interface specified in [I-Dshelby-core-resource-directory] This new lookup-type supports looking up the
ldquoSleepStaterdquo (ss) of a specified end-point
Proposal ndash RD Based Sleep Tracking (44)
The three time based parameters (SleepDuration TimeSleeping NextSleep) can be based on either an absolute network time (for a time synchronized network) or a relative local time (measured at the local node)
Following the approach of [I-Dietf-core-link-format] and [I-Dshelby-core-resource-directory] sleep parameters for sleepy servers can be stored by the server in the RD and accessed by all interested clients
Examples of using these parameters in a synchronous or asynchronous manner are shown in the I-D
http6lowappnet coreIETF86 2013-03-12-13
We assume people have read the drafts
Meetings serve to advance difficult issues by making good use of face-to-face communications
Note Well Be aware of the IPR principles according to RFC 3979 and its updates
uumlBlue sheetsuumlScribe(s)
96
drar-shy‐iep-shy‐core-shy‐coapsubmiqed13 to13 IESG
2013-shy‐03-shy‐13
97
OMA Lightweight M2M Overview(A new standard using lots of IETF specs including DTLS
CoAP Block Observe Resource Directory SenMLhellip)
Zach ShelbyCoRE WG IETF-86 Orlando
OMA Lightweight M2Mbull Open Mobile Alliance is well known for Device Management (DM)bull OMA Lightweight M2M is a new standard from the alliance
ndash Focused on constrained Cellular and sensor network M2M devicesndash Driven by leading operators and vendors
bull Scopendash Interfaces protocol amp security between Device and Serverndash Object and Resource modelndash Bootstrap Device Access Control Connectivity and Firmware Objects
bull Draft Specifications are availablendash httpmemberopenmobileallianceorgftpPublic_documentsDM
LightweightM2MPermanent_documentsOMA-TS-LightweightM2M-V1_0_0-20130301-Dzip
bull Timelinendash Requirements and Architecture completed 3Q2012ndash Spec ready for Consistency Review 2Q2013ndash Candidate Approval expected 3Q2013
2 CoRE WG IETF-86 Orlando
Architecture
3
Scope of LWM2M
CoRE WG IETF-86 Orlando
Object Model
bull A Client has one or more Object Instancesbull An Object is a collection of Resourcesbull A Resource is an atomic piece of information
ndash Read Written or Executed
bull Resources can have multiple instancesbull Objects and Resources are identified by a
16-bit Integer Instances by an 8-bit Integerbull ObjectsResources are accessed with
simple URIs Object IDObject InstanceResource ID
eg 1213
4 CoRE WG IETF-86 Orlando
CoRE WG IETF-86 Orlando
CoRE Resource Directory
draft-shelby-core-resource-directory-05
Z Shelby C Bormann S Krco
Backgroundbull Not a new concept
ndash think web search engine or any link directorybull Defines the interfaces to a Resource Directorybull Based on Web Linking framework and the CoRE Link Formatbull Generic REST design for use over HTTP and CoAPbull Used by OMA Lightweight M2Mbull Has already been deployed
ndash In traffic monitoring systemsndash In street lighting systemsndash For vehicular asset trackingndash By a major Cellular M2M operator
Changes since -04
bull Restricted Update to parameter updatesbull Added pagination support for the Lookup interfacebull Changed rt= to et= for the registration amp update
interfacebull Added group support
Group Management
bull RD now includes group management featuresbull New Group Function Set
ndash Register a groupbull Group name domain multicast address endpoint members
ndash Remove a groupbull Group lookup using the Lookup Function Set
ndash List registered groupsndash Find the members of a groupndash Find groups with certain endpoints or resources
Registering a Group
EP RD
| |
| - POST rd-groupgp=lights ltgtep=node1 --gt |
| |
| |
| lt---- 201 Created Location rd-group12 ---- |
| |
Req POST coaprdexamplecomrd-groupgp=lights
Payload
ltgtep=node1
ltgtep=node2
Res 201 Created
Location rd-group12
Looking up Group Members
Client RD
| |
| ----- GET rd-lookupepgp=lights1 ----------------------gt |
| |
| |
| lt-- 205 Content ltrdgtd=domain1ltrdgtd=domain2 --------- |
| |
Req GET rd-lookupepgp=lights1
Res 205 Content
ltcoaphostportgtep=node1
ltcoaphostportgtep=node2rdquo
Things for the futurebull Support for JSON representation of Web Links
ndash httptoolsietforgiddraft-bormann-core-links-json-02txtbull Registry for RD registration query parameters
ndash Already OMA Lightweight has defined some new onesbull More examples
Group 3 ldquonew workrdquo(continued)
109
drar-shy‐greevenbosch-shy‐core-shy‐profile-shy‐descripon-shy‐01Bert13 GreevenboschJeroen13 Hoebeke
Isam13 IshaqFloris13 Van13 den13 Abeele
Descripon
bull JSON13 format13 for13 signalling13 the13 servers13 capabilies
bull Signalling13 of13 supported13 opons13 media13 types13 and13 block13 sizendash Other13 items13 can13 be13 added
bull Filtering13 on13 specific13 fields13 through13 URI-shy‐Querybull Link13 hqpdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐profile-shy‐descripon
well-shy‐knownprofile
bull To13 acquire13 profile13 data13 of13 resources13 on13 a13 parcular13 service13 the13 well-shy‐knownprofile13 URI-shy‐path13 is13 introduced
bull For13 example13 to13 get13 all13 informaon13 from13 sensors13 served13 by13 wwwexampleorg13 we13 can13 do13 a13 GET13 to13 coapwwwexampleorgwell-shy‐knownprofile
bull Filtering13 on13 parcular13 resources13 is13 done13 through13 URI-shy‐Queries
Format
bull Currently13 the13 following13 fields13 are13 definedndash ldquopathrdquo13 contains13 the13 URI-shy‐path13 associated13 with13 a13 resource
ndash ldquooprdquo13 a13 numerical13 list13 of13 supported13 opon13 numbers
ndash ldquocfrdquo13 a13 numerical13 list13 of13 supported13 content-shy‐format13 numbers
ndash ldquob1srdquo13 ldquob2srdquo13 supported13 block13 sizes13 for13 Block113 and13 Block213 respecvely
Examplebull On13 the13 right13 is13 an13 example13 of13 a13 camera13 sensor13 at13 coapwwwexampleorgcam13 that13 supports13 the13 Uri-shy‐Host13 (3)13 ETag13 (4)13 Uri-shy‐Port13 (7)13 Uri-shy‐Path13 (11)13 Content-shy‐Format13 (12)13 Token13 (19)13 Block213 (23)13 and13 Proxy-shy‐Uri13 (35)13 opons
bull The13 supported13 content13 formats13 are13 textplain13 (0)13 applicaon13 link-shy‐format13 (40)13 and13 applicaonjson13 (50)
bull The13 supported13 Block213 can13 use13 25613 or13 51213 byte13 blocks
Req13 GET13 coapwwwexampleorgwell-shy‐knownprofile13 Res13 20513 Content13 (applicationjson)13 13 13 13 profile13 13 13 13 13 13 13 13 pathcam13 13 13 13 op[3471112192335]13 13 13 13 13 cf[04050]13 13 13 13 13 b2s[45]13 13 13 13
Filtering13 through13 use13 of13 URI-shy‐Query
bull Filtering13 can13 be13 done13 through13 the13 URI-shy‐Querybull Query13 format13 N=V
ndash N13 is13 a13 profile13 fieldndash V13 is13 the13 desired13 value
bull Examplesndash To13 find13 resources13 that13 support13 content13 format13 ldquoapplicaonjsonrdquo
13 GET13 wwwexampleorgwell-shy‐knownprofilecf=50ndash To13 get13 informaon13 about13 the13 camera
13 GET13 wwwexampleorgwell-shy‐knownprofilepath=cam
Open13 issues
bull Which13 other13 profile13 data13 needs13 signallingndash Content-shy‐type13 for13 different13 methods
bull Fix13 the13 order13 in13 which13 the13 profile13 fields13 must13 appearndash Non-shy‐fixed13 order13 easier13 extensible
bull Inheritance13 of13 a13 profile13 descriponbull Extend13 usage13 to13 signal13 the13 client13 profilebull Integraon13 with13 link13 format
Thank13 youQuesons
drar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval-shy‐00
Bert13 Greevenbosch
Descripon
bull The13 ldquoMinimumRequestInterval13 opon13 can13 be13 used13 to13 indicate13 the13 minimum13 me13 between13 two13 requests13 in13 a13 transacon
bull Originally13 intended13 for13 Block13 but13 also13 usable13 for13 other13 transaconsndash Example13 browsing13 a13 server
bull The13 goal13 is13 to13 reduce13 the13 server13 load13 and13 network13 traffic
bull Link13 hqpsdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval
Usage
bull The13 client13 keeps13 the13 server13 informed13 about13 its13 request13 speed13 through13 inclusion13 of13 the13 ldquoMinimumRequestIntervalrdquo13 opon
bull In13 responses13 the13 server13 fixes13 the13 minimum13 request13 interval13 through13 the13 same13 opon
bull The13 client13 obeys13 the13 speed13 indicated13 by13 the13 server
bull The13 client13 can13 send13 slower13 but13 not13 faster
Advantages
bull The13 server13 has13 means13 to13 limit13 the13 amount13 of13 incoming13 traffic
bull The13 server13 can13 prevent13 to13 become13 overloaded13 with13 too13 many13 tasks
bull The13 server13 does13 not13 need13 arficially13 slow13 down13 the13 client13 by13 sending13 late13 ACKsndash No13 need13 to13 keep13 track13 of13 delayed13 ACKsndash The13 server13 can13 perform13 other13 tasks13 instead
bull Reduced13 network13 traffic
Thank13 youQuesons
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-links-json-02txt
123
RFC 6690 (link-format) documents are somewhat foreign to many web app developerssect would prefer to have them in JSON format
There is no standard way to represent link-format documents in applicationssect but everyone knows how to handle JSON
Define a standard JSON translation for link-format
Itrsquos
not
rock
et
scien
ce
ltsensorsgtct=40title=Sensor Index ltsensorstempgtrt=temperature-cif=sensor ltsensorslightgtrt=light-luxif=sensor lthttpwwwexamplecomsensorst123gt anchor=sensorstemprel=describedby lttgtanchor=sensorstemprel=alternate [hrefsensorsct40titleSensor Index hrefsensorstemprttemperature-cifsensor hrefsensorslightrtlight-luxifsensor hrefhttpwwwexamplecomsensorst123 anchorsensorstempreldescribedby hreftanchorsensorstemprelalternate]
124
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-ipsec-for-coap-00txt
IPsec definitions for CoAP Mostly placeholder at this time Who has implementation experience with this
125
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-cross-reverse-convention-00txt
This draft has two lines of payload(based on a WGLC comment by Cullen Jennings)
coap12344567foobara=3
httpwwwproxycomwellknowncore-translate1234_4567foobara=3
Is that a useful convention to have
126
Insert CI slides here
127
128
0
5
10
15
20
25
30
35
40
10 20 30 40 50 60 70
good
put (
pps)
pps
Goodput vs pps (Econotags)
goodput
[Khattak preliminary]
Congestion Control
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-cocoa-00txt
ldquoadvancedrdquo cc (The draft is just a first shot) Others may have better ideas
129
Insert post-WGLC discussion slides here
130
Stop Continue Start
131
An Agile Retrospective
http6lowappnet coreIETF86 2013-03-12-13
Stop
132
Endless new CoAP optionssect instead use RESTful as much as possible
Move general security lifecycle out Looking at theoretical problems
http6lowappnet coreIETF86 2013-03-12-13
Continue
Interops Running code Look at real-world examples and deployments Solve their actual problems
sect Unilateral enhancements eg higher performance congestion control
sect Transports (SMS hellip)sect Make Web linking and Directories more and more usefulsect RESTful Design Paradigms for real-world problems
133
http6lowappnet coreIETF86 2013-03-12-13
Start
Further push into the (browser) web world (HTML5 browser security)
Specific supporting worksect SenMLsect URI work (dev URN hellip)sect Security Processes (next slide)
Spin outsect (We donrsquot really get to decide where this is done)
134
http6lowappnet coreIETF86 2013-03-12-13
Security
Integrate Application Network Group Keyingsect Tunnel-free setup
Donrsquot redo what has been done alreadysect ZigBee IP is finesect But what about other scenarios
Simple REST interfaces for working with keying materials and authorizationsect Start with defining objectives
Object Security for Constrained Nodes135
Re-chartering CoREWhat do we want to do now that wersquore grown up
Zach ShelbyCoRE WG IETF-86 Orlando
What is the scope
bull So we have a protocol and Web Linking what next
bull Keep with what we know besthellip1 Enhancements around CoAP2 New transports for CoAP3 New representations for Web Links4 General application layer solutions
CoRE WG IETF-86 Orlando 2
Enhancements around CoAP
bull Advanced congestion control
CoRE WG IETF-86 Orlando 3
New Transports for CoAP
bull Infrastructure for CoAP over foondash httptoolsietforgiddraft-silverajan-core-
coap-alternative-transports-01txtbull CoAP over SMS
ndash httptoolsietforgiddraft-becker-core-coap-sms-gprs-03txt
ndash OMA Lightweightbull CoAP over TCP
ndash httptoolsietforgiddraft-li-core-coap-payload-length-option-01txt
CoRE WG IETF-86 Orlando 4
New support for Web Links
bull JSON Web Linksndash httptoolsietforgiddraft-bormann-core-links-
json-02txt
2332010 CoRE WG IETF-77 Anaheim 5
General application layer solutions
bull Resource Directoryndash httptoolsietforgiddraft-shelby-core-
resource-directory-05txtndash OMA Lightweight
2332010 CoRE WG IETF-77 Anaheim 6
031113
What13 does13 the13 work13 entail
bull The13 ability13 to13 specify13 end13 point13 idenfiers13 and13 URIs13 to13 reflect13 which13 transport13 CoAP13 can13 use
bull The13 ability13 to13 register13 to13 resource13 directories13 resource13 types13 reflecng13 types13 of13 transport13 available
bull Ability13 for13 mul-shy‐transport13 nodes13 to13 select13 transport13 to13 use13 without13 significant13 alteraon13 to13 CoAP13 packet13 structure
55
031113
Points13 to13 consider
bull Requirements13 for13 transport13 layer13 protocol13 to13 carry13 CoAP13 packets
bull Representaon13 of13 URI13 scheme13 for13 generic13 transport13 protocols
bull Opon13 extensions13 for13 CoAP13 to13 express13 available13 transports
bull Mapping13 and13 message13 sizebull Security13 consideraons
56
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
URI13 =13 scheme13 13 13 authority13 path-shy‐abempty13 [13 query13 ]
bull Within13 the13 scheme13 namebull In13 the13 URI13 pathbull As13 a13 query13 component
57
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
bull Within13 the13 scheme13 namendash coap+tel+15105550101well-shy‐knowncorendash coap+tcpexamplecom5683temperaturendash coap+blel2cap[1234567890AB]4pulse
bull Easy13 URI13 parsing13 for13 transport13 type13 and13 idenfier
bull Each13 new13 scheme13 name13 requires13 IANA13 registraon
58
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
bull In13 the13 URI13 pathndash coaphostexamplecomtransport=tcpwell-shy‐knowncorert=core-shy‐rd
bull Easy13 adopon13 of13 new13 (and13 experimental)13 CoAP13 transports13 without13 IANA13 registraon
bull Caveat13 Uri-shy‐Path13 opon13 is13 a13 Crical13 CoAP13 opon13 see13 secon13 54113 of13 I-shy‐Diep-shy‐core-shy‐coap
59
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
bull As13 a13 URI13 query13 componentndash coaphostexamplecomwell-shy‐knowncorert=core-shy‐rdq=tcp
bull Also13 easy13 to13 adopt13 new13 (and13 experimental)13 CoAP13 transports13 without13 IANA13 registraon
bull Caveat13 Uri-shy‐Query13 opon13 is13 a13 Crical13 CoAP13 opon13 see13 secon13 54113 of13 I-shy‐Diep-shy‐core-shy‐coap
60
031113
URI13 Representaons13 for13 CoAPNon13 standard13 ways
bull Transport13 in13 the13 URI13 authority13 componentndash coaphost[port][transport]13 instead13 of13 coaphost[port]
bull Transport13 as13 a13 service13 URLndash servicecoaptcphostexamplecomwell-shy‐knowncorert=core-shy‐rd
bull Above13 two13 ways13 break13 exisng13 compability13 (although13 both13 are13 based13 on13 valid13 IANA13 URI13 registraons)
61
031113
URI13 Representaons13 for13 CoAPMiscellaneous13 Consideraons
bull Ensure13 that13 transport13 is13 defined13 unambiguously13 (eg13 L2CAP13 used13 by13 both13 BLE13 and13 standard13 Bluetooth13 so13 avoid13 rdquocoap+l2caprdquo13 or13 rdquotransport=l2caprdquo13 or13 rdquoq=l2caprdquondash Can13 be13 done13 as13 WG13 consensusndash Namespace13 approach13 eg13 rdquocoap+blel2caprdquo13 or13 rdquoq=blel2caprdquo
bull Allow13 end-shy‐points13 to13 use13 CoAP13 Resource13 Directory13 to13 register13 alternave13 transports13 and13 idenfiers13 and13 provide13 periodic13 updatesndash Register13 rdquocore-shy‐transportrdquo13 resource13 type
62
031113
Transport13 Consideraons
bull Uniqueness13 of13 end-shy‐point13 idenficaonbull Communicaon13 support13 Unidireconal13 Bidireconal13 1N13 (broadcast13 mulcast13 anycast)13 messaging
bull Binary13 encoding13 Network13 byte13 orderingbull MTU13 correlaon13 with13 CoAP13 PDU13 sizebull Transport13 latency
63
031113
Security13 Consideraons
bull Drar13 does13 not13 introduce13 new13 security13 requirements13 by13 itself
bull There13 may13 be13 privacy13 issues13 if13 nodes13 use13 telephone13 numbers13 or13 MAC13 addresses13 as13 public13 end13 point13 idenfiers
64
Akbar Rahman
IETF 86 March 2013 httpwwwietforgiddraft-rahman-core-sleepy-02txt
Enhanced Sleepy Node Support for CoAP
Introduction
It is expected that in CoAP networks there will be a certain portion of devices that are sleepy and which may occasionally go into a sleep mode (ie go into a low power state to conserve power) and subsequently have reduced CoAP protocol communication ability
This I-D proposes a minimal and efficient mechanism building on the Resource Directory concept (which will be integrated into a CoAP Proxy) to enhance sleepy node support in CoAP networks
Main Question from IETF-85 (Atlanta)
What performance benefit does the proposed Sleepy Node support solution give in a network that already has standard CoAP caching enabled
Sleepy Node Performance Analysis
Experimental Network
1-5 clients
Both Sleepy and Non-
Sleepy servers
Sleepy Node Performance Analysis Network Setup
CoAPSleepyServer(s)
CoAPSleepAwareReverseProxy
CoAP
Client(s)
Request
Response
Sleep9AwareCoREResourceDirectoryCapability
PublishedSleepParameters
Sleep9AwareCoAPStoreandForwardCapability Response
Request
SleepAwareCoAP503ResponseCapability
CoAPCachingCapability
bull Server supports publishing sleep parameters to proxy bull Eg Irsquom going to be asleep for X seconds
bull Proxy supports sleep-awareness capabilities bull Proxy also supports caching capability based off of maxAge bull Protocol flow similar to approach of Figure 1 (Synchronous RD Based Sleep
Tracking) of I-D
Proxy capabilities can be selectively enableddisabled
Proxy ndash Server Interface
Client ndash Proxy Interface
CoAP Sleep-Aware Reverse Proxy Features CoRE Sleep-aware Resource Directory
Support storing published sleep parameters from CoAP servers sleepState (AWAKE ASLEEP) sleepDuration
Sleep-aware CoAP 503 Response Capability If CoAP request to a sleeping server is received proxy returns a
lsquo503 Retry-Afterrsquo response to client 503 contains a timestamp indicating when the sever will wake back up
(timestamp delivered in CoAP maxAge option) Sleep-aware CoAP Store-and-Forward Capability
If CoAP request to a sleeping server is received proxy stores request until server wakes up and then forwards it
Caching capability Cache GET responses from server if maxAge option is present
(this is not a sleep aware feature)
Goals of Performance Analysis
For networks having sleepy servers provide measurements to quantify the impact that CoAP sleep-awareness capabilities can have
See if sleep-awareness capabilities can
provide additional benefits even when CoAP caching is used
Overview of Performance Analysis Performed The analysis was broken up into a set of test scenarios Each test scenario used a different combination of the following
variables Client issued GET requests Server was configured as a sleepy or non-sleepy server Proxy caching of GET responses was enabled or disabled Proxy sleep-aware 503 response capability was enabled or disabled Proxy store-and-forward capability was enabled or disabled maxAge in GET responses ndash Two values were tested 60sec and 5sec of Clients ndash Two values were used ndash 1 client and 5 clients
For comparison purposes the following were held constant across all test scenarios Client issued a fixed number of requests (100) across all test scenarios Client used a delay between each GET request (35sec) to better exercise
proxyrsquos caching and sleep-awareness capabilities For sleepy server test scenarios the server slept 60 sec awake for 3 sec
Format of Results The following results were collected for each
test scenario
Breakdown of the and types of transactions occurring between clientproxyserver
ldquoGETrdquo ndash Test Scenario Results
GET ndash Description of Test Scenarios
TestScenarios-GET
Scenario
CoAPSleepyServerSe7ngs CoAPSleepAwareReverseProxySe7ngs CoAPClientSe7ngs
SleepDuragton(sec)
AwakeDuragton(sec)
maxAge(sec) Caching SleepAwareSAF+
503NumberofClients
NumberofGETs
DelayBetweenClient
Requests(sec)
1a 0 Always 60 Enabled Disabled 1 100 35
1b 60 3 60 Enabled Disabled 1 100 35
1c 60 3 60 Enabled Enabled 1 100 35
2a 0 Always 60 Enabled Disabled 5 100 35
2b 60 3 60 Enabled Disabled 5 100 35
2c 60 3 60 Enabled Enabled 5 100 35
3a 0 Always 5 Enabled Disabled 5 100 35
3b 60 3 5 Enabled Disabled 5 100 35
3c 60 3 5 Enabled Enabled 5 100 35
ldquoGETrdquo ndash Test Scenario 1 Results
maxAge = 60 and 1 Client
GET ndash Scenario 1 ClientProxy Interface Transaction Mix
Scenarios 1a - Non-Sleepy Server Caching Proxy maxAge = 60sec 1b- Sleepy Server Caching Proxy maxAge = 60sec 1c - Sleepy Server Sleep Aware Proxy maxAge = 60sec
Sleep Aware Proxy has better performance for sleepy servers
0
100
200
300
400
500
600
700
1a 1b 1c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
GET ndash Scenario 1 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
Scenarios 1a - Non-Sleepy Server Caching Proxy maxAge = 60sec 1b- Sleepy Server Caching Proxy maxAge = 60sec 1c - Sleepy Server Sleep Aware Proxy maxAge = 60sec
0
100
200
300
400
500
600
700
800
1a 1b 1c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
ldquoGETrdquo ndash Test Scenario 2 Results
maxAge = 60 and 5 Clients
GET ndash Scenario 2 ClientProxy Interface Transaction Mix
Sleep Aware Proxy has slightly better performance for sleepy servers
0
200
400
600
800
1000
1200
1400
2a 2b 2c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
Scenarios 2a - Non-Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2b- Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2c - Sleepy Server Sleep Aware Proxy maxAge = 60sec 5 Clients
See ldquoExperimental Artifactsrdquo Note 1
GET ndash Scenario 2 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has slightly better performance for sleepy servers
0
50
100
150
200
250
300
350
400
2a 2b 2c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
Scenarios 2a - Non-Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2b- Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2c - Sleepy Server Sleep Aware Proxy maxAge = 60sec 5 Clients
See ldquoExperimental Artifactsrdquo Note 2
Experimental Artifacts Note 1
Currently in the experiment the sleep aware proxy checks the cached state of a resource before putting a request into its Store-and-forward queue while a server is sleeping Once in the queue the proxy unconditionally forwards the queued requests to the server once it wakes up This is not the most efficient setup and can easily be improved If the proxy instead checks its cache again before forwarding each queued request it may not need to forward the request to the server For example if there are two queued GET requests in the proxyrsquos queue that address the same resource Only the first request needs to be sent to the server the second request can use the cached response from the first request
Note 2 Currently in the experiment the sleepy server sends a sleepState PUT request to the
proxy each time it goes to sleep This is not the most efficient setup and can easily be improved For example if the server assumes that the proxy can keep track of its ONOFF cycles with its internal timers (eg as per Fig 1 of I-D) then the number of messages from the sleepy server dramatically goes down
ldquoGETrdquo ndash Test Scenario 3 Results
maxAge = 5 and 5 Clients
GET ndash Scenario 3 ClientProxy Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
Scenarios 3a - Non-Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3b- Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3c - Sleepy Server Sleep Aware Proxy maxAge = 5sec 5 Clients
0
500
1000
1500
2000
2500
3000
3500
4000
4500
5000
3a 3b 3c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
GET ndash Scenario 3 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
0
1000
2000
3000
4000
5000
6000
7000
3a 3b 3c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
Scenarios 3a - Non-Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3b- Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3c - Sleepy Server Sleep Aware Proxy maxAge = 5sec 5 Clients
Conclusions
Conclusions These results show that sleep-aware CoAP
proxy features can significantly optimize communication with sleepy servers in most scenarios
These results also show that sleep-
awareness capabilities can provide additional benefits above and beyond CoAP caching in most scenarios
Backup
Current CoAP Support of Sleepy Node (12)
CoAP proxies can use a previously cached response to service a new GET request for a sleepy origin server (as in HTTP) But if no valid cache then proxy has to attempt to
retrieve and may fail if origin server is sleeping [I-Dietf-core-coap]
Clients can discover list of resources from RD (GET rd-lookuphellip) for sleepy servers But attempt to GET resource from sleepy origin server
may fail if origin server is sleeping [IDietf-core-link-format amp IDshelby-core-resource-
directory]
Current CoAP Support of Sleepy Node (22)
Lower layer support for sleepy nodes in most wireless technologies (eg WiFi ZigBee) But limited to MAC packet scheduling for sleepy nodes
and not aware of specific needs of IP applications (like CoAP)
Proposal ndash RD Based Sleep Tracking (14)
The current CoAP approach to support sleepy nodes can be significantly improved by introducing RD based mechanisms for a CoAP client to determine whether A targeted resource is located on a sleepy server A sleepy server is currently in sleep mode or not
There is any associated caching Proxy (possibly the RD itself) for a sleepy server
Proposal ndash RD Based Sleep Tracking (24)
We define the following new RD attributes to characterize the properties of a sleepy node SleepState - Indicates whether the node is currently in
sleep mode or not (ie Sleeping or Awake) SleepDuration - Indicates the maximum duration of time
that the node stays in sleep mode TimeSleeping - Indicates the length of time the node
has been sleeping (ie if Sleep State = Sleeping) NextSleep - Indicates the next time the node will go to
sleep (ie if Sleep State = Awake)
CachingProxy ndash Indicates the caching proxy of the sleepy node (ie the RD itself or another node)
Proposal ndash RD Based Sleep Tracking (34)
These attributes are all server (node) level and are new parameters added to the RD URI Template Variables
Finally we also define a new lookup-type (ss) for the RD lookup interface specified in [I-Dshelby-core-resource-directory] This new lookup-type supports looking up the
ldquoSleepStaterdquo (ss) of a specified end-point
Proposal ndash RD Based Sleep Tracking (44)
The three time based parameters (SleepDuration TimeSleeping NextSleep) can be based on either an absolute network time (for a time synchronized network) or a relative local time (measured at the local node)
Following the approach of [I-Dietf-core-link-format] and [I-Dshelby-core-resource-directory] sleep parameters for sleepy servers can be stored by the server in the RD and accessed by all interested clients
Examples of using these parameters in a synchronous or asynchronous manner are shown in the I-D
http6lowappnet coreIETF86 2013-03-12-13
We assume people have read the drafts
Meetings serve to advance difficult issues by making good use of face-to-face communications
Note Well Be aware of the IPR principles according to RFC 3979 and its updates
uumlBlue sheetsuumlScribe(s)
96
drar-shy‐iep-shy‐core-shy‐coapsubmiqed13 to13 IESG
2013-shy‐03-shy‐13
97
OMA Lightweight M2M Overview(A new standard using lots of IETF specs including DTLS
CoAP Block Observe Resource Directory SenMLhellip)
Zach ShelbyCoRE WG IETF-86 Orlando
OMA Lightweight M2Mbull Open Mobile Alliance is well known for Device Management (DM)bull OMA Lightweight M2M is a new standard from the alliance
ndash Focused on constrained Cellular and sensor network M2M devicesndash Driven by leading operators and vendors
bull Scopendash Interfaces protocol amp security between Device and Serverndash Object and Resource modelndash Bootstrap Device Access Control Connectivity and Firmware Objects
bull Draft Specifications are availablendash httpmemberopenmobileallianceorgftpPublic_documentsDM
LightweightM2MPermanent_documentsOMA-TS-LightweightM2M-V1_0_0-20130301-Dzip
bull Timelinendash Requirements and Architecture completed 3Q2012ndash Spec ready for Consistency Review 2Q2013ndash Candidate Approval expected 3Q2013
2 CoRE WG IETF-86 Orlando
Architecture
3
Scope of LWM2M
CoRE WG IETF-86 Orlando
Object Model
bull A Client has one or more Object Instancesbull An Object is a collection of Resourcesbull A Resource is an atomic piece of information
ndash Read Written or Executed
bull Resources can have multiple instancesbull Objects and Resources are identified by a
16-bit Integer Instances by an 8-bit Integerbull ObjectsResources are accessed with
simple URIs Object IDObject InstanceResource ID
eg 1213
4 CoRE WG IETF-86 Orlando
CoRE WG IETF-86 Orlando
CoRE Resource Directory
draft-shelby-core-resource-directory-05
Z Shelby C Bormann S Krco
Backgroundbull Not a new concept
ndash think web search engine or any link directorybull Defines the interfaces to a Resource Directorybull Based on Web Linking framework and the CoRE Link Formatbull Generic REST design for use over HTTP and CoAPbull Used by OMA Lightweight M2Mbull Has already been deployed
ndash In traffic monitoring systemsndash In street lighting systemsndash For vehicular asset trackingndash By a major Cellular M2M operator
Changes since -04
bull Restricted Update to parameter updatesbull Added pagination support for the Lookup interfacebull Changed rt= to et= for the registration amp update
interfacebull Added group support
Group Management
bull RD now includes group management featuresbull New Group Function Set
ndash Register a groupbull Group name domain multicast address endpoint members
ndash Remove a groupbull Group lookup using the Lookup Function Set
ndash List registered groupsndash Find the members of a groupndash Find groups with certain endpoints or resources
Registering a Group
EP RD
| |
| - POST rd-groupgp=lights ltgtep=node1 --gt |
| |
| |
| lt---- 201 Created Location rd-group12 ---- |
| |
Req POST coaprdexamplecomrd-groupgp=lights
Payload
ltgtep=node1
ltgtep=node2
Res 201 Created
Location rd-group12
Looking up Group Members
Client RD
| |
| ----- GET rd-lookupepgp=lights1 ----------------------gt |
| |
| |
| lt-- 205 Content ltrdgtd=domain1ltrdgtd=domain2 --------- |
| |
Req GET rd-lookupepgp=lights1
Res 205 Content
ltcoaphostportgtep=node1
ltcoaphostportgtep=node2rdquo
Things for the futurebull Support for JSON representation of Web Links
ndash httptoolsietforgiddraft-bormann-core-links-json-02txtbull Registry for RD registration query parameters
ndash Already OMA Lightweight has defined some new onesbull More examples
Group 3 ldquonew workrdquo(continued)
109
drar-shy‐greevenbosch-shy‐core-shy‐profile-shy‐descripon-shy‐01Bert13 GreevenboschJeroen13 Hoebeke
Isam13 IshaqFloris13 Van13 den13 Abeele
Descripon
bull JSON13 format13 for13 signalling13 the13 servers13 capabilies
bull Signalling13 of13 supported13 opons13 media13 types13 and13 block13 sizendash Other13 items13 can13 be13 added
bull Filtering13 on13 specific13 fields13 through13 URI-shy‐Querybull Link13 hqpdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐profile-shy‐descripon
well-shy‐knownprofile
bull To13 acquire13 profile13 data13 of13 resources13 on13 a13 parcular13 service13 the13 well-shy‐knownprofile13 URI-shy‐path13 is13 introduced
bull For13 example13 to13 get13 all13 informaon13 from13 sensors13 served13 by13 wwwexampleorg13 we13 can13 do13 a13 GET13 to13 coapwwwexampleorgwell-shy‐knownprofile
bull Filtering13 on13 parcular13 resources13 is13 done13 through13 URI-shy‐Queries
Format
bull Currently13 the13 following13 fields13 are13 definedndash ldquopathrdquo13 contains13 the13 URI-shy‐path13 associated13 with13 a13 resource
ndash ldquooprdquo13 a13 numerical13 list13 of13 supported13 opon13 numbers
ndash ldquocfrdquo13 a13 numerical13 list13 of13 supported13 content-shy‐format13 numbers
ndash ldquob1srdquo13 ldquob2srdquo13 supported13 block13 sizes13 for13 Block113 and13 Block213 respecvely
Examplebull On13 the13 right13 is13 an13 example13 of13 a13 camera13 sensor13 at13 coapwwwexampleorgcam13 that13 supports13 the13 Uri-shy‐Host13 (3)13 ETag13 (4)13 Uri-shy‐Port13 (7)13 Uri-shy‐Path13 (11)13 Content-shy‐Format13 (12)13 Token13 (19)13 Block213 (23)13 and13 Proxy-shy‐Uri13 (35)13 opons
bull The13 supported13 content13 formats13 are13 textplain13 (0)13 applicaon13 link-shy‐format13 (40)13 and13 applicaonjson13 (50)
bull The13 supported13 Block213 can13 use13 25613 or13 51213 byte13 blocks
Req13 GET13 coapwwwexampleorgwell-shy‐knownprofile13 Res13 20513 Content13 (applicationjson)13 13 13 13 profile13 13 13 13 13 13 13 13 pathcam13 13 13 13 op[3471112192335]13 13 13 13 13 cf[04050]13 13 13 13 13 b2s[45]13 13 13 13
Filtering13 through13 use13 of13 URI-shy‐Query
bull Filtering13 can13 be13 done13 through13 the13 URI-shy‐Querybull Query13 format13 N=V
ndash N13 is13 a13 profile13 fieldndash V13 is13 the13 desired13 value
bull Examplesndash To13 find13 resources13 that13 support13 content13 format13 ldquoapplicaonjsonrdquo
13 GET13 wwwexampleorgwell-shy‐knownprofilecf=50ndash To13 get13 informaon13 about13 the13 camera
13 GET13 wwwexampleorgwell-shy‐knownprofilepath=cam
Open13 issues
bull Which13 other13 profile13 data13 needs13 signallingndash Content-shy‐type13 for13 different13 methods
bull Fix13 the13 order13 in13 which13 the13 profile13 fields13 must13 appearndash Non-shy‐fixed13 order13 easier13 extensible
bull Inheritance13 of13 a13 profile13 descriponbull Extend13 usage13 to13 signal13 the13 client13 profilebull Integraon13 with13 link13 format
Thank13 youQuesons
drar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval-shy‐00
Bert13 Greevenbosch
Descripon
bull The13 ldquoMinimumRequestInterval13 opon13 can13 be13 used13 to13 indicate13 the13 minimum13 me13 between13 two13 requests13 in13 a13 transacon
bull Originally13 intended13 for13 Block13 but13 also13 usable13 for13 other13 transaconsndash Example13 browsing13 a13 server
bull The13 goal13 is13 to13 reduce13 the13 server13 load13 and13 network13 traffic
bull Link13 hqpsdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval
Usage
bull The13 client13 keeps13 the13 server13 informed13 about13 its13 request13 speed13 through13 inclusion13 of13 the13 ldquoMinimumRequestIntervalrdquo13 opon
bull In13 responses13 the13 server13 fixes13 the13 minimum13 request13 interval13 through13 the13 same13 opon
bull The13 client13 obeys13 the13 speed13 indicated13 by13 the13 server
bull The13 client13 can13 send13 slower13 but13 not13 faster
Advantages
bull The13 server13 has13 means13 to13 limit13 the13 amount13 of13 incoming13 traffic
bull The13 server13 can13 prevent13 to13 become13 overloaded13 with13 too13 many13 tasks
bull The13 server13 does13 not13 need13 arficially13 slow13 down13 the13 client13 by13 sending13 late13 ACKsndash No13 need13 to13 keep13 track13 of13 delayed13 ACKsndash The13 server13 can13 perform13 other13 tasks13 instead
bull Reduced13 network13 traffic
Thank13 youQuesons
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-links-json-02txt
123
RFC 6690 (link-format) documents are somewhat foreign to many web app developerssect would prefer to have them in JSON format
There is no standard way to represent link-format documents in applicationssect but everyone knows how to handle JSON
Define a standard JSON translation for link-format
Itrsquos
not
rock
et
scien
ce
ltsensorsgtct=40title=Sensor Index ltsensorstempgtrt=temperature-cif=sensor ltsensorslightgtrt=light-luxif=sensor lthttpwwwexamplecomsensorst123gt anchor=sensorstemprel=describedby lttgtanchor=sensorstemprel=alternate [hrefsensorsct40titleSensor Index hrefsensorstemprttemperature-cifsensor hrefsensorslightrtlight-luxifsensor hrefhttpwwwexamplecomsensorst123 anchorsensorstempreldescribedby hreftanchorsensorstemprelalternate]
124
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-ipsec-for-coap-00txt
IPsec definitions for CoAP Mostly placeholder at this time Who has implementation experience with this
125
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-cross-reverse-convention-00txt
This draft has two lines of payload(based on a WGLC comment by Cullen Jennings)
coap12344567foobara=3
httpwwwproxycomwellknowncore-translate1234_4567foobara=3
Is that a useful convention to have
126
Insert CI slides here
127
128
0
5
10
15
20
25
30
35
40
10 20 30 40 50 60 70
good
put (
pps)
pps
Goodput vs pps (Econotags)
goodput
[Khattak preliminary]
Congestion Control
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-cocoa-00txt
ldquoadvancedrdquo cc (The draft is just a first shot) Others may have better ideas
129
Insert post-WGLC discussion slides here
130
Stop Continue Start
131
An Agile Retrospective
http6lowappnet coreIETF86 2013-03-12-13
Stop
132
Endless new CoAP optionssect instead use RESTful as much as possible
Move general security lifecycle out Looking at theoretical problems
http6lowappnet coreIETF86 2013-03-12-13
Continue
Interops Running code Look at real-world examples and deployments Solve their actual problems
sect Unilateral enhancements eg higher performance congestion control
sect Transports (SMS hellip)sect Make Web linking and Directories more and more usefulsect RESTful Design Paradigms for real-world problems
133
http6lowappnet coreIETF86 2013-03-12-13
Start
Further push into the (browser) web world (HTML5 browser security)
Specific supporting worksect SenMLsect URI work (dev URN hellip)sect Security Processes (next slide)
Spin outsect (We donrsquot really get to decide where this is done)
134
http6lowappnet coreIETF86 2013-03-12-13
Security
Integrate Application Network Group Keyingsect Tunnel-free setup
Donrsquot redo what has been done alreadysect ZigBee IP is finesect But what about other scenarios
Simple REST interfaces for working with keying materials and authorizationsect Start with defining objectives
Object Security for Constrained Nodes135
Re-chartering CoREWhat do we want to do now that wersquore grown up
Zach ShelbyCoRE WG IETF-86 Orlando
What is the scope
bull So we have a protocol and Web Linking what next
bull Keep with what we know besthellip1 Enhancements around CoAP2 New transports for CoAP3 New representations for Web Links4 General application layer solutions
CoRE WG IETF-86 Orlando 2
Enhancements around CoAP
bull Advanced congestion control
CoRE WG IETF-86 Orlando 3
New Transports for CoAP
bull Infrastructure for CoAP over foondash httptoolsietforgiddraft-silverajan-core-
coap-alternative-transports-01txtbull CoAP over SMS
ndash httptoolsietforgiddraft-becker-core-coap-sms-gprs-03txt
ndash OMA Lightweightbull CoAP over TCP
ndash httptoolsietforgiddraft-li-core-coap-payload-length-option-01txt
CoRE WG IETF-86 Orlando 4
New support for Web Links
bull JSON Web Linksndash httptoolsietforgiddraft-bormann-core-links-
json-02txt
2332010 CoRE WG IETF-77 Anaheim 5
General application layer solutions
bull Resource Directoryndash httptoolsietforgiddraft-shelby-core-
resource-directory-05txtndash OMA Lightweight
2332010 CoRE WG IETF-77 Anaheim 6
031113
Points13 to13 consider
bull Requirements13 for13 transport13 layer13 protocol13 to13 carry13 CoAP13 packets
bull Representaon13 of13 URI13 scheme13 for13 generic13 transport13 protocols
bull Opon13 extensions13 for13 CoAP13 to13 express13 available13 transports
bull Mapping13 and13 message13 sizebull Security13 consideraons
56
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
URI13 =13 scheme13 13 13 authority13 path-shy‐abempty13 [13 query13 ]
bull Within13 the13 scheme13 namebull In13 the13 URI13 pathbull As13 a13 query13 component
57
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
bull Within13 the13 scheme13 namendash coap+tel+15105550101well-shy‐knowncorendash coap+tcpexamplecom5683temperaturendash coap+blel2cap[1234567890AB]4pulse
bull Easy13 URI13 parsing13 for13 transport13 type13 and13 idenfier
bull Each13 new13 scheme13 name13 requires13 IANA13 registraon
58
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
bull In13 the13 URI13 pathndash coaphostexamplecomtransport=tcpwell-shy‐knowncorert=core-shy‐rd
bull Easy13 adopon13 of13 new13 (and13 experimental)13 CoAP13 transports13 without13 IANA13 registraon
bull Caveat13 Uri-shy‐Path13 opon13 is13 a13 Crical13 CoAP13 opon13 see13 secon13 54113 of13 I-shy‐Diep-shy‐core-shy‐coap
59
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
bull As13 a13 URI13 query13 componentndash coaphostexamplecomwell-shy‐knowncorert=core-shy‐rdq=tcp
bull Also13 easy13 to13 adopt13 new13 (and13 experimental)13 CoAP13 transports13 without13 IANA13 registraon
bull Caveat13 Uri-shy‐Query13 opon13 is13 a13 Crical13 CoAP13 opon13 see13 secon13 54113 of13 I-shy‐Diep-shy‐core-shy‐coap
60
031113
URI13 Representaons13 for13 CoAPNon13 standard13 ways
bull Transport13 in13 the13 URI13 authority13 componentndash coaphost[port][transport]13 instead13 of13 coaphost[port]
bull Transport13 as13 a13 service13 URLndash servicecoaptcphostexamplecomwell-shy‐knowncorert=core-shy‐rd
bull Above13 two13 ways13 break13 exisng13 compability13 (although13 both13 are13 based13 on13 valid13 IANA13 URI13 registraons)
61
031113
URI13 Representaons13 for13 CoAPMiscellaneous13 Consideraons
bull Ensure13 that13 transport13 is13 defined13 unambiguously13 (eg13 L2CAP13 used13 by13 both13 BLE13 and13 standard13 Bluetooth13 so13 avoid13 rdquocoap+l2caprdquo13 or13 rdquotransport=l2caprdquo13 or13 rdquoq=l2caprdquondash Can13 be13 done13 as13 WG13 consensusndash Namespace13 approach13 eg13 rdquocoap+blel2caprdquo13 or13 rdquoq=blel2caprdquo
bull Allow13 end-shy‐points13 to13 use13 CoAP13 Resource13 Directory13 to13 register13 alternave13 transports13 and13 idenfiers13 and13 provide13 periodic13 updatesndash Register13 rdquocore-shy‐transportrdquo13 resource13 type
62
031113
Transport13 Consideraons
bull Uniqueness13 of13 end-shy‐point13 idenficaonbull Communicaon13 support13 Unidireconal13 Bidireconal13 1N13 (broadcast13 mulcast13 anycast)13 messaging
bull Binary13 encoding13 Network13 byte13 orderingbull MTU13 correlaon13 with13 CoAP13 PDU13 sizebull Transport13 latency
63
031113
Security13 Consideraons
bull Drar13 does13 not13 introduce13 new13 security13 requirements13 by13 itself
bull There13 may13 be13 privacy13 issues13 if13 nodes13 use13 telephone13 numbers13 or13 MAC13 addresses13 as13 public13 end13 point13 idenfiers
64
Akbar Rahman
IETF 86 March 2013 httpwwwietforgiddraft-rahman-core-sleepy-02txt
Enhanced Sleepy Node Support for CoAP
Introduction
It is expected that in CoAP networks there will be a certain portion of devices that are sleepy and which may occasionally go into a sleep mode (ie go into a low power state to conserve power) and subsequently have reduced CoAP protocol communication ability
This I-D proposes a minimal and efficient mechanism building on the Resource Directory concept (which will be integrated into a CoAP Proxy) to enhance sleepy node support in CoAP networks
Main Question from IETF-85 (Atlanta)
What performance benefit does the proposed Sleepy Node support solution give in a network that already has standard CoAP caching enabled
Sleepy Node Performance Analysis
Experimental Network
1-5 clients
Both Sleepy and Non-
Sleepy servers
Sleepy Node Performance Analysis Network Setup
CoAPSleepyServer(s)
CoAPSleepAwareReverseProxy
CoAP
Client(s)
Request
Response
Sleep9AwareCoREResourceDirectoryCapability
PublishedSleepParameters
Sleep9AwareCoAPStoreandForwardCapability Response
Request
SleepAwareCoAP503ResponseCapability
CoAPCachingCapability
bull Server supports publishing sleep parameters to proxy bull Eg Irsquom going to be asleep for X seconds
bull Proxy supports sleep-awareness capabilities bull Proxy also supports caching capability based off of maxAge bull Protocol flow similar to approach of Figure 1 (Synchronous RD Based Sleep
Tracking) of I-D
Proxy capabilities can be selectively enableddisabled
Proxy ndash Server Interface
Client ndash Proxy Interface
CoAP Sleep-Aware Reverse Proxy Features CoRE Sleep-aware Resource Directory
Support storing published sleep parameters from CoAP servers sleepState (AWAKE ASLEEP) sleepDuration
Sleep-aware CoAP 503 Response Capability If CoAP request to a sleeping server is received proxy returns a
lsquo503 Retry-Afterrsquo response to client 503 contains a timestamp indicating when the sever will wake back up
(timestamp delivered in CoAP maxAge option) Sleep-aware CoAP Store-and-Forward Capability
If CoAP request to a sleeping server is received proxy stores request until server wakes up and then forwards it
Caching capability Cache GET responses from server if maxAge option is present
(this is not a sleep aware feature)
Goals of Performance Analysis
For networks having sleepy servers provide measurements to quantify the impact that CoAP sleep-awareness capabilities can have
See if sleep-awareness capabilities can
provide additional benefits even when CoAP caching is used
Overview of Performance Analysis Performed The analysis was broken up into a set of test scenarios Each test scenario used a different combination of the following
variables Client issued GET requests Server was configured as a sleepy or non-sleepy server Proxy caching of GET responses was enabled or disabled Proxy sleep-aware 503 response capability was enabled or disabled Proxy store-and-forward capability was enabled or disabled maxAge in GET responses ndash Two values were tested 60sec and 5sec of Clients ndash Two values were used ndash 1 client and 5 clients
For comparison purposes the following were held constant across all test scenarios Client issued a fixed number of requests (100) across all test scenarios Client used a delay between each GET request (35sec) to better exercise
proxyrsquos caching and sleep-awareness capabilities For sleepy server test scenarios the server slept 60 sec awake for 3 sec
Format of Results The following results were collected for each
test scenario
Breakdown of the and types of transactions occurring between clientproxyserver
ldquoGETrdquo ndash Test Scenario Results
GET ndash Description of Test Scenarios
TestScenarios-GET
Scenario
CoAPSleepyServerSe7ngs CoAPSleepAwareReverseProxySe7ngs CoAPClientSe7ngs
SleepDuragton(sec)
AwakeDuragton(sec)
maxAge(sec) Caching SleepAwareSAF+
503NumberofClients
NumberofGETs
DelayBetweenClient
Requests(sec)
1a 0 Always 60 Enabled Disabled 1 100 35
1b 60 3 60 Enabled Disabled 1 100 35
1c 60 3 60 Enabled Enabled 1 100 35
2a 0 Always 60 Enabled Disabled 5 100 35
2b 60 3 60 Enabled Disabled 5 100 35
2c 60 3 60 Enabled Enabled 5 100 35
3a 0 Always 5 Enabled Disabled 5 100 35
3b 60 3 5 Enabled Disabled 5 100 35
3c 60 3 5 Enabled Enabled 5 100 35
ldquoGETrdquo ndash Test Scenario 1 Results
maxAge = 60 and 1 Client
GET ndash Scenario 1 ClientProxy Interface Transaction Mix
Scenarios 1a - Non-Sleepy Server Caching Proxy maxAge = 60sec 1b- Sleepy Server Caching Proxy maxAge = 60sec 1c - Sleepy Server Sleep Aware Proxy maxAge = 60sec
Sleep Aware Proxy has better performance for sleepy servers
0
100
200
300
400
500
600
700
1a 1b 1c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
GET ndash Scenario 1 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
Scenarios 1a - Non-Sleepy Server Caching Proxy maxAge = 60sec 1b- Sleepy Server Caching Proxy maxAge = 60sec 1c - Sleepy Server Sleep Aware Proxy maxAge = 60sec
0
100
200
300
400
500
600
700
800
1a 1b 1c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
ldquoGETrdquo ndash Test Scenario 2 Results
maxAge = 60 and 5 Clients
GET ndash Scenario 2 ClientProxy Interface Transaction Mix
Sleep Aware Proxy has slightly better performance for sleepy servers
0
200
400
600
800
1000
1200
1400
2a 2b 2c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
Scenarios 2a - Non-Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2b- Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2c - Sleepy Server Sleep Aware Proxy maxAge = 60sec 5 Clients
See ldquoExperimental Artifactsrdquo Note 1
GET ndash Scenario 2 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has slightly better performance for sleepy servers
0
50
100
150
200
250
300
350
400
2a 2b 2c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
Scenarios 2a - Non-Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2b- Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2c - Sleepy Server Sleep Aware Proxy maxAge = 60sec 5 Clients
See ldquoExperimental Artifactsrdquo Note 2
Experimental Artifacts Note 1
Currently in the experiment the sleep aware proxy checks the cached state of a resource before putting a request into its Store-and-forward queue while a server is sleeping Once in the queue the proxy unconditionally forwards the queued requests to the server once it wakes up This is not the most efficient setup and can easily be improved If the proxy instead checks its cache again before forwarding each queued request it may not need to forward the request to the server For example if there are two queued GET requests in the proxyrsquos queue that address the same resource Only the first request needs to be sent to the server the second request can use the cached response from the first request
Note 2 Currently in the experiment the sleepy server sends a sleepState PUT request to the
proxy each time it goes to sleep This is not the most efficient setup and can easily be improved For example if the server assumes that the proxy can keep track of its ONOFF cycles with its internal timers (eg as per Fig 1 of I-D) then the number of messages from the sleepy server dramatically goes down
ldquoGETrdquo ndash Test Scenario 3 Results
maxAge = 5 and 5 Clients
GET ndash Scenario 3 ClientProxy Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
Scenarios 3a - Non-Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3b- Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3c - Sleepy Server Sleep Aware Proxy maxAge = 5sec 5 Clients
0
500
1000
1500
2000
2500
3000
3500
4000
4500
5000
3a 3b 3c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
GET ndash Scenario 3 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
0
1000
2000
3000
4000
5000
6000
7000
3a 3b 3c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
Scenarios 3a - Non-Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3b- Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3c - Sleepy Server Sleep Aware Proxy maxAge = 5sec 5 Clients
Conclusions
Conclusions These results show that sleep-aware CoAP
proxy features can significantly optimize communication with sleepy servers in most scenarios
These results also show that sleep-
awareness capabilities can provide additional benefits above and beyond CoAP caching in most scenarios
Backup
Current CoAP Support of Sleepy Node (12)
CoAP proxies can use a previously cached response to service a new GET request for a sleepy origin server (as in HTTP) But if no valid cache then proxy has to attempt to
retrieve and may fail if origin server is sleeping [I-Dietf-core-coap]
Clients can discover list of resources from RD (GET rd-lookuphellip) for sleepy servers But attempt to GET resource from sleepy origin server
may fail if origin server is sleeping [IDietf-core-link-format amp IDshelby-core-resource-
directory]
Current CoAP Support of Sleepy Node (22)
Lower layer support for sleepy nodes in most wireless technologies (eg WiFi ZigBee) But limited to MAC packet scheduling for sleepy nodes
and not aware of specific needs of IP applications (like CoAP)
Proposal ndash RD Based Sleep Tracking (14)
The current CoAP approach to support sleepy nodes can be significantly improved by introducing RD based mechanisms for a CoAP client to determine whether A targeted resource is located on a sleepy server A sleepy server is currently in sleep mode or not
There is any associated caching Proxy (possibly the RD itself) for a sleepy server
Proposal ndash RD Based Sleep Tracking (24)
We define the following new RD attributes to characterize the properties of a sleepy node SleepState - Indicates whether the node is currently in
sleep mode or not (ie Sleeping or Awake) SleepDuration - Indicates the maximum duration of time
that the node stays in sleep mode TimeSleeping - Indicates the length of time the node
has been sleeping (ie if Sleep State = Sleeping) NextSleep - Indicates the next time the node will go to
sleep (ie if Sleep State = Awake)
CachingProxy ndash Indicates the caching proxy of the sleepy node (ie the RD itself or another node)
Proposal ndash RD Based Sleep Tracking (34)
These attributes are all server (node) level and are new parameters added to the RD URI Template Variables
Finally we also define a new lookup-type (ss) for the RD lookup interface specified in [I-Dshelby-core-resource-directory] This new lookup-type supports looking up the
ldquoSleepStaterdquo (ss) of a specified end-point
Proposal ndash RD Based Sleep Tracking (44)
The three time based parameters (SleepDuration TimeSleeping NextSleep) can be based on either an absolute network time (for a time synchronized network) or a relative local time (measured at the local node)
Following the approach of [I-Dietf-core-link-format] and [I-Dshelby-core-resource-directory] sleep parameters for sleepy servers can be stored by the server in the RD and accessed by all interested clients
Examples of using these parameters in a synchronous or asynchronous manner are shown in the I-D
http6lowappnet coreIETF86 2013-03-12-13
We assume people have read the drafts
Meetings serve to advance difficult issues by making good use of face-to-face communications
Note Well Be aware of the IPR principles according to RFC 3979 and its updates
uumlBlue sheetsuumlScribe(s)
96
drar-shy‐iep-shy‐core-shy‐coapsubmiqed13 to13 IESG
2013-shy‐03-shy‐13
97
OMA Lightweight M2M Overview(A new standard using lots of IETF specs including DTLS
CoAP Block Observe Resource Directory SenMLhellip)
Zach ShelbyCoRE WG IETF-86 Orlando
OMA Lightweight M2Mbull Open Mobile Alliance is well known for Device Management (DM)bull OMA Lightweight M2M is a new standard from the alliance
ndash Focused on constrained Cellular and sensor network M2M devicesndash Driven by leading operators and vendors
bull Scopendash Interfaces protocol amp security between Device and Serverndash Object and Resource modelndash Bootstrap Device Access Control Connectivity and Firmware Objects
bull Draft Specifications are availablendash httpmemberopenmobileallianceorgftpPublic_documentsDM
LightweightM2MPermanent_documentsOMA-TS-LightweightM2M-V1_0_0-20130301-Dzip
bull Timelinendash Requirements and Architecture completed 3Q2012ndash Spec ready for Consistency Review 2Q2013ndash Candidate Approval expected 3Q2013
2 CoRE WG IETF-86 Orlando
Architecture
3
Scope of LWM2M
CoRE WG IETF-86 Orlando
Object Model
bull A Client has one or more Object Instancesbull An Object is a collection of Resourcesbull A Resource is an atomic piece of information
ndash Read Written or Executed
bull Resources can have multiple instancesbull Objects and Resources are identified by a
16-bit Integer Instances by an 8-bit Integerbull ObjectsResources are accessed with
simple URIs Object IDObject InstanceResource ID
eg 1213
4 CoRE WG IETF-86 Orlando
CoRE WG IETF-86 Orlando
CoRE Resource Directory
draft-shelby-core-resource-directory-05
Z Shelby C Bormann S Krco
Backgroundbull Not a new concept
ndash think web search engine or any link directorybull Defines the interfaces to a Resource Directorybull Based on Web Linking framework and the CoRE Link Formatbull Generic REST design for use over HTTP and CoAPbull Used by OMA Lightweight M2Mbull Has already been deployed
ndash In traffic monitoring systemsndash In street lighting systemsndash For vehicular asset trackingndash By a major Cellular M2M operator
Changes since -04
bull Restricted Update to parameter updatesbull Added pagination support for the Lookup interfacebull Changed rt= to et= for the registration amp update
interfacebull Added group support
Group Management
bull RD now includes group management featuresbull New Group Function Set
ndash Register a groupbull Group name domain multicast address endpoint members
ndash Remove a groupbull Group lookup using the Lookup Function Set
ndash List registered groupsndash Find the members of a groupndash Find groups with certain endpoints or resources
Registering a Group
EP RD
| |
| - POST rd-groupgp=lights ltgtep=node1 --gt |
| |
| |
| lt---- 201 Created Location rd-group12 ---- |
| |
Req POST coaprdexamplecomrd-groupgp=lights
Payload
ltgtep=node1
ltgtep=node2
Res 201 Created
Location rd-group12
Looking up Group Members
Client RD
| |
| ----- GET rd-lookupepgp=lights1 ----------------------gt |
| |
| |
| lt-- 205 Content ltrdgtd=domain1ltrdgtd=domain2 --------- |
| |
Req GET rd-lookupepgp=lights1
Res 205 Content
ltcoaphostportgtep=node1
ltcoaphostportgtep=node2rdquo
Things for the futurebull Support for JSON representation of Web Links
ndash httptoolsietforgiddraft-bormann-core-links-json-02txtbull Registry for RD registration query parameters
ndash Already OMA Lightweight has defined some new onesbull More examples
Group 3 ldquonew workrdquo(continued)
109
drar-shy‐greevenbosch-shy‐core-shy‐profile-shy‐descripon-shy‐01Bert13 GreevenboschJeroen13 Hoebeke
Isam13 IshaqFloris13 Van13 den13 Abeele
Descripon
bull JSON13 format13 for13 signalling13 the13 servers13 capabilies
bull Signalling13 of13 supported13 opons13 media13 types13 and13 block13 sizendash Other13 items13 can13 be13 added
bull Filtering13 on13 specific13 fields13 through13 URI-shy‐Querybull Link13 hqpdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐profile-shy‐descripon
well-shy‐knownprofile
bull To13 acquire13 profile13 data13 of13 resources13 on13 a13 parcular13 service13 the13 well-shy‐knownprofile13 URI-shy‐path13 is13 introduced
bull For13 example13 to13 get13 all13 informaon13 from13 sensors13 served13 by13 wwwexampleorg13 we13 can13 do13 a13 GET13 to13 coapwwwexampleorgwell-shy‐knownprofile
bull Filtering13 on13 parcular13 resources13 is13 done13 through13 URI-shy‐Queries
Format
bull Currently13 the13 following13 fields13 are13 definedndash ldquopathrdquo13 contains13 the13 URI-shy‐path13 associated13 with13 a13 resource
ndash ldquooprdquo13 a13 numerical13 list13 of13 supported13 opon13 numbers
ndash ldquocfrdquo13 a13 numerical13 list13 of13 supported13 content-shy‐format13 numbers
ndash ldquob1srdquo13 ldquob2srdquo13 supported13 block13 sizes13 for13 Block113 and13 Block213 respecvely
Examplebull On13 the13 right13 is13 an13 example13 of13 a13 camera13 sensor13 at13 coapwwwexampleorgcam13 that13 supports13 the13 Uri-shy‐Host13 (3)13 ETag13 (4)13 Uri-shy‐Port13 (7)13 Uri-shy‐Path13 (11)13 Content-shy‐Format13 (12)13 Token13 (19)13 Block213 (23)13 and13 Proxy-shy‐Uri13 (35)13 opons
bull The13 supported13 content13 formats13 are13 textplain13 (0)13 applicaon13 link-shy‐format13 (40)13 and13 applicaonjson13 (50)
bull The13 supported13 Block213 can13 use13 25613 or13 51213 byte13 blocks
Req13 GET13 coapwwwexampleorgwell-shy‐knownprofile13 Res13 20513 Content13 (applicationjson)13 13 13 13 profile13 13 13 13 13 13 13 13 pathcam13 13 13 13 op[3471112192335]13 13 13 13 13 cf[04050]13 13 13 13 13 b2s[45]13 13 13 13
Filtering13 through13 use13 of13 URI-shy‐Query
bull Filtering13 can13 be13 done13 through13 the13 URI-shy‐Querybull Query13 format13 N=V
ndash N13 is13 a13 profile13 fieldndash V13 is13 the13 desired13 value
bull Examplesndash To13 find13 resources13 that13 support13 content13 format13 ldquoapplicaonjsonrdquo
13 GET13 wwwexampleorgwell-shy‐knownprofilecf=50ndash To13 get13 informaon13 about13 the13 camera
13 GET13 wwwexampleorgwell-shy‐knownprofilepath=cam
Open13 issues
bull Which13 other13 profile13 data13 needs13 signallingndash Content-shy‐type13 for13 different13 methods
bull Fix13 the13 order13 in13 which13 the13 profile13 fields13 must13 appearndash Non-shy‐fixed13 order13 easier13 extensible
bull Inheritance13 of13 a13 profile13 descriponbull Extend13 usage13 to13 signal13 the13 client13 profilebull Integraon13 with13 link13 format
Thank13 youQuesons
drar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval-shy‐00
Bert13 Greevenbosch
Descripon
bull The13 ldquoMinimumRequestInterval13 opon13 can13 be13 used13 to13 indicate13 the13 minimum13 me13 between13 two13 requests13 in13 a13 transacon
bull Originally13 intended13 for13 Block13 but13 also13 usable13 for13 other13 transaconsndash Example13 browsing13 a13 server
bull The13 goal13 is13 to13 reduce13 the13 server13 load13 and13 network13 traffic
bull Link13 hqpsdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval
Usage
bull The13 client13 keeps13 the13 server13 informed13 about13 its13 request13 speed13 through13 inclusion13 of13 the13 ldquoMinimumRequestIntervalrdquo13 opon
bull In13 responses13 the13 server13 fixes13 the13 minimum13 request13 interval13 through13 the13 same13 opon
bull The13 client13 obeys13 the13 speed13 indicated13 by13 the13 server
bull The13 client13 can13 send13 slower13 but13 not13 faster
Advantages
bull The13 server13 has13 means13 to13 limit13 the13 amount13 of13 incoming13 traffic
bull The13 server13 can13 prevent13 to13 become13 overloaded13 with13 too13 many13 tasks
bull The13 server13 does13 not13 need13 arficially13 slow13 down13 the13 client13 by13 sending13 late13 ACKsndash No13 need13 to13 keep13 track13 of13 delayed13 ACKsndash The13 server13 can13 perform13 other13 tasks13 instead
bull Reduced13 network13 traffic
Thank13 youQuesons
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-links-json-02txt
123
RFC 6690 (link-format) documents are somewhat foreign to many web app developerssect would prefer to have them in JSON format
There is no standard way to represent link-format documents in applicationssect but everyone knows how to handle JSON
Define a standard JSON translation for link-format
Itrsquos
not
rock
et
scien
ce
ltsensorsgtct=40title=Sensor Index ltsensorstempgtrt=temperature-cif=sensor ltsensorslightgtrt=light-luxif=sensor lthttpwwwexamplecomsensorst123gt anchor=sensorstemprel=describedby lttgtanchor=sensorstemprel=alternate [hrefsensorsct40titleSensor Index hrefsensorstemprttemperature-cifsensor hrefsensorslightrtlight-luxifsensor hrefhttpwwwexamplecomsensorst123 anchorsensorstempreldescribedby hreftanchorsensorstemprelalternate]
124
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-ipsec-for-coap-00txt
IPsec definitions for CoAP Mostly placeholder at this time Who has implementation experience with this
125
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-cross-reverse-convention-00txt
This draft has two lines of payload(based on a WGLC comment by Cullen Jennings)
coap12344567foobara=3
httpwwwproxycomwellknowncore-translate1234_4567foobara=3
Is that a useful convention to have
126
Insert CI slides here
127
128
0
5
10
15
20
25
30
35
40
10 20 30 40 50 60 70
good
put (
pps)
pps
Goodput vs pps (Econotags)
goodput
[Khattak preliminary]
Congestion Control
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-cocoa-00txt
ldquoadvancedrdquo cc (The draft is just a first shot) Others may have better ideas
129
Insert post-WGLC discussion slides here
130
Stop Continue Start
131
An Agile Retrospective
http6lowappnet coreIETF86 2013-03-12-13
Stop
132
Endless new CoAP optionssect instead use RESTful as much as possible
Move general security lifecycle out Looking at theoretical problems
http6lowappnet coreIETF86 2013-03-12-13
Continue
Interops Running code Look at real-world examples and deployments Solve their actual problems
sect Unilateral enhancements eg higher performance congestion control
sect Transports (SMS hellip)sect Make Web linking and Directories more and more usefulsect RESTful Design Paradigms for real-world problems
133
http6lowappnet coreIETF86 2013-03-12-13
Start
Further push into the (browser) web world (HTML5 browser security)
Specific supporting worksect SenMLsect URI work (dev URN hellip)sect Security Processes (next slide)
Spin outsect (We donrsquot really get to decide where this is done)
134
http6lowappnet coreIETF86 2013-03-12-13
Security
Integrate Application Network Group Keyingsect Tunnel-free setup
Donrsquot redo what has been done alreadysect ZigBee IP is finesect But what about other scenarios
Simple REST interfaces for working with keying materials and authorizationsect Start with defining objectives
Object Security for Constrained Nodes135
Re-chartering CoREWhat do we want to do now that wersquore grown up
Zach ShelbyCoRE WG IETF-86 Orlando
What is the scope
bull So we have a protocol and Web Linking what next
bull Keep with what we know besthellip1 Enhancements around CoAP2 New transports for CoAP3 New representations for Web Links4 General application layer solutions
CoRE WG IETF-86 Orlando 2
Enhancements around CoAP
bull Advanced congestion control
CoRE WG IETF-86 Orlando 3
New Transports for CoAP
bull Infrastructure for CoAP over foondash httptoolsietforgiddraft-silverajan-core-
coap-alternative-transports-01txtbull CoAP over SMS
ndash httptoolsietforgiddraft-becker-core-coap-sms-gprs-03txt
ndash OMA Lightweightbull CoAP over TCP
ndash httptoolsietforgiddraft-li-core-coap-payload-length-option-01txt
CoRE WG IETF-86 Orlando 4
New support for Web Links
bull JSON Web Linksndash httptoolsietforgiddraft-bormann-core-links-
json-02txt
2332010 CoRE WG IETF-77 Anaheim 5
General application layer solutions
bull Resource Directoryndash httptoolsietforgiddraft-shelby-core-
resource-directory-05txtndash OMA Lightweight
2332010 CoRE WG IETF-77 Anaheim 6
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
URI13 =13 scheme13 13 13 authority13 path-shy‐abempty13 [13 query13 ]
bull Within13 the13 scheme13 namebull In13 the13 URI13 pathbull As13 a13 query13 component
57
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
bull Within13 the13 scheme13 namendash coap+tel+15105550101well-shy‐knowncorendash coap+tcpexamplecom5683temperaturendash coap+blel2cap[1234567890AB]4pulse
bull Easy13 URI13 parsing13 for13 transport13 type13 and13 idenfier
bull Each13 new13 scheme13 name13 requires13 IANA13 registraon
58
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
bull In13 the13 URI13 pathndash coaphostexamplecomtransport=tcpwell-shy‐knowncorert=core-shy‐rd
bull Easy13 adopon13 of13 new13 (and13 experimental)13 CoAP13 transports13 without13 IANA13 registraon
bull Caveat13 Uri-shy‐Path13 opon13 is13 a13 Crical13 CoAP13 opon13 see13 secon13 54113 of13 I-shy‐Diep-shy‐core-shy‐coap
59
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
bull As13 a13 URI13 query13 componentndash coaphostexamplecomwell-shy‐knowncorert=core-shy‐rdq=tcp
bull Also13 easy13 to13 adopt13 new13 (and13 experimental)13 CoAP13 transports13 without13 IANA13 registraon
bull Caveat13 Uri-shy‐Query13 opon13 is13 a13 Crical13 CoAP13 opon13 see13 secon13 54113 of13 I-shy‐Diep-shy‐core-shy‐coap
60
031113
URI13 Representaons13 for13 CoAPNon13 standard13 ways
bull Transport13 in13 the13 URI13 authority13 componentndash coaphost[port][transport]13 instead13 of13 coaphost[port]
bull Transport13 as13 a13 service13 URLndash servicecoaptcphostexamplecomwell-shy‐knowncorert=core-shy‐rd
bull Above13 two13 ways13 break13 exisng13 compability13 (although13 both13 are13 based13 on13 valid13 IANA13 URI13 registraons)
61
031113
URI13 Representaons13 for13 CoAPMiscellaneous13 Consideraons
bull Ensure13 that13 transport13 is13 defined13 unambiguously13 (eg13 L2CAP13 used13 by13 both13 BLE13 and13 standard13 Bluetooth13 so13 avoid13 rdquocoap+l2caprdquo13 or13 rdquotransport=l2caprdquo13 or13 rdquoq=l2caprdquondash Can13 be13 done13 as13 WG13 consensusndash Namespace13 approach13 eg13 rdquocoap+blel2caprdquo13 or13 rdquoq=blel2caprdquo
bull Allow13 end-shy‐points13 to13 use13 CoAP13 Resource13 Directory13 to13 register13 alternave13 transports13 and13 idenfiers13 and13 provide13 periodic13 updatesndash Register13 rdquocore-shy‐transportrdquo13 resource13 type
62
031113
Transport13 Consideraons
bull Uniqueness13 of13 end-shy‐point13 idenficaonbull Communicaon13 support13 Unidireconal13 Bidireconal13 1N13 (broadcast13 mulcast13 anycast)13 messaging
bull Binary13 encoding13 Network13 byte13 orderingbull MTU13 correlaon13 with13 CoAP13 PDU13 sizebull Transport13 latency
63
031113
Security13 Consideraons
bull Drar13 does13 not13 introduce13 new13 security13 requirements13 by13 itself
bull There13 may13 be13 privacy13 issues13 if13 nodes13 use13 telephone13 numbers13 or13 MAC13 addresses13 as13 public13 end13 point13 idenfiers
64
Akbar Rahman
IETF 86 March 2013 httpwwwietforgiddraft-rahman-core-sleepy-02txt
Enhanced Sleepy Node Support for CoAP
Introduction
It is expected that in CoAP networks there will be a certain portion of devices that are sleepy and which may occasionally go into a sleep mode (ie go into a low power state to conserve power) and subsequently have reduced CoAP protocol communication ability
This I-D proposes a minimal and efficient mechanism building on the Resource Directory concept (which will be integrated into a CoAP Proxy) to enhance sleepy node support in CoAP networks
Main Question from IETF-85 (Atlanta)
What performance benefit does the proposed Sleepy Node support solution give in a network that already has standard CoAP caching enabled
Sleepy Node Performance Analysis
Experimental Network
1-5 clients
Both Sleepy and Non-
Sleepy servers
Sleepy Node Performance Analysis Network Setup
CoAPSleepyServer(s)
CoAPSleepAwareReverseProxy
CoAP
Client(s)
Request
Response
Sleep9AwareCoREResourceDirectoryCapability
PublishedSleepParameters
Sleep9AwareCoAPStoreandForwardCapability Response
Request
SleepAwareCoAP503ResponseCapability
CoAPCachingCapability
bull Server supports publishing sleep parameters to proxy bull Eg Irsquom going to be asleep for X seconds
bull Proxy supports sleep-awareness capabilities bull Proxy also supports caching capability based off of maxAge bull Protocol flow similar to approach of Figure 1 (Synchronous RD Based Sleep
Tracking) of I-D
Proxy capabilities can be selectively enableddisabled
Proxy ndash Server Interface
Client ndash Proxy Interface
CoAP Sleep-Aware Reverse Proxy Features CoRE Sleep-aware Resource Directory
Support storing published sleep parameters from CoAP servers sleepState (AWAKE ASLEEP) sleepDuration
Sleep-aware CoAP 503 Response Capability If CoAP request to a sleeping server is received proxy returns a
lsquo503 Retry-Afterrsquo response to client 503 contains a timestamp indicating when the sever will wake back up
(timestamp delivered in CoAP maxAge option) Sleep-aware CoAP Store-and-Forward Capability
If CoAP request to a sleeping server is received proxy stores request until server wakes up and then forwards it
Caching capability Cache GET responses from server if maxAge option is present
(this is not a sleep aware feature)
Goals of Performance Analysis
For networks having sleepy servers provide measurements to quantify the impact that CoAP sleep-awareness capabilities can have
See if sleep-awareness capabilities can
provide additional benefits even when CoAP caching is used
Overview of Performance Analysis Performed The analysis was broken up into a set of test scenarios Each test scenario used a different combination of the following
variables Client issued GET requests Server was configured as a sleepy or non-sleepy server Proxy caching of GET responses was enabled or disabled Proxy sleep-aware 503 response capability was enabled or disabled Proxy store-and-forward capability was enabled or disabled maxAge in GET responses ndash Two values were tested 60sec and 5sec of Clients ndash Two values were used ndash 1 client and 5 clients
For comparison purposes the following were held constant across all test scenarios Client issued a fixed number of requests (100) across all test scenarios Client used a delay between each GET request (35sec) to better exercise
proxyrsquos caching and sleep-awareness capabilities For sleepy server test scenarios the server slept 60 sec awake for 3 sec
Format of Results The following results were collected for each
test scenario
Breakdown of the and types of transactions occurring between clientproxyserver
ldquoGETrdquo ndash Test Scenario Results
GET ndash Description of Test Scenarios
TestScenarios-GET
Scenario
CoAPSleepyServerSe7ngs CoAPSleepAwareReverseProxySe7ngs CoAPClientSe7ngs
SleepDuragton(sec)
AwakeDuragton(sec)
maxAge(sec) Caching SleepAwareSAF+
503NumberofClients
NumberofGETs
DelayBetweenClient
Requests(sec)
1a 0 Always 60 Enabled Disabled 1 100 35
1b 60 3 60 Enabled Disabled 1 100 35
1c 60 3 60 Enabled Enabled 1 100 35
2a 0 Always 60 Enabled Disabled 5 100 35
2b 60 3 60 Enabled Disabled 5 100 35
2c 60 3 60 Enabled Enabled 5 100 35
3a 0 Always 5 Enabled Disabled 5 100 35
3b 60 3 5 Enabled Disabled 5 100 35
3c 60 3 5 Enabled Enabled 5 100 35
ldquoGETrdquo ndash Test Scenario 1 Results
maxAge = 60 and 1 Client
GET ndash Scenario 1 ClientProxy Interface Transaction Mix
Scenarios 1a - Non-Sleepy Server Caching Proxy maxAge = 60sec 1b- Sleepy Server Caching Proxy maxAge = 60sec 1c - Sleepy Server Sleep Aware Proxy maxAge = 60sec
Sleep Aware Proxy has better performance for sleepy servers
0
100
200
300
400
500
600
700
1a 1b 1c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
GET ndash Scenario 1 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
Scenarios 1a - Non-Sleepy Server Caching Proxy maxAge = 60sec 1b- Sleepy Server Caching Proxy maxAge = 60sec 1c - Sleepy Server Sleep Aware Proxy maxAge = 60sec
0
100
200
300
400
500
600
700
800
1a 1b 1c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
ldquoGETrdquo ndash Test Scenario 2 Results
maxAge = 60 and 5 Clients
GET ndash Scenario 2 ClientProxy Interface Transaction Mix
Sleep Aware Proxy has slightly better performance for sleepy servers
0
200
400
600
800
1000
1200
1400
2a 2b 2c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
Scenarios 2a - Non-Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2b- Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2c - Sleepy Server Sleep Aware Proxy maxAge = 60sec 5 Clients
See ldquoExperimental Artifactsrdquo Note 1
GET ndash Scenario 2 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has slightly better performance for sleepy servers
0
50
100
150
200
250
300
350
400
2a 2b 2c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
Scenarios 2a - Non-Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2b- Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2c - Sleepy Server Sleep Aware Proxy maxAge = 60sec 5 Clients
See ldquoExperimental Artifactsrdquo Note 2
Experimental Artifacts Note 1
Currently in the experiment the sleep aware proxy checks the cached state of a resource before putting a request into its Store-and-forward queue while a server is sleeping Once in the queue the proxy unconditionally forwards the queued requests to the server once it wakes up This is not the most efficient setup and can easily be improved If the proxy instead checks its cache again before forwarding each queued request it may not need to forward the request to the server For example if there are two queued GET requests in the proxyrsquos queue that address the same resource Only the first request needs to be sent to the server the second request can use the cached response from the first request
Note 2 Currently in the experiment the sleepy server sends a sleepState PUT request to the
proxy each time it goes to sleep This is not the most efficient setup and can easily be improved For example if the server assumes that the proxy can keep track of its ONOFF cycles with its internal timers (eg as per Fig 1 of I-D) then the number of messages from the sleepy server dramatically goes down
ldquoGETrdquo ndash Test Scenario 3 Results
maxAge = 5 and 5 Clients
GET ndash Scenario 3 ClientProxy Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
Scenarios 3a - Non-Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3b- Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3c - Sleepy Server Sleep Aware Proxy maxAge = 5sec 5 Clients
0
500
1000
1500
2000
2500
3000
3500
4000
4500
5000
3a 3b 3c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
GET ndash Scenario 3 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
0
1000
2000
3000
4000
5000
6000
7000
3a 3b 3c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
Scenarios 3a - Non-Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3b- Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3c - Sleepy Server Sleep Aware Proxy maxAge = 5sec 5 Clients
Conclusions
Conclusions These results show that sleep-aware CoAP
proxy features can significantly optimize communication with sleepy servers in most scenarios
These results also show that sleep-
awareness capabilities can provide additional benefits above and beyond CoAP caching in most scenarios
Backup
Current CoAP Support of Sleepy Node (12)
CoAP proxies can use a previously cached response to service a new GET request for a sleepy origin server (as in HTTP) But if no valid cache then proxy has to attempt to
retrieve and may fail if origin server is sleeping [I-Dietf-core-coap]
Clients can discover list of resources from RD (GET rd-lookuphellip) for sleepy servers But attempt to GET resource from sleepy origin server
may fail if origin server is sleeping [IDietf-core-link-format amp IDshelby-core-resource-
directory]
Current CoAP Support of Sleepy Node (22)
Lower layer support for sleepy nodes in most wireless technologies (eg WiFi ZigBee) But limited to MAC packet scheduling for sleepy nodes
and not aware of specific needs of IP applications (like CoAP)
Proposal ndash RD Based Sleep Tracking (14)
The current CoAP approach to support sleepy nodes can be significantly improved by introducing RD based mechanisms for a CoAP client to determine whether A targeted resource is located on a sleepy server A sleepy server is currently in sleep mode or not
There is any associated caching Proxy (possibly the RD itself) for a sleepy server
Proposal ndash RD Based Sleep Tracking (24)
We define the following new RD attributes to characterize the properties of a sleepy node SleepState - Indicates whether the node is currently in
sleep mode or not (ie Sleeping or Awake) SleepDuration - Indicates the maximum duration of time
that the node stays in sleep mode TimeSleeping - Indicates the length of time the node
has been sleeping (ie if Sleep State = Sleeping) NextSleep - Indicates the next time the node will go to
sleep (ie if Sleep State = Awake)
CachingProxy ndash Indicates the caching proxy of the sleepy node (ie the RD itself or another node)
Proposal ndash RD Based Sleep Tracking (34)
These attributes are all server (node) level and are new parameters added to the RD URI Template Variables
Finally we also define a new lookup-type (ss) for the RD lookup interface specified in [I-Dshelby-core-resource-directory] This new lookup-type supports looking up the
ldquoSleepStaterdquo (ss) of a specified end-point
Proposal ndash RD Based Sleep Tracking (44)
The three time based parameters (SleepDuration TimeSleeping NextSleep) can be based on either an absolute network time (for a time synchronized network) or a relative local time (measured at the local node)
Following the approach of [I-Dietf-core-link-format] and [I-Dshelby-core-resource-directory] sleep parameters for sleepy servers can be stored by the server in the RD and accessed by all interested clients
Examples of using these parameters in a synchronous or asynchronous manner are shown in the I-D
http6lowappnet coreIETF86 2013-03-12-13
We assume people have read the drafts
Meetings serve to advance difficult issues by making good use of face-to-face communications
Note Well Be aware of the IPR principles according to RFC 3979 and its updates
uumlBlue sheetsuumlScribe(s)
96
drar-shy‐iep-shy‐core-shy‐coapsubmiqed13 to13 IESG
2013-shy‐03-shy‐13
97
OMA Lightweight M2M Overview(A new standard using lots of IETF specs including DTLS
CoAP Block Observe Resource Directory SenMLhellip)
Zach ShelbyCoRE WG IETF-86 Orlando
OMA Lightweight M2Mbull Open Mobile Alliance is well known for Device Management (DM)bull OMA Lightweight M2M is a new standard from the alliance
ndash Focused on constrained Cellular and sensor network M2M devicesndash Driven by leading operators and vendors
bull Scopendash Interfaces protocol amp security between Device and Serverndash Object and Resource modelndash Bootstrap Device Access Control Connectivity and Firmware Objects
bull Draft Specifications are availablendash httpmemberopenmobileallianceorgftpPublic_documentsDM
LightweightM2MPermanent_documentsOMA-TS-LightweightM2M-V1_0_0-20130301-Dzip
bull Timelinendash Requirements and Architecture completed 3Q2012ndash Spec ready for Consistency Review 2Q2013ndash Candidate Approval expected 3Q2013
2 CoRE WG IETF-86 Orlando
Architecture
3
Scope of LWM2M
CoRE WG IETF-86 Orlando
Object Model
bull A Client has one or more Object Instancesbull An Object is a collection of Resourcesbull A Resource is an atomic piece of information
ndash Read Written or Executed
bull Resources can have multiple instancesbull Objects and Resources are identified by a
16-bit Integer Instances by an 8-bit Integerbull ObjectsResources are accessed with
simple URIs Object IDObject InstanceResource ID
eg 1213
4 CoRE WG IETF-86 Orlando
CoRE WG IETF-86 Orlando
CoRE Resource Directory
draft-shelby-core-resource-directory-05
Z Shelby C Bormann S Krco
Backgroundbull Not a new concept
ndash think web search engine or any link directorybull Defines the interfaces to a Resource Directorybull Based on Web Linking framework and the CoRE Link Formatbull Generic REST design for use over HTTP and CoAPbull Used by OMA Lightweight M2Mbull Has already been deployed
ndash In traffic monitoring systemsndash In street lighting systemsndash For vehicular asset trackingndash By a major Cellular M2M operator
Changes since -04
bull Restricted Update to parameter updatesbull Added pagination support for the Lookup interfacebull Changed rt= to et= for the registration amp update
interfacebull Added group support
Group Management
bull RD now includes group management featuresbull New Group Function Set
ndash Register a groupbull Group name domain multicast address endpoint members
ndash Remove a groupbull Group lookup using the Lookup Function Set
ndash List registered groupsndash Find the members of a groupndash Find groups with certain endpoints or resources
Registering a Group
EP RD
| |
| - POST rd-groupgp=lights ltgtep=node1 --gt |
| |
| |
| lt---- 201 Created Location rd-group12 ---- |
| |
Req POST coaprdexamplecomrd-groupgp=lights
Payload
ltgtep=node1
ltgtep=node2
Res 201 Created
Location rd-group12
Looking up Group Members
Client RD
| |
| ----- GET rd-lookupepgp=lights1 ----------------------gt |
| |
| |
| lt-- 205 Content ltrdgtd=domain1ltrdgtd=domain2 --------- |
| |
Req GET rd-lookupepgp=lights1
Res 205 Content
ltcoaphostportgtep=node1
ltcoaphostportgtep=node2rdquo
Things for the futurebull Support for JSON representation of Web Links
ndash httptoolsietforgiddraft-bormann-core-links-json-02txtbull Registry for RD registration query parameters
ndash Already OMA Lightweight has defined some new onesbull More examples
Group 3 ldquonew workrdquo(continued)
109
drar-shy‐greevenbosch-shy‐core-shy‐profile-shy‐descripon-shy‐01Bert13 GreevenboschJeroen13 Hoebeke
Isam13 IshaqFloris13 Van13 den13 Abeele
Descripon
bull JSON13 format13 for13 signalling13 the13 servers13 capabilies
bull Signalling13 of13 supported13 opons13 media13 types13 and13 block13 sizendash Other13 items13 can13 be13 added
bull Filtering13 on13 specific13 fields13 through13 URI-shy‐Querybull Link13 hqpdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐profile-shy‐descripon
well-shy‐knownprofile
bull To13 acquire13 profile13 data13 of13 resources13 on13 a13 parcular13 service13 the13 well-shy‐knownprofile13 URI-shy‐path13 is13 introduced
bull For13 example13 to13 get13 all13 informaon13 from13 sensors13 served13 by13 wwwexampleorg13 we13 can13 do13 a13 GET13 to13 coapwwwexampleorgwell-shy‐knownprofile
bull Filtering13 on13 parcular13 resources13 is13 done13 through13 URI-shy‐Queries
Format
bull Currently13 the13 following13 fields13 are13 definedndash ldquopathrdquo13 contains13 the13 URI-shy‐path13 associated13 with13 a13 resource
ndash ldquooprdquo13 a13 numerical13 list13 of13 supported13 opon13 numbers
ndash ldquocfrdquo13 a13 numerical13 list13 of13 supported13 content-shy‐format13 numbers
ndash ldquob1srdquo13 ldquob2srdquo13 supported13 block13 sizes13 for13 Block113 and13 Block213 respecvely
Examplebull On13 the13 right13 is13 an13 example13 of13 a13 camera13 sensor13 at13 coapwwwexampleorgcam13 that13 supports13 the13 Uri-shy‐Host13 (3)13 ETag13 (4)13 Uri-shy‐Port13 (7)13 Uri-shy‐Path13 (11)13 Content-shy‐Format13 (12)13 Token13 (19)13 Block213 (23)13 and13 Proxy-shy‐Uri13 (35)13 opons
bull The13 supported13 content13 formats13 are13 textplain13 (0)13 applicaon13 link-shy‐format13 (40)13 and13 applicaonjson13 (50)
bull The13 supported13 Block213 can13 use13 25613 or13 51213 byte13 blocks
Req13 GET13 coapwwwexampleorgwell-shy‐knownprofile13 Res13 20513 Content13 (applicationjson)13 13 13 13 profile13 13 13 13 13 13 13 13 pathcam13 13 13 13 op[3471112192335]13 13 13 13 13 cf[04050]13 13 13 13 13 b2s[45]13 13 13 13
Filtering13 through13 use13 of13 URI-shy‐Query
bull Filtering13 can13 be13 done13 through13 the13 URI-shy‐Querybull Query13 format13 N=V
ndash N13 is13 a13 profile13 fieldndash V13 is13 the13 desired13 value
bull Examplesndash To13 find13 resources13 that13 support13 content13 format13 ldquoapplicaonjsonrdquo
13 GET13 wwwexampleorgwell-shy‐knownprofilecf=50ndash To13 get13 informaon13 about13 the13 camera
13 GET13 wwwexampleorgwell-shy‐knownprofilepath=cam
Open13 issues
bull Which13 other13 profile13 data13 needs13 signallingndash Content-shy‐type13 for13 different13 methods
bull Fix13 the13 order13 in13 which13 the13 profile13 fields13 must13 appearndash Non-shy‐fixed13 order13 easier13 extensible
bull Inheritance13 of13 a13 profile13 descriponbull Extend13 usage13 to13 signal13 the13 client13 profilebull Integraon13 with13 link13 format
Thank13 youQuesons
drar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval-shy‐00
Bert13 Greevenbosch
Descripon
bull The13 ldquoMinimumRequestInterval13 opon13 can13 be13 used13 to13 indicate13 the13 minimum13 me13 between13 two13 requests13 in13 a13 transacon
bull Originally13 intended13 for13 Block13 but13 also13 usable13 for13 other13 transaconsndash Example13 browsing13 a13 server
bull The13 goal13 is13 to13 reduce13 the13 server13 load13 and13 network13 traffic
bull Link13 hqpsdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval
Usage
bull The13 client13 keeps13 the13 server13 informed13 about13 its13 request13 speed13 through13 inclusion13 of13 the13 ldquoMinimumRequestIntervalrdquo13 opon
bull In13 responses13 the13 server13 fixes13 the13 minimum13 request13 interval13 through13 the13 same13 opon
bull The13 client13 obeys13 the13 speed13 indicated13 by13 the13 server
bull The13 client13 can13 send13 slower13 but13 not13 faster
Advantages
bull The13 server13 has13 means13 to13 limit13 the13 amount13 of13 incoming13 traffic
bull The13 server13 can13 prevent13 to13 become13 overloaded13 with13 too13 many13 tasks
bull The13 server13 does13 not13 need13 arficially13 slow13 down13 the13 client13 by13 sending13 late13 ACKsndash No13 need13 to13 keep13 track13 of13 delayed13 ACKsndash The13 server13 can13 perform13 other13 tasks13 instead
bull Reduced13 network13 traffic
Thank13 youQuesons
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-links-json-02txt
123
RFC 6690 (link-format) documents are somewhat foreign to many web app developerssect would prefer to have them in JSON format
There is no standard way to represent link-format documents in applicationssect but everyone knows how to handle JSON
Define a standard JSON translation for link-format
Itrsquos
not
rock
et
scien
ce
ltsensorsgtct=40title=Sensor Index ltsensorstempgtrt=temperature-cif=sensor ltsensorslightgtrt=light-luxif=sensor lthttpwwwexamplecomsensorst123gt anchor=sensorstemprel=describedby lttgtanchor=sensorstemprel=alternate [hrefsensorsct40titleSensor Index hrefsensorstemprttemperature-cifsensor hrefsensorslightrtlight-luxifsensor hrefhttpwwwexamplecomsensorst123 anchorsensorstempreldescribedby hreftanchorsensorstemprelalternate]
124
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-ipsec-for-coap-00txt
IPsec definitions for CoAP Mostly placeholder at this time Who has implementation experience with this
125
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-cross-reverse-convention-00txt
This draft has two lines of payload(based on a WGLC comment by Cullen Jennings)
coap12344567foobara=3
httpwwwproxycomwellknowncore-translate1234_4567foobara=3
Is that a useful convention to have
126
Insert CI slides here
127
128
0
5
10
15
20
25
30
35
40
10 20 30 40 50 60 70
good
put (
pps)
pps
Goodput vs pps (Econotags)
goodput
[Khattak preliminary]
Congestion Control
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-cocoa-00txt
ldquoadvancedrdquo cc (The draft is just a first shot) Others may have better ideas
129
Insert post-WGLC discussion slides here
130
Stop Continue Start
131
An Agile Retrospective
http6lowappnet coreIETF86 2013-03-12-13
Stop
132
Endless new CoAP optionssect instead use RESTful as much as possible
Move general security lifecycle out Looking at theoretical problems
http6lowappnet coreIETF86 2013-03-12-13
Continue
Interops Running code Look at real-world examples and deployments Solve their actual problems
sect Unilateral enhancements eg higher performance congestion control
sect Transports (SMS hellip)sect Make Web linking and Directories more and more usefulsect RESTful Design Paradigms for real-world problems
133
http6lowappnet coreIETF86 2013-03-12-13
Start
Further push into the (browser) web world (HTML5 browser security)
Specific supporting worksect SenMLsect URI work (dev URN hellip)sect Security Processes (next slide)
Spin outsect (We donrsquot really get to decide where this is done)
134
http6lowappnet coreIETF86 2013-03-12-13
Security
Integrate Application Network Group Keyingsect Tunnel-free setup
Donrsquot redo what has been done alreadysect ZigBee IP is finesect But what about other scenarios
Simple REST interfaces for working with keying materials and authorizationsect Start with defining objectives
Object Security for Constrained Nodes135
Re-chartering CoREWhat do we want to do now that wersquore grown up
Zach ShelbyCoRE WG IETF-86 Orlando
What is the scope
bull So we have a protocol and Web Linking what next
bull Keep with what we know besthellip1 Enhancements around CoAP2 New transports for CoAP3 New representations for Web Links4 General application layer solutions
CoRE WG IETF-86 Orlando 2
Enhancements around CoAP
bull Advanced congestion control
CoRE WG IETF-86 Orlando 3
New Transports for CoAP
bull Infrastructure for CoAP over foondash httptoolsietforgiddraft-silverajan-core-
coap-alternative-transports-01txtbull CoAP over SMS
ndash httptoolsietforgiddraft-becker-core-coap-sms-gprs-03txt
ndash OMA Lightweightbull CoAP over TCP
ndash httptoolsietforgiddraft-li-core-coap-payload-length-option-01txt
CoRE WG IETF-86 Orlando 4
New support for Web Links
bull JSON Web Linksndash httptoolsietforgiddraft-bormann-core-links-
json-02txt
2332010 CoRE WG IETF-77 Anaheim 5
General application layer solutions
bull Resource Directoryndash httptoolsietforgiddraft-shelby-core-
resource-directory-05txtndash OMA Lightweight
2332010 CoRE WG IETF-77 Anaheim 6
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
bull Within13 the13 scheme13 namendash coap+tel+15105550101well-shy‐knowncorendash coap+tcpexamplecom5683temperaturendash coap+blel2cap[1234567890AB]4pulse
bull Easy13 URI13 parsing13 for13 transport13 type13 and13 idenfier
bull Each13 new13 scheme13 name13 requires13 IANA13 registraon
58
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
bull In13 the13 URI13 pathndash coaphostexamplecomtransport=tcpwell-shy‐knowncorert=core-shy‐rd
bull Easy13 adopon13 of13 new13 (and13 experimental)13 CoAP13 transports13 without13 IANA13 registraon
bull Caveat13 Uri-shy‐Path13 opon13 is13 a13 Crical13 CoAP13 opon13 see13 secon13 54113 of13 I-shy‐Diep-shy‐core-shy‐coap
59
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
bull As13 a13 URI13 query13 componentndash coaphostexamplecomwell-shy‐knowncorert=core-shy‐rdq=tcp
bull Also13 easy13 to13 adopt13 new13 (and13 experimental)13 CoAP13 transports13 without13 IANA13 registraon
bull Caveat13 Uri-shy‐Query13 opon13 is13 a13 Crical13 CoAP13 opon13 see13 secon13 54113 of13 I-shy‐Diep-shy‐core-shy‐coap
60
031113
URI13 Representaons13 for13 CoAPNon13 standard13 ways
bull Transport13 in13 the13 URI13 authority13 componentndash coaphost[port][transport]13 instead13 of13 coaphost[port]
bull Transport13 as13 a13 service13 URLndash servicecoaptcphostexamplecomwell-shy‐knowncorert=core-shy‐rd
bull Above13 two13 ways13 break13 exisng13 compability13 (although13 both13 are13 based13 on13 valid13 IANA13 URI13 registraons)
61
031113
URI13 Representaons13 for13 CoAPMiscellaneous13 Consideraons
bull Ensure13 that13 transport13 is13 defined13 unambiguously13 (eg13 L2CAP13 used13 by13 both13 BLE13 and13 standard13 Bluetooth13 so13 avoid13 rdquocoap+l2caprdquo13 or13 rdquotransport=l2caprdquo13 or13 rdquoq=l2caprdquondash Can13 be13 done13 as13 WG13 consensusndash Namespace13 approach13 eg13 rdquocoap+blel2caprdquo13 or13 rdquoq=blel2caprdquo
bull Allow13 end-shy‐points13 to13 use13 CoAP13 Resource13 Directory13 to13 register13 alternave13 transports13 and13 idenfiers13 and13 provide13 periodic13 updatesndash Register13 rdquocore-shy‐transportrdquo13 resource13 type
62
031113
Transport13 Consideraons
bull Uniqueness13 of13 end-shy‐point13 idenficaonbull Communicaon13 support13 Unidireconal13 Bidireconal13 1N13 (broadcast13 mulcast13 anycast)13 messaging
bull Binary13 encoding13 Network13 byte13 orderingbull MTU13 correlaon13 with13 CoAP13 PDU13 sizebull Transport13 latency
63
031113
Security13 Consideraons
bull Drar13 does13 not13 introduce13 new13 security13 requirements13 by13 itself
bull There13 may13 be13 privacy13 issues13 if13 nodes13 use13 telephone13 numbers13 or13 MAC13 addresses13 as13 public13 end13 point13 idenfiers
64
Akbar Rahman
IETF 86 March 2013 httpwwwietforgiddraft-rahman-core-sleepy-02txt
Enhanced Sleepy Node Support for CoAP
Introduction
It is expected that in CoAP networks there will be a certain portion of devices that are sleepy and which may occasionally go into a sleep mode (ie go into a low power state to conserve power) and subsequently have reduced CoAP protocol communication ability
This I-D proposes a minimal and efficient mechanism building on the Resource Directory concept (which will be integrated into a CoAP Proxy) to enhance sleepy node support in CoAP networks
Main Question from IETF-85 (Atlanta)
What performance benefit does the proposed Sleepy Node support solution give in a network that already has standard CoAP caching enabled
Sleepy Node Performance Analysis
Experimental Network
1-5 clients
Both Sleepy and Non-
Sleepy servers
Sleepy Node Performance Analysis Network Setup
CoAPSleepyServer(s)
CoAPSleepAwareReverseProxy
CoAP
Client(s)
Request
Response
Sleep9AwareCoREResourceDirectoryCapability
PublishedSleepParameters
Sleep9AwareCoAPStoreandForwardCapability Response
Request
SleepAwareCoAP503ResponseCapability
CoAPCachingCapability
bull Server supports publishing sleep parameters to proxy bull Eg Irsquom going to be asleep for X seconds
bull Proxy supports sleep-awareness capabilities bull Proxy also supports caching capability based off of maxAge bull Protocol flow similar to approach of Figure 1 (Synchronous RD Based Sleep
Tracking) of I-D
Proxy capabilities can be selectively enableddisabled
Proxy ndash Server Interface
Client ndash Proxy Interface
CoAP Sleep-Aware Reverse Proxy Features CoRE Sleep-aware Resource Directory
Support storing published sleep parameters from CoAP servers sleepState (AWAKE ASLEEP) sleepDuration
Sleep-aware CoAP 503 Response Capability If CoAP request to a sleeping server is received proxy returns a
lsquo503 Retry-Afterrsquo response to client 503 contains a timestamp indicating when the sever will wake back up
(timestamp delivered in CoAP maxAge option) Sleep-aware CoAP Store-and-Forward Capability
If CoAP request to a sleeping server is received proxy stores request until server wakes up and then forwards it
Caching capability Cache GET responses from server if maxAge option is present
(this is not a sleep aware feature)
Goals of Performance Analysis
For networks having sleepy servers provide measurements to quantify the impact that CoAP sleep-awareness capabilities can have
See if sleep-awareness capabilities can
provide additional benefits even when CoAP caching is used
Overview of Performance Analysis Performed The analysis was broken up into a set of test scenarios Each test scenario used a different combination of the following
variables Client issued GET requests Server was configured as a sleepy or non-sleepy server Proxy caching of GET responses was enabled or disabled Proxy sleep-aware 503 response capability was enabled or disabled Proxy store-and-forward capability was enabled or disabled maxAge in GET responses ndash Two values were tested 60sec and 5sec of Clients ndash Two values were used ndash 1 client and 5 clients
For comparison purposes the following were held constant across all test scenarios Client issued a fixed number of requests (100) across all test scenarios Client used a delay between each GET request (35sec) to better exercise
proxyrsquos caching and sleep-awareness capabilities For sleepy server test scenarios the server slept 60 sec awake for 3 sec
Format of Results The following results were collected for each
test scenario
Breakdown of the and types of transactions occurring between clientproxyserver
ldquoGETrdquo ndash Test Scenario Results
GET ndash Description of Test Scenarios
TestScenarios-GET
Scenario
CoAPSleepyServerSe7ngs CoAPSleepAwareReverseProxySe7ngs CoAPClientSe7ngs
SleepDuragton(sec)
AwakeDuragton(sec)
maxAge(sec) Caching SleepAwareSAF+
503NumberofClients
NumberofGETs
DelayBetweenClient
Requests(sec)
1a 0 Always 60 Enabled Disabled 1 100 35
1b 60 3 60 Enabled Disabled 1 100 35
1c 60 3 60 Enabled Enabled 1 100 35
2a 0 Always 60 Enabled Disabled 5 100 35
2b 60 3 60 Enabled Disabled 5 100 35
2c 60 3 60 Enabled Enabled 5 100 35
3a 0 Always 5 Enabled Disabled 5 100 35
3b 60 3 5 Enabled Disabled 5 100 35
3c 60 3 5 Enabled Enabled 5 100 35
ldquoGETrdquo ndash Test Scenario 1 Results
maxAge = 60 and 1 Client
GET ndash Scenario 1 ClientProxy Interface Transaction Mix
Scenarios 1a - Non-Sleepy Server Caching Proxy maxAge = 60sec 1b- Sleepy Server Caching Proxy maxAge = 60sec 1c - Sleepy Server Sleep Aware Proxy maxAge = 60sec
Sleep Aware Proxy has better performance for sleepy servers
0
100
200
300
400
500
600
700
1a 1b 1c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
GET ndash Scenario 1 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
Scenarios 1a - Non-Sleepy Server Caching Proxy maxAge = 60sec 1b- Sleepy Server Caching Proxy maxAge = 60sec 1c - Sleepy Server Sleep Aware Proxy maxAge = 60sec
0
100
200
300
400
500
600
700
800
1a 1b 1c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
ldquoGETrdquo ndash Test Scenario 2 Results
maxAge = 60 and 5 Clients
GET ndash Scenario 2 ClientProxy Interface Transaction Mix
Sleep Aware Proxy has slightly better performance for sleepy servers
0
200
400
600
800
1000
1200
1400
2a 2b 2c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
Scenarios 2a - Non-Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2b- Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2c - Sleepy Server Sleep Aware Proxy maxAge = 60sec 5 Clients
See ldquoExperimental Artifactsrdquo Note 1
GET ndash Scenario 2 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has slightly better performance for sleepy servers
0
50
100
150
200
250
300
350
400
2a 2b 2c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
Scenarios 2a - Non-Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2b- Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2c - Sleepy Server Sleep Aware Proxy maxAge = 60sec 5 Clients
See ldquoExperimental Artifactsrdquo Note 2
Experimental Artifacts Note 1
Currently in the experiment the sleep aware proxy checks the cached state of a resource before putting a request into its Store-and-forward queue while a server is sleeping Once in the queue the proxy unconditionally forwards the queued requests to the server once it wakes up This is not the most efficient setup and can easily be improved If the proxy instead checks its cache again before forwarding each queued request it may not need to forward the request to the server For example if there are two queued GET requests in the proxyrsquos queue that address the same resource Only the first request needs to be sent to the server the second request can use the cached response from the first request
Note 2 Currently in the experiment the sleepy server sends a sleepState PUT request to the
proxy each time it goes to sleep This is not the most efficient setup and can easily be improved For example if the server assumes that the proxy can keep track of its ONOFF cycles with its internal timers (eg as per Fig 1 of I-D) then the number of messages from the sleepy server dramatically goes down
ldquoGETrdquo ndash Test Scenario 3 Results
maxAge = 5 and 5 Clients
GET ndash Scenario 3 ClientProxy Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
Scenarios 3a - Non-Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3b- Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3c - Sleepy Server Sleep Aware Proxy maxAge = 5sec 5 Clients
0
500
1000
1500
2000
2500
3000
3500
4000
4500
5000
3a 3b 3c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
GET ndash Scenario 3 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
0
1000
2000
3000
4000
5000
6000
7000
3a 3b 3c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
Scenarios 3a - Non-Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3b- Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3c - Sleepy Server Sleep Aware Proxy maxAge = 5sec 5 Clients
Conclusions
Conclusions These results show that sleep-aware CoAP
proxy features can significantly optimize communication with sleepy servers in most scenarios
These results also show that sleep-
awareness capabilities can provide additional benefits above and beyond CoAP caching in most scenarios
Backup
Current CoAP Support of Sleepy Node (12)
CoAP proxies can use a previously cached response to service a new GET request for a sleepy origin server (as in HTTP) But if no valid cache then proxy has to attempt to
retrieve and may fail if origin server is sleeping [I-Dietf-core-coap]
Clients can discover list of resources from RD (GET rd-lookuphellip) for sleepy servers But attempt to GET resource from sleepy origin server
may fail if origin server is sleeping [IDietf-core-link-format amp IDshelby-core-resource-
directory]
Current CoAP Support of Sleepy Node (22)
Lower layer support for sleepy nodes in most wireless technologies (eg WiFi ZigBee) But limited to MAC packet scheduling for sleepy nodes
and not aware of specific needs of IP applications (like CoAP)
Proposal ndash RD Based Sleep Tracking (14)
The current CoAP approach to support sleepy nodes can be significantly improved by introducing RD based mechanisms for a CoAP client to determine whether A targeted resource is located on a sleepy server A sleepy server is currently in sleep mode or not
There is any associated caching Proxy (possibly the RD itself) for a sleepy server
Proposal ndash RD Based Sleep Tracking (24)
We define the following new RD attributes to characterize the properties of a sleepy node SleepState - Indicates whether the node is currently in
sleep mode or not (ie Sleeping or Awake) SleepDuration - Indicates the maximum duration of time
that the node stays in sleep mode TimeSleeping - Indicates the length of time the node
has been sleeping (ie if Sleep State = Sleeping) NextSleep - Indicates the next time the node will go to
sleep (ie if Sleep State = Awake)
CachingProxy ndash Indicates the caching proxy of the sleepy node (ie the RD itself or another node)
Proposal ndash RD Based Sleep Tracking (34)
These attributes are all server (node) level and are new parameters added to the RD URI Template Variables
Finally we also define a new lookup-type (ss) for the RD lookup interface specified in [I-Dshelby-core-resource-directory] This new lookup-type supports looking up the
ldquoSleepStaterdquo (ss) of a specified end-point
Proposal ndash RD Based Sleep Tracking (44)
The three time based parameters (SleepDuration TimeSleeping NextSleep) can be based on either an absolute network time (for a time synchronized network) or a relative local time (measured at the local node)
Following the approach of [I-Dietf-core-link-format] and [I-Dshelby-core-resource-directory] sleep parameters for sleepy servers can be stored by the server in the RD and accessed by all interested clients
Examples of using these parameters in a synchronous or asynchronous manner are shown in the I-D
http6lowappnet coreIETF86 2013-03-12-13
We assume people have read the drafts
Meetings serve to advance difficult issues by making good use of face-to-face communications
Note Well Be aware of the IPR principles according to RFC 3979 and its updates
uumlBlue sheetsuumlScribe(s)
96
drar-shy‐iep-shy‐core-shy‐coapsubmiqed13 to13 IESG
2013-shy‐03-shy‐13
97
OMA Lightweight M2M Overview(A new standard using lots of IETF specs including DTLS
CoAP Block Observe Resource Directory SenMLhellip)
Zach ShelbyCoRE WG IETF-86 Orlando
OMA Lightweight M2Mbull Open Mobile Alliance is well known for Device Management (DM)bull OMA Lightweight M2M is a new standard from the alliance
ndash Focused on constrained Cellular and sensor network M2M devicesndash Driven by leading operators and vendors
bull Scopendash Interfaces protocol amp security between Device and Serverndash Object and Resource modelndash Bootstrap Device Access Control Connectivity and Firmware Objects
bull Draft Specifications are availablendash httpmemberopenmobileallianceorgftpPublic_documentsDM
LightweightM2MPermanent_documentsOMA-TS-LightweightM2M-V1_0_0-20130301-Dzip
bull Timelinendash Requirements and Architecture completed 3Q2012ndash Spec ready for Consistency Review 2Q2013ndash Candidate Approval expected 3Q2013
2 CoRE WG IETF-86 Orlando
Architecture
3
Scope of LWM2M
CoRE WG IETF-86 Orlando
Object Model
bull A Client has one or more Object Instancesbull An Object is a collection of Resourcesbull A Resource is an atomic piece of information
ndash Read Written or Executed
bull Resources can have multiple instancesbull Objects and Resources are identified by a
16-bit Integer Instances by an 8-bit Integerbull ObjectsResources are accessed with
simple URIs Object IDObject InstanceResource ID
eg 1213
4 CoRE WG IETF-86 Orlando
CoRE WG IETF-86 Orlando
CoRE Resource Directory
draft-shelby-core-resource-directory-05
Z Shelby C Bormann S Krco
Backgroundbull Not a new concept
ndash think web search engine or any link directorybull Defines the interfaces to a Resource Directorybull Based on Web Linking framework and the CoRE Link Formatbull Generic REST design for use over HTTP and CoAPbull Used by OMA Lightweight M2Mbull Has already been deployed
ndash In traffic monitoring systemsndash In street lighting systemsndash For vehicular asset trackingndash By a major Cellular M2M operator
Changes since -04
bull Restricted Update to parameter updatesbull Added pagination support for the Lookup interfacebull Changed rt= to et= for the registration amp update
interfacebull Added group support
Group Management
bull RD now includes group management featuresbull New Group Function Set
ndash Register a groupbull Group name domain multicast address endpoint members
ndash Remove a groupbull Group lookup using the Lookup Function Set
ndash List registered groupsndash Find the members of a groupndash Find groups with certain endpoints or resources
Registering a Group
EP RD
| |
| - POST rd-groupgp=lights ltgtep=node1 --gt |
| |
| |
| lt---- 201 Created Location rd-group12 ---- |
| |
Req POST coaprdexamplecomrd-groupgp=lights
Payload
ltgtep=node1
ltgtep=node2
Res 201 Created
Location rd-group12
Looking up Group Members
Client RD
| |
| ----- GET rd-lookupepgp=lights1 ----------------------gt |
| |
| |
| lt-- 205 Content ltrdgtd=domain1ltrdgtd=domain2 --------- |
| |
Req GET rd-lookupepgp=lights1
Res 205 Content
ltcoaphostportgtep=node1
ltcoaphostportgtep=node2rdquo
Things for the futurebull Support for JSON representation of Web Links
ndash httptoolsietforgiddraft-bormann-core-links-json-02txtbull Registry for RD registration query parameters
ndash Already OMA Lightweight has defined some new onesbull More examples
Group 3 ldquonew workrdquo(continued)
109
drar-shy‐greevenbosch-shy‐core-shy‐profile-shy‐descripon-shy‐01Bert13 GreevenboschJeroen13 Hoebeke
Isam13 IshaqFloris13 Van13 den13 Abeele
Descripon
bull JSON13 format13 for13 signalling13 the13 servers13 capabilies
bull Signalling13 of13 supported13 opons13 media13 types13 and13 block13 sizendash Other13 items13 can13 be13 added
bull Filtering13 on13 specific13 fields13 through13 URI-shy‐Querybull Link13 hqpdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐profile-shy‐descripon
well-shy‐knownprofile
bull To13 acquire13 profile13 data13 of13 resources13 on13 a13 parcular13 service13 the13 well-shy‐knownprofile13 URI-shy‐path13 is13 introduced
bull For13 example13 to13 get13 all13 informaon13 from13 sensors13 served13 by13 wwwexampleorg13 we13 can13 do13 a13 GET13 to13 coapwwwexampleorgwell-shy‐knownprofile
bull Filtering13 on13 parcular13 resources13 is13 done13 through13 URI-shy‐Queries
Format
bull Currently13 the13 following13 fields13 are13 definedndash ldquopathrdquo13 contains13 the13 URI-shy‐path13 associated13 with13 a13 resource
ndash ldquooprdquo13 a13 numerical13 list13 of13 supported13 opon13 numbers
ndash ldquocfrdquo13 a13 numerical13 list13 of13 supported13 content-shy‐format13 numbers
ndash ldquob1srdquo13 ldquob2srdquo13 supported13 block13 sizes13 for13 Block113 and13 Block213 respecvely
Examplebull On13 the13 right13 is13 an13 example13 of13 a13 camera13 sensor13 at13 coapwwwexampleorgcam13 that13 supports13 the13 Uri-shy‐Host13 (3)13 ETag13 (4)13 Uri-shy‐Port13 (7)13 Uri-shy‐Path13 (11)13 Content-shy‐Format13 (12)13 Token13 (19)13 Block213 (23)13 and13 Proxy-shy‐Uri13 (35)13 opons
bull The13 supported13 content13 formats13 are13 textplain13 (0)13 applicaon13 link-shy‐format13 (40)13 and13 applicaonjson13 (50)
bull The13 supported13 Block213 can13 use13 25613 or13 51213 byte13 blocks
Req13 GET13 coapwwwexampleorgwell-shy‐knownprofile13 Res13 20513 Content13 (applicationjson)13 13 13 13 profile13 13 13 13 13 13 13 13 pathcam13 13 13 13 op[3471112192335]13 13 13 13 13 cf[04050]13 13 13 13 13 b2s[45]13 13 13 13
Filtering13 through13 use13 of13 URI-shy‐Query
bull Filtering13 can13 be13 done13 through13 the13 URI-shy‐Querybull Query13 format13 N=V
ndash N13 is13 a13 profile13 fieldndash V13 is13 the13 desired13 value
bull Examplesndash To13 find13 resources13 that13 support13 content13 format13 ldquoapplicaonjsonrdquo
13 GET13 wwwexampleorgwell-shy‐knownprofilecf=50ndash To13 get13 informaon13 about13 the13 camera
13 GET13 wwwexampleorgwell-shy‐knownprofilepath=cam
Open13 issues
bull Which13 other13 profile13 data13 needs13 signallingndash Content-shy‐type13 for13 different13 methods
bull Fix13 the13 order13 in13 which13 the13 profile13 fields13 must13 appearndash Non-shy‐fixed13 order13 easier13 extensible
bull Inheritance13 of13 a13 profile13 descriponbull Extend13 usage13 to13 signal13 the13 client13 profilebull Integraon13 with13 link13 format
Thank13 youQuesons
drar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval-shy‐00
Bert13 Greevenbosch
Descripon
bull The13 ldquoMinimumRequestInterval13 opon13 can13 be13 used13 to13 indicate13 the13 minimum13 me13 between13 two13 requests13 in13 a13 transacon
bull Originally13 intended13 for13 Block13 but13 also13 usable13 for13 other13 transaconsndash Example13 browsing13 a13 server
bull The13 goal13 is13 to13 reduce13 the13 server13 load13 and13 network13 traffic
bull Link13 hqpsdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval
Usage
bull The13 client13 keeps13 the13 server13 informed13 about13 its13 request13 speed13 through13 inclusion13 of13 the13 ldquoMinimumRequestIntervalrdquo13 opon
bull In13 responses13 the13 server13 fixes13 the13 minimum13 request13 interval13 through13 the13 same13 opon
bull The13 client13 obeys13 the13 speed13 indicated13 by13 the13 server
bull The13 client13 can13 send13 slower13 but13 not13 faster
Advantages
bull The13 server13 has13 means13 to13 limit13 the13 amount13 of13 incoming13 traffic
bull The13 server13 can13 prevent13 to13 become13 overloaded13 with13 too13 many13 tasks
bull The13 server13 does13 not13 need13 arficially13 slow13 down13 the13 client13 by13 sending13 late13 ACKsndash No13 need13 to13 keep13 track13 of13 delayed13 ACKsndash The13 server13 can13 perform13 other13 tasks13 instead
bull Reduced13 network13 traffic
Thank13 youQuesons
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-links-json-02txt
123
RFC 6690 (link-format) documents are somewhat foreign to many web app developerssect would prefer to have them in JSON format
There is no standard way to represent link-format documents in applicationssect but everyone knows how to handle JSON
Define a standard JSON translation for link-format
Itrsquos
not
rock
et
scien
ce
ltsensorsgtct=40title=Sensor Index ltsensorstempgtrt=temperature-cif=sensor ltsensorslightgtrt=light-luxif=sensor lthttpwwwexamplecomsensorst123gt anchor=sensorstemprel=describedby lttgtanchor=sensorstemprel=alternate [hrefsensorsct40titleSensor Index hrefsensorstemprttemperature-cifsensor hrefsensorslightrtlight-luxifsensor hrefhttpwwwexamplecomsensorst123 anchorsensorstempreldescribedby hreftanchorsensorstemprelalternate]
124
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-ipsec-for-coap-00txt
IPsec definitions for CoAP Mostly placeholder at this time Who has implementation experience with this
125
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-cross-reverse-convention-00txt
This draft has two lines of payload(based on a WGLC comment by Cullen Jennings)
coap12344567foobara=3
httpwwwproxycomwellknowncore-translate1234_4567foobara=3
Is that a useful convention to have
126
Insert CI slides here
127
128
0
5
10
15
20
25
30
35
40
10 20 30 40 50 60 70
good
put (
pps)
pps
Goodput vs pps (Econotags)
goodput
[Khattak preliminary]
Congestion Control
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-cocoa-00txt
ldquoadvancedrdquo cc (The draft is just a first shot) Others may have better ideas
129
Insert post-WGLC discussion slides here
130
Stop Continue Start
131
An Agile Retrospective
http6lowappnet coreIETF86 2013-03-12-13
Stop
132
Endless new CoAP optionssect instead use RESTful as much as possible
Move general security lifecycle out Looking at theoretical problems
http6lowappnet coreIETF86 2013-03-12-13
Continue
Interops Running code Look at real-world examples and deployments Solve their actual problems
sect Unilateral enhancements eg higher performance congestion control
sect Transports (SMS hellip)sect Make Web linking and Directories more and more usefulsect RESTful Design Paradigms for real-world problems
133
http6lowappnet coreIETF86 2013-03-12-13
Start
Further push into the (browser) web world (HTML5 browser security)
Specific supporting worksect SenMLsect URI work (dev URN hellip)sect Security Processes (next slide)
Spin outsect (We donrsquot really get to decide where this is done)
134
http6lowappnet coreIETF86 2013-03-12-13
Security
Integrate Application Network Group Keyingsect Tunnel-free setup
Donrsquot redo what has been done alreadysect ZigBee IP is finesect But what about other scenarios
Simple REST interfaces for working with keying materials and authorizationsect Start with defining objectives
Object Security for Constrained Nodes135
Re-chartering CoREWhat do we want to do now that wersquore grown up
Zach ShelbyCoRE WG IETF-86 Orlando
What is the scope
bull So we have a protocol and Web Linking what next
bull Keep with what we know besthellip1 Enhancements around CoAP2 New transports for CoAP3 New representations for Web Links4 General application layer solutions
CoRE WG IETF-86 Orlando 2
Enhancements around CoAP
bull Advanced congestion control
CoRE WG IETF-86 Orlando 3
New Transports for CoAP
bull Infrastructure for CoAP over foondash httptoolsietforgiddraft-silverajan-core-
coap-alternative-transports-01txtbull CoAP over SMS
ndash httptoolsietforgiddraft-becker-core-coap-sms-gprs-03txt
ndash OMA Lightweightbull CoAP over TCP
ndash httptoolsietforgiddraft-li-core-coap-payload-length-option-01txt
CoRE WG IETF-86 Orlando 4
New support for Web Links
bull JSON Web Linksndash httptoolsietforgiddraft-bormann-core-links-
json-02txt
2332010 CoRE WG IETF-77 Anaheim 5
General application layer solutions
bull Resource Directoryndash httptoolsietforgiddraft-shelby-core-
resource-directory-05txtndash OMA Lightweight
2332010 CoRE WG IETF-77 Anaheim 6
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
bull In13 the13 URI13 pathndash coaphostexamplecomtransport=tcpwell-shy‐knowncorert=core-shy‐rd
bull Easy13 adopon13 of13 new13 (and13 experimental)13 CoAP13 transports13 without13 IANA13 registraon
bull Caveat13 Uri-shy‐Path13 opon13 is13 a13 Crical13 CoAP13 opon13 see13 secon13 54113 of13 I-shy‐Diep-shy‐core-shy‐coap
59
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
bull As13 a13 URI13 query13 componentndash coaphostexamplecomwell-shy‐knowncorert=core-shy‐rdq=tcp
bull Also13 easy13 to13 adopt13 new13 (and13 experimental)13 CoAP13 transports13 without13 IANA13 registraon
bull Caveat13 Uri-shy‐Query13 opon13 is13 a13 Crical13 CoAP13 opon13 see13 secon13 54113 of13 I-shy‐Diep-shy‐core-shy‐coap
60
031113
URI13 Representaons13 for13 CoAPNon13 standard13 ways
bull Transport13 in13 the13 URI13 authority13 componentndash coaphost[port][transport]13 instead13 of13 coaphost[port]
bull Transport13 as13 a13 service13 URLndash servicecoaptcphostexamplecomwell-shy‐knowncorert=core-shy‐rd
bull Above13 two13 ways13 break13 exisng13 compability13 (although13 both13 are13 based13 on13 valid13 IANA13 URI13 registraons)
61
031113
URI13 Representaons13 for13 CoAPMiscellaneous13 Consideraons
bull Ensure13 that13 transport13 is13 defined13 unambiguously13 (eg13 L2CAP13 used13 by13 both13 BLE13 and13 standard13 Bluetooth13 so13 avoid13 rdquocoap+l2caprdquo13 or13 rdquotransport=l2caprdquo13 or13 rdquoq=l2caprdquondash Can13 be13 done13 as13 WG13 consensusndash Namespace13 approach13 eg13 rdquocoap+blel2caprdquo13 or13 rdquoq=blel2caprdquo
bull Allow13 end-shy‐points13 to13 use13 CoAP13 Resource13 Directory13 to13 register13 alternave13 transports13 and13 idenfiers13 and13 provide13 periodic13 updatesndash Register13 rdquocore-shy‐transportrdquo13 resource13 type
62
031113
Transport13 Consideraons
bull Uniqueness13 of13 end-shy‐point13 idenficaonbull Communicaon13 support13 Unidireconal13 Bidireconal13 1N13 (broadcast13 mulcast13 anycast)13 messaging
bull Binary13 encoding13 Network13 byte13 orderingbull MTU13 correlaon13 with13 CoAP13 PDU13 sizebull Transport13 latency
63
031113
Security13 Consideraons
bull Drar13 does13 not13 introduce13 new13 security13 requirements13 by13 itself
bull There13 may13 be13 privacy13 issues13 if13 nodes13 use13 telephone13 numbers13 or13 MAC13 addresses13 as13 public13 end13 point13 idenfiers
64
Akbar Rahman
IETF 86 March 2013 httpwwwietforgiddraft-rahman-core-sleepy-02txt
Enhanced Sleepy Node Support for CoAP
Introduction
It is expected that in CoAP networks there will be a certain portion of devices that are sleepy and which may occasionally go into a sleep mode (ie go into a low power state to conserve power) and subsequently have reduced CoAP protocol communication ability
This I-D proposes a minimal and efficient mechanism building on the Resource Directory concept (which will be integrated into a CoAP Proxy) to enhance sleepy node support in CoAP networks
Main Question from IETF-85 (Atlanta)
What performance benefit does the proposed Sleepy Node support solution give in a network that already has standard CoAP caching enabled
Sleepy Node Performance Analysis
Experimental Network
1-5 clients
Both Sleepy and Non-
Sleepy servers
Sleepy Node Performance Analysis Network Setup
CoAPSleepyServer(s)
CoAPSleepAwareReverseProxy
CoAP
Client(s)
Request
Response
Sleep9AwareCoREResourceDirectoryCapability
PublishedSleepParameters
Sleep9AwareCoAPStoreandForwardCapability Response
Request
SleepAwareCoAP503ResponseCapability
CoAPCachingCapability
bull Server supports publishing sleep parameters to proxy bull Eg Irsquom going to be asleep for X seconds
bull Proxy supports sleep-awareness capabilities bull Proxy also supports caching capability based off of maxAge bull Protocol flow similar to approach of Figure 1 (Synchronous RD Based Sleep
Tracking) of I-D
Proxy capabilities can be selectively enableddisabled
Proxy ndash Server Interface
Client ndash Proxy Interface
CoAP Sleep-Aware Reverse Proxy Features CoRE Sleep-aware Resource Directory
Support storing published sleep parameters from CoAP servers sleepState (AWAKE ASLEEP) sleepDuration
Sleep-aware CoAP 503 Response Capability If CoAP request to a sleeping server is received proxy returns a
lsquo503 Retry-Afterrsquo response to client 503 contains a timestamp indicating when the sever will wake back up
(timestamp delivered in CoAP maxAge option) Sleep-aware CoAP Store-and-Forward Capability
If CoAP request to a sleeping server is received proxy stores request until server wakes up and then forwards it
Caching capability Cache GET responses from server if maxAge option is present
(this is not a sleep aware feature)
Goals of Performance Analysis
For networks having sleepy servers provide measurements to quantify the impact that CoAP sleep-awareness capabilities can have
See if sleep-awareness capabilities can
provide additional benefits even when CoAP caching is used
Overview of Performance Analysis Performed The analysis was broken up into a set of test scenarios Each test scenario used a different combination of the following
variables Client issued GET requests Server was configured as a sleepy or non-sleepy server Proxy caching of GET responses was enabled or disabled Proxy sleep-aware 503 response capability was enabled or disabled Proxy store-and-forward capability was enabled or disabled maxAge in GET responses ndash Two values were tested 60sec and 5sec of Clients ndash Two values were used ndash 1 client and 5 clients
For comparison purposes the following were held constant across all test scenarios Client issued a fixed number of requests (100) across all test scenarios Client used a delay between each GET request (35sec) to better exercise
proxyrsquos caching and sleep-awareness capabilities For sleepy server test scenarios the server slept 60 sec awake for 3 sec
Format of Results The following results were collected for each
test scenario
Breakdown of the and types of transactions occurring between clientproxyserver
ldquoGETrdquo ndash Test Scenario Results
GET ndash Description of Test Scenarios
TestScenarios-GET
Scenario
CoAPSleepyServerSe7ngs CoAPSleepAwareReverseProxySe7ngs CoAPClientSe7ngs
SleepDuragton(sec)
AwakeDuragton(sec)
maxAge(sec) Caching SleepAwareSAF+
503NumberofClients
NumberofGETs
DelayBetweenClient
Requests(sec)
1a 0 Always 60 Enabled Disabled 1 100 35
1b 60 3 60 Enabled Disabled 1 100 35
1c 60 3 60 Enabled Enabled 1 100 35
2a 0 Always 60 Enabled Disabled 5 100 35
2b 60 3 60 Enabled Disabled 5 100 35
2c 60 3 60 Enabled Enabled 5 100 35
3a 0 Always 5 Enabled Disabled 5 100 35
3b 60 3 5 Enabled Disabled 5 100 35
3c 60 3 5 Enabled Enabled 5 100 35
ldquoGETrdquo ndash Test Scenario 1 Results
maxAge = 60 and 1 Client
GET ndash Scenario 1 ClientProxy Interface Transaction Mix
Scenarios 1a - Non-Sleepy Server Caching Proxy maxAge = 60sec 1b- Sleepy Server Caching Proxy maxAge = 60sec 1c - Sleepy Server Sleep Aware Proxy maxAge = 60sec
Sleep Aware Proxy has better performance for sleepy servers
0
100
200
300
400
500
600
700
1a 1b 1c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
GET ndash Scenario 1 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
Scenarios 1a - Non-Sleepy Server Caching Proxy maxAge = 60sec 1b- Sleepy Server Caching Proxy maxAge = 60sec 1c - Sleepy Server Sleep Aware Proxy maxAge = 60sec
0
100
200
300
400
500
600
700
800
1a 1b 1c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
ldquoGETrdquo ndash Test Scenario 2 Results
maxAge = 60 and 5 Clients
GET ndash Scenario 2 ClientProxy Interface Transaction Mix
Sleep Aware Proxy has slightly better performance for sleepy servers
0
200
400
600
800
1000
1200
1400
2a 2b 2c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
Scenarios 2a - Non-Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2b- Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2c - Sleepy Server Sleep Aware Proxy maxAge = 60sec 5 Clients
See ldquoExperimental Artifactsrdquo Note 1
GET ndash Scenario 2 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has slightly better performance for sleepy servers
0
50
100
150
200
250
300
350
400
2a 2b 2c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
Scenarios 2a - Non-Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2b- Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2c - Sleepy Server Sleep Aware Proxy maxAge = 60sec 5 Clients
See ldquoExperimental Artifactsrdquo Note 2
Experimental Artifacts Note 1
Currently in the experiment the sleep aware proxy checks the cached state of a resource before putting a request into its Store-and-forward queue while a server is sleeping Once in the queue the proxy unconditionally forwards the queued requests to the server once it wakes up This is not the most efficient setup and can easily be improved If the proxy instead checks its cache again before forwarding each queued request it may not need to forward the request to the server For example if there are two queued GET requests in the proxyrsquos queue that address the same resource Only the first request needs to be sent to the server the second request can use the cached response from the first request
Note 2 Currently in the experiment the sleepy server sends a sleepState PUT request to the
proxy each time it goes to sleep This is not the most efficient setup and can easily be improved For example if the server assumes that the proxy can keep track of its ONOFF cycles with its internal timers (eg as per Fig 1 of I-D) then the number of messages from the sleepy server dramatically goes down
ldquoGETrdquo ndash Test Scenario 3 Results
maxAge = 5 and 5 Clients
GET ndash Scenario 3 ClientProxy Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
Scenarios 3a - Non-Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3b- Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3c - Sleepy Server Sleep Aware Proxy maxAge = 5sec 5 Clients
0
500
1000
1500
2000
2500
3000
3500
4000
4500
5000
3a 3b 3c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
GET ndash Scenario 3 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
0
1000
2000
3000
4000
5000
6000
7000
3a 3b 3c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
Scenarios 3a - Non-Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3b- Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3c - Sleepy Server Sleep Aware Proxy maxAge = 5sec 5 Clients
Conclusions
Conclusions These results show that sleep-aware CoAP
proxy features can significantly optimize communication with sleepy servers in most scenarios
These results also show that sleep-
awareness capabilities can provide additional benefits above and beyond CoAP caching in most scenarios
Backup
Current CoAP Support of Sleepy Node (12)
CoAP proxies can use a previously cached response to service a new GET request for a sleepy origin server (as in HTTP) But if no valid cache then proxy has to attempt to
retrieve and may fail if origin server is sleeping [I-Dietf-core-coap]
Clients can discover list of resources from RD (GET rd-lookuphellip) for sleepy servers But attempt to GET resource from sleepy origin server
may fail if origin server is sleeping [IDietf-core-link-format amp IDshelby-core-resource-
directory]
Current CoAP Support of Sleepy Node (22)
Lower layer support for sleepy nodes in most wireless technologies (eg WiFi ZigBee) But limited to MAC packet scheduling for sleepy nodes
and not aware of specific needs of IP applications (like CoAP)
Proposal ndash RD Based Sleep Tracking (14)
The current CoAP approach to support sleepy nodes can be significantly improved by introducing RD based mechanisms for a CoAP client to determine whether A targeted resource is located on a sleepy server A sleepy server is currently in sleep mode or not
There is any associated caching Proxy (possibly the RD itself) for a sleepy server
Proposal ndash RD Based Sleep Tracking (24)
We define the following new RD attributes to characterize the properties of a sleepy node SleepState - Indicates whether the node is currently in
sleep mode or not (ie Sleeping or Awake) SleepDuration - Indicates the maximum duration of time
that the node stays in sleep mode TimeSleeping - Indicates the length of time the node
has been sleeping (ie if Sleep State = Sleeping) NextSleep - Indicates the next time the node will go to
sleep (ie if Sleep State = Awake)
CachingProxy ndash Indicates the caching proxy of the sleepy node (ie the RD itself or another node)
Proposal ndash RD Based Sleep Tracking (34)
These attributes are all server (node) level and are new parameters added to the RD URI Template Variables
Finally we also define a new lookup-type (ss) for the RD lookup interface specified in [I-Dshelby-core-resource-directory] This new lookup-type supports looking up the
ldquoSleepStaterdquo (ss) of a specified end-point
Proposal ndash RD Based Sleep Tracking (44)
The three time based parameters (SleepDuration TimeSleeping NextSleep) can be based on either an absolute network time (for a time synchronized network) or a relative local time (measured at the local node)
Following the approach of [I-Dietf-core-link-format] and [I-Dshelby-core-resource-directory] sleep parameters for sleepy servers can be stored by the server in the RD and accessed by all interested clients
Examples of using these parameters in a synchronous or asynchronous manner are shown in the I-D
http6lowappnet coreIETF86 2013-03-12-13
We assume people have read the drafts
Meetings serve to advance difficult issues by making good use of face-to-face communications
Note Well Be aware of the IPR principles according to RFC 3979 and its updates
uumlBlue sheetsuumlScribe(s)
96
drar-shy‐iep-shy‐core-shy‐coapsubmiqed13 to13 IESG
2013-shy‐03-shy‐13
97
OMA Lightweight M2M Overview(A new standard using lots of IETF specs including DTLS
CoAP Block Observe Resource Directory SenMLhellip)
Zach ShelbyCoRE WG IETF-86 Orlando
OMA Lightweight M2Mbull Open Mobile Alliance is well known for Device Management (DM)bull OMA Lightweight M2M is a new standard from the alliance
ndash Focused on constrained Cellular and sensor network M2M devicesndash Driven by leading operators and vendors
bull Scopendash Interfaces protocol amp security between Device and Serverndash Object and Resource modelndash Bootstrap Device Access Control Connectivity and Firmware Objects
bull Draft Specifications are availablendash httpmemberopenmobileallianceorgftpPublic_documentsDM
LightweightM2MPermanent_documentsOMA-TS-LightweightM2M-V1_0_0-20130301-Dzip
bull Timelinendash Requirements and Architecture completed 3Q2012ndash Spec ready for Consistency Review 2Q2013ndash Candidate Approval expected 3Q2013
2 CoRE WG IETF-86 Orlando
Architecture
3
Scope of LWM2M
CoRE WG IETF-86 Orlando
Object Model
bull A Client has one or more Object Instancesbull An Object is a collection of Resourcesbull A Resource is an atomic piece of information
ndash Read Written or Executed
bull Resources can have multiple instancesbull Objects and Resources are identified by a
16-bit Integer Instances by an 8-bit Integerbull ObjectsResources are accessed with
simple URIs Object IDObject InstanceResource ID
eg 1213
4 CoRE WG IETF-86 Orlando
CoRE WG IETF-86 Orlando
CoRE Resource Directory
draft-shelby-core-resource-directory-05
Z Shelby C Bormann S Krco
Backgroundbull Not a new concept
ndash think web search engine or any link directorybull Defines the interfaces to a Resource Directorybull Based on Web Linking framework and the CoRE Link Formatbull Generic REST design for use over HTTP and CoAPbull Used by OMA Lightweight M2Mbull Has already been deployed
ndash In traffic monitoring systemsndash In street lighting systemsndash For vehicular asset trackingndash By a major Cellular M2M operator
Changes since -04
bull Restricted Update to parameter updatesbull Added pagination support for the Lookup interfacebull Changed rt= to et= for the registration amp update
interfacebull Added group support
Group Management
bull RD now includes group management featuresbull New Group Function Set
ndash Register a groupbull Group name domain multicast address endpoint members
ndash Remove a groupbull Group lookup using the Lookup Function Set
ndash List registered groupsndash Find the members of a groupndash Find groups with certain endpoints or resources
Registering a Group
EP RD
| |
| - POST rd-groupgp=lights ltgtep=node1 --gt |
| |
| |
| lt---- 201 Created Location rd-group12 ---- |
| |
Req POST coaprdexamplecomrd-groupgp=lights
Payload
ltgtep=node1
ltgtep=node2
Res 201 Created
Location rd-group12
Looking up Group Members
Client RD
| |
| ----- GET rd-lookupepgp=lights1 ----------------------gt |
| |
| |
| lt-- 205 Content ltrdgtd=domain1ltrdgtd=domain2 --------- |
| |
Req GET rd-lookupepgp=lights1
Res 205 Content
ltcoaphostportgtep=node1
ltcoaphostportgtep=node2rdquo
Things for the futurebull Support for JSON representation of Web Links
ndash httptoolsietforgiddraft-bormann-core-links-json-02txtbull Registry for RD registration query parameters
ndash Already OMA Lightweight has defined some new onesbull More examples
Group 3 ldquonew workrdquo(continued)
109
drar-shy‐greevenbosch-shy‐core-shy‐profile-shy‐descripon-shy‐01Bert13 GreevenboschJeroen13 Hoebeke
Isam13 IshaqFloris13 Van13 den13 Abeele
Descripon
bull JSON13 format13 for13 signalling13 the13 servers13 capabilies
bull Signalling13 of13 supported13 opons13 media13 types13 and13 block13 sizendash Other13 items13 can13 be13 added
bull Filtering13 on13 specific13 fields13 through13 URI-shy‐Querybull Link13 hqpdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐profile-shy‐descripon
well-shy‐knownprofile
bull To13 acquire13 profile13 data13 of13 resources13 on13 a13 parcular13 service13 the13 well-shy‐knownprofile13 URI-shy‐path13 is13 introduced
bull For13 example13 to13 get13 all13 informaon13 from13 sensors13 served13 by13 wwwexampleorg13 we13 can13 do13 a13 GET13 to13 coapwwwexampleorgwell-shy‐knownprofile
bull Filtering13 on13 parcular13 resources13 is13 done13 through13 URI-shy‐Queries
Format
bull Currently13 the13 following13 fields13 are13 definedndash ldquopathrdquo13 contains13 the13 URI-shy‐path13 associated13 with13 a13 resource
ndash ldquooprdquo13 a13 numerical13 list13 of13 supported13 opon13 numbers
ndash ldquocfrdquo13 a13 numerical13 list13 of13 supported13 content-shy‐format13 numbers
ndash ldquob1srdquo13 ldquob2srdquo13 supported13 block13 sizes13 for13 Block113 and13 Block213 respecvely
Examplebull On13 the13 right13 is13 an13 example13 of13 a13 camera13 sensor13 at13 coapwwwexampleorgcam13 that13 supports13 the13 Uri-shy‐Host13 (3)13 ETag13 (4)13 Uri-shy‐Port13 (7)13 Uri-shy‐Path13 (11)13 Content-shy‐Format13 (12)13 Token13 (19)13 Block213 (23)13 and13 Proxy-shy‐Uri13 (35)13 opons
bull The13 supported13 content13 formats13 are13 textplain13 (0)13 applicaon13 link-shy‐format13 (40)13 and13 applicaonjson13 (50)
bull The13 supported13 Block213 can13 use13 25613 or13 51213 byte13 blocks
Req13 GET13 coapwwwexampleorgwell-shy‐knownprofile13 Res13 20513 Content13 (applicationjson)13 13 13 13 profile13 13 13 13 13 13 13 13 pathcam13 13 13 13 op[3471112192335]13 13 13 13 13 cf[04050]13 13 13 13 13 b2s[45]13 13 13 13
Filtering13 through13 use13 of13 URI-shy‐Query
bull Filtering13 can13 be13 done13 through13 the13 URI-shy‐Querybull Query13 format13 N=V
ndash N13 is13 a13 profile13 fieldndash V13 is13 the13 desired13 value
bull Examplesndash To13 find13 resources13 that13 support13 content13 format13 ldquoapplicaonjsonrdquo
13 GET13 wwwexampleorgwell-shy‐knownprofilecf=50ndash To13 get13 informaon13 about13 the13 camera
13 GET13 wwwexampleorgwell-shy‐knownprofilepath=cam
Open13 issues
bull Which13 other13 profile13 data13 needs13 signallingndash Content-shy‐type13 for13 different13 methods
bull Fix13 the13 order13 in13 which13 the13 profile13 fields13 must13 appearndash Non-shy‐fixed13 order13 easier13 extensible
bull Inheritance13 of13 a13 profile13 descriponbull Extend13 usage13 to13 signal13 the13 client13 profilebull Integraon13 with13 link13 format
Thank13 youQuesons
drar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval-shy‐00
Bert13 Greevenbosch
Descripon
bull The13 ldquoMinimumRequestInterval13 opon13 can13 be13 used13 to13 indicate13 the13 minimum13 me13 between13 two13 requests13 in13 a13 transacon
bull Originally13 intended13 for13 Block13 but13 also13 usable13 for13 other13 transaconsndash Example13 browsing13 a13 server
bull The13 goal13 is13 to13 reduce13 the13 server13 load13 and13 network13 traffic
bull Link13 hqpsdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval
Usage
bull The13 client13 keeps13 the13 server13 informed13 about13 its13 request13 speed13 through13 inclusion13 of13 the13 ldquoMinimumRequestIntervalrdquo13 opon
bull In13 responses13 the13 server13 fixes13 the13 minimum13 request13 interval13 through13 the13 same13 opon
bull The13 client13 obeys13 the13 speed13 indicated13 by13 the13 server
bull The13 client13 can13 send13 slower13 but13 not13 faster
Advantages
bull The13 server13 has13 means13 to13 limit13 the13 amount13 of13 incoming13 traffic
bull The13 server13 can13 prevent13 to13 become13 overloaded13 with13 too13 many13 tasks
bull The13 server13 does13 not13 need13 arficially13 slow13 down13 the13 client13 by13 sending13 late13 ACKsndash No13 need13 to13 keep13 track13 of13 delayed13 ACKsndash The13 server13 can13 perform13 other13 tasks13 instead
bull Reduced13 network13 traffic
Thank13 youQuesons
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-links-json-02txt
123
RFC 6690 (link-format) documents are somewhat foreign to many web app developerssect would prefer to have them in JSON format
There is no standard way to represent link-format documents in applicationssect but everyone knows how to handle JSON
Define a standard JSON translation for link-format
Itrsquos
not
rock
et
scien
ce
ltsensorsgtct=40title=Sensor Index ltsensorstempgtrt=temperature-cif=sensor ltsensorslightgtrt=light-luxif=sensor lthttpwwwexamplecomsensorst123gt anchor=sensorstemprel=describedby lttgtanchor=sensorstemprel=alternate [hrefsensorsct40titleSensor Index hrefsensorstemprttemperature-cifsensor hrefsensorslightrtlight-luxifsensor hrefhttpwwwexamplecomsensorst123 anchorsensorstempreldescribedby hreftanchorsensorstemprelalternate]
124
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-ipsec-for-coap-00txt
IPsec definitions for CoAP Mostly placeholder at this time Who has implementation experience with this
125
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-cross-reverse-convention-00txt
This draft has two lines of payload(based on a WGLC comment by Cullen Jennings)
coap12344567foobara=3
httpwwwproxycomwellknowncore-translate1234_4567foobara=3
Is that a useful convention to have
126
Insert CI slides here
127
128
0
5
10
15
20
25
30
35
40
10 20 30 40 50 60 70
good
put (
pps)
pps
Goodput vs pps (Econotags)
goodput
[Khattak preliminary]
Congestion Control
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-cocoa-00txt
ldquoadvancedrdquo cc (The draft is just a first shot) Others may have better ideas
129
Insert post-WGLC discussion slides here
130
Stop Continue Start
131
An Agile Retrospective
http6lowappnet coreIETF86 2013-03-12-13
Stop
132
Endless new CoAP optionssect instead use RESTful as much as possible
Move general security lifecycle out Looking at theoretical problems
http6lowappnet coreIETF86 2013-03-12-13
Continue
Interops Running code Look at real-world examples and deployments Solve their actual problems
sect Unilateral enhancements eg higher performance congestion control
sect Transports (SMS hellip)sect Make Web linking and Directories more and more usefulsect RESTful Design Paradigms for real-world problems
133
http6lowappnet coreIETF86 2013-03-12-13
Start
Further push into the (browser) web world (HTML5 browser security)
Specific supporting worksect SenMLsect URI work (dev URN hellip)sect Security Processes (next slide)
Spin outsect (We donrsquot really get to decide where this is done)
134
http6lowappnet coreIETF86 2013-03-12-13
Security
Integrate Application Network Group Keyingsect Tunnel-free setup
Donrsquot redo what has been done alreadysect ZigBee IP is finesect But what about other scenarios
Simple REST interfaces for working with keying materials and authorizationsect Start with defining objectives
Object Security for Constrained Nodes135
Re-chartering CoREWhat do we want to do now that wersquore grown up
Zach ShelbyCoRE WG IETF-86 Orlando
What is the scope
bull So we have a protocol and Web Linking what next
bull Keep with what we know besthellip1 Enhancements around CoAP2 New transports for CoAP3 New representations for Web Links4 General application layer solutions
CoRE WG IETF-86 Orlando 2
Enhancements around CoAP
bull Advanced congestion control
CoRE WG IETF-86 Orlando 3
New Transports for CoAP
bull Infrastructure for CoAP over foondash httptoolsietforgiddraft-silverajan-core-
coap-alternative-transports-01txtbull CoAP over SMS
ndash httptoolsietforgiddraft-becker-core-coap-sms-gprs-03txt
ndash OMA Lightweightbull CoAP over TCP
ndash httptoolsietforgiddraft-li-core-coap-payload-length-option-01txt
CoRE WG IETF-86 Orlando 4
New support for Web Links
bull JSON Web Linksndash httptoolsietforgiddraft-bormann-core-links-
json-02txt
2332010 CoRE WG IETF-77 Anaheim 5
General application layer solutions
bull Resource Directoryndash httptoolsietforgiddraft-shelby-core-
resource-directory-05txtndash OMA Lightweight
2332010 CoRE WG IETF-77 Anaheim 6
031113
URI13 Representaons13 for13 CoAPMeans13 of13 expressing13 transport13 types
bull As13 a13 URI13 query13 componentndash coaphostexamplecomwell-shy‐knowncorert=core-shy‐rdq=tcp
bull Also13 easy13 to13 adopt13 new13 (and13 experimental)13 CoAP13 transports13 without13 IANA13 registraon
bull Caveat13 Uri-shy‐Query13 opon13 is13 a13 Crical13 CoAP13 opon13 see13 secon13 54113 of13 I-shy‐Diep-shy‐core-shy‐coap
60
031113
URI13 Representaons13 for13 CoAPNon13 standard13 ways
bull Transport13 in13 the13 URI13 authority13 componentndash coaphost[port][transport]13 instead13 of13 coaphost[port]
bull Transport13 as13 a13 service13 URLndash servicecoaptcphostexamplecomwell-shy‐knowncorert=core-shy‐rd
bull Above13 two13 ways13 break13 exisng13 compability13 (although13 both13 are13 based13 on13 valid13 IANA13 URI13 registraons)
61
031113
URI13 Representaons13 for13 CoAPMiscellaneous13 Consideraons
bull Ensure13 that13 transport13 is13 defined13 unambiguously13 (eg13 L2CAP13 used13 by13 both13 BLE13 and13 standard13 Bluetooth13 so13 avoid13 rdquocoap+l2caprdquo13 or13 rdquotransport=l2caprdquo13 or13 rdquoq=l2caprdquondash Can13 be13 done13 as13 WG13 consensusndash Namespace13 approach13 eg13 rdquocoap+blel2caprdquo13 or13 rdquoq=blel2caprdquo
bull Allow13 end-shy‐points13 to13 use13 CoAP13 Resource13 Directory13 to13 register13 alternave13 transports13 and13 idenfiers13 and13 provide13 periodic13 updatesndash Register13 rdquocore-shy‐transportrdquo13 resource13 type
62
031113
Transport13 Consideraons
bull Uniqueness13 of13 end-shy‐point13 idenficaonbull Communicaon13 support13 Unidireconal13 Bidireconal13 1N13 (broadcast13 mulcast13 anycast)13 messaging
bull Binary13 encoding13 Network13 byte13 orderingbull MTU13 correlaon13 with13 CoAP13 PDU13 sizebull Transport13 latency
63
031113
Security13 Consideraons
bull Drar13 does13 not13 introduce13 new13 security13 requirements13 by13 itself
bull There13 may13 be13 privacy13 issues13 if13 nodes13 use13 telephone13 numbers13 or13 MAC13 addresses13 as13 public13 end13 point13 idenfiers
64
Akbar Rahman
IETF 86 March 2013 httpwwwietforgiddraft-rahman-core-sleepy-02txt
Enhanced Sleepy Node Support for CoAP
Introduction
It is expected that in CoAP networks there will be a certain portion of devices that are sleepy and which may occasionally go into a sleep mode (ie go into a low power state to conserve power) and subsequently have reduced CoAP protocol communication ability
This I-D proposes a minimal and efficient mechanism building on the Resource Directory concept (which will be integrated into a CoAP Proxy) to enhance sleepy node support in CoAP networks
Main Question from IETF-85 (Atlanta)
What performance benefit does the proposed Sleepy Node support solution give in a network that already has standard CoAP caching enabled
Sleepy Node Performance Analysis
Experimental Network
1-5 clients
Both Sleepy and Non-
Sleepy servers
Sleepy Node Performance Analysis Network Setup
CoAPSleepyServer(s)
CoAPSleepAwareReverseProxy
CoAP
Client(s)
Request
Response
Sleep9AwareCoREResourceDirectoryCapability
PublishedSleepParameters
Sleep9AwareCoAPStoreandForwardCapability Response
Request
SleepAwareCoAP503ResponseCapability
CoAPCachingCapability
bull Server supports publishing sleep parameters to proxy bull Eg Irsquom going to be asleep for X seconds
bull Proxy supports sleep-awareness capabilities bull Proxy also supports caching capability based off of maxAge bull Protocol flow similar to approach of Figure 1 (Synchronous RD Based Sleep
Tracking) of I-D
Proxy capabilities can be selectively enableddisabled
Proxy ndash Server Interface
Client ndash Proxy Interface
CoAP Sleep-Aware Reverse Proxy Features CoRE Sleep-aware Resource Directory
Support storing published sleep parameters from CoAP servers sleepState (AWAKE ASLEEP) sleepDuration
Sleep-aware CoAP 503 Response Capability If CoAP request to a sleeping server is received proxy returns a
lsquo503 Retry-Afterrsquo response to client 503 contains a timestamp indicating when the sever will wake back up
(timestamp delivered in CoAP maxAge option) Sleep-aware CoAP Store-and-Forward Capability
If CoAP request to a sleeping server is received proxy stores request until server wakes up and then forwards it
Caching capability Cache GET responses from server if maxAge option is present
(this is not a sleep aware feature)
Goals of Performance Analysis
For networks having sleepy servers provide measurements to quantify the impact that CoAP sleep-awareness capabilities can have
See if sleep-awareness capabilities can
provide additional benefits even when CoAP caching is used
Overview of Performance Analysis Performed The analysis was broken up into a set of test scenarios Each test scenario used a different combination of the following
variables Client issued GET requests Server was configured as a sleepy or non-sleepy server Proxy caching of GET responses was enabled or disabled Proxy sleep-aware 503 response capability was enabled or disabled Proxy store-and-forward capability was enabled or disabled maxAge in GET responses ndash Two values were tested 60sec and 5sec of Clients ndash Two values were used ndash 1 client and 5 clients
For comparison purposes the following were held constant across all test scenarios Client issued a fixed number of requests (100) across all test scenarios Client used a delay between each GET request (35sec) to better exercise
proxyrsquos caching and sleep-awareness capabilities For sleepy server test scenarios the server slept 60 sec awake for 3 sec
Format of Results The following results were collected for each
test scenario
Breakdown of the and types of transactions occurring between clientproxyserver
ldquoGETrdquo ndash Test Scenario Results
GET ndash Description of Test Scenarios
TestScenarios-GET
Scenario
CoAPSleepyServerSe7ngs CoAPSleepAwareReverseProxySe7ngs CoAPClientSe7ngs
SleepDuragton(sec)
AwakeDuragton(sec)
maxAge(sec) Caching SleepAwareSAF+
503NumberofClients
NumberofGETs
DelayBetweenClient
Requests(sec)
1a 0 Always 60 Enabled Disabled 1 100 35
1b 60 3 60 Enabled Disabled 1 100 35
1c 60 3 60 Enabled Enabled 1 100 35
2a 0 Always 60 Enabled Disabled 5 100 35
2b 60 3 60 Enabled Disabled 5 100 35
2c 60 3 60 Enabled Enabled 5 100 35
3a 0 Always 5 Enabled Disabled 5 100 35
3b 60 3 5 Enabled Disabled 5 100 35
3c 60 3 5 Enabled Enabled 5 100 35
ldquoGETrdquo ndash Test Scenario 1 Results
maxAge = 60 and 1 Client
GET ndash Scenario 1 ClientProxy Interface Transaction Mix
Scenarios 1a - Non-Sleepy Server Caching Proxy maxAge = 60sec 1b- Sleepy Server Caching Proxy maxAge = 60sec 1c - Sleepy Server Sleep Aware Proxy maxAge = 60sec
Sleep Aware Proxy has better performance for sleepy servers
0
100
200
300
400
500
600
700
1a 1b 1c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
GET ndash Scenario 1 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
Scenarios 1a - Non-Sleepy Server Caching Proxy maxAge = 60sec 1b- Sleepy Server Caching Proxy maxAge = 60sec 1c - Sleepy Server Sleep Aware Proxy maxAge = 60sec
0
100
200
300
400
500
600
700
800
1a 1b 1c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
ldquoGETrdquo ndash Test Scenario 2 Results
maxAge = 60 and 5 Clients
GET ndash Scenario 2 ClientProxy Interface Transaction Mix
Sleep Aware Proxy has slightly better performance for sleepy servers
0
200
400
600
800
1000
1200
1400
2a 2b 2c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
Scenarios 2a - Non-Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2b- Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2c - Sleepy Server Sleep Aware Proxy maxAge = 60sec 5 Clients
See ldquoExperimental Artifactsrdquo Note 1
GET ndash Scenario 2 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has slightly better performance for sleepy servers
0
50
100
150
200
250
300
350
400
2a 2b 2c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
Scenarios 2a - Non-Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2b- Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2c - Sleepy Server Sleep Aware Proxy maxAge = 60sec 5 Clients
See ldquoExperimental Artifactsrdquo Note 2
Experimental Artifacts Note 1
Currently in the experiment the sleep aware proxy checks the cached state of a resource before putting a request into its Store-and-forward queue while a server is sleeping Once in the queue the proxy unconditionally forwards the queued requests to the server once it wakes up This is not the most efficient setup and can easily be improved If the proxy instead checks its cache again before forwarding each queued request it may not need to forward the request to the server For example if there are two queued GET requests in the proxyrsquos queue that address the same resource Only the first request needs to be sent to the server the second request can use the cached response from the first request
Note 2 Currently in the experiment the sleepy server sends a sleepState PUT request to the
proxy each time it goes to sleep This is not the most efficient setup and can easily be improved For example if the server assumes that the proxy can keep track of its ONOFF cycles with its internal timers (eg as per Fig 1 of I-D) then the number of messages from the sleepy server dramatically goes down
ldquoGETrdquo ndash Test Scenario 3 Results
maxAge = 5 and 5 Clients
GET ndash Scenario 3 ClientProxy Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
Scenarios 3a - Non-Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3b- Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3c - Sleepy Server Sleep Aware Proxy maxAge = 5sec 5 Clients
0
500
1000
1500
2000
2500
3000
3500
4000
4500
5000
3a 3b 3c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
GET ndash Scenario 3 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
0
1000
2000
3000
4000
5000
6000
7000
3a 3b 3c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
Scenarios 3a - Non-Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3b- Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3c - Sleepy Server Sleep Aware Proxy maxAge = 5sec 5 Clients
Conclusions
Conclusions These results show that sleep-aware CoAP
proxy features can significantly optimize communication with sleepy servers in most scenarios
These results also show that sleep-
awareness capabilities can provide additional benefits above and beyond CoAP caching in most scenarios
Backup
Current CoAP Support of Sleepy Node (12)
CoAP proxies can use a previously cached response to service a new GET request for a sleepy origin server (as in HTTP) But if no valid cache then proxy has to attempt to
retrieve and may fail if origin server is sleeping [I-Dietf-core-coap]
Clients can discover list of resources from RD (GET rd-lookuphellip) for sleepy servers But attempt to GET resource from sleepy origin server
may fail if origin server is sleeping [IDietf-core-link-format amp IDshelby-core-resource-
directory]
Current CoAP Support of Sleepy Node (22)
Lower layer support for sleepy nodes in most wireless technologies (eg WiFi ZigBee) But limited to MAC packet scheduling for sleepy nodes
and not aware of specific needs of IP applications (like CoAP)
Proposal ndash RD Based Sleep Tracking (14)
The current CoAP approach to support sleepy nodes can be significantly improved by introducing RD based mechanisms for a CoAP client to determine whether A targeted resource is located on a sleepy server A sleepy server is currently in sleep mode or not
There is any associated caching Proxy (possibly the RD itself) for a sleepy server
Proposal ndash RD Based Sleep Tracking (24)
We define the following new RD attributes to characterize the properties of a sleepy node SleepState - Indicates whether the node is currently in
sleep mode or not (ie Sleeping or Awake) SleepDuration - Indicates the maximum duration of time
that the node stays in sleep mode TimeSleeping - Indicates the length of time the node
has been sleeping (ie if Sleep State = Sleeping) NextSleep - Indicates the next time the node will go to
sleep (ie if Sleep State = Awake)
CachingProxy ndash Indicates the caching proxy of the sleepy node (ie the RD itself or another node)
Proposal ndash RD Based Sleep Tracking (34)
These attributes are all server (node) level and are new parameters added to the RD URI Template Variables
Finally we also define a new lookup-type (ss) for the RD lookup interface specified in [I-Dshelby-core-resource-directory] This new lookup-type supports looking up the
ldquoSleepStaterdquo (ss) of a specified end-point
Proposal ndash RD Based Sleep Tracking (44)
The three time based parameters (SleepDuration TimeSleeping NextSleep) can be based on either an absolute network time (for a time synchronized network) or a relative local time (measured at the local node)
Following the approach of [I-Dietf-core-link-format] and [I-Dshelby-core-resource-directory] sleep parameters for sleepy servers can be stored by the server in the RD and accessed by all interested clients
Examples of using these parameters in a synchronous or asynchronous manner are shown in the I-D
http6lowappnet coreIETF86 2013-03-12-13
We assume people have read the drafts
Meetings serve to advance difficult issues by making good use of face-to-face communications
Note Well Be aware of the IPR principles according to RFC 3979 and its updates
uumlBlue sheetsuumlScribe(s)
96
drar-shy‐iep-shy‐core-shy‐coapsubmiqed13 to13 IESG
2013-shy‐03-shy‐13
97
OMA Lightweight M2M Overview(A new standard using lots of IETF specs including DTLS
CoAP Block Observe Resource Directory SenMLhellip)
Zach ShelbyCoRE WG IETF-86 Orlando
OMA Lightweight M2Mbull Open Mobile Alliance is well known for Device Management (DM)bull OMA Lightweight M2M is a new standard from the alliance
ndash Focused on constrained Cellular and sensor network M2M devicesndash Driven by leading operators and vendors
bull Scopendash Interfaces protocol amp security between Device and Serverndash Object and Resource modelndash Bootstrap Device Access Control Connectivity and Firmware Objects
bull Draft Specifications are availablendash httpmemberopenmobileallianceorgftpPublic_documentsDM
LightweightM2MPermanent_documentsOMA-TS-LightweightM2M-V1_0_0-20130301-Dzip
bull Timelinendash Requirements and Architecture completed 3Q2012ndash Spec ready for Consistency Review 2Q2013ndash Candidate Approval expected 3Q2013
2 CoRE WG IETF-86 Orlando
Architecture
3
Scope of LWM2M
CoRE WG IETF-86 Orlando
Object Model
bull A Client has one or more Object Instancesbull An Object is a collection of Resourcesbull A Resource is an atomic piece of information
ndash Read Written or Executed
bull Resources can have multiple instancesbull Objects and Resources are identified by a
16-bit Integer Instances by an 8-bit Integerbull ObjectsResources are accessed with
simple URIs Object IDObject InstanceResource ID
eg 1213
4 CoRE WG IETF-86 Orlando
CoRE WG IETF-86 Orlando
CoRE Resource Directory
draft-shelby-core-resource-directory-05
Z Shelby C Bormann S Krco
Backgroundbull Not a new concept
ndash think web search engine or any link directorybull Defines the interfaces to a Resource Directorybull Based on Web Linking framework and the CoRE Link Formatbull Generic REST design for use over HTTP and CoAPbull Used by OMA Lightweight M2Mbull Has already been deployed
ndash In traffic monitoring systemsndash In street lighting systemsndash For vehicular asset trackingndash By a major Cellular M2M operator
Changes since -04
bull Restricted Update to parameter updatesbull Added pagination support for the Lookup interfacebull Changed rt= to et= for the registration amp update
interfacebull Added group support
Group Management
bull RD now includes group management featuresbull New Group Function Set
ndash Register a groupbull Group name domain multicast address endpoint members
ndash Remove a groupbull Group lookup using the Lookup Function Set
ndash List registered groupsndash Find the members of a groupndash Find groups with certain endpoints or resources
Registering a Group
EP RD
| |
| - POST rd-groupgp=lights ltgtep=node1 --gt |
| |
| |
| lt---- 201 Created Location rd-group12 ---- |
| |
Req POST coaprdexamplecomrd-groupgp=lights
Payload
ltgtep=node1
ltgtep=node2
Res 201 Created
Location rd-group12
Looking up Group Members
Client RD
| |
| ----- GET rd-lookupepgp=lights1 ----------------------gt |
| |
| |
| lt-- 205 Content ltrdgtd=domain1ltrdgtd=domain2 --------- |
| |
Req GET rd-lookupepgp=lights1
Res 205 Content
ltcoaphostportgtep=node1
ltcoaphostportgtep=node2rdquo
Things for the futurebull Support for JSON representation of Web Links
ndash httptoolsietforgiddraft-bormann-core-links-json-02txtbull Registry for RD registration query parameters
ndash Already OMA Lightweight has defined some new onesbull More examples
Group 3 ldquonew workrdquo(continued)
109
drar-shy‐greevenbosch-shy‐core-shy‐profile-shy‐descripon-shy‐01Bert13 GreevenboschJeroen13 Hoebeke
Isam13 IshaqFloris13 Van13 den13 Abeele
Descripon
bull JSON13 format13 for13 signalling13 the13 servers13 capabilies
bull Signalling13 of13 supported13 opons13 media13 types13 and13 block13 sizendash Other13 items13 can13 be13 added
bull Filtering13 on13 specific13 fields13 through13 URI-shy‐Querybull Link13 hqpdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐profile-shy‐descripon
well-shy‐knownprofile
bull To13 acquire13 profile13 data13 of13 resources13 on13 a13 parcular13 service13 the13 well-shy‐knownprofile13 URI-shy‐path13 is13 introduced
bull For13 example13 to13 get13 all13 informaon13 from13 sensors13 served13 by13 wwwexampleorg13 we13 can13 do13 a13 GET13 to13 coapwwwexampleorgwell-shy‐knownprofile
bull Filtering13 on13 parcular13 resources13 is13 done13 through13 URI-shy‐Queries
Format
bull Currently13 the13 following13 fields13 are13 definedndash ldquopathrdquo13 contains13 the13 URI-shy‐path13 associated13 with13 a13 resource
ndash ldquooprdquo13 a13 numerical13 list13 of13 supported13 opon13 numbers
ndash ldquocfrdquo13 a13 numerical13 list13 of13 supported13 content-shy‐format13 numbers
ndash ldquob1srdquo13 ldquob2srdquo13 supported13 block13 sizes13 for13 Block113 and13 Block213 respecvely
Examplebull On13 the13 right13 is13 an13 example13 of13 a13 camera13 sensor13 at13 coapwwwexampleorgcam13 that13 supports13 the13 Uri-shy‐Host13 (3)13 ETag13 (4)13 Uri-shy‐Port13 (7)13 Uri-shy‐Path13 (11)13 Content-shy‐Format13 (12)13 Token13 (19)13 Block213 (23)13 and13 Proxy-shy‐Uri13 (35)13 opons
bull The13 supported13 content13 formats13 are13 textplain13 (0)13 applicaon13 link-shy‐format13 (40)13 and13 applicaonjson13 (50)
bull The13 supported13 Block213 can13 use13 25613 or13 51213 byte13 blocks
Req13 GET13 coapwwwexampleorgwell-shy‐knownprofile13 Res13 20513 Content13 (applicationjson)13 13 13 13 profile13 13 13 13 13 13 13 13 pathcam13 13 13 13 op[3471112192335]13 13 13 13 13 cf[04050]13 13 13 13 13 b2s[45]13 13 13 13
Filtering13 through13 use13 of13 URI-shy‐Query
bull Filtering13 can13 be13 done13 through13 the13 URI-shy‐Querybull Query13 format13 N=V
ndash N13 is13 a13 profile13 fieldndash V13 is13 the13 desired13 value
bull Examplesndash To13 find13 resources13 that13 support13 content13 format13 ldquoapplicaonjsonrdquo
13 GET13 wwwexampleorgwell-shy‐knownprofilecf=50ndash To13 get13 informaon13 about13 the13 camera
13 GET13 wwwexampleorgwell-shy‐knownprofilepath=cam
Open13 issues
bull Which13 other13 profile13 data13 needs13 signallingndash Content-shy‐type13 for13 different13 methods
bull Fix13 the13 order13 in13 which13 the13 profile13 fields13 must13 appearndash Non-shy‐fixed13 order13 easier13 extensible
bull Inheritance13 of13 a13 profile13 descriponbull Extend13 usage13 to13 signal13 the13 client13 profilebull Integraon13 with13 link13 format
Thank13 youQuesons
drar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval-shy‐00
Bert13 Greevenbosch
Descripon
bull The13 ldquoMinimumRequestInterval13 opon13 can13 be13 used13 to13 indicate13 the13 minimum13 me13 between13 two13 requests13 in13 a13 transacon
bull Originally13 intended13 for13 Block13 but13 also13 usable13 for13 other13 transaconsndash Example13 browsing13 a13 server
bull The13 goal13 is13 to13 reduce13 the13 server13 load13 and13 network13 traffic
bull Link13 hqpsdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval
Usage
bull The13 client13 keeps13 the13 server13 informed13 about13 its13 request13 speed13 through13 inclusion13 of13 the13 ldquoMinimumRequestIntervalrdquo13 opon
bull In13 responses13 the13 server13 fixes13 the13 minimum13 request13 interval13 through13 the13 same13 opon
bull The13 client13 obeys13 the13 speed13 indicated13 by13 the13 server
bull The13 client13 can13 send13 slower13 but13 not13 faster
Advantages
bull The13 server13 has13 means13 to13 limit13 the13 amount13 of13 incoming13 traffic
bull The13 server13 can13 prevent13 to13 become13 overloaded13 with13 too13 many13 tasks
bull The13 server13 does13 not13 need13 arficially13 slow13 down13 the13 client13 by13 sending13 late13 ACKsndash No13 need13 to13 keep13 track13 of13 delayed13 ACKsndash The13 server13 can13 perform13 other13 tasks13 instead
bull Reduced13 network13 traffic
Thank13 youQuesons
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-links-json-02txt
123
RFC 6690 (link-format) documents are somewhat foreign to many web app developerssect would prefer to have them in JSON format
There is no standard way to represent link-format documents in applicationssect but everyone knows how to handle JSON
Define a standard JSON translation for link-format
Itrsquos
not
rock
et
scien
ce
ltsensorsgtct=40title=Sensor Index ltsensorstempgtrt=temperature-cif=sensor ltsensorslightgtrt=light-luxif=sensor lthttpwwwexamplecomsensorst123gt anchor=sensorstemprel=describedby lttgtanchor=sensorstemprel=alternate [hrefsensorsct40titleSensor Index hrefsensorstemprttemperature-cifsensor hrefsensorslightrtlight-luxifsensor hrefhttpwwwexamplecomsensorst123 anchorsensorstempreldescribedby hreftanchorsensorstemprelalternate]
124
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-ipsec-for-coap-00txt
IPsec definitions for CoAP Mostly placeholder at this time Who has implementation experience with this
125
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-cross-reverse-convention-00txt
This draft has two lines of payload(based on a WGLC comment by Cullen Jennings)
coap12344567foobara=3
httpwwwproxycomwellknowncore-translate1234_4567foobara=3
Is that a useful convention to have
126
Insert CI slides here
127
128
0
5
10
15
20
25
30
35
40
10 20 30 40 50 60 70
good
put (
pps)
pps
Goodput vs pps (Econotags)
goodput
[Khattak preliminary]
Congestion Control
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-cocoa-00txt
ldquoadvancedrdquo cc (The draft is just a first shot) Others may have better ideas
129
Insert post-WGLC discussion slides here
130
Stop Continue Start
131
An Agile Retrospective
http6lowappnet coreIETF86 2013-03-12-13
Stop
132
Endless new CoAP optionssect instead use RESTful as much as possible
Move general security lifecycle out Looking at theoretical problems
http6lowappnet coreIETF86 2013-03-12-13
Continue
Interops Running code Look at real-world examples and deployments Solve their actual problems
sect Unilateral enhancements eg higher performance congestion control
sect Transports (SMS hellip)sect Make Web linking and Directories more and more usefulsect RESTful Design Paradigms for real-world problems
133
http6lowappnet coreIETF86 2013-03-12-13
Start
Further push into the (browser) web world (HTML5 browser security)
Specific supporting worksect SenMLsect URI work (dev URN hellip)sect Security Processes (next slide)
Spin outsect (We donrsquot really get to decide where this is done)
134
http6lowappnet coreIETF86 2013-03-12-13
Security
Integrate Application Network Group Keyingsect Tunnel-free setup
Donrsquot redo what has been done alreadysect ZigBee IP is finesect But what about other scenarios
Simple REST interfaces for working with keying materials and authorizationsect Start with defining objectives
Object Security for Constrained Nodes135
Re-chartering CoREWhat do we want to do now that wersquore grown up
Zach ShelbyCoRE WG IETF-86 Orlando
What is the scope
bull So we have a protocol and Web Linking what next
bull Keep with what we know besthellip1 Enhancements around CoAP2 New transports for CoAP3 New representations for Web Links4 General application layer solutions
CoRE WG IETF-86 Orlando 2
Enhancements around CoAP
bull Advanced congestion control
CoRE WG IETF-86 Orlando 3
New Transports for CoAP
bull Infrastructure for CoAP over foondash httptoolsietforgiddraft-silverajan-core-
coap-alternative-transports-01txtbull CoAP over SMS
ndash httptoolsietforgiddraft-becker-core-coap-sms-gprs-03txt
ndash OMA Lightweightbull CoAP over TCP
ndash httptoolsietforgiddraft-li-core-coap-payload-length-option-01txt
CoRE WG IETF-86 Orlando 4
New support for Web Links
bull JSON Web Linksndash httptoolsietforgiddraft-bormann-core-links-
json-02txt
2332010 CoRE WG IETF-77 Anaheim 5
General application layer solutions
bull Resource Directoryndash httptoolsietforgiddraft-shelby-core-
resource-directory-05txtndash OMA Lightweight
2332010 CoRE WG IETF-77 Anaheim 6
031113
URI13 Representaons13 for13 CoAPNon13 standard13 ways
bull Transport13 in13 the13 URI13 authority13 componentndash coaphost[port][transport]13 instead13 of13 coaphost[port]
bull Transport13 as13 a13 service13 URLndash servicecoaptcphostexamplecomwell-shy‐knowncorert=core-shy‐rd
bull Above13 two13 ways13 break13 exisng13 compability13 (although13 both13 are13 based13 on13 valid13 IANA13 URI13 registraons)
61
031113
URI13 Representaons13 for13 CoAPMiscellaneous13 Consideraons
bull Ensure13 that13 transport13 is13 defined13 unambiguously13 (eg13 L2CAP13 used13 by13 both13 BLE13 and13 standard13 Bluetooth13 so13 avoid13 rdquocoap+l2caprdquo13 or13 rdquotransport=l2caprdquo13 or13 rdquoq=l2caprdquondash Can13 be13 done13 as13 WG13 consensusndash Namespace13 approach13 eg13 rdquocoap+blel2caprdquo13 or13 rdquoq=blel2caprdquo
bull Allow13 end-shy‐points13 to13 use13 CoAP13 Resource13 Directory13 to13 register13 alternave13 transports13 and13 idenfiers13 and13 provide13 periodic13 updatesndash Register13 rdquocore-shy‐transportrdquo13 resource13 type
62
031113
Transport13 Consideraons
bull Uniqueness13 of13 end-shy‐point13 idenficaonbull Communicaon13 support13 Unidireconal13 Bidireconal13 1N13 (broadcast13 mulcast13 anycast)13 messaging
bull Binary13 encoding13 Network13 byte13 orderingbull MTU13 correlaon13 with13 CoAP13 PDU13 sizebull Transport13 latency
63
031113
Security13 Consideraons
bull Drar13 does13 not13 introduce13 new13 security13 requirements13 by13 itself
bull There13 may13 be13 privacy13 issues13 if13 nodes13 use13 telephone13 numbers13 or13 MAC13 addresses13 as13 public13 end13 point13 idenfiers
64
Akbar Rahman
IETF 86 March 2013 httpwwwietforgiddraft-rahman-core-sleepy-02txt
Enhanced Sleepy Node Support for CoAP
Introduction
It is expected that in CoAP networks there will be a certain portion of devices that are sleepy and which may occasionally go into a sleep mode (ie go into a low power state to conserve power) and subsequently have reduced CoAP protocol communication ability
This I-D proposes a minimal and efficient mechanism building on the Resource Directory concept (which will be integrated into a CoAP Proxy) to enhance sleepy node support in CoAP networks
Main Question from IETF-85 (Atlanta)
What performance benefit does the proposed Sleepy Node support solution give in a network that already has standard CoAP caching enabled
Sleepy Node Performance Analysis
Experimental Network
1-5 clients
Both Sleepy and Non-
Sleepy servers
Sleepy Node Performance Analysis Network Setup
CoAPSleepyServer(s)
CoAPSleepAwareReverseProxy
CoAP
Client(s)
Request
Response
Sleep9AwareCoREResourceDirectoryCapability
PublishedSleepParameters
Sleep9AwareCoAPStoreandForwardCapability Response
Request
SleepAwareCoAP503ResponseCapability
CoAPCachingCapability
bull Server supports publishing sleep parameters to proxy bull Eg Irsquom going to be asleep for X seconds
bull Proxy supports sleep-awareness capabilities bull Proxy also supports caching capability based off of maxAge bull Protocol flow similar to approach of Figure 1 (Synchronous RD Based Sleep
Tracking) of I-D
Proxy capabilities can be selectively enableddisabled
Proxy ndash Server Interface
Client ndash Proxy Interface
CoAP Sleep-Aware Reverse Proxy Features CoRE Sleep-aware Resource Directory
Support storing published sleep parameters from CoAP servers sleepState (AWAKE ASLEEP) sleepDuration
Sleep-aware CoAP 503 Response Capability If CoAP request to a sleeping server is received proxy returns a
lsquo503 Retry-Afterrsquo response to client 503 contains a timestamp indicating when the sever will wake back up
(timestamp delivered in CoAP maxAge option) Sleep-aware CoAP Store-and-Forward Capability
If CoAP request to a sleeping server is received proxy stores request until server wakes up and then forwards it
Caching capability Cache GET responses from server if maxAge option is present
(this is not a sleep aware feature)
Goals of Performance Analysis
For networks having sleepy servers provide measurements to quantify the impact that CoAP sleep-awareness capabilities can have
See if sleep-awareness capabilities can
provide additional benefits even when CoAP caching is used
Overview of Performance Analysis Performed The analysis was broken up into a set of test scenarios Each test scenario used a different combination of the following
variables Client issued GET requests Server was configured as a sleepy or non-sleepy server Proxy caching of GET responses was enabled or disabled Proxy sleep-aware 503 response capability was enabled or disabled Proxy store-and-forward capability was enabled or disabled maxAge in GET responses ndash Two values were tested 60sec and 5sec of Clients ndash Two values were used ndash 1 client and 5 clients
For comparison purposes the following were held constant across all test scenarios Client issued a fixed number of requests (100) across all test scenarios Client used a delay between each GET request (35sec) to better exercise
proxyrsquos caching and sleep-awareness capabilities For sleepy server test scenarios the server slept 60 sec awake for 3 sec
Format of Results The following results were collected for each
test scenario
Breakdown of the and types of transactions occurring between clientproxyserver
ldquoGETrdquo ndash Test Scenario Results
GET ndash Description of Test Scenarios
TestScenarios-GET
Scenario
CoAPSleepyServerSe7ngs CoAPSleepAwareReverseProxySe7ngs CoAPClientSe7ngs
SleepDuragton(sec)
AwakeDuragton(sec)
maxAge(sec) Caching SleepAwareSAF+
503NumberofClients
NumberofGETs
DelayBetweenClient
Requests(sec)
1a 0 Always 60 Enabled Disabled 1 100 35
1b 60 3 60 Enabled Disabled 1 100 35
1c 60 3 60 Enabled Enabled 1 100 35
2a 0 Always 60 Enabled Disabled 5 100 35
2b 60 3 60 Enabled Disabled 5 100 35
2c 60 3 60 Enabled Enabled 5 100 35
3a 0 Always 5 Enabled Disabled 5 100 35
3b 60 3 5 Enabled Disabled 5 100 35
3c 60 3 5 Enabled Enabled 5 100 35
ldquoGETrdquo ndash Test Scenario 1 Results
maxAge = 60 and 1 Client
GET ndash Scenario 1 ClientProxy Interface Transaction Mix
Scenarios 1a - Non-Sleepy Server Caching Proxy maxAge = 60sec 1b- Sleepy Server Caching Proxy maxAge = 60sec 1c - Sleepy Server Sleep Aware Proxy maxAge = 60sec
Sleep Aware Proxy has better performance for sleepy servers
0
100
200
300
400
500
600
700
1a 1b 1c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
GET ndash Scenario 1 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
Scenarios 1a - Non-Sleepy Server Caching Proxy maxAge = 60sec 1b- Sleepy Server Caching Proxy maxAge = 60sec 1c - Sleepy Server Sleep Aware Proxy maxAge = 60sec
0
100
200
300
400
500
600
700
800
1a 1b 1c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
ldquoGETrdquo ndash Test Scenario 2 Results
maxAge = 60 and 5 Clients
GET ndash Scenario 2 ClientProxy Interface Transaction Mix
Sleep Aware Proxy has slightly better performance for sleepy servers
0
200
400
600
800
1000
1200
1400
2a 2b 2c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
Scenarios 2a - Non-Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2b- Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2c - Sleepy Server Sleep Aware Proxy maxAge = 60sec 5 Clients
See ldquoExperimental Artifactsrdquo Note 1
GET ndash Scenario 2 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has slightly better performance for sleepy servers
0
50
100
150
200
250
300
350
400
2a 2b 2c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
Scenarios 2a - Non-Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2b- Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2c - Sleepy Server Sleep Aware Proxy maxAge = 60sec 5 Clients
See ldquoExperimental Artifactsrdquo Note 2
Experimental Artifacts Note 1
Currently in the experiment the sleep aware proxy checks the cached state of a resource before putting a request into its Store-and-forward queue while a server is sleeping Once in the queue the proxy unconditionally forwards the queued requests to the server once it wakes up This is not the most efficient setup and can easily be improved If the proxy instead checks its cache again before forwarding each queued request it may not need to forward the request to the server For example if there are two queued GET requests in the proxyrsquos queue that address the same resource Only the first request needs to be sent to the server the second request can use the cached response from the first request
Note 2 Currently in the experiment the sleepy server sends a sleepState PUT request to the
proxy each time it goes to sleep This is not the most efficient setup and can easily be improved For example if the server assumes that the proxy can keep track of its ONOFF cycles with its internal timers (eg as per Fig 1 of I-D) then the number of messages from the sleepy server dramatically goes down
ldquoGETrdquo ndash Test Scenario 3 Results
maxAge = 5 and 5 Clients
GET ndash Scenario 3 ClientProxy Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
Scenarios 3a - Non-Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3b- Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3c - Sleepy Server Sleep Aware Proxy maxAge = 5sec 5 Clients
0
500
1000
1500
2000
2500
3000
3500
4000
4500
5000
3a 3b 3c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
GET ndash Scenario 3 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
0
1000
2000
3000
4000
5000
6000
7000
3a 3b 3c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
Scenarios 3a - Non-Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3b- Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3c - Sleepy Server Sleep Aware Proxy maxAge = 5sec 5 Clients
Conclusions
Conclusions These results show that sleep-aware CoAP
proxy features can significantly optimize communication with sleepy servers in most scenarios
These results also show that sleep-
awareness capabilities can provide additional benefits above and beyond CoAP caching in most scenarios
Backup
Current CoAP Support of Sleepy Node (12)
CoAP proxies can use a previously cached response to service a new GET request for a sleepy origin server (as in HTTP) But if no valid cache then proxy has to attempt to
retrieve and may fail if origin server is sleeping [I-Dietf-core-coap]
Clients can discover list of resources from RD (GET rd-lookuphellip) for sleepy servers But attempt to GET resource from sleepy origin server
may fail if origin server is sleeping [IDietf-core-link-format amp IDshelby-core-resource-
directory]
Current CoAP Support of Sleepy Node (22)
Lower layer support for sleepy nodes in most wireless technologies (eg WiFi ZigBee) But limited to MAC packet scheduling for sleepy nodes
and not aware of specific needs of IP applications (like CoAP)
Proposal ndash RD Based Sleep Tracking (14)
The current CoAP approach to support sleepy nodes can be significantly improved by introducing RD based mechanisms for a CoAP client to determine whether A targeted resource is located on a sleepy server A sleepy server is currently in sleep mode or not
There is any associated caching Proxy (possibly the RD itself) for a sleepy server
Proposal ndash RD Based Sleep Tracking (24)
We define the following new RD attributes to characterize the properties of a sleepy node SleepState - Indicates whether the node is currently in
sleep mode or not (ie Sleeping or Awake) SleepDuration - Indicates the maximum duration of time
that the node stays in sleep mode TimeSleeping - Indicates the length of time the node
has been sleeping (ie if Sleep State = Sleeping) NextSleep - Indicates the next time the node will go to
sleep (ie if Sleep State = Awake)
CachingProxy ndash Indicates the caching proxy of the sleepy node (ie the RD itself or another node)
Proposal ndash RD Based Sleep Tracking (34)
These attributes are all server (node) level and are new parameters added to the RD URI Template Variables
Finally we also define a new lookup-type (ss) for the RD lookup interface specified in [I-Dshelby-core-resource-directory] This new lookup-type supports looking up the
ldquoSleepStaterdquo (ss) of a specified end-point
Proposal ndash RD Based Sleep Tracking (44)
The three time based parameters (SleepDuration TimeSleeping NextSleep) can be based on either an absolute network time (for a time synchronized network) or a relative local time (measured at the local node)
Following the approach of [I-Dietf-core-link-format] and [I-Dshelby-core-resource-directory] sleep parameters for sleepy servers can be stored by the server in the RD and accessed by all interested clients
Examples of using these parameters in a synchronous or asynchronous manner are shown in the I-D
http6lowappnet coreIETF86 2013-03-12-13
We assume people have read the drafts
Meetings serve to advance difficult issues by making good use of face-to-face communications
Note Well Be aware of the IPR principles according to RFC 3979 and its updates
uumlBlue sheetsuumlScribe(s)
96
drar-shy‐iep-shy‐core-shy‐coapsubmiqed13 to13 IESG
2013-shy‐03-shy‐13
97
OMA Lightweight M2M Overview(A new standard using lots of IETF specs including DTLS
CoAP Block Observe Resource Directory SenMLhellip)
Zach ShelbyCoRE WG IETF-86 Orlando
OMA Lightweight M2Mbull Open Mobile Alliance is well known for Device Management (DM)bull OMA Lightweight M2M is a new standard from the alliance
ndash Focused on constrained Cellular and sensor network M2M devicesndash Driven by leading operators and vendors
bull Scopendash Interfaces protocol amp security between Device and Serverndash Object and Resource modelndash Bootstrap Device Access Control Connectivity and Firmware Objects
bull Draft Specifications are availablendash httpmemberopenmobileallianceorgftpPublic_documentsDM
LightweightM2MPermanent_documentsOMA-TS-LightweightM2M-V1_0_0-20130301-Dzip
bull Timelinendash Requirements and Architecture completed 3Q2012ndash Spec ready for Consistency Review 2Q2013ndash Candidate Approval expected 3Q2013
2 CoRE WG IETF-86 Orlando
Architecture
3
Scope of LWM2M
CoRE WG IETF-86 Orlando
Object Model
bull A Client has one or more Object Instancesbull An Object is a collection of Resourcesbull A Resource is an atomic piece of information
ndash Read Written or Executed
bull Resources can have multiple instancesbull Objects and Resources are identified by a
16-bit Integer Instances by an 8-bit Integerbull ObjectsResources are accessed with
simple URIs Object IDObject InstanceResource ID
eg 1213
4 CoRE WG IETF-86 Orlando
CoRE WG IETF-86 Orlando
CoRE Resource Directory
draft-shelby-core-resource-directory-05
Z Shelby C Bormann S Krco
Backgroundbull Not a new concept
ndash think web search engine or any link directorybull Defines the interfaces to a Resource Directorybull Based on Web Linking framework and the CoRE Link Formatbull Generic REST design for use over HTTP and CoAPbull Used by OMA Lightweight M2Mbull Has already been deployed
ndash In traffic monitoring systemsndash In street lighting systemsndash For vehicular asset trackingndash By a major Cellular M2M operator
Changes since -04
bull Restricted Update to parameter updatesbull Added pagination support for the Lookup interfacebull Changed rt= to et= for the registration amp update
interfacebull Added group support
Group Management
bull RD now includes group management featuresbull New Group Function Set
ndash Register a groupbull Group name domain multicast address endpoint members
ndash Remove a groupbull Group lookup using the Lookup Function Set
ndash List registered groupsndash Find the members of a groupndash Find groups with certain endpoints or resources
Registering a Group
EP RD
| |
| - POST rd-groupgp=lights ltgtep=node1 --gt |
| |
| |
| lt---- 201 Created Location rd-group12 ---- |
| |
Req POST coaprdexamplecomrd-groupgp=lights
Payload
ltgtep=node1
ltgtep=node2
Res 201 Created
Location rd-group12
Looking up Group Members
Client RD
| |
| ----- GET rd-lookupepgp=lights1 ----------------------gt |
| |
| |
| lt-- 205 Content ltrdgtd=domain1ltrdgtd=domain2 --------- |
| |
Req GET rd-lookupepgp=lights1
Res 205 Content
ltcoaphostportgtep=node1
ltcoaphostportgtep=node2rdquo
Things for the futurebull Support for JSON representation of Web Links
ndash httptoolsietforgiddraft-bormann-core-links-json-02txtbull Registry for RD registration query parameters
ndash Already OMA Lightweight has defined some new onesbull More examples
Group 3 ldquonew workrdquo(continued)
109
drar-shy‐greevenbosch-shy‐core-shy‐profile-shy‐descripon-shy‐01Bert13 GreevenboschJeroen13 Hoebeke
Isam13 IshaqFloris13 Van13 den13 Abeele
Descripon
bull JSON13 format13 for13 signalling13 the13 servers13 capabilies
bull Signalling13 of13 supported13 opons13 media13 types13 and13 block13 sizendash Other13 items13 can13 be13 added
bull Filtering13 on13 specific13 fields13 through13 URI-shy‐Querybull Link13 hqpdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐profile-shy‐descripon
well-shy‐knownprofile
bull To13 acquire13 profile13 data13 of13 resources13 on13 a13 parcular13 service13 the13 well-shy‐knownprofile13 URI-shy‐path13 is13 introduced
bull For13 example13 to13 get13 all13 informaon13 from13 sensors13 served13 by13 wwwexampleorg13 we13 can13 do13 a13 GET13 to13 coapwwwexampleorgwell-shy‐knownprofile
bull Filtering13 on13 parcular13 resources13 is13 done13 through13 URI-shy‐Queries
Format
bull Currently13 the13 following13 fields13 are13 definedndash ldquopathrdquo13 contains13 the13 URI-shy‐path13 associated13 with13 a13 resource
ndash ldquooprdquo13 a13 numerical13 list13 of13 supported13 opon13 numbers
ndash ldquocfrdquo13 a13 numerical13 list13 of13 supported13 content-shy‐format13 numbers
ndash ldquob1srdquo13 ldquob2srdquo13 supported13 block13 sizes13 for13 Block113 and13 Block213 respecvely
Examplebull On13 the13 right13 is13 an13 example13 of13 a13 camera13 sensor13 at13 coapwwwexampleorgcam13 that13 supports13 the13 Uri-shy‐Host13 (3)13 ETag13 (4)13 Uri-shy‐Port13 (7)13 Uri-shy‐Path13 (11)13 Content-shy‐Format13 (12)13 Token13 (19)13 Block213 (23)13 and13 Proxy-shy‐Uri13 (35)13 opons
bull The13 supported13 content13 formats13 are13 textplain13 (0)13 applicaon13 link-shy‐format13 (40)13 and13 applicaonjson13 (50)
bull The13 supported13 Block213 can13 use13 25613 or13 51213 byte13 blocks
Req13 GET13 coapwwwexampleorgwell-shy‐knownprofile13 Res13 20513 Content13 (applicationjson)13 13 13 13 profile13 13 13 13 13 13 13 13 pathcam13 13 13 13 op[3471112192335]13 13 13 13 13 cf[04050]13 13 13 13 13 b2s[45]13 13 13 13
Filtering13 through13 use13 of13 URI-shy‐Query
bull Filtering13 can13 be13 done13 through13 the13 URI-shy‐Querybull Query13 format13 N=V
ndash N13 is13 a13 profile13 fieldndash V13 is13 the13 desired13 value
bull Examplesndash To13 find13 resources13 that13 support13 content13 format13 ldquoapplicaonjsonrdquo
13 GET13 wwwexampleorgwell-shy‐knownprofilecf=50ndash To13 get13 informaon13 about13 the13 camera
13 GET13 wwwexampleorgwell-shy‐knownprofilepath=cam
Open13 issues
bull Which13 other13 profile13 data13 needs13 signallingndash Content-shy‐type13 for13 different13 methods
bull Fix13 the13 order13 in13 which13 the13 profile13 fields13 must13 appearndash Non-shy‐fixed13 order13 easier13 extensible
bull Inheritance13 of13 a13 profile13 descriponbull Extend13 usage13 to13 signal13 the13 client13 profilebull Integraon13 with13 link13 format
Thank13 youQuesons
drar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval-shy‐00
Bert13 Greevenbosch
Descripon
bull The13 ldquoMinimumRequestInterval13 opon13 can13 be13 used13 to13 indicate13 the13 minimum13 me13 between13 two13 requests13 in13 a13 transacon
bull Originally13 intended13 for13 Block13 but13 also13 usable13 for13 other13 transaconsndash Example13 browsing13 a13 server
bull The13 goal13 is13 to13 reduce13 the13 server13 load13 and13 network13 traffic
bull Link13 hqpsdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval
Usage
bull The13 client13 keeps13 the13 server13 informed13 about13 its13 request13 speed13 through13 inclusion13 of13 the13 ldquoMinimumRequestIntervalrdquo13 opon
bull In13 responses13 the13 server13 fixes13 the13 minimum13 request13 interval13 through13 the13 same13 opon
bull The13 client13 obeys13 the13 speed13 indicated13 by13 the13 server
bull The13 client13 can13 send13 slower13 but13 not13 faster
Advantages
bull The13 server13 has13 means13 to13 limit13 the13 amount13 of13 incoming13 traffic
bull The13 server13 can13 prevent13 to13 become13 overloaded13 with13 too13 many13 tasks
bull The13 server13 does13 not13 need13 arficially13 slow13 down13 the13 client13 by13 sending13 late13 ACKsndash No13 need13 to13 keep13 track13 of13 delayed13 ACKsndash The13 server13 can13 perform13 other13 tasks13 instead
bull Reduced13 network13 traffic
Thank13 youQuesons
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-links-json-02txt
123
RFC 6690 (link-format) documents are somewhat foreign to many web app developerssect would prefer to have them in JSON format
There is no standard way to represent link-format documents in applicationssect but everyone knows how to handle JSON
Define a standard JSON translation for link-format
Itrsquos
not
rock
et
scien
ce
ltsensorsgtct=40title=Sensor Index ltsensorstempgtrt=temperature-cif=sensor ltsensorslightgtrt=light-luxif=sensor lthttpwwwexamplecomsensorst123gt anchor=sensorstemprel=describedby lttgtanchor=sensorstemprel=alternate [hrefsensorsct40titleSensor Index hrefsensorstemprttemperature-cifsensor hrefsensorslightrtlight-luxifsensor hrefhttpwwwexamplecomsensorst123 anchorsensorstempreldescribedby hreftanchorsensorstemprelalternate]
124
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-ipsec-for-coap-00txt
IPsec definitions for CoAP Mostly placeholder at this time Who has implementation experience with this
125
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-cross-reverse-convention-00txt
This draft has two lines of payload(based on a WGLC comment by Cullen Jennings)
coap12344567foobara=3
httpwwwproxycomwellknowncore-translate1234_4567foobara=3
Is that a useful convention to have
126
Insert CI slides here
127
128
0
5
10
15
20
25
30
35
40
10 20 30 40 50 60 70
good
put (
pps)
pps
Goodput vs pps (Econotags)
goodput
[Khattak preliminary]
Congestion Control
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-cocoa-00txt
ldquoadvancedrdquo cc (The draft is just a first shot) Others may have better ideas
129
Insert post-WGLC discussion slides here
130
Stop Continue Start
131
An Agile Retrospective
http6lowappnet coreIETF86 2013-03-12-13
Stop
132
Endless new CoAP optionssect instead use RESTful as much as possible
Move general security lifecycle out Looking at theoretical problems
http6lowappnet coreIETF86 2013-03-12-13
Continue
Interops Running code Look at real-world examples and deployments Solve their actual problems
sect Unilateral enhancements eg higher performance congestion control
sect Transports (SMS hellip)sect Make Web linking and Directories more and more usefulsect RESTful Design Paradigms for real-world problems
133
http6lowappnet coreIETF86 2013-03-12-13
Start
Further push into the (browser) web world (HTML5 browser security)
Specific supporting worksect SenMLsect URI work (dev URN hellip)sect Security Processes (next slide)
Spin outsect (We donrsquot really get to decide where this is done)
134
http6lowappnet coreIETF86 2013-03-12-13
Security
Integrate Application Network Group Keyingsect Tunnel-free setup
Donrsquot redo what has been done alreadysect ZigBee IP is finesect But what about other scenarios
Simple REST interfaces for working with keying materials and authorizationsect Start with defining objectives
Object Security for Constrained Nodes135
Re-chartering CoREWhat do we want to do now that wersquore grown up
Zach ShelbyCoRE WG IETF-86 Orlando
What is the scope
bull So we have a protocol and Web Linking what next
bull Keep with what we know besthellip1 Enhancements around CoAP2 New transports for CoAP3 New representations for Web Links4 General application layer solutions
CoRE WG IETF-86 Orlando 2
Enhancements around CoAP
bull Advanced congestion control
CoRE WG IETF-86 Orlando 3
New Transports for CoAP
bull Infrastructure for CoAP over foondash httptoolsietforgiddraft-silverajan-core-
coap-alternative-transports-01txtbull CoAP over SMS
ndash httptoolsietforgiddraft-becker-core-coap-sms-gprs-03txt
ndash OMA Lightweightbull CoAP over TCP
ndash httptoolsietforgiddraft-li-core-coap-payload-length-option-01txt
CoRE WG IETF-86 Orlando 4
New support for Web Links
bull JSON Web Linksndash httptoolsietforgiddraft-bormann-core-links-
json-02txt
2332010 CoRE WG IETF-77 Anaheim 5
General application layer solutions
bull Resource Directoryndash httptoolsietforgiddraft-shelby-core-
resource-directory-05txtndash OMA Lightweight
2332010 CoRE WG IETF-77 Anaheim 6
031113
URI13 Representaons13 for13 CoAPMiscellaneous13 Consideraons
bull Ensure13 that13 transport13 is13 defined13 unambiguously13 (eg13 L2CAP13 used13 by13 both13 BLE13 and13 standard13 Bluetooth13 so13 avoid13 rdquocoap+l2caprdquo13 or13 rdquotransport=l2caprdquo13 or13 rdquoq=l2caprdquondash Can13 be13 done13 as13 WG13 consensusndash Namespace13 approach13 eg13 rdquocoap+blel2caprdquo13 or13 rdquoq=blel2caprdquo
bull Allow13 end-shy‐points13 to13 use13 CoAP13 Resource13 Directory13 to13 register13 alternave13 transports13 and13 idenfiers13 and13 provide13 periodic13 updatesndash Register13 rdquocore-shy‐transportrdquo13 resource13 type
62
031113
Transport13 Consideraons
bull Uniqueness13 of13 end-shy‐point13 idenficaonbull Communicaon13 support13 Unidireconal13 Bidireconal13 1N13 (broadcast13 mulcast13 anycast)13 messaging
bull Binary13 encoding13 Network13 byte13 orderingbull MTU13 correlaon13 with13 CoAP13 PDU13 sizebull Transport13 latency
63
031113
Security13 Consideraons
bull Drar13 does13 not13 introduce13 new13 security13 requirements13 by13 itself
bull There13 may13 be13 privacy13 issues13 if13 nodes13 use13 telephone13 numbers13 or13 MAC13 addresses13 as13 public13 end13 point13 idenfiers
64
Akbar Rahman
IETF 86 March 2013 httpwwwietforgiddraft-rahman-core-sleepy-02txt
Enhanced Sleepy Node Support for CoAP
Introduction
It is expected that in CoAP networks there will be a certain portion of devices that are sleepy and which may occasionally go into a sleep mode (ie go into a low power state to conserve power) and subsequently have reduced CoAP protocol communication ability
This I-D proposes a minimal and efficient mechanism building on the Resource Directory concept (which will be integrated into a CoAP Proxy) to enhance sleepy node support in CoAP networks
Main Question from IETF-85 (Atlanta)
What performance benefit does the proposed Sleepy Node support solution give in a network that already has standard CoAP caching enabled
Sleepy Node Performance Analysis
Experimental Network
1-5 clients
Both Sleepy and Non-
Sleepy servers
Sleepy Node Performance Analysis Network Setup
CoAPSleepyServer(s)
CoAPSleepAwareReverseProxy
CoAP
Client(s)
Request
Response
Sleep9AwareCoREResourceDirectoryCapability
PublishedSleepParameters
Sleep9AwareCoAPStoreandForwardCapability Response
Request
SleepAwareCoAP503ResponseCapability
CoAPCachingCapability
bull Server supports publishing sleep parameters to proxy bull Eg Irsquom going to be asleep for X seconds
bull Proxy supports sleep-awareness capabilities bull Proxy also supports caching capability based off of maxAge bull Protocol flow similar to approach of Figure 1 (Synchronous RD Based Sleep
Tracking) of I-D
Proxy capabilities can be selectively enableddisabled
Proxy ndash Server Interface
Client ndash Proxy Interface
CoAP Sleep-Aware Reverse Proxy Features CoRE Sleep-aware Resource Directory
Support storing published sleep parameters from CoAP servers sleepState (AWAKE ASLEEP) sleepDuration
Sleep-aware CoAP 503 Response Capability If CoAP request to a sleeping server is received proxy returns a
lsquo503 Retry-Afterrsquo response to client 503 contains a timestamp indicating when the sever will wake back up
(timestamp delivered in CoAP maxAge option) Sleep-aware CoAP Store-and-Forward Capability
If CoAP request to a sleeping server is received proxy stores request until server wakes up and then forwards it
Caching capability Cache GET responses from server if maxAge option is present
(this is not a sleep aware feature)
Goals of Performance Analysis
For networks having sleepy servers provide measurements to quantify the impact that CoAP sleep-awareness capabilities can have
See if sleep-awareness capabilities can
provide additional benefits even when CoAP caching is used
Overview of Performance Analysis Performed The analysis was broken up into a set of test scenarios Each test scenario used a different combination of the following
variables Client issued GET requests Server was configured as a sleepy or non-sleepy server Proxy caching of GET responses was enabled or disabled Proxy sleep-aware 503 response capability was enabled or disabled Proxy store-and-forward capability was enabled or disabled maxAge in GET responses ndash Two values were tested 60sec and 5sec of Clients ndash Two values were used ndash 1 client and 5 clients
For comparison purposes the following were held constant across all test scenarios Client issued a fixed number of requests (100) across all test scenarios Client used a delay between each GET request (35sec) to better exercise
proxyrsquos caching and sleep-awareness capabilities For sleepy server test scenarios the server slept 60 sec awake for 3 sec
Format of Results The following results were collected for each
test scenario
Breakdown of the and types of transactions occurring between clientproxyserver
ldquoGETrdquo ndash Test Scenario Results
GET ndash Description of Test Scenarios
TestScenarios-GET
Scenario
CoAPSleepyServerSe7ngs CoAPSleepAwareReverseProxySe7ngs CoAPClientSe7ngs
SleepDuragton(sec)
AwakeDuragton(sec)
maxAge(sec) Caching SleepAwareSAF+
503NumberofClients
NumberofGETs
DelayBetweenClient
Requests(sec)
1a 0 Always 60 Enabled Disabled 1 100 35
1b 60 3 60 Enabled Disabled 1 100 35
1c 60 3 60 Enabled Enabled 1 100 35
2a 0 Always 60 Enabled Disabled 5 100 35
2b 60 3 60 Enabled Disabled 5 100 35
2c 60 3 60 Enabled Enabled 5 100 35
3a 0 Always 5 Enabled Disabled 5 100 35
3b 60 3 5 Enabled Disabled 5 100 35
3c 60 3 5 Enabled Enabled 5 100 35
ldquoGETrdquo ndash Test Scenario 1 Results
maxAge = 60 and 1 Client
GET ndash Scenario 1 ClientProxy Interface Transaction Mix
Scenarios 1a - Non-Sleepy Server Caching Proxy maxAge = 60sec 1b- Sleepy Server Caching Proxy maxAge = 60sec 1c - Sleepy Server Sleep Aware Proxy maxAge = 60sec
Sleep Aware Proxy has better performance for sleepy servers
0
100
200
300
400
500
600
700
1a 1b 1c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
GET ndash Scenario 1 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
Scenarios 1a - Non-Sleepy Server Caching Proxy maxAge = 60sec 1b- Sleepy Server Caching Proxy maxAge = 60sec 1c - Sleepy Server Sleep Aware Proxy maxAge = 60sec
0
100
200
300
400
500
600
700
800
1a 1b 1c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
ldquoGETrdquo ndash Test Scenario 2 Results
maxAge = 60 and 5 Clients
GET ndash Scenario 2 ClientProxy Interface Transaction Mix
Sleep Aware Proxy has slightly better performance for sleepy servers
0
200
400
600
800
1000
1200
1400
2a 2b 2c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
Scenarios 2a - Non-Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2b- Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2c - Sleepy Server Sleep Aware Proxy maxAge = 60sec 5 Clients
See ldquoExperimental Artifactsrdquo Note 1
GET ndash Scenario 2 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has slightly better performance for sleepy servers
0
50
100
150
200
250
300
350
400
2a 2b 2c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
Scenarios 2a - Non-Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2b- Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2c - Sleepy Server Sleep Aware Proxy maxAge = 60sec 5 Clients
See ldquoExperimental Artifactsrdquo Note 2
Experimental Artifacts Note 1
Currently in the experiment the sleep aware proxy checks the cached state of a resource before putting a request into its Store-and-forward queue while a server is sleeping Once in the queue the proxy unconditionally forwards the queued requests to the server once it wakes up This is not the most efficient setup and can easily be improved If the proxy instead checks its cache again before forwarding each queued request it may not need to forward the request to the server For example if there are two queued GET requests in the proxyrsquos queue that address the same resource Only the first request needs to be sent to the server the second request can use the cached response from the first request
Note 2 Currently in the experiment the sleepy server sends a sleepState PUT request to the
proxy each time it goes to sleep This is not the most efficient setup and can easily be improved For example if the server assumes that the proxy can keep track of its ONOFF cycles with its internal timers (eg as per Fig 1 of I-D) then the number of messages from the sleepy server dramatically goes down
ldquoGETrdquo ndash Test Scenario 3 Results
maxAge = 5 and 5 Clients
GET ndash Scenario 3 ClientProxy Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
Scenarios 3a - Non-Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3b- Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3c - Sleepy Server Sleep Aware Proxy maxAge = 5sec 5 Clients
0
500
1000
1500
2000
2500
3000
3500
4000
4500
5000
3a 3b 3c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
GET ndash Scenario 3 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
0
1000
2000
3000
4000
5000
6000
7000
3a 3b 3c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
Scenarios 3a - Non-Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3b- Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3c - Sleepy Server Sleep Aware Proxy maxAge = 5sec 5 Clients
Conclusions
Conclusions These results show that sleep-aware CoAP
proxy features can significantly optimize communication with sleepy servers in most scenarios
These results also show that sleep-
awareness capabilities can provide additional benefits above and beyond CoAP caching in most scenarios
Backup
Current CoAP Support of Sleepy Node (12)
CoAP proxies can use a previously cached response to service a new GET request for a sleepy origin server (as in HTTP) But if no valid cache then proxy has to attempt to
retrieve and may fail if origin server is sleeping [I-Dietf-core-coap]
Clients can discover list of resources from RD (GET rd-lookuphellip) for sleepy servers But attempt to GET resource from sleepy origin server
may fail if origin server is sleeping [IDietf-core-link-format amp IDshelby-core-resource-
directory]
Current CoAP Support of Sleepy Node (22)
Lower layer support for sleepy nodes in most wireless technologies (eg WiFi ZigBee) But limited to MAC packet scheduling for sleepy nodes
and not aware of specific needs of IP applications (like CoAP)
Proposal ndash RD Based Sleep Tracking (14)
The current CoAP approach to support sleepy nodes can be significantly improved by introducing RD based mechanisms for a CoAP client to determine whether A targeted resource is located on a sleepy server A sleepy server is currently in sleep mode or not
There is any associated caching Proxy (possibly the RD itself) for a sleepy server
Proposal ndash RD Based Sleep Tracking (24)
We define the following new RD attributes to characterize the properties of a sleepy node SleepState - Indicates whether the node is currently in
sleep mode or not (ie Sleeping or Awake) SleepDuration - Indicates the maximum duration of time
that the node stays in sleep mode TimeSleeping - Indicates the length of time the node
has been sleeping (ie if Sleep State = Sleeping) NextSleep - Indicates the next time the node will go to
sleep (ie if Sleep State = Awake)
CachingProxy ndash Indicates the caching proxy of the sleepy node (ie the RD itself or another node)
Proposal ndash RD Based Sleep Tracking (34)
These attributes are all server (node) level and are new parameters added to the RD URI Template Variables
Finally we also define a new lookup-type (ss) for the RD lookup interface specified in [I-Dshelby-core-resource-directory] This new lookup-type supports looking up the
ldquoSleepStaterdquo (ss) of a specified end-point
Proposal ndash RD Based Sleep Tracking (44)
The three time based parameters (SleepDuration TimeSleeping NextSleep) can be based on either an absolute network time (for a time synchronized network) or a relative local time (measured at the local node)
Following the approach of [I-Dietf-core-link-format] and [I-Dshelby-core-resource-directory] sleep parameters for sleepy servers can be stored by the server in the RD and accessed by all interested clients
Examples of using these parameters in a synchronous or asynchronous manner are shown in the I-D
http6lowappnet coreIETF86 2013-03-12-13
We assume people have read the drafts
Meetings serve to advance difficult issues by making good use of face-to-face communications
Note Well Be aware of the IPR principles according to RFC 3979 and its updates
uumlBlue sheetsuumlScribe(s)
96
drar-shy‐iep-shy‐core-shy‐coapsubmiqed13 to13 IESG
2013-shy‐03-shy‐13
97
OMA Lightweight M2M Overview(A new standard using lots of IETF specs including DTLS
CoAP Block Observe Resource Directory SenMLhellip)
Zach ShelbyCoRE WG IETF-86 Orlando
OMA Lightweight M2Mbull Open Mobile Alliance is well known for Device Management (DM)bull OMA Lightweight M2M is a new standard from the alliance
ndash Focused on constrained Cellular and sensor network M2M devicesndash Driven by leading operators and vendors
bull Scopendash Interfaces protocol amp security between Device and Serverndash Object and Resource modelndash Bootstrap Device Access Control Connectivity and Firmware Objects
bull Draft Specifications are availablendash httpmemberopenmobileallianceorgftpPublic_documentsDM
LightweightM2MPermanent_documentsOMA-TS-LightweightM2M-V1_0_0-20130301-Dzip
bull Timelinendash Requirements and Architecture completed 3Q2012ndash Spec ready for Consistency Review 2Q2013ndash Candidate Approval expected 3Q2013
2 CoRE WG IETF-86 Orlando
Architecture
3
Scope of LWM2M
CoRE WG IETF-86 Orlando
Object Model
bull A Client has one or more Object Instancesbull An Object is a collection of Resourcesbull A Resource is an atomic piece of information
ndash Read Written or Executed
bull Resources can have multiple instancesbull Objects and Resources are identified by a
16-bit Integer Instances by an 8-bit Integerbull ObjectsResources are accessed with
simple URIs Object IDObject InstanceResource ID
eg 1213
4 CoRE WG IETF-86 Orlando
CoRE WG IETF-86 Orlando
CoRE Resource Directory
draft-shelby-core-resource-directory-05
Z Shelby C Bormann S Krco
Backgroundbull Not a new concept
ndash think web search engine or any link directorybull Defines the interfaces to a Resource Directorybull Based on Web Linking framework and the CoRE Link Formatbull Generic REST design for use over HTTP and CoAPbull Used by OMA Lightweight M2Mbull Has already been deployed
ndash In traffic monitoring systemsndash In street lighting systemsndash For vehicular asset trackingndash By a major Cellular M2M operator
Changes since -04
bull Restricted Update to parameter updatesbull Added pagination support for the Lookup interfacebull Changed rt= to et= for the registration amp update
interfacebull Added group support
Group Management
bull RD now includes group management featuresbull New Group Function Set
ndash Register a groupbull Group name domain multicast address endpoint members
ndash Remove a groupbull Group lookup using the Lookup Function Set
ndash List registered groupsndash Find the members of a groupndash Find groups with certain endpoints or resources
Registering a Group
EP RD
| |
| - POST rd-groupgp=lights ltgtep=node1 --gt |
| |
| |
| lt---- 201 Created Location rd-group12 ---- |
| |
Req POST coaprdexamplecomrd-groupgp=lights
Payload
ltgtep=node1
ltgtep=node2
Res 201 Created
Location rd-group12
Looking up Group Members
Client RD
| |
| ----- GET rd-lookupepgp=lights1 ----------------------gt |
| |
| |
| lt-- 205 Content ltrdgtd=domain1ltrdgtd=domain2 --------- |
| |
Req GET rd-lookupepgp=lights1
Res 205 Content
ltcoaphostportgtep=node1
ltcoaphostportgtep=node2rdquo
Things for the futurebull Support for JSON representation of Web Links
ndash httptoolsietforgiddraft-bormann-core-links-json-02txtbull Registry for RD registration query parameters
ndash Already OMA Lightweight has defined some new onesbull More examples
Group 3 ldquonew workrdquo(continued)
109
drar-shy‐greevenbosch-shy‐core-shy‐profile-shy‐descripon-shy‐01Bert13 GreevenboschJeroen13 Hoebeke
Isam13 IshaqFloris13 Van13 den13 Abeele
Descripon
bull JSON13 format13 for13 signalling13 the13 servers13 capabilies
bull Signalling13 of13 supported13 opons13 media13 types13 and13 block13 sizendash Other13 items13 can13 be13 added
bull Filtering13 on13 specific13 fields13 through13 URI-shy‐Querybull Link13 hqpdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐profile-shy‐descripon
well-shy‐knownprofile
bull To13 acquire13 profile13 data13 of13 resources13 on13 a13 parcular13 service13 the13 well-shy‐knownprofile13 URI-shy‐path13 is13 introduced
bull For13 example13 to13 get13 all13 informaon13 from13 sensors13 served13 by13 wwwexampleorg13 we13 can13 do13 a13 GET13 to13 coapwwwexampleorgwell-shy‐knownprofile
bull Filtering13 on13 parcular13 resources13 is13 done13 through13 URI-shy‐Queries
Format
bull Currently13 the13 following13 fields13 are13 definedndash ldquopathrdquo13 contains13 the13 URI-shy‐path13 associated13 with13 a13 resource
ndash ldquooprdquo13 a13 numerical13 list13 of13 supported13 opon13 numbers
ndash ldquocfrdquo13 a13 numerical13 list13 of13 supported13 content-shy‐format13 numbers
ndash ldquob1srdquo13 ldquob2srdquo13 supported13 block13 sizes13 for13 Block113 and13 Block213 respecvely
Examplebull On13 the13 right13 is13 an13 example13 of13 a13 camera13 sensor13 at13 coapwwwexampleorgcam13 that13 supports13 the13 Uri-shy‐Host13 (3)13 ETag13 (4)13 Uri-shy‐Port13 (7)13 Uri-shy‐Path13 (11)13 Content-shy‐Format13 (12)13 Token13 (19)13 Block213 (23)13 and13 Proxy-shy‐Uri13 (35)13 opons
bull The13 supported13 content13 formats13 are13 textplain13 (0)13 applicaon13 link-shy‐format13 (40)13 and13 applicaonjson13 (50)
bull The13 supported13 Block213 can13 use13 25613 or13 51213 byte13 blocks
Req13 GET13 coapwwwexampleorgwell-shy‐knownprofile13 Res13 20513 Content13 (applicationjson)13 13 13 13 profile13 13 13 13 13 13 13 13 pathcam13 13 13 13 op[3471112192335]13 13 13 13 13 cf[04050]13 13 13 13 13 b2s[45]13 13 13 13
Filtering13 through13 use13 of13 URI-shy‐Query
bull Filtering13 can13 be13 done13 through13 the13 URI-shy‐Querybull Query13 format13 N=V
ndash N13 is13 a13 profile13 fieldndash V13 is13 the13 desired13 value
bull Examplesndash To13 find13 resources13 that13 support13 content13 format13 ldquoapplicaonjsonrdquo
13 GET13 wwwexampleorgwell-shy‐knownprofilecf=50ndash To13 get13 informaon13 about13 the13 camera
13 GET13 wwwexampleorgwell-shy‐knownprofilepath=cam
Open13 issues
bull Which13 other13 profile13 data13 needs13 signallingndash Content-shy‐type13 for13 different13 methods
bull Fix13 the13 order13 in13 which13 the13 profile13 fields13 must13 appearndash Non-shy‐fixed13 order13 easier13 extensible
bull Inheritance13 of13 a13 profile13 descriponbull Extend13 usage13 to13 signal13 the13 client13 profilebull Integraon13 with13 link13 format
Thank13 youQuesons
drar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval-shy‐00
Bert13 Greevenbosch
Descripon
bull The13 ldquoMinimumRequestInterval13 opon13 can13 be13 used13 to13 indicate13 the13 minimum13 me13 between13 two13 requests13 in13 a13 transacon
bull Originally13 intended13 for13 Block13 but13 also13 usable13 for13 other13 transaconsndash Example13 browsing13 a13 server
bull The13 goal13 is13 to13 reduce13 the13 server13 load13 and13 network13 traffic
bull Link13 hqpsdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval
Usage
bull The13 client13 keeps13 the13 server13 informed13 about13 its13 request13 speed13 through13 inclusion13 of13 the13 ldquoMinimumRequestIntervalrdquo13 opon
bull In13 responses13 the13 server13 fixes13 the13 minimum13 request13 interval13 through13 the13 same13 opon
bull The13 client13 obeys13 the13 speed13 indicated13 by13 the13 server
bull The13 client13 can13 send13 slower13 but13 not13 faster
Advantages
bull The13 server13 has13 means13 to13 limit13 the13 amount13 of13 incoming13 traffic
bull The13 server13 can13 prevent13 to13 become13 overloaded13 with13 too13 many13 tasks
bull The13 server13 does13 not13 need13 arficially13 slow13 down13 the13 client13 by13 sending13 late13 ACKsndash No13 need13 to13 keep13 track13 of13 delayed13 ACKsndash The13 server13 can13 perform13 other13 tasks13 instead
bull Reduced13 network13 traffic
Thank13 youQuesons
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-links-json-02txt
123
RFC 6690 (link-format) documents are somewhat foreign to many web app developerssect would prefer to have them in JSON format
There is no standard way to represent link-format documents in applicationssect but everyone knows how to handle JSON
Define a standard JSON translation for link-format
Itrsquos
not
rock
et
scien
ce
ltsensorsgtct=40title=Sensor Index ltsensorstempgtrt=temperature-cif=sensor ltsensorslightgtrt=light-luxif=sensor lthttpwwwexamplecomsensorst123gt anchor=sensorstemprel=describedby lttgtanchor=sensorstemprel=alternate [hrefsensorsct40titleSensor Index hrefsensorstemprttemperature-cifsensor hrefsensorslightrtlight-luxifsensor hrefhttpwwwexamplecomsensorst123 anchorsensorstempreldescribedby hreftanchorsensorstemprelalternate]
124
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-ipsec-for-coap-00txt
IPsec definitions for CoAP Mostly placeholder at this time Who has implementation experience with this
125
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-cross-reverse-convention-00txt
This draft has two lines of payload(based on a WGLC comment by Cullen Jennings)
coap12344567foobara=3
httpwwwproxycomwellknowncore-translate1234_4567foobara=3
Is that a useful convention to have
126
Insert CI slides here
127
128
0
5
10
15
20
25
30
35
40
10 20 30 40 50 60 70
good
put (
pps)
pps
Goodput vs pps (Econotags)
goodput
[Khattak preliminary]
Congestion Control
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-cocoa-00txt
ldquoadvancedrdquo cc (The draft is just a first shot) Others may have better ideas
129
Insert post-WGLC discussion slides here
130
Stop Continue Start
131
An Agile Retrospective
http6lowappnet coreIETF86 2013-03-12-13
Stop
132
Endless new CoAP optionssect instead use RESTful as much as possible
Move general security lifecycle out Looking at theoretical problems
http6lowappnet coreIETF86 2013-03-12-13
Continue
Interops Running code Look at real-world examples and deployments Solve their actual problems
sect Unilateral enhancements eg higher performance congestion control
sect Transports (SMS hellip)sect Make Web linking and Directories more and more usefulsect RESTful Design Paradigms for real-world problems
133
http6lowappnet coreIETF86 2013-03-12-13
Start
Further push into the (browser) web world (HTML5 browser security)
Specific supporting worksect SenMLsect URI work (dev URN hellip)sect Security Processes (next slide)
Spin outsect (We donrsquot really get to decide where this is done)
134
http6lowappnet coreIETF86 2013-03-12-13
Security
Integrate Application Network Group Keyingsect Tunnel-free setup
Donrsquot redo what has been done alreadysect ZigBee IP is finesect But what about other scenarios
Simple REST interfaces for working with keying materials and authorizationsect Start with defining objectives
Object Security for Constrained Nodes135
Re-chartering CoREWhat do we want to do now that wersquore grown up
Zach ShelbyCoRE WG IETF-86 Orlando
What is the scope
bull So we have a protocol and Web Linking what next
bull Keep with what we know besthellip1 Enhancements around CoAP2 New transports for CoAP3 New representations for Web Links4 General application layer solutions
CoRE WG IETF-86 Orlando 2
Enhancements around CoAP
bull Advanced congestion control
CoRE WG IETF-86 Orlando 3
New Transports for CoAP
bull Infrastructure for CoAP over foondash httptoolsietforgiddraft-silverajan-core-
coap-alternative-transports-01txtbull CoAP over SMS
ndash httptoolsietforgiddraft-becker-core-coap-sms-gprs-03txt
ndash OMA Lightweightbull CoAP over TCP
ndash httptoolsietforgiddraft-li-core-coap-payload-length-option-01txt
CoRE WG IETF-86 Orlando 4
New support for Web Links
bull JSON Web Linksndash httptoolsietforgiddraft-bormann-core-links-
json-02txt
2332010 CoRE WG IETF-77 Anaheim 5
General application layer solutions
bull Resource Directoryndash httptoolsietforgiddraft-shelby-core-
resource-directory-05txtndash OMA Lightweight
2332010 CoRE WG IETF-77 Anaheim 6
031113
Transport13 Consideraons
bull Uniqueness13 of13 end-shy‐point13 idenficaonbull Communicaon13 support13 Unidireconal13 Bidireconal13 1N13 (broadcast13 mulcast13 anycast)13 messaging
bull Binary13 encoding13 Network13 byte13 orderingbull MTU13 correlaon13 with13 CoAP13 PDU13 sizebull Transport13 latency
63
031113
Security13 Consideraons
bull Drar13 does13 not13 introduce13 new13 security13 requirements13 by13 itself
bull There13 may13 be13 privacy13 issues13 if13 nodes13 use13 telephone13 numbers13 or13 MAC13 addresses13 as13 public13 end13 point13 idenfiers
64
Akbar Rahman
IETF 86 March 2013 httpwwwietforgiddraft-rahman-core-sleepy-02txt
Enhanced Sleepy Node Support for CoAP
Introduction
It is expected that in CoAP networks there will be a certain portion of devices that are sleepy and which may occasionally go into a sleep mode (ie go into a low power state to conserve power) and subsequently have reduced CoAP protocol communication ability
This I-D proposes a minimal and efficient mechanism building on the Resource Directory concept (which will be integrated into a CoAP Proxy) to enhance sleepy node support in CoAP networks
Main Question from IETF-85 (Atlanta)
What performance benefit does the proposed Sleepy Node support solution give in a network that already has standard CoAP caching enabled
Sleepy Node Performance Analysis
Experimental Network
1-5 clients
Both Sleepy and Non-
Sleepy servers
Sleepy Node Performance Analysis Network Setup
CoAPSleepyServer(s)
CoAPSleepAwareReverseProxy
CoAP
Client(s)
Request
Response
Sleep9AwareCoREResourceDirectoryCapability
PublishedSleepParameters
Sleep9AwareCoAPStoreandForwardCapability Response
Request
SleepAwareCoAP503ResponseCapability
CoAPCachingCapability
bull Server supports publishing sleep parameters to proxy bull Eg Irsquom going to be asleep for X seconds
bull Proxy supports sleep-awareness capabilities bull Proxy also supports caching capability based off of maxAge bull Protocol flow similar to approach of Figure 1 (Synchronous RD Based Sleep
Tracking) of I-D
Proxy capabilities can be selectively enableddisabled
Proxy ndash Server Interface
Client ndash Proxy Interface
CoAP Sleep-Aware Reverse Proxy Features CoRE Sleep-aware Resource Directory
Support storing published sleep parameters from CoAP servers sleepState (AWAKE ASLEEP) sleepDuration
Sleep-aware CoAP 503 Response Capability If CoAP request to a sleeping server is received proxy returns a
lsquo503 Retry-Afterrsquo response to client 503 contains a timestamp indicating when the sever will wake back up
(timestamp delivered in CoAP maxAge option) Sleep-aware CoAP Store-and-Forward Capability
If CoAP request to a sleeping server is received proxy stores request until server wakes up and then forwards it
Caching capability Cache GET responses from server if maxAge option is present
(this is not a sleep aware feature)
Goals of Performance Analysis
For networks having sleepy servers provide measurements to quantify the impact that CoAP sleep-awareness capabilities can have
See if sleep-awareness capabilities can
provide additional benefits even when CoAP caching is used
Overview of Performance Analysis Performed The analysis was broken up into a set of test scenarios Each test scenario used a different combination of the following
variables Client issued GET requests Server was configured as a sleepy or non-sleepy server Proxy caching of GET responses was enabled or disabled Proxy sleep-aware 503 response capability was enabled or disabled Proxy store-and-forward capability was enabled or disabled maxAge in GET responses ndash Two values were tested 60sec and 5sec of Clients ndash Two values were used ndash 1 client and 5 clients
For comparison purposes the following were held constant across all test scenarios Client issued a fixed number of requests (100) across all test scenarios Client used a delay between each GET request (35sec) to better exercise
proxyrsquos caching and sleep-awareness capabilities For sleepy server test scenarios the server slept 60 sec awake for 3 sec
Format of Results The following results were collected for each
test scenario
Breakdown of the and types of transactions occurring between clientproxyserver
ldquoGETrdquo ndash Test Scenario Results
GET ndash Description of Test Scenarios
TestScenarios-GET
Scenario
CoAPSleepyServerSe7ngs CoAPSleepAwareReverseProxySe7ngs CoAPClientSe7ngs
SleepDuragton(sec)
AwakeDuragton(sec)
maxAge(sec) Caching SleepAwareSAF+
503NumberofClients
NumberofGETs
DelayBetweenClient
Requests(sec)
1a 0 Always 60 Enabled Disabled 1 100 35
1b 60 3 60 Enabled Disabled 1 100 35
1c 60 3 60 Enabled Enabled 1 100 35
2a 0 Always 60 Enabled Disabled 5 100 35
2b 60 3 60 Enabled Disabled 5 100 35
2c 60 3 60 Enabled Enabled 5 100 35
3a 0 Always 5 Enabled Disabled 5 100 35
3b 60 3 5 Enabled Disabled 5 100 35
3c 60 3 5 Enabled Enabled 5 100 35
ldquoGETrdquo ndash Test Scenario 1 Results
maxAge = 60 and 1 Client
GET ndash Scenario 1 ClientProxy Interface Transaction Mix
Scenarios 1a - Non-Sleepy Server Caching Proxy maxAge = 60sec 1b- Sleepy Server Caching Proxy maxAge = 60sec 1c - Sleepy Server Sleep Aware Proxy maxAge = 60sec
Sleep Aware Proxy has better performance for sleepy servers
0
100
200
300
400
500
600
700
1a 1b 1c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
GET ndash Scenario 1 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
Scenarios 1a - Non-Sleepy Server Caching Proxy maxAge = 60sec 1b- Sleepy Server Caching Proxy maxAge = 60sec 1c - Sleepy Server Sleep Aware Proxy maxAge = 60sec
0
100
200
300
400
500
600
700
800
1a 1b 1c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
ldquoGETrdquo ndash Test Scenario 2 Results
maxAge = 60 and 5 Clients
GET ndash Scenario 2 ClientProxy Interface Transaction Mix
Sleep Aware Proxy has slightly better performance for sleepy servers
0
200
400
600
800
1000
1200
1400
2a 2b 2c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
Scenarios 2a - Non-Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2b- Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2c - Sleepy Server Sleep Aware Proxy maxAge = 60sec 5 Clients
See ldquoExperimental Artifactsrdquo Note 1
GET ndash Scenario 2 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has slightly better performance for sleepy servers
0
50
100
150
200
250
300
350
400
2a 2b 2c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
Scenarios 2a - Non-Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2b- Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2c - Sleepy Server Sleep Aware Proxy maxAge = 60sec 5 Clients
See ldquoExperimental Artifactsrdquo Note 2
Experimental Artifacts Note 1
Currently in the experiment the sleep aware proxy checks the cached state of a resource before putting a request into its Store-and-forward queue while a server is sleeping Once in the queue the proxy unconditionally forwards the queued requests to the server once it wakes up This is not the most efficient setup and can easily be improved If the proxy instead checks its cache again before forwarding each queued request it may not need to forward the request to the server For example if there are two queued GET requests in the proxyrsquos queue that address the same resource Only the first request needs to be sent to the server the second request can use the cached response from the first request
Note 2 Currently in the experiment the sleepy server sends a sleepState PUT request to the
proxy each time it goes to sleep This is not the most efficient setup and can easily be improved For example if the server assumes that the proxy can keep track of its ONOFF cycles with its internal timers (eg as per Fig 1 of I-D) then the number of messages from the sleepy server dramatically goes down
ldquoGETrdquo ndash Test Scenario 3 Results
maxAge = 5 and 5 Clients
GET ndash Scenario 3 ClientProxy Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
Scenarios 3a - Non-Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3b- Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3c - Sleepy Server Sleep Aware Proxy maxAge = 5sec 5 Clients
0
500
1000
1500
2000
2500
3000
3500
4000
4500
5000
3a 3b 3c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
GET ndash Scenario 3 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
0
1000
2000
3000
4000
5000
6000
7000
3a 3b 3c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
Scenarios 3a - Non-Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3b- Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3c - Sleepy Server Sleep Aware Proxy maxAge = 5sec 5 Clients
Conclusions
Conclusions These results show that sleep-aware CoAP
proxy features can significantly optimize communication with sleepy servers in most scenarios
These results also show that sleep-
awareness capabilities can provide additional benefits above and beyond CoAP caching in most scenarios
Backup
Current CoAP Support of Sleepy Node (12)
CoAP proxies can use a previously cached response to service a new GET request for a sleepy origin server (as in HTTP) But if no valid cache then proxy has to attempt to
retrieve and may fail if origin server is sleeping [I-Dietf-core-coap]
Clients can discover list of resources from RD (GET rd-lookuphellip) for sleepy servers But attempt to GET resource from sleepy origin server
may fail if origin server is sleeping [IDietf-core-link-format amp IDshelby-core-resource-
directory]
Current CoAP Support of Sleepy Node (22)
Lower layer support for sleepy nodes in most wireless technologies (eg WiFi ZigBee) But limited to MAC packet scheduling for sleepy nodes
and not aware of specific needs of IP applications (like CoAP)
Proposal ndash RD Based Sleep Tracking (14)
The current CoAP approach to support sleepy nodes can be significantly improved by introducing RD based mechanisms for a CoAP client to determine whether A targeted resource is located on a sleepy server A sleepy server is currently in sleep mode or not
There is any associated caching Proxy (possibly the RD itself) for a sleepy server
Proposal ndash RD Based Sleep Tracking (24)
We define the following new RD attributes to characterize the properties of a sleepy node SleepState - Indicates whether the node is currently in
sleep mode or not (ie Sleeping or Awake) SleepDuration - Indicates the maximum duration of time
that the node stays in sleep mode TimeSleeping - Indicates the length of time the node
has been sleeping (ie if Sleep State = Sleeping) NextSleep - Indicates the next time the node will go to
sleep (ie if Sleep State = Awake)
CachingProxy ndash Indicates the caching proxy of the sleepy node (ie the RD itself or another node)
Proposal ndash RD Based Sleep Tracking (34)
These attributes are all server (node) level and are new parameters added to the RD URI Template Variables
Finally we also define a new lookup-type (ss) for the RD lookup interface specified in [I-Dshelby-core-resource-directory] This new lookup-type supports looking up the
ldquoSleepStaterdquo (ss) of a specified end-point
Proposal ndash RD Based Sleep Tracking (44)
The three time based parameters (SleepDuration TimeSleeping NextSleep) can be based on either an absolute network time (for a time synchronized network) or a relative local time (measured at the local node)
Following the approach of [I-Dietf-core-link-format] and [I-Dshelby-core-resource-directory] sleep parameters for sleepy servers can be stored by the server in the RD and accessed by all interested clients
Examples of using these parameters in a synchronous or asynchronous manner are shown in the I-D
http6lowappnet coreIETF86 2013-03-12-13
We assume people have read the drafts
Meetings serve to advance difficult issues by making good use of face-to-face communications
Note Well Be aware of the IPR principles according to RFC 3979 and its updates
uumlBlue sheetsuumlScribe(s)
96
drar-shy‐iep-shy‐core-shy‐coapsubmiqed13 to13 IESG
2013-shy‐03-shy‐13
97
OMA Lightweight M2M Overview(A new standard using lots of IETF specs including DTLS
CoAP Block Observe Resource Directory SenMLhellip)
Zach ShelbyCoRE WG IETF-86 Orlando
OMA Lightweight M2Mbull Open Mobile Alliance is well known for Device Management (DM)bull OMA Lightweight M2M is a new standard from the alliance
ndash Focused on constrained Cellular and sensor network M2M devicesndash Driven by leading operators and vendors
bull Scopendash Interfaces protocol amp security between Device and Serverndash Object and Resource modelndash Bootstrap Device Access Control Connectivity and Firmware Objects
bull Draft Specifications are availablendash httpmemberopenmobileallianceorgftpPublic_documentsDM
LightweightM2MPermanent_documentsOMA-TS-LightweightM2M-V1_0_0-20130301-Dzip
bull Timelinendash Requirements and Architecture completed 3Q2012ndash Spec ready for Consistency Review 2Q2013ndash Candidate Approval expected 3Q2013
2 CoRE WG IETF-86 Orlando
Architecture
3
Scope of LWM2M
CoRE WG IETF-86 Orlando
Object Model
bull A Client has one or more Object Instancesbull An Object is a collection of Resourcesbull A Resource is an atomic piece of information
ndash Read Written or Executed
bull Resources can have multiple instancesbull Objects and Resources are identified by a
16-bit Integer Instances by an 8-bit Integerbull ObjectsResources are accessed with
simple URIs Object IDObject InstanceResource ID
eg 1213
4 CoRE WG IETF-86 Orlando
CoRE WG IETF-86 Orlando
CoRE Resource Directory
draft-shelby-core-resource-directory-05
Z Shelby C Bormann S Krco
Backgroundbull Not a new concept
ndash think web search engine or any link directorybull Defines the interfaces to a Resource Directorybull Based on Web Linking framework and the CoRE Link Formatbull Generic REST design for use over HTTP and CoAPbull Used by OMA Lightweight M2Mbull Has already been deployed
ndash In traffic monitoring systemsndash In street lighting systemsndash For vehicular asset trackingndash By a major Cellular M2M operator
Changes since -04
bull Restricted Update to parameter updatesbull Added pagination support for the Lookup interfacebull Changed rt= to et= for the registration amp update
interfacebull Added group support
Group Management
bull RD now includes group management featuresbull New Group Function Set
ndash Register a groupbull Group name domain multicast address endpoint members
ndash Remove a groupbull Group lookup using the Lookup Function Set
ndash List registered groupsndash Find the members of a groupndash Find groups with certain endpoints or resources
Registering a Group
EP RD
| |
| - POST rd-groupgp=lights ltgtep=node1 --gt |
| |
| |
| lt---- 201 Created Location rd-group12 ---- |
| |
Req POST coaprdexamplecomrd-groupgp=lights
Payload
ltgtep=node1
ltgtep=node2
Res 201 Created
Location rd-group12
Looking up Group Members
Client RD
| |
| ----- GET rd-lookupepgp=lights1 ----------------------gt |
| |
| |
| lt-- 205 Content ltrdgtd=domain1ltrdgtd=domain2 --------- |
| |
Req GET rd-lookupepgp=lights1
Res 205 Content
ltcoaphostportgtep=node1
ltcoaphostportgtep=node2rdquo
Things for the futurebull Support for JSON representation of Web Links
ndash httptoolsietforgiddraft-bormann-core-links-json-02txtbull Registry for RD registration query parameters
ndash Already OMA Lightweight has defined some new onesbull More examples
Group 3 ldquonew workrdquo(continued)
109
drar-shy‐greevenbosch-shy‐core-shy‐profile-shy‐descripon-shy‐01Bert13 GreevenboschJeroen13 Hoebeke
Isam13 IshaqFloris13 Van13 den13 Abeele
Descripon
bull JSON13 format13 for13 signalling13 the13 servers13 capabilies
bull Signalling13 of13 supported13 opons13 media13 types13 and13 block13 sizendash Other13 items13 can13 be13 added
bull Filtering13 on13 specific13 fields13 through13 URI-shy‐Querybull Link13 hqpdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐profile-shy‐descripon
well-shy‐knownprofile
bull To13 acquire13 profile13 data13 of13 resources13 on13 a13 parcular13 service13 the13 well-shy‐knownprofile13 URI-shy‐path13 is13 introduced
bull For13 example13 to13 get13 all13 informaon13 from13 sensors13 served13 by13 wwwexampleorg13 we13 can13 do13 a13 GET13 to13 coapwwwexampleorgwell-shy‐knownprofile
bull Filtering13 on13 parcular13 resources13 is13 done13 through13 URI-shy‐Queries
Format
bull Currently13 the13 following13 fields13 are13 definedndash ldquopathrdquo13 contains13 the13 URI-shy‐path13 associated13 with13 a13 resource
ndash ldquooprdquo13 a13 numerical13 list13 of13 supported13 opon13 numbers
ndash ldquocfrdquo13 a13 numerical13 list13 of13 supported13 content-shy‐format13 numbers
ndash ldquob1srdquo13 ldquob2srdquo13 supported13 block13 sizes13 for13 Block113 and13 Block213 respecvely
Examplebull On13 the13 right13 is13 an13 example13 of13 a13 camera13 sensor13 at13 coapwwwexampleorgcam13 that13 supports13 the13 Uri-shy‐Host13 (3)13 ETag13 (4)13 Uri-shy‐Port13 (7)13 Uri-shy‐Path13 (11)13 Content-shy‐Format13 (12)13 Token13 (19)13 Block213 (23)13 and13 Proxy-shy‐Uri13 (35)13 opons
bull The13 supported13 content13 formats13 are13 textplain13 (0)13 applicaon13 link-shy‐format13 (40)13 and13 applicaonjson13 (50)
bull The13 supported13 Block213 can13 use13 25613 or13 51213 byte13 blocks
Req13 GET13 coapwwwexampleorgwell-shy‐knownprofile13 Res13 20513 Content13 (applicationjson)13 13 13 13 profile13 13 13 13 13 13 13 13 pathcam13 13 13 13 op[3471112192335]13 13 13 13 13 cf[04050]13 13 13 13 13 b2s[45]13 13 13 13
Filtering13 through13 use13 of13 URI-shy‐Query
bull Filtering13 can13 be13 done13 through13 the13 URI-shy‐Querybull Query13 format13 N=V
ndash N13 is13 a13 profile13 fieldndash V13 is13 the13 desired13 value
bull Examplesndash To13 find13 resources13 that13 support13 content13 format13 ldquoapplicaonjsonrdquo
13 GET13 wwwexampleorgwell-shy‐knownprofilecf=50ndash To13 get13 informaon13 about13 the13 camera
13 GET13 wwwexampleorgwell-shy‐knownprofilepath=cam
Open13 issues
bull Which13 other13 profile13 data13 needs13 signallingndash Content-shy‐type13 for13 different13 methods
bull Fix13 the13 order13 in13 which13 the13 profile13 fields13 must13 appearndash Non-shy‐fixed13 order13 easier13 extensible
bull Inheritance13 of13 a13 profile13 descriponbull Extend13 usage13 to13 signal13 the13 client13 profilebull Integraon13 with13 link13 format
Thank13 youQuesons
drar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval-shy‐00
Bert13 Greevenbosch
Descripon
bull The13 ldquoMinimumRequestInterval13 opon13 can13 be13 used13 to13 indicate13 the13 minimum13 me13 between13 two13 requests13 in13 a13 transacon
bull Originally13 intended13 for13 Block13 but13 also13 usable13 for13 other13 transaconsndash Example13 browsing13 a13 server
bull The13 goal13 is13 to13 reduce13 the13 server13 load13 and13 network13 traffic
bull Link13 hqpsdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval
Usage
bull The13 client13 keeps13 the13 server13 informed13 about13 its13 request13 speed13 through13 inclusion13 of13 the13 ldquoMinimumRequestIntervalrdquo13 opon
bull In13 responses13 the13 server13 fixes13 the13 minimum13 request13 interval13 through13 the13 same13 opon
bull The13 client13 obeys13 the13 speed13 indicated13 by13 the13 server
bull The13 client13 can13 send13 slower13 but13 not13 faster
Advantages
bull The13 server13 has13 means13 to13 limit13 the13 amount13 of13 incoming13 traffic
bull The13 server13 can13 prevent13 to13 become13 overloaded13 with13 too13 many13 tasks
bull The13 server13 does13 not13 need13 arficially13 slow13 down13 the13 client13 by13 sending13 late13 ACKsndash No13 need13 to13 keep13 track13 of13 delayed13 ACKsndash The13 server13 can13 perform13 other13 tasks13 instead
bull Reduced13 network13 traffic
Thank13 youQuesons
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-links-json-02txt
123
RFC 6690 (link-format) documents are somewhat foreign to many web app developerssect would prefer to have them in JSON format
There is no standard way to represent link-format documents in applicationssect but everyone knows how to handle JSON
Define a standard JSON translation for link-format
Itrsquos
not
rock
et
scien
ce
ltsensorsgtct=40title=Sensor Index ltsensorstempgtrt=temperature-cif=sensor ltsensorslightgtrt=light-luxif=sensor lthttpwwwexamplecomsensorst123gt anchor=sensorstemprel=describedby lttgtanchor=sensorstemprel=alternate [hrefsensorsct40titleSensor Index hrefsensorstemprttemperature-cifsensor hrefsensorslightrtlight-luxifsensor hrefhttpwwwexamplecomsensorst123 anchorsensorstempreldescribedby hreftanchorsensorstemprelalternate]
124
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-ipsec-for-coap-00txt
IPsec definitions for CoAP Mostly placeholder at this time Who has implementation experience with this
125
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-cross-reverse-convention-00txt
This draft has two lines of payload(based on a WGLC comment by Cullen Jennings)
coap12344567foobara=3
httpwwwproxycomwellknowncore-translate1234_4567foobara=3
Is that a useful convention to have
126
Insert CI slides here
127
128
0
5
10
15
20
25
30
35
40
10 20 30 40 50 60 70
good
put (
pps)
pps
Goodput vs pps (Econotags)
goodput
[Khattak preliminary]
Congestion Control
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-cocoa-00txt
ldquoadvancedrdquo cc (The draft is just a first shot) Others may have better ideas
129
Insert post-WGLC discussion slides here
130
Stop Continue Start
131
An Agile Retrospective
http6lowappnet coreIETF86 2013-03-12-13
Stop
132
Endless new CoAP optionssect instead use RESTful as much as possible
Move general security lifecycle out Looking at theoretical problems
http6lowappnet coreIETF86 2013-03-12-13
Continue
Interops Running code Look at real-world examples and deployments Solve their actual problems
sect Unilateral enhancements eg higher performance congestion control
sect Transports (SMS hellip)sect Make Web linking and Directories more and more usefulsect RESTful Design Paradigms for real-world problems
133
http6lowappnet coreIETF86 2013-03-12-13
Start
Further push into the (browser) web world (HTML5 browser security)
Specific supporting worksect SenMLsect URI work (dev URN hellip)sect Security Processes (next slide)
Spin outsect (We donrsquot really get to decide where this is done)
134
http6lowappnet coreIETF86 2013-03-12-13
Security
Integrate Application Network Group Keyingsect Tunnel-free setup
Donrsquot redo what has been done alreadysect ZigBee IP is finesect But what about other scenarios
Simple REST interfaces for working with keying materials and authorizationsect Start with defining objectives
Object Security for Constrained Nodes135
Re-chartering CoREWhat do we want to do now that wersquore grown up
Zach ShelbyCoRE WG IETF-86 Orlando
What is the scope
bull So we have a protocol and Web Linking what next
bull Keep with what we know besthellip1 Enhancements around CoAP2 New transports for CoAP3 New representations for Web Links4 General application layer solutions
CoRE WG IETF-86 Orlando 2
Enhancements around CoAP
bull Advanced congestion control
CoRE WG IETF-86 Orlando 3
New Transports for CoAP
bull Infrastructure for CoAP over foondash httptoolsietforgiddraft-silverajan-core-
coap-alternative-transports-01txtbull CoAP over SMS
ndash httptoolsietforgiddraft-becker-core-coap-sms-gprs-03txt
ndash OMA Lightweightbull CoAP over TCP
ndash httptoolsietforgiddraft-li-core-coap-payload-length-option-01txt
CoRE WG IETF-86 Orlando 4
New support for Web Links
bull JSON Web Linksndash httptoolsietforgiddraft-bormann-core-links-
json-02txt
2332010 CoRE WG IETF-77 Anaheim 5
General application layer solutions
bull Resource Directoryndash httptoolsietforgiddraft-shelby-core-
resource-directory-05txtndash OMA Lightweight
2332010 CoRE WG IETF-77 Anaheim 6
031113
Security13 Consideraons
bull Drar13 does13 not13 introduce13 new13 security13 requirements13 by13 itself
bull There13 may13 be13 privacy13 issues13 if13 nodes13 use13 telephone13 numbers13 or13 MAC13 addresses13 as13 public13 end13 point13 idenfiers
64
Akbar Rahman
IETF 86 March 2013 httpwwwietforgiddraft-rahman-core-sleepy-02txt
Enhanced Sleepy Node Support for CoAP
Introduction
It is expected that in CoAP networks there will be a certain portion of devices that are sleepy and which may occasionally go into a sleep mode (ie go into a low power state to conserve power) and subsequently have reduced CoAP protocol communication ability
This I-D proposes a minimal and efficient mechanism building on the Resource Directory concept (which will be integrated into a CoAP Proxy) to enhance sleepy node support in CoAP networks
Main Question from IETF-85 (Atlanta)
What performance benefit does the proposed Sleepy Node support solution give in a network that already has standard CoAP caching enabled
Sleepy Node Performance Analysis
Experimental Network
1-5 clients
Both Sleepy and Non-
Sleepy servers
Sleepy Node Performance Analysis Network Setup
CoAPSleepyServer(s)
CoAPSleepAwareReverseProxy
CoAP
Client(s)
Request
Response
Sleep9AwareCoREResourceDirectoryCapability
PublishedSleepParameters
Sleep9AwareCoAPStoreandForwardCapability Response
Request
SleepAwareCoAP503ResponseCapability
CoAPCachingCapability
bull Server supports publishing sleep parameters to proxy bull Eg Irsquom going to be asleep for X seconds
bull Proxy supports sleep-awareness capabilities bull Proxy also supports caching capability based off of maxAge bull Protocol flow similar to approach of Figure 1 (Synchronous RD Based Sleep
Tracking) of I-D
Proxy capabilities can be selectively enableddisabled
Proxy ndash Server Interface
Client ndash Proxy Interface
CoAP Sleep-Aware Reverse Proxy Features CoRE Sleep-aware Resource Directory
Support storing published sleep parameters from CoAP servers sleepState (AWAKE ASLEEP) sleepDuration
Sleep-aware CoAP 503 Response Capability If CoAP request to a sleeping server is received proxy returns a
lsquo503 Retry-Afterrsquo response to client 503 contains a timestamp indicating when the sever will wake back up
(timestamp delivered in CoAP maxAge option) Sleep-aware CoAP Store-and-Forward Capability
If CoAP request to a sleeping server is received proxy stores request until server wakes up and then forwards it
Caching capability Cache GET responses from server if maxAge option is present
(this is not a sleep aware feature)
Goals of Performance Analysis
For networks having sleepy servers provide measurements to quantify the impact that CoAP sleep-awareness capabilities can have
See if sleep-awareness capabilities can
provide additional benefits even when CoAP caching is used
Overview of Performance Analysis Performed The analysis was broken up into a set of test scenarios Each test scenario used a different combination of the following
variables Client issued GET requests Server was configured as a sleepy or non-sleepy server Proxy caching of GET responses was enabled or disabled Proxy sleep-aware 503 response capability was enabled or disabled Proxy store-and-forward capability was enabled or disabled maxAge in GET responses ndash Two values were tested 60sec and 5sec of Clients ndash Two values were used ndash 1 client and 5 clients
For comparison purposes the following were held constant across all test scenarios Client issued a fixed number of requests (100) across all test scenarios Client used a delay between each GET request (35sec) to better exercise
proxyrsquos caching and sleep-awareness capabilities For sleepy server test scenarios the server slept 60 sec awake for 3 sec
Format of Results The following results were collected for each
test scenario
Breakdown of the and types of transactions occurring between clientproxyserver
ldquoGETrdquo ndash Test Scenario Results
GET ndash Description of Test Scenarios
TestScenarios-GET
Scenario
CoAPSleepyServerSe7ngs CoAPSleepAwareReverseProxySe7ngs CoAPClientSe7ngs
SleepDuragton(sec)
AwakeDuragton(sec)
maxAge(sec) Caching SleepAwareSAF+
503NumberofClients
NumberofGETs
DelayBetweenClient
Requests(sec)
1a 0 Always 60 Enabled Disabled 1 100 35
1b 60 3 60 Enabled Disabled 1 100 35
1c 60 3 60 Enabled Enabled 1 100 35
2a 0 Always 60 Enabled Disabled 5 100 35
2b 60 3 60 Enabled Disabled 5 100 35
2c 60 3 60 Enabled Enabled 5 100 35
3a 0 Always 5 Enabled Disabled 5 100 35
3b 60 3 5 Enabled Disabled 5 100 35
3c 60 3 5 Enabled Enabled 5 100 35
ldquoGETrdquo ndash Test Scenario 1 Results
maxAge = 60 and 1 Client
GET ndash Scenario 1 ClientProxy Interface Transaction Mix
Scenarios 1a - Non-Sleepy Server Caching Proxy maxAge = 60sec 1b- Sleepy Server Caching Proxy maxAge = 60sec 1c - Sleepy Server Sleep Aware Proxy maxAge = 60sec
Sleep Aware Proxy has better performance for sleepy servers
0
100
200
300
400
500
600
700
1a 1b 1c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
GET ndash Scenario 1 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
Scenarios 1a - Non-Sleepy Server Caching Proxy maxAge = 60sec 1b- Sleepy Server Caching Proxy maxAge = 60sec 1c - Sleepy Server Sleep Aware Proxy maxAge = 60sec
0
100
200
300
400
500
600
700
800
1a 1b 1c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
ldquoGETrdquo ndash Test Scenario 2 Results
maxAge = 60 and 5 Clients
GET ndash Scenario 2 ClientProxy Interface Transaction Mix
Sleep Aware Proxy has slightly better performance for sleepy servers
0
200
400
600
800
1000
1200
1400
2a 2b 2c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
Scenarios 2a - Non-Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2b- Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2c - Sleepy Server Sleep Aware Proxy maxAge = 60sec 5 Clients
See ldquoExperimental Artifactsrdquo Note 1
GET ndash Scenario 2 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has slightly better performance for sleepy servers
0
50
100
150
200
250
300
350
400
2a 2b 2c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
Scenarios 2a - Non-Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2b- Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2c - Sleepy Server Sleep Aware Proxy maxAge = 60sec 5 Clients
See ldquoExperimental Artifactsrdquo Note 2
Experimental Artifacts Note 1
Currently in the experiment the sleep aware proxy checks the cached state of a resource before putting a request into its Store-and-forward queue while a server is sleeping Once in the queue the proxy unconditionally forwards the queued requests to the server once it wakes up This is not the most efficient setup and can easily be improved If the proxy instead checks its cache again before forwarding each queued request it may not need to forward the request to the server For example if there are two queued GET requests in the proxyrsquos queue that address the same resource Only the first request needs to be sent to the server the second request can use the cached response from the first request
Note 2 Currently in the experiment the sleepy server sends a sleepState PUT request to the
proxy each time it goes to sleep This is not the most efficient setup and can easily be improved For example if the server assumes that the proxy can keep track of its ONOFF cycles with its internal timers (eg as per Fig 1 of I-D) then the number of messages from the sleepy server dramatically goes down
ldquoGETrdquo ndash Test Scenario 3 Results
maxAge = 5 and 5 Clients
GET ndash Scenario 3 ClientProxy Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
Scenarios 3a - Non-Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3b- Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3c - Sleepy Server Sleep Aware Proxy maxAge = 5sec 5 Clients
0
500
1000
1500
2000
2500
3000
3500
4000
4500
5000
3a 3b 3c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
GET ndash Scenario 3 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
0
1000
2000
3000
4000
5000
6000
7000
3a 3b 3c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
Scenarios 3a - Non-Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3b- Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3c - Sleepy Server Sleep Aware Proxy maxAge = 5sec 5 Clients
Conclusions
Conclusions These results show that sleep-aware CoAP
proxy features can significantly optimize communication with sleepy servers in most scenarios
These results also show that sleep-
awareness capabilities can provide additional benefits above and beyond CoAP caching in most scenarios
Backup
Current CoAP Support of Sleepy Node (12)
CoAP proxies can use a previously cached response to service a new GET request for a sleepy origin server (as in HTTP) But if no valid cache then proxy has to attempt to
retrieve and may fail if origin server is sleeping [I-Dietf-core-coap]
Clients can discover list of resources from RD (GET rd-lookuphellip) for sleepy servers But attempt to GET resource from sleepy origin server
may fail if origin server is sleeping [IDietf-core-link-format amp IDshelby-core-resource-
directory]
Current CoAP Support of Sleepy Node (22)
Lower layer support for sleepy nodes in most wireless technologies (eg WiFi ZigBee) But limited to MAC packet scheduling for sleepy nodes
and not aware of specific needs of IP applications (like CoAP)
Proposal ndash RD Based Sleep Tracking (14)
The current CoAP approach to support sleepy nodes can be significantly improved by introducing RD based mechanisms for a CoAP client to determine whether A targeted resource is located on a sleepy server A sleepy server is currently in sleep mode or not
There is any associated caching Proxy (possibly the RD itself) for a sleepy server
Proposal ndash RD Based Sleep Tracking (24)
We define the following new RD attributes to characterize the properties of a sleepy node SleepState - Indicates whether the node is currently in
sleep mode or not (ie Sleeping or Awake) SleepDuration - Indicates the maximum duration of time
that the node stays in sleep mode TimeSleeping - Indicates the length of time the node
has been sleeping (ie if Sleep State = Sleeping) NextSleep - Indicates the next time the node will go to
sleep (ie if Sleep State = Awake)
CachingProxy ndash Indicates the caching proxy of the sleepy node (ie the RD itself or another node)
Proposal ndash RD Based Sleep Tracking (34)
These attributes are all server (node) level and are new parameters added to the RD URI Template Variables
Finally we also define a new lookup-type (ss) for the RD lookup interface specified in [I-Dshelby-core-resource-directory] This new lookup-type supports looking up the
ldquoSleepStaterdquo (ss) of a specified end-point
Proposal ndash RD Based Sleep Tracking (44)
The three time based parameters (SleepDuration TimeSleeping NextSleep) can be based on either an absolute network time (for a time synchronized network) or a relative local time (measured at the local node)
Following the approach of [I-Dietf-core-link-format] and [I-Dshelby-core-resource-directory] sleep parameters for sleepy servers can be stored by the server in the RD and accessed by all interested clients
Examples of using these parameters in a synchronous or asynchronous manner are shown in the I-D
http6lowappnet coreIETF86 2013-03-12-13
We assume people have read the drafts
Meetings serve to advance difficult issues by making good use of face-to-face communications
Note Well Be aware of the IPR principles according to RFC 3979 and its updates
uumlBlue sheetsuumlScribe(s)
96
drar-shy‐iep-shy‐core-shy‐coapsubmiqed13 to13 IESG
2013-shy‐03-shy‐13
97
OMA Lightweight M2M Overview(A new standard using lots of IETF specs including DTLS
CoAP Block Observe Resource Directory SenMLhellip)
Zach ShelbyCoRE WG IETF-86 Orlando
OMA Lightweight M2Mbull Open Mobile Alliance is well known for Device Management (DM)bull OMA Lightweight M2M is a new standard from the alliance
ndash Focused on constrained Cellular and sensor network M2M devicesndash Driven by leading operators and vendors
bull Scopendash Interfaces protocol amp security between Device and Serverndash Object and Resource modelndash Bootstrap Device Access Control Connectivity and Firmware Objects
bull Draft Specifications are availablendash httpmemberopenmobileallianceorgftpPublic_documentsDM
LightweightM2MPermanent_documentsOMA-TS-LightweightM2M-V1_0_0-20130301-Dzip
bull Timelinendash Requirements and Architecture completed 3Q2012ndash Spec ready for Consistency Review 2Q2013ndash Candidate Approval expected 3Q2013
2 CoRE WG IETF-86 Orlando
Architecture
3
Scope of LWM2M
CoRE WG IETF-86 Orlando
Object Model
bull A Client has one or more Object Instancesbull An Object is a collection of Resourcesbull A Resource is an atomic piece of information
ndash Read Written or Executed
bull Resources can have multiple instancesbull Objects and Resources are identified by a
16-bit Integer Instances by an 8-bit Integerbull ObjectsResources are accessed with
simple URIs Object IDObject InstanceResource ID
eg 1213
4 CoRE WG IETF-86 Orlando
CoRE WG IETF-86 Orlando
CoRE Resource Directory
draft-shelby-core-resource-directory-05
Z Shelby C Bormann S Krco
Backgroundbull Not a new concept
ndash think web search engine or any link directorybull Defines the interfaces to a Resource Directorybull Based on Web Linking framework and the CoRE Link Formatbull Generic REST design for use over HTTP and CoAPbull Used by OMA Lightweight M2Mbull Has already been deployed
ndash In traffic monitoring systemsndash In street lighting systemsndash For vehicular asset trackingndash By a major Cellular M2M operator
Changes since -04
bull Restricted Update to parameter updatesbull Added pagination support for the Lookup interfacebull Changed rt= to et= for the registration amp update
interfacebull Added group support
Group Management
bull RD now includes group management featuresbull New Group Function Set
ndash Register a groupbull Group name domain multicast address endpoint members
ndash Remove a groupbull Group lookup using the Lookup Function Set
ndash List registered groupsndash Find the members of a groupndash Find groups with certain endpoints or resources
Registering a Group
EP RD
| |
| - POST rd-groupgp=lights ltgtep=node1 --gt |
| |
| |
| lt---- 201 Created Location rd-group12 ---- |
| |
Req POST coaprdexamplecomrd-groupgp=lights
Payload
ltgtep=node1
ltgtep=node2
Res 201 Created
Location rd-group12
Looking up Group Members
Client RD
| |
| ----- GET rd-lookupepgp=lights1 ----------------------gt |
| |
| |
| lt-- 205 Content ltrdgtd=domain1ltrdgtd=domain2 --------- |
| |
Req GET rd-lookupepgp=lights1
Res 205 Content
ltcoaphostportgtep=node1
ltcoaphostportgtep=node2rdquo
Things for the futurebull Support for JSON representation of Web Links
ndash httptoolsietforgiddraft-bormann-core-links-json-02txtbull Registry for RD registration query parameters
ndash Already OMA Lightweight has defined some new onesbull More examples
Group 3 ldquonew workrdquo(continued)
109
drar-shy‐greevenbosch-shy‐core-shy‐profile-shy‐descripon-shy‐01Bert13 GreevenboschJeroen13 Hoebeke
Isam13 IshaqFloris13 Van13 den13 Abeele
Descripon
bull JSON13 format13 for13 signalling13 the13 servers13 capabilies
bull Signalling13 of13 supported13 opons13 media13 types13 and13 block13 sizendash Other13 items13 can13 be13 added
bull Filtering13 on13 specific13 fields13 through13 URI-shy‐Querybull Link13 hqpdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐profile-shy‐descripon
well-shy‐knownprofile
bull To13 acquire13 profile13 data13 of13 resources13 on13 a13 parcular13 service13 the13 well-shy‐knownprofile13 URI-shy‐path13 is13 introduced
bull For13 example13 to13 get13 all13 informaon13 from13 sensors13 served13 by13 wwwexampleorg13 we13 can13 do13 a13 GET13 to13 coapwwwexampleorgwell-shy‐knownprofile
bull Filtering13 on13 parcular13 resources13 is13 done13 through13 URI-shy‐Queries
Format
bull Currently13 the13 following13 fields13 are13 definedndash ldquopathrdquo13 contains13 the13 URI-shy‐path13 associated13 with13 a13 resource
ndash ldquooprdquo13 a13 numerical13 list13 of13 supported13 opon13 numbers
ndash ldquocfrdquo13 a13 numerical13 list13 of13 supported13 content-shy‐format13 numbers
ndash ldquob1srdquo13 ldquob2srdquo13 supported13 block13 sizes13 for13 Block113 and13 Block213 respecvely
Examplebull On13 the13 right13 is13 an13 example13 of13 a13 camera13 sensor13 at13 coapwwwexampleorgcam13 that13 supports13 the13 Uri-shy‐Host13 (3)13 ETag13 (4)13 Uri-shy‐Port13 (7)13 Uri-shy‐Path13 (11)13 Content-shy‐Format13 (12)13 Token13 (19)13 Block213 (23)13 and13 Proxy-shy‐Uri13 (35)13 opons
bull The13 supported13 content13 formats13 are13 textplain13 (0)13 applicaon13 link-shy‐format13 (40)13 and13 applicaonjson13 (50)
bull The13 supported13 Block213 can13 use13 25613 or13 51213 byte13 blocks
Req13 GET13 coapwwwexampleorgwell-shy‐knownprofile13 Res13 20513 Content13 (applicationjson)13 13 13 13 profile13 13 13 13 13 13 13 13 pathcam13 13 13 13 op[3471112192335]13 13 13 13 13 cf[04050]13 13 13 13 13 b2s[45]13 13 13 13
Filtering13 through13 use13 of13 URI-shy‐Query
bull Filtering13 can13 be13 done13 through13 the13 URI-shy‐Querybull Query13 format13 N=V
ndash N13 is13 a13 profile13 fieldndash V13 is13 the13 desired13 value
bull Examplesndash To13 find13 resources13 that13 support13 content13 format13 ldquoapplicaonjsonrdquo
13 GET13 wwwexampleorgwell-shy‐knownprofilecf=50ndash To13 get13 informaon13 about13 the13 camera
13 GET13 wwwexampleorgwell-shy‐knownprofilepath=cam
Open13 issues
bull Which13 other13 profile13 data13 needs13 signallingndash Content-shy‐type13 for13 different13 methods
bull Fix13 the13 order13 in13 which13 the13 profile13 fields13 must13 appearndash Non-shy‐fixed13 order13 easier13 extensible
bull Inheritance13 of13 a13 profile13 descriponbull Extend13 usage13 to13 signal13 the13 client13 profilebull Integraon13 with13 link13 format
Thank13 youQuesons
drar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval-shy‐00
Bert13 Greevenbosch
Descripon
bull The13 ldquoMinimumRequestInterval13 opon13 can13 be13 used13 to13 indicate13 the13 minimum13 me13 between13 two13 requests13 in13 a13 transacon
bull Originally13 intended13 for13 Block13 but13 also13 usable13 for13 other13 transaconsndash Example13 browsing13 a13 server
bull The13 goal13 is13 to13 reduce13 the13 server13 load13 and13 network13 traffic
bull Link13 hqpsdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval
Usage
bull The13 client13 keeps13 the13 server13 informed13 about13 its13 request13 speed13 through13 inclusion13 of13 the13 ldquoMinimumRequestIntervalrdquo13 opon
bull In13 responses13 the13 server13 fixes13 the13 minimum13 request13 interval13 through13 the13 same13 opon
bull The13 client13 obeys13 the13 speed13 indicated13 by13 the13 server
bull The13 client13 can13 send13 slower13 but13 not13 faster
Advantages
bull The13 server13 has13 means13 to13 limit13 the13 amount13 of13 incoming13 traffic
bull The13 server13 can13 prevent13 to13 become13 overloaded13 with13 too13 many13 tasks
bull The13 server13 does13 not13 need13 arficially13 slow13 down13 the13 client13 by13 sending13 late13 ACKsndash No13 need13 to13 keep13 track13 of13 delayed13 ACKsndash The13 server13 can13 perform13 other13 tasks13 instead
bull Reduced13 network13 traffic
Thank13 youQuesons
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-links-json-02txt
123
RFC 6690 (link-format) documents are somewhat foreign to many web app developerssect would prefer to have them in JSON format
There is no standard way to represent link-format documents in applicationssect but everyone knows how to handle JSON
Define a standard JSON translation for link-format
Itrsquos
not
rock
et
scien
ce
ltsensorsgtct=40title=Sensor Index ltsensorstempgtrt=temperature-cif=sensor ltsensorslightgtrt=light-luxif=sensor lthttpwwwexamplecomsensorst123gt anchor=sensorstemprel=describedby lttgtanchor=sensorstemprel=alternate [hrefsensorsct40titleSensor Index hrefsensorstemprttemperature-cifsensor hrefsensorslightrtlight-luxifsensor hrefhttpwwwexamplecomsensorst123 anchorsensorstempreldescribedby hreftanchorsensorstemprelalternate]
124
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-ipsec-for-coap-00txt
IPsec definitions for CoAP Mostly placeholder at this time Who has implementation experience with this
125
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-cross-reverse-convention-00txt
This draft has two lines of payload(based on a WGLC comment by Cullen Jennings)
coap12344567foobara=3
httpwwwproxycomwellknowncore-translate1234_4567foobara=3
Is that a useful convention to have
126
Insert CI slides here
127
128
0
5
10
15
20
25
30
35
40
10 20 30 40 50 60 70
good
put (
pps)
pps
Goodput vs pps (Econotags)
goodput
[Khattak preliminary]
Congestion Control
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-cocoa-00txt
ldquoadvancedrdquo cc (The draft is just a first shot) Others may have better ideas
129
Insert post-WGLC discussion slides here
130
Stop Continue Start
131
An Agile Retrospective
http6lowappnet coreIETF86 2013-03-12-13
Stop
132
Endless new CoAP optionssect instead use RESTful as much as possible
Move general security lifecycle out Looking at theoretical problems
http6lowappnet coreIETF86 2013-03-12-13
Continue
Interops Running code Look at real-world examples and deployments Solve their actual problems
sect Unilateral enhancements eg higher performance congestion control
sect Transports (SMS hellip)sect Make Web linking and Directories more and more usefulsect RESTful Design Paradigms for real-world problems
133
http6lowappnet coreIETF86 2013-03-12-13
Start
Further push into the (browser) web world (HTML5 browser security)
Specific supporting worksect SenMLsect URI work (dev URN hellip)sect Security Processes (next slide)
Spin outsect (We donrsquot really get to decide where this is done)
134
http6lowappnet coreIETF86 2013-03-12-13
Security
Integrate Application Network Group Keyingsect Tunnel-free setup
Donrsquot redo what has been done alreadysect ZigBee IP is finesect But what about other scenarios
Simple REST interfaces for working with keying materials and authorizationsect Start with defining objectives
Object Security for Constrained Nodes135
Re-chartering CoREWhat do we want to do now that wersquore grown up
Zach ShelbyCoRE WG IETF-86 Orlando
What is the scope
bull So we have a protocol and Web Linking what next
bull Keep with what we know besthellip1 Enhancements around CoAP2 New transports for CoAP3 New representations for Web Links4 General application layer solutions
CoRE WG IETF-86 Orlando 2
Enhancements around CoAP
bull Advanced congestion control
CoRE WG IETF-86 Orlando 3
New Transports for CoAP
bull Infrastructure for CoAP over foondash httptoolsietforgiddraft-silverajan-core-
coap-alternative-transports-01txtbull CoAP over SMS
ndash httptoolsietforgiddraft-becker-core-coap-sms-gprs-03txt
ndash OMA Lightweightbull CoAP over TCP
ndash httptoolsietforgiddraft-li-core-coap-payload-length-option-01txt
CoRE WG IETF-86 Orlando 4
New support for Web Links
bull JSON Web Linksndash httptoolsietforgiddraft-bormann-core-links-
json-02txt
2332010 CoRE WG IETF-77 Anaheim 5
General application layer solutions
bull Resource Directoryndash httptoolsietforgiddraft-shelby-core-
resource-directory-05txtndash OMA Lightweight
2332010 CoRE WG IETF-77 Anaheim 6
Akbar Rahman
IETF 86 March 2013 httpwwwietforgiddraft-rahman-core-sleepy-02txt
Enhanced Sleepy Node Support for CoAP
Introduction
It is expected that in CoAP networks there will be a certain portion of devices that are sleepy and which may occasionally go into a sleep mode (ie go into a low power state to conserve power) and subsequently have reduced CoAP protocol communication ability
This I-D proposes a minimal and efficient mechanism building on the Resource Directory concept (which will be integrated into a CoAP Proxy) to enhance sleepy node support in CoAP networks
Main Question from IETF-85 (Atlanta)
What performance benefit does the proposed Sleepy Node support solution give in a network that already has standard CoAP caching enabled
Sleepy Node Performance Analysis
Experimental Network
1-5 clients
Both Sleepy and Non-
Sleepy servers
Sleepy Node Performance Analysis Network Setup
CoAPSleepyServer(s)
CoAPSleepAwareReverseProxy
CoAP
Client(s)
Request
Response
Sleep9AwareCoREResourceDirectoryCapability
PublishedSleepParameters
Sleep9AwareCoAPStoreandForwardCapability Response
Request
SleepAwareCoAP503ResponseCapability
CoAPCachingCapability
bull Server supports publishing sleep parameters to proxy bull Eg Irsquom going to be asleep for X seconds
bull Proxy supports sleep-awareness capabilities bull Proxy also supports caching capability based off of maxAge bull Protocol flow similar to approach of Figure 1 (Synchronous RD Based Sleep
Tracking) of I-D
Proxy capabilities can be selectively enableddisabled
Proxy ndash Server Interface
Client ndash Proxy Interface
CoAP Sleep-Aware Reverse Proxy Features CoRE Sleep-aware Resource Directory
Support storing published sleep parameters from CoAP servers sleepState (AWAKE ASLEEP) sleepDuration
Sleep-aware CoAP 503 Response Capability If CoAP request to a sleeping server is received proxy returns a
lsquo503 Retry-Afterrsquo response to client 503 contains a timestamp indicating when the sever will wake back up
(timestamp delivered in CoAP maxAge option) Sleep-aware CoAP Store-and-Forward Capability
If CoAP request to a sleeping server is received proxy stores request until server wakes up and then forwards it
Caching capability Cache GET responses from server if maxAge option is present
(this is not a sleep aware feature)
Goals of Performance Analysis
For networks having sleepy servers provide measurements to quantify the impact that CoAP sleep-awareness capabilities can have
See if sleep-awareness capabilities can
provide additional benefits even when CoAP caching is used
Overview of Performance Analysis Performed The analysis was broken up into a set of test scenarios Each test scenario used a different combination of the following
variables Client issued GET requests Server was configured as a sleepy or non-sleepy server Proxy caching of GET responses was enabled or disabled Proxy sleep-aware 503 response capability was enabled or disabled Proxy store-and-forward capability was enabled or disabled maxAge in GET responses ndash Two values were tested 60sec and 5sec of Clients ndash Two values were used ndash 1 client and 5 clients
For comparison purposes the following were held constant across all test scenarios Client issued a fixed number of requests (100) across all test scenarios Client used a delay between each GET request (35sec) to better exercise
proxyrsquos caching and sleep-awareness capabilities For sleepy server test scenarios the server slept 60 sec awake for 3 sec
Format of Results The following results were collected for each
test scenario
Breakdown of the and types of transactions occurring between clientproxyserver
ldquoGETrdquo ndash Test Scenario Results
GET ndash Description of Test Scenarios
TestScenarios-GET
Scenario
CoAPSleepyServerSe7ngs CoAPSleepAwareReverseProxySe7ngs CoAPClientSe7ngs
SleepDuragton(sec)
AwakeDuragton(sec)
maxAge(sec) Caching SleepAwareSAF+
503NumberofClients
NumberofGETs
DelayBetweenClient
Requests(sec)
1a 0 Always 60 Enabled Disabled 1 100 35
1b 60 3 60 Enabled Disabled 1 100 35
1c 60 3 60 Enabled Enabled 1 100 35
2a 0 Always 60 Enabled Disabled 5 100 35
2b 60 3 60 Enabled Disabled 5 100 35
2c 60 3 60 Enabled Enabled 5 100 35
3a 0 Always 5 Enabled Disabled 5 100 35
3b 60 3 5 Enabled Disabled 5 100 35
3c 60 3 5 Enabled Enabled 5 100 35
ldquoGETrdquo ndash Test Scenario 1 Results
maxAge = 60 and 1 Client
GET ndash Scenario 1 ClientProxy Interface Transaction Mix
Scenarios 1a - Non-Sleepy Server Caching Proxy maxAge = 60sec 1b- Sleepy Server Caching Proxy maxAge = 60sec 1c - Sleepy Server Sleep Aware Proxy maxAge = 60sec
Sleep Aware Proxy has better performance for sleepy servers
0
100
200
300
400
500
600
700
1a 1b 1c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
GET ndash Scenario 1 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
Scenarios 1a - Non-Sleepy Server Caching Proxy maxAge = 60sec 1b- Sleepy Server Caching Proxy maxAge = 60sec 1c - Sleepy Server Sleep Aware Proxy maxAge = 60sec
0
100
200
300
400
500
600
700
800
1a 1b 1c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
ldquoGETrdquo ndash Test Scenario 2 Results
maxAge = 60 and 5 Clients
GET ndash Scenario 2 ClientProxy Interface Transaction Mix
Sleep Aware Proxy has slightly better performance for sleepy servers
0
200
400
600
800
1000
1200
1400
2a 2b 2c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
Scenarios 2a - Non-Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2b- Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2c - Sleepy Server Sleep Aware Proxy maxAge = 60sec 5 Clients
See ldquoExperimental Artifactsrdquo Note 1
GET ndash Scenario 2 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has slightly better performance for sleepy servers
0
50
100
150
200
250
300
350
400
2a 2b 2c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
Scenarios 2a - Non-Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2b- Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2c - Sleepy Server Sleep Aware Proxy maxAge = 60sec 5 Clients
See ldquoExperimental Artifactsrdquo Note 2
Experimental Artifacts Note 1
Currently in the experiment the sleep aware proxy checks the cached state of a resource before putting a request into its Store-and-forward queue while a server is sleeping Once in the queue the proxy unconditionally forwards the queued requests to the server once it wakes up This is not the most efficient setup and can easily be improved If the proxy instead checks its cache again before forwarding each queued request it may not need to forward the request to the server For example if there are two queued GET requests in the proxyrsquos queue that address the same resource Only the first request needs to be sent to the server the second request can use the cached response from the first request
Note 2 Currently in the experiment the sleepy server sends a sleepState PUT request to the
proxy each time it goes to sleep This is not the most efficient setup and can easily be improved For example if the server assumes that the proxy can keep track of its ONOFF cycles with its internal timers (eg as per Fig 1 of I-D) then the number of messages from the sleepy server dramatically goes down
ldquoGETrdquo ndash Test Scenario 3 Results
maxAge = 5 and 5 Clients
GET ndash Scenario 3 ClientProxy Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
Scenarios 3a - Non-Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3b- Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3c - Sleepy Server Sleep Aware Proxy maxAge = 5sec 5 Clients
0
500
1000
1500
2000
2500
3000
3500
4000
4500
5000
3a 3b 3c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
GET ndash Scenario 3 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
0
1000
2000
3000
4000
5000
6000
7000
3a 3b 3c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
Scenarios 3a - Non-Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3b- Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3c - Sleepy Server Sleep Aware Proxy maxAge = 5sec 5 Clients
Conclusions
Conclusions These results show that sleep-aware CoAP
proxy features can significantly optimize communication with sleepy servers in most scenarios
These results also show that sleep-
awareness capabilities can provide additional benefits above and beyond CoAP caching in most scenarios
Backup
Current CoAP Support of Sleepy Node (12)
CoAP proxies can use a previously cached response to service a new GET request for a sleepy origin server (as in HTTP) But if no valid cache then proxy has to attempt to
retrieve and may fail if origin server is sleeping [I-Dietf-core-coap]
Clients can discover list of resources from RD (GET rd-lookuphellip) for sleepy servers But attempt to GET resource from sleepy origin server
may fail if origin server is sleeping [IDietf-core-link-format amp IDshelby-core-resource-
directory]
Current CoAP Support of Sleepy Node (22)
Lower layer support for sleepy nodes in most wireless technologies (eg WiFi ZigBee) But limited to MAC packet scheduling for sleepy nodes
and not aware of specific needs of IP applications (like CoAP)
Proposal ndash RD Based Sleep Tracking (14)
The current CoAP approach to support sleepy nodes can be significantly improved by introducing RD based mechanisms for a CoAP client to determine whether A targeted resource is located on a sleepy server A sleepy server is currently in sleep mode or not
There is any associated caching Proxy (possibly the RD itself) for a sleepy server
Proposal ndash RD Based Sleep Tracking (24)
We define the following new RD attributes to characterize the properties of a sleepy node SleepState - Indicates whether the node is currently in
sleep mode or not (ie Sleeping or Awake) SleepDuration - Indicates the maximum duration of time
that the node stays in sleep mode TimeSleeping - Indicates the length of time the node
has been sleeping (ie if Sleep State = Sleeping) NextSleep - Indicates the next time the node will go to
sleep (ie if Sleep State = Awake)
CachingProxy ndash Indicates the caching proxy of the sleepy node (ie the RD itself or another node)
Proposal ndash RD Based Sleep Tracking (34)
These attributes are all server (node) level and are new parameters added to the RD URI Template Variables
Finally we also define a new lookup-type (ss) for the RD lookup interface specified in [I-Dshelby-core-resource-directory] This new lookup-type supports looking up the
ldquoSleepStaterdquo (ss) of a specified end-point
Proposal ndash RD Based Sleep Tracking (44)
The three time based parameters (SleepDuration TimeSleeping NextSleep) can be based on either an absolute network time (for a time synchronized network) or a relative local time (measured at the local node)
Following the approach of [I-Dietf-core-link-format] and [I-Dshelby-core-resource-directory] sleep parameters for sleepy servers can be stored by the server in the RD and accessed by all interested clients
Examples of using these parameters in a synchronous or asynchronous manner are shown in the I-D
http6lowappnet coreIETF86 2013-03-12-13
We assume people have read the drafts
Meetings serve to advance difficult issues by making good use of face-to-face communications
Note Well Be aware of the IPR principles according to RFC 3979 and its updates
uumlBlue sheetsuumlScribe(s)
96
drar-shy‐iep-shy‐core-shy‐coapsubmiqed13 to13 IESG
2013-shy‐03-shy‐13
97
OMA Lightweight M2M Overview(A new standard using lots of IETF specs including DTLS
CoAP Block Observe Resource Directory SenMLhellip)
Zach ShelbyCoRE WG IETF-86 Orlando
OMA Lightweight M2Mbull Open Mobile Alliance is well known for Device Management (DM)bull OMA Lightweight M2M is a new standard from the alliance
ndash Focused on constrained Cellular and sensor network M2M devicesndash Driven by leading operators and vendors
bull Scopendash Interfaces protocol amp security between Device and Serverndash Object and Resource modelndash Bootstrap Device Access Control Connectivity and Firmware Objects
bull Draft Specifications are availablendash httpmemberopenmobileallianceorgftpPublic_documentsDM
LightweightM2MPermanent_documentsOMA-TS-LightweightM2M-V1_0_0-20130301-Dzip
bull Timelinendash Requirements and Architecture completed 3Q2012ndash Spec ready for Consistency Review 2Q2013ndash Candidate Approval expected 3Q2013
2 CoRE WG IETF-86 Orlando
Architecture
3
Scope of LWM2M
CoRE WG IETF-86 Orlando
Object Model
bull A Client has one or more Object Instancesbull An Object is a collection of Resourcesbull A Resource is an atomic piece of information
ndash Read Written or Executed
bull Resources can have multiple instancesbull Objects and Resources are identified by a
16-bit Integer Instances by an 8-bit Integerbull ObjectsResources are accessed with
simple URIs Object IDObject InstanceResource ID
eg 1213
4 CoRE WG IETF-86 Orlando
CoRE WG IETF-86 Orlando
CoRE Resource Directory
draft-shelby-core-resource-directory-05
Z Shelby C Bormann S Krco
Backgroundbull Not a new concept
ndash think web search engine or any link directorybull Defines the interfaces to a Resource Directorybull Based on Web Linking framework and the CoRE Link Formatbull Generic REST design for use over HTTP and CoAPbull Used by OMA Lightweight M2Mbull Has already been deployed
ndash In traffic monitoring systemsndash In street lighting systemsndash For vehicular asset trackingndash By a major Cellular M2M operator
Changes since -04
bull Restricted Update to parameter updatesbull Added pagination support for the Lookup interfacebull Changed rt= to et= for the registration amp update
interfacebull Added group support
Group Management
bull RD now includes group management featuresbull New Group Function Set
ndash Register a groupbull Group name domain multicast address endpoint members
ndash Remove a groupbull Group lookup using the Lookup Function Set
ndash List registered groupsndash Find the members of a groupndash Find groups with certain endpoints or resources
Registering a Group
EP RD
| |
| - POST rd-groupgp=lights ltgtep=node1 --gt |
| |
| |
| lt---- 201 Created Location rd-group12 ---- |
| |
Req POST coaprdexamplecomrd-groupgp=lights
Payload
ltgtep=node1
ltgtep=node2
Res 201 Created
Location rd-group12
Looking up Group Members
Client RD
| |
| ----- GET rd-lookupepgp=lights1 ----------------------gt |
| |
| |
| lt-- 205 Content ltrdgtd=domain1ltrdgtd=domain2 --------- |
| |
Req GET rd-lookupepgp=lights1
Res 205 Content
ltcoaphostportgtep=node1
ltcoaphostportgtep=node2rdquo
Things for the futurebull Support for JSON representation of Web Links
ndash httptoolsietforgiddraft-bormann-core-links-json-02txtbull Registry for RD registration query parameters
ndash Already OMA Lightweight has defined some new onesbull More examples
Group 3 ldquonew workrdquo(continued)
109
drar-shy‐greevenbosch-shy‐core-shy‐profile-shy‐descripon-shy‐01Bert13 GreevenboschJeroen13 Hoebeke
Isam13 IshaqFloris13 Van13 den13 Abeele
Descripon
bull JSON13 format13 for13 signalling13 the13 servers13 capabilies
bull Signalling13 of13 supported13 opons13 media13 types13 and13 block13 sizendash Other13 items13 can13 be13 added
bull Filtering13 on13 specific13 fields13 through13 URI-shy‐Querybull Link13 hqpdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐profile-shy‐descripon
well-shy‐knownprofile
bull To13 acquire13 profile13 data13 of13 resources13 on13 a13 parcular13 service13 the13 well-shy‐knownprofile13 URI-shy‐path13 is13 introduced
bull For13 example13 to13 get13 all13 informaon13 from13 sensors13 served13 by13 wwwexampleorg13 we13 can13 do13 a13 GET13 to13 coapwwwexampleorgwell-shy‐knownprofile
bull Filtering13 on13 parcular13 resources13 is13 done13 through13 URI-shy‐Queries
Format
bull Currently13 the13 following13 fields13 are13 definedndash ldquopathrdquo13 contains13 the13 URI-shy‐path13 associated13 with13 a13 resource
ndash ldquooprdquo13 a13 numerical13 list13 of13 supported13 opon13 numbers
ndash ldquocfrdquo13 a13 numerical13 list13 of13 supported13 content-shy‐format13 numbers
ndash ldquob1srdquo13 ldquob2srdquo13 supported13 block13 sizes13 for13 Block113 and13 Block213 respecvely
Examplebull On13 the13 right13 is13 an13 example13 of13 a13 camera13 sensor13 at13 coapwwwexampleorgcam13 that13 supports13 the13 Uri-shy‐Host13 (3)13 ETag13 (4)13 Uri-shy‐Port13 (7)13 Uri-shy‐Path13 (11)13 Content-shy‐Format13 (12)13 Token13 (19)13 Block213 (23)13 and13 Proxy-shy‐Uri13 (35)13 opons
bull The13 supported13 content13 formats13 are13 textplain13 (0)13 applicaon13 link-shy‐format13 (40)13 and13 applicaonjson13 (50)
bull The13 supported13 Block213 can13 use13 25613 or13 51213 byte13 blocks
Req13 GET13 coapwwwexampleorgwell-shy‐knownprofile13 Res13 20513 Content13 (applicationjson)13 13 13 13 profile13 13 13 13 13 13 13 13 pathcam13 13 13 13 op[3471112192335]13 13 13 13 13 cf[04050]13 13 13 13 13 b2s[45]13 13 13 13
Filtering13 through13 use13 of13 URI-shy‐Query
bull Filtering13 can13 be13 done13 through13 the13 URI-shy‐Querybull Query13 format13 N=V
ndash N13 is13 a13 profile13 fieldndash V13 is13 the13 desired13 value
bull Examplesndash To13 find13 resources13 that13 support13 content13 format13 ldquoapplicaonjsonrdquo
13 GET13 wwwexampleorgwell-shy‐knownprofilecf=50ndash To13 get13 informaon13 about13 the13 camera
13 GET13 wwwexampleorgwell-shy‐knownprofilepath=cam
Open13 issues
bull Which13 other13 profile13 data13 needs13 signallingndash Content-shy‐type13 for13 different13 methods
bull Fix13 the13 order13 in13 which13 the13 profile13 fields13 must13 appearndash Non-shy‐fixed13 order13 easier13 extensible
bull Inheritance13 of13 a13 profile13 descriponbull Extend13 usage13 to13 signal13 the13 client13 profilebull Integraon13 with13 link13 format
Thank13 youQuesons
drar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval-shy‐00
Bert13 Greevenbosch
Descripon
bull The13 ldquoMinimumRequestInterval13 opon13 can13 be13 used13 to13 indicate13 the13 minimum13 me13 between13 two13 requests13 in13 a13 transacon
bull Originally13 intended13 for13 Block13 but13 also13 usable13 for13 other13 transaconsndash Example13 browsing13 a13 server
bull The13 goal13 is13 to13 reduce13 the13 server13 load13 and13 network13 traffic
bull Link13 hqpsdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval
Usage
bull The13 client13 keeps13 the13 server13 informed13 about13 its13 request13 speed13 through13 inclusion13 of13 the13 ldquoMinimumRequestIntervalrdquo13 opon
bull In13 responses13 the13 server13 fixes13 the13 minimum13 request13 interval13 through13 the13 same13 opon
bull The13 client13 obeys13 the13 speed13 indicated13 by13 the13 server
bull The13 client13 can13 send13 slower13 but13 not13 faster
Advantages
bull The13 server13 has13 means13 to13 limit13 the13 amount13 of13 incoming13 traffic
bull The13 server13 can13 prevent13 to13 become13 overloaded13 with13 too13 many13 tasks
bull The13 server13 does13 not13 need13 arficially13 slow13 down13 the13 client13 by13 sending13 late13 ACKsndash No13 need13 to13 keep13 track13 of13 delayed13 ACKsndash The13 server13 can13 perform13 other13 tasks13 instead
bull Reduced13 network13 traffic
Thank13 youQuesons
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-links-json-02txt
123
RFC 6690 (link-format) documents are somewhat foreign to many web app developerssect would prefer to have them in JSON format
There is no standard way to represent link-format documents in applicationssect but everyone knows how to handle JSON
Define a standard JSON translation for link-format
Itrsquos
not
rock
et
scien
ce
ltsensorsgtct=40title=Sensor Index ltsensorstempgtrt=temperature-cif=sensor ltsensorslightgtrt=light-luxif=sensor lthttpwwwexamplecomsensorst123gt anchor=sensorstemprel=describedby lttgtanchor=sensorstemprel=alternate [hrefsensorsct40titleSensor Index hrefsensorstemprttemperature-cifsensor hrefsensorslightrtlight-luxifsensor hrefhttpwwwexamplecomsensorst123 anchorsensorstempreldescribedby hreftanchorsensorstemprelalternate]
124
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-ipsec-for-coap-00txt
IPsec definitions for CoAP Mostly placeholder at this time Who has implementation experience with this
125
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-cross-reverse-convention-00txt
This draft has two lines of payload(based on a WGLC comment by Cullen Jennings)
coap12344567foobara=3
httpwwwproxycomwellknowncore-translate1234_4567foobara=3
Is that a useful convention to have
126
Insert CI slides here
127
128
0
5
10
15
20
25
30
35
40
10 20 30 40 50 60 70
good
put (
pps)
pps
Goodput vs pps (Econotags)
goodput
[Khattak preliminary]
Congestion Control
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-cocoa-00txt
ldquoadvancedrdquo cc (The draft is just a first shot) Others may have better ideas
129
Insert post-WGLC discussion slides here
130
Stop Continue Start
131
An Agile Retrospective
http6lowappnet coreIETF86 2013-03-12-13
Stop
132
Endless new CoAP optionssect instead use RESTful as much as possible
Move general security lifecycle out Looking at theoretical problems
http6lowappnet coreIETF86 2013-03-12-13
Continue
Interops Running code Look at real-world examples and deployments Solve their actual problems
sect Unilateral enhancements eg higher performance congestion control
sect Transports (SMS hellip)sect Make Web linking and Directories more and more usefulsect RESTful Design Paradigms for real-world problems
133
http6lowappnet coreIETF86 2013-03-12-13
Start
Further push into the (browser) web world (HTML5 browser security)
Specific supporting worksect SenMLsect URI work (dev URN hellip)sect Security Processes (next slide)
Spin outsect (We donrsquot really get to decide where this is done)
134
http6lowappnet coreIETF86 2013-03-12-13
Security
Integrate Application Network Group Keyingsect Tunnel-free setup
Donrsquot redo what has been done alreadysect ZigBee IP is finesect But what about other scenarios
Simple REST interfaces for working with keying materials and authorizationsect Start with defining objectives
Object Security for Constrained Nodes135
Re-chartering CoREWhat do we want to do now that wersquore grown up
Zach ShelbyCoRE WG IETF-86 Orlando
What is the scope
bull So we have a protocol and Web Linking what next
bull Keep with what we know besthellip1 Enhancements around CoAP2 New transports for CoAP3 New representations for Web Links4 General application layer solutions
CoRE WG IETF-86 Orlando 2
Enhancements around CoAP
bull Advanced congestion control
CoRE WG IETF-86 Orlando 3
New Transports for CoAP
bull Infrastructure for CoAP over foondash httptoolsietforgiddraft-silverajan-core-
coap-alternative-transports-01txtbull CoAP over SMS
ndash httptoolsietforgiddraft-becker-core-coap-sms-gprs-03txt
ndash OMA Lightweightbull CoAP over TCP
ndash httptoolsietforgiddraft-li-core-coap-payload-length-option-01txt
CoRE WG IETF-86 Orlando 4
New support for Web Links
bull JSON Web Linksndash httptoolsietforgiddraft-bormann-core-links-
json-02txt
2332010 CoRE WG IETF-77 Anaheim 5
General application layer solutions
bull Resource Directoryndash httptoolsietforgiddraft-shelby-core-
resource-directory-05txtndash OMA Lightweight
2332010 CoRE WG IETF-77 Anaheim 6
Introduction
It is expected that in CoAP networks there will be a certain portion of devices that are sleepy and which may occasionally go into a sleep mode (ie go into a low power state to conserve power) and subsequently have reduced CoAP protocol communication ability
This I-D proposes a minimal and efficient mechanism building on the Resource Directory concept (which will be integrated into a CoAP Proxy) to enhance sleepy node support in CoAP networks
Main Question from IETF-85 (Atlanta)
What performance benefit does the proposed Sleepy Node support solution give in a network that already has standard CoAP caching enabled
Sleepy Node Performance Analysis
Experimental Network
1-5 clients
Both Sleepy and Non-
Sleepy servers
Sleepy Node Performance Analysis Network Setup
CoAPSleepyServer(s)
CoAPSleepAwareReverseProxy
CoAP
Client(s)
Request
Response
Sleep9AwareCoREResourceDirectoryCapability
PublishedSleepParameters
Sleep9AwareCoAPStoreandForwardCapability Response
Request
SleepAwareCoAP503ResponseCapability
CoAPCachingCapability
bull Server supports publishing sleep parameters to proxy bull Eg Irsquom going to be asleep for X seconds
bull Proxy supports sleep-awareness capabilities bull Proxy also supports caching capability based off of maxAge bull Protocol flow similar to approach of Figure 1 (Synchronous RD Based Sleep
Tracking) of I-D
Proxy capabilities can be selectively enableddisabled
Proxy ndash Server Interface
Client ndash Proxy Interface
CoAP Sleep-Aware Reverse Proxy Features CoRE Sleep-aware Resource Directory
Support storing published sleep parameters from CoAP servers sleepState (AWAKE ASLEEP) sleepDuration
Sleep-aware CoAP 503 Response Capability If CoAP request to a sleeping server is received proxy returns a
lsquo503 Retry-Afterrsquo response to client 503 contains a timestamp indicating when the sever will wake back up
(timestamp delivered in CoAP maxAge option) Sleep-aware CoAP Store-and-Forward Capability
If CoAP request to a sleeping server is received proxy stores request until server wakes up and then forwards it
Caching capability Cache GET responses from server if maxAge option is present
(this is not a sleep aware feature)
Goals of Performance Analysis
For networks having sleepy servers provide measurements to quantify the impact that CoAP sleep-awareness capabilities can have
See if sleep-awareness capabilities can
provide additional benefits even when CoAP caching is used
Overview of Performance Analysis Performed The analysis was broken up into a set of test scenarios Each test scenario used a different combination of the following
variables Client issued GET requests Server was configured as a sleepy or non-sleepy server Proxy caching of GET responses was enabled or disabled Proxy sleep-aware 503 response capability was enabled or disabled Proxy store-and-forward capability was enabled or disabled maxAge in GET responses ndash Two values were tested 60sec and 5sec of Clients ndash Two values were used ndash 1 client and 5 clients
For comparison purposes the following were held constant across all test scenarios Client issued a fixed number of requests (100) across all test scenarios Client used a delay between each GET request (35sec) to better exercise
proxyrsquos caching and sleep-awareness capabilities For sleepy server test scenarios the server slept 60 sec awake for 3 sec
Format of Results The following results were collected for each
test scenario
Breakdown of the and types of transactions occurring between clientproxyserver
ldquoGETrdquo ndash Test Scenario Results
GET ndash Description of Test Scenarios
TestScenarios-GET
Scenario
CoAPSleepyServerSe7ngs CoAPSleepAwareReverseProxySe7ngs CoAPClientSe7ngs
SleepDuragton(sec)
AwakeDuragton(sec)
maxAge(sec) Caching SleepAwareSAF+
503NumberofClients
NumberofGETs
DelayBetweenClient
Requests(sec)
1a 0 Always 60 Enabled Disabled 1 100 35
1b 60 3 60 Enabled Disabled 1 100 35
1c 60 3 60 Enabled Enabled 1 100 35
2a 0 Always 60 Enabled Disabled 5 100 35
2b 60 3 60 Enabled Disabled 5 100 35
2c 60 3 60 Enabled Enabled 5 100 35
3a 0 Always 5 Enabled Disabled 5 100 35
3b 60 3 5 Enabled Disabled 5 100 35
3c 60 3 5 Enabled Enabled 5 100 35
ldquoGETrdquo ndash Test Scenario 1 Results
maxAge = 60 and 1 Client
GET ndash Scenario 1 ClientProxy Interface Transaction Mix
Scenarios 1a - Non-Sleepy Server Caching Proxy maxAge = 60sec 1b- Sleepy Server Caching Proxy maxAge = 60sec 1c - Sleepy Server Sleep Aware Proxy maxAge = 60sec
Sleep Aware Proxy has better performance for sleepy servers
0
100
200
300
400
500
600
700
1a 1b 1c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
GET ndash Scenario 1 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
Scenarios 1a - Non-Sleepy Server Caching Proxy maxAge = 60sec 1b- Sleepy Server Caching Proxy maxAge = 60sec 1c - Sleepy Server Sleep Aware Proxy maxAge = 60sec
0
100
200
300
400
500
600
700
800
1a 1b 1c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
ldquoGETrdquo ndash Test Scenario 2 Results
maxAge = 60 and 5 Clients
GET ndash Scenario 2 ClientProxy Interface Transaction Mix
Sleep Aware Proxy has slightly better performance for sleepy servers
0
200
400
600
800
1000
1200
1400
2a 2b 2c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
Scenarios 2a - Non-Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2b- Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2c - Sleepy Server Sleep Aware Proxy maxAge = 60sec 5 Clients
See ldquoExperimental Artifactsrdquo Note 1
GET ndash Scenario 2 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has slightly better performance for sleepy servers
0
50
100
150
200
250
300
350
400
2a 2b 2c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
Scenarios 2a - Non-Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2b- Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2c - Sleepy Server Sleep Aware Proxy maxAge = 60sec 5 Clients
See ldquoExperimental Artifactsrdquo Note 2
Experimental Artifacts Note 1
Currently in the experiment the sleep aware proxy checks the cached state of a resource before putting a request into its Store-and-forward queue while a server is sleeping Once in the queue the proxy unconditionally forwards the queued requests to the server once it wakes up This is not the most efficient setup and can easily be improved If the proxy instead checks its cache again before forwarding each queued request it may not need to forward the request to the server For example if there are two queued GET requests in the proxyrsquos queue that address the same resource Only the first request needs to be sent to the server the second request can use the cached response from the first request
Note 2 Currently in the experiment the sleepy server sends a sleepState PUT request to the
proxy each time it goes to sleep This is not the most efficient setup and can easily be improved For example if the server assumes that the proxy can keep track of its ONOFF cycles with its internal timers (eg as per Fig 1 of I-D) then the number of messages from the sleepy server dramatically goes down
ldquoGETrdquo ndash Test Scenario 3 Results
maxAge = 5 and 5 Clients
GET ndash Scenario 3 ClientProxy Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
Scenarios 3a - Non-Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3b- Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3c - Sleepy Server Sleep Aware Proxy maxAge = 5sec 5 Clients
0
500
1000
1500
2000
2500
3000
3500
4000
4500
5000
3a 3b 3c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
GET ndash Scenario 3 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
0
1000
2000
3000
4000
5000
6000
7000
3a 3b 3c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
Scenarios 3a - Non-Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3b- Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3c - Sleepy Server Sleep Aware Proxy maxAge = 5sec 5 Clients
Conclusions
Conclusions These results show that sleep-aware CoAP
proxy features can significantly optimize communication with sleepy servers in most scenarios
These results also show that sleep-
awareness capabilities can provide additional benefits above and beyond CoAP caching in most scenarios
Backup
Current CoAP Support of Sleepy Node (12)
CoAP proxies can use a previously cached response to service a new GET request for a sleepy origin server (as in HTTP) But if no valid cache then proxy has to attempt to
retrieve and may fail if origin server is sleeping [I-Dietf-core-coap]
Clients can discover list of resources from RD (GET rd-lookuphellip) for sleepy servers But attempt to GET resource from sleepy origin server
may fail if origin server is sleeping [IDietf-core-link-format amp IDshelby-core-resource-
directory]
Current CoAP Support of Sleepy Node (22)
Lower layer support for sleepy nodes in most wireless technologies (eg WiFi ZigBee) But limited to MAC packet scheduling for sleepy nodes
and not aware of specific needs of IP applications (like CoAP)
Proposal ndash RD Based Sleep Tracking (14)
The current CoAP approach to support sleepy nodes can be significantly improved by introducing RD based mechanisms for a CoAP client to determine whether A targeted resource is located on a sleepy server A sleepy server is currently in sleep mode or not
There is any associated caching Proxy (possibly the RD itself) for a sleepy server
Proposal ndash RD Based Sleep Tracking (24)
We define the following new RD attributes to characterize the properties of a sleepy node SleepState - Indicates whether the node is currently in
sleep mode or not (ie Sleeping or Awake) SleepDuration - Indicates the maximum duration of time
that the node stays in sleep mode TimeSleeping - Indicates the length of time the node
has been sleeping (ie if Sleep State = Sleeping) NextSleep - Indicates the next time the node will go to
sleep (ie if Sleep State = Awake)
CachingProxy ndash Indicates the caching proxy of the sleepy node (ie the RD itself or another node)
Proposal ndash RD Based Sleep Tracking (34)
These attributes are all server (node) level and are new parameters added to the RD URI Template Variables
Finally we also define a new lookup-type (ss) for the RD lookup interface specified in [I-Dshelby-core-resource-directory] This new lookup-type supports looking up the
ldquoSleepStaterdquo (ss) of a specified end-point
Proposal ndash RD Based Sleep Tracking (44)
The three time based parameters (SleepDuration TimeSleeping NextSleep) can be based on either an absolute network time (for a time synchronized network) or a relative local time (measured at the local node)
Following the approach of [I-Dietf-core-link-format] and [I-Dshelby-core-resource-directory] sleep parameters for sleepy servers can be stored by the server in the RD and accessed by all interested clients
Examples of using these parameters in a synchronous or asynchronous manner are shown in the I-D
http6lowappnet coreIETF86 2013-03-12-13
We assume people have read the drafts
Meetings serve to advance difficult issues by making good use of face-to-face communications
Note Well Be aware of the IPR principles according to RFC 3979 and its updates
uumlBlue sheetsuumlScribe(s)
96
drar-shy‐iep-shy‐core-shy‐coapsubmiqed13 to13 IESG
2013-shy‐03-shy‐13
97
OMA Lightweight M2M Overview(A new standard using lots of IETF specs including DTLS
CoAP Block Observe Resource Directory SenMLhellip)
Zach ShelbyCoRE WG IETF-86 Orlando
OMA Lightweight M2Mbull Open Mobile Alliance is well known for Device Management (DM)bull OMA Lightweight M2M is a new standard from the alliance
ndash Focused on constrained Cellular and sensor network M2M devicesndash Driven by leading operators and vendors
bull Scopendash Interfaces protocol amp security between Device and Serverndash Object and Resource modelndash Bootstrap Device Access Control Connectivity and Firmware Objects
bull Draft Specifications are availablendash httpmemberopenmobileallianceorgftpPublic_documentsDM
LightweightM2MPermanent_documentsOMA-TS-LightweightM2M-V1_0_0-20130301-Dzip
bull Timelinendash Requirements and Architecture completed 3Q2012ndash Spec ready for Consistency Review 2Q2013ndash Candidate Approval expected 3Q2013
2 CoRE WG IETF-86 Orlando
Architecture
3
Scope of LWM2M
CoRE WG IETF-86 Orlando
Object Model
bull A Client has one or more Object Instancesbull An Object is a collection of Resourcesbull A Resource is an atomic piece of information
ndash Read Written or Executed
bull Resources can have multiple instancesbull Objects and Resources are identified by a
16-bit Integer Instances by an 8-bit Integerbull ObjectsResources are accessed with
simple URIs Object IDObject InstanceResource ID
eg 1213
4 CoRE WG IETF-86 Orlando
CoRE WG IETF-86 Orlando
CoRE Resource Directory
draft-shelby-core-resource-directory-05
Z Shelby C Bormann S Krco
Backgroundbull Not a new concept
ndash think web search engine or any link directorybull Defines the interfaces to a Resource Directorybull Based on Web Linking framework and the CoRE Link Formatbull Generic REST design for use over HTTP and CoAPbull Used by OMA Lightweight M2Mbull Has already been deployed
ndash In traffic monitoring systemsndash In street lighting systemsndash For vehicular asset trackingndash By a major Cellular M2M operator
Changes since -04
bull Restricted Update to parameter updatesbull Added pagination support for the Lookup interfacebull Changed rt= to et= for the registration amp update
interfacebull Added group support
Group Management
bull RD now includes group management featuresbull New Group Function Set
ndash Register a groupbull Group name domain multicast address endpoint members
ndash Remove a groupbull Group lookup using the Lookup Function Set
ndash List registered groupsndash Find the members of a groupndash Find groups with certain endpoints or resources
Registering a Group
EP RD
| |
| - POST rd-groupgp=lights ltgtep=node1 --gt |
| |
| |
| lt---- 201 Created Location rd-group12 ---- |
| |
Req POST coaprdexamplecomrd-groupgp=lights
Payload
ltgtep=node1
ltgtep=node2
Res 201 Created
Location rd-group12
Looking up Group Members
Client RD
| |
| ----- GET rd-lookupepgp=lights1 ----------------------gt |
| |
| |
| lt-- 205 Content ltrdgtd=domain1ltrdgtd=domain2 --------- |
| |
Req GET rd-lookupepgp=lights1
Res 205 Content
ltcoaphostportgtep=node1
ltcoaphostportgtep=node2rdquo
Things for the futurebull Support for JSON representation of Web Links
ndash httptoolsietforgiddraft-bormann-core-links-json-02txtbull Registry for RD registration query parameters
ndash Already OMA Lightweight has defined some new onesbull More examples
Group 3 ldquonew workrdquo(continued)
109
drar-shy‐greevenbosch-shy‐core-shy‐profile-shy‐descripon-shy‐01Bert13 GreevenboschJeroen13 Hoebeke
Isam13 IshaqFloris13 Van13 den13 Abeele
Descripon
bull JSON13 format13 for13 signalling13 the13 servers13 capabilies
bull Signalling13 of13 supported13 opons13 media13 types13 and13 block13 sizendash Other13 items13 can13 be13 added
bull Filtering13 on13 specific13 fields13 through13 URI-shy‐Querybull Link13 hqpdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐profile-shy‐descripon
well-shy‐knownprofile
bull To13 acquire13 profile13 data13 of13 resources13 on13 a13 parcular13 service13 the13 well-shy‐knownprofile13 URI-shy‐path13 is13 introduced
bull For13 example13 to13 get13 all13 informaon13 from13 sensors13 served13 by13 wwwexampleorg13 we13 can13 do13 a13 GET13 to13 coapwwwexampleorgwell-shy‐knownprofile
bull Filtering13 on13 parcular13 resources13 is13 done13 through13 URI-shy‐Queries
Format
bull Currently13 the13 following13 fields13 are13 definedndash ldquopathrdquo13 contains13 the13 URI-shy‐path13 associated13 with13 a13 resource
ndash ldquooprdquo13 a13 numerical13 list13 of13 supported13 opon13 numbers
ndash ldquocfrdquo13 a13 numerical13 list13 of13 supported13 content-shy‐format13 numbers
ndash ldquob1srdquo13 ldquob2srdquo13 supported13 block13 sizes13 for13 Block113 and13 Block213 respecvely
Examplebull On13 the13 right13 is13 an13 example13 of13 a13 camera13 sensor13 at13 coapwwwexampleorgcam13 that13 supports13 the13 Uri-shy‐Host13 (3)13 ETag13 (4)13 Uri-shy‐Port13 (7)13 Uri-shy‐Path13 (11)13 Content-shy‐Format13 (12)13 Token13 (19)13 Block213 (23)13 and13 Proxy-shy‐Uri13 (35)13 opons
bull The13 supported13 content13 formats13 are13 textplain13 (0)13 applicaon13 link-shy‐format13 (40)13 and13 applicaonjson13 (50)
bull The13 supported13 Block213 can13 use13 25613 or13 51213 byte13 blocks
Req13 GET13 coapwwwexampleorgwell-shy‐knownprofile13 Res13 20513 Content13 (applicationjson)13 13 13 13 profile13 13 13 13 13 13 13 13 pathcam13 13 13 13 op[3471112192335]13 13 13 13 13 cf[04050]13 13 13 13 13 b2s[45]13 13 13 13
Filtering13 through13 use13 of13 URI-shy‐Query
bull Filtering13 can13 be13 done13 through13 the13 URI-shy‐Querybull Query13 format13 N=V
ndash N13 is13 a13 profile13 fieldndash V13 is13 the13 desired13 value
bull Examplesndash To13 find13 resources13 that13 support13 content13 format13 ldquoapplicaonjsonrdquo
13 GET13 wwwexampleorgwell-shy‐knownprofilecf=50ndash To13 get13 informaon13 about13 the13 camera
13 GET13 wwwexampleorgwell-shy‐knownprofilepath=cam
Open13 issues
bull Which13 other13 profile13 data13 needs13 signallingndash Content-shy‐type13 for13 different13 methods
bull Fix13 the13 order13 in13 which13 the13 profile13 fields13 must13 appearndash Non-shy‐fixed13 order13 easier13 extensible
bull Inheritance13 of13 a13 profile13 descriponbull Extend13 usage13 to13 signal13 the13 client13 profilebull Integraon13 with13 link13 format
Thank13 youQuesons
drar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval-shy‐00
Bert13 Greevenbosch
Descripon
bull The13 ldquoMinimumRequestInterval13 opon13 can13 be13 used13 to13 indicate13 the13 minimum13 me13 between13 two13 requests13 in13 a13 transacon
bull Originally13 intended13 for13 Block13 but13 also13 usable13 for13 other13 transaconsndash Example13 browsing13 a13 server
bull The13 goal13 is13 to13 reduce13 the13 server13 load13 and13 network13 traffic
bull Link13 hqpsdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval
Usage
bull The13 client13 keeps13 the13 server13 informed13 about13 its13 request13 speed13 through13 inclusion13 of13 the13 ldquoMinimumRequestIntervalrdquo13 opon
bull In13 responses13 the13 server13 fixes13 the13 minimum13 request13 interval13 through13 the13 same13 opon
bull The13 client13 obeys13 the13 speed13 indicated13 by13 the13 server
bull The13 client13 can13 send13 slower13 but13 not13 faster
Advantages
bull The13 server13 has13 means13 to13 limit13 the13 amount13 of13 incoming13 traffic
bull The13 server13 can13 prevent13 to13 become13 overloaded13 with13 too13 many13 tasks
bull The13 server13 does13 not13 need13 arficially13 slow13 down13 the13 client13 by13 sending13 late13 ACKsndash No13 need13 to13 keep13 track13 of13 delayed13 ACKsndash The13 server13 can13 perform13 other13 tasks13 instead
bull Reduced13 network13 traffic
Thank13 youQuesons
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-links-json-02txt
123
RFC 6690 (link-format) documents are somewhat foreign to many web app developerssect would prefer to have them in JSON format
There is no standard way to represent link-format documents in applicationssect but everyone knows how to handle JSON
Define a standard JSON translation for link-format
Itrsquos
not
rock
et
scien
ce
ltsensorsgtct=40title=Sensor Index ltsensorstempgtrt=temperature-cif=sensor ltsensorslightgtrt=light-luxif=sensor lthttpwwwexamplecomsensorst123gt anchor=sensorstemprel=describedby lttgtanchor=sensorstemprel=alternate [hrefsensorsct40titleSensor Index hrefsensorstemprttemperature-cifsensor hrefsensorslightrtlight-luxifsensor hrefhttpwwwexamplecomsensorst123 anchorsensorstempreldescribedby hreftanchorsensorstemprelalternate]
124
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-ipsec-for-coap-00txt
IPsec definitions for CoAP Mostly placeholder at this time Who has implementation experience with this
125
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-cross-reverse-convention-00txt
This draft has two lines of payload(based on a WGLC comment by Cullen Jennings)
coap12344567foobara=3
httpwwwproxycomwellknowncore-translate1234_4567foobara=3
Is that a useful convention to have
126
Insert CI slides here
127
128
0
5
10
15
20
25
30
35
40
10 20 30 40 50 60 70
good
put (
pps)
pps
Goodput vs pps (Econotags)
goodput
[Khattak preliminary]
Congestion Control
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-cocoa-00txt
ldquoadvancedrdquo cc (The draft is just a first shot) Others may have better ideas
129
Insert post-WGLC discussion slides here
130
Stop Continue Start
131
An Agile Retrospective
http6lowappnet coreIETF86 2013-03-12-13
Stop
132
Endless new CoAP optionssect instead use RESTful as much as possible
Move general security lifecycle out Looking at theoretical problems
http6lowappnet coreIETF86 2013-03-12-13
Continue
Interops Running code Look at real-world examples and deployments Solve their actual problems
sect Unilateral enhancements eg higher performance congestion control
sect Transports (SMS hellip)sect Make Web linking and Directories more and more usefulsect RESTful Design Paradigms for real-world problems
133
http6lowappnet coreIETF86 2013-03-12-13
Start
Further push into the (browser) web world (HTML5 browser security)
Specific supporting worksect SenMLsect URI work (dev URN hellip)sect Security Processes (next slide)
Spin outsect (We donrsquot really get to decide where this is done)
134
http6lowappnet coreIETF86 2013-03-12-13
Security
Integrate Application Network Group Keyingsect Tunnel-free setup
Donrsquot redo what has been done alreadysect ZigBee IP is finesect But what about other scenarios
Simple REST interfaces for working with keying materials and authorizationsect Start with defining objectives
Object Security for Constrained Nodes135
Re-chartering CoREWhat do we want to do now that wersquore grown up
Zach ShelbyCoRE WG IETF-86 Orlando
What is the scope
bull So we have a protocol and Web Linking what next
bull Keep with what we know besthellip1 Enhancements around CoAP2 New transports for CoAP3 New representations for Web Links4 General application layer solutions
CoRE WG IETF-86 Orlando 2
Enhancements around CoAP
bull Advanced congestion control
CoRE WG IETF-86 Orlando 3
New Transports for CoAP
bull Infrastructure for CoAP over foondash httptoolsietforgiddraft-silverajan-core-
coap-alternative-transports-01txtbull CoAP over SMS
ndash httptoolsietforgiddraft-becker-core-coap-sms-gprs-03txt
ndash OMA Lightweightbull CoAP over TCP
ndash httptoolsietforgiddraft-li-core-coap-payload-length-option-01txt
CoRE WG IETF-86 Orlando 4
New support for Web Links
bull JSON Web Linksndash httptoolsietforgiddraft-bormann-core-links-
json-02txt
2332010 CoRE WG IETF-77 Anaheim 5
General application layer solutions
bull Resource Directoryndash httptoolsietforgiddraft-shelby-core-
resource-directory-05txtndash OMA Lightweight
2332010 CoRE WG IETF-77 Anaheim 6
Main Question from IETF-85 (Atlanta)
What performance benefit does the proposed Sleepy Node support solution give in a network that already has standard CoAP caching enabled
Sleepy Node Performance Analysis
Experimental Network
1-5 clients
Both Sleepy and Non-
Sleepy servers
Sleepy Node Performance Analysis Network Setup
CoAPSleepyServer(s)
CoAPSleepAwareReverseProxy
CoAP
Client(s)
Request
Response
Sleep9AwareCoREResourceDirectoryCapability
PublishedSleepParameters
Sleep9AwareCoAPStoreandForwardCapability Response
Request
SleepAwareCoAP503ResponseCapability
CoAPCachingCapability
bull Server supports publishing sleep parameters to proxy bull Eg Irsquom going to be asleep for X seconds
bull Proxy supports sleep-awareness capabilities bull Proxy also supports caching capability based off of maxAge bull Protocol flow similar to approach of Figure 1 (Synchronous RD Based Sleep
Tracking) of I-D
Proxy capabilities can be selectively enableddisabled
Proxy ndash Server Interface
Client ndash Proxy Interface
CoAP Sleep-Aware Reverse Proxy Features CoRE Sleep-aware Resource Directory
Support storing published sleep parameters from CoAP servers sleepState (AWAKE ASLEEP) sleepDuration
Sleep-aware CoAP 503 Response Capability If CoAP request to a sleeping server is received proxy returns a
lsquo503 Retry-Afterrsquo response to client 503 contains a timestamp indicating when the sever will wake back up
(timestamp delivered in CoAP maxAge option) Sleep-aware CoAP Store-and-Forward Capability
If CoAP request to a sleeping server is received proxy stores request until server wakes up and then forwards it
Caching capability Cache GET responses from server if maxAge option is present
(this is not a sleep aware feature)
Goals of Performance Analysis
For networks having sleepy servers provide measurements to quantify the impact that CoAP sleep-awareness capabilities can have
See if sleep-awareness capabilities can
provide additional benefits even when CoAP caching is used
Overview of Performance Analysis Performed The analysis was broken up into a set of test scenarios Each test scenario used a different combination of the following
variables Client issued GET requests Server was configured as a sleepy or non-sleepy server Proxy caching of GET responses was enabled or disabled Proxy sleep-aware 503 response capability was enabled or disabled Proxy store-and-forward capability was enabled or disabled maxAge in GET responses ndash Two values were tested 60sec and 5sec of Clients ndash Two values were used ndash 1 client and 5 clients
For comparison purposes the following were held constant across all test scenarios Client issued a fixed number of requests (100) across all test scenarios Client used a delay between each GET request (35sec) to better exercise
proxyrsquos caching and sleep-awareness capabilities For sleepy server test scenarios the server slept 60 sec awake for 3 sec
Format of Results The following results were collected for each
test scenario
Breakdown of the and types of transactions occurring between clientproxyserver
ldquoGETrdquo ndash Test Scenario Results
GET ndash Description of Test Scenarios
TestScenarios-GET
Scenario
CoAPSleepyServerSe7ngs CoAPSleepAwareReverseProxySe7ngs CoAPClientSe7ngs
SleepDuragton(sec)
AwakeDuragton(sec)
maxAge(sec) Caching SleepAwareSAF+
503NumberofClients
NumberofGETs
DelayBetweenClient
Requests(sec)
1a 0 Always 60 Enabled Disabled 1 100 35
1b 60 3 60 Enabled Disabled 1 100 35
1c 60 3 60 Enabled Enabled 1 100 35
2a 0 Always 60 Enabled Disabled 5 100 35
2b 60 3 60 Enabled Disabled 5 100 35
2c 60 3 60 Enabled Enabled 5 100 35
3a 0 Always 5 Enabled Disabled 5 100 35
3b 60 3 5 Enabled Disabled 5 100 35
3c 60 3 5 Enabled Enabled 5 100 35
ldquoGETrdquo ndash Test Scenario 1 Results
maxAge = 60 and 1 Client
GET ndash Scenario 1 ClientProxy Interface Transaction Mix
Scenarios 1a - Non-Sleepy Server Caching Proxy maxAge = 60sec 1b- Sleepy Server Caching Proxy maxAge = 60sec 1c - Sleepy Server Sleep Aware Proxy maxAge = 60sec
Sleep Aware Proxy has better performance for sleepy servers
0
100
200
300
400
500
600
700
1a 1b 1c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
GET ndash Scenario 1 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
Scenarios 1a - Non-Sleepy Server Caching Proxy maxAge = 60sec 1b- Sleepy Server Caching Proxy maxAge = 60sec 1c - Sleepy Server Sleep Aware Proxy maxAge = 60sec
0
100
200
300
400
500
600
700
800
1a 1b 1c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
ldquoGETrdquo ndash Test Scenario 2 Results
maxAge = 60 and 5 Clients
GET ndash Scenario 2 ClientProxy Interface Transaction Mix
Sleep Aware Proxy has slightly better performance for sleepy servers
0
200
400
600
800
1000
1200
1400
2a 2b 2c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
Scenarios 2a - Non-Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2b- Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2c - Sleepy Server Sleep Aware Proxy maxAge = 60sec 5 Clients
See ldquoExperimental Artifactsrdquo Note 1
GET ndash Scenario 2 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has slightly better performance for sleepy servers
0
50
100
150
200
250
300
350
400
2a 2b 2c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
Scenarios 2a - Non-Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2b- Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2c - Sleepy Server Sleep Aware Proxy maxAge = 60sec 5 Clients
See ldquoExperimental Artifactsrdquo Note 2
Experimental Artifacts Note 1
Currently in the experiment the sleep aware proxy checks the cached state of a resource before putting a request into its Store-and-forward queue while a server is sleeping Once in the queue the proxy unconditionally forwards the queued requests to the server once it wakes up This is not the most efficient setup and can easily be improved If the proxy instead checks its cache again before forwarding each queued request it may not need to forward the request to the server For example if there are two queued GET requests in the proxyrsquos queue that address the same resource Only the first request needs to be sent to the server the second request can use the cached response from the first request
Note 2 Currently in the experiment the sleepy server sends a sleepState PUT request to the
proxy each time it goes to sleep This is not the most efficient setup and can easily be improved For example if the server assumes that the proxy can keep track of its ONOFF cycles with its internal timers (eg as per Fig 1 of I-D) then the number of messages from the sleepy server dramatically goes down
ldquoGETrdquo ndash Test Scenario 3 Results
maxAge = 5 and 5 Clients
GET ndash Scenario 3 ClientProxy Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
Scenarios 3a - Non-Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3b- Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3c - Sleepy Server Sleep Aware Proxy maxAge = 5sec 5 Clients
0
500
1000
1500
2000
2500
3000
3500
4000
4500
5000
3a 3b 3c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
GET ndash Scenario 3 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
0
1000
2000
3000
4000
5000
6000
7000
3a 3b 3c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
Scenarios 3a - Non-Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3b- Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3c - Sleepy Server Sleep Aware Proxy maxAge = 5sec 5 Clients
Conclusions
Conclusions These results show that sleep-aware CoAP
proxy features can significantly optimize communication with sleepy servers in most scenarios
These results also show that sleep-
awareness capabilities can provide additional benefits above and beyond CoAP caching in most scenarios
Backup
Current CoAP Support of Sleepy Node (12)
CoAP proxies can use a previously cached response to service a new GET request for a sleepy origin server (as in HTTP) But if no valid cache then proxy has to attempt to
retrieve and may fail if origin server is sleeping [I-Dietf-core-coap]
Clients can discover list of resources from RD (GET rd-lookuphellip) for sleepy servers But attempt to GET resource from sleepy origin server
may fail if origin server is sleeping [IDietf-core-link-format amp IDshelby-core-resource-
directory]
Current CoAP Support of Sleepy Node (22)
Lower layer support for sleepy nodes in most wireless technologies (eg WiFi ZigBee) But limited to MAC packet scheduling for sleepy nodes
and not aware of specific needs of IP applications (like CoAP)
Proposal ndash RD Based Sleep Tracking (14)
The current CoAP approach to support sleepy nodes can be significantly improved by introducing RD based mechanisms for a CoAP client to determine whether A targeted resource is located on a sleepy server A sleepy server is currently in sleep mode or not
There is any associated caching Proxy (possibly the RD itself) for a sleepy server
Proposal ndash RD Based Sleep Tracking (24)
We define the following new RD attributes to characterize the properties of a sleepy node SleepState - Indicates whether the node is currently in
sleep mode or not (ie Sleeping or Awake) SleepDuration - Indicates the maximum duration of time
that the node stays in sleep mode TimeSleeping - Indicates the length of time the node
has been sleeping (ie if Sleep State = Sleeping) NextSleep - Indicates the next time the node will go to
sleep (ie if Sleep State = Awake)
CachingProxy ndash Indicates the caching proxy of the sleepy node (ie the RD itself or another node)
Proposal ndash RD Based Sleep Tracking (34)
These attributes are all server (node) level and are new parameters added to the RD URI Template Variables
Finally we also define a new lookup-type (ss) for the RD lookup interface specified in [I-Dshelby-core-resource-directory] This new lookup-type supports looking up the
ldquoSleepStaterdquo (ss) of a specified end-point
Proposal ndash RD Based Sleep Tracking (44)
The three time based parameters (SleepDuration TimeSleeping NextSleep) can be based on either an absolute network time (for a time synchronized network) or a relative local time (measured at the local node)
Following the approach of [I-Dietf-core-link-format] and [I-Dshelby-core-resource-directory] sleep parameters for sleepy servers can be stored by the server in the RD and accessed by all interested clients
Examples of using these parameters in a synchronous or asynchronous manner are shown in the I-D
http6lowappnet coreIETF86 2013-03-12-13
We assume people have read the drafts
Meetings serve to advance difficult issues by making good use of face-to-face communications
Note Well Be aware of the IPR principles according to RFC 3979 and its updates
uumlBlue sheetsuumlScribe(s)
96
drar-shy‐iep-shy‐core-shy‐coapsubmiqed13 to13 IESG
2013-shy‐03-shy‐13
97
OMA Lightweight M2M Overview(A new standard using lots of IETF specs including DTLS
CoAP Block Observe Resource Directory SenMLhellip)
Zach ShelbyCoRE WG IETF-86 Orlando
OMA Lightweight M2Mbull Open Mobile Alliance is well known for Device Management (DM)bull OMA Lightweight M2M is a new standard from the alliance
ndash Focused on constrained Cellular and sensor network M2M devicesndash Driven by leading operators and vendors
bull Scopendash Interfaces protocol amp security between Device and Serverndash Object and Resource modelndash Bootstrap Device Access Control Connectivity and Firmware Objects
bull Draft Specifications are availablendash httpmemberopenmobileallianceorgftpPublic_documentsDM
LightweightM2MPermanent_documentsOMA-TS-LightweightM2M-V1_0_0-20130301-Dzip
bull Timelinendash Requirements and Architecture completed 3Q2012ndash Spec ready for Consistency Review 2Q2013ndash Candidate Approval expected 3Q2013
2 CoRE WG IETF-86 Orlando
Architecture
3
Scope of LWM2M
CoRE WG IETF-86 Orlando
Object Model
bull A Client has one or more Object Instancesbull An Object is a collection of Resourcesbull A Resource is an atomic piece of information
ndash Read Written or Executed
bull Resources can have multiple instancesbull Objects and Resources are identified by a
16-bit Integer Instances by an 8-bit Integerbull ObjectsResources are accessed with
simple URIs Object IDObject InstanceResource ID
eg 1213
4 CoRE WG IETF-86 Orlando
CoRE WG IETF-86 Orlando
CoRE Resource Directory
draft-shelby-core-resource-directory-05
Z Shelby C Bormann S Krco
Backgroundbull Not a new concept
ndash think web search engine or any link directorybull Defines the interfaces to a Resource Directorybull Based on Web Linking framework and the CoRE Link Formatbull Generic REST design for use over HTTP and CoAPbull Used by OMA Lightweight M2Mbull Has already been deployed
ndash In traffic monitoring systemsndash In street lighting systemsndash For vehicular asset trackingndash By a major Cellular M2M operator
Changes since -04
bull Restricted Update to parameter updatesbull Added pagination support for the Lookup interfacebull Changed rt= to et= for the registration amp update
interfacebull Added group support
Group Management
bull RD now includes group management featuresbull New Group Function Set
ndash Register a groupbull Group name domain multicast address endpoint members
ndash Remove a groupbull Group lookup using the Lookup Function Set
ndash List registered groupsndash Find the members of a groupndash Find groups with certain endpoints or resources
Registering a Group
EP RD
| |
| - POST rd-groupgp=lights ltgtep=node1 --gt |
| |
| |
| lt---- 201 Created Location rd-group12 ---- |
| |
Req POST coaprdexamplecomrd-groupgp=lights
Payload
ltgtep=node1
ltgtep=node2
Res 201 Created
Location rd-group12
Looking up Group Members
Client RD
| |
| ----- GET rd-lookupepgp=lights1 ----------------------gt |
| |
| |
| lt-- 205 Content ltrdgtd=domain1ltrdgtd=domain2 --------- |
| |
Req GET rd-lookupepgp=lights1
Res 205 Content
ltcoaphostportgtep=node1
ltcoaphostportgtep=node2rdquo
Things for the futurebull Support for JSON representation of Web Links
ndash httptoolsietforgiddraft-bormann-core-links-json-02txtbull Registry for RD registration query parameters
ndash Already OMA Lightweight has defined some new onesbull More examples
Group 3 ldquonew workrdquo(continued)
109
drar-shy‐greevenbosch-shy‐core-shy‐profile-shy‐descripon-shy‐01Bert13 GreevenboschJeroen13 Hoebeke
Isam13 IshaqFloris13 Van13 den13 Abeele
Descripon
bull JSON13 format13 for13 signalling13 the13 servers13 capabilies
bull Signalling13 of13 supported13 opons13 media13 types13 and13 block13 sizendash Other13 items13 can13 be13 added
bull Filtering13 on13 specific13 fields13 through13 URI-shy‐Querybull Link13 hqpdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐profile-shy‐descripon
well-shy‐knownprofile
bull To13 acquire13 profile13 data13 of13 resources13 on13 a13 parcular13 service13 the13 well-shy‐knownprofile13 URI-shy‐path13 is13 introduced
bull For13 example13 to13 get13 all13 informaon13 from13 sensors13 served13 by13 wwwexampleorg13 we13 can13 do13 a13 GET13 to13 coapwwwexampleorgwell-shy‐knownprofile
bull Filtering13 on13 parcular13 resources13 is13 done13 through13 URI-shy‐Queries
Format
bull Currently13 the13 following13 fields13 are13 definedndash ldquopathrdquo13 contains13 the13 URI-shy‐path13 associated13 with13 a13 resource
ndash ldquooprdquo13 a13 numerical13 list13 of13 supported13 opon13 numbers
ndash ldquocfrdquo13 a13 numerical13 list13 of13 supported13 content-shy‐format13 numbers
ndash ldquob1srdquo13 ldquob2srdquo13 supported13 block13 sizes13 for13 Block113 and13 Block213 respecvely
Examplebull On13 the13 right13 is13 an13 example13 of13 a13 camera13 sensor13 at13 coapwwwexampleorgcam13 that13 supports13 the13 Uri-shy‐Host13 (3)13 ETag13 (4)13 Uri-shy‐Port13 (7)13 Uri-shy‐Path13 (11)13 Content-shy‐Format13 (12)13 Token13 (19)13 Block213 (23)13 and13 Proxy-shy‐Uri13 (35)13 opons
bull The13 supported13 content13 formats13 are13 textplain13 (0)13 applicaon13 link-shy‐format13 (40)13 and13 applicaonjson13 (50)
bull The13 supported13 Block213 can13 use13 25613 or13 51213 byte13 blocks
Req13 GET13 coapwwwexampleorgwell-shy‐knownprofile13 Res13 20513 Content13 (applicationjson)13 13 13 13 profile13 13 13 13 13 13 13 13 pathcam13 13 13 13 op[3471112192335]13 13 13 13 13 cf[04050]13 13 13 13 13 b2s[45]13 13 13 13
Filtering13 through13 use13 of13 URI-shy‐Query
bull Filtering13 can13 be13 done13 through13 the13 URI-shy‐Querybull Query13 format13 N=V
ndash N13 is13 a13 profile13 fieldndash V13 is13 the13 desired13 value
bull Examplesndash To13 find13 resources13 that13 support13 content13 format13 ldquoapplicaonjsonrdquo
13 GET13 wwwexampleorgwell-shy‐knownprofilecf=50ndash To13 get13 informaon13 about13 the13 camera
13 GET13 wwwexampleorgwell-shy‐knownprofilepath=cam
Open13 issues
bull Which13 other13 profile13 data13 needs13 signallingndash Content-shy‐type13 for13 different13 methods
bull Fix13 the13 order13 in13 which13 the13 profile13 fields13 must13 appearndash Non-shy‐fixed13 order13 easier13 extensible
bull Inheritance13 of13 a13 profile13 descriponbull Extend13 usage13 to13 signal13 the13 client13 profilebull Integraon13 with13 link13 format
Thank13 youQuesons
drar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval-shy‐00
Bert13 Greevenbosch
Descripon
bull The13 ldquoMinimumRequestInterval13 opon13 can13 be13 used13 to13 indicate13 the13 minimum13 me13 between13 two13 requests13 in13 a13 transacon
bull Originally13 intended13 for13 Block13 but13 also13 usable13 for13 other13 transaconsndash Example13 browsing13 a13 server
bull The13 goal13 is13 to13 reduce13 the13 server13 load13 and13 network13 traffic
bull Link13 hqpsdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval
Usage
bull The13 client13 keeps13 the13 server13 informed13 about13 its13 request13 speed13 through13 inclusion13 of13 the13 ldquoMinimumRequestIntervalrdquo13 opon
bull In13 responses13 the13 server13 fixes13 the13 minimum13 request13 interval13 through13 the13 same13 opon
bull The13 client13 obeys13 the13 speed13 indicated13 by13 the13 server
bull The13 client13 can13 send13 slower13 but13 not13 faster
Advantages
bull The13 server13 has13 means13 to13 limit13 the13 amount13 of13 incoming13 traffic
bull The13 server13 can13 prevent13 to13 become13 overloaded13 with13 too13 many13 tasks
bull The13 server13 does13 not13 need13 arficially13 slow13 down13 the13 client13 by13 sending13 late13 ACKsndash No13 need13 to13 keep13 track13 of13 delayed13 ACKsndash The13 server13 can13 perform13 other13 tasks13 instead
bull Reduced13 network13 traffic
Thank13 youQuesons
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-links-json-02txt
123
RFC 6690 (link-format) documents are somewhat foreign to many web app developerssect would prefer to have them in JSON format
There is no standard way to represent link-format documents in applicationssect but everyone knows how to handle JSON
Define a standard JSON translation for link-format
Itrsquos
not
rock
et
scien
ce
ltsensorsgtct=40title=Sensor Index ltsensorstempgtrt=temperature-cif=sensor ltsensorslightgtrt=light-luxif=sensor lthttpwwwexamplecomsensorst123gt anchor=sensorstemprel=describedby lttgtanchor=sensorstemprel=alternate [hrefsensorsct40titleSensor Index hrefsensorstemprttemperature-cifsensor hrefsensorslightrtlight-luxifsensor hrefhttpwwwexamplecomsensorst123 anchorsensorstempreldescribedby hreftanchorsensorstemprelalternate]
124
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-ipsec-for-coap-00txt
IPsec definitions for CoAP Mostly placeholder at this time Who has implementation experience with this
125
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-cross-reverse-convention-00txt
This draft has two lines of payload(based on a WGLC comment by Cullen Jennings)
coap12344567foobara=3
httpwwwproxycomwellknowncore-translate1234_4567foobara=3
Is that a useful convention to have
126
Insert CI slides here
127
128
0
5
10
15
20
25
30
35
40
10 20 30 40 50 60 70
good
put (
pps)
pps
Goodput vs pps (Econotags)
goodput
[Khattak preliminary]
Congestion Control
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-cocoa-00txt
ldquoadvancedrdquo cc (The draft is just a first shot) Others may have better ideas
129
Insert post-WGLC discussion slides here
130
Stop Continue Start
131
An Agile Retrospective
http6lowappnet coreIETF86 2013-03-12-13
Stop
132
Endless new CoAP optionssect instead use RESTful as much as possible
Move general security lifecycle out Looking at theoretical problems
http6lowappnet coreIETF86 2013-03-12-13
Continue
Interops Running code Look at real-world examples and deployments Solve their actual problems
sect Unilateral enhancements eg higher performance congestion control
sect Transports (SMS hellip)sect Make Web linking and Directories more and more usefulsect RESTful Design Paradigms for real-world problems
133
http6lowappnet coreIETF86 2013-03-12-13
Start
Further push into the (browser) web world (HTML5 browser security)
Specific supporting worksect SenMLsect URI work (dev URN hellip)sect Security Processes (next slide)
Spin outsect (We donrsquot really get to decide where this is done)
134
http6lowappnet coreIETF86 2013-03-12-13
Security
Integrate Application Network Group Keyingsect Tunnel-free setup
Donrsquot redo what has been done alreadysect ZigBee IP is finesect But what about other scenarios
Simple REST interfaces for working with keying materials and authorizationsect Start with defining objectives
Object Security for Constrained Nodes135
Re-chartering CoREWhat do we want to do now that wersquore grown up
Zach ShelbyCoRE WG IETF-86 Orlando
What is the scope
bull So we have a protocol and Web Linking what next
bull Keep with what we know besthellip1 Enhancements around CoAP2 New transports for CoAP3 New representations for Web Links4 General application layer solutions
CoRE WG IETF-86 Orlando 2
Enhancements around CoAP
bull Advanced congestion control
CoRE WG IETF-86 Orlando 3
New Transports for CoAP
bull Infrastructure for CoAP over foondash httptoolsietforgiddraft-silverajan-core-
coap-alternative-transports-01txtbull CoAP over SMS
ndash httptoolsietforgiddraft-becker-core-coap-sms-gprs-03txt
ndash OMA Lightweightbull CoAP over TCP
ndash httptoolsietforgiddraft-li-core-coap-payload-length-option-01txt
CoRE WG IETF-86 Orlando 4
New support for Web Links
bull JSON Web Linksndash httptoolsietforgiddraft-bormann-core-links-
json-02txt
2332010 CoRE WG IETF-77 Anaheim 5
General application layer solutions
bull Resource Directoryndash httptoolsietforgiddraft-shelby-core-
resource-directory-05txtndash OMA Lightweight
2332010 CoRE WG IETF-77 Anaheim 6
Sleepy Node Performance Analysis
Experimental Network
1-5 clients
Both Sleepy and Non-
Sleepy servers
Sleepy Node Performance Analysis Network Setup
CoAPSleepyServer(s)
CoAPSleepAwareReverseProxy
CoAP
Client(s)
Request
Response
Sleep9AwareCoREResourceDirectoryCapability
PublishedSleepParameters
Sleep9AwareCoAPStoreandForwardCapability Response
Request
SleepAwareCoAP503ResponseCapability
CoAPCachingCapability
bull Server supports publishing sleep parameters to proxy bull Eg Irsquom going to be asleep for X seconds
bull Proxy supports sleep-awareness capabilities bull Proxy also supports caching capability based off of maxAge bull Protocol flow similar to approach of Figure 1 (Synchronous RD Based Sleep
Tracking) of I-D
Proxy capabilities can be selectively enableddisabled
Proxy ndash Server Interface
Client ndash Proxy Interface
CoAP Sleep-Aware Reverse Proxy Features CoRE Sleep-aware Resource Directory
Support storing published sleep parameters from CoAP servers sleepState (AWAKE ASLEEP) sleepDuration
Sleep-aware CoAP 503 Response Capability If CoAP request to a sleeping server is received proxy returns a
lsquo503 Retry-Afterrsquo response to client 503 contains a timestamp indicating when the sever will wake back up
(timestamp delivered in CoAP maxAge option) Sleep-aware CoAP Store-and-Forward Capability
If CoAP request to a sleeping server is received proxy stores request until server wakes up and then forwards it
Caching capability Cache GET responses from server if maxAge option is present
(this is not a sleep aware feature)
Goals of Performance Analysis
For networks having sleepy servers provide measurements to quantify the impact that CoAP sleep-awareness capabilities can have
See if sleep-awareness capabilities can
provide additional benefits even when CoAP caching is used
Overview of Performance Analysis Performed The analysis was broken up into a set of test scenarios Each test scenario used a different combination of the following
variables Client issued GET requests Server was configured as a sleepy or non-sleepy server Proxy caching of GET responses was enabled or disabled Proxy sleep-aware 503 response capability was enabled or disabled Proxy store-and-forward capability was enabled or disabled maxAge in GET responses ndash Two values were tested 60sec and 5sec of Clients ndash Two values were used ndash 1 client and 5 clients
For comparison purposes the following were held constant across all test scenarios Client issued a fixed number of requests (100) across all test scenarios Client used a delay between each GET request (35sec) to better exercise
proxyrsquos caching and sleep-awareness capabilities For sleepy server test scenarios the server slept 60 sec awake for 3 sec
Format of Results The following results were collected for each
test scenario
Breakdown of the and types of transactions occurring between clientproxyserver
ldquoGETrdquo ndash Test Scenario Results
GET ndash Description of Test Scenarios
TestScenarios-GET
Scenario
CoAPSleepyServerSe7ngs CoAPSleepAwareReverseProxySe7ngs CoAPClientSe7ngs
SleepDuragton(sec)
AwakeDuragton(sec)
maxAge(sec) Caching SleepAwareSAF+
503NumberofClients
NumberofGETs
DelayBetweenClient
Requests(sec)
1a 0 Always 60 Enabled Disabled 1 100 35
1b 60 3 60 Enabled Disabled 1 100 35
1c 60 3 60 Enabled Enabled 1 100 35
2a 0 Always 60 Enabled Disabled 5 100 35
2b 60 3 60 Enabled Disabled 5 100 35
2c 60 3 60 Enabled Enabled 5 100 35
3a 0 Always 5 Enabled Disabled 5 100 35
3b 60 3 5 Enabled Disabled 5 100 35
3c 60 3 5 Enabled Enabled 5 100 35
ldquoGETrdquo ndash Test Scenario 1 Results
maxAge = 60 and 1 Client
GET ndash Scenario 1 ClientProxy Interface Transaction Mix
Scenarios 1a - Non-Sleepy Server Caching Proxy maxAge = 60sec 1b- Sleepy Server Caching Proxy maxAge = 60sec 1c - Sleepy Server Sleep Aware Proxy maxAge = 60sec
Sleep Aware Proxy has better performance for sleepy servers
0
100
200
300
400
500
600
700
1a 1b 1c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
GET ndash Scenario 1 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
Scenarios 1a - Non-Sleepy Server Caching Proxy maxAge = 60sec 1b- Sleepy Server Caching Proxy maxAge = 60sec 1c - Sleepy Server Sleep Aware Proxy maxAge = 60sec
0
100
200
300
400
500
600
700
800
1a 1b 1c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
ldquoGETrdquo ndash Test Scenario 2 Results
maxAge = 60 and 5 Clients
GET ndash Scenario 2 ClientProxy Interface Transaction Mix
Sleep Aware Proxy has slightly better performance for sleepy servers
0
200
400
600
800
1000
1200
1400
2a 2b 2c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
Scenarios 2a - Non-Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2b- Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2c - Sleepy Server Sleep Aware Proxy maxAge = 60sec 5 Clients
See ldquoExperimental Artifactsrdquo Note 1
GET ndash Scenario 2 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has slightly better performance for sleepy servers
0
50
100
150
200
250
300
350
400
2a 2b 2c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
Scenarios 2a - Non-Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2b- Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2c - Sleepy Server Sleep Aware Proxy maxAge = 60sec 5 Clients
See ldquoExperimental Artifactsrdquo Note 2
Experimental Artifacts Note 1
Currently in the experiment the sleep aware proxy checks the cached state of a resource before putting a request into its Store-and-forward queue while a server is sleeping Once in the queue the proxy unconditionally forwards the queued requests to the server once it wakes up This is not the most efficient setup and can easily be improved If the proxy instead checks its cache again before forwarding each queued request it may not need to forward the request to the server For example if there are two queued GET requests in the proxyrsquos queue that address the same resource Only the first request needs to be sent to the server the second request can use the cached response from the first request
Note 2 Currently in the experiment the sleepy server sends a sleepState PUT request to the
proxy each time it goes to sleep This is not the most efficient setup and can easily be improved For example if the server assumes that the proxy can keep track of its ONOFF cycles with its internal timers (eg as per Fig 1 of I-D) then the number of messages from the sleepy server dramatically goes down
ldquoGETrdquo ndash Test Scenario 3 Results
maxAge = 5 and 5 Clients
GET ndash Scenario 3 ClientProxy Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
Scenarios 3a - Non-Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3b- Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3c - Sleepy Server Sleep Aware Proxy maxAge = 5sec 5 Clients
0
500
1000
1500
2000
2500
3000
3500
4000
4500
5000
3a 3b 3c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
GET ndash Scenario 3 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
0
1000
2000
3000
4000
5000
6000
7000
3a 3b 3c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
Scenarios 3a - Non-Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3b- Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3c - Sleepy Server Sleep Aware Proxy maxAge = 5sec 5 Clients
Conclusions
Conclusions These results show that sleep-aware CoAP
proxy features can significantly optimize communication with sleepy servers in most scenarios
These results also show that sleep-
awareness capabilities can provide additional benefits above and beyond CoAP caching in most scenarios
Backup
Current CoAP Support of Sleepy Node (12)
CoAP proxies can use a previously cached response to service a new GET request for a sleepy origin server (as in HTTP) But if no valid cache then proxy has to attempt to
retrieve and may fail if origin server is sleeping [I-Dietf-core-coap]
Clients can discover list of resources from RD (GET rd-lookuphellip) for sleepy servers But attempt to GET resource from sleepy origin server
may fail if origin server is sleeping [IDietf-core-link-format amp IDshelby-core-resource-
directory]
Current CoAP Support of Sleepy Node (22)
Lower layer support for sleepy nodes in most wireless technologies (eg WiFi ZigBee) But limited to MAC packet scheduling for sleepy nodes
and not aware of specific needs of IP applications (like CoAP)
Proposal ndash RD Based Sleep Tracking (14)
The current CoAP approach to support sleepy nodes can be significantly improved by introducing RD based mechanisms for a CoAP client to determine whether A targeted resource is located on a sleepy server A sleepy server is currently in sleep mode or not
There is any associated caching Proxy (possibly the RD itself) for a sleepy server
Proposal ndash RD Based Sleep Tracking (24)
We define the following new RD attributes to characterize the properties of a sleepy node SleepState - Indicates whether the node is currently in
sleep mode or not (ie Sleeping or Awake) SleepDuration - Indicates the maximum duration of time
that the node stays in sleep mode TimeSleeping - Indicates the length of time the node
has been sleeping (ie if Sleep State = Sleeping) NextSleep - Indicates the next time the node will go to
sleep (ie if Sleep State = Awake)
CachingProxy ndash Indicates the caching proxy of the sleepy node (ie the RD itself or another node)
Proposal ndash RD Based Sleep Tracking (34)
These attributes are all server (node) level and are new parameters added to the RD URI Template Variables
Finally we also define a new lookup-type (ss) for the RD lookup interface specified in [I-Dshelby-core-resource-directory] This new lookup-type supports looking up the
ldquoSleepStaterdquo (ss) of a specified end-point
Proposal ndash RD Based Sleep Tracking (44)
The three time based parameters (SleepDuration TimeSleeping NextSleep) can be based on either an absolute network time (for a time synchronized network) or a relative local time (measured at the local node)
Following the approach of [I-Dietf-core-link-format] and [I-Dshelby-core-resource-directory] sleep parameters for sleepy servers can be stored by the server in the RD and accessed by all interested clients
Examples of using these parameters in a synchronous or asynchronous manner are shown in the I-D
http6lowappnet coreIETF86 2013-03-12-13
We assume people have read the drafts
Meetings serve to advance difficult issues by making good use of face-to-face communications
Note Well Be aware of the IPR principles according to RFC 3979 and its updates
uumlBlue sheetsuumlScribe(s)
96
drar-shy‐iep-shy‐core-shy‐coapsubmiqed13 to13 IESG
2013-shy‐03-shy‐13
97
OMA Lightweight M2M Overview(A new standard using lots of IETF specs including DTLS
CoAP Block Observe Resource Directory SenMLhellip)
Zach ShelbyCoRE WG IETF-86 Orlando
OMA Lightweight M2Mbull Open Mobile Alliance is well known for Device Management (DM)bull OMA Lightweight M2M is a new standard from the alliance
ndash Focused on constrained Cellular and sensor network M2M devicesndash Driven by leading operators and vendors
bull Scopendash Interfaces protocol amp security between Device and Serverndash Object and Resource modelndash Bootstrap Device Access Control Connectivity and Firmware Objects
bull Draft Specifications are availablendash httpmemberopenmobileallianceorgftpPublic_documentsDM
LightweightM2MPermanent_documentsOMA-TS-LightweightM2M-V1_0_0-20130301-Dzip
bull Timelinendash Requirements and Architecture completed 3Q2012ndash Spec ready for Consistency Review 2Q2013ndash Candidate Approval expected 3Q2013
2 CoRE WG IETF-86 Orlando
Architecture
3
Scope of LWM2M
CoRE WG IETF-86 Orlando
Object Model
bull A Client has one or more Object Instancesbull An Object is a collection of Resourcesbull A Resource is an atomic piece of information
ndash Read Written or Executed
bull Resources can have multiple instancesbull Objects and Resources are identified by a
16-bit Integer Instances by an 8-bit Integerbull ObjectsResources are accessed with
simple URIs Object IDObject InstanceResource ID
eg 1213
4 CoRE WG IETF-86 Orlando
CoRE WG IETF-86 Orlando
CoRE Resource Directory
draft-shelby-core-resource-directory-05
Z Shelby C Bormann S Krco
Backgroundbull Not a new concept
ndash think web search engine or any link directorybull Defines the interfaces to a Resource Directorybull Based on Web Linking framework and the CoRE Link Formatbull Generic REST design for use over HTTP and CoAPbull Used by OMA Lightweight M2Mbull Has already been deployed
ndash In traffic monitoring systemsndash In street lighting systemsndash For vehicular asset trackingndash By a major Cellular M2M operator
Changes since -04
bull Restricted Update to parameter updatesbull Added pagination support for the Lookup interfacebull Changed rt= to et= for the registration amp update
interfacebull Added group support
Group Management
bull RD now includes group management featuresbull New Group Function Set
ndash Register a groupbull Group name domain multicast address endpoint members
ndash Remove a groupbull Group lookup using the Lookup Function Set
ndash List registered groupsndash Find the members of a groupndash Find groups with certain endpoints or resources
Registering a Group
EP RD
| |
| - POST rd-groupgp=lights ltgtep=node1 --gt |
| |
| |
| lt---- 201 Created Location rd-group12 ---- |
| |
Req POST coaprdexamplecomrd-groupgp=lights
Payload
ltgtep=node1
ltgtep=node2
Res 201 Created
Location rd-group12
Looking up Group Members
Client RD
| |
| ----- GET rd-lookupepgp=lights1 ----------------------gt |
| |
| |
| lt-- 205 Content ltrdgtd=domain1ltrdgtd=domain2 --------- |
| |
Req GET rd-lookupepgp=lights1
Res 205 Content
ltcoaphostportgtep=node1
ltcoaphostportgtep=node2rdquo
Things for the futurebull Support for JSON representation of Web Links
ndash httptoolsietforgiddraft-bormann-core-links-json-02txtbull Registry for RD registration query parameters
ndash Already OMA Lightweight has defined some new onesbull More examples
Group 3 ldquonew workrdquo(continued)
109
drar-shy‐greevenbosch-shy‐core-shy‐profile-shy‐descripon-shy‐01Bert13 GreevenboschJeroen13 Hoebeke
Isam13 IshaqFloris13 Van13 den13 Abeele
Descripon
bull JSON13 format13 for13 signalling13 the13 servers13 capabilies
bull Signalling13 of13 supported13 opons13 media13 types13 and13 block13 sizendash Other13 items13 can13 be13 added
bull Filtering13 on13 specific13 fields13 through13 URI-shy‐Querybull Link13 hqpdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐profile-shy‐descripon
well-shy‐knownprofile
bull To13 acquire13 profile13 data13 of13 resources13 on13 a13 parcular13 service13 the13 well-shy‐knownprofile13 URI-shy‐path13 is13 introduced
bull For13 example13 to13 get13 all13 informaon13 from13 sensors13 served13 by13 wwwexampleorg13 we13 can13 do13 a13 GET13 to13 coapwwwexampleorgwell-shy‐knownprofile
bull Filtering13 on13 parcular13 resources13 is13 done13 through13 URI-shy‐Queries
Format
bull Currently13 the13 following13 fields13 are13 definedndash ldquopathrdquo13 contains13 the13 URI-shy‐path13 associated13 with13 a13 resource
ndash ldquooprdquo13 a13 numerical13 list13 of13 supported13 opon13 numbers
ndash ldquocfrdquo13 a13 numerical13 list13 of13 supported13 content-shy‐format13 numbers
ndash ldquob1srdquo13 ldquob2srdquo13 supported13 block13 sizes13 for13 Block113 and13 Block213 respecvely
Examplebull On13 the13 right13 is13 an13 example13 of13 a13 camera13 sensor13 at13 coapwwwexampleorgcam13 that13 supports13 the13 Uri-shy‐Host13 (3)13 ETag13 (4)13 Uri-shy‐Port13 (7)13 Uri-shy‐Path13 (11)13 Content-shy‐Format13 (12)13 Token13 (19)13 Block213 (23)13 and13 Proxy-shy‐Uri13 (35)13 opons
bull The13 supported13 content13 formats13 are13 textplain13 (0)13 applicaon13 link-shy‐format13 (40)13 and13 applicaonjson13 (50)
bull The13 supported13 Block213 can13 use13 25613 or13 51213 byte13 blocks
Req13 GET13 coapwwwexampleorgwell-shy‐knownprofile13 Res13 20513 Content13 (applicationjson)13 13 13 13 profile13 13 13 13 13 13 13 13 pathcam13 13 13 13 op[3471112192335]13 13 13 13 13 cf[04050]13 13 13 13 13 b2s[45]13 13 13 13
Filtering13 through13 use13 of13 URI-shy‐Query
bull Filtering13 can13 be13 done13 through13 the13 URI-shy‐Querybull Query13 format13 N=V
ndash N13 is13 a13 profile13 fieldndash V13 is13 the13 desired13 value
bull Examplesndash To13 find13 resources13 that13 support13 content13 format13 ldquoapplicaonjsonrdquo
13 GET13 wwwexampleorgwell-shy‐knownprofilecf=50ndash To13 get13 informaon13 about13 the13 camera
13 GET13 wwwexampleorgwell-shy‐knownprofilepath=cam
Open13 issues
bull Which13 other13 profile13 data13 needs13 signallingndash Content-shy‐type13 for13 different13 methods
bull Fix13 the13 order13 in13 which13 the13 profile13 fields13 must13 appearndash Non-shy‐fixed13 order13 easier13 extensible
bull Inheritance13 of13 a13 profile13 descriponbull Extend13 usage13 to13 signal13 the13 client13 profilebull Integraon13 with13 link13 format
Thank13 youQuesons
drar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval-shy‐00
Bert13 Greevenbosch
Descripon
bull The13 ldquoMinimumRequestInterval13 opon13 can13 be13 used13 to13 indicate13 the13 minimum13 me13 between13 two13 requests13 in13 a13 transacon
bull Originally13 intended13 for13 Block13 but13 also13 usable13 for13 other13 transaconsndash Example13 browsing13 a13 server
bull The13 goal13 is13 to13 reduce13 the13 server13 load13 and13 network13 traffic
bull Link13 hqpsdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval
Usage
bull The13 client13 keeps13 the13 server13 informed13 about13 its13 request13 speed13 through13 inclusion13 of13 the13 ldquoMinimumRequestIntervalrdquo13 opon
bull In13 responses13 the13 server13 fixes13 the13 minimum13 request13 interval13 through13 the13 same13 opon
bull The13 client13 obeys13 the13 speed13 indicated13 by13 the13 server
bull The13 client13 can13 send13 slower13 but13 not13 faster
Advantages
bull The13 server13 has13 means13 to13 limit13 the13 amount13 of13 incoming13 traffic
bull The13 server13 can13 prevent13 to13 become13 overloaded13 with13 too13 many13 tasks
bull The13 server13 does13 not13 need13 arficially13 slow13 down13 the13 client13 by13 sending13 late13 ACKsndash No13 need13 to13 keep13 track13 of13 delayed13 ACKsndash The13 server13 can13 perform13 other13 tasks13 instead
bull Reduced13 network13 traffic
Thank13 youQuesons
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-links-json-02txt
123
RFC 6690 (link-format) documents are somewhat foreign to many web app developerssect would prefer to have them in JSON format
There is no standard way to represent link-format documents in applicationssect but everyone knows how to handle JSON
Define a standard JSON translation for link-format
Itrsquos
not
rock
et
scien
ce
ltsensorsgtct=40title=Sensor Index ltsensorstempgtrt=temperature-cif=sensor ltsensorslightgtrt=light-luxif=sensor lthttpwwwexamplecomsensorst123gt anchor=sensorstemprel=describedby lttgtanchor=sensorstemprel=alternate [hrefsensorsct40titleSensor Index hrefsensorstemprttemperature-cifsensor hrefsensorslightrtlight-luxifsensor hrefhttpwwwexamplecomsensorst123 anchorsensorstempreldescribedby hreftanchorsensorstemprelalternate]
124
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-ipsec-for-coap-00txt
IPsec definitions for CoAP Mostly placeholder at this time Who has implementation experience with this
125
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-cross-reverse-convention-00txt
This draft has two lines of payload(based on a WGLC comment by Cullen Jennings)
coap12344567foobara=3
httpwwwproxycomwellknowncore-translate1234_4567foobara=3
Is that a useful convention to have
126
Insert CI slides here
127
128
0
5
10
15
20
25
30
35
40
10 20 30 40 50 60 70
good
put (
pps)
pps
Goodput vs pps (Econotags)
goodput
[Khattak preliminary]
Congestion Control
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-cocoa-00txt
ldquoadvancedrdquo cc (The draft is just a first shot) Others may have better ideas
129
Insert post-WGLC discussion slides here
130
Stop Continue Start
131
An Agile Retrospective
http6lowappnet coreIETF86 2013-03-12-13
Stop
132
Endless new CoAP optionssect instead use RESTful as much as possible
Move general security lifecycle out Looking at theoretical problems
http6lowappnet coreIETF86 2013-03-12-13
Continue
Interops Running code Look at real-world examples and deployments Solve their actual problems
sect Unilateral enhancements eg higher performance congestion control
sect Transports (SMS hellip)sect Make Web linking and Directories more and more usefulsect RESTful Design Paradigms for real-world problems
133
http6lowappnet coreIETF86 2013-03-12-13
Start
Further push into the (browser) web world (HTML5 browser security)
Specific supporting worksect SenMLsect URI work (dev URN hellip)sect Security Processes (next slide)
Spin outsect (We donrsquot really get to decide where this is done)
134
http6lowappnet coreIETF86 2013-03-12-13
Security
Integrate Application Network Group Keyingsect Tunnel-free setup
Donrsquot redo what has been done alreadysect ZigBee IP is finesect But what about other scenarios
Simple REST interfaces for working with keying materials and authorizationsect Start with defining objectives
Object Security for Constrained Nodes135
Re-chartering CoREWhat do we want to do now that wersquore grown up
Zach ShelbyCoRE WG IETF-86 Orlando
What is the scope
bull So we have a protocol and Web Linking what next
bull Keep with what we know besthellip1 Enhancements around CoAP2 New transports for CoAP3 New representations for Web Links4 General application layer solutions
CoRE WG IETF-86 Orlando 2
Enhancements around CoAP
bull Advanced congestion control
CoRE WG IETF-86 Orlando 3
New Transports for CoAP
bull Infrastructure for CoAP over foondash httptoolsietforgiddraft-silverajan-core-
coap-alternative-transports-01txtbull CoAP over SMS
ndash httptoolsietforgiddraft-becker-core-coap-sms-gprs-03txt
ndash OMA Lightweightbull CoAP over TCP
ndash httptoolsietforgiddraft-li-core-coap-payload-length-option-01txt
CoRE WG IETF-86 Orlando 4
New support for Web Links
bull JSON Web Linksndash httptoolsietforgiddraft-bormann-core-links-
json-02txt
2332010 CoRE WG IETF-77 Anaheim 5
General application layer solutions
bull Resource Directoryndash httptoolsietforgiddraft-shelby-core-
resource-directory-05txtndash OMA Lightweight
2332010 CoRE WG IETF-77 Anaheim 6
Experimental Network
1-5 clients
Both Sleepy and Non-
Sleepy servers
Sleepy Node Performance Analysis Network Setup
CoAPSleepyServer(s)
CoAPSleepAwareReverseProxy
CoAP
Client(s)
Request
Response
Sleep9AwareCoREResourceDirectoryCapability
PublishedSleepParameters
Sleep9AwareCoAPStoreandForwardCapability Response
Request
SleepAwareCoAP503ResponseCapability
CoAPCachingCapability
bull Server supports publishing sleep parameters to proxy bull Eg Irsquom going to be asleep for X seconds
bull Proxy supports sleep-awareness capabilities bull Proxy also supports caching capability based off of maxAge bull Protocol flow similar to approach of Figure 1 (Synchronous RD Based Sleep
Tracking) of I-D
Proxy capabilities can be selectively enableddisabled
Proxy ndash Server Interface
Client ndash Proxy Interface
CoAP Sleep-Aware Reverse Proxy Features CoRE Sleep-aware Resource Directory
Support storing published sleep parameters from CoAP servers sleepState (AWAKE ASLEEP) sleepDuration
Sleep-aware CoAP 503 Response Capability If CoAP request to a sleeping server is received proxy returns a
lsquo503 Retry-Afterrsquo response to client 503 contains a timestamp indicating when the sever will wake back up
(timestamp delivered in CoAP maxAge option) Sleep-aware CoAP Store-and-Forward Capability
If CoAP request to a sleeping server is received proxy stores request until server wakes up and then forwards it
Caching capability Cache GET responses from server if maxAge option is present
(this is not a sleep aware feature)
Goals of Performance Analysis
For networks having sleepy servers provide measurements to quantify the impact that CoAP sleep-awareness capabilities can have
See if sleep-awareness capabilities can
provide additional benefits even when CoAP caching is used
Overview of Performance Analysis Performed The analysis was broken up into a set of test scenarios Each test scenario used a different combination of the following
variables Client issued GET requests Server was configured as a sleepy or non-sleepy server Proxy caching of GET responses was enabled or disabled Proxy sleep-aware 503 response capability was enabled or disabled Proxy store-and-forward capability was enabled or disabled maxAge in GET responses ndash Two values were tested 60sec and 5sec of Clients ndash Two values were used ndash 1 client and 5 clients
For comparison purposes the following were held constant across all test scenarios Client issued a fixed number of requests (100) across all test scenarios Client used a delay between each GET request (35sec) to better exercise
proxyrsquos caching and sleep-awareness capabilities For sleepy server test scenarios the server slept 60 sec awake for 3 sec
Format of Results The following results were collected for each
test scenario
Breakdown of the and types of transactions occurring between clientproxyserver
ldquoGETrdquo ndash Test Scenario Results
GET ndash Description of Test Scenarios
TestScenarios-GET
Scenario
CoAPSleepyServerSe7ngs CoAPSleepAwareReverseProxySe7ngs CoAPClientSe7ngs
SleepDuragton(sec)
AwakeDuragton(sec)
maxAge(sec) Caching SleepAwareSAF+
503NumberofClients
NumberofGETs
DelayBetweenClient
Requests(sec)
1a 0 Always 60 Enabled Disabled 1 100 35
1b 60 3 60 Enabled Disabled 1 100 35
1c 60 3 60 Enabled Enabled 1 100 35
2a 0 Always 60 Enabled Disabled 5 100 35
2b 60 3 60 Enabled Disabled 5 100 35
2c 60 3 60 Enabled Enabled 5 100 35
3a 0 Always 5 Enabled Disabled 5 100 35
3b 60 3 5 Enabled Disabled 5 100 35
3c 60 3 5 Enabled Enabled 5 100 35
ldquoGETrdquo ndash Test Scenario 1 Results
maxAge = 60 and 1 Client
GET ndash Scenario 1 ClientProxy Interface Transaction Mix
Scenarios 1a - Non-Sleepy Server Caching Proxy maxAge = 60sec 1b- Sleepy Server Caching Proxy maxAge = 60sec 1c - Sleepy Server Sleep Aware Proxy maxAge = 60sec
Sleep Aware Proxy has better performance for sleepy servers
0
100
200
300
400
500
600
700
1a 1b 1c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
GET ndash Scenario 1 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
Scenarios 1a - Non-Sleepy Server Caching Proxy maxAge = 60sec 1b- Sleepy Server Caching Proxy maxAge = 60sec 1c - Sleepy Server Sleep Aware Proxy maxAge = 60sec
0
100
200
300
400
500
600
700
800
1a 1b 1c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
ldquoGETrdquo ndash Test Scenario 2 Results
maxAge = 60 and 5 Clients
GET ndash Scenario 2 ClientProxy Interface Transaction Mix
Sleep Aware Proxy has slightly better performance for sleepy servers
0
200
400
600
800
1000
1200
1400
2a 2b 2c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
Scenarios 2a - Non-Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2b- Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2c - Sleepy Server Sleep Aware Proxy maxAge = 60sec 5 Clients
See ldquoExperimental Artifactsrdquo Note 1
GET ndash Scenario 2 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has slightly better performance for sleepy servers
0
50
100
150
200
250
300
350
400
2a 2b 2c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
Scenarios 2a - Non-Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2b- Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2c - Sleepy Server Sleep Aware Proxy maxAge = 60sec 5 Clients
See ldquoExperimental Artifactsrdquo Note 2
Experimental Artifacts Note 1
Currently in the experiment the sleep aware proxy checks the cached state of a resource before putting a request into its Store-and-forward queue while a server is sleeping Once in the queue the proxy unconditionally forwards the queued requests to the server once it wakes up This is not the most efficient setup and can easily be improved If the proxy instead checks its cache again before forwarding each queued request it may not need to forward the request to the server For example if there are two queued GET requests in the proxyrsquos queue that address the same resource Only the first request needs to be sent to the server the second request can use the cached response from the first request
Note 2 Currently in the experiment the sleepy server sends a sleepState PUT request to the
proxy each time it goes to sleep This is not the most efficient setup and can easily be improved For example if the server assumes that the proxy can keep track of its ONOFF cycles with its internal timers (eg as per Fig 1 of I-D) then the number of messages from the sleepy server dramatically goes down
ldquoGETrdquo ndash Test Scenario 3 Results
maxAge = 5 and 5 Clients
GET ndash Scenario 3 ClientProxy Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
Scenarios 3a - Non-Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3b- Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3c - Sleepy Server Sleep Aware Proxy maxAge = 5sec 5 Clients
0
500
1000
1500
2000
2500
3000
3500
4000
4500
5000
3a 3b 3c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
GET ndash Scenario 3 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
0
1000
2000
3000
4000
5000
6000
7000
3a 3b 3c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
Scenarios 3a - Non-Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3b- Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3c - Sleepy Server Sleep Aware Proxy maxAge = 5sec 5 Clients
Conclusions
Conclusions These results show that sleep-aware CoAP
proxy features can significantly optimize communication with sleepy servers in most scenarios
These results also show that sleep-
awareness capabilities can provide additional benefits above and beyond CoAP caching in most scenarios
Backup
Current CoAP Support of Sleepy Node (12)
CoAP proxies can use a previously cached response to service a new GET request for a sleepy origin server (as in HTTP) But if no valid cache then proxy has to attempt to
retrieve and may fail if origin server is sleeping [I-Dietf-core-coap]
Clients can discover list of resources from RD (GET rd-lookuphellip) for sleepy servers But attempt to GET resource from sleepy origin server
may fail if origin server is sleeping [IDietf-core-link-format amp IDshelby-core-resource-
directory]
Current CoAP Support of Sleepy Node (22)
Lower layer support for sleepy nodes in most wireless technologies (eg WiFi ZigBee) But limited to MAC packet scheduling for sleepy nodes
and not aware of specific needs of IP applications (like CoAP)
Proposal ndash RD Based Sleep Tracking (14)
The current CoAP approach to support sleepy nodes can be significantly improved by introducing RD based mechanisms for a CoAP client to determine whether A targeted resource is located on a sleepy server A sleepy server is currently in sleep mode or not
There is any associated caching Proxy (possibly the RD itself) for a sleepy server
Proposal ndash RD Based Sleep Tracking (24)
We define the following new RD attributes to characterize the properties of a sleepy node SleepState - Indicates whether the node is currently in
sleep mode or not (ie Sleeping or Awake) SleepDuration - Indicates the maximum duration of time
that the node stays in sleep mode TimeSleeping - Indicates the length of time the node
has been sleeping (ie if Sleep State = Sleeping) NextSleep - Indicates the next time the node will go to
sleep (ie if Sleep State = Awake)
CachingProxy ndash Indicates the caching proxy of the sleepy node (ie the RD itself or another node)
Proposal ndash RD Based Sleep Tracking (34)
These attributes are all server (node) level and are new parameters added to the RD URI Template Variables
Finally we also define a new lookup-type (ss) for the RD lookup interface specified in [I-Dshelby-core-resource-directory] This new lookup-type supports looking up the
ldquoSleepStaterdquo (ss) of a specified end-point
Proposal ndash RD Based Sleep Tracking (44)
The three time based parameters (SleepDuration TimeSleeping NextSleep) can be based on either an absolute network time (for a time synchronized network) or a relative local time (measured at the local node)
Following the approach of [I-Dietf-core-link-format] and [I-Dshelby-core-resource-directory] sleep parameters for sleepy servers can be stored by the server in the RD and accessed by all interested clients
Examples of using these parameters in a synchronous or asynchronous manner are shown in the I-D
http6lowappnet coreIETF86 2013-03-12-13
We assume people have read the drafts
Meetings serve to advance difficult issues by making good use of face-to-face communications
Note Well Be aware of the IPR principles according to RFC 3979 and its updates
uumlBlue sheetsuumlScribe(s)
96
drar-shy‐iep-shy‐core-shy‐coapsubmiqed13 to13 IESG
2013-shy‐03-shy‐13
97
OMA Lightweight M2M Overview(A new standard using lots of IETF specs including DTLS
CoAP Block Observe Resource Directory SenMLhellip)
Zach ShelbyCoRE WG IETF-86 Orlando
OMA Lightweight M2Mbull Open Mobile Alliance is well known for Device Management (DM)bull OMA Lightweight M2M is a new standard from the alliance
ndash Focused on constrained Cellular and sensor network M2M devicesndash Driven by leading operators and vendors
bull Scopendash Interfaces protocol amp security between Device and Serverndash Object and Resource modelndash Bootstrap Device Access Control Connectivity and Firmware Objects
bull Draft Specifications are availablendash httpmemberopenmobileallianceorgftpPublic_documentsDM
LightweightM2MPermanent_documentsOMA-TS-LightweightM2M-V1_0_0-20130301-Dzip
bull Timelinendash Requirements and Architecture completed 3Q2012ndash Spec ready for Consistency Review 2Q2013ndash Candidate Approval expected 3Q2013
2 CoRE WG IETF-86 Orlando
Architecture
3
Scope of LWM2M
CoRE WG IETF-86 Orlando
Object Model
bull A Client has one or more Object Instancesbull An Object is a collection of Resourcesbull A Resource is an atomic piece of information
ndash Read Written or Executed
bull Resources can have multiple instancesbull Objects and Resources are identified by a
16-bit Integer Instances by an 8-bit Integerbull ObjectsResources are accessed with
simple URIs Object IDObject InstanceResource ID
eg 1213
4 CoRE WG IETF-86 Orlando
CoRE WG IETF-86 Orlando
CoRE Resource Directory
draft-shelby-core-resource-directory-05
Z Shelby C Bormann S Krco
Backgroundbull Not a new concept
ndash think web search engine or any link directorybull Defines the interfaces to a Resource Directorybull Based on Web Linking framework and the CoRE Link Formatbull Generic REST design for use over HTTP and CoAPbull Used by OMA Lightweight M2Mbull Has already been deployed
ndash In traffic monitoring systemsndash In street lighting systemsndash For vehicular asset trackingndash By a major Cellular M2M operator
Changes since -04
bull Restricted Update to parameter updatesbull Added pagination support for the Lookup interfacebull Changed rt= to et= for the registration amp update
interfacebull Added group support
Group Management
bull RD now includes group management featuresbull New Group Function Set
ndash Register a groupbull Group name domain multicast address endpoint members
ndash Remove a groupbull Group lookup using the Lookup Function Set
ndash List registered groupsndash Find the members of a groupndash Find groups with certain endpoints or resources
Registering a Group
EP RD
| |
| - POST rd-groupgp=lights ltgtep=node1 --gt |
| |
| |
| lt---- 201 Created Location rd-group12 ---- |
| |
Req POST coaprdexamplecomrd-groupgp=lights
Payload
ltgtep=node1
ltgtep=node2
Res 201 Created
Location rd-group12
Looking up Group Members
Client RD
| |
| ----- GET rd-lookupepgp=lights1 ----------------------gt |
| |
| |
| lt-- 205 Content ltrdgtd=domain1ltrdgtd=domain2 --------- |
| |
Req GET rd-lookupepgp=lights1
Res 205 Content
ltcoaphostportgtep=node1
ltcoaphostportgtep=node2rdquo
Things for the futurebull Support for JSON representation of Web Links
ndash httptoolsietforgiddraft-bormann-core-links-json-02txtbull Registry for RD registration query parameters
ndash Already OMA Lightweight has defined some new onesbull More examples
Group 3 ldquonew workrdquo(continued)
109
drar-shy‐greevenbosch-shy‐core-shy‐profile-shy‐descripon-shy‐01Bert13 GreevenboschJeroen13 Hoebeke
Isam13 IshaqFloris13 Van13 den13 Abeele
Descripon
bull JSON13 format13 for13 signalling13 the13 servers13 capabilies
bull Signalling13 of13 supported13 opons13 media13 types13 and13 block13 sizendash Other13 items13 can13 be13 added
bull Filtering13 on13 specific13 fields13 through13 URI-shy‐Querybull Link13 hqpdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐profile-shy‐descripon
well-shy‐knownprofile
bull To13 acquire13 profile13 data13 of13 resources13 on13 a13 parcular13 service13 the13 well-shy‐knownprofile13 URI-shy‐path13 is13 introduced
bull For13 example13 to13 get13 all13 informaon13 from13 sensors13 served13 by13 wwwexampleorg13 we13 can13 do13 a13 GET13 to13 coapwwwexampleorgwell-shy‐knownprofile
bull Filtering13 on13 parcular13 resources13 is13 done13 through13 URI-shy‐Queries
Format
bull Currently13 the13 following13 fields13 are13 definedndash ldquopathrdquo13 contains13 the13 URI-shy‐path13 associated13 with13 a13 resource
ndash ldquooprdquo13 a13 numerical13 list13 of13 supported13 opon13 numbers
ndash ldquocfrdquo13 a13 numerical13 list13 of13 supported13 content-shy‐format13 numbers
ndash ldquob1srdquo13 ldquob2srdquo13 supported13 block13 sizes13 for13 Block113 and13 Block213 respecvely
Examplebull On13 the13 right13 is13 an13 example13 of13 a13 camera13 sensor13 at13 coapwwwexampleorgcam13 that13 supports13 the13 Uri-shy‐Host13 (3)13 ETag13 (4)13 Uri-shy‐Port13 (7)13 Uri-shy‐Path13 (11)13 Content-shy‐Format13 (12)13 Token13 (19)13 Block213 (23)13 and13 Proxy-shy‐Uri13 (35)13 opons
bull The13 supported13 content13 formats13 are13 textplain13 (0)13 applicaon13 link-shy‐format13 (40)13 and13 applicaonjson13 (50)
bull The13 supported13 Block213 can13 use13 25613 or13 51213 byte13 blocks
Req13 GET13 coapwwwexampleorgwell-shy‐knownprofile13 Res13 20513 Content13 (applicationjson)13 13 13 13 profile13 13 13 13 13 13 13 13 pathcam13 13 13 13 op[3471112192335]13 13 13 13 13 cf[04050]13 13 13 13 13 b2s[45]13 13 13 13
Filtering13 through13 use13 of13 URI-shy‐Query
bull Filtering13 can13 be13 done13 through13 the13 URI-shy‐Querybull Query13 format13 N=V
ndash N13 is13 a13 profile13 fieldndash V13 is13 the13 desired13 value
bull Examplesndash To13 find13 resources13 that13 support13 content13 format13 ldquoapplicaonjsonrdquo
13 GET13 wwwexampleorgwell-shy‐knownprofilecf=50ndash To13 get13 informaon13 about13 the13 camera
13 GET13 wwwexampleorgwell-shy‐knownprofilepath=cam
Open13 issues
bull Which13 other13 profile13 data13 needs13 signallingndash Content-shy‐type13 for13 different13 methods
bull Fix13 the13 order13 in13 which13 the13 profile13 fields13 must13 appearndash Non-shy‐fixed13 order13 easier13 extensible
bull Inheritance13 of13 a13 profile13 descriponbull Extend13 usage13 to13 signal13 the13 client13 profilebull Integraon13 with13 link13 format
Thank13 youQuesons
drar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval-shy‐00
Bert13 Greevenbosch
Descripon
bull The13 ldquoMinimumRequestInterval13 opon13 can13 be13 used13 to13 indicate13 the13 minimum13 me13 between13 two13 requests13 in13 a13 transacon
bull Originally13 intended13 for13 Block13 but13 also13 usable13 for13 other13 transaconsndash Example13 browsing13 a13 server
bull The13 goal13 is13 to13 reduce13 the13 server13 load13 and13 network13 traffic
bull Link13 hqpsdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval
Usage
bull The13 client13 keeps13 the13 server13 informed13 about13 its13 request13 speed13 through13 inclusion13 of13 the13 ldquoMinimumRequestIntervalrdquo13 opon
bull In13 responses13 the13 server13 fixes13 the13 minimum13 request13 interval13 through13 the13 same13 opon
bull The13 client13 obeys13 the13 speed13 indicated13 by13 the13 server
bull The13 client13 can13 send13 slower13 but13 not13 faster
Advantages
bull The13 server13 has13 means13 to13 limit13 the13 amount13 of13 incoming13 traffic
bull The13 server13 can13 prevent13 to13 become13 overloaded13 with13 too13 many13 tasks
bull The13 server13 does13 not13 need13 arficially13 slow13 down13 the13 client13 by13 sending13 late13 ACKsndash No13 need13 to13 keep13 track13 of13 delayed13 ACKsndash The13 server13 can13 perform13 other13 tasks13 instead
bull Reduced13 network13 traffic
Thank13 youQuesons
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-links-json-02txt
123
RFC 6690 (link-format) documents are somewhat foreign to many web app developerssect would prefer to have them in JSON format
There is no standard way to represent link-format documents in applicationssect but everyone knows how to handle JSON
Define a standard JSON translation for link-format
Itrsquos
not
rock
et
scien
ce
ltsensorsgtct=40title=Sensor Index ltsensorstempgtrt=temperature-cif=sensor ltsensorslightgtrt=light-luxif=sensor lthttpwwwexamplecomsensorst123gt anchor=sensorstemprel=describedby lttgtanchor=sensorstemprel=alternate [hrefsensorsct40titleSensor Index hrefsensorstemprttemperature-cifsensor hrefsensorslightrtlight-luxifsensor hrefhttpwwwexamplecomsensorst123 anchorsensorstempreldescribedby hreftanchorsensorstemprelalternate]
124
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-ipsec-for-coap-00txt
IPsec definitions for CoAP Mostly placeholder at this time Who has implementation experience with this
125
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-cross-reverse-convention-00txt
This draft has two lines of payload(based on a WGLC comment by Cullen Jennings)
coap12344567foobara=3
httpwwwproxycomwellknowncore-translate1234_4567foobara=3
Is that a useful convention to have
126
Insert CI slides here
127
128
0
5
10
15
20
25
30
35
40
10 20 30 40 50 60 70
good
put (
pps)
pps
Goodput vs pps (Econotags)
goodput
[Khattak preliminary]
Congestion Control
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-cocoa-00txt
ldquoadvancedrdquo cc (The draft is just a first shot) Others may have better ideas
129
Insert post-WGLC discussion slides here
130
Stop Continue Start
131
An Agile Retrospective
http6lowappnet coreIETF86 2013-03-12-13
Stop
132
Endless new CoAP optionssect instead use RESTful as much as possible
Move general security lifecycle out Looking at theoretical problems
http6lowappnet coreIETF86 2013-03-12-13
Continue
Interops Running code Look at real-world examples and deployments Solve their actual problems
sect Unilateral enhancements eg higher performance congestion control
sect Transports (SMS hellip)sect Make Web linking and Directories more and more usefulsect RESTful Design Paradigms for real-world problems
133
http6lowappnet coreIETF86 2013-03-12-13
Start
Further push into the (browser) web world (HTML5 browser security)
Specific supporting worksect SenMLsect URI work (dev URN hellip)sect Security Processes (next slide)
Spin outsect (We donrsquot really get to decide where this is done)
134
http6lowappnet coreIETF86 2013-03-12-13
Security
Integrate Application Network Group Keyingsect Tunnel-free setup
Donrsquot redo what has been done alreadysect ZigBee IP is finesect But what about other scenarios
Simple REST interfaces for working with keying materials and authorizationsect Start with defining objectives
Object Security for Constrained Nodes135
Re-chartering CoREWhat do we want to do now that wersquore grown up
Zach ShelbyCoRE WG IETF-86 Orlando
What is the scope
bull So we have a protocol and Web Linking what next
bull Keep with what we know besthellip1 Enhancements around CoAP2 New transports for CoAP3 New representations for Web Links4 General application layer solutions
CoRE WG IETF-86 Orlando 2
Enhancements around CoAP
bull Advanced congestion control
CoRE WG IETF-86 Orlando 3
New Transports for CoAP
bull Infrastructure for CoAP over foondash httptoolsietforgiddraft-silverajan-core-
coap-alternative-transports-01txtbull CoAP over SMS
ndash httptoolsietforgiddraft-becker-core-coap-sms-gprs-03txt
ndash OMA Lightweightbull CoAP over TCP
ndash httptoolsietforgiddraft-li-core-coap-payload-length-option-01txt
CoRE WG IETF-86 Orlando 4
New support for Web Links
bull JSON Web Linksndash httptoolsietforgiddraft-bormann-core-links-
json-02txt
2332010 CoRE WG IETF-77 Anaheim 5
General application layer solutions
bull Resource Directoryndash httptoolsietforgiddraft-shelby-core-
resource-directory-05txtndash OMA Lightweight
2332010 CoRE WG IETF-77 Anaheim 6
Sleepy Node Performance Analysis Network Setup
CoAPSleepyServer(s)
CoAPSleepAwareReverseProxy
CoAP
Client(s)
Request
Response
Sleep9AwareCoREResourceDirectoryCapability
PublishedSleepParameters
Sleep9AwareCoAPStoreandForwardCapability Response
Request
SleepAwareCoAP503ResponseCapability
CoAPCachingCapability
bull Server supports publishing sleep parameters to proxy bull Eg Irsquom going to be asleep for X seconds
bull Proxy supports sleep-awareness capabilities bull Proxy also supports caching capability based off of maxAge bull Protocol flow similar to approach of Figure 1 (Synchronous RD Based Sleep
Tracking) of I-D
Proxy capabilities can be selectively enableddisabled
Proxy ndash Server Interface
Client ndash Proxy Interface
CoAP Sleep-Aware Reverse Proxy Features CoRE Sleep-aware Resource Directory
Support storing published sleep parameters from CoAP servers sleepState (AWAKE ASLEEP) sleepDuration
Sleep-aware CoAP 503 Response Capability If CoAP request to a sleeping server is received proxy returns a
lsquo503 Retry-Afterrsquo response to client 503 contains a timestamp indicating when the sever will wake back up
(timestamp delivered in CoAP maxAge option) Sleep-aware CoAP Store-and-Forward Capability
If CoAP request to a sleeping server is received proxy stores request until server wakes up and then forwards it
Caching capability Cache GET responses from server if maxAge option is present
(this is not a sleep aware feature)
Goals of Performance Analysis
For networks having sleepy servers provide measurements to quantify the impact that CoAP sleep-awareness capabilities can have
See if sleep-awareness capabilities can
provide additional benefits even when CoAP caching is used
Overview of Performance Analysis Performed The analysis was broken up into a set of test scenarios Each test scenario used a different combination of the following
variables Client issued GET requests Server was configured as a sleepy or non-sleepy server Proxy caching of GET responses was enabled or disabled Proxy sleep-aware 503 response capability was enabled or disabled Proxy store-and-forward capability was enabled or disabled maxAge in GET responses ndash Two values were tested 60sec and 5sec of Clients ndash Two values were used ndash 1 client and 5 clients
For comparison purposes the following were held constant across all test scenarios Client issued a fixed number of requests (100) across all test scenarios Client used a delay between each GET request (35sec) to better exercise
proxyrsquos caching and sleep-awareness capabilities For sleepy server test scenarios the server slept 60 sec awake for 3 sec
Format of Results The following results were collected for each
test scenario
Breakdown of the and types of transactions occurring between clientproxyserver
ldquoGETrdquo ndash Test Scenario Results
GET ndash Description of Test Scenarios
TestScenarios-GET
Scenario
CoAPSleepyServerSe7ngs CoAPSleepAwareReverseProxySe7ngs CoAPClientSe7ngs
SleepDuragton(sec)
AwakeDuragton(sec)
maxAge(sec) Caching SleepAwareSAF+
503NumberofClients
NumberofGETs
DelayBetweenClient
Requests(sec)
1a 0 Always 60 Enabled Disabled 1 100 35
1b 60 3 60 Enabled Disabled 1 100 35
1c 60 3 60 Enabled Enabled 1 100 35
2a 0 Always 60 Enabled Disabled 5 100 35
2b 60 3 60 Enabled Disabled 5 100 35
2c 60 3 60 Enabled Enabled 5 100 35
3a 0 Always 5 Enabled Disabled 5 100 35
3b 60 3 5 Enabled Disabled 5 100 35
3c 60 3 5 Enabled Enabled 5 100 35
ldquoGETrdquo ndash Test Scenario 1 Results
maxAge = 60 and 1 Client
GET ndash Scenario 1 ClientProxy Interface Transaction Mix
Scenarios 1a - Non-Sleepy Server Caching Proxy maxAge = 60sec 1b- Sleepy Server Caching Proxy maxAge = 60sec 1c - Sleepy Server Sleep Aware Proxy maxAge = 60sec
Sleep Aware Proxy has better performance for sleepy servers
0
100
200
300
400
500
600
700
1a 1b 1c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
GET ndash Scenario 1 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
Scenarios 1a - Non-Sleepy Server Caching Proxy maxAge = 60sec 1b- Sleepy Server Caching Proxy maxAge = 60sec 1c - Sleepy Server Sleep Aware Proxy maxAge = 60sec
0
100
200
300
400
500
600
700
800
1a 1b 1c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
ldquoGETrdquo ndash Test Scenario 2 Results
maxAge = 60 and 5 Clients
GET ndash Scenario 2 ClientProxy Interface Transaction Mix
Sleep Aware Proxy has slightly better performance for sleepy servers
0
200
400
600
800
1000
1200
1400
2a 2b 2c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
Scenarios 2a - Non-Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2b- Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2c - Sleepy Server Sleep Aware Proxy maxAge = 60sec 5 Clients
See ldquoExperimental Artifactsrdquo Note 1
GET ndash Scenario 2 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has slightly better performance for sleepy servers
0
50
100
150
200
250
300
350
400
2a 2b 2c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
Scenarios 2a - Non-Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2b- Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2c - Sleepy Server Sleep Aware Proxy maxAge = 60sec 5 Clients
See ldquoExperimental Artifactsrdquo Note 2
Experimental Artifacts Note 1
Currently in the experiment the sleep aware proxy checks the cached state of a resource before putting a request into its Store-and-forward queue while a server is sleeping Once in the queue the proxy unconditionally forwards the queued requests to the server once it wakes up This is not the most efficient setup and can easily be improved If the proxy instead checks its cache again before forwarding each queued request it may not need to forward the request to the server For example if there are two queued GET requests in the proxyrsquos queue that address the same resource Only the first request needs to be sent to the server the second request can use the cached response from the first request
Note 2 Currently in the experiment the sleepy server sends a sleepState PUT request to the
proxy each time it goes to sleep This is not the most efficient setup and can easily be improved For example if the server assumes that the proxy can keep track of its ONOFF cycles with its internal timers (eg as per Fig 1 of I-D) then the number of messages from the sleepy server dramatically goes down
ldquoGETrdquo ndash Test Scenario 3 Results
maxAge = 5 and 5 Clients
GET ndash Scenario 3 ClientProxy Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
Scenarios 3a - Non-Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3b- Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3c - Sleepy Server Sleep Aware Proxy maxAge = 5sec 5 Clients
0
500
1000
1500
2000
2500
3000
3500
4000
4500
5000
3a 3b 3c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
GET ndash Scenario 3 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
0
1000
2000
3000
4000
5000
6000
7000
3a 3b 3c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
Scenarios 3a - Non-Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3b- Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3c - Sleepy Server Sleep Aware Proxy maxAge = 5sec 5 Clients
Conclusions
Conclusions These results show that sleep-aware CoAP
proxy features can significantly optimize communication with sleepy servers in most scenarios
These results also show that sleep-
awareness capabilities can provide additional benefits above and beyond CoAP caching in most scenarios
Backup
Current CoAP Support of Sleepy Node (12)
CoAP proxies can use a previously cached response to service a new GET request for a sleepy origin server (as in HTTP) But if no valid cache then proxy has to attempt to
retrieve and may fail if origin server is sleeping [I-Dietf-core-coap]
Clients can discover list of resources from RD (GET rd-lookuphellip) for sleepy servers But attempt to GET resource from sleepy origin server
may fail if origin server is sleeping [IDietf-core-link-format amp IDshelby-core-resource-
directory]
Current CoAP Support of Sleepy Node (22)
Lower layer support for sleepy nodes in most wireless technologies (eg WiFi ZigBee) But limited to MAC packet scheduling for sleepy nodes
and not aware of specific needs of IP applications (like CoAP)
Proposal ndash RD Based Sleep Tracking (14)
The current CoAP approach to support sleepy nodes can be significantly improved by introducing RD based mechanisms for a CoAP client to determine whether A targeted resource is located on a sleepy server A sleepy server is currently in sleep mode or not
There is any associated caching Proxy (possibly the RD itself) for a sleepy server
Proposal ndash RD Based Sleep Tracking (24)
We define the following new RD attributes to characterize the properties of a sleepy node SleepState - Indicates whether the node is currently in
sleep mode or not (ie Sleeping or Awake) SleepDuration - Indicates the maximum duration of time
that the node stays in sleep mode TimeSleeping - Indicates the length of time the node
has been sleeping (ie if Sleep State = Sleeping) NextSleep - Indicates the next time the node will go to
sleep (ie if Sleep State = Awake)
CachingProxy ndash Indicates the caching proxy of the sleepy node (ie the RD itself or another node)
Proposal ndash RD Based Sleep Tracking (34)
These attributes are all server (node) level and are new parameters added to the RD URI Template Variables
Finally we also define a new lookup-type (ss) for the RD lookup interface specified in [I-Dshelby-core-resource-directory] This new lookup-type supports looking up the
ldquoSleepStaterdquo (ss) of a specified end-point
Proposal ndash RD Based Sleep Tracking (44)
The three time based parameters (SleepDuration TimeSleeping NextSleep) can be based on either an absolute network time (for a time synchronized network) or a relative local time (measured at the local node)
Following the approach of [I-Dietf-core-link-format] and [I-Dshelby-core-resource-directory] sleep parameters for sleepy servers can be stored by the server in the RD and accessed by all interested clients
Examples of using these parameters in a synchronous or asynchronous manner are shown in the I-D
http6lowappnet coreIETF86 2013-03-12-13
We assume people have read the drafts
Meetings serve to advance difficult issues by making good use of face-to-face communications
Note Well Be aware of the IPR principles according to RFC 3979 and its updates
uumlBlue sheetsuumlScribe(s)
96
drar-shy‐iep-shy‐core-shy‐coapsubmiqed13 to13 IESG
2013-shy‐03-shy‐13
97
OMA Lightweight M2M Overview(A new standard using lots of IETF specs including DTLS
CoAP Block Observe Resource Directory SenMLhellip)
Zach ShelbyCoRE WG IETF-86 Orlando
OMA Lightweight M2Mbull Open Mobile Alliance is well known for Device Management (DM)bull OMA Lightweight M2M is a new standard from the alliance
ndash Focused on constrained Cellular and sensor network M2M devicesndash Driven by leading operators and vendors
bull Scopendash Interfaces protocol amp security between Device and Serverndash Object and Resource modelndash Bootstrap Device Access Control Connectivity and Firmware Objects
bull Draft Specifications are availablendash httpmemberopenmobileallianceorgftpPublic_documentsDM
LightweightM2MPermanent_documentsOMA-TS-LightweightM2M-V1_0_0-20130301-Dzip
bull Timelinendash Requirements and Architecture completed 3Q2012ndash Spec ready for Consistency Review 2Q2013ndash Candidate Approval expected 3Q2013
2 CoRE WG IETF-86 Orlando
Architecture
3
Scope of LWM2M
CoRE WG IETF-86 Orlando
Object Model
bull A Client has one or more Object Instancesbull An Object is a collection of Resourcesbull A Resource is an atomic piece of information
ndash Read Written or Executed
bull Resources can have multiple instancesbull Objects and Resources are identified by a
16-bit Integer Instances by an 8-bit Integerbull ObjectsResources are accessed with
simple URIs Object IDObject InstanceResource ID
eg 1213
4 CoRE WG IETF-86 Orlando
CoRE WG IETF-86 Orlando
CoRE Resource Directory
draft-shelby-core-resource-directory-05
Z Shelby C Bormann S Krco
Backgroundbull Not a new concept
ndash think web search engine or any link directorybull Defines the interfaces to a Resource Directorybull Based on Web Linking framework and the CoRE Link Formatbull Generic REST design for use over HTTP and CoAPbull Used by OMA Lightweight M2Mbull Has already been deployed
ndash In traffic monitoring systemsndash In street lighting systemsndash For vehicular asset trackingndash By a major Cellular M2M operator
Changes since -04
bull Restricted Update to parameter updatesbull Added pagination support for the Lookup interfacebull Changed rt= to et= for the registration amp update
interfacebull Added group support
Group Management
bull RD now includes group management featuresbull New Group Function Set
ndash Register a groupbull Group name domain multicast address endpoint members
ndash Remove a groupbull Group lookup using the Lookup Function Set
ndash List registered groupsndash Find the members of a groupndash Find groups with certain endpoints or resources
Registering a Group
EP RD
| |
| - POST rd-groupgp=lights ltgtep=node1 --gt |
| |
| |
| lt---- 201 Created Location rd-group12 ---- |
| |
Req POST coaprdexamplecomrd-groupgp=lights
Payload
ltgtep=node1
ltgtep=node2
Res 201 Created
Location rd-group12
Looking up Group Members
Client RD
| |
| ----- GET rd-lookupepgp=lights1 ----------------------gt |
| |
| |
| lt-- 205 Content ltrdgtd=domain1ltrdgtd=domain2 --------- |
| |
Req GET rd-lookupepgp=lights1
Res 205 Content
ltcoaphostportgtep=node1
ltcoaphostportgtep=node2rdquo
Things for the futurebull Support for JSON representation of Web Links
ndash httptoolsietforgiddraft-bormann-core-links-json-02txtbull Registry for RD registration query parameters
ndash Already OMA Lightweight has defined some new onesbull More examples
Group 3 ldquonew workrdquo(continued)
109
drar-shy‐greevenbosch-shy‐core-shy‐profile-shy‐descripon-shy‐01Bert13 GreevenboschJeroen13 Hoebeke
Isam13 IshaqFloris13 Van13 den13 Abeele
Descripon
bull JSON13 format13 for13 signalling13 the13 servers13 capabilies
bull Signalling13 of13 supported13 opons13 media13 types13 and13 block13 sizendash Other13 items13 can13 be13 added
bull Filtering13 on13 specific13 fields13 through13 URI-shy‐Querybull Link13 hqpdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐profile-shy‐descripon
well-shy‐knownprofile
bull To13 acquire13 profile13 data13 of13 resources13 on13 a13 parcular13 service13 the13 well-shy‐knownprofile13 URI-shy‐path13 is13 introduced
bull For13 example13 to13 get13 all13 informaon13 from13 sensors13 served13 by13 wwwexampleorg13 we13 can13 do13 a13 GET13 to13 coapwwwexampleorgwell-shy‐knownprofile
bull Filtering13 on13 parcular13 resources13 is13 done13 through13 URI-shy‐Queries
Format
bull Currently13 the13 following13 fields13 are13 definedndash ldquopathrdquo13 contains13 the13 URI-shy‐path13 associated13 with13 a13 resource
ndash ldquooprdquo13 a13 numerical13 list13 of13 supported13 opon13 numbers
ndash ldquocfrdquo13 a13 numerical13 list13 of13 supported13 content-shy‐format13 numbers
ndash ldquob1srdquo13 ldquob2srdquo13 supported13 block13 sizes13 for13 Block113 and13 Block213 respecvely
Examplebull On13 the13 right13 is13 an13 example13 of13 a13 camera13 sensor13 at13 coapwwwexampleorgcam13 that13 supports13 the13 Uri-shy‐Host13 (3)13 ETag13 (4)13 Uri-shy‐Port13 (7)13 Uri-shy‐Path13 (11)13 Content-shy‐Format13 (12)13 Token13 (19)13 Block213 (23)13 and13 Proxy-shy‐Uri13 (35)13 opons
bull The13 supported13 content13 formats13 are13 textplain13 (0)13 applicaon13 link-shy‐format13 (40)13 and13 applicaonjson13 (50)
bull The13 supported13 Block213 can13 use13 25613 or13 51213 byte13 blocks
Req13 GET13 coapwwwexampleorgwell-shy‐knownprofile13 Res13 20513 Content13 (applicationjson)13 13 13 13 profile13 13 13 13 13 13 13 13 pathcam13 13 13 13 op[3471112192335]13 13 13 13 13 cf[04050]13 13 13 13 13 b2s[45]13 13 13 13
Filtering13 through13 use13 of13 URI-shy‐Query
bull Filtering13 can13 be13 done13 through13 the13 URI-shy‐Querybull Query13 format13 N=V
ndash N13 is13 a13 profile13 fieldndash V13 is13 the13 desired13 value
bull Examplesndash To13 find13 resources13 that13 support13 content13 format13 ldquoapplicaonjsonrdquo
13 GET13 wwwexampleorgwell-shy‐knownprofilecf=50ndash To13 get13 informaon13 about13 the13 camera
13 GET13 wwwexampleorgwell-shy‐knownprofilepath=cam
Open13 issues
bull Which13 other13 profile13 data13 needs13 signallingndash Content-shy‐type13 for13 different13 methods
bull Fix13 the13 order13 in13 which13 the13 profile13 fields13 must13 appearndash Non-shy‐fixed13 order13 easier13 extensible
bull Inheritance13 of13 a13 profile13 descriponbull Extend13 usage13 to13 signal13 the13 client13 profilebull Integraon13 with13 link13 format
Thank13 youQuesons
drar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval-shy‐00
Bert13 Greevenbosch
Descripon
bull The13 ldquoMinimumRequestInterval13 opon13 can13 be13 used13 to13 indicate13 the13 minimum13 me13 between13 two13 requests13 in13 a13 transacon
bull Originally13 intended13 for13 Block13 but13 also13 usable13 for13 other13 transaconsndash Example13 browsing13 a13 server
bull The13 goal13 is13 to13 reduce13 the13 server13 load13 and13 network13 traffic
bull Link13 hqpsdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval
Usage
bull The13 client13 keeps13 the13 server13 informed13 about13 its13 request13 speed13 through13 inclusion13 of13 the13 ldquoMinimumRequestIntervalrdquo13 opon
bull In13 responses13 the13 server13 fixes13 the13 minimum13 request13 interval13 through13 the13 same13 opon
bull The13 client13 obeys13 the13 speed13 indicated13 by13 the13 server
bull The13 client13 can13 send13 slower13 but13 not13 faster
Advantages
bull The13 server13 has13 means13 to13 limit13 the13 amount13 of13 incoming13 traffic
bull The13 server13 can13 prevent13 to13 become13 overloaded13 with13 too13 many13 tasks
bull The13 server13 does13 not13 need13 arficially13 slow13 down13 the13 client13 by13 sending13 late13 ACKsndash No13 need13 to13 keep13 track13 of13 delayed13 ACKsndash The13 server13 can13 perform13 other13 tasks13 instead
bull Reduced13 network13 traffic
Thank13 youQuesons
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-links-json-02txt
123
RFC 6690 (link-format) documents are somewhat foreign to many web app developerssect would prefer to have them in JSON format
There is no standard way to represent link-format documents in applicationssect but everyone knows how to handle JSON
Define a standard JSON translation for link-format
Itrsquos
not
rock
et
scien
ce
ltsensorsgtct=40title=Sensor Index ltsensorstempgtrt=temperature-cif=sensor ltsensorslightgtrt=light-luxif=sensor lthttpwwwexamplecomsensorst123gt anchor=sensorstemprel=describedby lttgtanchor=sensorstemprel=alternate [hrefsensorsct40titleSensor Index hrefsensorstemprttemperature-cifsensor hrefsensorslightrtlight-luxifsensor hrefhttpwwwexamplecomsensorst123 anchorsensorstempreldescribedby hreftanchorsensorstemprelalternate]
124
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-ipsec-for-coap-00txt
IPsec definitions for CoAP Mostly placeholder at this time Who has implementation experience with this
125
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-cross-reverse-convention-00txt
This draft has two lines of payload(based on a WGLC comment by Cullen Jennings)
coap12344567foobara=3
httpwwwproxycomwellknowncore-translate1234_4567foobara=3
Is that a useful convention to have
126
Insert CI slides here
127
128
0
5
10
15
20
25
30
35
40
10 20 30 40 50 60 70
good
put (
pps)
pps
Goodput vs pps (Econotags)
goodput
[Khattak preliminary]
Congestion Control
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-cocoa-00txt
ldquoadvancedrdquo cc (The draft is just a first shot) Others may have better ideas
129
Insert post-WGLC discussion slides here
130
Stop Continue Start
131
An Agile Retrospective
http6lowappnet coreIETF86 2013-03-12-13
Stop
132
Endless new CoAP optionssect instead use RESTful as much as possible
Move general security lifecycle out Looking at theoretical problems
http6lowappnet coreIETF86 2013-03-12-13
Continue
Interops Running code Look at real-world examples and deployments Solve their actual problems
sect Unilateral enhancements eg higher performance congestion control
sect Transports (SMS hellip)sect Make Web linking and Directories more and more usefulsect RESTful Design Paradigms for real-world problems
133
http6lowappnet coreIETF86 2013-03-12-13
Start
Further push into the (browser) web world (HTML5 browser security)
Specific supporting worksect SenMLsect URI work (dev URN hellip)sect Security Processes (next slide)
Spin outsect (We donrsquot really get to decide where this is done)
134
http6lowappnet coreIETF86 2013-03-12-13
Security
Integrate Application Network Group Keyingsect Tunnel-free setup
Donrsquot redo what has been done alreadysect ZigBee IP is finesect But what about other scenarios
Simple REST interfaces for working with keying materials and authorizationsect Start with defining objectives
Object Security for Constrained Nodes135
Re-chartering CoREWhat do we want to do now that wersquore grown up
Zach ShelbyCoRE WG IETF-86 Orlando
What is the scope
bull So we have a protocol and Web Linking what next
bull Keep with what we know besthellip1 Enhancements around CoAP2 New transports for CoAP3 New representations for Web Links4 General application layer solutions
CoRE WG IETF-86 Orlando 2
Enhancements around CoAP
bull Advanced congestion control
CoRE WG IETF-86 Orlando 3
New Transports for CoAP
bull Infrastructure for CoAP over foondash httptoolsietforgiddraft-silverajan-core-
coap-alternative-transports-01txtbull CoAP over SMS
ndash httptoolsietforgiddraft-becker-core-coap-sms-gprs-03txt
ndash OMA Lightweightbull CoAP over TCP
ndash httptoolsietforgiddraft-li-core-coap-payload-length-option-01txt
CoRE WG IETF-86 Orlando 4
New support for Web Links
bull JSON Web Linksndash httptoolsietforgiddraft-bormann-core-links-
json-02txt
2332010 CoRE WG IETF-77 Anaheim 5
General application layer solutions
bull Resource Directoryndash httptoolsietforgiddraft-shelby-core-
resource-directory-05txtndash OMA Lightweight
2332010 CoRE WG IETF-77 Anaheim 6
CoAP Sleep-Aware Reverse Proxy Features CoRE Sleep-aware Resource Directory
Support storing published sleep parameters from CoAP servers sleepState (AWAKE ASLEEP) sleepDuration
Sleep-aware CoAP 503 Response Capability If CoAP request to a sleeping server is received proxy returns a
lsquo503 Retry-Afterrsquo response to client 503 contains a timestamp indicating when the sever will wake back up
(timestamp delivered in CoAP maxAge option) Sleep-aware CoAP Store-and-Forward Capability
If CoAP request to a sleeping server is received proxy stores request until server wakes up and then forwards it
Caching capability Cache GET responses from server if maxAge option is present
(this is not a sleep aware feature)
Goals of Performance Analysis
For networks having sleepy servers provide measurements to quantify the impact that CoAP sleep-awareness capabilities can have
See if sleep-awareness capabilities can
provide additional benefits even when CoAP caching is used
Overview of Performance Analysis Performed The analysis was broken up into a set of test scenarios Each test scenario used a different combination of the following
variables Client issued GET requests Server was configured as a sleepy or non-sleepy server Proxy caching of GET responses was enabled or disabled Proxy sleep-aware 503 response capability was enabled or disabled Proxy store-and-forward capability was enabled or disabled maxAge in GET responses ndash Two values were tested 60sec and 5sec of Clients ndash Two values were used ndash 1 client and 5 clients
For comparison purposes the following were held constant across all test scenarios Client issued a fixed number of requests (100) across all test scenarios Client used a delay between each GET request (35sec) to better exercise
proxyrsquos caching and sleep-awareness capabilities For sleepy server test scenarios the server slept 60 sec awake for 3 sec
Format of Results The following results were collected for each
test scenario
Breakdown of the and types of transactions occurring between clientproxyserver
ldquoGETrdquo ndash Test Scenario Results
GET ndash Description of Test Scenarios
TestScenarios-GET
Scenario
CoAPSleepyServerSe7ngs CoAPSleepAwareReverseProxySe7ngs CoAPClientSe7ngs
SleepDuragton(sec)
AwakeDuragton(sec)
maxAge(sec) Caching SleepAwareSAF+
503NumberofClients
NumberofGETs
DelayBetweenClient
Requests(sec)
1a 0 Always 60 Enabled Disabled 1 100 35
1b 60 3 60 Enabled Disabled 1 100 35
1c 60 3 60 Enabled Enabled 1 100 35
2a 0 Always 60 Enabled Disabled 5 100 35
2b 60 3 60 Enabled Disabled 5 100 35
2c 60 3 60 Enabled Enabled 5 100 35
3a 0 Always 5 Enabled Disabled 5 100 35
3b 60 3 5 Enabled Disabled 5 100 35
3c 60 3 5 Enabled Enabled 5 100 35
ldquoGETrdquo ndash Test Scenario 1 Results
maxAge = 60 and 1 Client
GET ndash Scenario 1 ClientProxy Interface Transaction Mix
Scenarios 1a - Non-Sleepy Server Caching Proxy maxAge = 60sec 1b- Sleepy Server Caching Proxy maxAge = 60sec 1c - Sleepy Server Sleep Aware Proxy maxAge = 60sec
Sleep Aware Proxy has better performance for sleepy servers
0
100
200
300
400
500
600
700
1a 1b 1c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
GET ndash Scenario 1 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
Scenarios 1a - Non-Sleepy Server Caching Proxy maxAge = 60sec 1b- Sleepy Server Caching Proxy maxAge = 60sec 1c - Sleepy Server Sleep Aware Proxy maxAge = 60sec
0
100
200
300
400
500
600
700
800
1a 1b 1c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
ldquoGETrdquo ndash Test Scenario 2 Results
maxAge = 60 and 5 Clients
GET ndash Scenario 2 ClientProxy Interface Transaction Mix
Sleep Aware Proxy has slightly better performance for sleepy servers
0
200
400
600
800
1000
1200
1400
2a 2b 2c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
Scenarios 2a - Non-Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2b- Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2c - Sleepy Server Sleep Aware Proxy maxAge = 60sec 5 Clients
See ldquoExperimental Artifactsrdquo Note 1
GET ndash Scenario 2 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has slightly better performance for sleepy servers
0
50
100
150
200
250
300
350
400
2a 2b 2c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
Scenarios 2a - Non-Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2b- Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2c - Sleepy Server Sleep Aware Proxy maxAge = 60sec 5 Clients
See ldquoExperimental Artifactsrdquo Note 2
Experimental Artifacts Note 1
Currently in the experiment the sleep aware proxy checks the cached state of a resource before putting a request into its Store-and-forward queue while a server is sleeping Once in the queue the proxy unconditionally forwards the queued requests to the server once it wakes up This is not the most efficient setup and can easily be improved If the proxy instead checks its cache again before forwarding each queued request it may not need to forward the request to the server For example if there are two queued GET requests in the proxyrsquos queue that address the same resource Only the first request needs to be sent to the server the second request can use the cached response from the first request
Note 2 Currently in the experiment the sleepy server sends a sleepState PUT request to the
proxy each time it goes to sleep This is not the most efficient setup and can easily be improved For example if the server assumes that the proxy can keep track of its ONOFF cycles with its internal timers (eg as per Fig 1 of I-D) then the number of messages from the sleepy server dramatically goes down
ldquoGETrdquo ndash Test Scenario 3 Results
maxAge = 5 and 5 Clients
GET ndash Scenario 3 ClientProxy Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
Scenarios 3a - Non-Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3b- Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3c - Sleepy Server Sleep Aware Proxy maxAge = 5sec 5 Clients
0
500
1000
1500
2000
2500
3000
3500
4000
4500
5000
3a 3b 3c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
GET ndash Scenario 3 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
0
1000
2000
3000
4000
5000
6000
7000
3a 3b 3c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
Scenarios 3a - Non-Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3b- Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3c - Sleepy Server Sleep Aware Proxy maxAge = 5sec 5 Clients
Conclusions
Conclusions These results show that sleep-aware CoAP
proxy features can significantly optimize communication with sleepy servers in most scenarios
These results also show that sleep-
awareness capabilities can provide additional benefits above and beyond CoAP caching in most scenarios
Backup
Current CoAP Support of Sleepy Node (12)
CoAP proxies can use a previously cached response to service a new GET request for a sleepy origin server (as in HTTP) But if no valid cache then proxy has to attempt to
retrieve and may fail if origin server is sleeping [I-Dietf-core-coap]
Clients can discover list of resources from RD (GET rd-lookuphellip) for sleepy servers But attempt to GET resource from sleepy origin server
may fail if origin server is sleeping [IDietf-core-link-format amp IDshelby-core-resource-
directory]
Current CoAP Support of Sleepy Node (22)
Lower layer support for sleepy nodes in most wireless technologies (eg WiFi ZigBee) But limited to MAC packet scheduling for sleepy nodes
and not aware of specific needs of IP applications (like CoAP)
Proposal ndash RD Based Sleep Tracking (14)
The current CoAP approach to support sleepy nodes can be significantly improved by introducing RD based mechanisms for a CoAP client to determine whether A targeted resource is located on a sleepy server A sleepy server is currently in sleep mode or not
There is any associated caching Proxy (possibly the RD itself) for a sleepy server
Proposal ndash RD Based Sleep Tracking (24)
We define the following new RD attributes to characterize the properties of a sleepy node SleepState - Indicates whether the node is currently in
sleep mode or not (ie Sleeping or Awake) SleepDuration - Indicates the maximum duration of time
that the node stays in sleep mode TimeSleeping - Indicates the length of time the node
has been sleeping (ie if Sleep State = Sleeping) NextSleep - Indicates the next time the node will go to
sleep (ie if Sleep State = Awake)
CachingProxy ndash Indicates the caching proxy of the sleepy node (ie the RD itself or another node)
Proposal ndash RD Based Sleep Tracking (34)
These attributes are all server (node) level and are new parameters added to the RD URI Template Variables
Finally we also define a new lookup-type (ss) for the RD lookup interface specified in [I-Dshelby-core-resource-directory] This new lookup-type supports looking up the
ldquoSleepStaterdquo (ss) of a specified end-point
Proposal ndash RD Based Sleep Tracking (44)
The three time based parameters (SleepDuration TimeSleeping NextSleep) can be based on either an absolute network time (for a time synchronized network) or a relative local time (measured at the local node)
Following the approach of [I-Dietf-core-link-format] and [I-Dshelby-core-resource-directory] sleep parameters for sleepy servers can be stored by the server in the RD and accessed by all interested clients
Examples of using these parameters in a synchronous or asynchronous manner are shown in the I-D
http6lowappnet coreIETF86 2013-03-12-13
We assume people have read the drafts
Meetings serve to advance difficult issues by making good use of face-to-face communications
Note Well Be aware of the IPR principles according to RFC 3979 and its updates
uumlBlue sheetsuumlScribe(s)
96
drar-shy‐iep-shy‐core-shy‐coapsubmiqed13 to13 IESG
2013-shy‐03-shy‐13
97
OMA Lightweight M2M Overview(A new standard using lots of IETF specs including DTLS
CoAP Block Observe Resource Directory SenMLhellip)
Zach ShelbyCoRE WG IETF-86 Orlando
OMA Lightweight M2Mbull Open Mobile Alliance is well known for Device Management (DM)bull OMA Lightweight M2M is a new standard from the alliance
ndash Focused on constrained Cellular and sensor network M2M devicesndash Driven by leading operators and vendors
bull Scopendash Interfaces protocol amp security between Device and Serverndash Object and Resource modelndash Bootstrap Device Access Control Connectivity and Firmware Objects
bull Draft Specifications are availablendash httpmemberopenmobileallianceorgftpPublic_documentsDM
LightweightM2MPermanent_documentsOMA-TS-LightweightM2M-V1_0_0-20130301-Dzip
bull Timelinendash Requirements and Architecture completed 3Q2012ndash Spec ready for Consistency Review 2Q2013ndash Candidate Approval expected 3Q2013
2 CoRE WG IETF-86 Orlando
Architecture
3
Scope of LWM2M
CoRE WG IETF-86 Orlando
Object Model
bull A Client has one or more Object Instancesbull An Object is a collection of Resourcesbull A Resource is an atomic piece of information
ndash Read Written or Executed
bull Resources can have multiple instancesbull Objects and Resources are identified by a
16-bit Integer Instances by an 8-bit Integerbull ObjectsResources are accessed with
simple URIs Object IDObject InstanceResource ID
eg 1213
4 CoRE WG IETF-86 Orlando
CoRE WG IETF-86 Orlando
CoRE Resource Directory
draft-shelby-core-resource-directory-05
Z Shelby C Bormann S Krco
Backgroundbull Not a new concept
ndash think web search engine or any link directorybull Defines the interfaces to a Resource Directorybull Based on Web Linking framework and the CoRE Link Formatbull Generic REST design for use over HTTP and CoAPbull Used by OMA Lightweight M2Mbull Has already been deployed
ndash In traffic monitoring systemsndash In street lighting systemsndash For vehicular asset trackingndash By a major Cellular M2M operator
Changes since -04
bull Restricted Update to parameter updatesbull Added pagination support for the Lookup interfacebull Changed rt= to et= for the registration amp update
interfacebull Added group support
Group Management
bull RD now includes group management featuresbull New Group Function Set
ndash Register a groupbull Group name domain multicast address endpoint members
ndash Remove a groupbull Group lookup using the Lookup Function Set
ndash List registered groupsndash Find the members of a groupndash Find groups with certain endpoints or resources
Registering a Group
EP RD
| |
| - POST rd-groupgp=lights ltgtep=node1 --gt |
| |
| |
| lt---- 201 Created Location rd-group12 ---- |
| |
Req POST coaprdexamplecomrd-groupgp=lights
Payload
ltgtep=node1
ltgtep=node2
Res 201 Created
Location rd-group12
Looking up Group Members
Client RD
| |
| ----- GET rd-lookupepgp=lights1 ----------------------gt |
| |
| |
| lt-- 205 Content ltrdgtd=domain1ltrdgtd=domain2 --------- |
| |
Req GET rd-lookupepgp=lights1
Res 205 Content
ltcoaphostportgtep=node1
ltcoaphostportgtep=node2rdquo
Things for the futurebull Support for JSON representation of Web Links
ndash httptoolsietforgiddraft-bormann-core-links-json-02txtbull Registry for RD registration query parameters
ndash Already OMA Lightweight has defined some new onesbull More examples
Group 3 ldquonew workrdquo(continued)
109
drar-shy‐greevenbosch-shy‐core-shy‐profile-shy‐descripon-shy‐01Bert13 GreevenboschJeroen13 Hoebeke
Isam13 IshaqFloris13 Van13 den13 Abeele
Descripon
bull JSON13 format13 for13 signalling13 the13 servers13 capabilies
bull Signalling13 of13 supported13 opons13 media13 types13 and13 block13 sizendash Other13 items13 can13 be13 added
bull Filtering13 on13 specific13 fields13 through13 URI-shy‐Querybull Link13 hqpdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐profile-shy‐descripon
well-shy‐knownprofile
bull To13 acquire13 profile13 data13 of13 resources13 on13 a13 parcular13 service13 the13 well-shy‐knownprofile13 URI-shy‐path13 is13 introduced
bull For13 example13 to13 get13 all13 informaon13 from13 sensors13 served13 by13 wwwexampleorg13 we13 can13 do13 a13 GET13 to13 coapwwwexampleorgwell-shy‐knownprofile
bull Filtering13 on13 parcular13 resources13 is13 done13 through13 URI-shy‐Queries
Format
bull Currently13 the13 following13 fields13 are13 definedndash ldquopathrdquo13 contains13 the13 URI-shy‐path13 associated13 with13 a13 resource
ndash ldquooprdquo13 a13 numerical13 list13 of13 supported13 opon13 numbers
ndash ldquocfrdquo13 a13 numerical13 list13 of13 supported13 content-shy‐format13 numbers
ndash ldquob1srdquo13 ldquob2srdquo13 supported13 block13 sizes13 for13 Block113 and13 Block213 respecvely
Examplebull On13 the13 right13 is13 an13 example13 of13 a13 camera13 sensor13 at13 coapwwwexampleorgcam13 that13 supports13 the13 Uri-shy‐Host13 (3)13 ETag13 (4)13 Uri-shy‐Port13 (7)13 Uri-shy‐Path13 (11)13 Content-shy‐Format13 (12)13 Token13 (19)13 Block213 (23)13 and13 Proxy-shy‐Uri13 (35)13 opons
bull The13 supported13 content13 formats13 are13 textplain13 (0)13 applicaon13 link-shy‐format13 (40)13 and13 applicaonjson13 (50)
bull The13 supported13 Block213 can13 use13 25613 or13 51213 byte13 blocks
Req13 GET13 coapwwwexampleorgwell-shy‐knownprofile13 Res13 20513 Content13 (applicationjson)13 13 13 13 profile13 13 13 13 13 13 13 13 pathcam13 13 13 13 op[3471112192335]13 13 13 13 13 cf[04050]13 13 13 13 13 b2s[45]13 13 13 13
Filtering13 through13 use13 of13 URI-shy‐Query
bull Filtering13 can13 be13 done13 through13 the13 URI-shy‐Querybull Query13 format13 N=V
ndash N13 is13 a13 profile13 fieldndash V13 is13 the13 desired13 value
bull Examplesndash To13 find13 resources13 that13 support13 content13 format13 ldquoapplicaonjsonrdquo
13 GET13 wwwexampleorgwell-shy‐knownprofilecf=50ndash To13 get13 informaon13 about13 the13 camera
13 GET13 wwwexampleorgwell-shy‐knownprofilepath=cam
Open13 issues
bull Which13 other13 profile13 data13 needs13 signallingndash Content-shy‐type13 for13 different13 methods
bull Fix13 the13 order13 in13 which13 the13 profile13 fields13 must13 appearndash Non-shy‐fixed13 order13 easier13 extensible
bull Inheritance13 of13 a13 profile13 descriponbull Extend13 usage13 to13 signal13 the13 client13 profilebull Integraon13 with13 link13 format
Thank13 youQuesons
drar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval-shy‐00
Bert13 Greevenbosch
Descripon
bull The13 ldquoMinimumRequestInterval13 opon13 can13 be13 used13 to13 indicate13 the13 minimum13 me13 between13 two13 requests13 in13 a13 transacon
bull Originally13 intended13 for13 Block13 but13 also13 usable13 for13 other13 transaconsndash Example13 browsing13 a13 server
bull The13 goal13 is13 to13 reduce13 the13 server13 load13 and13 network13 traffic
bull Link13 hqpsdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval
Usage
bull The13 client13 keeps13 the13 server13 informed13 about13 its13 request13 speed13 through13 inclusion13 of13 the13 ldquoMinimumRequestIntervalrdquo13 opon
bull In13 responses13 the13 server13 fixes13 the13 minimum13 request13 interval13 through13 the13 same13 opon
bull The13 client13 obeys13 the13 speed13 indicated13 by13 the13 server
bull The13 client13 can13 send13 slower13 but13 not13 faster
Advantages
bull The13 server13 has13 means13 to13 limit13 the13 amount13 of13 incoming13 traffic
bull The13 server13 can13 prevent13 to13 become13 overloaded13 with13 too13 many13 tasks
bull The13 server13 does13 not13 need13 arficially13 slow13 down13 the13 client13 by13 sending13 late13 ACKsndash No13 need13 to13 keep13 track13 of13 delayed13 ACKsndash The13 server13 can13 perform13 other13 tasks13 instead
bull Reduced13 network13 traffic
Thank13 youQuesons
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-links-json-02txt
123
RFC 6690 (link-format) documents are somewhat foreign to many web app developerssect would prefer to have them in JSON format
There is no standard way to represent link-format documents in applicationssect but everyone knows how to handle JSON
Define a standard JSON translation for link-format
Itrsquos
not
rock
et
scien
ce
ltsensorsgtct=40title=Sensor Index ltsensorstempgtrt=temperature-cif=sensor ltsensorslightgtrt=light-luxif=sensor lthttpwwwexamplecomsensorst123gt anchor=sensorstemprel=describedby lttgtanchor=sensorstemprel=alternate [hrefsensorsct40titleSensor Index hrefsensorstemprttemperature-cifsensor hrefsensorslightrtlight-luxifsensor hrefhttpwwwexamplecomsensorst123 anchorsensorstempreldescribedby hreftanchorsensorstemprelalternate]
124
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-ipsec-for-coap-00txt
IPsec definitions for CoAP Mostly placeholder at this time Who has implementation experience with this
125
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-cross-reverse-convention-00txt
This draft has two lines of payload(based on a WGLC comment by Cullen Jennings)
coap12344567foobara=3
httpwwwproxycomwellknowncore-translate1234_4567foobara=3
Is that a useful convention to have
126
Insert CI slides here
127
128
0
5
10
15
20
25
30
35
40
10 20 30 40 50 60 70
good
put (
pps)
pps
Goodput vs pps (Econotags)
goodput
[Khattak preliminary]
Congestion Control
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-cocoa-00txt
ldquoadvancedrdquo cc (The draft is just a first shot) Others may have better ideas
129
Insert post-WGLC discussion slides here
130
Stop Continue Start
131
An Agile Retrospective
http6lowappnet coreIETF86 2013-03-12-13
Stop
132
Endless new CoAP optionssect instead use RESTful as much as possible
Move general security lifecycle out Looking at theoretical problems
http6lowappnet coreIETF86 2013-03-12-13
Continue
Interops Running code Look at real-world examples and deployments Solve their actual problems
sect Unilateral enhancements eg higher performance congestion control
sect Transports (SMS hellip)sect Make Web linking and Directories more and more usefulsect RESTful Design Paradigms for real-world problems
133
http6lowappnet coreIETF86 2013-03-12-13
Start
Further push into the (browser) web world (HTML5 browser security)
Specific supporting worksect SenMLsect URI work (dev URN hellip)sect Security Processes (next slide)
Spin outsect (We donrsquot really get to decide where this is done)
134
http6lowappnet coreIETF86 2013-03-12-13
Security
Integrate Application Network Group Keyingsect Tunnel-free setup
Donrsquot redo what has been done alreadysect ZigBee IP is finesect But what about other scenarios
Simple REST interfaces for working with keying materials and authorizationsect Start with defining objectives
Object Security for Constrained Nodes135
Re-chartering CoREWhat do we want to do now that wersquore grown up
Zach ShelbyCoRE WG IETF-86 Orlando
What is the scope
bull So we have a protocol and Web Linking what next
bull Keep with what we know besthellip1 Enhancements around CoAP2 New transports for CoAP3 New representations for Web Links4 General application layer solutions
CoRE WG IETF-86 Orlando 2
Enhancements around CoAP
bull Advanced congestion control
CoRE WG IETF-86 Orlando 3
New Transports for CoAP
bull Infrastructure for CoAP over foondash httptoolsietforgiddraft-silverajan-core-
coap-alternative-transports-01txtbull CoAP over SMS
ndash httptoolsietforgiddraft-becker-core-coap-sms-gprs-03txt
ndash OMA Lightweightbull CoAP over TCP
ndash httptoolsietforgiddraft-li-core-coap-payload-length-option-01txt
CoRE WG IETF-86 Orlando 4
New support for Web Links
bull JSON Web Linksndash httptoolsietforgiddraft-bormann-core-links-
json-02txt
2332010 CoRE WG IETF-77 Anaheim 5
General application layer solutions
bull Resource Directoryndash httptoolsietforgiddraft-shelby-core-
resource-directory-05txtndash OMA Lightweight
2332010 CoRE WG IETF-77 Anaheim 6
Goals of Performance Analysis
For networks having sleepy servers provide measurements to quantify the impact that CoAP sleep-awareness capabilities can have
See if sleep-awareness capabilities can
provide additional benefits even when CoAP caching is used
Overview of Performance Analysis Performed The analysis was broken up into a set of test scenarios Each test scenario used a different combination of the following
variables Client issued GET requests Server was configured as a sleepy or non-sleepy server Proxy caching of GET responses was enabled or disabled Proxy sleep-aware 503 response capability was enabled or disabled Proxy store-and-forward capability was enabled or disabled maxAge in GET responses ndash Two values were tested 60sec and 5sec of Clients ndash Two values were used ndash 1 client and 5 clients
For comparison purposes the following were held constant across all test scenarios Client issued a fixed number of requests (100) across all test scenarios Client used a delay between each GET request (35sec) to better exercise
proxyrsquos caching and sleep-awareness capabilities For sleepy server test scenarios the server slept 60 sec awake for 3 sec
Format of Results The following results were collected for each
test scenario
Breakdown of the and types of transactions occurring between clientproxyserver
ldquoGETrdquo ndash Test Scenario Results
GET ndash Description of Test Scenarios
TestScenarios-GET
Scenario
CoAPSleepyServerSe7ngs CoAPSleepAwareReverseProxySe7ngs CoAPClientSe7ngs
SleepDuragton(sec)
AwakeDuragton(sec)
maxAge(sec) Caching SleepAwareSAF+
503NumberofClients
NumberofGETs
DelayBetweenClient
Requests(sec)
1a 0 Always 60 Enabled Disabled 1 100 35
1b 60 3 60 Enabled Disabled 1 100 35
1c 60 3 60 Enabled Enabled 1 100 35
2a 0 Always 60 Enabled Disabled 5 100 35
2b 60 3 60 Enabled Disabled 5 100 35
2c 60 3 60 Enabled Enabled 5 100 35
3a 0 Always 5 Enabled Disabled 5 100 35
3b 60 3 5 Enabled Disabled 5 100 35
3c 60 3 5 Enabled Enabled 5 100 35
ldquoGETrdquo ndash Test Scenario 1 Results
maxAge = 60 and 1 Client
GET ndash Scenario 1 ClientProxy Interface Transaction Mix
Scenarios 1a - Non-Sleepy Server Caching Proxy maxAge = 60sec 1b- Sleepy Server Caching Proxy maxAge = 60sec 1c - Sleepy Server Sleep Aware Proxy maxAge = 60sec
Sleep Aware Proxy has better performance for sleepy servers
0
100
200
300
400
500
600
700
1a 1b 1c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
GET ndash Scenario 1 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
Scenarios 1a - Non-Sleepy Server Caching Proxy maxAge = 60sec 1b- Sleepy Server Caching Proxy maxAge = 60sec 1c - Sleepy Server Sleep Aware Proxy maxAge = 60sec
0
100
200
300
400
500
600
700
800
1a 1b 1c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
ldquoGETrdquo ndash Test Scenario 2 Results
maxAge = 60 and 5 Clients
GET ndash Scenario 2 ClientProxy Interface Transaction Mix
Sleep Aware Proxy has slightly better performance for sleepy servers
0
200
400
600
800
1000
1200
1400
2a 2b 2c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
Scenarios 2a - Non-Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2b- Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2c - Sleepy Server Sleep Aware Proxy maxAge = 60sec 5 Clients
See ldquoExperimental Artifactsrdquo Note 1
GET ndash Scenario 2 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has slightly better performance for sleepy servers
0
50
100
150
200
250
300
350
400
2a 2b 2c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
Scenarios 2a - Non-Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2b- Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2c - Sleepy Server Sleep Aware Proxy maxAge = 60sec 5 Clients
See ldquoExperimental Artifactsrdquo Note 2
Experimental Artifacts Note 1
Currently in the experiment the sleep aware proxy checks the cached state of a resource before putting a request into its Store-and-forward queue while a server is sleeping Once in the queue the proxy unconditionally forwards the queued requests to the server once it wakes up This is not the most efficient setup and can easily be improved If the proxy instead checks its cache again before forwarding each queued request it may not need to forward the request to the server For example if there are two queued GET requests in the proxyrsquos queue that address the same resource Only the first request needs to be sent to the server the second request can use the cached response from the first request
Note 2 Currently in the experiment the sleepy server sends a sleepState PUT request to the
proxy each time it goes to sleep This is not the most efficient setup and can easily be improved For example if the server assumes that the proxy can keep track of its ONOFF cycles with its internal timers (eg as per Fig 1 of I-D) then the number of messages from the sleepy server dramatically goes down
ldquoGETrdquo ndash Test Scenario 3 Results
maxAge = 5 and 5 Clients
GET ndash Scenario 3 ClientProxy Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
Scenarios 3a - Non-Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3b- Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3c - Sleepy Server Sleep Aware Proxy maxAge = 5sec 5 Clients
0
500
1000
1500
2000
2500
3000
3500
4000
4500
5000
3a 3b 3c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
GET ndash Scenario 3 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
0
1000
2000
3000
4000
5000
6000
7000
3a 3b 3c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
Scenarios 3a - Non-Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3b- Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3c - Sleepy Server Sleep Aware Proxy maxAge = 5sec 5 Clients
Conclusions
Conclusions These results show that sleep-aware CoAP
proxy features can significantly optimize communication with sleepy servers in most scenarios
These results also show that sleep-
awareness capabilities can provide additional benefits above and beyond CoAP caching in most scenarios
Backup
Current CoAP Support of Sleepy Node (12)
CoAP proxies can use a previously cached response to service a new GET request for a sleepy origin server (as in HTTP) But if no valid cache then proxy has to attempt to
retrieve and may fail if origin server is sleeping [I-Dietf-core-coap]
Clients can discover list of resources from RD (GET rd-lookuphellip) for sleepy servers But attempt to GET resource from sleepy origin server
may fail if origin server is sleeping [IDietf-core-link-format amp IDshelby-core-resource-
directory]
Current CoAP Support of Sleepy Node (22)
Lower layer support for sleepy nodes in most wireless technologies (eg WiFi ZigBee) But limited to MAC packet scheduling for sleepy nodes
and not aware of specific needs of IP applications (like CoAP)
Proposal ndash RD Based Sleep Tracking (14)
The current CoAP approach to support sleepy nodes can be significantly improved by introducing RD based mechanisms for a CoAP client to determine whether A targeted resource is located on a sleepy server A sleepy server is currently in sleep mode or not
There is any associated caching Proxy (possibly the RD itself) for a sleepy server
Proposal ndash RD Based Sleep Tracking (24)
We define the following new RD attributes to characterize the properties of a sleepy node SleepState - Indicates whether the node is currently in
sleep mode or not (ie Sleeping or Awake) SleepDuration - Indicates the maximum duration of time
that the node stays in sleep mode TimeSleeping - Indicates the length of time the node
has been sleeping (ie if Sleep State = Sleeping) NextSleep - Indicates the next time the node will go to
sleep (ie if Sleep State = Awake)
CachingProxy ndash Indicates the caching proxy of the sleepy node (ie the RD itself or another node)
Proposal ndash RD Based Sleep Tracking (34)
These attributes are all server (node) level and are new parameters added to the RD URI Template Variables
Finally we also define a new lookup-type (ss) for the RD lookup interface specified in [I-Dshelby-core-resource-directory] This new lookup-type supports looking up the
ldquoSleepStaterdquo (ss) of a specified end-point
Proposal ndash RD Based Sleep Tracking (44)
The three time based parameters (SleepDuration TimeSleeping NextSleep) can be based on either an absolute network time (for a time synchronized network) or a relative local time (measured at the local node)
Following the approach of [I-Dietf-core-link-format] and [I-Dshelby-core-resource-directory] sleep parameters for sleepy servers can be stored by the server in the RD and accessed by all interested clients
Examples of using these parameters in a synchronous or asynchronous manner are shown in the I-D
http6lowappnet coreIETF86 2013-03-12-13
We assume people have read the drafts
Meetings serve to advance difficult issues by making good use of face-to-face communications
Note Well Be aware of the IPR principles according to RFC 3979 and its updates
uumlBlue sheetsuumlScribe(s)
96
drar-shy‐iep-shy‐core-shy‐coapsubmiqed13 to13 IESG
2013-shy‐03-shy‐13
97
OMA Lightweight M2M Overview(A new standard using lots of IETF specs including DTLS
CoAP Block Observe Resource Directory SenMLhellip)
Zach ShelbyCoRE WG IETF-86 Orlando
OMA Lightweight M2Mbull Open Mobile Alliance is well known for Device Management (DM)bull OMA Lightweight M2M is a new standard from the alliance
ndash Focused on constrained Cellular and sensor network M2M devicesndash Driven by leading operators and vendors
bull Scopendash Interfaces protocol amp security between Device and Serverndash Object and Resource modelndash Bootstrap Device Access Control Connectivity and Firmware Objects
bull Draft Specifications are availablendash httpmemberopenmobileallianceorgftpPublic_documentsDM
LightweightM2MPermanent_documentsOMA-TS-LightweightM2M-V1_0_0-20130301-Dzip
bull Timelinendash Requirements and Architecture completed 3Q2012ndash Spec ready for Consistency Review 2Q2013ndash Candidate Approval expected 3Q2013
2 CoRE WG IETF-86 Orlando
Architecture
3
Scope of LWM2M
CoRE WG IETF-86 Orlando
Object Model
bull A Client has one or more Object Instancesbull An Object is a collection of Resourcesbull A Resource is an atomic piece of information
ndash Read Written or Executed
bull Resources can have multiple instancesbull Objects and Resources are identified by a
16-bit Integer Instances by an 8-bit Integerbull ObjectsResources are accessed with
simple URIs Object IDObject InstanceResource ID
eg 1213
4 CoRE WG IETF-86 Orlando
CoRE WG IETF-86 Orlando
CoRE Resource Directory
draft-shelby-core-resource-directory-05
Z Shelby C Bormann S Krco
Backgroundbull Not a new concept
ndash think web search engine or any link directorybull Defines the interfaces to a Resource Directorybull Based on Web Linking framework and the CoRE Link Formatbull Generic REST design for use over HTTP and CoAPbull Used by OMA Lightweight M2Mbull Has already been deployed
ndash In traffic monitoring systemsndash In street lighting systemsndash For vehicular asset trackingndash By a major Cellular M2M operator
Changes since -04
bull Restricted Update to parameter updatesbull Added pagination support for the Lookup interfacebull Changed rt= to et= for the registration amp update
interfacebull Added group support
Group Management
bull RD now includes group management featuresbull New Group Function Set
ndash Register a groupbull Group name domain multicast address endpoint members
ndash Remove a groupbull Group lookup using the Lookup Function Set
ndash List registered groupsndash Find the members of a groupndash Find groups with certain endpoints or resources
Registering a Group
EP RD
| |
| - POST rd-groupgp=lights ltgtep=node1 --gt |
| |
| |
| lt---- 201 Created Location rd-group12 ---- |
| |
Req POST coaprdexamplecomrd-groupgp=lights
Payload
ltgtep=node1
ltgtep=node2
Res 201 Created
Location rd-group12
Looking up Group Members
Client RD
| |
| ----- GET rd-lookupepgp=lights1 ----------------------gt |
| |
| |
| lt-- 205 Content ltrdgtd=domain1ltrdgtd=domain2 --------- |
| |
Req GET rd-lookupepgp=lights1
Res 205 Content
ltcoaphostportgtep=node1
ltcoaphostportgtep=node2rdquo
Things for the futurebull Support for JSON representation of Web Links
ndash httptoolsietforgiddraft-bormann-core-links-json-02txtbull Registry for RD registration query parameters
ndash Already OMA Lightweight has defined some new onesbull More examples
Group 3 ldquonew workrdquo(continued)
109
drar-shy‐greevenbosch-shy‐core-shy‐profile-shy‐descripon-shy‐01Bert13 GreevenboschJeroen13 Hoebeke
Isam13 IshaqFloris13 Van13 den13 Abeele
Descripon
bull JSON13 format13 for13 signalling13 the13 servers13 capabilies
bull Signalling13 of13 supported13 opons13 media13 types13 and13 block13 sizendash Other13 items13 can13 be13 added
bull Filtering13 on13 specific13 fields13 through13 URI-shy‐Querybull Link13 hqpdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐profile-shy‐descripon
well-shy‐knownprofile
bull To13 acquire13 profile13 data13 of13 resources13 on13 a13 parcular13 service13 the13 well-shy‐knownprofile13 URI-shy‐path13 is13 introduced
bull For13 example13 to13 get13 all13 informaon13 from13 sensors13 served13 by13 wwwexampleorg13 we13 can13 do13 a13 GET13 to13 coapwwwexampleorgwell-shy‐knownprofile
bull Filtering13 on13 parcular13 resources13 is13 done13 through13 URI-shy‐Queries
Format
bull Currently13 the13 following13 fields13 are13 definedndash ldquopathrdquo13 contains13 the13 URI-shy‐path13 associated13 with13 a13 resource
ndash ldquooprdquo13 a13 numerical13 list13 of13 supported13 opon13 numbers
ndash ldquocfrdquo13 a13 numerical13 list13 of13 supported13 content-shy‐format13 numbers
ndash ldquob1srdquo13 ldquob2srdquo13 supported13 block13 sizes13 for13 Block113 and13 Block213 respecvely
Examplebull On13 the13 right13 is13 an13 example13 of13 a13 camera13 sensor13 at13 coapwwwexampleorgcam13 that13 supports13 the13 Uri-shy‐Host13 (3)13 ETag13 (4)13 Uri-shy‐Port13 (7)13 Uri-shy‐Path13 (11)13 Content-shy‐Format13 (12)13 Token13 (19)13 Block213 (23)13 and13 Proxy-shy‐Uri13 (35)13 opons
bull The13 supported13 content13 formats13 are13 textplain13 (0)13 applicaon13 link-shy‐format13 (40)13 and13 applicaonjson13 (50)
bull The13 supported13 Block213 can13 use13 25613 or13 51213 byte13 blocks
Req13 GET13 coapwwwexampleorgwell-shy‐knownprofile13 Res13 20513 Content13 (applicationjson)13 13 13 13 profile13 13 13 13 13 13 13 13 pathcam13 13 13 13 op[3471112192335]13 13 13 13 13 cf[04050]13 13 13 13 13 b2s[45]13 13 13 13
Filtering13 through13 use13 of13 URI-shy‐Query
bull Filtering13 can13 be13 done13 through13 the13 URI-shy‐Querybull Query13 format13 N=V
ndash N13 is13 a13 profile13 fieldndash V13 is13 the13 desired13 value
bull Examplesndash To13 find13 resources13 that13 support13 content13 format13 ldquoapplicaonjsonrdquo
13 GET13 wwwexampleorgwell-shy‐knownprofilecf=50ndash To13 get13 informaon13 about13 the13 camera
13 GET13 wwwexampleorgwell-shy‐knownprofilepath=cam
Open13 issues
bull Which13 other13 profile13 data13 needs13 signallingndash Content-shy‐type13 for13 different13 methods
bull Fix13 the13 order13 in13 which13 the13 profile13 fields13 must13 appearndash Non-shy‐fixed13 order13 easier13 extensible
bull Inheritance13 of13 a13 profile13 descriponbull Extend13 usage13 to13 signal13 the13 client13 profilebull Integraon13 with13 link13 format
Thank13 youQuesons
drar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval-shy‐00
Bert13 Greevenbosch
Descripon
bull The13 ldquoMinimumRequestInterval13 opon13 can13 be13 used13 to13 indicate13 the13 minimum13 me13 between13 two13 requests13 in13 a13 transacon
bull Originally13 intended13 for13 Block13 but13 also13 usable13 for13 other13 transaconsndash Example13 browsing13 a13 server
bull The13 goal13 is13 to13 reduce13 the13 server13 load13 and13 network13 traffic
bull Link13 hqpsdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval
Usage
bull The13 client13 keeps13 the13 server13 informed13 about13 its13 request13 speed13 through13 inclusion13 of13 the13 ldquoMinimumRequestIntervalrdquo13 opon
bull In13 responses13 the13 server13 fixes13 the13 minimum13 request13 interval13 through13 the13 same13 opon
bull The13 client13 obeys13 the13 speed13 indicated13 by13 the13 server
bull The13 client13 can13 send13 slower13 but13 not13 faster
Advantages
bull The13 server13 has13 means13 to13 limit13 the13 amount13 of13 incoming13 traffic
bull The13 server13 can13 prevent13 to13 become13 overloaded13 with13 too13 many13 tasks
bull The13 server13 does13 not13 need13 arficially13 slow13 down13 the13 client13 by13 sending13 late13 ACKsndash No13 need13 to13 keep13 track13 of13 delayed13 ACKsndash The13 server13 can13 perform13 other13 tasks13 instead
bull Reduced13 network13 traffic
Thank13 youQuesons
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-links-json-02txt
123
RFC 6690 (link-format) documents are somewhat foreign to many web app developerssect would prefer to have them in JSON format
There is no standard way to represent link-format documents in applicationssect but everyone knows how to handle JSON
Define a standard JSON translation for link-format
Itrsquos
not
rock
et
scien
ce
ltsensorsgtct=40title=Sensor Index ltsensorstempgtrt=temperature-cif=sensor ltsensorslightgtrt=light-luxif=sensor lthttpwwwexamplecomsensorst123gt anchor=sensorstemprel=describedby lttgtanchor=sensorstemprel=alternate [hrefsensorsct40titleSensor Index hrefsensorstemprttemperature-cifsensor hrefsensorslightrtlight-luxifsensor hrefhttpwwwexamplecomsensorst123 anchorsensorstempreldescribedby hreftanchorsensorstemprelalternate]
124
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-ipsec-for-coap-00txt
IPsec definitions for CoAP Mostly placeholder at this time Who has implementation experience with this
125
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-cross-reverse-convention-00txt
This draft has two lines of payload(based on a WGLC comment by Cullen Jennings)
coap12344567foobara=3
httpwwwproxycomwellknowncore-translate1234_4567foobara=3
Is that a useful convention to have
126
Insert CI slides here
127
128
0
5
10
15
20
25
30
35
40
10 20 30 40 50 60 70
good
put (
pps)
pps
Goodput vs pps (Econotags)
goodput
[Khattak preliminary]
Congestion Control
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-cocoa-00txt
ldquoadvancedrdquo cc (The draft is just a first shot) Others may have better ideas
129
Insert post-WGLC discussion slides here
130
Stop Continue Start
131
An Agile Retrospective
http6lowappnet coreIETF86 2013-03-12-13
Stop
132
Endless new CoAP optionssect instead use RESTful as much as possible
Move general security lifecycle out Looking at theoretical problems
http6lowappnet coreIETF86 2013-03-12-13
Continue
Interops Running code Look at real-world examples and deployments Solve their actual problems
sect Unilateral enhancements eg higher performance congestion control
sect Transports (SMS hellip)sect Make Web linking and Directories more and more usefulsect RESTful Design Paradigms for real-world problems
133
http6lowappnet coreIETF86 2013-03-12-13
Start
Further push into the (browser) web world (HTML5 browser security)
Specific supporting worksect SenMLsect URI work (dev URN hellip)sect Security Processes (next slide)
Spin outsect (We donrsquot really get to decide where this is done)
134
http6lowappnet coreIETF86 2013-03-12-13
Security
Integrate Application Network Group Keyingsect Tunnel-free setup
Donrsquot redo what has been done alreadysect ZigBee IP is finesect But what about other scenarios
Simple REST interfaces for working with keying materials and authorizationsect Start with defining objectives
Object Security for Constrained Nodes135
Re-chartering CoREWhat do we want to do now that wersquore grown up
Zach ShelbyCoRE WG IETF-86 Orlando
What is the scope
bull So we have a protocol and Web Linking what next
bull Keep with what we know besthellip1 Enhancements around CoAP2 New transports for CoAP3 New representations for Web Links4 General application layer solutions
CoRE WG IETF-86 Orlando 2
Enhancements around CoAP
bull Advanced congestion control
CoRE WG IETF-86 Orlando 3
New Transports for CoAP
bull Infrastructure for CoAP over foondash httptoolsietforgiddraft-silverajan-core-
coap-alternative-transports-01txtbull CoAP over SMS
ndash httptoolsietforgiddraft-becker-core-coap-sms-gprs-03txt
ndash OMA Lightweightbull CoAP over TCP
ndash httptoolsietforgiddraft-li-core-coap-payload-length-option-01txt
CoRE WG IETF-86 Orlando 4
New support for Web Links
bull JSON Web Linksndash httptoolsietforgiddraft-bormann-core-links-
json-02txt
2332010 CoRE WG IETF-77 Anaheim 5
General application layer solutions
bull Resource Directoryndash httptoolsietforgiddraft-shelby-core-
resource-directory-05txtndash OMA Lightweight
2332010 CoRE WG IETF-77 Anaheim 6
Overview of Performance Analysis Performed The analysis was broken up into a set of test scenarios Each test scenario used a different combination of the following
variables Client issued GET requests Server was configured as a sleepy or non-sleepy server Proxy caching of GET responses was enabled or disabled Proxy sleep-aware 503 response capability was enabled or disabled Proxy store-and-forward capability was enabled or disabled maxAge in GET responses ndash Two values were tested 60sec and 5sec of Clients ndash Two values were used ndash 1 client and 5 clients
For comparison purposes the following were held constant across all test scenarios Client issued a fixed number of requests (100) across all test scenarios Client used a delay between each GET request (35sec) to better exercise
proxyrsquos caching and sleep-awareness capabilities For sleepy server test scenarios the server slept 60 sec awake for 3 sec
Format of Results The following results were collected for each
test scenario
Breakdown of the and types of transactions occurring between clientproxyserver
ldquoGETrdquo ndash Test Scenario Results
GET ndash Description of Test Scenarios
TestScenarios-GET
Scenario
CoAPSleepyServerSe7ngs CoAPSleepAwareReverseProxySe7ngs CoAPClientSe7ngs
SleepDuragton(sec)
AwakeDuragton(sec)
maxAge(sec) Caching SleepAwareSAF+
503NumberofClients
NumberofGETs
DelayBetweenClient
Requests(sec)
1a 0 Always 60 Enabled Disabled 1 100 35
1b 60 3 60 Enabled Disabled 1 100 35
1c 60 3 60 Enabled Enabled 1 100 35
2a 0 Always 60 Enabled Disabled 5 100 35
2b 60 3 60 Enabled Disabled 5 100 35
2c 60 3 60 Enabled Enabled 5 100 35
3a 0 Always 5 Enabled Disabled 5 100 35
3b 60 3 5 Enabled Disabled 5 100 35
3c 60 3 5 Enabled Enabled 5 100 35
ldquoGETrdquo ndash Test Scenario 1 Results
maxAge = 60 and 1 Client
GET ndash Scenario 1 ClientProxy Interface Transaction Mix
Scenarios 1a - Non-Sleepy Server Caching Proxy maxAge = 60sec 1b- Sleepy Server Caching Proxy maxAge = 60sec 1c - Sleepy Server Sleep Aware Proxy maxAge = 60sec
Sleep Aware Proxy has better performance for sleepy servers
0
100
200
300
400
500
600
700
1a 1b 1c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
GET ndash Scenario 1 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
Scenarios 1a - Non-Sleepy Server Caching Proxy maxAge = 60sec 1b- Sleepy Server Caching Proxy maxAge = 60sec 1c - Sleepy Server Sleep Aware Proxy maxAge = 60sec
0
100
200
300
400
500
600
700
800
1a 1b 1c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
ldquoGETrdquo ndash Test Scenario 2 Results
maxAge = 60 and 5 Clients
GET ndash Scenario 2 ClientProxy Interface Transaction Mix
Sleep Aware Proxy has slightly better performance for sleepy servers
0
200
400
600
800
1000
1200
1400
2a 2b 2c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
Scenarios 2a - Non-Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2b- Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2c - Sleepy Server Sleep Aware Proxy maxAge = 60sec 5 Clients
See ldquoExperimental Artifactsrdquo Note 1
GET ndash Scenario 2 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has slightly better performance for sleepy servers
0
50
100
150
200
250
300
350
400
2a 2b 2c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
Scenarios 2a - Non-Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2b- Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2c - Sleepy Server Sleep Aware Proxy maxAge = 60sec 5 Clients
See ldquoExperimental Artifactsrdquo Note 2
Experimental Artifacts Note 1
Currently in the experiment the sleep aware proxy checks the cached state of a resource before putting a request into its Store-and-forward queue while a server is sleeping Once in the queue the proxy unconditionally forwards the queued requests to the server once it wakes up This is not the most efficient setup and can easily be improved If the proxy instead checks its cache again before forwarding each queued request it may not need to forward the request to the server For example if there are two queued GET requests in the proxyrsquos queue that address the same resource Only the first request needs to be sent to the server the second request can use the cached response from the first request
Note 2 Currently in the experiment the sleepy server sends a sleepState PUT request to the
proxy each time it goes to sleep This is not the most efficient setup and can easily be improved For example if the server assumes that the proxy can keep track of its ONOFF cycles with its internal timers (eg as per Fig 1 of I-D) then the number of messages from the sleepy server dramatically goes down
ldquoGETrdquo ndash Test Scenario 3 Results
maxAge = 5 and 5 Clients
GET ndash Scenario 3 ClientProxy Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
Scenarios 3a - Non-Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3b- Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3c - Sleepy Server Sleep Aware Proxy maxAge = 5sec 5 Clients
0
500
1000
1500
2000
2500
3000
3500
4000
4500
5000
3a 3b 3c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
GET ndash Scenario 3 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
0
1000
2000
3000
4000
5000
6000
7000
3a 3b 3c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
Scenarios 3a - Non-Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3b- Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3c - Sleepy Server Sleep Aware Proxy maxAge = 5sec 5 Clients
Conclusions
Conclusions These results show that sleep-aware CoAP
proxy features can significantly optimize communication with sleepy servers in most scenarios
These results also show that sleep-
awareness capabilities can provide additional benefits above and beyond CoAP caching in most scenarios
Backup
Current CoAP Support of Sleepy Node (12)
CoAP proxies can use a previously cached response to service a new GET request for a sleepy origin server (as in HTTP) But if no valid cache then proxy has to attempt to
retrieve and may fail if origin server is sleeping [I-Dietf-core-coap]
Clients can discover list of resources from RD (GET rd-lookuphellip) for sleepy servers But attempt to GET resource from sleepy origin server
may fail if origin server is sleeping [IDietf-core-link-format amp IDshelby-core-resource-
directory]
Current CoAP Support of Sleepy Node (22)
Lower layer support for sleepy nodes in most wireless technologies (eg WiFi ZigBee) But limited to MAC packet scheduling for sleepy nodes
and not aware of specific needs of IP applications (like CoAP)
Proposal ndash RD Based Sleep Tracking (14)
The current CoAP approach to support sleepy nodes can be significantly improved by introducing RD based mechanisms for a CoAP client to determine whether A targeted resource is located on a sleepy server A sleepy server is currently in sleep mode or not
There is any associated caching Proxy (possibly the RD itself) for a sleepy server
Proposal ndash RD Based Sleep Tracking (24)
We define the following new RD attributes to characterize the properties of a sleepy node SleepState - Indicates whether the node is currently in
sleep mode or not (ie Sleeping or Awake) SleepDuration - Indicates the maximum duration of time
that the node stays in sleep mode TimeSleeping - Indicates the length of time the node
has been sleeping (ie if Sleep State = Sleeping) NextSleep - Indicates the next time the node will go to
sleep (ie if Sleep State = Awake)
CachingProxy ndash Indicates the caching proxy of the sleepy node (ie the RD itself or another node)
Proposal ndash RD Based Sleep Tracking (34)
These attributes are all server (node) level and are new parameters added to the RD URI Template Variables
Finally we also define a new lookup-type (ss) for the RD lookup interface specified in [I-Dshelby-core-resource-directory] This new lookup-type supports looking up the
ldquoSleepStaterdquo (ss) of a specified end-point
Proposal ndash RD Based Sleep Tracking (44)
The three time based parameters (SleepDuration TimeSleeping NextSleep) can be based on either an absolute network time (for a time synchronized network) or a relative local time (measured at the local node)
Following the approach of [I-Dietf-core-link-format] and [I-Dshelby-core-resource-directory] sleep parameters for sleepy servers can be stored by the server in the RD and accessed by all interested clients
Examples of using these parameters in a synchronous or asynchronous manner are shown in the I-D
http6lowappnet coreIETF86 2013-03-12-13
We assume people have read the drafts
Meetings serve to advance difficult issues by making good use of face-to-face communications
Note Well Be aware of the IPR principles according to RFC 3979 and its updates
uumlBlue sheetsuumlScribe(s)
96
drar-shy‐iep-shy‐core-shy‐coapsubmiqed13 to13 IESG
2013-shy‐03-shy‐13
97
OMA Lightweight M2M Overview(A new standard using lots of IETF specs including DTLS
CoAP Block Observe Resource Directory SenMLhellip)
Zach ShelbyCoRE WG IETF-86 Orlando
OMA Lightweight M2Mbull Open Mobile Alliance is well known for Device Management (DM)bull OMA Lightweight M2M is a new standard from the alliance
ndash Focused on constrained Cellular and sensor network M2M devicesndash Driven by leading operators and vendors
bull Scopendash Interfaces protocol amp security between Device and Serverndash Object and Resource modelndash Bootstrap Device Access Control Connectivity and Firmware Objects
bull Draft Specifications are availablendash httpmemberopenmobileallianceorgftpPublic_documentsDM
LightweightM2MPermanent_documentsOMA-TS-LightweightM2M-V1_0_0-20130301-Dzip
bull Timelinendash Requirements and Architecture completed 3Q2012ndash Spec ready for Consistency Review 2Q2013ndash Candidate Approval expected 3Q2013
2 CoRE WG IETF-86 Orlando
Architecture
3
Scope of LWM2M
CoRE WG IETF-86 Orlando
Object Model
bull A Client has one or more Object Instancesbull An Object is a collection of Resourcesbull A Resource is an atomic piece of information
ndash Read Written or Executed
bull Resources can have multiple instancesbull Objects and Resources are identified by a
16-bit Integer Instances by an 8-bit Integerbull ObjectsResources are accessed with
simple URIs Object IDObject InstanceResource ID
eg 1213
4 CoRE WG IETF-86 Orlando
CoRE WG IETF-86 Orlando
CoRE Resource Directory
draft-shelby-core-resource-directory-05
Z Shelby C Bormann S Krco
Backgroundbull Not a new concept
ndash think web search engine or any link directorybull Defines the interfaces to a Resource Directorybull Based on Web Linking framework and the CoRE Link Formatbull Generic REST design for use over HTTP and CoAPbull Used by OMA Lightweight M2Mbull Has already been deployed
ndash In traffic monitoring systemsndash In street lighting systemsndash For vehicular asset trackingndash By a major Cellular M2M operator
Changes since -04
bull Restricted Update to parameter updatesbull Added pagination support for the Lookup interfacebull Changed rt= to et= for the registration amp update
interfacebull Added group support
Group Management
bull RD now includes group management featuresbull New Group Function Set
ndash Register a groupbull Group name domain multicast address endpoint members
ndash Remove a groupbull Group lookup using the Lookup Function Set
ndash List registered groupsndash Find the members of a groupndash Find groups with certain endpoints or resources
Registering a Group
EP RD
| |
| - POST rd-groupgp=lights ltgtep=node1 --gt |
| |
| |
| lt---- 201 Created Location rd-group12 ---- |
| |
Req POST coaprdexamplecomrd-groupgp=lights
Payload
ltgtep=node1
ltgtep=node2
Res 201 Created
Location rd-group12
Looking up Group Members
Client RD
| |
| ----- GET rd-lookupepgp=lights1 ----------------------gt |
| |
| |
| lt-- 205 Content ltrdgtd=domain1ltrdgtd=domain2 --------- |
| |
Req GET rd-lookupepgp=lights1
Res 205 Content
ltcoaphostportgtep=node1
ltcoaphostportgtep=node2rdquo
Things for the futurebull Support for JSON representation of Web Links
ndash httptoolsietforgiddraft-bormann-core-links-json-02txtbull Registry for RD registration query parameters
ndash Already OMA Lightweight has defined some new onesbull More examples
Group 3 ldquonew workrdquo(continued)
109
drar-shy‐greevenbosch-shy‐core-shy‐profile-shy‐descripon-shy‐01Bert13 GreevenboschJeroen13 Hoebeke
Isam13 IshaqFloris13 Van13 den13 Abeele
Descripon
bull JSON13 format13 for13 signalling13 the13 servers13 capabilies
bull Signalling13 of13 supported13 opons13 media13 types13 and13 block13 sizendash Other13 items13 can13 be13 added
bull Filtering13 on13 specific13 fields13 through13 URI-shy‐Querybull Link13 hqpdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐profile-shy‐descripon
well-shy‐knownprofile
bull To13 acquire13 profile13 data13 of13 resources13 on13 a13 parcular13 service13 the13 well-shy‐knownprofile13 URI-shy‐path13 is13 introduced
bull For13 example13 to13 get13 all13 informaon13 from13 sensors13 served13 by13 wwwexampleorg13 we13 can13 do13 a13 GET13 to13 coapwwwexampleorgwell-shy‐knownprofile
bull Filtering13 on13 parcular13 resources13 is13 done13 through13 URI-shy‐Queries
Format
bull Currently13 the13 following13 fields13 are13 definedndash ldquopathrdquo13 contains13 the13 URI-shy‐path13 associated13 with13 a13 resource
ndash ldquooprdquo13 a13 numerical13 list13 of13 supported13 opon13 numbers
ndash ldquocfrdquo13 a13 numerical13 list13 of13 supported13 content-shy‐format13 numbers
ndash ldquob1srdquo13 ldquob2srdquo13 supported13 block13 sizes13 for13 Block113 and13 Block213 respecvely
Examplebull On13 the13 right13 is13 an13 example13 of13 a13 camera13 sensor13 at13 coapwwwexampleorgcam13 that13 supports13 the13 Uri-shy‐Host13 (3)13 ETag13 (4)13 Uri-shy‐Port13 (7)13 Uri-shy‐Path13 (11)13 Content-shy‐Format13 (12)13 Token13 (19)13 Block213 (23)13 and13 Proxy-shy‐Uri13 (35)13 opons
bull The13 supported13 content13 formats13 are13 textplain13 (0)13 applicaon13 link-shy‐format13 (40)13 and13 applicaonjson13 (50)
bull The13 supported13 Block213 can13 use13 25613 or13 51213 byte13 blocks
Req13 GET13 coapwwwexampleorgwell-shy‐knownprofile13 Res13 20513 Content13 (applicationjson)13 13 13 13 profile13 13 13 13 13 13 13 13 pathcam13 13 13 13 op[3471112192335]13 13 13 13 13 cf[04050]13 13 13 13 13 b2s[45]13 13 13 13
Filtering13 through13 use13 of13 URI-shy‐Query
bull Filtering13 can13 be13 done13 through13 the13 URI-shy‐Querybull Query13 format13 N=V
ndash N13 is13 a13 profile13 fieldndash V13 is13 the13 desired13 value
bull Examplesndash To13 find13 resources13 that13 support13 content13 format13 ldquoapplicaonjsonrdquo
13 GET13 wwwexampleorgwell-shy‐knownprofilecf=50ndash To13 get13 informaon13 about13 the13 camera
13 GET13 wwwexampleorgwell-shy‐knownprofilepath=cam
Open13 issues
bull Which13 other13 profile13 data13 needs13 signallingndash Content-shy‐type13 for13 different13 methods
bull Fix13 the13 order13 in13 which13 the13 profile13 fields13 must13 appearndash Non-shy‐fixed13 order13 easier13 extensible
bull Inheritance13 of13 a13 profile13 descriponbull Extend13 usage13 to13 signal13 the13 client13 profilebull Integraon13 with13 link13 format
Thank13 youQuesons
drar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval-shy‐00
Bert13 Greevenbosch
Descripon
bull The13 ldquoMinimumRequestInterval13 opon13 can13 be13 used13 to13 indicate13 the13 minimum13 me13 between13 two13 requests13 in13 a13 transacon
bull Originally13 intended13 for13 Block13 but13 also13 usable13 for13 other13 transaconsndash Example13 browsing13 a13 server
bull The13 goal13 is13 to13 reduce13 the13 server13 load13 and13 network13 traffic
bull Link13 hqpsdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval
Usage
bull The13 client13 keeps13 the13 server13 informed13 about13 its13 request13 speed13 through13 inclusion13 of13 the13 ldquoMinimumRequestIntervalrdquo13 opon
bull In13 responses13 the13 server13 fixes13 the13 minimum13 request13 interval13 through13 the13 same13 opon
bull The13 client13 obeys13 the13 speed13 indicated13 by13 the13 server
bull The13 client13 can13 send13 slower13 but13 not13 faster
Advantages
bull The13 server13 has13 means13 to13 limit13 the13 amount13 of13 incoming13 traffic
bull The13 server13 can13 prevent13 to13 become13 overloaded13 with13 too13 many13 tasks
bull The13 server13 does13 not13 need13 arficially13 slow13 down13 the13 client13 by13 sending13 late13 ACKsndash No13 need13 to13 keep13 track13 of13 delayed13 ACKsndash The13 server13 can13 perform13 other13 tasks13 instead
bull Reduced13 network13 traffic
Thank13 youQuesons
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-links-json-02txt
123
RFC 6690 (link-format) documents are somewhat foreign to many web app developerssect would prefer to have them in JSON format
There is no standard way to represent link-format documents in applicationssect but everyone knows how to handle JSON
Define a standard JSON translation for link-format
Itrsquos
not
rock
et
scien
ce
ltsensorsgtct=40title=Sensor Index ltsensorstempgtrt=temperature-cif=sensor ltsensorslightgtrt=light-luxif=sensor lthttpwwwexamplecomsensorst123gt anchor=sensorstemprel=describedby lttgtanchor=sensorstemprel=alternate [hrefsensorsct40titleSensor Index hrefsensorstemprttemperature-cifsensor hrefsensorslightrtlight-luxifsensor hrefhttpwwwexamplecomsensorst123 anchorsensorstempreldescribedby hreftanchorsensorstemprelalternate]
124
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-ipsec-for-coap-00txt
IPsec definitions for CoAP Mostly placeholder at this time Who has implementation experience with this
125
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-cross-reverse-convention-00txt
This draft has two lines of payload(based on a WGLC comment by Cullen Jennings)
coap12344567foobara=3
httpwwwproxycomwellknowncore-translate1234_4567foobara=3
Is that a useful convention to have
126
Insert CI slides here
127
128
0
5
10
15
20
25
30
35
40
10 20 30 40 50 60 70
good
put (
pps)
pps
Goodput vs pps (Econotags)
goodput
[Khattak preliminary]
Congestion Control
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-cocoa-00txt
ldquoadvancedrdquo cc (The draft is just a first shot) Others may have better ideas
129
Insert post-WGLC discussion slides here
130
Stop Continue Start
131
An Agile Retrospective
http6lowappnet coreIETF86 2013-03-12-13
Stop
132
Endless new CoAP optionssect instead use RESTful as much as possible
Move general security lifecycle out Looking at theoretical problems
http6lowappnet coreIETF86 2013-03-12-13
Continue
Interops Running code Look at real-world examples and deployments Solve their actual problems
sect Unilateral enhancements eg higher performance congestion control
sect Transports (SMS hellip)sect Make Web linking and Directories more and more usefulsect RESTful Design Paradigms for real-world problems
133
http6lowappnet coreIETF86 2013-03-12-13
Start
Further push into the (browser) web world (HTML5 browser security)
Specific supporting worksect SenMLsect URI work (dev URN hellip)sect Security Processes (next slide)
Spin outsect (We donrsquot really get to decide where this is done)
134
http6lowappnet coreIETF86 2013-03-12-13
Security
Integrate Application Network Group Keyingsect Tunnel-free setup
Donrsquot redo what has been done alreadysect ZigBee IP is finesect But what about other scenarios
Simple REST interfaces for working with keying materials and authorizationsect Start with defining objectives
Object Security for Constrained Nodes135
Re-chartering CoREWhat do we want to do now that wersquore grown up
Zach ShelbyCoRE WG IETF-86 Orlando
What is the scope
bull So we have a protocol and Web Linking what next
bull Keep with what we know besthellip1 Enhancements around CoAP2 New transports for CoAP3 New representations for Web Links4 General application layer solutions
CoRE WG IETF-86 Orlando 2
Enhancements around CoAP
bull Advanced congestion control
CoRE WG IETF-86 Orlando 3
New Transports for CoAP
bull Infrastructure for CoAP over foondash httptoolsietforgiddraft-silverajan-core-
coap-alternative-transports-01txtbull CoAP over SMS
ndash httptoolsietforgiddraft-becker-core-coap-sms-gprs-03txt
ndash OMA Lightweightbull CoAP over TCP
ndash httptoolsietforgiddraft-li-core-coap-payload-length-option-01txt
CoRE WG IETF-86 Orlando 4
New support for Web Links
bull JSON Web Linksndash httptoolsietforgiddraft-bormann-core-links-
json-02txt
2332010 CoRE WG IETF-77 Anaheim 5
General application layer solutions
bull Resource Directoryndash httptoolsietforgiddraft-shelby-core-
resource-directory-05txtndash OMA Lightweight
2332010 CoRE WG IETF-77 Anaheim 6
Format of Results The following results were collected for each
test scenario
Breakdown of the and types of transactions occurring between clientproxyserver
ldquoGETrdquo ndash Test Scenario Results
GET ndash Description of Test Scenarios
TestScenarios-GET
Scenario
CoAPSleepyServerSe7ngs CoAPSleepAwareReverseProxySe7ngs CoAPClientSe7ngs
SleepDuragton(sec)
AwakeDuragton(sec)
maxAge(sec) Caching SleepAwareSAF+
503NumberofClients
NumberofGETs
DelayBetweenClient
Requests(sec)
1a 0 Always 60 Enabled Disabled 1 100 35
1b 60 3 60 Enabled Disabled 1 100 35
1c 60 3 60 Enabled Enabled 1 100 35
2a 0 Always 60 Enabled Disabled 5 100 35
2b 60 3 60 Enabled Disabled 5 100 35
2c 60 3 60 Enabled Enabled 5 100 35
3a 0 Always 5 Enabled Disabled 5 100 35
3b 60 3 5 Enabled Disabled 5 100 35
3c 60 3 5 Enabled Enabled 5 100 35
ldquoGETrdquo ndash Test Scenario 1 Results
maxAge = 60 and 1 Client
GET ndash Scenario 1 ClientProxy Interface Transaction Mix
Scenarios 1a - Non-Sleepy Server Caching Proxy maxAge = 60sec 1b- Sleepy Server Caching Proxy maxAge = 60sec 1c - Sleepy Server Sleep Aware Proxy maxAge = 60sec
Sleep Aware Proxy has better performance for sleepy servers
0
100
200
300
400
500
600
700
1a 1b 1c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
GET ndash Scenario 1 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
Scenarios 1a - Non-Sleepy Server Caching Proxy maxAge = 60sec 1b- Sleepy Server Caching Proxy maxAge = 60sec 1c - Sleepy Server Sleep Aware Proxy maxAge = 60sec
0
100
200
300
400
500
600
700
800
1a 1b 1c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
ldquoGETrdquo ndash Test Scenario 2 Results
maxAge = 60 and 5 Clients
GET ndash Scenario 2 ClientProxy Interface Transaction Mix
Sleep Aware Proxy has slightly better performance for sleepy servers
0
200
400
600
800
1000
1200
1400
2a 2b 2c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
Scenarios 2a - Non-Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2b- Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2c - Sleepy Server Sleep Aware Proxy maxAge = 60sec 5 Clients
See ldquoExperimental Artifactsrdquo Note 1
GET ndash Scenario 2 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has slightly better performance for sleepy servers
0
50
100
150
200
250
300
350
400
2a 2b 2c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
Scenarios 2a - Non-Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2b- Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2c - Sleepy Server Sleep Aware Proxy maxAge = 60sec 5 Clients
See ldquoExperimental Artifactsrdquo Note 2
Experimental Artifacts Note 1
Currently in the experiment the sleep aware proxy checks the cached state of a resource before putting a request into its Store-and-forward queue while a server is sleeping Once in the queue the proxy unconditionally forwards the queued requests to the server once it wakes up This is not the most efficient setup and can easily be improved If the proxy instead checks its cache again before forwarding each queued request it may not need to forward the request to the server For example if there are two queued GET requests in the proxyrsquos queue that address the same resource Only the first request needs to be sent to the server the second request can use the cached response from the first request
Note 2 Currently in the experiment the sleepy server sends a sleepState PUT request to the
proxy each time it goes to sleep This is not the most efficient setup and can easily be improved For example if the server assumes that the proxy can keep track of its ONOFF cycles with its internal timers (eg as per Fig 1 of I-D) then the number of messages from the sleepy server dramatically goes down
ldquoGETrdquo ndash Test Scenario 3 Results
maxAge = 5 and 5 Clients
GET ndash Scenario 3 ClientProxy Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
Scenarios 3a - Non-Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3b- Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3c - Sleepy Server Sleep Aware Proxy maxAge = 5sec 5 Clients
0
500
1000
1500
2000
2500
3000
3500
4000
4500
5000
3a 3b 3c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
GET ndash Scenario 3 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
0
1000
2000
3000
4000
5000
6000
7000
3a 3b 3c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
Scenarios 3a - Non-Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3b- Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3c - Sleepy Server Sleep Aware Proxy maxAge = 5sec 5 Clients
Conclusions
Conclusions These results show that sleep-aware CoAP
proxy features can significantly optimize communication with sleepy servers in most scenarios
These results also show that sleep-
awareness capabilities can provide additional benefits above and beyond CoAP caching in most scenarios
Backup
Current CoAP Support of Sleepy Node (12)
CoAP proxies can use a previously cached response to service a new GET request for a sleepy origin server (as in HTTP) But if no valid cache then proxy has to attempt to
retrieve and may fail if origin server is sleeping [I-Dietf-core-coap]
Clients can discover list of resources from RD (GET rd-lookuphellip) for sleepy servers But attempt to GET resource from sleepy origin server
may fail if origin server is sleeping [IDietf-core-link-format amp IDshelby-core-resource-
directory]
Current CoAP Support of Sleepy Node (22)
Lower layer support for sleepy nodes in most wireless technologies (eg WiFi ZigBee) But limited to MAC packet scheduling for sleepy nodes
and not aware of specific needs of IP applications (like CoAP)
Proposal ndash RD Based Sleep Tracking (14)
The current CoAP approach to support sleepy nodes can be significantly improved by introducing RD based mechanisms for a CoAP client to determine whether A targeted resource is located on a sleepy server A sleepy server is currently in sleep mode or not
There is any associated caching Proxy (possibly the RD itself) for a sleepy server
Proposal ndash RD Based Sleep Tracking (24)
We define the following new RD attributes to characterize the properties of a sleepy node SleepState - Indicates whether the node is currently in
sleep mode or not (ie Sleeping or Awake) SleepDuration - Indicates the maximum duration of time
that the node stays in sleep mode TimeSleeping - Indicates the length of time the node
has been sleeping (ie if Sleep State = Sleeping) NextSleep - Indicates the next time the node will go to
sleep (ie if Sleep State = Awake)
CachingProxy ndash Indicates the caching proxy of the sleepy node (ie the RD itself or another node)
Proposal ndash RD Based Sleep Tracking (34)
These attributes are all server (node) level and are new parameters added to the RD URI Template Variables
Finally we also define a new lookup-type (ss) for the RD lookup interface specified in [I-Dshelby-core-resource-directory] This new lookup-type supports looking up the
ldquoSleepStaterdquo (ss) of a specified end-point
Proposal ndash RD Based Sleep Tracking (44)
The three time based parameters (SleepDuration TimeSleeping NextSleep) can be based on either an absolute network time (for a time synchronized network) or a relative local time (measured at the local node)
Following the approach of [I-Dietf-core-link-format] and [I-Dshelby-core-resource-directory] sleep parameters for sleepy servers can be stored by the server in the RD and accessed by all interested clients
Examples of using these parameters in a synchronous or asynchronous manner are shown in the I-D
http6lowappnet coreIETF86 2013-03-12-13
We assume people have read the drafts
Meetings serve to advance difficult issues by making good use of face-to-face communications
Note Well Be aware of the IPR principles according to RFC 3979 and its updates
uumlBlue sheetsuumlScribe(s)
96
drar-shy‐iep-shy‐core-shy‐coapsubmiqed13 to13 IESG
2013-shy‐03-shy‐13
97
OMA Lightweight M2M Overview(A new standard using lots of IETF specs including DTLS
CoAP Block Observe Resource Directory SenMLhellip)
Zach ShelbyCoRE WG IETF-86 Orlando
OMA Lightweight M2Mbull Open Mobile Alliance is well known for Device Management (DM)bull OMA Lightweight M2M is a new standard from the alliance
ndash Focused on constrained Cellular and sensor network M2M devicesndash Driven by leading operators and vendors
bull Scopendash Interfaces protocol amp security between Device and Serverndash Object and Resource modelndash Bootstrap Device Access Control Connectivity and Firmware Objects
bull Draft Specifications are availablendash httpmemberopenmobileallianceorgftpPublic_documentsDM
LightweightM2MPermanent_documentsOMA-TS-LightweightM2M-V1_0_0-20130301-Dzip
bull Timelinendash Requirements and Architecture completed 3Q2012ndash Spec ready for Consistency Review 2Q2013ndash Candidate Approval expected 3Q2013
2 CoRE WG IETF-86 Orlando
Architecture
3
Scope of LWM2M
CoRE WG IETF-86 Orlando
Object Model
bull A Client has one or more Object Instancesbull An Object is a collection of Resourcesbull A Resource is an atomic piece of information
ndash Read Written or Executed
bull Resources can have multiple instancesbull Objects and Resources are identified by a
16-bit Integer Instances by an 8-bit Integerbull ObjectsResources are accessed with
simple URIs Object IDObject InstanceResource ID
eg 1213
4 CoRE WG IETF-86 Orlando
CoRE WG IETF-86 Orlando
CoRE Resource Directory
draft-shelby-core-resource-directory-05
Z Shelby C Bormann S Krco
Backgroundbull Not a new concept
ndash think web search engine or any link directorybull Defines the interfaces to a Resource Directorybull Based on Web Linking framework and the CoRE Link Formatbull Generic REST design for use over HTTP and CoAPbull Used by OMA Lightweight M2Mbull Has already been deployed
ndash In traffic monitoring systemsndash In street lighting systemsndash For vehicular asset trackingndash By a major Cellular M2M operator
Changes since -04
bull Restricted Update to parameter updatesbull Added pagination support for the Lookup interfacebull Changed rt= to et= for the registration amp update
interfacebull Added group support
Group Management
bull RD now includes group management featuresbull New Group Function Set
ndash Register a groupbull Group name domain multicast address endpoint members
ndash Remove a groupbull Group lookup using the Lookup Function Set
ndash List registered groupsndash Find the members of a groupndash Find groups with certain endpoints or resources
Registering a Group
EP RD
| |
| - POST rd-groupgp=lights ltgtep=node1 --gt |
| |
| |
| lt---- 201 Created Location rd-group12 ---- |
| |
Req POST coaprdexamplecomrd-groupgp=lights
Payload
ltgtep=node1
ltgtep=node2
Res 201 Created
Location rd-group12
Looking up Group Members
Client RD
| |
| ----- GET rd-lookupepgp=lights1 ----------------------gt |
| |
| |
| lt-- 205 Content ltrdgtd=domain1ltrdgtd=domain2 --------- |
| |
Req GET rd-lookupepgp=lights1
Res 205 Content
ltcoaphostportgtep=node1
ltcoaphostportgtep=node2rdquo
Things for the futurebull Support for JSON representation of Web Links
ndash httptoolsietforgiddraft-bormann-core-links-json-02txtbull Registry for RD registration query parameters
ndash Already OMA Lightweight has defined some new onesbull More examples
Group 3 ldquonew workrdquo(continued)
109
drar-shy‐greevenbosch-shy‐core-shy‐profile-shy‐descripon-shy‐01Bert13 GreevenboschJeroen13 Hoebeke
Isam13 IshaqFloris13 Van13 den13 Abeele
Descripon
bull JSON13 format13 for13 signalling13 the13 servers13 capabilies
bull Signalling13 of13 supported13 opons13 media13 types13 and13 block13 sizendash Other13 items13 can13 be13 added
bull Filtering13 on13 specific13 fields13 through13 URI-shy‐Querybull Link13 hqpdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐profile-shy‐descripon
well-shy‐knownprofile
bull To13 acquire13 profile13 data13 of13 resources13 on13 a13 parcular13 service13 the13 well-shy‐knownprofile13 URI-shy‐path13 is13 introduced
bull For13 example13 to13 get13 all13 informaon13 from13 sensors13 served13 by13 wwwexampleorg13 we13 can13 do13 a13 GET13 to13 coapwwwexampleorgwell-shy‐knownprofile
bull Filtering13 on13 parcular13 resources13 is13 done13 through13 URI-shy‐Queries
Format
bull Currently13 the13 following13 fields13 are13 definedndash ldquopathrdquo13 contains13 the13 URI-shy‐path13 associated13 with13 a13 resource
ndash ldquooprdquo13 a13 numerical13 list13 of13 supported13 opon13 numbers
ndash ldquocfrdquo13 a13 numerical13 list13 of13 supported13 content-shy‐format13 numbers
ndash ldquob1srdquo13 ldquob2srdquo13 supported13 block13 sizes13 for13 Block113 and13 Block213 respecvely
Examplebull On13 the13 right13 is13 an13 example13 of13 a13 camera13 sensor13 at13 coapwwwexampleorgcam13 that13 supports13 the13 Uri-shy‐Host13 (3)13 ETag13 (4)13 Uri-shy‐Port13 (7)13 Uri-shy‐Path13 (11)13 Content-shy‐Format13 (12)13 Token13 (19)13 Block213 (23)13 and13 Proxy-shy‐Uri13 (35)13 opons
bull The13 supported13 content13 formats13 are13 textplain13 (0)13 applicaon13 link-shy‐format13 (40)13 and13 applicaonjson13 (50)
bull The13 supported13 Block213 can13 use13 25613 or13 51213 byte13 blocks
Req13 GET13 coapwwwexampleorgwell-shy‐knownprofile13 Res13 20513 Content13 (applicationjson)13 13 13 13 profile13 13 13 13 13 13 13 13 pathcam13 13 13 13 op[3471112192335]13 13 13 13 13 cf[04050]13 13 13 13 13 b2s[45]13 13 13 13
Filtering13 through13 use13 of13 URI-shy‐Query
bull Filtering13 can13 be13 done13 through13 the13 URI-shy‐Querybull Query13 format13 N=V
ndash N13 is13 a13 profile13 fieldndash V13 is13 the13 desired13 value
bull Examplesndash To13 find13 resources13 that13 support13 content13 format13 ldquoapplicaonjsonrdquo
13 GET13 wwwexampleorgwell-shy‐knownprofilecf=50ndash To13 get13 informaon13 about13 the13 camera
13 GET13 wwwexampleorgwell-shy‐knownprofilepath=cam
Open13 issues
bull Which13 other13 profile13 data13 needs13 signallingndash Content-shy‐type13 for13 different13 methods
bull Fix13 the13 order13 in13 which13 the13 profile13 fields13 must13 appearndash Non-shy‐fixed13 order13 easier13 extensible
bull Inheritance13 of13 a13 profile13 descriponbull Extend13 usage13 to13 signal13 the13 client13 profilebull Integraon13 with13 link13 format
Thank13 youQuesons
drar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval-shy‐00
Bert13 Greevenbosch
Descripon
bull The13 ldquoMinimumRequestInterval13 opon13 can13 be13 used13 to13 indicate13 the13 minimum13 me13 between13 two13 requests13 in13 a13 transacon
bull Originally13 intended13 for13 Block13 but13 also13 usable13 for13 other13 transaconsndash Example13 browsing13 a13 server
bull The13 goal13 is13 to13 reduce13 the13 server13 load13 and13 network13 traffic
bull Link13 hqpsdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval
Usage
bull The13 client13 keeps13 the13 server13 informed13 about13 its13 request13 speed13 through13 inclusion13 of13 the13 ldquoMinimumRequestIntervalrdquo13 opon
bull In13 responses13 the13 server13 fixes13 the13 minimum13 request13 interval13 through13 the13 same13 opon
bull The13 client13 obeys13 the13 speed13 indicated13 by13 the13 server
bull The13 client13 can13 send13 slower13 but13 not13 faster
Advantages
bull The13 server13 has13 means13 to13 limit13 the13 amount13 of13 incoming13 traffic
bull The13 server13 can13 prevent13 to13 become13 overloaded13 with13 too13 many13 tasks
bull The13 server13 does13 not13 need13 arficially13 slow13 down13 the13 client13 by13 sending13 late13 ACKsndash No13 need13 to13 keep13 track13 of13 delayed13 ACKsndash The13 server13 can13 perform13 other13 tasks13 instead
bull Reduced13 network13 traffic
Thank13 youQuesons
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-links-json-02txt
123
RFC 6690 (link-format) documents are somewhat foreign to many web app developerssect would prefer to have them in JSON format
There is no standard way to represent link-format documents in applicationssect but everyone knows how to handle JSON
Define a standard JSON translation for link-format
Itrsquos
not
rock
et
scien
ce
ltsensorsgtct=40title=Sensor Index ltsensorstempgtrt=temperature-cif=sensor ltsensorslightgtrt=light-luxif=sensor lthttpwwwexamplecomsensorst123gt anchor=sensorstemprel=describedby lttgtanchor=sensorstemprel=alternate [hrefsensorsct40titleSensor Index hrefsensorstemprttemperature-cifsensor hrefsensorslightrtlight-luxifsensor hrefhttpwwwexamplecomsensorst123 anchorsensorstempreldescribedby hreftanchorsensorstemprelalternate]
124
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-ipsec-for-coap-00txt
IPsec definitions for CoAP Mostly placeholder at this time Who has implementation experience with this
125
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-cross-reverse-convention-00txt
This draft has two lines of payload(based on a WGLC comment by Cullen Jennings)
coap12344567foobara=3
httpwwwproxycomwellknowncore-translate1234_4567foobara=3
Is that a useful convention to have
126
Insert CI slides here
127
128
0
5
10
15
20
25
30
35
40
10 20 30 40 50 60 70
good
put (
pps)
pps
Goodput vs pps (Econotags)
goodput
[Khattak preliminary]
Congestion Control
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-cocoa-00txt
ldquoadvancedrdquo cc (The draft is just a first shot) Others may have better ideas
129
Insert post-WGLC discussion slides here
130
Stop Continue Start
131
An Agile Retrospective
http6lowappnet coreIETF86 2013-03-12-13
Stop
132
Endless new CoAP optionssect instead use RESTful as much as possible
Move general security lifecycle out Looking at theoretical problems
http6lowappnet coreIETF86 2013-03-12-13
Continue
Interops Running code Look at real-world examples and deployments Solve their actual problems
sect Unilateral enhancements eg higher performance congestion control
sect Transports (SMS hellip)sect Make Web linking and Directories more and more usefulsect RESTful Design Paradigms for real-world problems
133
http6lowappnet coreIETF86 2013-03-12-13
Start
Further push into the (browser) web world (HTML5 browser security)
Specific supporting worksect SenMLsect URI work (dev URN hellip)sect Security Processes (next slide)
Spin outsect (We donrsquot really get to decide where this is done)
134
http6lowappnet coreIETF86 2013-03-12-13
Security
Integrate Application Network Group Keyingsect Tunnel-free setup
Donrsquot redo what has been done alreadysect ZigBee IP is finesect But what about other scenarios
Simple REST interfaces for working with keying materials and authorizationsect Start with defining objectives
Object Security for Constrained Nodes135
Re-chartering CoREWhat do we want to do now that wersquore grown up
Zach ShelbyCoRE WG IETF-86 Orlando
What is the scope
bull So we have a protocol and Web Linking what next
bull Keep with what we know besthellip1 Enhancements around CoAP2 New transports for CoAP3 New representations for Web Links4 General application layer solutions
CoRE WG IETF-86 Orlando 2
Enhancements around CoAP
bull Advanced congestion control
CoRE WG IETF-86 Orlando 3
New Transports for CoAP
bull Infrastructure for CoAP over foondash httptoolsietforgiddraft-silverajan-core-
coap-alternative-transports-01txtbull CoAP over SMS
ndash httptoolsietforgiddraft-becker-core-coap-sms-gprs-03txt
ndash OMA Lightweightbull CoAP over TCP
ndash httptoolsietforgiddraft-li-core-coap-payload-length-option-01txt
CoRE WG IETF-86 Orlando 4
New support for Web Links
bull JSON Web Linksndash httptoolsietforgiddraft-bormann-core-links-
json-02txt
2332010 CoRE WG IETF-77 Anaheim 5
General application layer solutions
bull Resource Directoryndash httptoolsietforgiddraft-shelby-core-
resource-directory-05txtndash OMA Lightweight
2332010 CoRE WG IETF-77 Anaheim 6
ldquoGETrdquo ndash Test Scenario Results
GET ndash Description of Test Scenarios
TestScenarios-GET
Scenario
CoAPSleepyServerSe7ngs CoAPSleepAwareReverseProxySe7ngs CoAPClientSe7ngs
SleepDuragton(sec)
AwakeDuragton(sec)
maxAge(sec) Caching SleepAwareSAF+
503NumberofClients
NumberofGETs
DelayBetweenClient
Requests(sec)
1a 0 Always 60 Enabled Disabled 1 100 35
1b 60 3 60 Enabled Disabled 1 100 35
1c 60 3 60 Enabled Enabled 1 100 35
2a 0 Always 60 Enabled Disabled 5 100 35
2b 60 3 60 Enabled Disabled 5 100 35
2c 60 3 60 Enabled Enabled 5 100 35
3a 0 Always 5 Enabled Disabled 5 100 35
3b 60 3 5 Enabled Disabled 5 100 35
3c 60 3 5 Enabled Enabled 5 100 35
ldquoGETrdquo ndash Test Scenario 1 Results
maxAge = 60 and 1 Client
GET ndash Scenario 1 ClientProxy Interface Transaction Mix
Scenarios 1a - Non-Sleepy Server Caching Proxy maxAge = 60sec 1b- Sleepy Server Caching Proxy maxAge = 60sec 1c - Sleepy Server Sleep Aware Proxy maxAge = 60sec
Sleep Aware Proxy has better performance for sleepy servers
0
100
200
300
400
500
600
700
1a 1b 1c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
GET ndash Scenario 1 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
Scenarios 1a - Non-Sleepy Server Caching Proxy maxAge = 60sec 1b- Sleepy Server Caching Proxy maxAge = 60sec 1c - Sleepy Server Sleep Aware Proxy maxAge = 60sec
0
100
200
300
400
500
600
700
800
1a 1b 1c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
ldquoGETrdquo ndash Test Scenario 2 Results
maxAge = 60 and 5 Clients
GET ndash Scenario 2 ClientProxy Interface Transaction Mix
Sleep Aware Proxy has slightly better performance for sleepy servers
0
200
400
600
800
1000
1200
1400
2a 2b 2c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
Scenarios 2a - Non-Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2b- Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2c - Sleepy Server Sleep Aware Proxy maxAge = 60sec 5 Clients
See ldquoExperimental Artifactsrdquo Note 1
GET ndash Scenario 2 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has slightly better performance for sleepy servers
0
50
100
150
200
250
300
350
400
2a 2b 2c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
Scenarios 2a - Non-Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2b- Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2c - Sleepy Server Sleep Aware Proxy maxAge = 60sec 5 Clients
See ldquoExperimental Artifactsrdquo Note 2
Experimental Artifacts Note 1
Currently in the experiment the sleep aware proxy checks the cached state of a resource before putting a request into its Store-and-forward queue while a server is sleeping Once in the queue the proxy unconditionally forwards the queued requests to the server once it wakes up This is not the most efficient setup and can easily be improved If the proxy instead checks its cache again before forwarding each queued request it may not need to forward the request to the server For example if there are two queued GET requests in the proxyrsquos queue that address the same resource Only the first request needs to be sent to the server the second request can use the cached response from the first request
Note 2 Currently in the experiment the sleepy server sends a sleepState PUT request to the
proxy each time it goes to sleep This is not the most efficient setup and can easily be improved For example if the server assumes that the proxy can keep track of its ONOFF cycles with its internal timers (eg as per Fig 1 of I-D) then the number of messages from the sleepy server dramatically goes down
ldquoGETrdquo ndash Test Scenario 3 Results
maxAge = 5 and 5 Clients
GET ndash Scenario 3 ClientProxy Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
Scenarios 3a - Non-Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3b- Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3c - Sleepy Server Sleep Aware Proxy maxAge = 5sec 5 Clients
0
500
1000
1500
2000
2500
3000
3500
4000
4500
5000
3a 3b 3c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
GET ndash Scenario 3 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
0
1000
2000
3000
4000
5000
6000
7000
3a 3b 3c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
Scenarios 3a - Non-Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3b- Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3c - Sleepy Server Sleep Aware Proxy maxAge = 5sec 5 Clients
Conclusions
Conclusions These results show that sleep-aware CoAP
proxy features can significantly optimize communication with sleepy servers in most scenarios
These results also show that sleep-
awareness capabilities can provide additional benefits above and beyond CoAP caching in most scenarios
Backup
Current CoAP Support of Sleepy Node (12)
CoAP proxies can use a previously cached response to service a new GET request for a sleepy origin server (as in HTTP) But if no valid cache then proxy has to attempt to
retrieve and may fail if origin server is sleeping [I-Dietf-core-coap]
Clients can discover list of resources from RD (GET rd-lookuphellip) for sleepy servers But attempt to GET resource from sleepy origin server
may fail if origin server is sleeping [IDietf-core-link-format amp IDshelby-core-resource-
directory]
Current CoAP Support of Sleepy Node (22)
Lower layer support for sleepy nodes in most wireless technologies (eg WiFi ZigBee) But limited to MAC packet scheduling for sleepy nodes
and not aware of specific needs of IP applications (like CoAP)
Proposal ndash RD Based Sleep Tracking (14)
The current CoAP approach to support sleepy nodes can be significantly improved by introducing RD based mechanisms for a CoAP client to determine whether A targeted resource is located on a sleepy server A sleepy server is currently in sleep mode or not
There is any associated caching Proxy (possibly the RD itself) for a sleepy server
Proposal ndash RD Based Sleep Tracking (24)
We define the following new RD attributes to characterize the properties of a sleepy node SleepState - Indicates whether the node is currently in
sleep mode or not (ie Sleeping or Awake) SleepDuration - Indicates the maximum duration of time
that the node stays in sleep mode TimeSleeping - Indicates the length of time the node
has been sleeping (ie if Sleep State = Sleeping) NextSleep - Indicates the next time the node will go to
sleep (ie if Sleep State = Awake)
CachingProxy ndash Indicates the caching proxy of the sleepy node (ie the RD itself or another node)
Proposal ndash RD Based Sleep Tracking (34)
These attributes are all server (node) level and are new parameters added to the RD URI Template Variables
Finally we also define a new lookup-type (ss) for the RD lookup interface specified in [I-Dshelby-core-resource-directory] This new lookup-type supports looking up the
ldquoSleepStaterdquo (ss) of a specified end-point
Proposal ndash RD Based Sleep Tracking (44)
The three time based parameters (SleepDuration TimeSleeping NextSleep) can be based on either an absolute network time (for a time synchronized network) or a relative local time (measured at the local node)
Following the approach of [I-Dietf-core-link-format] and [I-Dshelby-core-resource-directory] sleep parameters for sleepy servers can be stored by the server in the RD and accessed by all interested clients
Examples of using these parameters in a synchronous or asynchronous manner are shown in the I-D
http6lowappnet coreIETF86 2013-03-12-13
We assume people have read the drafts
Meetings serve to advance difficult issues by making good use of face-to-face communications
Note Well Be aware of the IPR principles according to RFC 3979 and its updates
uumlBlue sheetsuumlScribe(s)
96
drar-shy‐iep-shy‐core-shy‐coapsubmiqed13 to13 IESG
2013-shy‐03-shy‐13
97
OMA Lightweight M2M Overview(A new standard using lots of IETF specs including DTLS
CoAP Block Observe Resource Directory SenMLhellip)
Zach ShelbyCoRE WG IETF-86 Orlando
OMA Lightweight M2Mbull Open Mobile Alliance is well known for Device Management (DM)bull OMA Lightweight M2M is a new standard from the alliance
ndash Focused on constrained Cellular and sensor network M2M devicesndash Driven by leading operators and vendors
bull Scopendash Interfaces protocol amp security between Device and Serverndash Object and Resource modelndash Bootstrap Device Access Control Connectivity and Firmware Objects
bull Draft Specifications are availablendash httpmemberopenmobileallianceorgftpPublic_documentsDM
LightweightM2MPermanent_documentsOMA-TS-LightweightM2M-V1_0_0-20130301-Dzip
bull Timelinendash Requirements and Architecture completed 3Q2012ndash Spec ready for Consistency Review 2Q2013ndash Candidate Approval expected 3Q2013
2 CoRE WG IETF-86 Orlando
Architecture
3
Scope of LWM2M
CoRE WG IETF-86 Orlando
Object Model
bull A Client has one or more Object Instancesbull An Object is a collection of Resourcesbull A Resource is an atomic piece of information
ndash Read Written or Executed
bull Resources can have multiple instancesbull Objects and Resources are identified by a
16-bit Integer Instances by an 8-bit Integerbull ObjectsResources are accessed with
simple URIs Object IDObject InstanceResource ID
eg 1213
4 CoRE WG IETF-86 Orlando
CoRE WG IETF-86 Orlando
CoRE Resource Directory
draft-shelby-core-resource-directory-05
Z Shelby C Bormann S Krco
Backgroundbull Not a new concept
ndash think web search engine or any link directorybull Defines the interfaces to a Resource Directorybull Based on Web Linking framework and the CoRE Link Formatbull Generic REST design for use over HTTP and CoAPbull Used by OMA Lightweight M2Mbull Has already been deployed
ndash In traffic monitoring systemsndash In street lighting systemsndash For vehicular asset trackingndash By a major Cellular M2M operator
Changes since -04
bull Restricted Update to parameter updatesbull Added pagination support for the Lookup interfacebull Changed rt= to et= for the registration amp update
interfacebull Added group support
Group Management
bull RD now includes group management featuresbull New Group Function Set
ndash Register a groupbull Group name domain multicast address endpoint members
ndash Remove a groupbull Group lookup using the Lookup Function Set
ndash List registered groupsndash Find the members of a groupndash Find groups with certain endpoints or resources
Registering a Group
EP RD
| |
| - POST rd-groupgp=lights ltgtep=node1 --gt |
| |
| |
| lt---- 201 Created Location rd-group12 ---- |
| |
Req POST coaprdexamplecomrd-groupgp=lights
Payload
ltgtep=node1
ltgtep=node2
Res 201 Created
Location rd-group12
Looking up Group Members
Client RD
| |
| ----- GET rd-lookupepgp=lights1 ----------------------gt |
| |
| |
| lt-- 205 Content ltrdgtd=domain1ltrdgtd=domain2 --------- |
| |
Req GET rd-lookupepgp=lights1
Res 205 Content
ltcoaphostportgtep=node1
ltcoaphostportgtep=node2rdquo
Things for the futurebull Support for JSON representation of Web Links
ndash httptoolsietforgiddraft-bormann-core-links-json-02txtbull Registry for RD registration query parameters
ndash Already OMA Lightweight has defined some new onesbull More examples
Group 3 ldquonew workrdquo(continued)
109
drar-shy‐greevenbosch-shy‐core-shy‐profile-shy‐descripon-shy‐01Bert13 GreevenboschJeroen13 Hoebeke
Isam13 IshaqFloris13 Van13 den13 Abeele
Descripon
bull JSON13 format13 for13 signalling13 the13 servers13 capabilies
bull Signalling13 of13 supported13 opons13 media13 types13 and13 block13 sizendash Other13 items13 can13 be13 added
bull Filtering13 on13 specific13 fields13 through13 URI-shy‐Querybull Link13 hqpdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐profile-shy‐descripon
well-shy‐knownprofile
bull To13 acquire13 profile13 data13 of13 resources13 on13 a13 parcular13 service13 the13 well-shy‐knownprofile13 URI-shy‐path13 is13 introduced
bull For13 example13 to13 get13 all13 informaon13 from13 sensors13 served13 by13 wwwexampleorg13 we13 can13 do13 a13 GET13 to13 coapwwwexampleorgwell-shy‐knownprofile
bull Filtering13 on13 parcular13 resources13 is13 done13 through13 URI-shy‐Queries
Format
bull Currently13 the13 following13 fields13 are13 definedndash ldquopathrdquo13 contains13 the13 URI-shy‐path13 associated13 with13 a13 resource
ndash ldquooprdquo13 a13 numerical13 list13 of13 supported13 opon13 numbers
ndash ldquocfrdquo13 a13 numerical13 list13 of13 supported13 content-shy‐format13 numbers
ndash ldquob1srdquo13 ldquob2srdquo13 supported13 block13 sizes13 for13 Block113 and13 Block213 respecvely
Examplebull On13 the13 right13 is13 an13 example13 of13 a13 camera13 sensor13 at13 coapwwwexampleorgcam13 that13 supports13 the13 Uri-shy‐Host13 (3)13 ETag13 (4)13 Uri-shy‐Port13 (7)13 Uri-shy‐Path13 (11)13 Content-shy‐Format13 (12)13 Token13 (19)13 Block213 (23)13 and13 Proxy-shy‐Uri13 (35)13 opons
bull The13 supported13 content13 formats13 are13 textplain13 (0)13 applicaon13 link-shy‐format13 (40)13 and13 applicaonjson13 (50)
bull The13 supported13 Block213 can13 use13 25613 or13 51213 byte13 blocks
Req13 GET13 coapwwwexampleorgwell-shy‐knownprofile13 Res13 20513 Content13 (applicationjson)13 13 13 13 profile13 13 13 13 13 13 13 13 pathcam13 13 13 13 op[3471112192335]13 13 13 13 13 cf[04050]13 13 13 13 13 b2s[45]13 13 13 13
Filtering13 through13 use13 of13 URI-shy‐Query
bull Filtering13 can13 be13 done13 through13 the13 URI-shy‐Querybull Query13 format13 N=V
ndash N13 is13 a13 profile13 fieldndash V13 is13 the13 desired13 value
bull Examplesndash To13 find13 resources13 that13 support13 content13 format13 ldquoapplicaonjsonrdquo
13 GET13 wwwexampleorgwell-shy‐knownprofilecf=50ndash To13 get13 informaon13 about13 the13 camera
13 GET13 wwwexampleorgwell-shy‐knownprofilepath=cam
Open13 issues
bull Which13 other13 profile13 data13 needs13 signallingndash Content-shy‐type13 for13 different13 methods
bull Fix13 the13 order13 in13 which13 the13 profile13 fields13 must13 appearndash Non-shy‐fixed13 order13 easier13 extensible
bull Inheritance13 of13 a13 profile13 descriponbull Extend13 usage13 to13 signal13 the13 client13 profilebull Integraon13 with13 link13 format
Thank13 youQuesons
drar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval-shy‐00
Bert13 Greevenbosch
Descripon
bull The13 ldquoMinimumRequestInterval13 opon13 can13 be13 used13 to13 indicate13 the13 minimum13 me13 between13 two13 requests13 in13 a13 transacon
bull Originally13 intended13 for13 Block13 but13 also13 usable13 for13 other13 transaconsndash Example13 browsing13 a13 server
bull The13 goal13 is13 to13 reduce13 the13 server13 load13 and13 network13 traffic
bull Link13 hqpsdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval
Usage
bull The13 client13 keeps13 the13 server13 informed13 about13 its13 request13 speed13 through13 inclusion13 of13 the13 ldquoMinimumRequestIntervalrdquo13 opon
bull In13 responses13 the13 server13 fixes13 the13 minimum13 request13 interval13 through13 the13 same13 opon
bull The13 client13 obeys13 the13 speed13 indicated13 by13 the13 server
bull The13 client13 can13 send13 slower13 but13 not13 faster
Advantages
bull The13 server13 has13 means13 to13 limit13 the13 amount13 of13 incoming13 traffic
bull The13 server13 can13 prevent13 to13 become13 overloaded13 with13 too13 many13 tasks
bull The13 server13 does13 not13 need13 arficially13 slow13 down13 the13 client13 by13 sending13 late13 ACKsndash No13 need13 to13 keep13 track13 of13 delayed13 ACKsndash The13 server13 can13 perform13 other13 tasks13 instead
bull Reduced13 network13 traffic
Thank13 youQuesons
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-links-json-02txt
123
RFC 6690 (link-format) documents are somewhat foreign to many web app developerssect would prefer to have them in JSON format
There is no standard way to represent link-format documents in applicationssect but everyone knows how to handle JSON
Define a standard JSON translation for link-format
Itrsquos
not
rock
et
scien
ce
ltsensorsgtct=40title=Sensor Index ltsensorstempgtrt=temperature-cif=sensor ltsensorslightgtrt=light-luxif=sensor lthttpwwwexamplecomsensorst123gt anchor=sensorstemprel=describedby lttgtanchor=sensorstemprel=alternate [hrefsensorsct40titleSensor Index hrefsensorstemprttemperature-cifsensor hrefsensorslightrtlight-luxifsensor hrefhttpwwwexamplecomsensorst123 anchorsensorstempreldescribedby hreftanchorsensorstemprelalternate]
124
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-ipsec-for-coap-00txt
IPsec definitions for CoAP Mostly placeholder at this time Who has implementation experience with this
125
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-cross-reverse-convention-00txt
This draft has two lines of payload(based on a WGLC comment by Cullen Jennings)
coap12344567foobara=3
httpwwwproxycomwellknowncore-translate1234_4567foobara=3
Is that a useful convention to have
126
Insert CI slides here
127
128
0
5
10
15
20
25
30
35
40
10 20 30 40 50 60 70
good
put (
pps)
pps
Goodput vs pps (Econotags)
goodput
[Khattak preliminary]
Congestion Control
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-cocoa-00txt
ldquoadvancedrdquo cc (The draft is just a first shot) Others may have better ideas
129
Insert post-WGLC discussion slides here
130
Stop Continue Start
131
An Agile Retrospective
http6lowappnet coreIETF86 2013-03-12-13
Stop
132
Endless new CoAP optionssect instead use RESTful as much as possible
Move general security lifecycle out Looking at theoretical problems
http6lowappnet coreIETF86 2013-03-12-13
Continue
Interops Running code Look at real-world examples and deployments Solve their actual problems
sect Unilateral enhancements eg higher performance congestion control
sect Transports (SMS hellip)sect Make Web linking and Directories more and more usefulsect RESTful Design Paradigms for real-world problems
133
http6lowappnet coreIETF86 2013-03-12-13
Start
Further push into the (browser) web world (HTML5 browser security)
Specific supporting worksect SenMLsect URI work (dev URN hellip)sect Security Processes (next slide)
Spin outsect (We donrsquot really get to decide where this is done)
134
http6lowappnet coreIETF86 2013-03-12-13
Security
Integrate Application Network Group Keyingsect Tunnel-free setup
Donrsquot redo what has been done alreadysect ZigBee IP is finesect But what about other scenarios
Simple REST interfaces for working with keying materials and authorizationsect Start with defining objectives
Object Security for Constrained Nodes135
Re-chartering CoREWhat do we want to do now that wersquore grown up
Zach ShelbyCoRE WG IETF-86 Orlando
What is the scope
bull So we have a protocol and Web Linking what next
bull Keep with what we know besthellip1 Enhancements around CoAP2 New transports for CoAP3 New representations for Web Links4 General application layer solutions
CoRE WG IETF-86 Orlando 2
Enhancements around CoAP
bull Advanced congestion control
CoRE WG IETF-86 Orlando 3
New Transports for CoAP
bull Infrastructure for CoAP over foondash httptoolsietforgiddraft-silverajan-core-
coap-alternative-transports-01txtbull CoAP over SMS
ndash httptoolsietforgiddraft-becker-core-coap-sms-gprs-03txt
ndash OMA Lightweightbull CoAP over TCP
ndash httptoolsietforgiddraft-li-core-coap-payload-length-option-01txt
CoRE WG IETF-86 Orlando 4
New support for Web Links
bull JSON Web Linksndash httptoolsietforgiddraft-bormann-core-links-
json-02txt
2332010 CoRE WG IETF-77 Anaheim 5
General application layer solutions
bull Resource Directoryndash httptoolsietforgiddraft-shelby-core-
resource-directory-05txtndash OMA Lightweight
2332010 CoRE WG IETF-77 Anaheim 6
GET ndash Description of Test Scenarios
TestScenarios-GET
Scenario
CoAPSleepyServerSe7ngs CoAPSleepAwareReverseProxySe7ngs CoAPClientSe7ngs
SleepDuragton(sec)
AwakeDuragton(sec)
maxAge(sec) Caching SleepAwareSAF+
503NumberofClients
NumberofGETs
DelayBetweenClient
Requests(sec)
1a 0 Always 60 Enabled Disabled 1 100 35
1b 60 3 60 Enabled Disabled 1 100 35
1c 60 3 60 Enabled Enabled 1 100 35
2a 0 Always 60 Enabled Disabled 5 100 35
2b 60 3 60 Enabled Disabled 5 100 35
2c 60 3 60 Enabled Enabled 5 100 35
3a 0 Always 5 Enabled Disabled 5 100 35
3b 60 3 5 Enabled Disabled 5 100 35
3c 60 3 5 Enabled Enabled 5 100 35
ldquoGETrdquo ndash Test Scenario 1 Results
maxAge = 60 and 1 Client
GET ndash Scenario 1 ClientProxy Interface Transaction Mix
Scenarios 1a - Non-Sleepy Server Caching Proxy maxAge = 60sec 1b- Sleepy Server Caching Proxy maxAge = 60sec 1c - Sleepy Server Sleep Aware Proxy maxAge = 60sec
Sleep Aware Proxy has better performance for sleepy servers
0
100
200
300
400
500
600
700
1a 1b 1c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
GET ndash Scenario 1 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
Scenarios 1a - Non-Sleepy Server Caching Proxy maxAge = 60sec 1b- Sleepy Server Caching Proxy maxAge = 60sec 1c - Sleepy Server Sleep Aware Proxy maxAge = 60sec
0
100
200
300
400
500
600
700
800
1a 1b 1c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
ldquoGETrdquo ndash Test Scenario 2 Results
maxAge = 60 and 5 Clients
GET ndash Scenario 2 ClientProxy Interface Transaction Mix
Sleep Aware Proxy has slightly better performance for sleepy servers
0
200
400
600
800
1000
1200
1400
2a 2b 2c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
Scenarios 2a - Non-Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2b- Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2c - Sleepy Server Sleep Aware Proxy maxAge = 60sec 5 Clients
See ldquoExperimental Artifactsrdquo Note 1
GET ndash Scenario 2 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has slightly better performance for sleepy servers
0
50
100
150
200
250
300
350
400
2a 2b 2c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
Scenarios 2a - Non-Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2b- Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2c - Sleepy Server Sleep Aware Proxy maxAge = 60sec 5 Clients
See ldquoExperimental Artifactsrdquo Note 2
Experimental Artifacts Note 1
Currently in the experiment the sleep aware proxy checks the cached state of a resource before putting a request into its Store-and-forward queue while a server is sleeping Once in the queue the proxy unconditionally forwards the queued requests to the server once it wakes up This is not the most efficient setup and can easily be improved If the proxy instead checks its cache again before forwarding each queued request it may not need to forward the request to the server For example if there are two queued GET requests in the proxyrsquos queue that address the same resource Only the first request needs to be sent to the server the second request can use the cached response from the first request
Note 2 Currently in the experiment the sleepy server sends a sleepState PUT request to the
proxy each time it goes to sleep This is not the most efficient setup and can easily be improved For example if the server assumes that the proxy can keep track of its ONOFF cycles with its internal timers (eg as per Fig 1 of I-D) then the number of messages from the sleepy server dramatically goes down
ldquoGETrdquo ndash Test Scenario 3 Results
maxAge = 5 and 5 Clients
GET ndash Scenario 3 ClientProxy Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
Scenarios 3a - Non-Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3b- Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3c - Sleepy Server Sleep Aware Proxy maxAge = 5sec 5 Clients
0
500
1000
1500
2000
2500
3000
3500
4000
4500
5000
3a 3b 3c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
GET ndash Scenario 3 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
0
1000
2000
3000
4000
5000
6000
7000
3a 3b 3c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
Scenarios 3a - Non-Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3b- Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3c - Sleepy Server Sleep Aware Proxy maxAge = 5sec 5 Clients
Conclusions
Conclusions These results show that sleep-aware CoAP
proxy features can significantly optimize communication with sleepy servers in most scenarios
These results also show that sleep-
awareness capabilities can provide additional benefits above and beyond CoAP caching in most scenarios
Backup
Current CoAP Support of Sleepy Node (12)
CoAP proxies can use a previously cached response to service a new GET request for a sleepy origin server (as in HTTP) But if no valid cache then proxy has to attempt to
retrieve and may fail if origin server is sleeping [I-Dietf-core-coap]
Clients can discover list of resources from RD (GET rd-lookuphellip) for sleepy servers But attempt to GET resource from sleepy origin server
may fail if origin server is sleeping [IDietf-core-link-format amp IDshelby-core-resource-
directory]
Current CoAP Support of Sleepy Node (22)
Lower layer support for sleepy nodes in most wireless technologies (eg WiFi ZigBee) But limited to MAC packet scheduling for sleepy nodes
and not aware of specific needs of IP applications (like CoAP)
Proposal ndash RD Based Sleep Tracking (14)
The current CoAP approach to support sleepy nodes can be significantly improved by introducing RD based mechanisms for a CoAP client to determine whether A targeted resource is located on a sleepy server A sleepy server is currently in sleep mode or not
There is any associated caching Proxy (possibly the RD itself) for a sleepy server
Proposal ndash RD Based Sleep Tracking (24)
We define the following new RD attributes to characterize the properties of a sleepy node SleepState - Indicates whether the node is currently in
sleep mode or not (ie Sleeping or Awake) SleepDuration - Indicates the maximum duration of time
that the node stays in sleep mode TimeSleeping - Indicates the length of time the node
has been sleeping (ie if Sleep State = Sleeping) NextSleep - Indicates the next time the node will go to
sleep (ie if Sleep State = Awake)
CachingProxy ndash Indicates the caching proxy of the sleepy node (ie the RD itself or another node)
Proposal ndash RD Based Sleep Tracking (34)
These attributes are all server (node) level and are new parameters added to the RD URI Template Variables
Finally we also define a new lookup-type (ss) for the RD lookup interface specified in [I-Dshelby-core-resource-directory] This new lookup-type supports looking up the
ldquoSleepStaterdquo (ss) of a specified end-point
Proposal ndash RD Based Sleep Tracking (44)
The three time based parameters (SleepDuration TimeSleeping NextSleep) can be based on either an absolute network time (for a time synchronized network) or a relative local time (measured at the local node)
Following the approach of [I-Dietf-core-link-format] and [I-Dshelby-core-resource-directory] sleep parameters for sleepy servers can be stored by the server in the RD and accessed by all interested clients
Examples of using these parameters in a synchronous or asynchronous manner are shown in the I-D
http6lowappnet coreIETF86 2013-03-12-13
We assume people have read the drafts
Meetings serve to advance difficult issues by making good use of face-to-face communications
Note Well Be aware of the IPR principles according to RFC 3979 and its updates
uumlBlue sheetsuumlScribe(s)
96
drar-shy‐iep-shy‐core-shy‐coapsubmiqed13 to13 IESG
2013-shy‐03-shy‐13
97
OMA Lightweight M2M Overview(A new standard using lots of IETF specs including DTLS
CoAP Block Observe Resource Directory SenMLhellip)
Zach ShelbyCoRE WG IETF-86 Orlando
OMA Lightweight M2Mbull Open Mobile Alliance is well known for Device Management (DM)bull OMA Lightweight M2M is a new standard from the alliance
ndash Focused on constrained Cellular and sensor network M2M devicesndash Driven by leading operators and vendors
bull Scopendash Interfaces protocol amp security between Device and Serverndash Object and Resource modelndash Bootstrap Device Access Control Connectivity and Firmware Objects
bull Draft Specifications are availablendash httpmemberopenmobileallianceorgftpPublic_documentsDM
LightweightM2MPermanent_documentsOMA-TS-LightweightM2M-V1_0_0-20130301-Dzip
bull Timelinendash Requirements and Architecture completed 3Q2012ndash Spec ready for Consistency Review 2Q2013ndash Candidate Approval expected 3Q2013
2 CoRE WG IETF-86 Orlando
Architecture
3
Scope of LWM2M
CoRE WG IETF-86 Orlando
Object Model
bull A Client has one or more Object Instancesbull An Object is a collection of Resourcesbull A Resource is an atomic piece of information
ndash Read Written or Executed
bull Resources can have multiple instancesbull Objects and Resources are identified by a
16-bit Integer Instances by an 8-bit Integerbull ObjectsResources are accessed with
simple URIs Object IDObject InstanceResource ID
eg 1213
4 CoRE WG IETF-86 Orlando
CoRE WG IETF-86 Orlando
CoRE Resource Directory
draft-shelby-core-resource-directory-05
Z Shelby C Bormann S Krco
Backgroundbull Not a new concept
ndash think web search engine or any link directorybull Defines the interfaces to a Resource Directorybull Based on Web Linking framework and the CoRE Link Formatbull Generic REST design for use over HTTP and CoAPbull Used by OMA Lightweight M2Mbull Has already been deployed
ndash In traffic monitoring systemsndash In street lighting systemsndash For vehicular asset trackingndash By a major Cellular M2M operator
Changes since -04
bull Restricted Update to parameter updatesbull Added pagination support for the Lookup interfacebull Changed rt= to et= for the registration amp update
interfacebull Added group support
Group Management
bull RD now includes group management featuresbull New Group Function Set
ndash Register a groupbull Group name domain multicast address endpoint members
ndash Remove a groupbull Group lookup using the Lookup Function Set
ndash List registered groupsndash Find the members of a groupndash Find groups with certain endpoints or resources
Registering a Group
EP RD
| |
| - POST rd-groupgp=lights ltgtep=node1 --gt |
| |
| |
| lt---- 201 Created Location rd-group12 ---- |
| |
Req POST coaprdexamplecomrd-groupgp=lights
Payload
ltgtep=node1
ltgtep=node2
Res 201 Created
Location rd-group12
Looking up Group Members
Client RD
| |
| ----- GET rd-lookupepgp=lights1 ----------------------gt |
| |
| |
| lt-- 205 Content ltrdgtd=domain1ltrdgtd=domain2 --------- |
| |
Req GET rd-lookupepgp=lights1
Res 205 Content
ltcoaphostportgtep=node1
ltcoaphostportgtep=node2rdquo
Things for the futurebull Support for JSON representation of Web Links
ndash httptoolsietforgiddraft-bormann-core-links-json-02txtbull Registry for RD registration query parameters
ndash Already OMA Lightweight has defined some new onesbull More examples
Group 3 ldquonew workrdquo(continued)
109
drar-shy‐greevenbosch-shy‐core-shy‐profile-shy‐descripon-shy‐01Bert13 GreevenboschJeroen13 Hoebeke
Isam13 IshaqFloris13 Van13 den13 Abeele
Descripon
bull JSON13 format13 for13 signalling13 the13 servers13 capabilies
bull Signalling13 of13 supported13 opons13 media13 types13 and13 block13 sizendash Other13 items13 can13 be13 added
bull Filtering13 on13 specific13 fields13 through13 URI-shy‐Querybull Link13 hqpdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐profile-shy‐descripon
well-shy‐knownprofile
bull To13 acquire13 profile13 data13 of13 resources13 on13 a13 parcular13 service13 the13 well-shy‐knownprofile13 URI-shy‐path13 is13 introduced
bull For13 example13 to13 get13 all13 informaon13 from13 sensors13 served13 by13 wwwexampleorg13 we13 can13 do13 a13 GET13 to13 coapwwwexampleorgwell-shy‐knownprofile
bull Filtering13 on13 parcular13 resources13 is13 done13 through13 URI-shy‐Queries
Format
bull Currently13 the13 following13 fields13 are13 definedndash ldquopathrdquo13 contains13 the13 URI-shy‐path13 associated13 with13 a13 resource
ndash ldquooprdquo13 a13 numerical13 list13 of13 supported13 opon13 numbers
ndash ldquocfrdquo13 a13 numerical13 list13 of13 supported13 content-shy‐format13 numbers
ndash ldquob1srdquo13 ldquob2srdquo13 supported13 block13 sizes13 for13 Block113 and13 Block213 respecvely
Examplebull On13 the13 right13 is13 an13 example13 of13 a13 camera13 sensor13 at13 coapwwwexampleorgcam13 that13 supports13 the13 Uri-shy‐Host13 (3)13 ETag13 (4)13 Uri-shy‐Port13 (7)13 Uri-shy‐Path13 (11)13 Content-shy‐Format13 (12)13 Token13 (19)13 Block213 (23)13 and13 Proxy-shy‐Uri13 (35)13 opons
bull The13 supported13 content13 formats13 are13 textplain13 (0)13 applicaon13 link-shy‐format13 (40)13 and13 applicaonjson13 (50)
bull The13 supported13 Block213 can13 use13 25613 or13 51213 byte13 blocks
Req13 GET13 coapwwwexampleorgwell-shy‐knownprofile13 Res13 20513 Content13 (applicationjson)13 13 13 13 profile13 13 13 13 13 13 13 13 pathcam13 13 13 13 op[3471112192335]13 13 13 13 13 cf[04050]13 13 13 13 13 b2s[45]13 13 13 13
Filtering13 through13 use13 of13 URI-shy‐Query
bull Filtering13 can13 be13 done13 through13 the13 URI-shy‐Querybull Query13 format13 N=V
ndash N13 is13 a13 profile13 fieldndash V13 is13 the13 desired13 value
bull Examplesndash To13 find13 resources13 that13 support13 content13 format13 ldquoapplicaonjsonrdquo
13 GET13 wwwexampleorgwell-shy‐knownprofilecf=50ndash To13 get13 informaon13 about13 the13 camera
13 GET13 wwwexampleorgwell-shy‐knownprofilepath=cam
Open13 issues
bull Which13 other13 profile13 data13 needs13 signallingndash Content-shy‐type13 for13 different13 methods
bull Fix13 the13 order13 in13 which13 the13 profile13 fields13 must13 appearndash Non-shy‐fixed13 order13 easier13 extensible
bull Inheritance13 of13 a13 profile13 descriponbull Extend13 usage13 to13 signal13 the13 client13 profilebull Integraon13 with13 link13 format
Thank13 youQuesons
drar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval-shy‐00
Bert13 Greevenbosch
Descripon
bull The13 ldquoMinimumRequestInterval13 opon13 can13 be13 used13 to13 indicate13 the13 minimum13 me13 between13 two13 requests13 in13 a13 transacon
bull Originally13 intended13 for13 Block13 but13 also13 usable13 for13 other13 transaconsndash Example13 browsing13 a13 server
bull The13 goal13 is13 to13 reduce13 the13 server13 load13 and13 network13 traffic
bull Link13 hqpsdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval
Usage
bull The13 client13 keeps13 the13 server13 informed13 about13 its13 request13 speed13 through13 inclusion13 of13 the13 ldquoMinimumRequestIntervalrdquo13 opon
bull In13 responses13 the13 server13 fixes13 the13 minimum13 request13 interval13 through13 the13 same13 opon
bull The13 client13 obeys13 the13 speed13 indicated13 by13 the13 server
bull The13 client13 can13 send13 slower13 but13 not13 faster
Advantages
bull The13 server13 has13 means13 to13 limit13 the13 amount13 of13 incoming13 traffic
bull The13 server13 can13 prevent13 to13 become13 overloaded13 with13 too13 many13 tasks
bull The13 server13 does13 not13 need13 arficially13 slow13 down13 the13 client13 by13 sending13 late13 ACKsndash No13 need13 to13 keep13 track13 of13 delayed13 ACKsndash The13 server13 can13 perform13 other13 tasks13 instead
bull Reduced13 network13 traffic
Thank13 youQuesons
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-links-json-02txt
123
RFC 6690 (link-format) documents are somewhat foreign to many web app developerssect would prefer to have them in JSON format
There is no standard way to represent link-format documents in applicationssect but everyone knows how to handle JSON
Define a standard JSON translation for link-format
Itrsquos
not
rock
et
scien
ce
ltsensorsgtct=40title=Sensor Index ltsensorstempgtrt=temperature-cif=sensor ltsensorslightgtrt=light-luxif=sensor lthttpwwwexamplecomsensorst123gt anchor=sensorstemprel=describedby lttgtanchor=sensorstemprel=alternate [hrefsensorsct40titleSensor Index hrefsensorstemprttemperature-cifsensor hrefsensorslightrtlight-luxifsensor hrefhttpwwwexamplecomsensorst123 anchorsensorstempreldescribedby hreftanchorsensorstemprelalternate]
124
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-ipsec-for-coap-00txt
IPsec definitions for CoAP Mostly placeholder at this time Who has implementation experience with this
125
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-cross-reverse-convention-00txt
This draft has two lines of payload(based on a WGLC comment by Cullen Jennings)
coap12344567foobara=3
httpwwwproxycomwellknowncore-translate1234_4567foobara=3
Is that a useful convention to have
126
Insert CI slides here
127
128
0
5
10
15
20
25
30
35
40
10 20 30 40 50 60 70
good
put (
pps)
pps
Goodput vs pps (Econotags)
goodput
[Khattak preliminary]
Congestion Control
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-cocoa-00txt
ldquoadvancedrdquo cc (The draft is just a first shot) Others may have better ideas
129
Insert post-WGLC discussion slides here
130
Stop Continue Start
131
An Agile Retrospective
http6lowappnet coreIETF86 2013-03-12-13
Stop
132
Endless new CoAP optionssect instead use RESTful as much as possible
Move general security lifecycle out Looking at theoretical problems
http6lowappnet coreIETF86 2013-03-12-13
Continue
Interops Running code Look at real-world examples and deployments Solve their actual problems
sect Unilateral enhancements eg higher performance congestion control
sect Transports (SMS hellip)sect Make Web linking and Directories more and more usefulsect RESTful Design Paradigms for real-world problems
133
http6lowappnet coreIETF86 2013-03-12-13
Start
Further push into the (browser) web world (HTML5 browser security)
Specific supporting worksect SenMLsect URI work (dev URN hellip)sect Security Processes (next slide)
Spin outsect (We donrsquot really get to decide where this is done)
134
http6lowappnet coreIETF86 2013-03-12-13
Security
Integrate Application Network Group Keyingsect Tunnel-free setup
Donrsquot redo what has been done alreadysect ZigBee IP is finesect But what about other scenarios
Simple REST interfaces for working with keying materials and authorizationsect Start with defining objectives
Object Security for Constrained Nodes135
Re-chartering CoREWhat do we want to do now that wersquore grown up
Zach ShelbyCoRE WG IETF-86 Orlando
What is the scope
bull So we have a protocol and Web Linking what next
bull Keep with what we know besthellip1 Enhancements around CoAP2 New transports for CoAP3 New representations for Web Links4 General application layer solutions
CoRE WG IETF-86 Orlando 2
Enhancements around CoAP
bull Advanced congestion control
CoRE WG IETF-86 Orlando 3
New Transports for CoAP
bull Infrastructure for CoAP over foondash httptoolsietforgiddraft-silverajan-core-
coap-alternative-transports-01txtbull CoAP over SMS
ndash httptoolsietforgiddraft-becker-core-coap-sms-gprs-03txt
ndash OMA Lightweightbull CoAP over TCP
ndash httptoolsietforgiddraft-li-core-coap-payload-length-option-01txt
CoRE WG IETF-86 Orlando 4
New support for Web Links
bull JSON Web Linksndash httptoolsietforgiddraft-bormann-core-links-
json-02txt
2332010 CoRE WG IETF-77 Anaheim 5
General application layer solutions
bull Resource Directoryndash httptoolsietforgiddraft-shelby-core-
resource-directory-05txtndash OMA Lightweight
2332010 CoRE WG IETF-77 Anaheim 6
ldquoGETrdquo ndash Test Scenario 1 Results
maxAge = 60 and 1 Client
GET ndash Scenario 1 ClientProxy Interface Transaction Mix
Scenarios 1a - Non-Sleepy Server Caching Proxy maxAge = 60sec 1b- Sleepy Server Caching Proxy maxAge = 60sec 1c - Sleepy Server Sleep Aware Proxy maxAge = 60sec
Sleep Aware Proxy has better performance for sleepy servers
0
100
200
300
400
500
600
700
1a 1b 1c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
GET ndash Scenario 1 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
Scenarios 1a - Non-Sleepy Server Caching Proxy maxAge = 60sec 1b- Sleepy Server Caching Proxy maxAge = 60sec 1c - Sleepy Server Sleep Aware Proxy maxAge = 60sec
0
100
200
300
400
500
600
700
800
1a 1b 1c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
ldquoGETrdquo ndash Test Scenario 2 Results
maxAge = 60 and 5 Clients
GET ndash Scenario 2 ClientProxy Interface Transaction Mix
Sleep Aware Proxy has slightly better performance for sleepy servers
0
200
400
600
800
1000
1200
1400
2a 2b 2c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
Scenarios 2a - Non-Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2b- Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2c - Sleepy Server Sleep Aware Proxy maxAge = 60sec 5 Clients
See ldquoExperimental Artifactsrdquo Note 1
GET ndash Scenario 2 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has slightly better performance for sleepy servers
0
50
100
150
200
250
300
350
400
2a 2b 2c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
Scenarios 2a - Non-Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2b- Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2c - Sleepy Server Sleep Aware Proxy maxAge = 60sec 5 Clients
See ldquoExperimental Artifactsrdquo Note 2
Experimental Artifacts Note 1
Currently in the experiment the sleep aware proxy checks the cached state of a resource before putting a request into its Store-and-forward queue while a server is sleeping Once in the queue the proxy unconditionally forwards the queued requests to the server once it wakes up This is not the most efficient setup and can easily be improved If the proxy instead checks its cache again before forwarding each queued request it may not need to forward the request to the server For example if there are two queued GET requests in the proxyrsquos queue that address the same resource Only the first request needs to be sent to the server the second request can use the cached response from the first request
Note 2 Currently in the experiment the sleepy server sends a sleepState PUT request to the
proxy each time it goes to sleep This is not the most efficient setup and can easily be improved For example if the server assumes that the proxy can keep track of its ONOFF cycles with its internal timers (eg as per Fig 1 of I-D) then the number of messages from the sleepy server dramatically goes down
ldquoGETrdquo ndash Test Scenario 3 Results
maxAge = 5 and 5 Clients
GET ndash Scenario 3 ClientProxy Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
Scenarios 3a - Non-Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3b- Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3c - Sleepy Server Sleep Aware Proxy maxAge = 5sec 5 Clients
0
500
1000
1500
2000
2500
3000
3500
4000
4500
5000
3a 3b 3c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
GET ndash Scenario 3 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
0
1000
2000
3000
4000
5000
6000
7000
3a 3b 3c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
Scenarios 3a - Non-Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3b- Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3c - Sleepy Server Sleep Aware Proxy maxAge = 5sec 5 Clients
Conclusions
Conclusions These results show that sleep-aware CoAP
proxy features can significantly optimize communication with sleepy servers in most scenarios
These results also show that sleep-
awareness capabilities can provide additional benefits above and beyond CoAP caching in most scenarios
Backup
Current CoAP Support of Sleepy Node (12)
CoAP proxies can use a previously cached response to service a new GET request for a sleepy origin server (as in HTTP) But if no valid cache then proxy has to attempt to
retrieve and may fail if origin server is sleeping [I-Dietf-core-coap]
Clients can discover list of resources from RD (GET rd-lookuphellip) for sleepy servers But attempt to GET resource from sleepy origin server
may fail if origin server is sleeping [IDietf-core-link-format amp IDshelby-core-resource-
directory]
Current CoAP Support of Sleepy Node (22)
Lower layer support for sleepy nodes in most wireless technologies (eg WiFi ZigBee) But limited to MAC packet scheduling for sleepy nodes
and not aware of specific needs of IP applications (like CoAP)
Proposal ndash RD Based Sleep Tracking (14)
The current CoAP approach to support sleepy nodes can be significantly improved by introducing RD based mechanisms for a CoAP client to determine whether A targeted resource is located on a sleepy server A sleepy server is currently in sleep mode or not
There is any associated caching Proxy (possibly the RD itself) for a sleepy server
Proposal ndash RD Based Sleep Tracking (24)
We define the following new RD attributes to characterize the properties of a sleepy node SleepState - Indicates whether the node is currently in
sleep mode or not (ie Sleeping or Awake) SleepDuration - Indicates the maximum duration of time
that the node stays in sleep mode TimeSleeping - Indicates the length of time the node
has been sleeping (ie if Sleep State = Sleeping) NextSleep - Indicates the next time the node will go to
sleep (ie if Sleep State = Awake)
CachingProxy ndash Indicates the caching proxy of the sleepy node (ie the RD itself or another node)
Proposal ndash RD Based Sleep Tracking (34)
These attributes are all server (node) level and are new parameters added to the RD URI Template Variables
Finally we also define a new lookup-type (ss) for the RD lookup interface specified in [I-Dshelby-core-resource-directory] This new lookup-type supports looking up the
ldquoSleepStaterdquo (ss) of a specified end-point
Proposal ndash RD Based Sleep Tracking (44)
The three time based parameters (SleepDuration TimeSleeping NextSleep) can be based on either an absolute network time (for a time synchronized network) or a relative local time (measured at the local node)
Following the approach of [I-Dietf-core-link-format] and [I-Dshelby-core-resource-directory] sleep parameters for sleepy servers can be stored by the server in the RD and accessed by all interested clients
Examples of using these parameters in a synchronous or asynchronous manner are shown in the I-D
http6lowappnet coreIETF86 2013-03-12-13
We assume people have read the drafts
Meetings serve to advance difficult issues by making good use of face-to-face communications
Note Well Be aware of the IPR principles according to RFC 3979 and its updates
uumlBlue sheetsuumlScribe(s)
96
drar-shy‐iep-shy‐core-shy‐coapsubmiqed13 to13 IESG
2013-shy‐03-shy‐13
97
OMA Lightweight M2M Overview(A new standard using lots of IETF specs including DTLS
CoAP Block Observe Resource Directory SenMLhellip)
Zach ShelbyCoRE WG IETF-86 Orlando
OMA Lightweight M2Mbull Open Mobile Alliance is well known for Device Management (DM)bull OMA Lightweight M2M is a new standard from the alliance
ndash Focused on constrained Cellular and sensor network M2M devicesndash Driven by leading operators and vendors
bull Scopendash Interfaces protocol amp security between Device and Serverndash Object and Resource modelndash Bootstrap Device Access Control Connectivity and Firmware Objects
bull Draft Specifications are availablendash httpmemberopenmobileallianceorgftpPublic_documentsDM
LightweightM2MPermanent_documentsOMA-TS-LightweightM2M-V1_0_0-20130301-Dzip
bull Timelinendash Requirements and Architecture completed 3Q2012ndash Spec ready for Consistency Review 2Q2013ndash Candidate Approval expected 3Q2013
2 CoRE WG IETF-86 Orlando
Architecture
3
Scope of LWM2M
CoRE WG IETF-86 Orlando
Object Model
bull A Client has one or more Object Instancesbull An Object is a collection of Resourcesbull A Resource is an atomic piece of information
ndash Read Written or Executed
bull Resources can have multiple instancesbull Objects and Resources are identified by a
16-bit Integer Instances by an 8-bit Integerbull ObjectsResources are accessed with
simple URIs Object IDObject InstanceResource ID
eg 1213
4 CoRE WG IETF-86 Orlando
CoRE WG IETF-86 Orlando
CoRE Resource Directory
draft-shelby-core-resource-directory-05
Z Shelby C Bormann S Krco
Backgroundbull Not a new concept
ndash think web search engine or any link directorybull Defines the interfaces to a Resource Directorybull Based on Web Linking framework and the CoRE Link Formatbull Generic REST design for use over HTTP and CoAPbull Used by OMA Lightweight M2Mbull Has already been deployed
ndash In traffic monitoring systemsndash In street lighting systemsndash For vehicular asset trackingndash By a major Cellular M2M operator
Changes since -04
bull Restricted Update to parameter updatesbull Added pagination support for the Lookup interfacebull Changed rt= to et= for the registration amp update
interfacebull Added group support
Group Management
bull RD now includes group management featuresbull New Group Function Set
ndash Register a groupbull Group name domain multicast address endpoint members
ndash Remove a groupbull Group lookup using the Lookup Function Set
ndash List registered groupsndash Find the members of a groupndash Find groups with certain endpoints or resources
Registering a Group
EP RD
| |
| - POST rd-groupgp=lights ltgtep=node1 --gt |
| |
| |
| lt---- 201 Created Location rd-group12 ---- |
| |
Req POST coaprdexamplecomrd-groupgp=lights
Payload
ltgtep=node1
ltgtep=node2
Res 201 Created
Location rd-group12
Looking up Group Members
Client RD
| |
| ----- GET rd-lookupepgp=lights1 ----------------------gt |
| |
| |
| lt-- 205 Content ltrdgtd=domain1ltrdgtd=domain2 --------- |
| |
Req GET rd-lookupepgp=lights1
Res 205 Content
ltcoaphostportgtep=node1
ltcoaphostportgtep=node2rdquo
Things for the futurebull Support for JSON representation of Web Links
ndash httptoolsietforgiddraft-bormann-core-links-json-02txtbull Registry for RD registration query parameters
ndash Already OMA Lightweight has defined some new onesbull More examples
Group 3 ldquonew workrdquo(continued)
109
drar-shy‐greevenbosch-shy‐core-shy‐profile-shy‐descripon-shy‐01Bert13 GreevenboschJeroen13 Hoebeke
Isam13 IshaqFloris13 Van13 den13 Abeele
Descripon
bull JSON13 format13 for13 signalling13 the13 servers13 capabilies
bull Signalling13 of13 supported13 opons13 media13 types13 and13 block13 sizendash Other13 items13 can13 be13 added
bull Filtering13 on13 specific13 fields13 through13 URI-shy‐Querybull Link13 hqpdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐profile-shy‐descripon
well-shy‐knownprofile
bull To13 acquire13 profile13 data13 of13 resources13 on13 a13 parcular13 service13 the13 well-shy‐knownprofile13 URI-shy‐path13 is13 introduced
bull For13 example13 to13 get13 all13 informaon13 from13 sensors13 served13 by13 wwwexampleorg13 we13 can13 do13 a13 GET13 to13 coapwwwexampleorgwell-shy‐knownprofile
bull Filtering13 on13 parcular13 resources13 is13 done13 through13 URI-shy‐Queries
Format
bull Currently13 the13 following13 fields13 are13 definedndash ldquopathrdquo13 contains13 the13 URI-shy‐path13 associated13 with13 a13 resource
ndash ldquooprdquo13 a13 numerical13 list13 of13 supported13 opon13 numbers
ndash ldquocfrdquo13 a13 numerical13 list13 of13 supported13 content-shy‐format13 numbers
ndash ldquob1srdquo13 ldquob2srdquo13 supported13 block13 sizes13 for13 Block113 and13 Block213 respecvely
Examplebull On13 the13 right13 is13 an13 example13 of13 a13 camera13 sensor13 at13 coapwwwexampleorgcam13 that13 supports13 the13 Uri-shy‐Host13 (3)13 ETag13 (4)13 Uri-shy‐Port13 (7)13 Uri-shy‐Path13 (11)13 Content-shy‐Format13 (12)13 Token13 (19)13 Block213 (23)13 and13 Proxy-shy‐Uri13 (35)13 opons
bull The13 supported13 content13 formats13 are13 textplain13 (0)13 applicaon13 link-shy‐format13 (40)13 and13 applicaonjson13 (50)
bull The13 supported13 Block213 can13 use13 25613 or13 51213 byte13 blocks
Req13 GET13 coapwwwexampleorgwell-shy‐knownprofile13 Res13 20513 Content13 (applicationjson)13 13 13 13 profile13 13 13 13 13 13 13 13 pathcam13 13 13 13 op[3471112192335]13 13 13 13 13 cf[04050]13 13 13 13 13 b2s[45]13 13 13 13
Filtering13 through13 use13 of13 URI-shy‐Query
bull Filtering13 can13 be13 done13 through13 the13 URI-shy‐Querybull Query13 format13 N=V
ndash N13 is13 a13 profile13 fieldndash V13 is13 the13 desired13 value
bull Examplesndash To13 find13 resources13 that13 support13 content13 format13 ldquoapplicaonjsonrdquo
13 GET13 wwwexampleorgwell-shy‐knownprofilecf=50ndash To13 get13 informaon13 about13 the13 camera
13 GET13 wwwexampleorgwell-shy‐knownprofilepath=cam
Open13 issues
bull Which13 other13 profile13 data13 needs13 signallingndash Content-shy‐type13 for13 different13 methods
bull Fix13 the13 order13 in13 which13 the13 profile13 fields13 must13 appearndash Non-shy‐fixed13 order13 easier13 extensible
bull Inheritance13 of13 a13 profile13 descriponbull Extend13 usage13 to13 signal13 the13 client13 profilebull Integraon13 with13 link13 format
Thank13 youQuesons
drar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval-shy‐00
Bert13 Greevenbosch
Descripon
bull The13 ldquoMinimumRequestInterval13 opon13 can13 be13 used13 to13 indicate13 the13 minimum13 me13 between13 two13 requests13 in13 a13 transacon
bull Originally13 intended13 for13 Block13 but13 also13 usable13 for13 other13 transaconsndash Example13 browsing13 a13 server
bull The13 goal13 is13 to13 reduce13 the13 server13 load13 and13 network13 traffic
bull Link13 hqpsdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval
Usage
bull The13 client13 keeps13 the13 server13 informed13 about13 its13 request13 speed13 through13 inclusion13 of13 the13 ldquoMinimumRequestIntervalrdquo13 opon
bull In13 responses13 the13 server13 fixes13 the13 minimum13 request13 interval13 through13 the13 same13 opon
bull The13 client13 obeys13 the13 speed13 indicated13 by13 the13 server
bull The13 client13 can13 send13 slower13 but13 not13 faster
Advantages
bull The13 server13 has13 means13 to13 limit13 the13 amount13 of13 incoming13 traffic
bull The13 server13 can13 prevent13 to13 become13 overloaded13 with13 too13 many13 tasks
bull The13 server13 does13 not13 need13 arficially13 slow13 down13 the13 client13 by13 sending13 late13 ACKsndash No13 need13 to13 keep13 track13 of13 delayed13 ACKsndash The13 server13 can13 perform13 other13 tasks13 instead
bull Reduced13 network13 traffic
Thank13 youQuesons
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-links-json-02txt
123
RFC 6690 (link-format) documents are somewhat foreign to many web app developerssect would prefer to have them in JSON format
There is no standard way to represent link-format documents in applicationssect but everyone knows how to handle JSON
Define a standard JSON translation for link-format
Itrsquos
not
rock
et
scien
ce
ltsensorsgtct=40title=Sensor Index ltsensorstempgtrt=temperature-cif=sensor ltsensorslightgtrt=light-luxif=sensor lthttpwwwexamplecomsensorst123gt anchor=sensorstemprel=describedby lttgtanchor=sensorstemprel=alternate [hrefsensorsct40titleSensor Index hrefsensorstemprttemperature-cifsensor hrefsensorslightrtlight-luxifsensor hrefhttpwwwexamplecomsensorst123 anchorsensorstempreldescribedby hreftanchorsensorstemprelalternate]
124
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-ipsec-for-coap-00txt
IPsec definitions for CoAP Mostly placeholder at this time Who has implementation experience with this
125
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-cross-reverse-convention-00txt
This draft has two lines of payload(based on a WGLC comment by Cullen Jennings)
coap12344567foobara=3
httpwwwproxycomwellknowncore-translate1234_4567foobara=3
Is that a useful convention to have
126
Insert CI slides here
127
128
0
5
10
15
20
25
30
35
40
10 20 30 40 50 60 70
good
put (
pps)
pps
Goodput vs pps (Econotags)
goodput
[Khattak preliminary]
Congestion Control
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-cocoa-00txt
ldquoadvancedrdquo cc (The draft is just a first shot) Others may have better ideas
129
Insert post-WGLC discussion slides here
130
Stop Continue Start
131
An Agile Retrospective
http6lowappnet coreIETF86 2013-03-12-13
Stop
132
Endless new CoAP optionssect instead use RESTful as much as possible
Move general security lifecycle out Looking at theoretical problems
http6lowappnet coreIETF86 2013-03-12-13
Continue
Interops Running code Look at real-world examples and deployments Solve their actual problems
sect Unilateral enhancements eg higher performance congestion control
sect Transports (SMS hellip)sect Make Web linking and Directories more and more usefulsect RESTful Design Paradigms for real-world problems
133
http6lowappnet coreIETF86 2013-03-12-13
Start
Further push into the (browser) web world (HTML5 browser security)
Specific supporting worksect SenMLsect URI work (dev URN hellip)sect Security Processes (next slide)
Spin outsect (We donrsquot really get to decide where this is done)
134
http6lowappnet coreIETF86 2013-03-12-13
Security
Integrate Application Network Group Keyingsect Tunnel-free setup
Donrsquot redo what has been done alreadysect ZigBee IP is finesect But what about other scenarios
Simple REST interfaces for working with keying materials and authorizationsect Start with defining objectives
Object Security for Constrained Nodes135
Re-chartering CoREWhat do we want to do now that wersquore grown up
Zach ShelbyCoRE WG IETF-86 Orlando
What is the scope
bull So we have a protocol and Web Linking what next
bull Keep with what we know besthellip1 Enhancements around CoAP2 New transports for CoAP3 New representations for Web Links4 General application layer solutions
CoRE WG IETF-86 Orlando 2
Enhancements around CoAP
bull Advanced congestion control
CoRE WG IETF-86 Orlando 3
New Transports for CoAP
bull Infrastructure for CoAP over foondash httptoolsietforgiddraft-silverajan-core-
coap-alternative-transports-01txtbull CoAP over SMS
ndash httptoolsietforgiddraft-becker-core-coap-sms-gprs-03txt
ndash OMA Lightweightbull CoAP over TCP
ndash httptoolsietforgiddraft-li-core-coap-payload-length-option-01txt
CoRE WG IETF-86 Orlando 4
New support for Web Links
bull JSON Web Linksndash httptoolsietforgiddraft-bormann-core-links-
json-02txt
2332010 CoRE WG IETF-77 Anaheim 5
General application layer solutions
bull Resource Directoryndash httptoolsietforgiddraft-shelby-core-
resource-directory-05txtndash OMA Lightweight
2332010 CoRE WG IETF-77 Anaheim 6
GET ndash Scenario 1 ClientProxy Interface Transaction Mix
Scenarios 1a - Non-Sleepy Server Caching Proxy maxAge = 60sec 1b- Sleepy Server Caching Proxy maxAge = 60sec 1c - Sleepy Server Sleep Aware Proxy maxAge = 60sec
Sleep Aware Proxy has better performance for sleepy servers
0
100
200
300
400
500
600
700
1a 1b 1c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
GET ndash Scenario 1 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
Scenarios 1a - Non-Sleepy Server Caching Proxy maxAge = 60sec 1b- Sleepy Server Caching Proxy maxAge = 60sec 1c - Sleepy Server Sleep Aware Proxy maxAge = 60sec
0
100
200
300
400
500
600
700
800
1a 1b 1c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
ldquoGETrdquo ndash Test Scenario 2 Results
maxAge = 60 and 5 Clients
GET ndash Scenario 2 ClientProxy Interface Transaction Mix
Sleep Aware Proxy has slightly better performance for sleepy servers
0
200
400
600
800
1000
1200
1400
2a 2b 2c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
Scenarios 2a - Non-Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2b- Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2c - Sleepy Server Sleep Aware Proxy maxAge = 60sec 5 Clients
See ldquoExperimental Artifactsrdquo Note 1
GET ndash Scenario 2 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has slightly better performance for sleepy servers
0
50
100
150
200
250
300
350
400
2a 2b 2c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
Scenarios 2a - Non-Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2b- Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2c - Sleepy Server Sleep Aware Proxy maxAge = 60sec 5 Clients
See ldquoExperimental Artifactsrdquo Note 2
Experimental Artifacts Note 1
Currently in the experiment the sleep aware proxy checks the cached state of a resource before putting a request into its Store-and-forward queue while a server is sleeping Once in the queue the proxy unconditionally forwards the queued requests to the server once it wakes up This is not the most efficient setup and can easily be improved If the proxy instead checks its cache again before forwarding each queued request it may not need to forward the request to the server For example if there are two queued GET requests in the proxyrsquos queue that address the same resource Only the first request needs to be sent to the server the second request can use the cached response from the first request
Note 2 Currently in the experiment the sleepy server sends a sleepState PUT request to the
proxy each time it goes to sleep This is not the most efficient setup and can easily be improved For example if the server assumes that the proxy can keep track of its ONOFF cycles with its internal timers (eg as per Fig 1 of I-D) then the number of messages from the sleepy server dramatically goes down
ldquoGETrdquo ndash Test Scenario 3 Results
maxAge = 5 and 5 Clients
GET ndash Scenario 3 ClientProxy Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
Scenarios 3a - Non-Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3b- Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3c - Sleepy Server Sleep Aware Proxy maxAge = 5sec 5 Clients
0
500
1000
1500
2000
2500
3000
3500
4000
4500
5000
3a 3b 3c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
GET ndash Scenario 3 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
0
1000
2000
3000
4000
5000
6000
7000
3a 3b 3c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
Scenarios 3a - Non-Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3b- Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3c - Sleepy Server Sleep Aware Proxy maxAge = 5sec 5 Clients
Conclusions
Conclusions These results show that sleep-aware CoAP
proxy features can significantly optimize communication with sleepy servers in most scenarios
These results also show that sleep-
awareness capabilities can provide additional benefits above and beyond CoAP caching in most scenarios
Backup
Current CoAP Support of Sleepy Node (12)
CoAP proxies can use a previously cached response to service a new GET request for a sleepy origin server (as in HTTP) But if no valid cache then proxy has to attempt to
retrieve and may fail if origin server is sleeping [I-Dietf-core-coap]
Clients can discover list of resources from RD (GET rd-lookuphellip) for sleepy servers But attempt to GET resource from sleepy origin server
may fail if origin server is sleeping [IDietf-core-link-format amp IDshelby-core-resource-
directory]
Current CoAP Support of Sleepy Node (22)
Lower layer support for sleepy nodes in most wireless technologies (eg WiFi ZigBee) But limited to MAC packet scheduling for sleepy nodes
and not aware of specific needs of IP applications (like CoAP)
Proposal ndash RD Based Sleep Tracking (14)
The current CoAP approach to support sleepy nodes can be significantly improved by introducing RD based mechanisms for a CoAP client to determine whether A targeted resource is located on a sleepy server A sleepy server is currently in sleep mode or not
There is any associated caching Proxy (possibly the RD itself) for a sleepy server
Proposal ndash RD Based Sleep Tracking (24)
We define the following new RD attributes to characterize the properties of a sleepy node SleepState - Indicates whether the node is currently in
sleep mode or not (ie Sleeping or Awake) SleepDuration - Indicates the maximum duration of time
that the node stays in sleep mode TimeSleeping - Indicates the length of time the node
has been sleeping (ie if Sleep State = Sleeping) NextSleep - Indicates the next time the node will go to
sleep (ie if Sleep State = Awake)
CachingProxy ndash Indicates the caching proxy of the sleepy node (ie the RD itself or another node)
Proposal ndash RD Based Sleep Tracking (34)
These attributes are all server (node) level and are new parameters added to the RD URI Template Variables
Finally we also define a new lookup-type (ss) for the RD lookup interface specified in [I-Dshelby-core-resource-directory] This new lookup-type supports looking up the
ldquoSleepStaterdquo (ss) of a specified end-point
Proposal ndash RD Based Sleep Tracking (44)
The three time based parameters (SleepDuration TimeSleeping NextSleep) can be based on either an absolute network time (for a time synchronized network) or a relative local time (measured at the local node)
Following the approach of [I-Dietf-core-link-format] and [I-Dshelby-core-resource-directory] sleep parameters for sleepy servers can be stored by the server in the RD and accessed by all interested clients
Examples of using these parameters in a synchronous or asynchronous manner are shown in the I-D
http6lowappnet coreIETF86 2013-03-12-13
We assume people have read the drafts
Meetings serve to advance difficult issues by making good use of face-to-face communications
Note Well Be aware of the IPR principles according to RFC 3979 and its updates
uumlBlue sheetsuumlScribe(s)
96
drar-shy‐iep-shy‐core-shy‐coapsubmiqed13 to13 IESG
2013-shy‐03-shy‐13
97
OMA Lightweight M2M Overview(A new standard using lots of IETF specs including DTLS
CoAP Block Observe Resource Directory SenMLhellip)
Zach ShelbyCoRE WG IETF-86 Orlando
OMA Lightweight M2Mbull Open Mobile Alliance is well known for Device Management (DM)bull OMA Lightweight M2M is a new standard from the alliance
ndash Focused on constrained Cellular and sensor network M2M devicesndash Driven by leading operators and vendors
bull Scopendash Interfaces protocol amp security between Device and Serverndash Object and Resource modelndash Bootstrap Device Access Control Connectivity and Firmware Objects
bull Draft Specifications are availablendash httpmemberopenmobileallianceorgftpPublic_documentsDM
LightweightM2MPermanent_documentsOMA-TS-LightweightM2M-V1_0_0-20130301-Dzip
bull Timelinendash Requirements and Architecture completed 3Q2012ndash Spec ready for Consistency Review 2Q2013ndash Candidate Approval expected 3Q2013
2 CoRE WG IETF-86 Orlando
Architecture
3
Scope of LWM2M
CoRE WG IETF-86 Orlando
Object Model
bull A Client has one or more Object Instancesbull An Object is a collection of Resourcesbull A Resource is an atomic piece of information
ndash Read Written or Executed
bull Resources can have multiple instancesbull Objects and Resources are identified by a
16-bit Integer Instances by an 8-bit Integerbull ObjectsResources are accessed with
simple URIs Object IDObject InstanceResource ID
eg 1213
4 CoRE WG IETF-86 Orlando
CoRE WG IETF-86 Orlando
CoRE Resource Directory
draft-shelby-core-resource-directory-05
Z Shelby C Bormann S Krco
Backgroundbull Not a new concept
ndash think web search engine or any link directorybull Defines the interfaces to a Resource Directorybull Based on Web Linking framework and the CoRE Link Formatbull Generic REST design for use over HTTP and CoAPbull Used by OMA Lightweight M2Mbull Has already been deployed
ndash In traffic monitoring systemsndash In street lighting systemsndash For vehicular asset trackingndash By a major Cellular M2M operator
Changes since -04
bull Restricted Update to parameter updatesbull Added pagination support for the Lookup interfacebull Changed rt= to et= for the registration amp update
interfacebull Added group support
Group Management
bull RD now includes group management featuresbull New Group Function Set
ndash Register a groupbull Group name domain multicast address endpoint members
ndash Remove a groupbull Group lookup using the Lookup Function Set
ndash List registered groupsndash Find the members of a groupndash Find groups with certain endpoints or resources
Registering a Group
EP RD
| |
| - POST rd-groupgp=lights ltgtep=node1 --gt |
| |
| |
| lt---- 201 Created Location rd-group12 ---- |
| |
Req POST coaprdexamplecomrd-groupgp=lights
Payload
ltgtep=node1
ltgtep=node2
Res 201 Created
Location rd-group12
Looking up Group Members
Client RD
| |
| ----- GET rd-lookupepgp=lights1 ----------------------gt |
| |
| |
| lt-- 205 Content ltrdgtd=domain1ltrdgtd=domain2 --------- |
| |
Req GET rd-lookupepgp=lights1
Res 205 Content
ltcoaphostportgtep=node1
ltcoaphostportgtep=node2rdquo
Things for the futurebull Support for JSON representation of Web Links
ndash httptoolsietforgiddraft-bormann-core-links-json-02txtbull Registry for RD registration query parameters
ndash Already OMA Lightweight has defined some new onesbull More examples
Group 3 ldquonew workrdquo(continued)
109
drar-shy‐greevenbosch-shy‐core-shy‐profile-shy‐descripon-shy‐01Bert13 GreevenboschJeroen13 Hoebeke
Isam13 IshaqFloris13 Van13 den13 Abeele
Descripon
bull JSON13 format13 for13 signalling13 the13 servers13 capabilies
bull Signalling13 of13 supported13 opons13 media13 types13 and13 block13 sizendash Other13 items13 can13 be13 added
bull Filtering13 on13 specific13 fields13 through13 URI-shy‐Querybull Link13 hqpdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐profile-shy‐descripon
well-shy‐knownprofile
bull To13 acquire13 profile13 data13 of13 resources13 on13 a13 parcular13 service13 the13 well-shy‐knownprofile13 URI-shy‐path13 is13 introduced
bull For13 example13 to13 get13 all13 informaon13 from13 sensors13 served13 by13 wwwexampleorg13 we13 can13 do13 a13 GET13 to13 coapwwwexampleorgwell-shy‐knownprofile
bull Filtering13 on13 parcular13 resources13 is13 done13 through13 URI-shy‐Queries
Format
bull Currently13 the13 following13 fields13 are13 definedndash ldquopathrdquo13 contains13 the13 URI-shy‐path13 associated13 with13 a13 resource
ndash ldquooprdquo13 a13 numerical13 list13 of13 supported13 opon13 numbers
ndash ldquocfrdquo13 a13 numerical13 list13 of13 supported13 content-shy‐format13 numbers
ndash ldquob1srdquo13 ldquob2srdquo13 supported13 block13 sizes13 for13 Block113 and13 Block213 respecvely
Examplebull On13 the13 right13 is13 an13 example13 of13 a13 camera13 sensor13 at13 coapwwwexampleorgcam13 that13 supports13 the13 Uri-shy‐Host13 (3)13 ETag13 (4)13 Uri-shy‐Port13 (7)13 Uri-shy‐Path13 (11)13 Content-shy‐Format13 (12)13 Token13 (19)13 Block213 (23)13 and13 Proxy-shy‐Uri13 (35)13 opons
bull The13 supported13 content13 formats13 are13 textplain13 (0)13 applicaon13 link-shy‐format13 (40)13 and13 applicaonjson13 (50)
bull The13 supported13 Block213 can13 use13 25613 or13 51213 byte13 blocks
Req13 GET13 coapwwwexampleorgwell-shy‐knownprofile13 Res13 20513 Content13 (applicationjson)13 13 13 13 profile13 13 13 13 13 13 13 13 pathcam13 13 13 13 op[3471112192335]13 13 13 13 13 cf[04050]13 13 13 13 13 b2s[45]13 13 13 13
Filtering13 through13 use13 of13 URI-shy‐Query
bull Filtering13 can13 be13 done13 through13 the13 URI-shy‐Querybull Query13 format13 N=V
ndash N13 is13 a13 profile13 fieldndash V13 is13 the13 desired13 value
bull Examplesndash To13 find13 resources13 that13 support13 content13 format13 ldquoapplicaonjsonrdquo
13 GET13 wwwexampleorgwell-shy‐knownprofilecf=50ndash To13 get13 informaon13 about13 the13 camera
13 GET13 wwwexampleorgwell-shy‐knownprofilepath=cam
Open13 issues
bull Which13 other13 profile13 data13 needs13 signallingndash Content-shy‐type13 for13 different13 methods
bull Fix13 the13 order13 in13 which13 the13 profile13 fields13 must13 appearndash Non-shy‐fixed13 order13 easier13 extensible
bull Inheritance13 of13 a13 profile13 descriponbull Extend13 usage13 to13 signal13 the13 client13 profilebull Integraon13 with13 link13 format
Thank13 youQuesons
drar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval-shy‐00
Bert13 Greevenbosch
Descripon
bull The13 ldquoMinimumRequestInterval13 opon13 can13 be13 used13 to13 indicate13 the13 minimum13 me13 between13 two13 requests13 in13 a13 transacon
bull Originally13 intended13 for13 Block13 but13 also13 usable13 for13 other13 transaconsndash Example13 browsing13 a13 server
bull The13 goal13 is13 to13 reduce13 the13 server13 load13 and13 network13 traffic
bull Link13 hqpsdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval
Usage
bull The13 client13 keeps13 the13 server13 informed13 about13 its13 request13 speed13 through13 inclusion13 of13 the13 ldquoMinimumRequestIntervalrdquo13 opon
bull In13 responses13 the13 server13 fixes13 the13 minimum13 request13 interval13 through13 the13 same13 opon
bull The13 client13 obeys13 the13 speed13 indicated13 by13 the13 server
bull The13 client13 can13 send13 slower13 but13 not13 faster
Advantages
bull The13 server13 has13 means13 to13 limit13 the13 amount13 of13 incoming13 traffic
bull The13 server13 can13 prevent13 to13 become13 overloaded13 with13 too13 many13 tasks
bull The13 server13 does13 not13 need13 arficially13 slow13 down13 the13 client13 by13 sending13 late13 ACKsndash No13 need13 to13 keep13 track13 of13 delayed13 ACKsndash The13 server13 can13 perform13 other13 tasks13 instead
bull Reduced13 network13 traffic
Thank13 youQuesons
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-links-json-02txt
123
RFC 6690 (link-format) documents are somewhat foreign to many web app developerssect would prefer to have them in JSON format
There is no standard way to represent link-format documents in applicationssect but everyone knows how to handle JSON
Define a standard JSON translation for link-format
Itrsquos
not
rock
et
scien
ce
ltsensorsgtct=40title=Sensor Index ltsensorstempgtrt=temperature-cif=sensor ltsensorslightgtrt=light-luxif=sensor lthttpwwwexamplecomsensorst123gt anchor=sensorstemprel=describedby lttgtanchor=sensorstemprel=alternate [hrefsensorsct40titleSensor Index hrefsensorstemprttemperature-cifsensor hrefsensorslightrtlight-luxifsensor hrefhttpwwwexamplecomsensorst123 anchorsensorstempreldescribedby hreftanchorsensorstemprelalternate]
124
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-ipsec-for-coap-00txt
IPsec definitions for CoAP Mostly placeholder at this time Who has implementation experience with this
125
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-cross-reverse-convention-00txt
This draft has two lines of payload(based on a WGLC comment by Cullen Jennings)
coap12344567foobara=3
httpwwwproxycomwellknowncore-translate1234_4567foobara=3
Is that a useful convention to have
126
Insert CI slides here
127
128
0
5
10
15
20
25
30
35
40
10 20 30 40 50 60 70
good
put (
pps)
pps
Goodput vs pps (Econotags)
goodput
[Khattak preliminary]
Congestion Control
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-cocoa-00txt
ldquoadvancedrdquo cc (The draft is just a first shot) Others may have better ideas
129
Insert post-WGLC discussion slides here
130
Stop Continue Start
131
An Agile Retrospective
http6lowappnet coreIETF86 2013-03-12-13
Stop
132
Endless new CoAP optionssect instead use RESTful as much as possible
Move general security lifecycle out Looking at theoretical problems
http6lowappnet coreIETF86 2013-03-12-13
Continue
Interops Running code Look at real-world examples and deployments Solve their actual problems
sect Unilateral enhancements eg higher performance congestion control
sect Transports (SMS hellip)sect Make Web linking and Directories more and more usefulsect RESTful Design Paradigms for real-world problems
133
http6lowappnet coreIETF86 2013-03-12-13
Start
Further push into the (browser) web world (HTML5 browser security)
Specific supporting worksect SenMLsect URI work (dev URN hellip)sect Security Processes (next slide)
Spin outsect (We donrsquot really get to decide where this is done)
134
http6lowappnet coreIETF86 2013-03-12-13
Security
Integrate Application Network Group Keyingsect Tunnel-free setup
Donrsquot redo what has been done alreadysect ZigBee IP is finesect But what about other scenarios
Simple REST interfaces for working with keying materials and authorizationsect Start with defining objectives
Object Security for Constrained Nodes135
Re-chartering CoREWhat do we want to do now that wersquore grown up
Zach ShelbyCoRE WG IETF-86 Orlando
What is the scope
bull So we have a protocol and Web Linking what next
bull Keep with what we know besthellip1 Enhancements around CoAP2 New transports for CoAP3 New representations for Web Links4 General application layer solutions
CoRE WG IETF-86 Orlando 2
Enhancements around CoAP
bull Advanced congestion control
CoRE WG IETF-86 Orlando 3
New Transports for CoAP
bull Infrastructure for CoAP over foondash httptoolsietforgiddraft-silverajan-core-
coap-alternative-transports-01txtbull CoAP over SMS
ndash httptoolsietforgiddraft-becker-core-coap-sms-gprs-03txt
ndash OMA Lightweightbull CoAP over TCP
ndash httptoolsietforgiddraft-li-core-coap-payload-length-option-01txt
CoRE WG IETF-86 Orlando 4
New support for Web Links
bull JSON Web Linksndash httptoolsietforgiddraft-bormann-core-links-
json-02txt
2332010 CoRE WG IETF-77 Anaheim 5
General application layer solutions
bull Resource Directoryndash httptoolsietforgiddraft-shelby-core-
resource-directory-05txtndash OMA Lightweight
2332010 CoRE WG IETF-77 Anaheim 6
GET ndash Scenario 1 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
Scenarios 1a - Non-Sleepy Server Caching Proxy maxAge = 60sec 1b- Sleepy Server Caching Proxy maxAge = 60sec 1c - Sleepy Server Sleep Aware Proxy maxAge = 60sec
0
100
200
300
400
500
600
700
800
1a 1b 1c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
ldquoGETrdquo ndash Test Scenario 2 Results
maxAge = 60 and 5 Clients
GET ndash Scenario 2 ClientProxy Interface Transaction Mix
Sleep Aware Proxy has slightly better performance for sleepy servers
0
200
400
600
800
1000
1200
1400
2a 2b 2c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
Scenarios 2a - Non-Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2b- Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2c - Sleepy Server Sleep Aware Proxy maxAge = 60sec 5 Clients
See ldquoExperimental Artifactsrdquo Note 1
GET ndash Scenario 2 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has slightly better performance for sleepy servers
0
50
100
150
200
250
300
350
400
2a 2b 2c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
Scenarios 2a - Non-Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2b- Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2c - Sleepy Server Sleep Aware Proxy maxAge = 60sec 5 Clients
See ldquoExperimental Artifactsrdquo Note 2
Experimental Artifacts Note 1
Currently in the experiment the sleep aware proxy checks the cached state of a resource before putting a request into its Store-and-forward queue while a server is sleeping Once in the queue the proxy unconditionally forwards the queued requests to the server once it wakes up This is not the most efficient setup and can easily be improved If the proxy instead checks its cache again before forwarding each queued request it may not need to forward the request to the server For example if there are two queued GET requests in the proxyrsquos queue that address the same resource Only the first request needs to be sent to the server the second request can use the cached response from the first request
Note 2 Currently in the experiment the sleepy server sends a sleepState PUT request to the
proxy each time it goes to sleep This is not the most efficient setup and can easily be improved For example if the server assumes that the proxy can keep track of its ONOFF cycles with its internal timers (eg as per Fig 1 of I-D) then the number of messages from the sleepy server dramatically goes down
ldquoGETrdquo ndash Test Scenario 3 Results
maxAge = 5 and 5 Clients
GET ndash Scenario 3 ClientProxy Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
Scenarios 3a - Non-Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3b- Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3c - Sleepy Server Sleep Aware Proxy maxAge = 5sec 5 Clients
0
500
1000
1500
2000
2500
3000
3500
4000
4500
5000
3a 3b 3c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
GET ndash Scenario 3 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
0
1000
2000
3000
4000
5000
6000
7000
3a 3b 3c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
Scenarios 3a - Non-Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3b- Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3c - Sleepy Server Sleep Aware Proxy maxAge = 5sec 5 Clients
Conclusions
Conclusions These results show that sleep-aware CoAP
proxy features can significantly optimize communication with sleepy servers in most scenarios
These results also show that sleep-
awareness capabilities can provide additional benefits above and beyond CoAP caching in most scenarios
Backup
Current CoAP Support of Sleepy Node (12)
CoAP proxies can use a previously cached response to service a new GET request for a sleepy origin server (as in HTTP) But if no valid cache then proxy has to attempt to
retrieve and may fail if origin server is sleeping [I-Dietf-core-coap]
Clients can discover list of resources from RD (GET rd-lookuphellip) for sleepy servers But attempt to GET resource from sleepy origin server
may fail if origin server is sleeping [IDietf-core-link-format amp IDshelby-core-resource-
directory]
Current CoAP Support of Sleepy Node (22)
Lower layer support for sleepy nodes in most wireless technologies (eg WiFi ZigBee) But limited to MAC packet scheduling for sleepy nodes
and not aware of specific needs of IP applications (like CoAP)
Proposal ndash RD Based Sleep Tracking (14)
The current CoAP approach to support sleepy nodes can be significantly improved by introducing RD based mechanisms for a CoAP client to determine whether A targeted resource is located on a sleepy server A sleepy server is currently in sleep mode or not
There is any associated caching Proxy (possibly the RD itself) for a sleepy server
Proposal ndash RD Based Sleep Tracking (24)
We define the following new RD attributes to characterize the properties of a sleepy node SleepState - Indicates whether the node is currently in
sleep mode or not (ie Sleeping or Awake) SleepDuration - Indicates the maximum duration of time
that the node stays in sleep mode TimeSleeping - Indicates the length of time the node
has been sleeping (ie if Sleep State = Sleeping) NextSleep - Indicates the next time the node will go to
sleep (ie if Sleep State = Awake)
CachingProxy ndash Indicates the caching proxy of the sleepy node (ie the RD itself or another node)
Proposal ndash RD Based Sleep Tracking (34)
These attributes are all server (node) level and are new parameters added to the RD URI Template Variables
Finally we also define a new lookup-type (ss) for the RD lookup interface specified in [I-Dshelby-core-resource-directory] This new lookup-type supports looking up the
ldquoSleepStaterdquo (ss) of a specified end-point
Proposal ndash RD Based Sleep Tracking (44)
The three time based parameters (SleepDuration TimeSleeping NextSleep) can be based on either an absolute network time (for a time synchronized network) or a relative local time (measured at the local node)
Following the approach of [I-Dietf-core-link-format] and [I-Dshelby-core-resource-directory] sleep parameters for sleepy servers can be stored by the server in the RD and accessed by all interested clients
Examples of using these parameters in a synchronous or asynchronous manner are shown in the I-D
http6lowappnet coreIETF86 2013-03-12-13
We assume people have read the drafts
Meetings serve to advance difficult issues by making good use of face-to-face communications
Note Well Be aware of the IPR principles according to RFC 3979 and its updates
uumlBlue sheetsuumlScribe(s)
96
drar-shy‐iep-shy‐core-shy‐coapsubmiqed13 to13 IESG
2013-shy‐03-shy‐13
97
OMA Lightweight M2M Overview(A new standard using lots of IETF specs including DTLS
CoAP Block Observe Resource Directory SenMLhellip)
Zach ShelbyCoRE WG IETF-86 Orlando
OMA Lightweight M2Mbull Open Mobile Alliance is well known for Device Management (DM)bull OMA Lightweight M2M is a new standard from the alliance
ndash Focused on constrained Cellular and sensor network M2M devicesndash Driven by leading operators and vendors
bull Scopendash Interfaces protocol amp security between Device and Serverndash Object and Resource modelndash Bootstrap Device Access Control Connectivity and Firmware Objects
bull Draft Specifications are availablendash httpmemberopenmobileallianceorgftpPublic_documentsDM
LightweightM2MPermanent_documentsOMA-TS-LightweightM2M-V1_0_0-20130301-Dzip
bull Timelinendash Requirements and Architecture completed 3Q2012ndash Spec ready for Consistency Review 2Q2013ndash Candidate Approval expected 3Q2013
2 CoRE WG IETF-86 Orlando
Architecture
3
Scope of LWM2M
CoRE WG IETF-86 Orlando
Object Model
bull A Client has one or more Object Instancesbull An Object is a collection of Resourcesbull A Resource is an atomic piece of information
ndash Read Written or Executed
bull Resources can have multiple instancesbull Objects and Resources are identified by a
16-bit Integer Instances by an 8-bit Integerbull ObjectsResources are accessed with
simple URIs Object IDObject InstanceResource ID
eg 1213
4 CoRE WG IETF-86 Orlando
CoRE WG IETF-86 Orlando
CoRE Resource Directory
draft-shelby-core-resource-directory-05
Z Shelby C Bormann S Krco
Backgroundbull Not a new concept
ndash think web search engine or any link directorybull Defines the interfaces to a Resource Directorybull Based on Web Linking framework and the CoRE Link Formatbull Generic REST design for use over HTTP and CoAPbull Used by OMA Lightweight M2Mbull Has already been deployed
ndash In traffic monitoring systemsndash In street lighting systemsndash For vehicular asset trackingndash By a major Cellular M2M operator
Changes since -04
bull Restricted Update to parameter updatesbull Added pagination support for the Lookup interfacebull Changed rt= to et= for the registration amp update
interfacebull Added group support
Group Management
bull RD now includes group management featuresbull New Group Function Set
ndash Register a groupbull Group name domain multicast address endpoint members
ndash Remove a groupbull Group lookup using the Lookup Function Set
ndash List registered groupsndash Find the members of a groupndash Find groups with certain endpoints or resources
Registering a Group
EP RD
| |
| - POST rd-groupgp=lights ltgtep=node1 --gt |
| |
| |
| lt---- 201 Created Location rd-group12 ---- |
| |
Req POST coaprdexamplecomrd-groupgp=lights
Payload
ltgtep=node1
ltgtep=node2
Res 201 Created
Location rd-group12
Looking up Group Members
Client RD
| |
| ----- GET rd-lookupepgp=lights1 ----------------------gt |
| |
| |
| lt-- 205 Content ltrdgtd=domain1ltrdgtd=domain2 --------- |
| |
Req GET rd-lookupepgp=lights1
Res 205 Content
ltcoaphostportgtep=node1
ltcoaphostportgtep=node2rdquo
Things for the futurebull Support for JSON representation of Web Links
ndash httptoolsietforgiddraft-bormann-core-links-json-02txtbull Registry for RD registration query parameters
ndash Already OMA Lightweight has defined some new onesbull More examples
Group 3 ldquonew workrdquo(continued)
109
drar-shy‐greevenbosch-shy‐core-shy‐profile-shy‐descripon-shy‐01Bert13 GreevenboschJeroen13 Hoebeke
Isam13 IshaqFloris13 Van13 den13 Abeele
Descripon
bull JSON13 format13 for13 signalling13 the13 servers13 capabilies
bull Signalling13 of13 supported13 opons13 media13 types13 and13 block13 sizendash Other13 items13 can13 be13 added
bull Filtering13 on13 specific13 fields13 through13 URI-shy‐Querybull Link13 hqpdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐profile-shy‐descripon
well-shy‐knownprofile
bull To13 acquire13 profile13 data13 of13 resources13 on13 a13 parcular13 service13 the13 well-shy‐knownprofile13 URI-shy‐path13 is13 introduced
bull For13 example13 to13 get13 all13 informaon13 from13 sensors13 served13 by13 wwwexampleorg13 we13 can13 do13 a13 GET13 to13 coapwwwexampleorgwell-shy‐knownprofile
bull Filtering13 on13 parcular13 resources13 is13 done13 through13 URI-shy‐Queries
Format
bull Currently13 the13 following13 fields13 are13 definedndash ldquopathrdquo13 contains13 the13 URI-shy‐path13 associated13 with13 a13 resource
ndash ldquooprdquo13 a13 numerical13 list13 of13 supported13 opon13 numbers
ndash ldquocfrdquo13 a13 numerical13 list13 of13 supported13 content-shy‐format13 numbers
ndash ldquob1srdquo13 ldquob2srdquo13 supported13 block13 sizes13 for13 Block113 and13 Block213 respecvely
Examplebull On13 the13 right13 is13 an13 example13 of13 a13 camera13 sensor13 at13 coapwwwexampleorgcam13 that13 supports13 the13 Uri-shy‐Host13 (3)13 ETag13 (4)13 Uri-shy‐Port13 (7)13 Uri-shy‐Path13 (11)13 Content-shy‐Format13 (12)13 Token13 (19)13 Block213 (23)13 and13 Proxy-shy‐Uri13 (35)13 opons
bull The13 supported13 content13 formats13 are13 textplain13 (0)13 applicaon13 link-shy‐format13 (40)13 and13 applicaonjson13 (50)
bull The13 supported13 Block213 can13 use13 25613 or13 51213 byte13 blocks
Req13 GET13 coapwwwexampleorgwell-shy‐knownprofile13 Res13 20513 Content13 (applicationjson)13 13 13 13 profile13 13 13 13 13 13 13 13 pathcam13 13 13 13 op[3471112192335]13 13 13 13 13 cf[04050]13 13 13 13 13 b2s[45]13 13 13 13
Filtering13 through13 use13 of13 URI-shy‐Query
bull Filtering13 can13 be13 done13 through13 the13 URI-shy‐Querybull Query13 format13 N=V
ndash N13 is13 a13 profile13 fieldndash V13 is13 the13 desired13 value
bull Examplesndash To13 find13 resources13 that13 support13 content13 format13 ldquoapplicaonjsonrdquo
13 GET13 wwwexampleorgwell-shy‐knownprofilecf=50ndash To13 get13 informaon13 about13 the13 camera
13 GET13 wwwexampleorgwell-shy‐knownprofilepath=cam
Open13 issues
bull Which13 other13 profile13 data13 needs13 signallingndash Content-shy‐type13 for13 different13 methods
bull Fix13 the13 order13 in13 which13 the13 profile13 fields13 must13 appearndash Non-shy‐fixed13 order13 easier13 extensible
bull Inheritance13 of13 a13 profile13 descriponbull Extend13 usage13 to13 signal13 the13 client13 profilebull Integraon13 with13 link13 format
Thank13 youQuesons
drar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval-shy‐00
Bert13 Greevenbosch
Descripon
bull The13 ldquoMinimumRequestInterval13 opon13 can13 be13 used13 to13 indicate13 the13 minimum13 me13 between13 two13 requests13 in13 a13 transacon
bull Originally13 intended13 for13 Block13 but13 also13 usable13 for13 other13 transaconsndash Example13 browsing13 a13 server
bull The13 goal13 is13 to13 reduce13 the13 server13 load13 and13 network13 traffic
bull Link13 hqpsdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval
Usage
bull The13 client13 keeps13 the13 server13 informed13 about13 its13 request13 speed13 through13 inclusion13 of13 the13 ldquoMinimumRequestIntervalrdquo13 opon
bull In13 responses13 the13 server13 fixes13 the13 minimum13 request13 interval13 through13 the13 same13 opon
bull The13 client13 obeys13 the13 speed13 indicated13 by13 the13 server
bull The13 client13 can13 send13 slower13 but13 not13 faster
Advantages
bull The13 server13 has13 means13 to13 limit13 the13 amount13 of13 incoming13 traffic
bull The13 server13 can13 prevent13 to13 become13 overloaded13 with13 too13 many13 tasks
bull The13 server13 does13 not13 need13 arficially13 slow13 down13 the13 client13 by13 sending13 late13 ACKsndash No13 need13 to13 keep13 track13 of13 delayed13 ACKsndash The13 server13 can13 perform13 other13 tasks13 instead
bull Reduced13 network13 traffic
Thank13 youQuesons
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-links-json-02txt
123
RFC 6690 (link-format) documents are somewhat foreign to many web app developerssect would prefer to have them in JSON format
There is no standard way to represent link-format documents in applicationssect but everyone knows how to handle JSON
Define a standard JSON translation for link-format
Itrsquos
not
rock
et
scien
ce
ltsensorsgtct=40title=Sensor Index ltsensorstempgtrt=temperature-cif=sensor ltsensorslightgtrt=light-luxif=sensor lthttpwwwexamplecomsensorst123gt anchor=sensorstemprel=describedby lttgtanchor=sensorstemprel=alternate [hrefsensorsct40titleSensor Index hrefsensorstemprttemperature-cifsensor hrefsensorslightrtlight-luxifsensor hrefhttpwwwexamplecomsensorst123 anchorsensorstempreldescribedby hreftanchorsensorstemprelalternate]
124
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-ipsec-for-coap-00txt
IPsec definitions for CoAP Mostly placeholder at this time Who has implementation experience with this
125
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-cross-reverse-convention-00txt
This draft has two lines of payload(based on a WGLC comment by Cullen Jennings)
coap12344567foobara=3
httpwwwproxycomwellknowncore-translate1234_4567foobara=3
Is that a useful convention to have
126
Insert CI slides here
127
128
0
5
10
15
20
25
30
35
40
10 20 30 40 50 60 70
good
put (
pps)
pps
Goodput vs pps (Econotags)
goodput
[Khattak preliminary]
Congestion Control
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-cocoa-00txt
ldquoadvancedrdquo cc (The draft is just a first shot) Others may have better ideas
129
Insert post-WGLC discussion slides here
130
Stop Continue Start
131
An Agile Retrospective
http6lowappnet coreIETF86 2013-03-12-13
Stop
132
Endless new CoAP optionssect instead use RESTful as much as possible
Move general security lifecycle out Looking at theoretical problems
http6lowappnet coreIETF86 2013-03-12-13
Continue
Interops Running code Look at real-world examples and deployments Solve their actual problems
sect Unilateral enhancements eg higher performance congestion control
sect Transports (SMS hellip)sect Make Web linking and Directories more and more usefulsect RESTful Design Paradigms for real-world problems
133
http6lowappnet coreIETF86 2013-03-12-13
Start
Further push into the (browser) web world (HTML5 browser security)
Specific supporting worksect SenMLsect URI work (dev URN hellip)sect Security Processes (next slide)
Spin outsect (We donrsquot really get to decide where this is done)
134
http6lowappnet coreIETF86 2013-03-12-13
Security
Integrate Application Network Group Keyingsect Tunnel-free setup
Donrsquot redo what has been done alreadysect ZigBee IP is finesect But what about other scenarios
Simple REST interfaces for working with keying materials and authorizationsect Start with defining objectives
Object Security for Constrained Nodes135
Re-chartering CoREWhat do we want to do now that wersquore grown up
Zach ShelbyCoRE WG IETF-86 Orlando
What is the scope
bull So we have a protocol and Web Linking what next
bull Keep with what we know besthellip1 Enhancements around CoAP2 New transports for CoAP3 New representations for Web Links4 General application layer solutions
CoRE WG IETF-86 Orlando 2
Enhancements around CoAP
bull Advanced congestion control
CoRE WG IETF-86 Orlando 3
New Transports for CoAP
bull Infrastructure for CoAP over foondash httptoolsietforgiddraft-silverajan-core-
coap-alternative-transports-01txtbull CoAP over SMS
ndash httptoolsietforgiddraft-becker-core-coap-sms-gprs-03txt
ndash OMA Lightweightbull CoAP over TCP
ndash httptoolsietforgiddraft-li-core-coap-payload-length-option-01txt
CoRE WG IETF-86 Orlando 4
New support for Web Links
bull JSON Web Linksndash httptoolsietforgiddraft-bormann-core-links-
json-02txt
2332010 CoRE WG IETF-77 Anaheim 5
General application layer solutions
bull Resource Directoryndash httptoolsietforgiddraft-shelby-core-
resource-directory-05txtndash OMA Lightweight
2332010 CoRE WG IETF-77 Anaheim 6
ldquoGETrdquo ndash Test Scenario 2 Results
maxAge = 60 and 5 Clients
GET ndash Scenario 2 ClientProxy Interface Transaction Mix
Sleep Aware Proxy has slightly better performance for sleepy servers
0
200
400
600
800
1000
1200
1400
2a 2b 2c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
Scenarios 2a - Non-Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2b- Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2c - Sleepy Server Sleep Aware Proxy maxAge = 60sec 5 Clients
See ldquoExperimental Artifactsrdquo Note 1
GET ndash Scenario 2 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has slightly better performance for sleepy servers
0
50
100
150
200
250
300
350
400
2a 2b 2c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
Scenarios 2a - Non-Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2b- Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2c - Sleepy Server Sleep Aware Proxy maxAge = 60sec 5 Clients
See ldquoExperimental Artifactsrdquo Note 2
Experimental Artifacts Note 1
Currently in the experiment the sleep aware proxy checks the cached state of a resource before putting a request into its Store-and-forward queue while a server is sleeping Once in the queue the proxy unconditionally forwards the queued requests to the server once it wakes up This is not the most efficient setup and can easily be improved If the proxy instead checks its cache again before forwarding each queued request it may not need to forward the request to the server For example if there are two queued GET requests in the proxyrsquos queue that address the same resource Only the first request needs to be sent to the server the second request can use the cached response from the first request
Note 2 Currently in the experiment the sleepy server sends a sleepState PUT request to the
proxy each time it goes to sleep This is not the most efficient setup and can easily be improved For example if the server assumes that the proxy can keep track of its ONOFF cycles with its internal timers (eg as per Fig 1 of I-D) then the number of messages from the sleepy server dramatically goes down
ldquoGETrdquo ndash Test Scenario 3 Results
maxAge = 5 and 5 Clients
GET ndash Scenario 3 ClientProxy Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
Scenarios 3a - Non-Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3b- Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3c - Sleepy Server Sleep Aware Proxy maxAge = 5sec 5 Clients
0
500
1000
1500
2000
2500
3000
3500
4000
4500
5000
3a 3b 3c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
GET ndash Scenario 3 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
0
1000
2000
3000
4000
5000
6000
7000
3a 3b 3c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
Scenarios 3a - Non-Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3b- Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3c - Sleepy Server Sleep Aware Proxy maxAge = 5sec 5 Clients
Conclusions
Conclusions These results show that sleep-aware CoAP
proxy features can significantly optimize communication with sleepy servers in most scenarios
These results also show that sleep-
awareness capabilities can provide additional benefits above and beyond CoAP caching in most scenarios
Backup
Current CoAP Support of Sleepy Node (12)
CoAP proxies can use a previously cached response to service a new GET request for a sleepy origin server (as in HTTP) But if no valid cache then proxy has to attempt to
retrieve and may fail if origin server is sleeping [I-Dietf-core-coap]
Clients can discover list of resources from RD (GET rd-lookuphellip) for sleepy servers But attempt to GET resource from sleepy origin server
may fail if origin server is sleeping [IDietf-core-link-format amp IDshelby-core-resource-
directory]
Current CoAP Support of Sleepy Node (22)
Lower layer support for sleepy nodes in most wireless technologies (eg WiFi ZigBee) But limited to MAC packet scheduling for sleepy nodes
and not aware of specific needs of IP applications (like CoAP)
Proposal ndash RD Based Sleep Tracking (14)
The current CoAP approach to support sleepy nodes can be significantly improved by introducing RD based mechanisms for a CoAP client to determine whether A targeted resource is located on a sleepy server A sleepy server is currently in sleep mode or not
There is any associated caching Proxy (possibly the RD itself) for a sleepy server
Proposal ndash RD Based Sleep Tracking (24)
We define the following new RD attributes to characterize the properties of a sleepy node SleepState - Indicates whether the node is currently in
sleep mode or not (ie Sleeping or Awake) SleepDuration - Indicates the maximum duration of time
that the node stays in sleep mode TimeSleeping - Indicates the length of time the node
has been sleeping (ie if Sleep State = Sleeping) NextSleep - Indicates the next time the node will go to
sleep (ie if Sleep State = Awake)
CachingProxy ndash Indicates the caching proxy of the sleepy node (ie the RD itself or another node)
Proposal ndash RD Based Sleep Tracking (34)
These attributes are all server (node) level and are new parameters added to the RD URI Template Variables
Finally we also define a new lookup-type (ss) for the RD lookup interface specified in [I-Dshelby-core-resource-directory] This new lookup-type supports looking up the
ldquoSleepStaterdquo (ss) of a specified end-point
Proposal ndash RD Based Sleep Tracking (44)
The three time based parameters (SleepDuration TimeSleeping NextSleep) can be based on either an absolute network time (for a time synchronized network) or a relative local time (measured at the local node)
Following the approach of [I-Dietf-core-link-format] and [I-Dshelby-core-resource-directory] sleep parameters for sleepy servers can be stored by the server in the RD and accessed by all interested clients
Examples of using these parameters in a synchronous or asynchronous manner are shown in the I-D
http6lowappnet coreIETF86 2013-03-12-13
We assume people have read the drafts
Meetings serve to advance difficult issues by making good use of face-to-face communications
Note Well Be aware of the IPR principles according to RFC 3979 and its updates
uumlBlue sheetsuumlScribe(s)
96
drar-shy‐iep-shy‐core-shy‐coapsubmiqed13 to13 IESG
2013-shy‐03-shy‐13
97
OMA Lightweight M2M Overview(A new standard using lots of IETF specs including DTLS
CoAP Block Observe Resource Directory SenMLhellip)
Zach ShelbyCoRE WG IETF-86 Orlando
OMA Lightweight M2Mbull Open Mobile Alliance is well known for Device Management (DM)bull OMA Lightweight M2M is a new standard from the alliance
ndash Focused on constrained Cellular and sensor network M2M devicesndash Driven by leading operators and vendors
bull Scopendash Interfaces protocol amp security between Device and Serverndash Object and Resource modelndash Bootstrap Device Access Control Connectivity and Firmware Objects
bull Draft Specifications are availablendash httpmemberopenmobileallianceorgftpPublic_documentsDM
LightweightM2MPermanent_documentsOMA-TS-LightweightM2M-V1_0_0-20130301-Dzip
bull Timelinendash Requirements and Architecture completed 3Q2012ndash Spec ready for Consistency Review 2Q2013ndash Candidate Approval expected 3Q2013
2 CoRE WG IETF-86 Orlando
Architecture
3
Scope of LWM2M
CoRE WG IETF-86 Orlando
Object Model
bull A Client has one or more Object Instancesbull An Object is a collection of Resourcesbull A Resource is an atomic piece of information
ndash Read Written or Executed
bull Resources can have multiple instancesbull Objects and Resources are identified by a
16-bit Integer Instances by an 8-bit Integerbull ObjectsResources are accessed with
simple URIs Object IDObject InstanceResource ID
eg 1213
4 CoRE WG IETF-86 Orlando
CoRE WG IETF-86 Orlando
CoRE Resource Directory
draft-shelby-core-resource-directory-05
Z Shelby C Bormann S Krco
Backgroundbull Not a new concept
ndash think web search engine or any link directorybull Defines the interfaces to a Resource Directorybull Based on Web Linking framework and the CoRE Link Formatbull Generic REST design for use over HTTP and CoAPbull Used by OMA Lightweight M2Mbull Has already been deployed
ndash In traffic monitoring systemsndash In street lighting systemsndash For vehicular asset trackingndash By a major Cellular M2M operator
Changes since -04
bull Restricted Update to parameter updatesbull Added pagination support for the Lookup interfacebull Changed rt= to et= for the registration amp update
interfacebull Added group support
Group Management
bull RD now includes group management featuresbull New Group Function Set
ndash Register a groupbull Group name domain multicast address endpoint members
ndash Remove a groupbull Group lookup using the Lookup Function Set
ndash List registered groupsndash Find the members of a groupndash Find groups with certain endpoints or resources
Registering a Group
EP RD
| |
| - POST rd-groupgp=lights ltgtep=node1 --gt |
| |
| |
| lt---- 201 Created Location rd-group12 ---- |
| |
Req POST coaprdexamplecomrd-groupgp=lights
Payload
ltgtep=node1
ltgtep=node2
Res 201 Created
Location rd-group12
Looking up Group Members
Client RD
| |
| ----- GET rd-lookupepgp=lights1 ----------------------gt |
| |
| |
| lt-- 205 Content ltrdgtd=domain1ltrdgtd=domain2 --------- |
| |
Req GET rd-lookupepgp=lights1
Res 205 Content
ltcoaphostportgtep=node1
ltcoaphostportgtep=node2rdquo
Things for the futurebull Support for JSON representation of Web Links
ndash httptoolsietforgiddraft-bormann-core-links-json-02txtbull Registry for RD registration query parameters
ndash Already OMA Lightweight has defined some new onesbull More examples
Group 3 ldquonew workrdquo(continued)
109
drar-shy‐greevenbosch-shy‐core-shy‐profile-shy‐descripon-shy‐01Bert13 GreevenboschJeroen13 Hoebeke
Isam13 IshaqFloris13 Van13 den13 Abeele
Descripon
bull JSON13 format13 for13 signalling13 the13 servers13 capabilies
bull Signalling13 of13 supported13 opons13 media13 types13 and13 block13 sizendash Other13 items13 can13 be13 added
bull Filtering13 on13 specific13 fields13 through13 URI-shy‐Querybull Link13 hqpdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐profile-shy‐descripon
well-shy‐knownprofile
bull To13 acquire13 profile13 data13 of13 resources13 on13 a13 parcular13 service13 the13 well-shy‐knownprofile13 URI-shy‐path13 is13 introduced
bull For13 example13 to13 get13 all13 informaon13 from13 sensors13 served13 by13 wwwexampleorg13 we13 can13 do13 a13 GET13 to13 coapwwwexampleorgwell-shy‐knownprofile
bull Filtering13 on13 parcular13 resources13 is13 done13 through13 URI-shy‐Queries
Format
bull Currently13 the13 following13 fields13 are13 definedndash ldquopathrdquo13 contains13 the13 URI-shy‐path13 associated13 with13 a13 resource
ndash ldquooprdquo13 a13 numerical13 list13 of13 supported13 opon13 numbers
ndash ldquocfrdquo13 a13 numerical13 list13 of13 supported13 content-shy‐format13 numbers
ndash ldquob1srdquo13 ldquob2srdquo13 supported13 block13 sizes13 for13 Block113 and13 Block213 respecvely
Examplebull On13 the13 right13 is13 an13 example13 of13 a13 camera13 sensor13 at13 coapwwwexampleorgcam13 that13 supports13 the13 Uri-shy‐Host13 (3)13 ETag13 (4)13 Uri-shy‐Port13 (7)13 Uri-shy‐Path13 (11)13 Content-shy‐Format13 (12)13 Token13 (19)13 Block213 (23)13 and13 Proxy-shy‐Uri13 (35)13 opons
bull The13 supported13 content13 formats13 are13 textplain13 (0)13 applicaon13 link-shy‐format13 (40)13 and13 applicaonjson13 (50)
bull The13 supported13 Block213 can13 use13 25613 or13 51213 byte13 blocks
Req13 GET13 coapwwwexampleorgwell-shy‐knownprofile13 Res13 20513 Content13 (applicationjson)13 13 13 13 profile13 13 13 13 13 13 13 13 pathcam13 13 13 13 op[3471112192335]13 13 13 13 13 cf[04050]13 13 13 13 13 b2s[45]13 13 13 13
Filtering13 through13 use13 of13 URI-shy‐Query
bull Filtering13 can13 be13 done13 through13 the13 URI-shy‐Querybull Query13 format13 N=V
ndash N13 is13 a13 profile13 fieldndash V13 is13 the13 desired13 value
bull Examplesndash To13 find13 resources13 that13 support13 content13 format13 ldquoapplicaonjsonrdquo
13 GET13 wwwexampleorgwell-shy‐knownprofilecf=50ndash To13 get13 informaon13 about13 the13 camera
13 GET13 wwwexampleorgwell-shy‐knownprofilepath=cam
Open13 issues
bull Which13 other13 profile13 data13 needs13 signallingndash Content-shy‐type13 for13 different13 methods
bull Fix13 the13 order13 in13 which13 the13 profile13 fields13 must13 appearndash Non-shy‐fixed13 order13 easier13 extensible
bull Inheritance13 of13 a13 profile13 descriponbull Extend13 usage13 to13 signal13 the13 client13 profilebull Integraon13 with13 link13 format
Thank13 youQuesons
drar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval-shy‐00
Bert13 Greevenbosch
Descripon
bull The13 ldquoMinimumRequestInterval13 opon13 can13 be13 used13 to13 indicate13 the13 minimum13 me13 between13 two13 requests13 in13 a13 transacon
bull Originally13 intended13 for13 Block13 but13 also13 usable13 for13 other13 transaconsndash Example13 browsing13 a13 server
bull The13 goal13 is13 to13 reduce13 the13 server13 load13 and13 network13 traffic
bull Link13 hqpsdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval
Usage
bull The13 client13 keeps13 the13 server13 informed13 about13 its13 request13 speed13 through13 inclusion13 of13 the13 ldquoMinimumRequestIntervalrdquo13 opon
bull In13 responses13 the13 server13 fixes13 the13 minimum13 request13 interval13 through13 the13 same13 opon
bull The13 client13 obeys13 the13 speed13 indicated13 by13 the13 server
bull The13 client13 can13 send13 slower13 but13 not13 faster
Advantages
bull The13 server13 has13 means13 to13 limit13 the13 amount13 of13 incoming13 traffic
bull The13 server13 can13 prevent13 to13 become13 overloaded13 with13 too13 many13 tasks
bull The13 server13 does13 not13 need13 arficially13 slow13 down13 the13 client13 by13 sending13 late13 ACKsndash No13 need13 to13 keep13 track13 of13 delayed13 ACKsndash The13 server13 can13 perform13 other13 tasks13 instead
bull Reduced13 network13 traffic
Thank13 youQuesons
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-links-json-02txt
123
RFC 6690 (link-format) documents are somewhat foreign to many web app developerssect would prefer to have them in JSON format
There is no standard way to represent link-format documents in applicationssect but everyone knows how to handle JSON
Define a standard JSON translation for link-format
Itrsquos
not
rock
et
scien
ce
ltsensorsgtct=40title=Sensor Index ltsensorstempgtrt=temperature-cif=sensor ltsensorslightgtrt=light-luxif=sensor lthttpwwwexamplecomsensorst123gt anchor=sensorstemprel=describedby lttgtanchor=sensorstemprel=alternate [hrefsensorsct40titleSensor Index hrefsensorstemprttemperature-cifsensor hrefsensorslightrtlight-luxifsensor hrefhttpwwwexamplecomsensorst123 anchorsensorstempreldescribedby hreftanchorsensorstemprelalternate]
124
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-ipsec-for-coap-00txt
IPsec definitions for CoAP Mostly placeholder at this time Who has implementation experience with this
125
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-cross-reverse-convention-00txt
This draft has two lines of payload(based on a WGLC comment by Cullen Jennings)
coap12344567foobara=3
httpwwwproxycomwellknowncore-translate1234_4567foobara=3
Is that a useful convention to have
126
Insert CI slides here
127
128
0
5
10
15
20
25
30
35
40
10 20 30 40 50 60 70
good
put (
pps)
pps
Goodput vs pps (Econotags)
goodput
[Khattak preliminary]
Congestion Control
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-cocoa-00txt
ldquoadvancedrdquo cc (The draft is just a first shot) Others may have better ideas
129
Insert post-WGLC discussion slides here
130
Stop Continue Start
131
An Agile Retrospective
http6lowappnet coreIETF86 2013-03-12-13
Stop
132
Endless new CoAP optionssect instead use RESTful as much as possible
Move general security lifecycle out Looking at theoretical problems
http6lowappnet coreIETF86 2013-03-12-13
Continue
Interops Running code Look at real-world examples and deployments Solve their actual problems
sect Unilateral enhancements eg higher performance congestion control
sect Transports (SMS hellip)sect Make Web linking and Directories more and more usefulsect RESTful Design Paradigms for real-world problems
133
http6lowappnet coreIETF86 2013-03-12-13
Start
Further push into the (browser) web world (HTML5 browser security)
Specific supporting worksect SenMLsect URI work (dev URN hellip)sect Security Processes (next slide)
Spin outsect (We donrsquot really get to decide where this is done)
134
http6lowappnet coreIETF86 2013-03-12-13
Security
Integrate Application Network Group Keyingsect Tunnel-free setup
Donrsquot redo what has been done alreadysect ZigBee IP is finesect But what about other scenarios
Simple REST interfaces for working with keying materials and authorizationsect Start with defining objectives
Object Security for Constrained Nodes135
Re-chartering CoREWhat do we want to do now that wersquore grown up
Zach ShelbyCoRE WG IETF-86 Orlando
What is the scope
bull So we have a protocol and Web Linking what next
bull Keep with what we know besthellip1 Enhancements around CoAP2 New transports for CoAP3 New representations for Web Links4 General application layer solutions
CoRE WG IETF-86 Orlando 2
Enhancements around CoAP
bull Advanced congestion control
CoRE WG IETF-86 Orlando 3
New Transports for CoAP
bull Infrastructure for CoAP over foondash httptoolsietforgiddraft-silverajan-core-
coap-alternative-transports-01txtbull CoAP over SMS
ndash httptoolsietforgiddraft-becker-core-coap-sms-gprs-03txt
ndash OMA Lightweightbull CoAP over TCP
ndash httptoolsietforgiddraft-li-core-coap-payload-length-option-01txt
CoRE WG IETF-86 Orlando 4
New support for Web Links
bull JSON Web Linksndash httptoolsietforgiddraft-bormann-core-links-
json-02txt
2332010 CoRE WG IETF-77 Anaheim 5
General application layer solutions
bull Resource Directoryndash httptoolsietforgiddraft-shelby-core-
resource-directory-05txtndash OMA Lightweight
2332010 CoRE WG IETF-77 Anaheim 6
GET ndash Scenario 2 ClientProxy Interface Transaction Mix
Sleep Aware Proxy has slightly better performance for sleepy servers
0
200
400
600
800
1000
1200
1400
2a 2b 2c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
Scenarios 2a - Non-Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2b- Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2c - Sleepy Server Sleep Aware Proxy maxAge = 60sec 5 Clients
See ldquoExperimental Artifactsrdquo Note 1
GET ndash Scenario 2 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has slightly better performance for sleepy servers
0
50
100
150
200
250
300
350
400
2a 2b 2c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
Scenarios 2a - Non-Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2b- Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2c - Sleepy Server Sleep Aware Proxy maxAge = 60sec 5 Clients
See ldquoExperimental Artifactsrdquo Note 2
Experimental Artifacts Note 1
Currently in the experiment the sleep aware proxy checks the cached state of a resource before putting a request into its Store-and-forward queue while a server is sleeping Once in the queue the proxy unconditionally forwards the queued requests to the server once it wakes up This is not the most efficient setup and can easily be improved If the proxy instead checks its cache again before forwarding each queued request it may not need to forward the request to the server For example if there are two queued GET requests in the proxyrsquos queue that address the same resource Only the first request needs to be sent to the server the second request can use the cached response from the first request
Note 2 Currently in the experiment the sleepy server sends a sleepState PUT request to the
proxy each time it goes to sleep This is not the most efficient setup and can easily be improved For example if the server assumes that the proxy can keep track of its ONOFF cycles with its internal timers (eg as per Fig 1 of I-D) then the number of messages from the sleepy server dramatically goes down
ldquoGETrdquo ndash Test Scenario 3 Results
maxAge = 5 and 5 Clients
GET ndash Scenario 3 ClientProxy Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
Scenarios 3a - Non-Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3b- Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3c - Sleepy Server Sleep Aware Proxy maxAge = 5sec 5 Clients
0
500
1000
1500
2000
2500
3000
3500
4000
4500
5000
3a 3b 3c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
GET ndash Scenario 3 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
0
1000
2000
3000
4000
5000
6000
7000
3a 3b 3c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
Scenarios 3a - Non-Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3b- Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3c - Sleepy Server Sleep Aware Proxy maxAge = 5sec 5 Clients
Conclusions
Conclusions These results show that sleep-aware CoAP
proxy features can significantly optimize communication with sleepy servers in most scenarios
These results also show that sleep-
awareness capabilities can provide additional benefits above and beyond CoAP caching in most scenarios
Backup
Current CoAP Support of Sleepy Node (12)
CoAP proxies can use a previously cached response to service a new GET request for a sleepy origin server (as in HTTP) But if no valid cache then proxy has to attempt to
retrieve and may fail if origin server is sleeping [I-Dietf-core-coap]
Clients can discover list of resources from RD (GET rd-lookuphellip) for sleepy servers But attempt to GET resource from sleepy origin server
may fail if origin server is sleeping [IDietf-core-link-format amp IDshelby-core-resource-
directory]
Current CoAP Support of Sleepy Node (22)
Lower layer support for sleepy nodes in most wireless technologies (eg WiFi ZigBee) But limited to MAC packet scheduling for sleepy nodes
and not aware of specific needs of IP applications (like CoAP)
Proposal ndash RD Based Sleep Tracking (14)
The current CoAP approach to support sleepy nodes can be significantly improved by introducing RD based mechanisms for a CoAP client to determine whether A targeted resource is located on a sleepy server A sleepy server is currently in sleep mode or not
There is any associated caching Proxy (possibly the RD itself) for a sleepy server
Proposal ndash RD Based Sleep Tracking (24)
We define the following new RD attributes to characterize the properties of a sleepy node SleepState - Indicates whether the node is currently in
sleep mode or not (ie Sleeping or Awake) SleepDuration - Indicates the maximum duration of time
that the node stays in sleep mode TimeSleeping - Indicates the length of time the node
has been sleeping (ie if Sleep State = Sleeping) NextSleep - Indicates the next time the node will go to
sleep (ie if Sleep State = Awake)
CachingProxy ndash Indicates the caching proxy of the sleepy node (ie the RD itself or another node)
Proposal ndash RD Based Sleep Tracking (34)
These attributes are all server (node) level and are new parameters added to the RD URI Template Variables
Finally we also define a new lookup-type (ss) for the RD lookup interface specified in [I-Dshelby-core-resource-directory] This new lookup-type supports looking up the
ldquoSleepStaterdquo (ss) of a specified end-point
Proposal ndash RD Based Sleep Tracking (44)
The three time based parameters (SleepDuration TimeSleeping NextSleep) can be based on either an absolute network time (for a time synchronized network) or a relative local time (measured at the local node)
Following the approach of [I-Dietf-core-link-format] and [I-Dshelby-core-resource-directory] sleep parameters for sleepy servers can be stored by the server in the RD and accessed by all interested clients
Examples of using these parameters in a synchronous or asynchronous manner are shown in the I-D
http6lowappnet coreIETF86 2013-03-12-13
We assume people have read the drafts
Meetings serve to advance difficult issues by making good use of face-to-face communications
Note Well Be aware of the IPR principles according to RFC 3979 and its updates
uumlBlue sheetsuumlScribe(s)
96
drar-shy‐iep-shy‐core-shy‐coapsubmiqed13 to13 IESG
2013-shy‐03-shy‐13
97
OMA Lightweight M2M Overview(A new standard using lots of IETF specs including DTLS
CoAP Block Observe Resource Directory SenMLhellip)
Zach ShelbyCoRE WG IETF-86 Orlando
OMA Lightweight M2Mbull Open Mobile Alliance is well known for Device Management (DM)bull OMA Lightweight M2M is a new standard from the alliance
ndash Focused on constrained Cellular and sensor network M2M devicesndash Driven by leading operators and vendors
bull Scopendash Interfaces protocol amp security between Device and Serverndash Object and Resource modelndash Bootstrap Device Access Control Connectivity and Firmware Objects
bull Draft Specifications are availablendash httpmemberopenmobileallianceorgftpPublic_documentsDM
LightweightM2MPermanent_documentsOMA-TS-LightweightM2M-V1_0_0-20130301-Dzip
bull Timelinendash Requirements and Architecture completed 3Q2012ndash Spec ready for Consistency Review 2Q2013ndash Candidate Approval expected 3Q2013
2 CoRE WG IETF-86 Orlando
Architecture
3
Scope of LWM2M
CoRE WG IETF-86 Orlando
Object Model
bull A Client has one or more Object Instancesbull An Object is a collection of Resourcesbull A Resource is an atomic piece of information
ndash Read Written or Executed
bull Resources can have multiple instancesbull Objects and Resources are identified by a
16-bit Integer Instances by an 8-bit Integerbull ObjectsResources are accessed with
simple URIs Object IDObject InstanceResource ID
eg 1213
4 CoRE WG IETF-86 Orlando
CoRE WG IETF-86 Orlando
CoRE Resource Directory
draft-shelby-core-resource-directory-05
Z Shelby C Bormann S Krco
Backgroundbull Not a new concept
ndash think web search engine or any link directorybull Defines the interfaces to a Resource Directorybull Based on Web Linking framework and the CoRE Link Formatbull Generic REST design for use over HTTP and CoAPbull Used by OMA Lightweight M2Mbull Has already been deployed
ndash In traffic monitoring systemsndash In street lighting systemsndash For vehicular asset trackingndash By a major Cellular M2M operator
Changes since -04
bull Restricted Update to parameter updatesbull Added pagination support for the Lookup interfacebull Changed rt= to et= for the registration amp update
interfacebull Added group support
Group Management
bull RD now includes group management featuresbull New Group Function Set
ndash Register a groupbull Group name domain multicast address endpoint members
ndash Remove a groupbull Group lookup using the Lookup Function Set
ndash List registered groupsndash Find the members of a groupndash Find groups with certain endpoints or resources
Registering a Group
EP RD
| |
| - POST rd-groupgp=lights ltgtep=node1 --gt |
| |
| |
| lt---- 201 Created Location rd-group12 ---- |
| |
Req POST coaprdexamplecomrd-groupgp=lights
Payload
ltgtep=node1
ltgtep=node2
Res 201 Created
Location rd-group12
Looking up Group Members
Client RD
| |
| ----- GET rd-lookupepgp=lights1 ----------------------gt |
| |
| |
| lt-- 205 Content ltrdgtd=domain1ltrdgtd=domain2 --------- |
| |
Req GET rd-lookupepgp=lights1
Res 205 Content
ltcoaphostportgtep=node1
ltcoaphostportgtep=node2rdquo
Things for the futurebull Support for JSON representation of Web Links
ndash httptoolsietforgiddraft-bormann-core-links-json-02txtbull Registry for RD registration query parameters
ndash Already OMA Lightweight has defined some new onesbull More examples
Group 3 ldquonew workrdquo(continued)
109
drar-shy‐greevenbosch-shy‐core-shy‐profile-shy‐descripon-shy‐01Bert13 GreevenboschJeroen13 Hoebeke
Isam13 IshaqFloris13 Van13 den13 Abeele
Descripon
bull JSON13 format13 for13 signalling13 the13 servers13 capabilies
bull Signalling13 of13 supported13 opons13 media13 types13 and13 block13 sizendash Other13 items13 can13 be13 added
bull Filtering13 on13 specific13 fields13 through13 URI-shy‐Querybull Link13 hqpdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐profile-shy‐descripon
well-shy‐knownprofile
bull To13 acquire13 profile13 data13 of13 resources13 on13 a13 parcular13 service13 the13 well-shy‐knownprofile13 URI-shy‐path13 is13 introduced
bull For13 example13 to13 get13 all13 informaon13 from13 sensors13 served13 by13 wwwexampleorg13 we13 can13 do13 a13 GET13 to13 coapwwwexampleorgwell-shy‐knownprofile
bull Filtering13 on13 parcular13 resources13 is13 done13 through13 URI-shy‐Queries
Format
bull Currently13 the13 following13 fields13 are13 definedndash ldquopathrdquo13 contains13 the13 URI-shy‐path13 associated13 with13 a13 resource
ndash ldquooprdquo13 a13 numerical13 list13 of13 supported13 opon13 numbers
ndash ldquocfrdquo13 a13 numerical13 list13 of13 supported13 content-shy‐format13 numbers
ndash ldquob1srdquo13 ldquob2srdquo13 supported13 block13 sizes13 for13 Block113 and13 Block213 respecvely
Examplebull On13 the13 right13 is13 an13 example13 of13 a13 camera13 sensor13 at13 coapwwwexampleorgcam13 that13 supports13 the13 Uri-shy‐Host13 (3)13 ETag13 (4)13 Uri-shy‐Port13 (7)13 Uri-shy‐Path13 (11)13 Content-shy‐Format13 (12)13 Token13 (19)13 Block213 (23)13 and13 Proxy-shy‐Uri13 (35)13 opons
bull The13 supported13 content13 formats13 are13 textplain13 (0)13 applicaon13 link-shy‐format13 (40)13 and13 applicaonjson13 (50)
bull The13 supported13 Block213 can13 use13 25613 or13 51213 byte13 blocks
Req13 GET13 coapwwwexampleorgwell-shy‐knownprofile13 Res13 20513 Content13 (applicationjson)13 13 13 13 profile13 13 13 13 13 13 13 13 pathcam13 13 13 13 op[3471112192335]13 13 13 13 13 cf[04050]13 13 13 13 13 b2s[45]13 13 13 13
Filtering13 through13 use13 of13 URI-shy‐Query
bull Filtering13 can13 be13 done13 through13 the13 URI-shy‐Querybull Query13 format13 N=V
ndash N13 is13 a13 profile13 fieldndash V13 is13 the13 desired13 value
bull Examplesndash To13 find13 resources13 that13 support13 content13 format13 ldquoapplicaonjsonrdquo
13 GET13 wwwexampleorgwell-shy‐knownprofilecf=50ndash To13 get13 informaon13 about13 the13 camera
13 GET13 wwwexampleorgwell-shy‐knownprofilepath=cam
Open13 issues
bull Which13 other13 profile13 data13 needs13 signallingndash Content-shy‐type13 for13 different13 methods
bull Fix13 the13 order13 in13 which13 the13 profile13 fields13 must13 appearndash Non-shy‐fixed13 order13 easier13 extensible
bull Inheritance13 of13 a13 profile13 descriponbull Extend13 usage13 to13 signal13 the13 client13 profilebull Integraon13 with13 link13 format
Thank13 youQuesons
drar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval-shy‐00
Bert13 Greevenbosch
Descripon
bull The13 ldquoMinimumRequestInterval13 opon13 can13 be13 used13 to13 indicate13 the13 minimum13 me13 between13 two13 requests13 in13 a13 transacon
bull Originally13 intended13 for13 Block13 but13 also13 usable13 for13 other13 transaconsndash Example13 browsing13 a13 server
bull The13 goal13 is13 to13 reduce13 the13 server13 load13 and13 network13 traffic
bull Link13 hqpsdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval
Usage
bull The13 client13 keeps13 the13 server13 informed13 about13 its13 request13 speed13 through13 inclusion13 of13 the13 ldquoMinimumRequestIntervalrdquo13 opon
bull In13 responses13 the13 server13 fixes13 the13 minimum13 request13 interval13 through13 the13 same13 opon
bull The13 client13 obeys13 the13 speed13 indicated13 by13 the13 server
bull The13 client13 can13 send13 slower13 but13 not13 faster
Advantages
bull The13 server13 has13 means13 to13 limit13 the13 amount13 of13 incoming13 traffic
bull The13 server13 can13 prevent13 to13 become13 overloaded13 with13 too13 many13 tasks
bull The13 server13 does13 not13 need13 arficially13 slow13 down13 the13 client13 by13 sending13 late13 ACKsndash No13 need13 to13 keep13 track13 of13 delayed13 ACKsndash The13 server13 can13 perform13 other13 tasks13 instead
bull Reduced13 network13 traffic
Thank13 youQuesons
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-links-json-02txt
123
RFC 6690 (link-format) documents are somewhat foreign to many web app developerssect would prefer to have them in JSON format
There is no standard way to represent link-format documents in applicationssect but everyone knows how to handle JSON
Define a standard JSON translation for link-format
Itrsquos
not
rock
et
scien
ce
ltsensorsgtct=40title=Sensor Index ltsensorstempgtrt=temperature-cif=sensor ltsensorslightgtrt=light-luxif=sensor lthttpwwwexamplecomsensorst123gt anchor=sensorstemprel=describedby lttgtanchor=sensorstemprel=alternate [hrefsensorsct40titleSensor Index hrefsensorstemprttemperature-cifsensor hrefsensorslightrtlight-luxifsensor hrefhttpwwwexamplecomsensorst123 anchorsensorstempreldescribedby hreftanchorsensorstemprelalternate]
124
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-ipsec-for-coap-00txt
IPsec definitions for CoAP Mostly placeholder at this time Who has implementation experience with this
125
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-cross-reverse-convention-00txt
This draft has two lines of payload(based on a WGLC comment by Cullen Jennings)
coap12344567foobara=3
httpwwwproxycomwellknowncore-translate1234_4567foobara=3
Is that a useful convention to have
126
Insert CI slides here
127
128
0
5
10
15
20
25
30
35
40
10 20 30 40 50 60 70
good
put (
pps)
pps
Goodput vs pps (Econotags)
goodput
[Khattak preliminary]
Congestion Control
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-cocoa-00txt
ldquoadvancedrdquo cc (The draft is just a first shot) Others may have better ideas
129
Insert post-WGLC discussion slides here
130
Stop Continue Start
131
An Agile Retrospective
http6lowappnet coreIETF86 2013-03-12-13
Stop
132
Endless new CoAP optionssect instead use RESTful as much as possible
Move general security lifecycle out Looking at theoretical problems
http6lowappnet coreIETF86 2013-03-12-13
Continue
Interops Running code Look at real-world examples and deployments Solve their actual problems
sect Unilateral enhancements eg higher performance congestion control
sect Transports (SMS hellip)sect Make Web linking and Directories more and more usefulsect RESTful Design Paradigms for real-world problems
133
http6lowappnet coreIETF86 2013-03-12-13
Start
Further push into the (browser) web world (HTML5 browser security)
Specific supporting worksect SenMLsect URI work (dev URN hellip)sect Security Processes (next slide)
Spin outsect (We donrsquot really get to decide where this is done)
134
http6lowappnet coreIETF86 2013-03-12-13
Security
Integrate Application Network Group Keyingsect Tunnel-free setup
Donrsquot redo what has been done alreadysect ZigBee IP is finesect But what about other scenarios
Simple REST interfaces for working with keying materials and authorizationsect Start with defining objectives
Object Security for Constrained Nodes135
Re-chartering CoREWhat do we want to do now that wersquore grown up
Zach ShelbyCoRE WG IETF-86 Orlando
What is the scope
bull So we have a protocol and Web Linking what next
bull Keep with what we know besthellip1 Enhancements around CoAP2 New transports for CoAP3 New representations for Web Links4 General application layer solutions
CoRE WG IETF-86 Orlando 2
Enhancements around CoAP
bull Advanced congestion control
CoRE WG IETF-86 Orlando 3
New Transports for CoAP
bull Infrastructure for CoAP over foondash httptoolsietforgiddraft-silverajan-core-
coap-alternative-transports-01txtbull CoAP over SMS
ndash httptoolsietforgiddraft-becker-core-coap-sms-gprs-03txt
ndash OMA Lightweightbull CoAP over TCP
ndash httptoolsietforgiddraft-li-core-coap-payload-length-option-01txt
CoRE WG IETF-86 Orlando 4
New support for Web Links
bull JSON Web Linksndash httptoolsietforgiddraft-bormann-core-links-
json-02txt
2332010 CoRE WG IETF-77 Anaheim 5
General application layer solutions
bull Resource Directoryndash httptoolsietforgiddraft-shelby-core-
resource-directory-05txtndash OMA Lightweight
2332010 CoRE WG IETF-77 Anaheim 6
GET ndash Scenario 2 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has slightly better performance for sleepy servers
0
50
100
150
200
250
300
350
400
2a 2b 2c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
Scenarios 2a - Non-Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2b- Sleepy Server Caching Proxy maxAge = 60sec 5 Clients 2c - Sleepy Server Sleep Aware Proxy maxAge = 60sec 5 Clients
See ldquoExperimental Artifactsrdquo Note 2
Experimental Artifacts Note 1
Currently in the experiment the sleep aware proxy checks the cached state of a resource before putting a request into its Store-and-forward queue while a server is sleeping Once in the queue the proxy unconditionally forwards the queued requests to the server once it wakes up This is not the most efficient setup and can easily be improved If the proxy instead checks its cache again before forwarding each queued request it may not need to forward the request to the server For example if there are two queued GET requests in the proxyrsquos queue that address the same resource Only the first request needs to be sent to the server the second request can use the cached response from the first request
Note 2 Currently in the experiment the sleepy server sends a sleepState PUT request to the
proxy each time it goes to sleep This is not the most efficient setup and can easily be improved For example if the server assumes that the proxy can keep track of its ONOFF cycles with its internal timers (eg as per Fig 1 of I-D) then the number of messages from the sleepy server dramatically goes down
ldquoGETrdquo ndash Test Scenario 3 Results
maxAge = 5 and 5 Clients
GET ndash Scenario 3 ClientProxy Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
Scenarios 3a - Non-Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3b- Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3c - Sleepy Server Sleep Aware Proxy maxAge = 5sec 5 Clients
0
500
1000
1500
2000
2500
3000
3500
4000
4500
5000
3a 3b 3c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
GET ndash Scenario 3 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
0
1000
2000
3000
4000
5000
6000
7000
3a 3b 3c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
Scenarios 3a - Non-Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3b- Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3c - Sleepy Server Sleep Aware Proxy maxAge = 5sec 5 Clients
Conclusions
Conclusions These results show that sleep-aware CoAP
proxy features can significantly optimize communication with sleepy servers in most scenarios
These results also show that sleep-
awareness capabilities can provide additional benefits above and beyond CoAP caching in most scenarios
Backup
Current CoAP Support of Sleepy Node (12)
CoAP proxies can use a previously cached response to service a new GET request for a sleepy origin server (as in HTTP) But if no valid cache then proxy has to attempt to
retrieve and may fail if origin server is sleeping [I-Dietf-core-coap]
Clients can discover list of resources from RD (GET rd-lookuphellip) for sleepy servers But attempt to GET resource from sleepy origin server
may fail if origin server is sleeping [IDietf-core-link-format amp IDshelby-core-resource-
directory]
Current CoAP Support of Sleepy Node (22)
Lower layer support for sleepy nodes in most wireless technologies (eg WiFi ZigBee) But limited to MAC packet scheduling for sleepy nodes
and not aware of specific needs of IP applications (like CoAP)
Proposal ndash RD Based Sleep Tracking (14)
The current CoAP approach to support sleepy nodes can be significantly improved by introducing RD based mechanisms for a CoAP client to determine whether A targeted resource is located on a sleepy server A sleepy server is currently in sleep mode or not
There is any associated caching Proxy (possibly the RD itself) for a sleepy server
Proposal ndash RD Based Sleep Tracking (24)
We define the following new RD attributes to characterize the properties of a sleepy node SleepState - Indicates whether the node is currently in
sleep mode or not (ie Sleeping or Awake) SleepDuration - Indicates the maximum duration of time
that the node stays in sleep mode TimeSleeping - Indicates the length of time the node
has been sleeping (ie if Sleep State = Sleeping) NextSleep - Indicates the next time the node will go to
sleep (ie if Sleep State = Awake)
CachingProxy ndash Indicates the caching proxy of the sleepy node (ie the RD itself or another node)
Proposal ndash RD Based Sleep Tracking (34)
These attributes are all server (node) level and are new parameters added to the RD URI Template Variables
Finally we also define a new lookup-type (ss) for the RD lookup interface specified in [I-Dshelby-core-resource-directory] This new lookup-type supports looking up the
ldquoSleepStaterdquo (ss) of a specified end-point
Proposal ndash RD Based Sleep Tracking (44)
The three time based parameters (SleepDuration TimeSleeping NextSleep) can be based on either an absolute network time (for a time synchronized network) or a relative local time (measured at the local node)
Following the approach of [I-Dietf-core-link-format] and [I-Dshelby-core-resource-directory] sleep parameters for sleepy servers can be stored by the server in the RD and accessed by all interested clients
Examples of using these parameters in a synchronous or asynchronous manner are shown in the I-D
http6lowappnet coreIETF86 2013-03-12-13
We assume people have read the drafts
Meetings serve to advance difficult issues by making good use of face-to-face communications
Note Well Be aware of the IPR principles according to RFC 3979 and its updates
uumlBlue sheetsuumlScribe(s)
96
drar-shy‐iep-shy‐core-shy‐coapsubmiqed13 to13 IESG
2013-shy‐03-shy‐13
97
OMA Lightweight M2M Overview(A new standard using lots of IETF specs including DTLS
CoAP Block Observe Resource Directory SenMLhellip)
Zach ShelbyCoRE WG IETF-86 Orlando
OMA Lightweight M2Mbull Open Mobile Alliance is well known for Device Management (DM)bull OMA Lightweight M2M is a new standard from the alliance
ndash Focused on constrained Cellular and sensor network M2M devicesndash Driven by leading operators and vendors
bull Scopendash Interfaces protocol amp security between Device and Serverndash Object and Resource modelndash Bootstrap Device Access Control Connectivity and Firmware Objects
bull Draft Specifications are availablendash httpmemberopenmobileallianceorgftpPublic_documentsDM
LightweightM2MPermanent_documentsOMA-TS-LightweightM2M-V1_0_0-20130301-Dzip
bull Timelinendash Requirements and Architecture completed 3Q2012ndash Spec ready for Consistency Review 2Q2013ndash Candidate Approval expected 3Q2013
2 CoRE WG IETF-86 Orlando
Architecture
3
Scope of LWM2M
CoRE WG IETF-86 Orlando
Object Model
bull A Client has one or more Object Instancesbull An Object is a collection of Resourcesbull A Resource is an atomic piece of information
ndash Read Written or Executed
bull Resources can have multiple instancesbull Objects and Resources are identified by a
16-bit Integer Instances by an 8-bit Integerbull ObjectsResources are accessed with
simple URIs Object IDObject InstanceResource ID
eg 1213
4 CoRE WG IETF-86 Orlando
CoRE WG IETF-86 Orlando
CoRE Resource Directory
draft-shelby-core-resource-directory-05
Z Shelby C Bormann S Krco
Backgroundbull Not a new concept
ndash think web search engine or any link directorybull Defines the interfaces to a Resource Directorybull Based on Web Linking framework and the CoRE Link Formatbull Generic REST design for use over HTTP and CoAPbull Used by OMA Lightweight M2Mbull Has already been deployed
ndash In traffic monitoring systemsndash In street lighting systemsndash For vehicular asset trackingndash By a major Cellular M2M operator
Changes since -04
bull Restricted Update to parameter updatesbull Added pagination support for the Lookup interfacebull Changed rt= to et= for the registration amp update
interfacebull Added group support
Group Management
bull RD now includes group management featuresbull New Group Function Set
ndash Register a groupbull Group name domain multicast address endpoint members
ndash Remove a groupbull Group lookup using the Lookup Function Set
ndash List registered groupsndash Find the members of a groupndash Find groups with certain endpoints or resources
Registering a Group
EP RD
| |
| - POST rd-groupgp=lights ltgtep=node1 --gt |
| |
| |
| lt---- 201 Created Location rd-group12 ---- |
| |
Req POST coaprdexamplecomrd-groupgp=lights
Payload
ltgtep=node1
ltgtep=node2
Res 201 Created
Location rd-group12
Looking up Group Members
Client RD
| |
| ----- GET rd-lookupepgp=lights1 ----------------------gt |
| |
| |
| lt-- 205 Content ltrdgtd=domain1ltrdgtd=domain2 --------- |
| |
Req GET rd-lookupepgp=lights1
Res 205 Content
ltcoaphostportgtep=node1
ltcoaphostportgtep=node2rdquo
Things for the futurebull Support for JSON representation of Web Links
ndash httptoolsietforgiddraft-bormann-core-links-json-02txtbull Registry for RD registration query parameters
ndash Already OMA Lightweight has defined some new onesbull More examples
Group 3 ldquonew workrdquo(continued)
109
drar-shy‐greevenbosch-shy‐core-shy‐profile-shy‐descripon-shy‐01Bert13 GreevenboschJeroen13 Hoebeke
Isam13 IshaqFloris13 Van13 den13 Abeele
Descripon
bull JSON13 format13 for13 signalling13 the13 servers13 capabilies
bull Signalling13 of13 supported13 opons13 media13 types13 and13 block13 sizendash Other13 items13 can13 be13 added
bull Filtering13 on13 specific13 fields13 through13 URI-shy‐Querybull Link13 hqpdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐profile-shy‐descripon
well-shy‐knownprofile
bull To13 acquire13 profile13 data13 of13 resources13 on13 a13 parcular13 service13 the13 well-shy‐knownprofile13 URI-shy‐path13 is13 introduced
bull For13 example13 to13 get13 all13 informaon13 from13 sensors13 served13 by13 wwwexampleorg13 we13 can13 do13 a13 GET13 to13 coapwwwexampleorgwell-shy‐knownprofile
bull Filtering13 on13 parcular13 resources13 is13 done13 through13 URI-shy‐Queries
Format
bull Currently13 the13 following13 fields13 are13 definedndash ldquopathrdquo13 contains13 the13 URI-shy‐path13 associated13 with13 a13 resource
ndash ldquooprdquo13 a13 numerical13 list13 of13 supported13 opon13 numbers
ndash ldquocfrdquo13 a13 numerical13 list13 of13 supported13 content-shy‐format13 numbers
ndash ldquob1srdquo13 ldquob2srdquo13 supported13 block13 sizes13 for13 Block113 and13 Block213 respecvely
Examplebull On13 the13 right13 is13 an13 example13 of13 a13 camera13 sensor13 at13 coapwwwexampleorgcam13 that13 supports13 the13 Uri-shy‐Host13 (3)13 ETag13 (4)13 Uri-shy‐Port13 (7)13 Uri-shy‐Path13 (11)13 Content-shy‐Format13 (12)13 Token13 (19)13 Block213 (23)13 and13 Proxy-shy‐Uri13 (35)13 opons
bull The13 supported13 content13 formats13 are13 textplain13 (0)13 applicaon13 link-shy‐format13 (40)13 and13 applicaonjson13 (50)
bull The13 supported13 Block213 can13 use13 25613 or13 51213 byte13 blocks
Req13 GET13 coapwwwexampleorgwell-shy‐knownprofile13 Res13 20513 Content13 (applicationjson)13 13 13 13 profile13 13 13 13 13 13 13 13 pathcam13 13 13 13 op[3471112192335]13 13 13 13 13 cf[04050]13 13 13 13 13 b2s[45]13 13 13 13
Filtering13 through13 use13 of13 URI-shy‐Query
bull Filtering13 can13 be13 done13 through13 the13 URI-shy‐Querybull Query13 format13 N=V
ndash N13 is13 a13 profile13 fieldndash V13 is13 the13 desired13 value
bull Examplesndash To13 find13 resources13 that13 support13 content13 format13 ldquoapplicaonjsonrdquo
13 GET13 wwwexampleorgwell-shy‐knownprofilecf=50ndash To13 get13 informaon13 about13 the13 camera
13 GET13 wwwexampleorgwell-shy‐knownprofilepath=cam
Open13 issues
bull Which13 other13 profile13 data13 needs13 signallingndash Content-shy‐type13 for13 different13 methods
bull Fix13 the13 order13 in13 which13 the13 profile13 fields13 must13 appearndash Non-shy‐fixed13 order13 easier13 extensible
bull Inheritance13 of13 a13 profile13 descriponbull Extend13 usage13 to13 signal13 the13 client13 profilebull Integraon13 with13 link13 format
Thank13 youQuesons
drar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval-shy‐00
Bert13 Greevenbosch
Descripon
bull The13 ldquoMinimumRequestInterval13 opon13 can13 be13 used13 to13 indicate13 the13 minimum13 me13 between13 two13 requests13 in13 a13 transacon
bull Originally13 intended13 for13 Block13 but13 also13 usable13 for13 other13 transaconsndash Example13 browsing13 a13 server
bull The13 goal13 is13 to13 reduce13 the13 server13 load13 and13 network13 traffic
bull Link13 hqpsdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval
Usage
bull The13 client13 keeps13 the13 server13 informed13 about13 its13 request13 speed13 through13 inclusion13 of13 the13 ldquoMinimumRequestIntervalrdquo13 opon
bull In13 responses13 the13 server13 fixes13 the13 minimum13 request13 interval13 through13 the13 same13 opon
bull The13 client13 obeys13 the13 speed13 indicated13 by13 the13 server
bull The13 client13 can13 send13 slower13 but13 not13 faster
Advantages
bull The13 server13 has13 means13 to13 limit13 the13 amount13 of13 incoming13 traffic
bull The13 server13 can13 prevent13 to13 become13 overloaded13 with13 too13 many13 tasks
bull The13 server13 does13 not13 need13 arficially13 slow13 down13 the13 client13 by13 sending13 late13 ACKsndash No13 need13 to13 keep13 track13 of13 delayed13 ACKsndash The13 server13 can13 perform13 other13 tasks13 instead
bull Reduced13 network13 traffic
Thank13 youQuesons
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-links-json-02txt
123
RFC 6690 (link-format) documents are somewhat foreign to many web app developerssect would prefer to have them in JSON format
There is no standard way to represent link-format documents in applicationssect but everyone knows how to handle JSON
Define a standard JSON translation for link-format
Itrsquos
not
rock
et
scien
ce
ltsensorsgtct=40title=Sensor Index ltsensorstempgtrt=temperature-cif=sensor ltsensorslightgtrt=light-luxif=sensor lthttpwwwexamplecomsensorst123gt anchor=sensorstemprel=describedby lttgtanchor=sensorstemprel=alternate [hrefsensorsct40titleSensor Index hrefsensorstemprttemperature-cifsensor hrefsensorslightrtlight-luxifsensor hrefhttpwwwexamplecomsensorst123 anchorsensorstempreldescribedby hreftanchorsensorstemprelalternate]
124
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-ipsec-for-coap-00txt
IPsec definitions for CoAP Mostly placeholder at this time Who has implementation experience with this
125
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-cross-reverse-convention-00txt
This draft has two lines of payload(based on a WGLC comment by Cullen Jennings)
coap12344567foobara=3
httpwwwproxycomwellknowncore-translate1234_4567foobara=3
Is that a useful convention to have
126
Insert CI slides here
127
128
0
5
10
15
20
25
30
35
40
10 20 30 40 50 60 70
good
put (
pps)
pps
Goodput vs pps (Econotags)
goodput
[Khattak preliminary]
Congestion Control
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-cocoa-00txt
ldquoadvancedrdquo cc (The draft is just a first shot) Others may have better ideas
129
Insert post-WGLC discussion slides here
130
Stop Continue Start
131
An Agile Retrospective
http6lowappnet coreIETF86 2013-03-12-13
Stop
132
Endless new CoAP optionssect instead use RESTful as much as possible
Move general security lifecycle out Looking at theoretical problems
http6lowappnet coreIETF86 2013-03-12-13
Continue
Interops Running code Look at real-world examples and deployments Solve their actual problems
sect Unilateral enhancements eg higher performance congestion control
sect Transports (SMS hellip)sect Make Web linking and Directories more and more usefulsect RESTful Design Paradigms for real-world problems
133
http6lowappnet coreIETF86 2013-03-12-13
Start
Further push into the (browser) web world (HTML5 browser security)
Specific supporting worksect SenMLsect URI work (dev URN hellip)sect Security Processes (next slide)
Spin outsect (We donrsquot really get to decide where this is done)
134
http6lowappnet coreIETF86 2013-03-12-13
Security
Integrate Application Network Group Keyingsect Tunnel-free setup
Donrsquot redo what has been done alreadysect ZigBee IP is finesect But what about other scenarios
Simple REST interfaces for working with keying materials and authorizationsect Start with defining objectives
Object Security for Constrained Nodes135
Re-chartering CoREWhat do we want to do now that wersquore grown up
Zach ShelbyCoRE WG IETF-86 Orlando
What is the scope
bull So we have a protocol and Web Linking what next
bull Keep with what we know besthellip1 Enhancements around CoAP2 New transports for CoAP3 New representations for Web Links4 General application layer solutions
CoRE WG IETF-86 Orlando 2
Enhancements around CoAP
bull Advanced congestion control
CoRE WG IETF-86 Orlando 3
New Transports for CoAP
bull Infrastructure for CoAP over foondash httptoolsietforgiddraft-silverajan-core-
coap-alternative-transports-01txtbull CoAP over SMS
ndash httptoolsietforgiddraft-becker-core-coap-sms-gprs-03txt
ndash OMA Lightweightbull CoAP over TCP
ndash httptoolsietforgiddraft-li-core-coap-payload-length-option-01txt
CoRE WG IETF-86 Orlando 4
New support for Web Links
bull JSON Web Linksndash httptoolsietforgiddraft-bormann-core-links-
json-02txt
2332010 CoRE WG IETF-77 Anaheim 5
General application layer solutions
bull Resource Directoryndash httptoolsietforgiddraft-shelby-core-
resource-directory-05txtndash OMA Lightweight
2332010 CoRE WG IETF-77 Anaheim 6
Experimental Artifacts Note 1
Currently in the experiment the sleep aware proxy checks the cached state of a resource before putting a request into its Store-and-forward queue while a server is sleeping Once in the queue the proxy unconditionally forwards the queued requests to the server once it wakes up This is not the most efficient setup and can easily be improved If the proxy instead checks its cache again before forwarding each queued request it may not need to forward the request to the server For example if there are two queued GET requests in the proxyrsquos queue that address the same resource Only the first request needs to be sent to the server the second request can use the cached response from the first request
Note 2 Currently in the experiment the sleepy server sends a sleepState PUT request to the
proxy each time it goes to sleep This is not the most efficient setup and can easily be improved For example if the server assumes that the proxy can keep track of its ONOFF cycles with its internal timers (eg as per Fig 1 of I-D) then the number of messages from the sleepy server dramatically goes down
ldquoGETrdquo ndash Test Scenario 3 Results
maxAge = 5 and 5 Clients
GET ndash Scenario 3 ClientProxy Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
Scenarios 3a - Non-Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3b- Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3c - Sleepy Server Sleep Aware Proxy maxAge = 5sec 5 Clients
0
500
1000
1500
2000
2500
3000
3500
4000
4500
5000
3a 3b 3c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
GET ndash Scenario 3 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
0
1000
2000
3000
4000
5000
6000
7000
3a 3b 3c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
Scenarios 3a - Non-Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3b- Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3c - Sleepy Server Sleep Aware Proxy maxAge = 5sec 5 Clients
Conclusions
Conclusions These results show that sleep-aware CoAP
proxy features can significantly optimize communication with sleepy servers in most scenarios
These results also show that sleep-
awareness capabilities can provide additional benefits above and beyond CoAP caching in most scenarios
Backup
Current CoAP Support of Sleepy Node (12)
CoAP proxies can use a previously cached response to service a new GET request for a sleepy origin server (as in HTTP) But if no valid cache then proxy has to attempt to
retrieve and may fail if origin server is sleeping [I-Dietf-core-coap]
Clients can discover list of resources from RD (GET rd-lookuphellip) for sleepy servers But attempt to GET resource from sleepy origin server
may fail if origin server is sleeping [IDietf-core-link-format amp IDshelby-core-resource-
directory]
Current CoAP Support of Sleepy Node (22)
Lower layer support for sleepy nodes in most wireless technologies (eg WiFi ZigBee) But limited to MAC packet scheduling for sleepy nodes
and not aware of specific needs of IP applications (like CoAP)
Proposal ndash RD Based Sleep Tracking (14)
The current CoAP approach to support sleepy nodes can be significantly improved by introducing RD based mechanisms for a CoAP client to determine whether A targeted resource is located on a sleepy server A sleepy server is currently in sleep mode or not
There is any associated caching Proxy (possibly the RD itself) for a sleepy server
Proposal ndash RD Based Sleep Tracking (24)
We define the following new RD attributes to characterize the properties of a sleepy node SleepState - Indicates whether the node is currently in
sleep mode or not (ie Sleeping or Awake) SleepDuration - Indicates the maximum duration of time
that the node stays in sleep mode TimeSleeping - Indicates the length of time the node
has been sleeping (ie if Sleep State = Sleeping) NextSleep - Indicates the next time the node will go to
sleep (ie if Sleep State = Awake)
CachingProxy ndash Indicates the caching proxy of the sleepy node (ie the RD itself or another node)
Proposal ndash RD Based Sleep Tracking (34)
These attributes are all server (node) level and are new parameters added to the RD URI Template Variables
Finally we also define a new lookup-type (ss) for the RD lookup interface specified in [I-Dshelby-core-resource-directory] This new lookup-type supports looking up the
ldquoSleepStaterdquo (ss) of a specified end-point
Proposal ndash RD Based Sleep Tracking (44)
The three time based parameters (SleepDuration TimeSleeping NextSleep) can be based on either an absolute network time (for a time synchronized network) or a relative local time (measured at the local node)
Following the approach of [I-Dietf-core-link-format] and [I-Dshelby-core-resource-directory] sleep parameters for sleepy servers can be stored by the server in the RD and accessed by all interested clients
Examples of using these parameters in a synchronous or asynchronous manner are shown in the I-D
http6lowappnet coreIETF86 2013-03-12-13
We assume people have read the drafts
Meetings serve to advance difficult issues by making good use of face-to-face communications
Note Well Be aware of the IPR principles according to RFC 3979 and its updates
uumlBlue sheetsuumlScribe(s)
96
drar-shy‐iep-shy‐core-shy‐coapsubmiqed13 to13 IESG
2013-shy‐03-shy‐13
97
OMA Lightweight M2M Overview(A new standard using lots of IETF specs including DTLS
CoAP Block Observe Resource Directory SenMLhellip)
Zach ShelbyCoRE WG IETF-86 Orlando
OMA Lightweight M2Mbull Open Mobile Alliance is well known for Device Management (DM)bull OMA Lightweight M2M is a new standard from the alliance
ndash Focused on constrained Cellular and sensor network M2M devicesndash Driven by leading operators and vendors
bull Scopendash Interfaces protocol amp security between Device and Serverndash Object and Resource modelndash Bootstrap Device Access Control Connectivity and Firmware Objects
bull Draft Specifications are availablendash httpmemberopenmobileallianceorgftpPublic_documentsDM
LightweightM2MPermanent_documentsOMA-TS-LightweightM2M-V1_0_0-20130301-Dzip
bull Timelinendash Requirements and Architecture completed 3Q2012ndash Spec ready for Consistency Review 2Q2013ndash Candidate Approval expected 3Q2013
2 CoRE WG IETF-86 Orlando
Architecture
3
Scope of LWM2M
CoRE WG IETF-86 Orlando
Object Model
bull A Client has one or more Object Instancesbull An Object is a collection of Resourcesbull A Resource is an atomic piece of information
ndash Read Written or Executed
bull Resources can have multiple instancesbull Objects and Resources are identified by a
16-bit Integer Instances by an 8-bit Integerbull ObjectsResources are accessed with
simple URIs Object IDObject InstanceResource ID
eg 1213
4 CoRE WG IETF-86 Orlando
CoRE WG IETF-86 Orlando
CoRE Resource Directory
draft-shelby-core-resource-directory-05
Z Shelby C Bormann S Krco
Backgroundbull Not a new concept
ndash think web search engine or any link directorybull Defines the interfaces to a Resource Directorybull Based on Web Linking framework and the CoRE Link Formatbull Generic REST design for use over HTTP and CoAPbull Used by OMA Lightweight M2Mbull Has already been deployed
ndash In traffic monitoring systemsndash In street lighting systemsndash For vehicular asset trackingndash By a major Cellular M2M operator
Changes since -04
bull Restricted Update to parameter updatesbull Added pagination support for the Lookup interfacebull Changed rt= to et= for the registration amp update
interfacebull Added group support
Group Management
bull RD now includes group management featuresbull New Group Function Set
ndash Register a groupbull Group name domain multicast address endpoint members
ndash Remove a groupbull Group lookup using the Lookup Function Set
ndash List registered groupsndash Find the members of a groupndash Find groups with certain endpoints or resources
Registering a Group
EP RD
| |
| - POST rd-groupgp=lights ltgtep=node1 --gt |
| |
| |
| lt---- 201 Created Location rd-group12 ---- |
| |
Req POST coaprdexamplecomrd-groupgp=lights
Payload
ltgtep=node1
ltgtep=node2
Res 201 Created
Location rd-group12
Looking up Group Members
Client RD
| |
| ----- GET rd-lookupepgp=lights1 ----------------------gt |
| |
| |
| lt-- 205 Content ltrdgtd=domain1ltrdgtd=domain2 --------- |
| |
Req GET rd-lookupepgp=lights1
Res 205 Content
ltcoaphostportgtep=node1
ltcoaphostportgtep=node2rdquo
Things for the futurebull Support for JSON representation of Web Links
ndash httptoolsietforgiddraft-bormann-core-links-json-02txtbull Registry for RD registration query parameters
ndash Already OMA Lightweight has defined some new onesbull More examples
Group 3 ldquonew workrdquo(continued)
109
drar-shy‐greevenbosch-shy‐core-shy‐profile-shy‐descripon-shy‐01Bert13 GreevenboschJeroen13 Hoebeke
Isam13 IshaqFloris13 Van13 den13 Abeele
Descripon
bull JSON13 format13 for13 signalling13 the13 servers13 capabilies
bull Signalling13 of13 supported13 opons13 media13 types13 and13 block13 sizendash Other13 items13 can13 be13 added
bull Filtering13 on13 specific13 fields13 through13 URI-shy‐Querybull Link13 hqpdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐profile-shy‐descripon
well-shy‐knownprofile
bull To13 acquire13 profile13 data13 of13 resources13 on13 a13 parcular13 service13 the13 well-shy‐knownprofile13 URI-shy‐path13 is13 introduced
bull For13 example13 to13 get13 all13 informaon13 from13 sensors13 served13 by13 wwwexampleorg13 we13 can13 do13 a13 GET13 to13 coapwwwexampleorgwell-shy‐knownprofile
bull Filtering13 on13 parcular13 resources13 is13 done13 through13 URI-shy‐Queries
Format
bull Currently13 the13 following13 fields13 are13 definedndash ldquopathrdquo13 contains13 the13 URI-shy‐path13 associated13 with13 a13 resource
ndash ldquooprdquo13 a13 numerical13 list13 of13 supported13 opon13 numbers
ndash ldquocfrdquo13 a13 numerical13 list13 of13 supported13 content-shy‐format13 numbers
ndash ldquob1srdquo13 ldquob2srdquo13 supported13 block13 sizes13 for13 Block113 and13 Block213 respecvely
Examplebull On13 the13 right13 is13 an13 example13 of13 a13 camera13 sensor13 at13 coapwwwexampleorgcam13 that13 supports13 the13 Uri-shy‐Host13 (3)13 ETag13 (4)13 Uri-shy‐Port13 (7)13 Uri-shy‐Path13 (11)13 Content-shy‐Format13 (12)13 Token13 (19)13 Block213 (23)13 and13 Proxy-shy‐Uri13 (35)13 opons
bull The13 supported13 content13 formats13 are13 textplain13 (0)13 applicaon13 link-shy‐format13 (40)13 and13 applicaonjson13 (50)
bull The13 supported13 Block213 can13 use13 25613 or13 51213 byte13 blocks
Req13 GET13 coapwwwexampleorgwell-shy‐knownprofile13 Res13 20513 Content13 (applicationjson)13 13 13 13 profile13 13 13 13 13 13 13 13 pathcam13 13 13 13 op[3471112192335]13 13 13 13 13 cf[04050]13 13 13 13 13 b2s[45]13 13 13 13
Filtering13 through13 use13 of13 URI-shy‐Query
bull Filtering13 can13 be13 done13 through13 the13 URI-shy‐Querybull Query13 format13 N=V
ndash N13 is13 a13 profile13 fieldndash V13 is13 the13 desired13 value
bull Examplesndash To13 find13 resources13 that13 support13 content13 format13 ldquoapplicaonjsonrdquo
13 GET13 wwwexampleorgwell-shy‐knownprofilecf=50ndash To13 get13 informaon13 about13 the13 camera
13 GET13 wwwexampleorgwell-shy‐knownprofilepath=cam
Open13 issues
bull Which13 other13 profile13 data13 needs13 signallingndash Content-shy‐type13 for13 different13 methods
bull Fix13 the13 order13 in13 which13 the13 profile13 fields13 must13 appearndash Non-shy‐fixed13 order13 easier13 extensible
bull Inheritance13 of13 a13 profile13 descriponbull Extend13 usage13 to13 signal13 the13 client13 profilebull Integraon13 with13 link13 format
Thank13 youQuesons
drar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval-shy‐00
Bert13 Greevenbosch
Descripon
bull The13 ldquoMinimumRequestInterval13 opon13 can13 be13 used13 to13 indicate13 the13 minimum13 me13 between13 two13 requests13 in13 a13 transacon
bull Originally13 intended13 for13 Block13 but13 also13 usable13 for13 other13 transaconsndash Example13 browsing13 a13 server
bull The13 goal13 is13 to13 reduce13 the13 server13 load13 and13 network13 traffic
bull Link13 hqpsdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval
Usage
bull The13 client13 keeps13 the13 server13 informed13 about13 its13 request13 speed13 through13 inclusion13 of13 the13 ldquoMinimumRequestIntervalrdquo13 opon
bull In13 responses13 the13 server13 fixes13 the13 minimum13 request13 interval13 through13 the13 same13 opon
bull The13 client13 obeys13 the13 speed13 indicated13 by13 the13 server
bull The13 client13 can13 send13 slower13 but13 not13 faster
Advantages
bull The13 server13 has13 means13 to13 limit13 the13 amount13 of13 incoming13 traffic
bull The13 server13 can13 prevent13 to13 become13 overloaded13 with13 too13 many13 tasks
bull The13 server13 does13 not13 need13 arficially13 slow13 down13 the13 client13 by13 sending13 late13 ACKsndash No13 need13 to13 keep13 track13 of13 delayed13 ACKsndash The13 server13 can13 perform13 other13 tasks13 instead
bull Reduced13 network13 traffic
Thank13 youQuesons
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-links-json-02txt
123
RFC 6690 (link-format) documents are somewhat foreign to many web app developerssect would prefer to have them in JSON format
There is no standard way to represent link-format documents in applicationssect but everyone knows how to handle JSON
Define a standard JSON translation for link-format
Itrsquos
not
rock
et
scien
ce
ltsensorsgtct=40title=Sensor Index ltsensorstempgtrt=temperature-cif=sensor ltsensorslightgtrt=light-luxif=sensor lthttpwwwexamplecomsensorst123gt anchor=sensorstemprel=describedby lttgtanchor=sensorstemprel=alternate [hrefsensorsct40titleSensor Index hrefsensorstemprttemperature-cifsensor hrefsensorslightrtlight-luxifsensor hrefhttpwwwexamplecomsensorst123 anchorsensorstempreldescribedby hreftanchorsensorstemprelalternate]
124
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-ipsec-for-coap-00txt
IPsec definitions for CoAP Mostly placeholder at this time Who has implementation experience with this
125
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-cross-reverse-convention-00txt
This draft has two lines of payload(based on a WGLC comment by Cullen Jennings)
coap12344567foobara=3
httpwwwproxycomwellknowncore-translate1234_4567foobara=3
Is that a useful convention to have
126
Insert CI slides here
127
128
0
5
10
15
20
25
30
35
40
10 20 30 40 50 60 70
good
put (
pps)
pps
Goodput vs pps (Econotags)
goodput
[Khattak preliminary]
Congestion Control
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-cocoa-00txt
ldquoadvancedrdquo cc (The draft is just a first shot) Others may have better ideas
129
Insert post-WGLC discussion slides here
130
Stop Continue Start
131
An Agile Retrospective
http6lowappnet coreIETF86 2013-03-12-13
Stop
132
Endless new CoAP optionssect instead use RESTful as much as possible
Move general security lifecycle out Looking at theoretical problems
http6lowappnet coreIETF86 2013-03-12-13
Continue
Interops Running code Look at real-world examples and deployments Solve their actual problems
sect Unilateral enhancements eg higher performance congestion control
sect Transports (SMS hellip)sect Make Web linking and Directories more and more usefulsect RESTful Design Paradigms for real-world problems
133
http6lowappnet coreIETF86 2013-03-12-13
Start
Further push into the (browser) web world (HTML5 browser security)
Specific supporting worksect SenMLsect URI work (dev URN hellip)sect Security Processes (next slide)
Spin outsect (We donrsquot really get to decide where this is done)
134
http6lowappnet coreIETF86 2013-03-12-13
Security
Integrate Application Network Group Keyingsect Tunnel-free setup
Donrsquot redo what has been done alreadysect ZigBee IP is finesect But what about other scenarios
Simple REST interfaces for working with keying materials and authorizationsect Start with defining objectives
Object Security for Constrained Nodes135
Re-chartering CoREWhat do we want to do now that wersquore grown up
Zach ShelbyCoRE WG IETF-86 Orlando
What is the scope
bull So we have a protocol and Web Linking what next
bull Keep with what we know besthellip1 Enhancements around CoAP2 New transports for CoAP3 New representations for Web Links4 General application layer solutions
CoRE WG IETF-86 Orlando 2
Enhancements around CoAP
bull Advanced congestion control
CoRE WG IETF-86 Orlando 3
New Transports for CoAP
bull Infrastructure for CoAP over foondash httptoolsietforgiddraft-silverajan-core-
coap-alternative-transports-01txtbull CoAP over SMS
ndash httptoolsietforgiddraft-becker-core-coap-sms-gprs-03txt
ndash OMA Lightweightbull CoAP over TCP
ndash httptoolsietforgiddraft-li-core-coap-payload-length-option-01txt
CoRE WG IETF-86 Orlando 4
New support for Web Links
bull JSON Web Linksndash httptoolsietforgiddraft-bormann-core-links-
json-02txt
2332010 CoRE WG IETF-77 Anaheim 5
General application layer solutions
bull Resource Directoryndash httptoolsietforgiddraft-shelby-core-
resource-directory-05txtndash OMA Lightweight
2332010 CoRE WG IETF-77 Anaheim 6
ldquoGETrdquo ndash Test Scenario 3 Results
maxAge = 5 and 5 Clients
GET ndash Scenario 3 ClientProxy Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
Scenarios 3a - Non-Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3b- Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3c - Sleepy Server Sleep Aware Proxy maxAge = 5sec 5 Clients
0
500
1000
1500
2000
2500
3000
3500
4000
4500
5000
3a 3b 3c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
GET ndash Scenario 3 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
0
1000
2000
3000
4000
5000
6000
7000
3a 3b 3c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
Scenarios 3a - Non-Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3b- Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3c - Sleepy Server Sleep Aware Proxy maxAge = 5sec 5 Clients
Conclusions
Conclusions These results show that sleep-aware CoAP
proxy features can significantly optimize communication with sleepy servers in most scenarios
These results also show that sleep-
awareness capabilities can provide additional benefits above and beyond CoAP caching in most scenarios
Backup
Current CoAP Support of Sleepy Node (12)
CoAP proxies can use a previously cached response to service a new GET request for a sleepy origin server (as in HTTP) But if no valid cache then proxy has to attempt to
retrieve and may fail if origin server is sleeping [I-Dietf-core-coap]
Clients can discover list of resources from RD (GET rd-lookuphellip) for sleepy servers But attempt to GET resource from sleepy origin server
may fail if origin server is sleeping [IDietf-core-link-format amp IDshelby-core-resource-
directory]
Current CoAP Support of Sleepy Node (22)
Lower layer support for sleepy nodes in most wireless technologies (eg WiFi ZigBee) But limited to MAC packet scheduling for sleepy nodes
and not aware of specific needs of IP applications (like CoAP)
Proposal ndash RD Based Sleep Tracking (14)
The current CoAP approach to support sleepy nodes can be significantly improved by introducing RD based mechanisms for a CoAP client to determine whether A targeted resource is located on a sleepy server A sleepy server is currently in sleep mode or not
There is any associated caching Proxy (possibly the RD itself) for a sleepy server
Proposal ndash RD Based Sleep Tracking (24)
We define the following new RD attributes to characterize the properties of a sleepy node SleepState - Indicates whether the node is currently in
sleep mode or not (ie Sleeping or Awake) SleepDuration - Indicates the maximum duration of time
that the node stays in sleep mode TimeSleeping - Indicates the length of time the node
has been sleeping (ie if Sleep State = Sleeping) NextSleep - Indicates the next time the node will go to
sleep (ie if Sleep State = Awake)
CachingProxy ndash Indicates the caching proxy of the sleepy node (ie the RD itself or another node)
Proposal ndash RD Based Sleep Tracking (34)
These attributes are all server (node) level and are new parameters added to the RD URI Template Variables
Finally we also define a new lookup-type (ss) for the RD lookup interface specified in [I-Dshelby-core-resource-directory] This new lookup-type supports looking up the
ldquoSleepStaterdquo (ss) of a specified end-point
Proposal ndash RD Based Sleep Tracking (44)
The three time based parameters (SleepDuration TimeSleeping NextSleep) can be based on either an absolute network time (for a time synchronized network) or a relative local time (measured at the local node)
Following the approach of [I-Dietf-core-link-format] and [I-Dshelby-core-resource-directory] sleep parameters for sleepy servers can be stored by the server in the RD and accessed by all interested clients
Examples of using these parameters in a synchronous or asynchronous manner are shown in the I-D
http6lowappnet coreIETF86 2013-03-12-13
We assume people have read the drafts
Meetings serve to advance difficult issues by making good use of face-to-face communications
Note Well Be aware of the IPR principles according to RFC 3979 and its updates
uumlBlue sheetsuumlScribe(s)
96
drar-shy‐iep-shy‐core-shy‐coapsubmiqed13 to13 IESG
2013-shy‐03-shy‐13
97
OMA Lightweight M2M Overview(A new standard using lots of IETF specs including DTLS
CoAP Block Observe Resource Directory SenMLhellip)
Zach ShelbyCoRE WG IETF-86 Orlando
OMA Lightweight M2Mbull Open Mobile Alliance is well known for Device Management (DM)bull OMA Lightweight M2M is a new standard from the alliance
ndash Focused on constrained Cellular and sensor network M2M devicesndash Driven by leading operators and vendors
bull Scopendash Interfaces protocol amp security between Device and Serverndash Object and Resource modelndash Bootstrap Device Access Control Connectivity and Firmware Objects
bull Draft Specifications are availablendash httpmemberopenmobileallianceorgftpPublic_documentsDM
LightweightM2MPermanent_documentsOMA-TS-LightweightM2M-V1_0_0-20130301-Dzip
bull Timelinendash Requirements and Architecture completed 3Q2012ndash Spec ready for Consistency Review 2Q2013ndash Candidate Approval expected 3Q2013
2 CoRE WG IETF-86 Orlando
Architecture
3
Scope of LWM2M
CoRE WG IETF-86 Orlando
Object Model
bull A Client has one or more Object Instancesbull An Object is a collection of Resourcesbull A Resource is an atomic piece of information
ndash Read Written or Executed
bull Resources can have multiple instancesbull Objects and Resources are identified by a
16-bit Integer Instances by an 8-bit Integerbull ObjectsResources are accessed with
simple URIs Object IDObject InstanceResource ID
eg 1213
4 CoRE WG IETF-86 Orlando
CoRE WG IETF-86 Orlando
CoRE Resource Directory
draft-shelby-core-resource-directory-05
Z Shelby C Bormann S Krco
Backgroundbull Not a new concept
ndash think web search engine or any link directorybull Defines the interfaces to a Resource Directorybull Based on Web Linking framework and the CoRE Link Formatbull Generic REST design for use over HTTP and CoAPbull Used by OMA Lightweight M2Mbull Has already been deployed
ndash In traffic monitoring systemsndash In street lighting systemsndash For vehicular asset trackingndash By a major Cellular M2M operator
Changes since -04
bull Restricted Update to parameter updatesbull Added pagination support for the Lookup interfacebull Changed rt= to et= for the registration amp update
interfacebull Added group support
Group Management
bull RD now includes group management featuresbull New Group Function Set
ndash Register a groupbull Group name domain multicast address endpoint members
ndash Remove a groupbull Group lookup using the Lookup Function Set
ndash List registered groupsndash Find the members of a groupndash Find groups with certain endpoints or resources
Registering a Group
EP RD
| |
| - POST rd-groupgp=lights ltgtep=node1 --gt |
| |
| |
| lt---- 201 Created Location rd-group12 ---- |
| |
Req POST coaprdexamplecomrd-groupgp=lights
Payload
ltgtep=node1
ltgtep=node2
Res 201 Created
Location rd-group12
Looking up Group Members
Client RD
| |
| ----- GET rd-lookupepgp=lights1 ----------------------gt |
| |
| |
| lt-- 205 Content ltrdgtd=domain1ltrdgtd=domain2 --------- |
| |
Req GET rd-lookupepgp=lights1
Res 205 Content
ltcoaphostportgtep=node1
ltcoaphostportgtep=node2rdquo
Things for the futurebull Support for JSON representation of Web Links
ndash httptoolsietforgiddraft-bormann-core-links-json-02txtbull Registry for RD registration query parameters
ndash Already OMA Lightweight has defined some new onesbull More examples
Group 3 ldquonew workrdquo(continued)
109
drar-shy‐greevenbosch-shy‐core-shy‐profile-shy‐descripon-shy‐01Bert13 GreevenboschJeroen13 Hoebeke
Isam13 IshaqFloris13 Van13 den13 Abeele
Descripon
bull JSON13 format13 for13 signalling13 the13 servers13 capabilies
bull Signalling13 of13 supported13 opons13 media13 types13 and13 block13 sizendash Other13 items13 can13 be13 added
bull Filtering13 on13 specific13 fields13 through13 URI-shy‐Querybull Link13 hqpdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐profile-shy‐descripon
well-shy‐knownprofile
bull To13 acquire13 profile13 data13 of13 resources13 on13 a13 parcular13 service13 the13 well-shy‐knownprofile13 URI-shy‐path13 is13 introduced
bull For13 example13 to13 get13 all13 informaon13 from13 sensors13 served13 by13 wwwexampleorg13 we13 can13 do13 a13 GET13 to13 coapwwwexampleorgwell-shy‐knownprofile
bull Filtering13 on13 parcular13 resources13 is13 done13 through13 URI-shy‐Queries
Format
bull Currently13 the13 following13 fields13 are13 definedndash ldquopathrdquo13 contains13 the13 URI-shy‐path13 associated13 with13 a13 resource
ndash ldquooprdquo13 a13 numerical13 list13 of13 supported13 opon13 numbers
ndash ldquocfrdquo13 a13 numerical13 list13 of13 supported13 content-shy‐format13 numbers
ndash ldquob1srdquo13 ldquob2srdquo13 supported13 block13 sizes13 for13 Block113 and13 Block213 respecvely
Examplebull On13 the13 right13 is13 an13 example13 of13 a13 camera13 sensor13 at13 coapwwwexampleorgcam13 that13 supports13 the13 Uri-shy‐Host13 (3)13 ETag13 (4)13 Uri-shy‐Port13 (7)13 Uri-shy‐Path13 (11)13 Content-shy‐Format13 (12)13 Token13 (19)13 Block213 (23)13 and13 Proxy-shy‐Uri13 (35)13 opons
bull The13 supported13 content13 formats13 are13 textplain13 (0)13 applicaon13 link-shy‐format13 (40)13 and13 applicaonjson13 (50)
bull The13 supported13 Block213 can13 use13 25613 or13 51213 byte13 blocks
Req13 GET13 coapwwwexampleorgwell-shy‐knownprofile13 Res13 20513 Content13 (applicationjson)13 13 13 13 profile13 13 13 13 13 13 13 13 pathcam13 13 13 13 op[3471112192335]13 13 13 13 13 cf[04050]13 13 13 13 13 b2s[45]13 13 13 13
Filtering13 through13 use13 of13 URI-shy‐Query
bull Filtering13 can13 be13 done13 through13 the13 URI-shy‐Querybull Query13 format13 N=V
ndash N13 is13 a13 profile13 fieldndash V13 is13 the13 desired13 value
bull Examplesndash To13 find13 resources13 that13 support13 content13 format13 ldquoapplicaonjsonrdquo
13 GET13 wwwexampleorgwell-shy‐knownprofilecf=50ndash To13 get13 informaon13 about13 the13 camera
13 GET13 wwwexampleorgwell-shy‐knownprofilepath=cam
Open13 issues
bull Which13 other13 profile13 data13 needs13 signallingndash Content-shy‐type13 for13 different13 methods
bull Fix13 the13 order13 in13 which13 the13 profile13 fields13 must13 appearndash Non-shy‐fixed13 order13 easier13 extensible
bull Inheritance13 of13 a13 profile13 descriponbull Extend13 usage13 to13 signal13 the13 client13 profilebull Integraon13 with13 link13 format
Thank13 youQuesons
drar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval-shy‐00
Bert13 Greevenbosch
Descripon
bull The13 ldquoMinimumRequestInterval13 opon13 can13 be13 used13 to13 indicate13 the13 minimum13 me13 between13 two13 requests13 in13 a13 transacon
bull Originally13 intended13 for13 Block13 but13 also13 usable13 for13 other13 transaconsndash Example13 browsing13 a13 server
bull The13 goal13 is13 to13 reduce13 the13 server13 load13 and13 network13 traffic
bull Link13 hqpsdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval
Usage
bull The13 client13 keeps13 the13 server13 informed13 about13 its13 request13 speed13 through13 inclusion13 of13 the13 ldquoMinimumRequestIntervalrdquo13 opon
bull In13 responses13 the13 server13 fixes13 the13 minimum13 request13 interval13 through13 the13 same13 opon
bull The13 client13 obeys13 the13 speed13 indicated13 by13 the13 server
bull The13 client13 can13 send13 slower13 but13 not13 faster
Advantages
bull The13 server13 has13 means13 to13 limit13 the13 amount13 of13 incoming13 traffic
bull The13 server13 can13 prevent13 to13 become13 overloaded13 with13 too13 many13 tasks
bull The13 server13 does13 not13 need13 arficially13 slow13 down13 the13 client13 by13 sending13 late13 ACKsndash No13 need13 to13 keep13 track13 of13 delayed13 ACKsndash The13 server13 can13 perform13 other13 tasks13 instead
bull Reduced13 network13 traffic
Thank13 youQuesons
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-links-json-02txt
123
RFC 6690 (link-format) documents are somewhat foreign to many web app developerssect would prefer to have them in JSON format
There is no standard way to represent link-format documents in applicationssect but everyone knows how to handle JSON
Define a standard JSON translation for link-format
Itrsquos
not
rock
et
scien
ce
ltsensorsgtct=40title=Sensor Index ltsensorstempgtrt=temperature-cif=sensor ltsensorslightgtrt=light-luxif=sensor lthttpwwwexamplecomsensorst123gt anchor=sensorstemprel=describedby lttgtanchor=sensorstemprel=alternate [hrefsensorsct40titleSensor Index hrefsensorstemprttemperature-cifsensor hrefsensorslightrtlight-luxifsensor hrefhttpwwwexamplecomsensorst123 anchorsensorstempreldescribedby hreftanchorsensorstemprelalternate]
124
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-ipsec-for-coap-00txt
IPsec definitions for CoAP Mostly placeholder at this time Who has implementation experience with this
125
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-cross-reverse-convention-00txt
This draft has two lines of payload(based on a WGLC comment by Cullen Jennings)
coap12344567foobara=3
httpwwwproxycomwellknowncore-translate1234_4567foobara=3
Is that a useful convention to have
126
Insert CI slides here
127
128
0
5
10
15
20
25
30
35
40
10 20 30 40 50 60 70
good
put (
pps)
pps
Goodput vs pps (Econotags)
goodput
[Khattak preliminary]
Congestion Control
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-cocoa-00txt
ldquoadvancedrdquo cc (The draft is just a first shot) Others may have better ideas
129
Insert post-WGLC discussion slides here
130
Stop Continue Start
131
An Agile Retrospective
http6lowappnet coreIETF86 2013-03-12-13
Stop
132
Endless new CoAP optionssect instead use RESTful as much as possible
Move general security lifecycle out Looking at theoretical problems
http6lowappnet coreIETF86 2013-03-12-13
Continue
Interops Running code Look at real-world examples and deployments Solve their actual problems
sect Unilateral enhancements eg higher performance congestion control
sect Transports (SMS hellip)sect Make Web linking and Directories more and more usefulsect RESTful Design Paradigms for real-world problems
133
http6lowappnet coreIETF86 2013-03-12-13
Start
Further push into the (browser) web world (HTML5 browser security)
Specific supporting worksect SenMLsect URI work (dev URN hellip)sect Security Processes (next slide)
Spin outsect (We donrsquot really get to decide where this is done)
134
http6lowappnet coreIETF86 2013-03-12-13
Security
Integrate Application Network Group Keyingsect Tunnel-free setup
Donrsquot redo what has been done alreadysect ZigBee IP is finesect But what about other scenarios
Simple REST interfaces for working with keying materials and authorizationsect Start with defining objectives
Object Security for Constrained Nodes135
Re-chartering CoREWhat do we want to do now that wersquore grown up
Zach ShelbyCoRE WG IETF-86 Orlando
What is the scope
bull So we have a protocol and Web Linking what next
bull Keep with what we know besthellip1 Enhancements around CoAP2 New transports for CoAP3 New representations for Web Links4 General application layer solutions
CoRE WG IETF-86 Orlando 2
Enhancements around CoAP
bull Advanced congestion control
CoRE WG IETF-86 Orlando 3
New Transports for CoAP
bull Infrastructure for CoAP over foondash httptoolsietforgiddraft-silverajan-core-
coap-alternative-transports-01txtbull CoAP over SMS
ndash httptoolsietforgiddraft-becker-core-coap-sms-gprs-03txt
ndash OMA Lightweightbull CoAP over TCP
ndash httptoolsietforgiddraft-li-core-coap-payload-length-option-01txt
CoRE WG IETF-86 Orlando 4
New support for Web Links
bull JSON Web Linksndash httptoolsietforgiddraft-bormann-core-links-
json-02txt
2332010 CoRE WG IETF-77 Anaheim 5
General application layer solutions
bull Resource Directoryndash httptoolsietforgiddraft-shelby-core-
resource-directory-05txtndash OMA Lightweight
2332010 CoRE WG IETF-77 Anaheim 6
GET ndash Scenario 3 ClientProxy Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
Scenarios 3a - Non-Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3b- Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3c - Sleepy Server Sleep Aware Proxy maxAge = 5sec 5 Clients
0
500
1000
1500
2000
2500
3000
3500
4000
4500
5000
3a 3b 3c Scenarios
ClientProxy Interface Transactions
ACK
504
205
GET
GET ndash Scenario 3 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
0
1000
2000
3000
4000
5000
6000
7000
3a 3b 3c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
Scenarios 3a - Non-Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3b- Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3c - Sleepy Server Sleep Aware Proxy maxAge = 5sec 5 Clients
Conclusions
Conclusions These results show that sleep-aware CoAP
proxy features can significantly optimize communication with sleepy servers in most scenarios
These results also show that sleep-
awareness capabilities can provide additional benefits above and beyond CoAP caching in most scenarios
Backup
Current CoAP Support of Sleepy Node (12)
CoAP proxies can use a previously cached response to service a new GET request for a sleepy origin server (as in HTTP) But if no valid cache then proxy has to attempt to
retrieve and may fail if origin server is sleeping [I-Dietf-core-coap]
Clients can discover list of resources from RD (GET rd-lookuphellip) for sleepy servers But attempt to GET resource from sleepy origin server
may fail if origin server is sleeping [IDietf-core-link-format amp IDshelby-core-resource-
directory]
Current CoAP Support of Sleepy Node (22)
Lower layer support for sleepy nodes in most wireless technologies (eg WiFi ZigBee) But limited to MAC packet scheduling for sleepy nodes
and not aware of specific needs of IP applications (like CoAP)
Proposal ndash RD Based Sleep Tracking (14)
The current CoAP approach to support sleepy nodes can be significantly improved by introducing RD based mechanisms for a CoAP client to determine whether A targeted resource is located on a sleepy server A sleepy server is currently in sleep mode or not
There is any associated caching Proxy (possibly the RD itself) for a sleepy server
Proposal ndash RD Based Sleep Tracking (24)
We define the following new RD attributes to characterize the properties of a sleepy node SleepState - Indicates whether the node is currently in
sleep mode or not (ie Sleeping or Awake) SleepDuration - Indicates the maximum duration of time
that the node stays in sleep mode TimeSleeping - Indicates the length of time the node
has been sleeping (ie if Sleep State = Sleeping) NextSleep - Indicates the next time the node will go to
sleep (ie if Sleep State = Awake)
CachingProxy ndash Indicates the caching proxy of the sleepy node (ie the RD itself or another node)
Proposal ndash RD Based Sleep Tracking (34)
These attributes are all server (node) level and are new parameters added to the RD URI Template Variables
Finally we also define a new lookup-type (ss) for the RD lookup interface specified in [I-Dshelby-core-resource-directory] This new lookup-type supports looking up the
ldquoSleepStaterdquo (ss) of a specified end-point
Proposal ndash RD Based Sleep Tracking (44)
The three time based parameters (SleepDuration TimeSleeping NextSleep) can be based on either an absolute network time (for a time synchronized network) or a relative local time (measured at the local node)
Following the approach of [I-Dietf-core-link-format] and [I-Dshelby-core-resource-directory] sleep parameters for sleepy servers can be stored by the server in the RD and accessed by all interested clients
Examples of using these parameters in a synchronous or asynchronous manner are shown in the I-D
http6lowappnet coreIETF86 2013-03-12-13
We assume people have read the drafts
Meetings serve to advance difficult issues by making good use of face-to-face communications
Note Well Be aware of the IPR principles according to RFC 3979 and its updates
uumlBlue sheetsuumlScribe(s)
96
drar-shy‐iep-shy‐core-shy‐coapsubmiqed13 to13 IESG
2013-shy‐03-shy‐13
97
OMA Lightweight M2M Overview(A new standard using lots of IETF specs including DTLS
CoAP Block Observe Resource Directory SenMLhellip)
Zach ShelbyCoRE WG IETF-86 Orlando
OMA Lightweight M2Mbull Open Mobile Alliance is well known for Device Management (DM)bull OMA Lightweight M2M is a new standard from the alliance
ndash Focused on constrained Cellular and sensor network M2M devicesndash Driven by leading operators and vendors
bull Scopendash Interfaces protocol amp security between Device and Serverndash Object and Resource modelndash Bootstrap Device Access Control Connectivity and Firmware Objects
bull Draft Specifications are availablendash httpmemberopenmobileallianceorgftpPublic_documentsDM
LightweightM2MPermanent_documentsOMA-TS-LightweightM2M-V1_0_0-20130301-Dzip
bull Timelinendash Requirements and Architecture completed 3Q2012ndash Spec ready for Consistency Review 2Q2013ndash Candidate Approval expected 3Q2013
2 CoRE WG IETF-86 Orlando
Architecture
3
Scope of LWM2M
CoRE WG IETF-86 Orlando
Object Model
bull A Client has one or more Object Instancesbull An Object is a collection of Resourcesbull A Resource is an atomic piece of information
ndash Read Written or Executed
bull Resources can have multiple instancesbull Objects and Resources are identified by a
16-bit Integer Instances by an 8-bit Integerbull ObjectsResources are accessed with
simple URIs Object IDObject InstanceResource ID
eg 1213
4 CoRE WG IETF-86 Orlando
CoRE WG IETF-86 Orlando
CoRE Resource Directory
draft-shelby-core-resource-directory-05
Z Shelby C Bormann S Krco
Backgroundbull Not a new concept
ndash think web search engine or any link directorybull Defines the interfaces to a Resource Directorybull Based on Web Linking framework and the CoRE Link Formatbull Generic REST design for use over HTTP and CoAPbull Used by OMA Lightweight M2Mbull Has already been deployed
ndash In traffic monitoring systemsndash In street lighting systemsndash For vehicular asset trackingndash By a major Cellular M2M operator
Changes since -04
bull Restricted Update to parameter updatesbull Added pagination support for the Lookup interfacebull Changed rt= to et= for the registration amp update
interfacebull Added group support
Group Management
bull RD now includes group management featuresbull New Group Function Set
ndash Register a groupbull Group name domain multicast address endpoint members
ndash Remove a groupbull Group lookup using the Lookup Function Set
ndash List registered groupsndash Find the members of a groupndash Find groups with certain endpoints or resources
Registering a Group
EP RD
| |
| - POST rd-groupgp=lights ltgtep=node1 --gt |
| |
| |
| lt---- 201 Created Location rd-group12 ---- |
| |
Req POST coaprdexamplecomrd-groupgp=lights
Payload
ltgtep=node1
ltgtep=node2
Res 201 Created
Location rd-group12
Looking up Group Members
Client RD
| |
| ----- GET rd-lookupepgp=lights1 ----------------------gt |
| |
| |
| lt-- 205 Content ltrdgtd=domain1ltrdgtd=domain2 --------- |
| |
Req GET rd-lookupepgp=lights1
Res 205 Content
ltcoaphostportgtep=node1
ltcoaphostportgtep=node2rdquo
Things for the futurebull Support for JSON representation of Web Links
ndash httptoolsietforgiddraft-bormann-core-links-json-02txtbull Registry for RD registration query parameters
ndash Already OMA Lightweight has defined some new onesbull More examples
Group 3 ldquonew workrdquo(continued)
109
drar-shy‐greevenbosch-shy‐core-shy‐profile-shy‐descripon-shy‐01Bert13 GreevenboschJeroen13 Hoebeke
Isam13 IshaqFloris13 Van13 den13 Abeele
Descripon
bull JSON13 format13 for13 signalling13 the13 servers13 capabilies
bull Signalling13 of13 supported13 opons13 media13 types13 and13 block13 sizendash Other13 items13 can13 be13 added
bull Filtering13 on13 specific13 fields13 through13 URI-shy‐Querybull Link13 hqpdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐profile-shy‐descripon
well-shy‐knownprofile
bull To13 acquire13 profile13 data13 of13 resources13 on13 a13 parcular13 service13 the13 well-shy‐knownprofile13 URI-shy‐path13 is13 introduced
bull For13 example13 to13 get13 all13 informaon13 from13 sensors13 served13 by13 wwwexampleorg13 we13 can13 do13 a13 GET13 to13 coapwwwexampleorgwell-shy‐knownprofile
bull Filtering13 on13 parcular13 resources13 is13 done13 through13 URI-shy‐Queries
Format
bull Currently13 the13 following13 fields13 are13 definedndash ldquopathrdquo13 contains13 the13 URI-shy‐path13 associated13 with13 a13 resource
ndash ldquooprdquo13 a13 numerical13 list13 of13 supported13 opon13 numbers
ndash ldquocfrdquo13 a13 numerical13 list13 of13 supported13 content-shy‐format13 numbers
ndash ldquob1srdquo13 ldquob2srdquo13 supported13 block13 sizes13 for13 Block113 and13 Block213 respecvely
Examplebull On13 the13 right13 is13 an13 example13 of13 a13 camera13 sensor13 at13 coapwwwexampleorgcam13 that13 supports13 the13 Uri-shy‐Host13 (3)13 ETag13 (4)13 Uri-shy‐Port13 (7)13 Uri-shy‐Path13 (11)13 Content-shy‐Format13 (12)13 Token13 (19)13 Block213 (23)13 and13 Proxy-shy‐Uri13 (35)13 opons
bull The13 supported13 content13 formats13 are13 textplain13 (0)13 applicaon13 link-shy‐format13 (40)13 and13 applicaonjson13 (50)
bull The13 supported13 Block213 can13 use13 25613 or13 51213 byte13 blocks
Req13 GET13 coapwwwexampleorgwell-shy‐knownprofile13 Res13 20513 Content13 (applicationjson)13 13 13 13 profile13 13 13 13 13 13 13 13 pathcam13 13 13 13 op[3471112192335]13 13 13 13 13 cf[04050]13 13 13 13 13 b2s[45]13 13 13 13
Filtering13 through13 use13 of13 URI-shy‐Query
bull Filtering13 can13 be13 done13 through13 the13 URI-shy‐Querybull Query13 format13 N=V
ndash N13 is13 a13 profile13 fieldndash V13 is13 the13 desired13 value
bull Examplesndash To13 find13 resources13 that13 support13 content13 format13 ldquoapplicaonjsonrdquo
13 GET13 wwwexampleorgwell-shy‐knownprofilecf=50ndash To13 get13 informaon13 about13 the13 camera
13 GET13 wwwexampleorgwell-shy‐knownprofilepath=cam
Open13 issues
bull Which13 other13 profile13 data13 needs13 signallingndash Content-shy‐type13 for13 different13 methods
bull Fix13 the13 order13 in13 which13 the13 profile13 fields13 must13 appearndash Non-shy‐fixed13 order13 easier13 extensible
bull Inheritance13 of13 a13 profile13 descriponbull Extend13 usage13 to13 signal13 the13 client13 profilebull Integraon13 with13 link13 format
Thank13 youQuesons
drar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval-shy‐00
Bert13 Greevenbosch
Descripon
bull The13 ldquoMinimumRequestInterval13 opon13 can13 be13 used13 to13 indicate13 the13 minimum13 me13 between13 two13 requests13 in13 a13 transacon
bull Originally13 intended13 for13 Block13 but13 also13 usable13 for13 other13 transaconsndash Example13 browsing13 a13 server
bull The13 goal13 is13 to13 reduce13 the13 server13 load13 and13 network13 traffic
bull Link13 hqpsdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval
Usage
bull The13 client13 keeps13 the13 server13 informed13 about13 its13 request13 speed13 through13 inclusion13 of13 the13 ldquoMinimumRequestIntervalrdquo13 opon
bull In13 responses13 the13 server13 fixes13 the13 minimum13 request13 interval13 through13 the13 same13 opon
bull The13 client13 obeys13 the13 speed13 indicated13 by13 the13 server
bull The13 client13 can13 send13 slower13 but13 not13 faster
Advantages
bull The13 server13 has13 means13 to13 limit13 the13 amount13 of13 incoming13 traffic
bull The13 server13 can13 prevent13 to13 become13 overloaded13 with13 too13 many13 tasks
bull The13 server13 does13 not13 need13 arficially13 slow13 down13 the13 client13 by13 sending13 late13 ACKsndash No13 need13 to13 keep13 track13 of13 delayed13 ACKsndash The13 server13 can13 perform13 other13 tasks13 instead
bull Reduced13 network13 traffic
Thank13 youQuesons
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-links-json-02txt
123
RFC 6690 (link-format) documents are somewhat foreign to many web app developerssect would prefer to have them in JSON format
There is no standard way to represent link-format documents in applicationssect but everyone knows how to handle JSON
Define a standard JSON translation for link-format
Itrsquos
not
rock
et
scien
ce
ltsensorsgtct=40title=Sensor Index ltsensorstempgtrt=temperature-cif=sensor ltsensorslightgtrt=light-luxif=sensor lthttpwwwexamplecomsensorst123gt anchor=sensorstemprel=describedby lttgtanchor=sensorstemprel=alternate [hrefsensorsct40titleSensor Index hrefsensorstemprttemperature-cifsensor hrefsensorslightrtlight-luxifsensor hrefhttpwwwexamplecomsensorst123 anchorsensorstempreldescribedby hreftanchorsensorstemprelalternate]
124
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-ipsec-for-coap-00txt
IPsec definitions for CoAP Mostly placeholder at this time Who has implementation experience with this
125
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-cross-reverse-convention-00txt
This draft has two lines of payload(based on a WGLC comment by Cullen Jennings)
coap12344567foobara=3
httpwwwproxycomwellknowncore-translate1234_4567foobara=3
Is that a useful convention to have
126
Insert CI slides here
127
128
0
5
10
15
20
25
30
35
40
10 20 30 40 50 60 70
good
put (
pps)
pps
Goodput vs pps (Econotags)
goodput
[Khattak preliminary]
Congestion Control
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-cocoa-00txt
ldquoadvancedrdquo cc (The draft is just a first shot) Others may have better ideas
129
Insert post-WGLC discussion slides here
130
Stop Continue Start
131
An Agile Retrospective
http6lowappnet coreIETF86 2013-03-12-13
Stop
132
Endless new CoAP optionssect instead use RESTful as much as possible
Move general security lifecycle out Looking at theoretical problems
http6lowappnet coreIETF86 2013-03-12-13
Continue
Interops Running code Look at real-world examples and deployments Solve their actual problems
sect Unilateral enhancements eg higher performance congestion control
sect Transports (SMS hellip)sect Make Web linking and Directories more and more usefulsect RESTful Design Paradigms for real-world problems
133
http6lowappnet coreIETF86 2013-03-12-13
Start
Further push into the (browser) web world (HTML5 browser security)
Specific supporting worksect SenMLsect URI work (dev URN hellip)sect Security Processes (next slide)
Spin outsect (We donrsquot really get to decide where this is done)
134
http6lowappnet coreIETF86 2013-03-12-13
Security
Integrate Application Network Group Keyingsect Tunnel-free setup
Donrsquot redo what has been done alreadysect ZigBee IP is finesect But what about other scenarios
Simple REST interfaces for working with keying materials and authorizationsect Start with defining objectives
Object Security for Constrained Nodes135
Re-chartering CoREWhat do we want to do now that wersquore grown up
Zach ShelbyCoRE WG IETF-86 Orlando
What is the scope
bull So we have a protocol and Web Linking what next
bull Keep with what we know besthellip1 Enhancements around CoAP2 New transports for CoAP3 New representations for Web Links4 General application layer solutions
CoRE WG IETF-86 Orlando 2
Enhancements around CoAP
bull Advanced congestion control
CoRE WG IETF-86 Orlando 3
New Transports for CoAP
bull Infrastructure for CoAP over foondash httptoolsietforgiddraft-silverajan-core-
coap-alternative-transports-01txtbull CoAP over SMS
ndash httptoolsietforgiddraft-becker-core-coap-sms-gprs-03txt
ndash OMA Lightweightbull CoAP over TCP
ndash httptoolsietforgiddraft-li-core-coap-payload-length-option-01txt
CoRE WG IETF-86 Orlando 4
New support for Web Links
bull JSON Web Linksndash httptoolsietforgiddraft-bormann-core-links-
json-02txt
2332010 CoRE WG IETF-77 Anaheim 5
General application layer solutions
bull Resource Directoryndash httptoolsietforgiddraft-shelby-core-
resource-directory-05txtndash OMA Lightweight
2332010 CoRE WG IETF-77 Anaheim 6
GET ndash Scenario 3 ProxyServer Interface Transaction Mix
Sleep Aware Proxy has better performance for sleepy servers
0
1000
2000
3000
4000
5000
6000
7000
3a 3b 3c Scenarios
ProxyServer Interface Transactions
204 - Sleep State Update
PUT - Sleep State Update
205
GET
Scenarios 3a - Non-Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3b- Sleepy Server Caching Proxy maxAge = 5sec 5 Clients 3c - Sleepy Server Sleep Aware Proxy maxAge = 5sec 5 Clients
Conclusions
Conclusions These results show that sleep-aware CoAP
proxy features can significantly optimize communication with sleepy servers in most scenarios
These results also show that sleep-
awareness capabilities can provide additional benefits above and beyond CoAP caching in most scenarios
Backup
Current CoAP Support of Sleepy Node (12)
CoAP proxies can use a previously cached response to service a new GET request for a sleepy origin server (as in HTTP) But if no valid cache then proxy has to attempt to
retrieve and may fail if origin server is sleeping [I-Dietf-core-coap]
Clients can discover list of resources from RD (GET rd-lookuphellip) for sleepy servers But attempt to GET resource from sleepy origin server
may fail if origin server is sleeping [IDietf-core-link-format amp IDshelby-core-resource-
directory]
Current CoAP Support of Sleepy Node (22)
Lower layer support for sleepy nodes in most wireless technologies (eg WiFi ZigBee) But limited to MAC packet scheduling for sleepy nodes
and not aware of specific needs of IP applications (like CoAP)
Proposal ndash RD Based Sleep Tracking (14)
The current CoAP approach to support sleepy nodes can be significantly improved by introducing RD based mechanisms for a CoAP client to determine whether A targeted resource is located on a sleepy server A sleepy server is currently in sleep mode or not
There is any associated caching Proxy (possibly the RD itself) for a sleepy server
Proposal ndash RD Based Sleep Tracking (24)
We define the following new RD attributes to characterize the properties of a sleepy node SleepState - Indicates whether the node is currently in
sleep mode or not (ie Sleeping or Awake) SleepDuration - Indicates the maximum duration of time
that the node stays in sleep mode TimeSleeping - Indicates the length of time the node
has been sleeping (ie if Sleep State = Sleeping) NextSleep - Indicates the next time the node will go to
sleep (ie if Sleep State = Awake)
CachingProxy ndash Indicates the caching proxy of the sleepy node (ie the RD itself or another node)
Proposal ndash RD Based Sleep Tracking (34)
These attributes are all server (node) level and are new parameters added to the RD URI Template Variables
Finally we also define a new lookup-type (ss) for the RD lookup interface specified in [I-Dshelby-core-resource-directory] This new lookup-type supports looking up the
ldquoSleepStaterdquo (ss) of a specified end-point
Proposal ndash RD Based Sleep Tracking (44)
The three time based parameters (SleepDuration TimeSleeping NextSleep) can be based on either an absolute network time (for a time synchronized network) or a relative local time (measured at the local node)
Following the approach of [I-Dietf-core-link-format] and [I-Dshelby-core-resource-directory] sleep parameters for sleepy servers can be stored by the server in the RD and accessed by all interested clients
Examples of using these parameters in a synchronous or asynchronous manner are shown in the I-D
http6lowappnet coreIETF86 2013-03-12-13
We assume people have read the drafts
Meetings serve to advance difficult issues by making good use of face-to-face communications
Note Well Be aware of the IPR principles according to RFC 3979 and its updates
uumlBlue sheetsuumlScribe(s)
96
drar-shy‐iep-shy‐core-shy‐coapsubmiqed13 to13 IESG
2013-shy‐03-shy‐13
97
OMA Lightweight M2M Overview(A new standard using lots of IETF specs including DTLS
CoAP Block Observe Resource Directory SenMLhellip)
Zach ShelbyCoRE WG IETF-86 Orlando
OMA Lightweight M2Mbull Open Mobile Alliance is well known for Device Management (DM)bull OMA Lightweight M2M is a new standard from the alliance
ndash Focused on constrained Cellular and sensor network M2M devicesndash Driven by leading operators and vendors
bull Scopendash Interfaces protocol amp security between Device and Serverndash Object and Resource modelndash Bootstrap Device Access Control Connectivity and Firmware Objects
bull Draft Specifications are availablendash httpmemberopenmobileallianceorgftpPublic_documentsDM
LightweightM2MPermanent_documentsOMA-TS-LightweightM2M-V1_0_0-20130301-Dzip
bull Timelinendash Requirements and Architecture completed 3Q2012ndash Spec ready for Consistency Review 2Q2013ndash Candidate Approval expected 3Q2013
2 CoRE WG IETF-86 Orlando
Architecture
3
Scope of LWM2M
CoRE WG IETF-86 Orlando
Object Model
bull A Client has one or more Object Instancesbull An Object is a collection of Resourcesbull A Resource is an atomic piece of information
ndash Read Written or Executed
bull Resources can have multiple instancesbull Objects and Resources are identified by a
16-bit Integer Instances by an 8-bit Integerbull ObjectsResources are accessed with
simple URIs Object IDObject InstanceResource ID
eg 1213
4 CoRE WG IETF-86 Orlando
CoRE WG IETF-86 Orlando
CoRE Resource Directory
draft-shelby-core-resource-directory-05
Z Shelby C Bormann S Krco
Backgroundbull Not a new concept
ndash think web search engine or any link directorybull Defines the interfaces to a Resource Directorybull Based on Web Linking framework and the CoRE Link Formatbull Generic REST design for use over HTTP and CoAPbull Used by OMA Lightweight M2Mbull Has already been deployed
ndash In traffic monitoring systemsndash In street lighting systemsndash For vehicular asset trackingndash By a major Cellular M2M operator
Changes since -04
bull Restricted Update to parameter updatesbull Added pagination support for the Lookup interfacebull Changed rt= to et= for the registration amp update
interfacebull Added group support
Group Management
bull RD now includes group management featuresbull New Group Function Set
ndash Register a groupbull Group name domain multicast address endpoint members
ndash Remove a groupbull Group lookup using the Lookup Function Set
ndash List registered groupsndash Find the members of a groupndash Find groups with certain endpoints or resources
Registering a Group
EP RD
| |
| - POST rd-groupgp=lights ltgtep=node1 --gt |
| |
| |
| lt---- 201 Created Location rd-group12 ---- |
| |
Req POST coaprdexamplecomrd-groupgp=lights
Payload
ltgtep=node1
ltgtep=node2
Res 201 Created
Location rd-group12
Looking up Group Members
Client RD
| |
| ----- GET rd-lookupepgp=lights1 ----------------------gt |
| |
| |
| lt-- 205 Content ltrdgtd=domain1ltrdgtd=domain2 --------- |
| |
Req GET rd-lookupepgp=lights1
Res 205 Content
ltcoaphostportgtep=node1
ltcoaphostportgtep=node2rdquo
Things for the futurebull Support for JSON representation of Web Links
ndash httptoolsietforgiddraft-bormann-core-links-json-02txtbull Registry for RD registration query parameters
ndash Already OMA Lightweight has defined some new onesbull More examples
Group 3 ldquonew workrdquo(continued)
109
drar-shy‐greevenbosch-shy‐core-shy‐profile-shy‐descripon-shy‐01Bert13 GreevenboschJeroen13 Hoebeke
Isam13 IshaqFloris13 Van13 den13 Abeele
Descripon
bull JSON13 format13 for13 signalling13 the13 servers13 capabilies
bull Signalling13 of13 supported13 opons13 media13 types13 and13 block13 sizendash Other13 items13 can13 be13 added
bull Filtering13 on13 specific13 fields13 through13 URI-shy‐Querybull Link13 hqpdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐profile-shy‐descripon
well-shy‐knownprofile
bull To13 acquire13 profile13 data13 of13 resources13 on13 a13 parcular13 service13 the13 well-shy‐knownprofile13 URI-shy‐path13 is13 introduced
bull For13 example13 to13 get13 all13 informaon13 from13 sensors13 served13 by13 wwwexampleorg13 we13 can13 do13 a13 GET13 to13 coapwwwexampleorgwell-shy‐knownprofile
bull Filtering13 on13 parcular13 resources13 is13 done13 through13 URI-shy‐Queries
Format
bull Currently13 the13 following13 fields13 are13 definedndash ldquopathrdquo13 contains13 the13 URI-shy‐path13 associated13 with13 a13 resource
ndash ldquooprdquo13 a13 numerical13 list13 of13 supported13 opon13 numbers
ndash ldquocfrdquo13 a13 numerical13 list13 of13 supported13 content-shy‐format13 numbers
ndash ldquob1srdquo13 ldquob2srdquo13 supported13 block13 sizes13 for13 Block113 and13 Block213 respecvely
Examplebull On13 the13 right13 is13 an13 example13 of13 a13 camera13 sensor13 at13 coapwwwexampleorgcam13 that13 supports13 the13 Uri-shy‐Host13 (3)13 ETag13 (4)13 Uri-shy‐Port13 (7)13 Uri-shy‐Path13 (11)13 Content-shy‐Format13 (12)13 Token13 (19)13 Block213 (23)13 and13 Proxy-shy‐Uri13 (35)13 opons
bull The13 supported13 content13 formats13 are13 textplain13 (0)13 applicaon13 link-shy‐format13 (40)13 and13 applicaonjson13 (50)
bull The13 supported13 Block213 can13 use13 25613 or13 51213 byte13 blocks
Req13 GET13 coapwwwexampleorgwell-shy‐knownprofile13 Res13 20513 Content13 (applicationjson)13 13 13 13 profile13 13 13 13 13 13 13 13 pathcam13 13 13 13 op[3471112192335]13 13 13 13 13 cf[04050]13 13 13 13 13 b2s[45]13 13 13 13
Filtering13 through13 use13 of13 URI-shy‐Query
bull Filtering13 can13 be13 done13 through13 the13 URI-shy‐Querybull Query13 format13 N=V
ndash N13 is13 a13 profile13 fieldndash V13 is13 the13 desired13 value
bull Examplesndash To13 find13 resources13 that13 support13 content13 format13 ldquoapplicaonjsonrdquo
13 GET13 wwwexampleorgwell-shy‐knownprofilecf=50ndash To13 get13 informaon13 about13 the13 camera
13 GET13 wwwexampleorgwell-shy‐knownprofilepath=cam
Open13 issues
bull Which13 other13 profile13 data13 needs13 signallingndash Content-shy‐type13 for13 different13 methods
bull Fix13 the13 order13 in13 which13 the13 profile13 fields13 must13 appearndash Non-shy‐fixed13 order13 easier13 extensible
bull Inheritance13 of13 a13 profile13 descriponbull Extend13 usage13 to13 signal13 the13 client13 profilebull Integraon13 with13 link13 format
Thank13 youQuesons
drar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval-shy‐00
Bert13 Greevenbosch
Descripon
bull The13 ldquoMinimumRequestInterval13 opon13 can13 be13 used13 to13 indicate13 the13 minimum13 me13 between13 two13 requests13 in13 a13 transacon
bull Originally13 intended13 for13 Block13 but13 also13 usable13 for13 other13 transaconsndash Example13 browsing13 a13 server
bull The13 goal13 is13 to13 reduce13 the13 server13 load13 and13 network13 traffic
bull Link13 hqpsdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval
Usage
bull The13 client13 keeps13 the13 server13 informed13 about13 its13 request13 speed13 through13 inclusion13 of13 the13 ldquoMinimumRequestIntervalrdquo13 opon
bull In13 responses13 the13 server13 fixes13 the13 minimum13 request13 interval13 through13 the13 same13 opon
bull The13 client13 obeys13 the13 speed13 indicated13 by13 the13 server
bull The13 client13 can13 send13 slower13 but13 not13 faster
Advantages
bull The13 server13 has13 means13 to13 limit13 the13 amount13 of13 incoming13 traffic
bull The13 server13 can13 prevent13 to13 become13 overloaded13 with13 too13 many13 tasks
bull The13 server13 does13 not13 need13 arficially13 slow13 down13 the13 client13 by13 sending13 late13 ACKsndash No13 need13 to13 keep13 track13 of13 delayed13 ACKsndash The13 server13 can13 perform13 other13 tasks13 instead
bull Reduced13 network13 traffic
Thank13 youQuesons
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-links-json-02txt
123
RFC 6690 (link-format) documents are somewhat foreign to many web app developerssect would prefer to have them in JSON format
There is no standard way to represent link-format documents in applicationssect but everyone knows how to handle JSON
Define a standard JSON translation for link-format
Itrsquos
not
rock
et
scien
ce
ltsensorsgtct=40title=Sensor Index ltsensorstempgtrt=temperature-cif=sensor ltsensorslightgtrt=light-luxif=sensor lthttpwwwexamplecomsensorst123gt anchor=sensorstemprel=describedby lttgtanchor=sensorstemprel=alternate [hrefsensorsct40titleSensor Index hrefsensorstemprttemperature-cifsensor hrefsensorslightrtlight-luxifsensor hrefhttpwwwexamplecomsensorst123 anchorsensorstempreldescribedby hreftanchorsensorstemprelalternate]
124
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-ipsec-for-coap-00txt
IPsec definitions for CoAP Mostly placeholder at this time Who has implementation experience with this
125
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-cross-reverse-convention-00txt
This draft has two lines of payload(based on a WGLC comment by Cullen Jennings)
coap12344567foobara=3
httpwwwproxycomwellknowncore-translate1234_4567foobara=3
Is that a useful convention to have
126
Insert CI slides here
127
128
0
5
10
15
20
25
30
35
40
10 20 30 40 50 60 70
good
put (
pps)
pps
Goodput vs pps (Econotags)
goodput
[Khattak preliminary]
Congestion Control
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-cocoa-00txt
ldquoadvancedrdquo cc (The draft is just a first shot) Others may have better ideas
129
Insert post-WGLC discussion slides here
130
Stop Continue Start
131
An Agile Retrospective
http6lowappnet coreIETF86 2013-03-12-13
Stop
132
Endless new CoAP optionssect instead use RESTful as much as possible
Move general security lifecycle out Looking at theoretical problems
http6lowappnet coreIETF86 2013-03-12-13
Continue
Interops Running code Look at real-world examples and deployments Solve their actual problems
sect Unilateral enhancements eg higher performance congestion control
sect Transports (SMS hellip)sect Make Web linking and Directories more and more usefulsect RESTful Design Paradigms for real-world problems
133
http6lowappnet coreIETF86 2013-03-12-13
Start
Further push into the (browser) web world (HTML5 browser security)
Specific supporting worksect SenMLsect URI work (dev URN hellip)sect Security Processes (next slide)
Spin outsect (We donrsquot really get to decide where this is done)
134
http6lowappnet coreIETF86 2013-03-12-13
Security
Integrate Application Network Group Keyingsect Tunnel-free setup
Donrsquot redo what has been done alreadysect ZigBee IP is finesect But what about other scenarios
Simple REST interfaces for working with keying materials and authorizationsect Start with defining objectives
Object Security for Constrained Nodes135
Re-chartering CoREWhat do we want to do now that wersquore grown up
Zach ShelbyCoRE WG IETF-86 Orlando
What is the scope
bull So we have a protocol and Web Linking what next
bull Keep with what we know besthellip1 Enhancements around CoAP2 New transports for CoAP3 New representations for Web Links4 General application layer solutions
CoRE WG IETF-86 Orlando 2
Enhancements around CoAP
bull Advanced congestion control
CoRE WG IETF-86 Orlando 3
New Transports for CoAP
bull Infrastructure for CoAP over foondash httptoolsietforgiddraft-silverajan-core-
coap-alternative-transports-01txtbull CoAP over SMS
ndash httptoolsietforgiddraft-becker-core-coap-sms-gprs-03txt
ndash OMA Lightweightbull CoAP over TCP
ndash httptoolsietforgiddraft-li-core-coap-payload-length-option-01txt
CoRE WG IETF-86 Orlando 4
New support for Web Links
bull JSON Web Linksndash httptoolsietforgiddraft-bormann-core-links-
json-02txt
2332010 CoRE WG IETF-77 Anaheim 5
General application layer solutions
bull Resource Directoryndash httptoolsietforgiddraft-shelby-core-
resource-directory-05txtndash OMA Lightweight
2332010 CoRE WG IETF-77 Anaheim 6
Conclusions
Conclusions These results show that sleep-aware CoAP
proxy features can significantly optimize communication with sleepy servers in most scenarios
These results also show that sleep-
awareness capabilities can provide additional benefits above and beyond CoAP caching in most scenarios
Backup
Current CoAP Support of Sleepy Node (12)
CoAP proxies can use a previously cached response to service a new GET request for a sleepy origin server (as in HTTP) But if no valid cache then proxy has to attempt to
retrieve and may fail if origin server is sleeping [I-Dietf-core-coap]
Clients can discover list of resources from RD (GET rd-lookuphellip) for sleepy servers But attempt to GET resource from sleepy origin server
may fail if origin server is sleeping [IDietf-core-link-format amp IDshelby-core-resource-
directory]
Current CoAP Support of Sleepy Node (22)
Lower layer support for sleepy nodes in most wireless technologies (eg WiFi ZigBee) But limited to MAC packet scheduling for sleepy nodes
and not aware of specific needs of IP applications (like CoAP)
Proposal ndash RD Based Sleep Tracking (14)
The current CoAP approach to support sleepy nodes can be significantly improved by introducing RD based mechanisms for a CoAP client to determine whether A targeted resource is located on a sleepy server A sleepy server is currently in sleep mode or not
There is any associated caching Proxy (possibly the RD itself) for a sleepy server
Proposal ndash RD Based Sleep Tracking (24)
We define the following new RD attributes to characterize the properties of a sleepy node SleepState - Indicates whether the node is currently in
sleep mode or not (ie Sleeping or Awake) SleepDuration - Indicates the maximum duration of time
that the node stays in sleep mode TimeSleeping - Indicates the length of time the node
has been sleeping (ie if Sleep State = Sleeping) NextSleep - Indicates the next time the node will go to
sleep (ie if Sleep State = Awake)
CachingProxy ndash Indicates the caching proxy of the sleepy node (ie the RD itself or another node)
Proposal ndash RD Based Sleep Tracking (34)
These attributes are all server (node) level and are new parameters added to the RD URI Template Variables
Finally we also define a new lookup-type (ss) for the RD lookup interface specified in [I-Dshelby-core-resource-directory] This new lookup-type supports looking up the
ldquoSleepStaterdquo (ss) of a specified end-point
Proposal ndash RD Based Sleep Tracking (44)
The three time based parameters (SleepDuration TimeSleeping NextSleep) can be based on either an absolute network time (for a time synchronized network) or a relative local time (measured at the local node)
Following the approach of [I-Dietf-core-link-format] and [I-Dshelby-core-resource-directory] sleep parameters for sleepy servers can be stored by the server in the RD and accessed by all interested clients
Examples of using these parameters in a synchronous or asynchronous manner are shown in the I-D
http6lowappnet coreIETF86 2013-03-12-13
We assume people have read the drafts
Meetings serve to advance difficult issues by making good use of face-to-face communications
Note Well Be aware of the IPR principles according to RFC 3979 and its updates
uumlBlue sheetsuumlScribe(s)
96
drar-shy‐iep-shy‐core-shy‐coapsubmiqed13 to13 IESG
2013-shy‐03-shy‐13
97
OMA Lightweight M2M Overview(A new standard using lots of IETF specs including DTLS
CoAP Block Observe Resource Directory SenMLhellip)
Zach ShelbyCoRE WG IETF-86 Orlando
OMA Lightweight M2Mbull Open Mobile Alliance is well known for Device Management (DM)bull OMA Lightweight M2M is a new standard from the alliance
ndash Focused on constrained Cellular and sensor network M2M devicesndash Driven by leading operators and vendors
bull Scopendash Interfaces protocol amp security between Device and Serverndash Object and Resource modelndash Bootstrap Device Access Control Connectivity and Firmware Objects
bull Draft Specifications are availablendash httpmemberopenmobileallianceorgftpPublic_documentsDM
LightweightM2MPermanent_documentsOMA-TS-LightweightM2M-V1_0_0-20130301-Dzip
bull Timelinendash Requirements and Architecture completed 3Q2012ndash Spec ready for Consistency Review 2Q2013ndash Candidate Approval expected 3Q2013
2 CoRE WG IETF-86 Orlando
Architecture
3
Scope of LWM2M
CoRE WG IETF-86 Orlando
Object Model
bull A Client has one or more Object Instancesbull An Object is a collection of Resourcesbull A Resource is an atomic piece of information
ndash Read Written or Executed
bull Resources can have multiple instancesbull Objects and Resources are identified by a
16-bit Integer Instances by an 8-bit Integerbull ObjectsResources are accessed with
simple URIs Object IDObject InstanceResource ID
eg 1213
4 CoRE WG IETF-86 Orlando
CoRE WG IETF-86 Orlando
CoRE Resource Directory
draft-shelby-core-resource-directory-05
Z Shelby C Bormann S Krco
Backgroundbull Not a new concept
ndash think web search engine or any link directorybull Defines the interfaces to a Resource Directorybull Based on Web Linking framework and the CoRE Link Formatbull Generic REST design for use over HTTP and CoAPbull Used by OMA Lightweight M2Mbull Has already been deployed
ndash In traffic monitoring systemsndash In street lighting systemsndash For vehicular asset trackingndash By a major Cellular M2M operator
Changes since -04
bull Restricted Update to parameter updatesbull Added pagination support for the Lookup interfacebull Changed rt= to et= for the registration amp update
interfacebull Added group support
Group Management
bull RD now includes group management featuresbull New Group Function Set
ndash Register a groupbull Group name domain multicast address endpoint members
ndash Remove a groupbull Group lookup using the Lookup Function Set
ndash List registered groupsndash Find the members of a groupndash Find groups with certain endpoints or resources
Registering a Group
EP RD
| |
| - POST rd-groupgp=lights ltgtep=node1 --gt |
| |
| |
| lt---- 201 Created Location rd-group12 ---- |
| |
Req POST coaprdexamplecomrd-groupgp=lights
Payload
ltgtep=node1
ltgtep=node2
Res 201 Created
Location rd-group12
Looking up Group Members
Client RD
| |
| ----- GET rd-lookupepgp=lights1 ----------------------gt |
| |
| |
| lt-- 205 Content ltrdgtd=domain1ltrdgtd=domain2 --------- |
| |
Req GET rd-lookupepgp=lights1
Res 205 Content
ltcoaphostportgtep=node1
ltcoaphostportgtep=node2rdquo
Things for the futurebull Support for JSON representation of Web Links
ndash httptoolsietforgiddraft-bormann-core-links-json-02txtbull Registry for RD registration query parameters
ndash Already OMA Lightweight has defined some new onesbull More examples
Group 3 ldquonew workrdquo(continued)
109
drar-shy‐greevenbosch-shy‐core-shy‐profile-shy‐descripon-shy‐01Bert13 GreevenboschJeroen13 Hoebeke
Isam13 IshaqFloris13 Van13 den13 Abeele
Descripon
bull JSON13 format13 for13 signalling13 the13 servers13 capabilies
bull Signalling13 of13 supported13 opons13 media13 types13 and13 block13 sizendash Other13 items13 can13 be13 added
bull Filtering13 on13 specific13 fields13 through13 URI-shy‐Querybull Link13 hqpdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐profile-shy‐descripon
well-shy‐knownprofile
bull To13 acquire13 profile13 data13 of13 resources13 on13 a13 parcular13 service13 the13 well-shy‐knownprofile13 URI-shy‐path13 is13 introduced
bull For13 example13 to13 get13 all13 informaon13 from13 sensors13 served13 by13 wwwexampleorg13 we13 can13 do13 a13 GET13 to13 coapwwwexampleorgwell-shy‐knownprofile
bull Filtering13 on13 parcular13 resources13 is13 done13 through13 URI-shy‐Queries
Format
bull Currently13 the13 following13 fields13 are13 definedndash ldquopathrdquo13 contains13 the13 URI-shy‐path13 associated13 with13 a13 resource
ndash ldquooprdquo13 a13 numerical13 list13 of13 supported13 opon13 numbers
ndash ldquocfrdquo13 a13 numerical13 list13 of13 supported13 content-shy‐format13 numbers
ndash ldquob1srdquo13 ldquob2srdquo13 supported13 block13 sizes13 for13 Block113 and13 Block213 respecvely
Examplebull On13 the13 right13 is13 an13 example13 of13 a13 camera13 sensor13 at13 coapwwwexampleorgcam13 that13 supports13 the13 Uri-shy‐Host13 (3)13 ETag13 (4)13 Uri-shy‐Port13 (7)13 Uri-shy‐Path13 (11)13 Content-shy‐Format13 (12)13 Token13 (19)13 Block213 (23)13 and13 Proxy-shy‐Uri13 (35)13 opons
bull The13 supported13 content13 formats13 are13 textplain13 (0)13 applicaon13 link-shy‐format13 (40)13 and13 applicaonjson13 (50)
bull The13 supported13 Block213 can13 use13 25613 or13 51213 byte13 blocks
Req13 GET13 coapwwwexampleorgwell-shy‐knownprofile13 Res13 20513 Content13 (applicationjson)13 13 13 13 profile13 13 13 13 13 13 13 13 pathcam13 13 13 13 op[3471112192335]13 13 13 13 13 cf[04050]13 13 13 13 13 b2s[45]13 13 13 13
Filtering13 through13 use13 of13 URI-shy‐Query
bull Filtering13 can13 be13 done13 through13 the13 URI-shy‐Querybull Query13 format13 N=V
ndash N13 is13 a13 profile13 fieldndash V13 is13 the13 desired13 value
bull Examplesndash To13 find13 resources13 that13 support13 content13 format13 ldquoapplicaonjsonrdquo
13 GET13 wwwexampleorgwell-shy‐knownprofilecf=50ndash To13 get13 informaon13 about13 the13 camera
13 GET13 wwwexampleorgwell-shy‐knownprofilepath=cam
Open13 issues
bull Which13 other13 profile13 data13 needs13 signallingndash Content-shy‐type13 for13 different13 methods
bull Fix13 the13 order13 in13 which13 the13 profile13 fields13 must13 appearndash Non-shy‐fixed13 order13 easier13 extensible
bull Inheritance13 of13 a13 profile13 descriponbull Extend13 usage13 to13 signal13 the13 client13 profilebull Integraon13 with13 link13 format
Thank13 youQuesons
drar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval-shy‐00
Bert13 Greevenbosch
Descripon
bull The13 ldquoMinimumRequestInterval13 opon13 can13 be13 used13 to13 indicate13 the13 minimum13 me13 between13 two13 requests13 in13 a13 transacon
bull Originally13 intended13 for13 Block13 but13 also13 usable13 for13 other13 transaconsndash Example13 browsing13 a13 server
bull The13 goal13 is13 to13 reduce13 the13 server13 load13 and13 network13 traffic
bull Link13 hqpsdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval
Usage
bull The13 client13 keeps13 the13 server13 informed13 about13 its13 request13 speed13 through13 inclusion13 of13 the13 ldquoMinimumRequestIntervalrdquo13 opon
bull In13 responses13 the13 server13 fixes13 the13 minimum13 request13 interval13 through13 the13 same13 opon
bull The13 client13 obeys13 the13 speed13 indicated13 by13 the13 server
bull The13 client13 can13 send13 slower13 but13 not13 faster
Advantages
bull The13 server13 has13 means13 to13 limit13 the13 amount13 of13 incoming13 traffic
bull The13 server13 can13 prevent13 to13 become13 overloaded13 with13 too13 many13 tasks
bull The13 server13 does13 not13 need13 arficially13 slow13 down13 the13 client13 by13 sending13 late13 ACKsndash No13 need13 to13 keep13 track13 of13 delayed13 ACKsndash The13 server13 can13 perform13 other13 tasks13 instead
bull Reduced13 network13 traffic
Thank13 youQuesons
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-links-json-02txt
123
RFC 6690 (link-format) documents are somewhat foreign to many web app developerssect would prefer to have them in JSON format
There is no standard way to represent link-format documents in applicationssect but everyone knows how to handle JSON
Define a standard JSON translation for link-format
Itrsquos
not
rock
et
scien
ce
ltsensorsgtct=40title=Sensor Index ltsensorstempgtrt=temperature-cif=sensor ltsensorslightgtrt=light-luxif=sensor lthttpwwwexamplecomsensorst123gt anchor=sensorstemprel=describedby lttgtanchor=sensorstemprel=alternate [hrefsensorsct40titleSensor Index hrefsensorstemprttemperature-cifsensor hrefsensorslightrtlight-luxifsensor hrefhttpwwwexamplecomsensorst123 anchorsensorstempreldescribedby hreftanchorsensorstemprelalternate]
124
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-ipsec-for-coap-00txt
IPsec definitions for CoAP Mostly placeholder at this time Who has implementation experience with this
125
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-cross-reverse-convention-00txt
This draft has two lines of payload(based on a WGLC comment by Cullen Jennings)
coap12344567foobara=3
httpwwwproxycomwellknowncore-translate1234_4567foobara=3
Is that a useful convention to have
126
Insert CI slides here
127
128
0
5
10
15
20
25
30
35
40
10 20 30 40 50 60 70
good
put (
pps)
pps
Goodput vs pps (Econotags)
goodput
[Khattak preliminary]
Congestion Control
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-cocoa-00txt
ldquoadvancedrdquo cc (The draft is just a first shot) Others may have better ideas
129
Insert post-WGLC discussion slides here
130
Stop Continue Start
131
An Agile Retrospective
http6lowappnet coreIETF86 2013-03-12-13
Stop
132
Endless new CoAP optionssect instead use RESTful as much as possible
Move general security lifecycle out Looking at theoretical problems
http6lowappnet coreIETF86 2013-03-12-13
Continue
Interops Running code Look at real-world examples and deployments Solve their actual problems
sect Unilateral enhancements eg higher performance congestion control
sect Transports (SMS hellip)sect Make Web linking and Directories more and more usefulsect RESTful Design Paradigms for real-world problems
133
http6lowappnet coreIETF86 2013-03-12-13
Start
Further push into the (browser) web world (HTML5 browser security)
Specific supporting worksect SenMLsect URI work (dev URN hellip)sect Security Processes (next slide)
Spin outsect (We donrsquot really get to decide where this is done)
134
http6lowappnet coreIETF86 2013-03-12-13
Security
Integrate Application Network Group Keyingsect Tunnel-free setup
Donrsquot redo what has been done alreadysect ZigBee IP is finesect But what about other scenarios
Simple REST interfaces for working with keying materials and authorizationsect Start with defining objectives
Object Security for Constrained Nodes135
Re-chartering CoREWhat do we want to do now that wersquore grown up
Zach ShelbyCoRE WG IETF-86 Orlando
What is the scope
bull So we have a protocol and Web Linking what next
bull Keep with what we know besthellip1 Enhancements around CoAP2 New transports for CoAP3 New representations for Web Links4 General application layer solutions
CoRE WG IETF-86 Orlando 2
Enhancements around CoAP
bull Advanced congestion control
CoRE WG IETF-86 Orlando 3
New Transports for CoAP
bull Infrastructure for CoAP over foondash httptoolsietforgiddraft-silverajan-core-
coap-alternative-transports-01txtbull CoAP over SMS
ndash httptoolsietforgiddraft-becker-core-coap-sms-gprs-03txt
ndash OMA Lightweightbull CoAP over TCP
ndash httptoolsietforgiddraft-li-core-coap-payload-length-option-01txt
CoRE WG IETF-86 Orlando 4
New support for Web Links
bull JSON Web Linksndash httptoolsietforgiddraft-bormann-core-links-
json-02txt
2332010 CoRE WG IETF-77 Anaheim 5
General application layer solutions
bull Resource Directoryndash httptoolsietforgiddraft-shelby-core-
resource-directory-05txtndash OMA Lightweight
2332010 CoRE WG IETF-77 Anaheim 6
Conclusions These results show that sleep-aware CoAP
proxy features can significantly optimize communication with sleepy servers in most scenarios
These results also show that sleep-
awareness capabilities can provide additional benefits above and beyond CoAP caching in most scenarios
Backup
Current CoAP Support of Sleepy Node (12)
CoAP proxies can use a previously cached response to service a new GET request for a sleepy origin server (as in HTTP) But if no valid cache then proxy has to attempt to
retrieve and may fail if origin server is sleeping [I-Dietf-core-coap]
Clients can discover list of resources from RD (GET rd-lookuphellip) for sleepy servers But attempt to GET resource from sleepy origin server
may fail if origin server is sleeping [IDietf-core-link-format amp IDshelby-core-resource-
directory]
Current CoAP Support of Sleepy Node (22)
Lower layer support for sleepy nodes in most wireless technologies (eg WiFi ZigBee) But limited to MAC packet scheduling for sleepy nodes
and not aware of specific needs of IP applications (like CoAP)
Proposal ndash RD Based Sleep Tracking (14)
The current CoAP approach to support sleepy nodes can be significantly improved by introducing RD based mechanisms for a CoAP client to determine whether A targeted resource is located on a sleepy server A sleepy server is currently in sleep mode or not
There is any associated caching Proxy (possibly the RD itself) for a sleepy server
Proposal ndash RD Based Sleep Tracking (24)
We define the following new RD attributes to characterize the properties of a sleepy node SleepState - Indicates whether the node is currently in
sleep mode or not (ie Sleeping or Awake) SleepDuration - Indicates the maximum duration of time
that the node stays in sleep mode TimeSleeping - Indicates the length of time the node
has been sleeping (ie if Sleep State = Sleeping) NextSleep - Indicates the next time the node will go to
sleep (ie if Sleep State = Awake)
CachingProxy ndash Indicates the caching proxy of the sleepy node (ie the RD itself or another node)
Proposal ndash RD Based Sleep Tracking (34)
These attributes are all server (node) level and are new parameters added to the RD URI Template Variables
Finally we also define a new lookup-type (ss) for the RD lookup interface specified in [I-Dshelby-core-resource-directory] This new lookup-type supports looking up the
ldquoSleepStaterdquo (ss) of a specified end-point
Proposal ndash RD Based Sleep Tracking (44)
The three time based parameters (SleepDuration TimeSleeping NextSleep) can be based on either an absolute network time (for a time synchronized network) or a relative local time (measured at the local node)
Following the approach of [I-Dietf-core-link-format] and [I-Dshelby-core-resource-directory] sleep parameters for sleepy servers can be stored by the server in the RD and accessed by all interested clients
Examples of using these parameters in a synchronous or asynchronous manner are shown in the I-D
http6lowappnet coreIETF86 2013-03-12-13
We assume people have read the drafts
Meetings serve to advance difficult issues by making good use of face-to-face communications
Note Well Be aware of the IPR principles according to RFC 3979 and its updates
uumlBlue sheetsuumlScribe(s)
96
drar-shy‐iep-shy‐core-shy‐coapsubmiqed13 to13 IESG
2013-shy‐03-shy‐13
97
OMA Lightweight M2M Overview(A new standard using lots of IETF specs including DTLS
CoAP Block Observe Resource Directory SenMLhellip)
Zach ShelbyCoRE WG IETF-86 Orlando
OMA Lightweight M2Mbull Open Mobile Alliance is well known for Device Management (DM)bull OMA Lightweight M2M is a new standard from the alliance
ndash Focused on constrained Cellular and sensor network M2M devicesndash Driven by leading operators and vendors
bull Scopendash Interfaces protocol amp security between Device and Serverndash Object and Resource modelndash Bootstrap Device Access Control Connectivity and Firmware Objects
bull Draft Specifications are availablendash httpmemberopenmobileallianceorgftpPublic_documentsDM
LightweightM2MPermanent_documentsOMA-TS-LightweightM2M-V1_0_0-20130301-Dzip
bull Timelinendash Requirements and Architecture completed 3Q2012ndash Spec ready for Consistency Review 2Q2013ndash Candidate Approval expected 3Q2013
2 CoRE WG IETF-86 Orlando
Architecture
3
Scope of LWM2M
CoRE WG IETF-86 Orlando
Object Model
bull A Client has one or more Object Instancesbull An Object is a collection of Resourcesbull A Resource is an atomic piece of information
ndash Read Written or Executed
bull Resources can have multiple instancesbull Objects and Resources are identified by a
16-bit Integer Instances by an 8-bit Integerbull ObjectsResources are accessed with
simple URIs Object IDObject InstanceResource ID
eg 1213
4 CoRE WG IETF-86 Orlando
CoRE WG IETF-86 Orlando
CoRE Resource Directory
draft-shelby-core-resource-directory-05
Z Shelby C Bormann S Krco
Backgroundbull Not a new concept
ndash think web search engine or any link directorybull Defines the interfaces to a Resource Directorybull Based on Web Linking framework and the CoRE Link Formatbull Generic REST design for use over HTTP and CoAPbull Used by OMA Lightweight M2Mbull Has already been deployed
ndash In traffic monitoring systemsndash In street lighting systemsndash For vehicular asset trackingndash By a major Cellular M2M operator
Changes since -04
bull Restricted Update to parameter updatesbull Added pagination support for the Lookup interfacebull Changed rt= to et= for the registration amp update
interfacebull Added group support
Group Management
bull RD now includes group management featuresbull New Group Function Set
ndash Register a groupbull Group name domain multicast address endpoint members
ndash Remove a groupbull Group lookup using the Lookup Function Set
ndash List registered groupsndash Find the members of a groupndash Find groups with certain endpoints or resources
Registering a Group
EP RD
| |
| - POST rd-groupgp=lights ltgtep=node1 --gt |
| |
| |
| lt---- 201 Created Location rd-group12 ---- |
| |
Req POST coaprdexamplecomrd-groupgp=lights
Payload
ltgtep=node1
ltgtep=node2
Res 201 Created
Location rd-group12
Looking up Group Members
Client RD
| |
| ----- GET rd-lookupepgp=lights1 ----------------------gt |
| |
| |
| lt-- 205 Content ltrdgtd=domain1ltrdgtd=domain2 --------- |
| |
Req GET rd-lookupepgp=lights1
Res 205 Content
ltcoaphostportgtep=node1
ltcoaphostportgtep=node2rdquo
Things for the futurebull Support for JSON representation of Web Links
ndash httptoolsietforgiddraft-bormann-core-links-json-02txtbull Registry for RD registration query parameters
ndash Already OMA Lightweight has defined some new onesbull More examples
Group 3 ldquonew workrdquo(continued)
109
drar-shy‐greevenbosch-shy‐core-shy‐profile-shy‐descripon-shy‐01Bert13 GreevenboschJeroen13 Hoebeke
Isam13 IshaqFloris13 Van13 den13 Abeele
Descripon
bull JSON13 format13 for13 signalling13 the13 servers13 capabilies
bull Signalling13 of13 supported13 opons13 media13 types13 and13 block13 sizendash Other13 items13 can13 be13 added
bull Filtering13 on13 specific13 fields13 through13 URI-shy‐Querybull Link13 hqpdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐profile-shy‐descripon
well-shy‐knownprofile
bull To13 acquire13 profile13 data13 of13 resources13 on13 a13 parcular13 service13 the13 well-shy‐knownprofile13 URI-shy‐path13 is13 introduced
bull For13 example13 to13 get13 all13 informaon13 from13 sensors13 served13 by13 wwwexampleorg13 we13 can13 do13 a13 GET13 to13 coapwwwexampleorgwell-shy‐knownprofile
bull Filtering13 on13 parcular13 resources13 is13 done13 through13 URI-shy‐Queries
Format
bull Currently13 the13 following13 fields13 are13 definedndash ldquopathrdquo13 contains13 the13 URI-shy‐path13 associated13 with13 a13 resource
ndash ldquooprdquo13 a13 numerical13 list13 of13 supported13 opon13 numbers
ndash ldquocfrdquo13 a13 numerical13 list13 of13 supported13 content-shy‐format13 numbers
ndash ldquob1srdquo13 ldquob2srdquo13 supported13 block13 sizes13 for13 Block113 and13 Block213 respecvely
Examplebull On13 the13 right13 is13 an13 example13 of13 a13 camera13 sensor13 at13 coapwwwexampleorgcam13 that13 supports13 the13 Uri-shy‐Host13 (3)13 ETag13 (4)13 Uri-shy‐Port13 (7)13 Uri-shy‐Path13 (11)13 Content-shy‐Format13 (12)13 Token13 (19)13 Block213 (23)13 and13 Proxy-shy‐Uri13 (35)13 opons
bull The13 supported13 content13 formats13 are13 textplain13 (0)13 applicaon13 link-shy‐format13 (40)13 and13 applicaonjson13 (50)
bull The13 supported13 Block213 can13 use13 25613 or13 51213 byte13 blocks
Req13 GET13 coapwwwexampleorgwell-shy‐knownprofile13 Res13 20513 Content13 (applicationjson)13 13 13 13 profile13 13 13 13 13 13 13 13 pathcam13 13 13 13 op[3471112192335]13 13 13 13 13 cf[04050]13 13 13 13 13 b2s[45]13 13 13 13
Filtering13 through13 use13 of13 URI-shy‐Query
bull Filtering13 can13 be13 done13 through13 the13 URI-shy‐Querybull Query13 format13 N=V
ndash N13 is13 a13 profile13 fieldndash V13 is13 the13 desired13 value
bull Examplesndash To13 find13 resources13 that13 support13 content13 format13 ldquoapplicaonjsonrdquo
13 GET13 wwwexampleorgwell-shy‐knownprofilecf=50ndash To13 get13 informaon13 about13 the13 camera
13 GET13 wwwexampleorgwell-shy‐knownprofilepath=cam
Open13 issues
bull Which13 other13 profile13 data13 needs13 signallingndash Content-shy‐type13 for13 different13 methods
bull Fix13 the13 order13 in13 which13 the13 profile13 fields13 must13 appearndash Non-shy‐fixed13 order13 easier13 extensible
bull Inheritance13 of13 a13 profile13 descriponbull Extend13 usage13 to13 signal13 the13 client13 profilebull Integraon13 with13 link13 format
Thank13 youQuesons
drar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval-shy‐00
Bert13 Greevenbosch
Descripon
bull The13 ldquoMinimumRequestInterval13 opon13 can13 be13 used13 to13 indicate13 the13 minimum13 me13 between13 two13 requests13 in13 a13 transacon
bull Originally13 intended13 for13 Block13 but13 also13 usable13 for13 other13 transaconsndash Example13 browsing13 a13 server
bull The13 goal13 is13 to13 reduce13 the13 server13 load13 and13 network13 traffic
bull Link13 hqpsdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval
Usage
bull The13 client13 keeps13 the13 server13 informed13 about13 its13 request13 speed13 through13 inclusion13 of13 the13 ldquoMinimumRequestIntervalrdquo13 opon
bull In13 responses13 the13 server13 fixes13 the13 minimum13 request13 interval13 through13 the13 same13 opon
bull The13 client13 obeys13 the13 speed13 indicated13 by13 the13 server
bull The13 client13 can13 send13 slower13 but13 not13 faster
Advantages
bull The13 server13 has13 means13 to13 limit13 the13 amount13 of13 incoming13 traffic
bull The13 server13 can13 prevent13 to13 become13 overloaded13 with13 too13 many13 tasks
bull The13 server13 does13 not13 need13 arficially13 slow13 down13 the13 client13 by13 sending13 late13 ACKsndash No13 need13 to13 keep13 track13 of13 delayed13 ACKsndash The13 server13 can13 perform13 other13 tasks13 instead
bull Reduced13 network13 traffic
Thank13 youQuesons
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-links-json-02txt
123
RFC 6690 (link-format) documents are somewhat foreign to many web app developerssect would prefer to have them in JSON format
There is no standard way to represent link-format documents in applicationssect but everyone knows how to handle JSON
Define a standard JSON translation for link-format
Itrsquos
not
rock
et
scien
ce
ltsensorsgtct=40title=Sensor Index ltsensorstempgtrt=temperature-cif=sensor ltsensorslightgtrt=light-luxif=sensor lthttpwwwexamplecomsensorst123gt anchor=sensorstemprel=describedby lttgtanchor=sensorstemprel=alternate [hrefsensorsct40titleSensor Index hrefsensorstemprttemperature-cifsensor hrefsensorslightrtlight-luxifsensor hrefhttpwwwexamplecomsensorst123 anchorsensorstempreldescribedby hreftanchorsensorstemprelalternate]
124
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-ipsec-for-coap-00txt
IPsec definitions for CoAP Mostly placeholder at this time Who has implementation experience with this
125
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-cross-reverse-convention-00txt
This draft has two lines of payload(based on a WGLC comment by Cullen Jennings)
coap12344567foobara=3
httpwwwproxycomwellknowncore-translate1234_4567foobara=3
Is that a useful convention to have
126
Insert CI slides here
127
128
0
5
10
15
20
25
30
35
40
10 20 30 40 50 60 70
good
put (
pps)
pps
Goodput vs pps (Econotags)
goodput
[Khattak preliminary]
Congestion Control
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-cocoa-00txt
ldquoadvancedrdquo cc (The draft is just a first shot) Others may have better ideas
129
Insert post-WGLC discussion slides here
130
Stop Continue Start
131
An Agile Retrospective
http6lowappnet coreIETF86 2013-03-12-13
Stop
132
Endless new CoAP optionssect instead use RESTful as much as possible
Move general security lifecycle out Looking at theoretical problems
http6lowappnet coreIETF86 2013-03-12-13
Continue
Interops Running code Look at real-world examples and deployments Solve their actual problems
sect Unilateral enhancements eg higher performance congestion control
sect Transports (SMS hellip)sect Make Web linking and Directories more and more usefulsect RESTful Design Paradigms for real-world problems
133
http6lowappnet coreIETF86 2013-03-12-13
Start
Further push into the (browser) web world (HTML5 browser security)
Specific supporting worksect SenMLsect URI work (dev URN hellip)sect Security Processes (next slide)
Spin outsect (We donrsquot really get to decide where this is done)
134
http6lowappnet coreIETF86 2013-03-12-13
Security
Integrate Application Network Group Keyingsect Tunnel-free setup
Donrsquot redo what has been done alreadysect ZigBee IP is finesect But what about other scenarios
Simple REST interfaces for working with keying materials and authorizationsect Start with defining objectives
Object Security for Constrained Nodes135
Re-chartering CoREWhat do we want to do now that wersquore grown up
Zach ShelbyCoRE WG IETF-86 Orlando
What is the scope
bull So we have a protocol and Web Linking what next
bull Keep with what we know besthellip1 Enhancements around CoAP2 New transports for CoAP3 New representations for Web Links4 General application layer solutions
CoRE WG IETF-86 Orlando 2
Enhancements around CoAP
bull Advanced congestion control
CoRE WG IETF-86 Orlando 3
New Transports for CoAP
bull Infrastructure for CoAP over foondash httptoolsietforgiddraft-silverajan-core-
coap-alternative-transports-01txtbull CoAP over SMS
ndash httptoolsietforgiddraft-becker-core-coap-sms-gprs-03txt
ndash OMA Lightweightbull CoAP over TCP
ndash httptoolsietforgiddraft-li-core-coap-payload-length-option-01txt
CoRE WG IETF-86 Orlando 4
New support for Web Links
bull JSON Web Linksndash httptoolsietforgiddraft-bormann-core-links-
json-02txt
2332010 CoRE WG IETF-77 Anaheim 5
General application layer solutions
bull Resource Directoryndash httptoolsietforgiddraft-shelby-core-
resource-directory-05txtndash OMA Lightweight
2332010 CoRE WG IETF-77 Anaheim 6
Backup
Current CoAP Support of Sleepy Node (12)
CoAP proxies can use a previously cached response to service a new GET request for a sleepy origin server (as in HTTP) But if no valid cache then proxy has to attempt to
retrieve and may fail if origin server is sleeping [I-Dietf-core-coap]
Clients can discover list of resources from RD (GET rd-lookuphellip) for sleepy servers But attempt to GET resource from sleepy origin server
may fail if origin server is sleeping [IDietf-core-link-format amp IDshelby-core-resource-
directory]
Current CoAP Support of Sleepy Node (22)
Lower layer support for sleepy nodes in most wireless technologies (eg WiFi ZigBee) But limited to MAC packet scheduling for sleepy nodes
and not aware of specific needs of IP applications (like CoAP)
Proposal ndash RD Based Sleep Tracking (14)
The current CoAP approach to support sleepy nodes can be significantly improved by introducing RD based mechanisms for a CoAP client to determine whether A targeted resource is located on a sleepy server A sleepy server is currently in sleep mode or not
There is any associated caching Proxy (possibly the RD itself) for a sleepy server
Proposal ndash RD Based Sleep Tracking (24)
We define the following new RD attributes to characterize the properties of a sleepy node SleepState - Indicates whether the node is currently in
sleep mode or not (ie Sleeping or Awake) SleepDuration - Indicates the maximum duration of time
that the node stays in sleep mode TimeSleeping - Indicates the length of time the node
has been sleeping (ie if Sleep State = Sleeping) NextSleep - Indicates the next time the node will go to
sleep (ie if Sleep State = Awake)
CachingProxy ndash Indicates the caching proxy of the sleepy node (ie the RD itself or another node)
Proposal ndash RD Based Sleep Tracking (34)
These attributes are all server (node) level and are new parameters added to the RD URI Template Variables
Finally we also define a new lookup-type (ss) for the RD lookup interface specified in [I-Dshelby-core-resource-directory] This new lookup-type supports looking up the
ldquoSleepStaterdquo (ss) of a specified end-point
Proposal ndash RD Based Sleep Tracking (44)
The three time based parameters (SleepDuration TimeSleeping NextSleep) can be based on either an absolute network time (for a time synchronized network) or a relative local time (measured at the local node)
Following the approach of [I-Dietf-core-link-format] and [I-Dshelby-core-resource-directory] sleep parameters for sleepy servers can be stored by the server in the RD and accessed by all interested clients
Examples of using these parameters in a synchronous or asynchronous manner are shown in the I-D
http6lowappnet coreIETF86 2013-03-12-13
We assume people have read the drafts
Meetings serve to advance difficult issues by making good use of face-to-face communications
Note Well Be aware of the IPR principles according to RFC 3979 and its updates
uumlBlue sheetsuumlScribe(s)
96
drar-shy‐iep-shy‐core-shy‐coapsubmiqed13 to13 IESG
2013-shy‐03-shy‐13
97
OMA Lightweight M2M Overview(A new standard using lots of IETF specs including DTLS
CoAP Block Observe Resource Directory SenMLhellip)
Zach ShelbyCoRE WG IETF-86 Orlando
OMA Lightweight M2Mbull Open Mobile Alliance is well known for Device Management (DM)bull OMA Lightweight M2M is a new standard from the alliance
ndash Focused on constrained Cellular and sensor network M2M devicesndash Driven by leading operators and vendors
bull Scopendash Interfaces protocol amp security between Device and Serverndash Object and Resource modelndash Bootstrap Device Access Control Connectivity and Firmware Objects
bull Draft Specifications are availablendash httpmemberopenmobileallianceorgftpPublic_documentsDM
LightweightM2MPermanent_documentsOMA-TS-LightweightM2M-V1_0_0-20130301-Dzip
bull Timelinendash Requirements and Architecture completed 3Q2012ndash Spec ready for Consistency Review 2Q2013ndash Candidate Approval expected 3Q2013
2 CoRE WG IETF-86 Orlando
Architecture
3
Scope of LWM2M
CoRE WG IETF-86 Orlando
Object Model
bull A Client has one or more Object Instancesbull An Object is a collection of Resourcesbull A Resource is an atomic piece of information
ndash Read Written or Executed
bull Resources can have multiple instancesbull Objects and Resources are identified by a
16-bit Integer Instances by an 8-bit Integerbull ObjectsResources are accessed with
simple URIs Object IDObject InstanceResource ID
eg 1213
4 CoRE WG IETF-86 Orlando
CoRE WG IETF-86 Orlando
CoRE Resource Directory
draft-shelby-core-resource-directory-05
Z Shelby C Bormann S Krco
Backgroundbull Not a new concept
ndash think web search engine or any link directorybull Defines the interfaces to a Resource Directorybull Based on Web Linking framework and the CoRE Link Formatbull Generic REST design for use over HTTP and CoAPbull Used by OMA Lightweight M2Mbull Has already been deployed
ndash In traffic monitoring systemsndash In street lighting systemsndash For vehicular asset trackingndash By a major Cellular M2M operator
Changes since -04
bull Restricted Update to parameter updatesbull Added pagination support for the Lookup interfacebull Changed rt= to et= for the registration amp update
interfacebull Added group support
Group Management
bull RD now includes group management featuresbull New Group Function Set
ndash Register a groupbull Group name domain multicast address endpoint members
ndash Remove a groupbull Group lookup using the Lookup Function Set
ndash List registered groupsndash Find the members of a groupndash Find groups with certain endpoints or resources
Registering a Group
EP RD
| |
| - POST rd-groupgp=lights ltgtep=node1 --gt |
| |
| |
| lt---- 201 Created Location rd-group12 ---- |
| |
Req POST coaprdexamplecomrd-groupgp=lights
Payload
ltgtep=node1
ltgtep=node2
Res 201 Created
Location rd-group12
Looking up Group Members
Client RD
| |
| ----- GET rd-lookupepgp=lights1 ----------------------gt |
| |
| |
| lt-- 205 Content ltrdgtd=domain1ltrdgtd=domain2 --------- |
| |
Req GET rd-lookupepgp=lights1
Res 205 Content
ltcoaphostportgtep=node1
ltcoaphostportgtep=node2rdquo
Things for the futurebull Support for JSON representation of Web Links
ndash httptoolsietforgiddraft-bormann-core-links-json-02txtbull Registry for RD registration query parameters
ndash Already OMA Lightweight has defined some new onesbull More examples
Group 3 ldquonew workrdquo(continued)
109
drar-shy‐greevenbosch-shy‐core-shy‐profile-shy‐descripon-shy‐01Bert13 GreevenboschJeroen13 Hoebeke
Isam13 IshaqFloris13 Van13 den13 Abeele
Descripon
bull JSON13 format13 for13 signalling13 the13 servers13 capabilies
bull Signalling13 of13 supported13 opons13 media13 types13 and13 block13 sizendash Other13 items13 can13 be13 added
bull Filtering13 on13 specific13 fields13 through13 URI-shy‐Querybull Link13 hqpdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐profile-shy‐descripon
well-shy‐knownprofile
bull To13 acquire13 profile13 data13 of13 resources13 on13 a13 parcular13 service13 the13 well-shy‐knownprofile13 URI-shy‐path13 is13 introduced
bull For13 example13 to13 get13 all13 informaon13 from13 sensors13 served13 by13 wwwexampleorg13 we13 can13 do13 a13 GET13 to13 coapwwwexampleorgwell-shy‐knownprofile
bull Filtering13 on13 parcular13 resources13 is13 done13 through13 URI-shy‐Queries
Format
bull Currently13 the13 following13 fields13 are13 definedndash ldquopathrdquo13 contains13 the13 URI-shy‐path13 associated13 with13 a13 resource
ndash ldquooprdquo13 a13 numerical13 list13 of13 supported13 opon13 numbers
ndash ldquocfrdquo13 a13 numerical13 list13 of13 supported13 content-shy‐format13 numbers
ndash ldquob1srdquo13 ldquob2srdquo13 supported13 block13 sizes13 for13 Block113 and13 Block213 respecvely
Examplebull On13 the13 right13 is13 an13 example13 of13 a13 camera13 sensor13 at13 coapwwwexampleorgcam13 that13 supports13 the13 Uri-shy‐Host13 (3)13 ETag13 (4)13 Uri-shy‐Port13 (7)13 Uri-shy‐Path13 (11)13 Content-shy‐Format13 (12)13 Token13 (19)13 Block213 (23)13 and13 Proxy-shy‐Uri13 (35)13 opons
bull The13 supported13 content13 formats13 are13 textplain13 (0)13 applicaon13 link-shy‐format13 (40)13 and13 applicaonjson13 (50)
bull The13 supported13 Block213 can13 use13 25613 or13 51213 byte13 blocks
Req13 GET13 coapwwwexampleorgwell-shy‐knownprofile13 Res13 20513 Content13 (applicationjson)13 13 13 13 profile13 13 13 13 13 13 13 13 pathcam13 13 13 13 op[3471112192335]13 13 13 13 13 cf[04050]13 13 13 13 13 b2s[45]13 13 13 13
Filtering13 through13 use13 of13 URI-shy‐Query
bull Filtering13 can13 be13 done13 through13 the13 URI-shy‐Querybull Query13 format13 N=V
ndash N13 is13 a13 profile13 fieldndash V13 is13 the13 desired13 value
bull Examplesndash To13 find13 resources13 that13 support13 content13 format13 ldquoapplicaonjsonrdquo
13 GET13 wwwexampleorgwell-shy‐knownprofilecf=50ndash To13 get13 informaon13 about13 the13 camera
13 GET13 wwwexampleorgwell-shy‐knownprofilepath=cam
Open13 issues
bull Which13 other13 profile13 data13 needs13 signallingndash Content-shy‐type13 for13 different13 methods
bull Fix13 the13 order13 in13 which13 the13 profile13 fields13 must13 appearndash Non-shy‐fixed13 order13 easier13 extensible
bull Inheritance13 of13 a13 profile13 descriponbull Extend13 usage13 to13 signal13 the13 client13 profilebull Integraon13 with13 link13 format
Thank13 youQuesons
drar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval-shy‐00
Bert13 Greevenbosch
Descripon
bull The13 ldquoMinimumRequestInterval13 opon13 can13 be13 used13 to13 indicate13 the13 minimum13 me13 between13 two13 requests13 in13 a13 transacon
bull Originally13 intended13 for13 Block13 but13 also13 usable13 for13 other13 transaconsndash Example13 browsing13 a13 server
bull The13 goal13 is13 to13 reduce13 the13 server13 load13 and13 network13 traffic
bull Link13 hqpsdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval
Usage
bull The13 client13 keeps13 the13 server13 informed13 about13 its13 request13 speed13 through13 inclusion13 of13 the13 ldquoMinimumRequestIntervalrdquo13 opon
bull In13 responses13 the13 server13 fixes13 the13 minimum13 request13 interval13 through13 the13 same13 opon
bull The13 client13 obeys13 the13 speed13 indicated13 by13 the13 server
bull The13 client13 can13 send13 slower13 but13 not13 faster
Advantages
bull The13 server13 has13 means13 to13 limit13 the13 amount13 of13 incoming13 traffic
bull The13 server13 can13 prevent13 to13 become13 overloaded13 with13 too13 many13 tasks
bull The13 server13 does13 not13 need13 arficially13 slow13 down13 the13 client13 by13 sending13 late13 ACKsndash No13 need13 to13 keep13 track13 of13 delayed13 ACKsndash The13 server13 can13 perform13 other13 tasks13 instead
bull Reduced13 network13 traffic
Thank13 youQuesons
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-links-json-02txt
123
RFC 6690 (link-format) documents are somewhat foreign to many web app developerssect would prefer to have them in JSON format
There is no standard way to represent link-format documents in applicationssect but everyone knows how to handle JSON
Define a standard JSON translation for link-format
Itrsquos
not
rock
et
scien
ce
ltsensorsgtct=40title=Sensor Index ltsensorstempgtrt=temperature-cif=sensor ltsensorslightgtrt=light-luxif=sensor lthttpwwwexamplecomsensorst123gt anchor=sensorstemprel=describedby lttgtanchor=sensorstemprel=alternate [hrefsensorsct40titleSensor Index hrefsensorstemprttemperature-cifsensor hrefsensorslightrtlight-luxifsensor hrefhttpwwwexamplecomsensorst123 anchorsensorstempreldescribedby hreftanchorsensorstemprelalternate]
124
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-ipsec-for-coap-00txt
IPsec definitions for CoAP Mostly placeholder at this time Who has implementation experience with this
125
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-cross-reverse-convention-00txt
This draft has two lines of payload(based on a WGLC comment by Cullen Jennings)
coap12344567foobara=3
httpwwwproxycomwellknowncore-translate1234_4567foobara=3
Is that a useful convention to have
126
Insert CI slides here
127
128
0
5
10
15
20
25
30
35
40
10 20 30 40 50 60 70
good
put (
pps)
pps
Goodput vs pps (Econotags)
goodput
[Khattak preliminary]
Congestion Control
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-cocoa-00txt
ldquoadvancedrdquo cc (The draft is just a first shot) Others may have better ideas
129
Insert post-WGLC discussion slides here
130
Stop Continue Start
131
An Agile Retrospective
http6lowappnet coreIETF86 2013-03-12-13
Stop
132
Endless new CoAP optionssect instead use RESTful as much as possible
Move general security lifecycle out Looking at theoretical problems
http6lowappnet coreIETF86 2013-03-12-13
Continue
Interops Running code Look at real-world examples and deployments Solve their actual problems
sect Unilateral enhancements eg higher performance congestion control
sect Transports (SMS hellip)sect Make Web linking and Directories more and more usefulsect RESTful Design Paradigms for real-world problems
133
http6lowappnet coreIETF86 2013-03-12-13
Start
Further push into the (browser) web world (HTML5 browser security)
Specific supporting worksect SenMLsect URI work (dev URN hellip)sect Security Processes (next slide)
Spin outsect (We donrsquot really get to decide where this is done)
134
http6lowappnet coreIETF86 2013-03-12-13
Security
Integrate Application Network Group Keyingsect Tunnel-free setup
Donrsquot redo what has been done alreadysect ZigBee IP is finesect But what about other scenarios
Simple REST interfaces for working with keying materials and authorizationsect Start with defining objectives
Object Security for Constrained Nodes135
Re-chartering CoREWhat do we want to do now that wersquore grown up
Zach ShelbyCoRE WG IETF-86 Orlando
What is the scope
bull So we have a protocol and Web Linking what next
bull Keep with what we know besthellip1 Enhancements around CoAP2 New transports for CoAP3 New representations for Web Links4 General application layer solutions
CoRE WG IETF-86 Orlando 2
Enhancements around CoAP
bull Advanced congestion control
CoRE WG IETF-86 Orlando 3
New Transports for CoAP
bull Infrastructure for CoAP over foondash httptoolsietforgiddraft-silverajan-core-
coap-alternative-transports-01txtbull CoAP over SMS
ndash httptoolsietforgiddraft-becker-core-coap-sms-gprs-03txt
ndash OMA Lightweightbull CoAP over TCP
ndash httptoolsietforgiddraft-li-core-coap-payload-length-option-01txt
CoRE WG IETF-86 Orlando 4
New support for Web Links
bull JSON Web Linksndash httptoolsietforgiddraft-bormann-core-links-
json-02txt
2332010 CoRE WG IETF-77 Anaheim 5
General application layer solutions
bull Resource Directoryndash httptoolsietforgiddraft-shelby-core-
resource-directory-05txtndash OMA Lightweight
2332010 CoRE WG IETF-77 Anaheim 6
Current CoAP Support of Sleepy Node (12)
CoAP proxies can use a previously cached response to service a new GET request for a sleepy origin server (as in HTTP) But if no valid cache then proxy has to attempt to
retrieve and may fail if origin server is sleeping [I-Dietf-core-coap]
Clients can discover list of resources from RD (GET rd-lookuphellip) for sleepy servers But attempt to GET resource from sleepy origin server
may fail if origin server is sleeping [IDietf-core-link-format amp IDshelby-core-resource-
directory]
Current CoAP Support of Sleepy Node (22)
Lower layer support for sleepy nodes in most wireless technologies (eg WiFi ZigBee) But limited to MAC packet scheduling for sleepy nodes
and not aware of specific needs of IP applications (like CoAP)
Proposal ndash RD Based Sleep Tracking (14)
The current CoAP approach to support sleepy nodes can be significantly improved by introducing RD based mechanisms for a CoAP client to determine whether A targeted resource is located on a sleepy server A sleepy server is currently in sleep mode or not
There is any associated caching Proxy (possibly the RD itself) for a sleepy server
Proposal ndash RD Based Sleep Tracking (24)
We define the following new RD attributes to characterize the properties of a sleepy node SleepState - Indicates whether the node is currently in
sleep mode or not (ie Sleeping or Awake) SleepDuration - Indicates the maximum duration of time
that the node stays in sleep mode TimeSleeping - Indicates the length of time the node
has been sleeping (ie if Sleep State = Sleeping) NextSleep - Indicates the next time the node will go to
sleep (ie if Sleep State = Awake)
CachingProxy ndash Indicates the caching proxy of the sleepy node (ie the RD itself or another node)
Proposal ndash RD Based Sleep Tracking (34)
These attributes are all server (node) level and are new parameters added to the RD URI Template Variables
Finally we also define a new lookup-type (ss) for the RD lookup interface specified in [I-Dshelby-core-resource-directory] This new lookup-type supports looking up the
ldquoSleepStaterdquo (ss) of a specified end-point
Proposal ndash RD Based Sleep Tracking (44)
The three time based parameters (SleepDuration TimeSleeping NextSleep) can be based on either an absolute network time (for a time synchronized network) or a relative local time (measured at the local node)
Following the approach of [I-Dietf-core-link-format] and [I-Dshelby-core-resource-directory] sleep parameters for sleepy servers can be stored by the server in the RD and accessed by all interested clients
Examples of using these parameters in a synchronous or asynchronous manner are shown in the I-D
http6lowappnet coreIETF86 2013-03-12-13
We assume people have read the drafts
Meetings serve to advance difficult issues by making good use of face-to-face communications
Note Well Be aware of the IPR principles according to RFC 3979 and its updates
uumlBlue sheetsuumlScribe(s)
96
drar-shy‐iep-shy‐core-shy‐coapsubmiqed13 to13 IESG
2013-shy‐03-shy‐13
97
OMA Lightweight M2M Overview(A new standard using lots of IETF specs including DTLS
CoAP Block Observe Resource Directory SenMLhellip)
Zach ShelbyCoRE WG IETF-86 Orlando
OMA Lightweight M2Mbull Open Mobile Alliance is well known for Device Management (DM)bull OMA Lightweight M2M is a new standard from the alliance
ndash Focused on constrained Cellular and sensor network M2M devicesndash Driven by leading operators and vendors
bull Scopendash Interfaces protocol amp security between Device and Serverndash Object and Resource modelndash Bootstrap Device Access Control Connectivity and Firmware Objects
bull Draft Specifications are availablendash httpmemberopenmobileallianceorgftpPublic_documentsDM
LightweightM2MPermanent_documentsOMA-TS-LightweightM2M-V1_0_0-20130301-Dzip
bull Timelinendash Requirements and Architecture completed 3Q2012ndash Spec ready for Consistency Review 2Q2013ndash Candidate Approval expected 3Q2013
2 CoRE WG IETF-86 Orlando
Architecture
3
Scope of LWM2M
CoRE WG IETF-86 Orlando
Object Model
bull A Client has one or more Object Instancesbull An Object is a collection of Resourcesbull A Resource is an atomic piece of information
ndash Read Written or Executed
bull Resources can have multiple instancesbull Objects and Resources are identified by a
16-bit Integer Instances by an 8-bit Integerbull ObjectsResources are accessed with
simple URIs Object IDObject InstanceResource ID
eg 1213
4 CoRE WG IETF-86 Orlando
CoRE WG IETF-86 Orlando
CoRE Resource Directory
draft-shelby-core-resource-directory-05
Z Shelby C Bormann S Krco
Backgroundbull Not a new concept
ndash think web search engine or any link directorybull Defines the interfaces to a Resource Directorybull Based on Web Linking framework and the CoRE Link Formatbull Generic REST design for use over HTTP and CoAPbull Used by OMA Lightweight M2Mbull Has already been deployed
ndash In traffic monitoring systemsndash In street lighting systemsndash For vehicular asset trackingndash By a major Cellular M2M operator
Changes since -04
bull Restricted Update to parameter updatesbull Added pagination support for the Lookup interfacebull Changed rt= to et= for the registration amp update
interfacebull Added group support
Group Management
bull RD now includes group management featuresbull New Group Function Set
ndash Register a groupbull Group name domain multicast address endpoint members
ndash Remove a groupbull Group lookup using the Lookup Function Set
ndash List registered groupsndash Find the members of a groupndash Find groups with certain endpoints or resources
Registering a Group
EP RD
| |
| - POST rd-groupgp=lights ltgtep=node1 --gt |
| |
| |
| lt---- 201 Created Location rd-group12 ---- |
| |
Req POST coaprdexamplecomrd-groupgp=lights
Payload
ltgtep=node1
ltgtep=node2
Res 201 Created
Location rd-group12
Looking up Group Members
Client RD
| |
| ----- GET rd-lookupepgp=lights1 ----------------------gt |
| |
| |
| lt-- 205 Content ltrdgtd=domain1ltrdgtd=domain2 --------- |
| |
Req GET rd-lookupepgp=lights1
Res 205 Content
ltcoaphostportgtep=node1
ltcoaphostportgtep=node2rdquo
Things for the futurebull Support for JSON representation of Web Links
ndash httptoolsietforgiddraft-bormann-core-links-json-02txtbull Registry for RD registration query parameters
ndash Already OMA Lightweight has defined some new onesbull More examples
Group 3 ldquonew workrdquo(continued)
109
drar-shy‐greevenbosch-shy‐core-shy‐profile-shy‐descripon-shy‐01Bert13 GreevenboschJeroen13 Hoebeke
Isam13 IshaqFloris13 Van13 den13 Abeele
Descripon
bull JSON13 format13 for13 signalling13 the13 servers13 capabilies
bull Signalling13 of13 supported13 opons13 media13 types13 and13 block13 sizendash Other13 items13 can13 be13 added
bull Filtering13 on13 specific13 fields13 through13 URI-shy‐Querybull Link13 hqpdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐profile-shy‐descripon
well-shy‐knownprofile
bull To13 acquire13 profile13 data13 of13 resources13 on13 a13 parcular13 service13 the13 well-shy‐knownprofile13 URI-shy‐path13 is13 introduced
bull For13 example13 to13 get13 all13 informaon13 from13 sensors13 served13 by13 wwwexampleorg13 we13 can13 do13 a13 GET13 to13 coapwwwexampleorgwell-shy‐knownprofile
bull Filtering13 on13 parcular13 resources13 is13 done13 through13 URI-shy‐Queries
Format
bull Currently13 the13 following13 fields13 are13 definedndash ldquopathrdquo13 contains13 the13 URI-shy‐path13 associated13 with13 a13 resource
ndash ldquooprdquo13 a13 numerical13 list13 of13 supported13 opon13 numbers
ndash ldquocfrdquo13 a13 numerical13 list13 of13 supported13 content-shy‐format13 numbers
ndash ldquob1srdquo13 ldquob2srdquo13 supported13 block13 sizes13 for13 Block113 and13 Block213 respecvely
Examplebull On13 the13 right13 is13 an13 example13 of13 a13 camera13 sensor13 at13 coapwwwexampleorgcam13 that13 supports13 the13 Uri-shy‐Host13 (3)13 ETag13 (4)13 Uri-shy‐Port13 (7)13 Uri-shy‐Path13 (11)13 Content-shy‐Format13 (12)13 Token13 (19)13 Block213 (23)13 and13 Proxy-shy‐Uri13 (35)13 opons
bull The13 supported13 content13 formats13 are13 textplain13 (0)13 applicaon13 link-shy‐format13 (40)13 and13 applicaonjson13 (50)
bull The13 supported13 Block213 can13 use13 25613 or13 51213 byte13 blocks
Req13 GET13 coapwwwexampleorgwell-shy‐knownprofile13 Res13 20513 Content13 (applicationjson)13 13 13 13 profile13 13 13 13 13 13 13 13 pathcam13 13 13 13 op[3471112192335]13 13 13 13 13 cf[04050]13 13 13 13 13 b2s[45]13 13 13 13
Filtering13 through13 use13 of13 URI-shy‐Query
bull Filtering13 can13 be13 done13 through13 the13 URI-shy‐Querybull Query13 format13 N=V
ndash N13 is13 a13 profile13 fieldndash V13 is13 the13 desired13 value
bull Examplesndash To13 find13 resources13 that13 support13 content13 format13 ldquoapplicaonjsonrdquo
13 GET13 wwwexampleorgwell-shy‐knownprofilecf=50ndash To13 get13 informaon13 about13 the13 camera
13 GET13 wwwexampleorgwell-shy‐knownprofilepath=cam
Open13 issues
bull Which13 other13 profile13 data13 needs13 signallingndash Content-shy‐type13 for13 different13 methods
bull Fix13 the13 order13 in13 which13 the13 profile13 fields13 must13 appearndash Non-shy‐fixed13 order13 easier13 extensible
bull Inheritance13 of13 a13 profile13 descriponbull Extend13 usage13 to13 signal13 the13 client13 profilebull Integraon13 with13 link13 format
Thank13 youQuesons
drar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval-shy‐00
Bert13 Greevenbosch
Descripon
bull The13 ldquoMinimumRequestInterval13 opon13 can13 be13 used13 to13 indicate13 the13 minimum13 me13 between13 two13 requests13 in13 a13 transacon
bull Originally13 intended13 for13 Block13 but13 also13 usable13 for13 other13 transaconsndash Example13 browsing13 a13 server
bull The13 goal13 is13 to13 reduce13 the13 server13 load13 and13 network13 traffic
bull Link13 hqpsdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval
Usage
bull The13 client13 keeps13 the13 server13 informed13 about13 its13 request13 speed13 through13 inclusion13 of13 the13 ldquoMinimumRequestIntervalrdquo13 opon
bull In13 responses13 the13 server13 fixes13 the13 minimum13 request13 interval13 through13 the13 same13 opon
bull The13 client13 obeys13 the13 speed13 indicated13 by13 the13 server
bull The13 client13 can13 send13 slower13 but13 not13 faster
Advantages
bull The13 server13 has13 means13 to13 limit13 the13 amount13 of13 incoming13 traffic
bull The13 server13 can13 prevent13 to13 become13 overloaded13 with13 too13 many13 tasks
bull The13 server13 does13 not13 need13 arficially13 slow13 down13 the13 client13 by13 sending13 late13 ACKsndash No13 need13 to13 keep13 track13 of13 delayed13 ACKsndash The13 server13 can13 perform13 other13 tasks13 instead
bull Reduced13 network13 traffic
Thank13 youQuesons
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-links-json-02txt
123
RFC 6690 (link-format) documents are somewhat foreign to many web app developerssect would prefer to have them in JSON format
There is no standard way to represent link-format documents in applicationssect but everyone knows how to handle JSON
Define a standard JSON translation for link-format
Itrsquos
not
rock
et
scien
ce
ltsensorsgtct=40title=Sensor Index ltsensorstempgtrt=temperature-cif=sensor ltsensorslightgtrt=light-luxif=sensor lthttpwwwexamplecomsensorst123gt anchor=sensorstemprel=describedby lttgtanchor=sensorstemprel=alternate [hrefsensorsct40titleSensor Index hrefsensorstemprttemperature-cifsensor hrefsensorslightrtlight-luxifsensor hrefhttpwwwexamplecomsensorst123 anchorsensorstempreldescribedby hreftanchorsensorstemprelalternate]
124
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-ipsec-for-coap-00txt
IPsec definitions for CoAP Mostly placeholder at this time Who has implementation experience with this
125
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-cross-reverse-convention-00txt
This draft has two lines of payload(based on a WGLC comment by Cullen Jennings)
coap12344567foobara=3
httpwwwproxycomwellknowncore-translate1234_4567foobara=3
Is that a useful convention to have
126
Insert CI slides here
127
128
0
5
10
15
20
25
30
35
40
10 20 30 40 50 60 70
good
put (
pps)
pps
Goodput vs pps (Econotags)
goodput
[Khattak preliminary]
Congestion Control
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-cocoa-00txt
ldquoadvancedrdquo cc (The draft is just a first shot) Others may have better ideas
129
Insert post-WGLC discussion slides here
130
Stop Continue Start
131
An Agile Retrospective
http6lowappnet coreIETF86 2013-03-12-13
Stop
132
Endless new CoAP optionssect instead use RESTful as much as possible
Move general security lifecycle out Looking at theoretical problems
http6lowappnet coreIETF86 2013-03-12-13
Continue
Interops Running code Look at real-world examples and deployments Solve their actual problems
sect Unilateral enhancements eg higher performance congestion control
sect Transports (SMS hellip)sect Make Web linking and Directories more and more usefulsect RESTful Design Paradigms for real-world problems
133
http6lowappnet coreIETF86 2013-03-12-13
Start
Further push into the (browser) web world (HTML5 browser security)
Specific supporting worksect SenMLsect URI work (dev URN hellip)sect Security Processes (next slide)
Spin outsect (We donrsquot really get to decide where this is done)
134
http6lowappnet coreIETF86 2013-03-12-13
Security
Integrate Application Network Group Keyingsect Tunnel-free setup
Donrsquot redo what has been done alreadysect ZigBee IP is finesect But what about other scenarios
Simple REST interfaces for working with keying materials and authorizationsect Start with defining objectives
Object Security for Constrained Nodes135
Re-chartering CoREWhat do we want to do now that wersquore grown up
Zach ShelbyCoRE WG IETF-86 Orlando
What is the scope
bull So we have a protocol and Web Linking what next
bull Keep with what we know besthellip1 Enhancements around CoAP2 New transports for CoAP3 New representations for Web Links4 General application layer solutions
CoRE WG IETF-86 Orlando 2
Enhancements around CoAP
bull Advanced congestion control
CoRE WG IETF-86 Orlando 3
New Transports for CoAP
bull Infrastructure for CoAP over foondash httptoolsietforgiddraft-silverajan-core-
coap-alternative-transports-01txtbull CoAP over SMS
ndash httptoolsietforgiddraft-becker-core-coap-sms-gprs-03txt
ndash OMA Lightweightbull CoAP over TCP
ndash httptoolsietforgiddraft-li-core-coap-payload-length-option-01txt
CoRE WG IETF-86 Orlando 4
New support for Web Links
bull JSON Web Linksndash httptoolsietforgiddraft-bormann-core-links-
json-02txt
2332010 CoRE WG IETF-77 Anaheim 5
General application layer solutions
bull Resource Directoryndash httptoolsietforgiddraft-shelby-core-
resource-directory-05txtndash OMA Lightweight
2332010 CoRE WG IETF-77 Anaheim 6
Current CoAP Support of Sleepy Node (22)
Lower layer support for sleepy nodes in most wireless technologies (eg WiFi ZigBee) But limited to MAC packet scheduling for sleepy nodes
and not aware of specific needs of IP applications (like CoAP)
Proposal ndash RD Based Sleep Tracking (14)
The current CoAP approach to support sleepy nodes can be significantly improved by introducing RD based mechanisms for a CoAP client to determine whether A targeted resource is located on a sleepy server A sleepy server is currently in sleep mode or not
There is any associated caching Proxy (possibly the RD itself) for a sleepy server
Proposal ndash RD Based Sleep Tracking (24)
We define the following new RD attributes to characterize the properties of a sleepy node SleepState - Indicates whether the node is currently in
sleep mode or not (ie Sleeping or Awake) SleepDuration - Indicates the maximum duration of time
that the node stays in sleep mode TimeSleeping - Indicates the length of time the node
has been sleeping (ie if Sleep State = Sleeping) NextSleep - Indicates the next time the node will go to
sleep (ie if Sleep State = Awake)
CachingProxy ndash Indicates the caching proxy of the sleepy node (ie the RD itself or another node)
Proposal ndash RD Based Sleep Tracking (34)
These attributes are all server (node) level and are new parameters added to the RD URI Template Variables
Finally we also define a new lookup-type (ss) for the RD lookup interface specified in [I-Dshelby-core-resource-directory] This new lookup-type supports looking up the
ldquoSleepStaterdquo (ss) of a specified end-point
Proposal ndash RD Based Sleep Tracking (44)
The three time based parameters (SleepDuration TimeSleeping NextSleep) can be based on either an absolute network time (for a time synchronized network) or a relative local time (measured at the local node)
Following the approach of [I-Dietf-core-link-format] and [I-Dshelby-core-resource-directory] sleep parameters for sleepy servers can be stored by the server in the RD and accessed by all interested clients
Examples of using these parameters in a synchronous or asynchronous manner are shown in the I-D
http6lowappnet coreIETF86 2013-03-12-13
We assume people have read the drafts
Meetings serve to advance difficult issues by making good use of face-to-face communications
Note Well Be aware of the IPR principles according to RFC 3979 and its updates
uumlBlue sheetsuumlScribe(s)
96
drar-shy‐iep-shy‐core-shy‐coapsubmiqed13 to13 IESG
2013-shy‐03-shy‐13
97
OMA Lightweight M2M Overview(A new standard using lots of IETF specs including DTLS
CoAP Block Observe Resource Directory SenMLhellip)
Zach ShelbyCoRE WG IETF-86 Orlando
OMA Lightweight M2Mbull Open Mobile Alliance is well known for Device Management (DM)bull OMA Lightweight M2M is a new standard from the alliance
ndash Focused on constrained Cellular and sensor network M2M devicesndash Driven by leading operators and vendors
bull Scopendash Interfaces protocol amp security between Device and Serverndash Object and Resource modelndash Bootstrap Device Access Control Connectivity and Firmware Objects
bull Draft Specifications are availablendash httpmemberopenmobileallianceorgftpPublic_documentsDM
LightweightM2MPermanent_documentsOMA-TS-LightweightM2M-V1_0_0-20130301-Dzip
bull Timelinendash Requirements and Architecture completed 3Q2012ndash Spec ready for Consistency Review 2Q2013ndash Candidate Approval expected 3Q2013
2 CoRE WG IETF-86 Orlando
Architecture
3
Scope of LWM2M
CoRE WG IETF-86 Orlando
Object Model
bull A Client has one or more Object Instancesbull An Object is a collection of Resourcesbull A Resource is an atomic piece of information
ndash Read Written or Executed
bull Resources can have multiple instancesbull Objects and Resources are identified by a
16-bit Integer Instances by an 8-bit Integerbull ObjectsResources are accessed with
simple URIs Object IDObject InstanceResource ID
eg 1213
4 CoRE WG IETF-86 Orlando
CoRE WG IETF-86 Orlando
CoRE Resource Directory
draft-shelby-core-resource-directory-05
Z Shelby C Bormann S Krco
Backgroundbull Not a new concept
ndash think web search engine or any link directorybull Defines the interfaces to a Resource Directorybull Based on Web Linking framework and the CoRE Link Formatbull Generic REST design for use over HTTP and CoAPbull Used by OMA Lightweight M2Mbull Has already been deployed
ndash In traffic monitoring systemsndash In street lighting systemsndash For vehicular asset trackingndash By a major Cellular M2M operator
Changes since -04
bull Restricted Update to parameter updatesbull Added pagination support for the Lookup interfacebull Changed rt= to et= for the registration amp update
interfacebull Added group support
Group Management
bull RD now includes group management featuresbull New Group Function Set
ndash Register a groupbull Group name domain multicast address endpoint members
ndash Remove a groupbull Group lookup using the Lookup Function Set
ndash List registered groupsndash Find the members of a groupndash Find groups with certain endpoints or resources
Registering a Group
EP RD
| |
| - POST rd-groupgp=lights ltgtep=node1 --gt |
| |
| |
| lt---- 201 Created Location rd-group12 ---- |
| |
Req POST coaprdexamplecomrd-groupgp=lights
Payload
ltgtep=node1
ltgtep=node2
Res 201 Created
Location rd-group12
Looking up Group Members
Client RD
| |
| ----- GET rd-lookupepgp=lights1 ----------------------gt |
| |
| |
| lt-- 205 Content ltrdgtd=domain1ltrdgtd=domain2 --------- |
| |
Req GET rd-lookupepgp=lights1
Res 205 Content
ltcoaphostportgtep=node1
ltcoaphostportgtep=node2rdquo
Things for the futurebull Support for JSON representation of Web Links
ndash httptoolsietforgiddraft-bormann-core-links-json-02txtbull Registry for RD registration query parameters
ndash Already OMA Lightweight has defined some new onesbull More examples
Group 3 ldquonew workrdquo(continued)
109
drar-shy‐greevenbosch-shy‐core-shy‐profile-shy‐descripon-shy‐01Bert13 GreevenboschJeroen13 Hoebeke
Isam13 IshaqFloris13 Van13 den13 Abeele
Descripon
bull JSON13 format13 for13 signalling13 the13 servers13 capabilies
bull Signalling13 of13 supported13 opons13 media13 types13 and13 block13 sizendash Other13 items13 can13 be13 added
bull Filtering13 on13 specific13 fields13 through13 URI-shy‐Querybull Link13 hqpdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐profile-shy‐descripon
well-shy‐knownprofile
bull To13 acquire13 profile13 data13 of13 resources13 on13 a13 parcular13 service13 the13 well-shy‐knownprofile13 URI-shy‐path13 is13 introduced
bull For13 example13 to13 get13 all13 informaon13 from13 sensors13 served13 by13 wwwexampleorg13 we13 can13 do13 a13 GET13 to13 coapwwwexampleorgwell-shy‐knownprofile
bull Filtering13 on13 parcular13 resources13 is13 done13 through13 URI-shy‐Queries
Format
bull Currently13 the13 following13 fields13 are13 definedndash ldquopathrdquo13 contains13 the13 URI-shy‐path13 associated13 with13 a13 resource
ndash ldquooprdquo13 a13 numerical13 list13 of13 supported13 opon13 numbers
ndash ldquocfrdquo13 a13 numerical13 list13 of13 supported13 content-shy‐format13 numbers
ndash ldquob1srdquo13 ldquob2srdquo13 supported13 block13 sizes13 for13 Block113 and13 Block213 respecvely
Examplebull On13 the13 right13 is13 an13 example13 of13 a13 camera13 sensor13 at13 coapwwwexampleorgcam13 that13 supports13 the13 Uri-shy‐Host13 (3)13 ETag13 (4)13 Uri-shy‐Port13 (7)13 Uri-shy‐Path13 (11)13 Content-shy‐Format13 (12)13 Token13 (19)13 Block213 (23)13 and13 Proxy-shy‐Uri13 (35)13 opons
bull The13 supported13 content13 formats13 are13 textplain13 (0)13 applicaon13 link-shy‐format13 (40)13 and13 applicaonjson13 (50)
bull The13 supported13 Block213 can13 use13 25613 or13 51213 byte13 blocks
Req13 GET13 coapwwwexampleorgwell-shy‐knownprofile13 Res13 20513 Content13 (applicationjson)13 13 13 13 profile13 13 13 13 13 13 13 13 pathcam13 13 13 13 op[3471112192335]13 13 13 13 13 cf[04050]13 13 13 13 13 b2s[45]13 13 13 13
Filtering13 through13 use13 of13 URI-shy‐Query
bull Filtering13 can13 be13 done13 through13 the13 URI-shy‐Querybull Query13 format13 N=V
ndash N13 is13 a13 profile13 fieldndash V13 is13 the13 desired13 value
bull Examplesndash To13 find13 resources13 that13 support13 content13 format13 ldquoapplicaonjsonrdquo
13 GET13 wwwexampleorgwell-shy‐knownprofilecf=50ndash To13 get13 informaon13 about13 the13 camera
13 GET13 wwwexampleorgwell-shy‐knownprofilepath=cam
Open13 issues
bull Which13 other13 profile13 data13 needs13 signallingndash Content-shy‐type13 for13 different13 methods
bull Fix13 the13 order13 in13 which13 the13 profile13 fields13 must13 appearndash Non-shy‐fixed13 order13 easier13 extensible
bull Inheritance13 of13 a13 profile13 descriponbull Extend13 usage13 to13 signal13 the13 client13 profilebull Integraon13 with13 link13 format
Thank13 youQuesons
drar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval-shy‐00
Bert13 Greevenbosch
Descripon
bull The13 ldquoMinimumRequestInterval13 opon13 can13 be13 used13 to13 indicate13 the13 minimum13 me13 between13 two13 requests13 in13 a13 transacon
bull Originally13 intended13 for13 Block13 but13 also13 usable13 for13 other13 transaconsndash Example13 browsing13 a13 server
bull The13 goal13 is13 to13 reduce13 the13 server13 load13 and13 network13 traffic
bull Link13 hqpsdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval
Usage
bull The13 client13 keeps13 the13 server13 informed13 about13 its13 request13 speed13 through13 inclusion13 of13 the13 ldquoMinimumRequestIntervalrdquo13 opon
bull In13 responses13 the13 server13 fixes13 the13 minimum13 request13 interval13 through13 the13 same13 opon
bull The13 client13 obeys13 the13 speed13 indicated13 by13 the13 server
bull The13 client13 can13 send13 slower13 but13 not13 faster
Advantages
bull The13 server13 has13 means13 to13 limit13 the13 amount13 of13 incoming13 traffic
bull The13 server13 can13 prevent13 to13 become13 overloaded13 with13 too13 many13 tasks
bull The13 server13 does13 not13 need13 arficially13 slow13 down13 the13 client13 by13 sending13 late13 ACKsndash No13 need13 to13 keep13 track13 of13 delayed13 ACKsndash The13 server13 can13 perform13 other13 tasks13 instead
bull Reduced13 network13 traffic
Thank13 youQuesons
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-links-json-02txt
123
RFC 6690 (link-format) documents are somewhat foreign to many web app developerssect would prefer to have them in JSON format
There is no standard way to represent link-format documents in applicationssect but everyone knows how to handle JSON
Define a standard JSON translation for link-format
Itrsquos
not
rock
et
scien
ce
ltsensorsgtct=40title=Sensor Index ltsensorstempgtrt=temperature-cif=sensor ltsensorslightgtrt=light-luxif=sensor lthttpwwwexamplecomsensorst123gt anchor=sensorstemprel=describedby lttgtanchor=sensorstemprel=alternate [hrefsensorsct40titleSensor Index hrefsensorstemprttemperature-cifsensor hrefsensorslightrtlight-luxifsensor hrefhttpwwwexamplecomsensorst123 anchorsensorstempreldescribedby hreftanchorsensorstemprelalternate]
124
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-ipsec-for-coap-00txt
IPsec definitions for CoAP Mostly placeholder at this time Who has implementation experience with this
125
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-cross-reverse-convention-00txt
This draft has two lines of payload(based on a WGLC comment by Cullen Jennings)
coap12344567foobara=3
httpwwwproxycomwellknowncore-translate1234_4567foobara=3
Is that a useful convention to have
126
Insert CI slides here
127
128
0
5
10
15
20
25
30
35
40
10 20 30 40 50 60 70
good
put (
pps)
pps
Goodput vs pps (Econotags)
goodput
[Khattak preliminary]
Congestion Control
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-cocoa-00txt
ldquoadvancedrdquo cc (The draft is just a first shot) Others may have better ideas
129
Insert post-WGLC discussion slides here
130
Stop Continue Start
131
An Agile Retrospective
http6lowappnet coreIETF86 2013-03-12-13
Stop
132
Endless new CoAP optionssect instead use RESTful as much as possible
Move general security lifecycle out Looking at theoretical problems
http6lowappnet coreIETF86 2013-03-12-13
Continue
Interops Running code Look at real-world examples and deployments Solve their actual problems
sect Unilateral enhancements eg higher performance congestion control
sect Transports (SMS hellip)sect Make Web linking and Directories more and more usefulsect RESTful Design Paradigms for real-world problems
133
http6lowappnet coreIETF86 2013-03-12-13
Start
Further push into the (browser) web world (HTML5 browser security)
Specific supporting worksect SenMLsect URI work (dev URN hellip)sect Security Processes (next slide)
Spin outsect (We donrsquot really get to decide where this is done)
134
http6lowappnet coreIETF86 2013-03-12-13
Security
Integrate Application Network Group Keyingsect Tunnel-free setup
Donrsquot redo what has been done alreadysect ZigBee IP is finesect But what about other scenarios
Simple REST interfaces for working with keying materials and authorizationsect Start with defining objectives
Object Security for Constrained Nodes135
Re-chartering CoREWhat do we want to do now that wersquore grown up
Zach ShelbyCoRE WG IETF-86 Orlando
What is the scope
bull So we have a protocol and Web Linking what next
bull Keep with what we know besthellip1 Enhancements around CoAP2 New transports for CoAP3 New representations for Web Links4 General application layer solutions
CoRE WG IETF-86 Orlando 2
Enhancements around CoAP
bull Advanced congestion control
CoRE WG IETF-86 Orlando 3
New Transports for CoAP
bull Infrastructure for CoAP over foondash httptoolsietforgiddraft-silverajan-core-
coap-alternative-transports-01txtbull CoAP over SMS
ndash httptoolsietforgiddraft-becker-core-coap-sms-gprs-03txt
ndash OMA Lightweightbull CoAP over TCP
ndash httptoolsietforgiddraft-li-core-coap-payload-length-option-01txt
CoRE WG IETF-86 Orlando 4
New support for Web Links
bull JSON Web Linksndash httptoolsietforgiddraft-bormann-core-links-
json-02txt
2332010 CoRE WG IETF-77 Anaheim 5
General application layer solutions
bull Resource Directoryndash httptoolsietforgiddraft-shelby-core-
resource-directory-05txtndash OMA Lightweight
2332010 CoRE WG IETF-77 Anaheim 6
Proposal ndash RD Based Sleep Tracking (14)
The current CoAP approach to support sleepy nodes can be significantly improved by introducing RD based mechanisms for a CoAP client to determine whether A targeted resource is located on a sleepy server A sleepy server is currently in sleep mode or not
There is any associated caching Proxy (possibly the RD itself) for a sleepy server
Proposal ndash RD Based Sleep Tracking (24)
We define the following new RD attributes to characterize the properties of a sleepy node SleepState - Indicates whether the node is currently in
sleep mode or not (ie Sleeping or Awake) SleepDuration - Indicates the maximum duration of time
that the node stays in sleep mode TimeSleeping - Indicates the length of time the node
has been sleeping (ie if Sleep State = Sleeping) NextSleep - Indicates the next time the node will go to
sleep (ie if Sleep State = Awake)
CachingProxy ndash Indicates the caching proxy of the sleepy node (ie the RD itself or another node)
Proposal ndash RD Based Sleep Tracking (34)
These attributes are all server (node) level and are new parameters added to the RD URI Template Variables
Finally we also define a new lookup-type (ss) for the RD lookup interface specified in [I-Dshelby-core-resource-directory] This new lookup-type supports looking up the
ldquoSleepStaterdquo (ss) of a specified end-point
Proposal ndash RD Based Sleep Tracking (44)
The three time based parameters (SleepDuration TimeSleeping NextSleep) can be based on either an absolute network time (for a time synchronized network) or a relative local time (measured at the local node)
Following the approach of [I-Dietf-core-link-format] and [I-Dshelby-core-resource-directory] sleep parameters for sleepy servers can be stored by the server in the RD and accessed by all interested clients
Examples of using these parameters in a synchronous or asynchronous manner are shown in the I-D
http6lowappnet coreIETF86 2013-03-12-13
We assume people have read the drafts
Meetings serve to advance difficult issues by making good use of face-to-face communications
Note Well Be aware of the IPR principles according to RFC 3979 and its updates
uumlBlue sheetsuumlScribe(s)
96
drar-shy‐iep-shy‐core-shy‐coapsubmiqed13 to13 IESG
2013-shy‐03-shy‐13
97
OMA Lightweight M2M Overview(A new standard using lots of IETF specs including DTLS
CoAP Block Observe Resource Directory SenMLhellip)
Zach ShelbyCoRE WG IETF-86 Orlando
OMA Lightweight M2Mbull Open Mobile Alliance is well known for Device Management (DM)bull OMA Lightweight M2M is a new standard from the alliance
ndash Focused on constrained Cellular and sensor network M2M devicesndash Driven by leading operators and vendors
bull Scopendash Interfaces protocol amp security between Device and Serverndash Object and Resource modelndash Bootstrap Device Access Control Connectivity and Firmware Objects
bull Draft Specifications are availablendash httpmemberopenmobileallianceorgftpPublic_documentsDM
LightweightM2MPermanent_documentsOMA-TS-LightweightM2M-V1_0_0-20130301-Dzip
bull Timelinendash Requirements and Architecture completed 3Q2012ndash Spec ready for Consistency Review 2Q2013ndash Candidate Approval expected 3Q2013
2 CoRE WG IETF-86 Orlando
Architecture
3
Scope of LWM2M
CoRE WG IETF-86 Orlando
Object Model
bull A Client has one or more Object Instancesbull An Object is a collection of Resourcesbull A Resource is an atomic piece of information
ndash Read Written or Executed
bull Resources can have multiple instancesbull Objects and Resources are identified by a
16-bit Integer Instances by an 8-bit Integerbull ObjectsResources are accessed with
simple URIs Object IDObject InstanceResource ID
eg 1213
4 CoRE WG IETF-86 Orlando
CoRE WG IETF-86 Orlando
CoRE Resource Directory
draft-shelby-core-resource-directory-05
Z Shelby C Bormann S Krco
Backgroundbull Not a new concept
ndash think web search engine or any link directorybull Defines the interfaces to a Resource Directorybull Based on Web Linking framework and the CoRE Link Formatbull Generic REST design for use over HTTP and CoAPbull Used by OMA Lightweight M2Mbull Has already been deployed
ndash In traffic monitoring systemsndash In street lighting systemsndash For vehicular asset trackingndash By a major Cellular M2M operator
Changes since -04
bull Restricted Update to parameter updatesbull Added pagination support for the Lookup interfacebull Changed rt= to et= for the registration amp update
interfacebull Added group support
Group Management
bull RD now includes group management featuresbull New Group Function Set
ndash Register a groupbull Group name domain multicast address endpoint members
ndash Remove a groupbull Group lookup using the Lookup Function Set
ndash List registered groupsndash Find the members of a groupndash Find groups with certain endpoints or resources
Registering a Group
EP RD
| |
| - POST rd-groupgp=lights ltgtep=node1 --gt |
| |
| |
| lt---- 201 Created Location rd-group12 ---- |
| |
Req POST coaprdexamplecomrd-groupgp=lights
Payload
ltgtep=node1
ltgtep=node2
Res 201 Created
Location rd-group12
Looking up Group Members
Client RD
| |
| ----- GET rd-lookupepgp=lights1 ----------------------gt |
| |
| |
| lt-- 205 Content ltrdgtd=domain1ltrdgtd=domain2 --------- |
| |
Req GET rd-lookupepgp=lights1
Res 205 Content
ltcoaphostportgtep=node1
ltcoaphostportgtep=node2rdquo
Things for the futurebull Support for JSON representation of Web Links
ndash httptoolsietforgiddraft-bormann-core-links-json-02txtbull Registry for RD registration query parameters
ndash Already OMA Lightweight has defined some new onesbull More examples
Group 3 ldquonew workrdquo(continued)
109
drar-shy‐greevenbosch-shy‐core-shy‐profile-shy‐descripon-shy‐01Bert13 GreevenboschJeroen13 Hoebeke
Isam13 IshaqFloris13 Van13 den13 Abeele
Descripon
bull JSON13 format13 for13 signalling13 the13 servers13 capabilies
bull Signalling13 of13 supported13 opons13 media13 types13 and13 block13 sizendash Other13 items13 can13 be13 added
bull Filtering13 on13 specific13 fields13 through13 URI-shy‐Querybull Link13 hqpdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐profile-shy‐descripon
well-shy‐knownprofile
bull To13 acquire13 profile13 data13 of13 resources13 on13 a13 parcular13 service13 the13 well-shy‐knownprofile13 URI-shy‐path13 is13 introduced
bull For13 example13 to13 get13 all13 informaon13 from13 sensors13 served13 by13 wwwexampleorg13 we13 can13 do13 a13 GET13 to13 coapwwwexampleorgwell-shy‐knownprofile
bull Filtering13 on13 parcular13 resources13 is13 done13 through13 URI-shy‐Queries
Format
bull Currently13 the13 following13 fields13 are13 definedndash ldquopathrdquo13 contains13 the13 URI-shy‐path13 associated13 with13 a13 resource
ndash ldquooprdquo13 a13 numerical13 list13 of13 supported13 opon13 numbers
ndash ldquocfrdquo13 a13 numerical13 list13 of13 supported13 content-shy‐format13 numbers
ndash ldquob1srdquo13 ldquob2srdquo13 supported13 block13 sizes13 for13 Block113 and13 Block213 respecvely
Examplebull On13 the13 right13 is13 an13 example13 of13 a13 camera13 sensor13 at13 coapwwwexampleorgcam13 that13 supports13 the13 Uri-shy‐Host13 (3)13 ETag13 (4)13 Uri-shy‐Port13 (7)13 Uri-shy‐Path13 (11)13 Content-shy‐Format13 (12)13 Token13 (19)13 Block213 (23)13 and13 Proxy-shy‐Uri13 (35)13 opons
bull The13 supported13 content13 formats13 are13 textplain13 (0)13 applicaon13 link-shy‐format13 (40)13 and13 applicaonjson13 (50)
bull The13 supported13 Block213 can13 use13 25613 or13 51213 byte13 blocks
Req13 GET13 coapwwwexampleorgwell-shy‐knownprofile13 Res13 20513 Content13 (applicationjson)13 13 13 13 profile13 13 13 13 13 13 13 13 pathcam13 13 13 13 op[3471112192335]13 13 13 13 13 cf[04050]13 13 13 13 13 b2s[45]13 13 13 13
Filtering13 through13 use13 of13 URI-shy‐Query
bull Filtering13 can13 be13 done13 through13 the13 URI-shy‐Querybull Query13 format13 N=V
ndash N13 is13 a13 profile13 fieldndash V13 is13 the13 desired13 value
bull Examplesndash To13 find13 resources13 that13 support13 content13 format13 ldquoapplicaonjsonrdquo
13 GET13 wwwexampleorgwell-shy‐knownprofilecf=50ndash To13 get13 informaon13 about13 the13 camera
13 GET13 wwwexampleorgwell-shy‐knownprofilepath=cam
Open13 issues
bull Which13 other13 profile13 data13 needs13 signallingndash Content-shy‐type13 for13 different13 methods
bull Fix13 the13 order13 in13 which13 the13 profile13 fields13 must13 appearndash Non-shy‐fixed13 order13 easier13 extensible
bull Inheritance13 of13 a13 profile13 descriponbull Extend13 usage13 to13 signal13 the13 client13 profilebull Integraon13 with13 link13 format
Thank13 youQuesons
drar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval-shy‐00
Bert13 Greevenbosch
Descripon
bull The13 ldquoMinimumRequestInterval13 opon13 can13 be13 used13 to13 indicate13 the13 minimum13 me13 between13 two13 requests13 in13 a13 transacon
bull Originally13 intended13 for13 Block13 but13 also13 usable13 for13 other13 transaconsndash Example13 browsing13 a13 server
bull The13 goal13 is13 to13 reduce13 the13 server13 load13 and13 network13 traffic
bull Link13 hqpsdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval
Usage
bull The13 client13 keeps13 the13 server13 informed13 about13 its13 request13 speed13 through13 inclusion13 of13 the13 ldquoMinimumRequestIntervalrdquo13 opon
bull In13 responses13 the13 server13 fixes13 the13 minimum13 request13 interval13 through13 the13 same13 opon
bull The13 client13 obeys13 the13 speed13 indicated13 by13 the13 server
bull The13 client13 can13 send13 slower13 but13 not13 faster
Advantages
bull The13 server13 has13 means13 to13 limit13 the13 amount13 of13 incoming13 traffic
bull The13 server13 can13 prevent13 to13 become13 overloaded13 with13 too13 many13 tasks
bull The13 server13 does13 not13 need13 arficially13 slow13 down13 the13 client13 by13 sending13 late13 ACKsndash No13 need13 to13 keep13 track13 of13 delayed13 ACKsndash The13 server13 can13 perform13 other13 tasks13 instead
bull Reduced13 network13 traffic
Thank13 youQuesons
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-links-json-02txt
123
RFC 6690 (link-format) documents are somewhat foreign to many web app developerssect would prefer to have them in JSON format
There is no standard way to represent link-format documents in applicationssect but everyone knows how to handle JSON
Define a standard JSON translation for link-format
Itrsquos
not
rock
et
scien
ce
ltsensorsgtct=40title=Sensor Index ltsensorstempgtrt=temperature-cif=sensor ltsensorslightgtrt=light-luxif=sensor lthttpwwwexamplecomsensorst123gt anchor=sensorstemprel=describedby lttgtanchor=sensorstemprel=alternate [hrefsensorsct40titleSensor Index hrefsensorstemprttemperature-cifsensor hrefsensorslightrtlight-luxifsensor hrefhttpwwwexamplecomsensorst123 anchorsensorstempreldescribedby hreftanchorsensorstemprelalternate]
124
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-ipsec-for-coap-00txt
IPsec definitions for CoAP Mostly placeholder at this time Who has implementation experience with this
125
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-cross-reverse-convention-00txt
This draft has two lines of payload(based on a WGLC comment by Cullen Jennings)
coap12344567foobara=3
httpwwwproxycomwellknowncore-translate1234_4567foobara=3
Is that a useful convention to have
126
Insert CI slides here
127
128
0
5
10
15
20
25
30
35
40
10 20 30 40 50 60 70
good
put (
pps)
pps
Goodput vs pps (Econotags)
goodput
[Khattak preliminary]
Congestion Control
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-cocoa-00txt
ldquoadvancedrdquo cc (The draft is just a first shot) Others may have better ideas
129
Insert post-WGLC discussion slides here
130
Stop Continue Start
131
An Agile Retrospective
http6lowappnet coreIETF86 2013-03-12-13
Stop
132
Endless new CoAP optionssect instead use RESTful as much as possible
Move general security lifecycle out Looking at theoretical problems
http6lowappnet coreIETF86 2013-03-12-13
Continue
Interops Running code Look at real-world examples and deployments Solve their actual problems
sect Unilateral enhancements eg higher performance congestion control
sect Transports (SMS hellip)sect Make Web linking and Directories more and more usefulsect RESTful Design Paradigms for real-world problems
133
http6lowappnet coreIETF86 2013-03-12-13
Start
Further push into the (browser) web world (HTML5 browser security)
Specific supporting worksect SenMLsect URI work (dev URN hellip)sect Security Processes (next slide)
Spin outsect (We donrsquot really get to decide where this is done)
134
http6lowappnet coreIETF86 2013-03-12-13
Security
Integrate Application Network Group Keyingsect Tunnel-free setup
Donrsquot redo what has been done alreadysect ZigBee IP is finesect But what about other scenarios
Simple REST interfaces for working with keying materials and authorizationsect Start with defining objectives
Object Security for Constrained Nodes135
Re-chartering CoREWhat do we want to do now that wersquore grown up
Zach ShelbyCoRE WG IETF-86 Orlando
What is the scope
bull So we have a protocol and Web Linking what next
bull Keep with what we know besthellip1 Enhancements around CoAP2 New transports for CoAP3 New representations for Web Links4 General application layer solutions
CoRE WG IETF-86 Orlando 2
Enhancements around CoAP
bull Advanced congestion control
CoRE WG IETF-86 Orlando 3
New Transports for CoAP
bull Infrastructure for CoAP over foondash httptoolsietforgiddraft-silverajan-core-
coap-alternative-transports-01txtbull CoAP over SMS
ndash httptoolsietforgiddraft-becker-core-coap-sms-gprs-03txt
ndash OMA Lightweightbull CoAP over TCP
ndash httptoolsietforgiddraft-li-core-coap-payload-length-option-01txt
CoRE WG IETF-86 Orlando 4
New support for Web Links
bull JSON Web Linksndash httptoolsietforgiddraft-bormann-core-links-
json-02txt
2332010 CoRE WG IETF-77 Anaheim 5
General application layer solutions
bull Resource Directoryndash httptoolsietforgiddraft-shelby-core-
resource-directory-05txtndash OMA Lightweight
2332010 CoRE WG IETF-77 Anaheim 6
Proposal ndash RD Based Sleep Tracking (24)
We define the following new RD attributes to characterize the properties of a sleepy node SleepState - Indicates whether the node is currently in
sleep mode or not (ie Sleeping or Awake) SleepDuration - Indicates the maximum duration of time
that the node stays in sleep mode TimeSleeping - Indicates the length of time the node
has been sleeping (ie if Sleep State = Sleeping) NextSleep - Indicates the next time the node will go to
sleep (ie if Sleep State = Awake)
CachingProxy ndash Indicates the caching proxy of the sleepy node (ie the RD itself or another node)
Proposal ndash RD Based Sleep Tracking (34)
These attributes are all server (node) level and are new parameters added to the RD URI Template Variables
Finally we also define a new lookup-type (ss) for the RD lookup interface specified in [I-Dshelby-core-resource-directory] This new lookup-type supports looking up the
ldquoSleepStaterdquo (ss) of a specified end-point
Proposal ndash RD Based Sleep Tracking (44)
The three time based parameters (SleepDuration TimeSleeping NextSleep) can be based on either an absolute network time (for a time synchronized network) or a relative local time (measured at the local node)
Following the approach of [I-Dietf-core-link-format] and [I-Dshelby-core-resource-directory] sleep parameters for sleepy servers can be stored by the server in the RD and accessed by all interested clients
Examples of using these parameters in a synchronous or asynchronous manner are shown in the I-D
http6lowappnet coreIETF86 2013-03-12-13
We assume people have read the drafts
Meetings serve to advance difficult issues by making good use of face-to-face communications
Note Well Be aware of the IPR principles according to RFC 3979 and its updates
uumlBlue sheetsuumlScribe(s)
96
drar-shy‐iep-shy‐core-shy‐coapsubmiqed13 to13 IESG
2013-shy‐03-shy‐13
97
OMA Lightweight M2M Overview(A new standard using lots of IETF specs including DTLS
CoAP Block Observe Resource Directory SenMLhellip)
Zach ShelbyCoRE WG IETF-86 Orlando
OMA Lightweight M2Mbull Open Mobile Alliance is well known for Device Management (DM)bull OMA Lightweight M2M is a new standard from the alliance
ndash Focused on constrained Cellular and sensor network M2M devicesndash Driven by leading operators and vendors
bull Scopendash Interfaces protocol amp security between Device and Serverndash Object and Resource modelndash Bootstrap Device Access Control Connectivity and Firmware Objects
bull Draft Specifications are availablendash httpmemberopenmobileallianceorgftpPublic_documentsDM
LightweightM2MPermanent_documentsOMA-TS-LightweightM2M-V1_0_0-20130301-Dzip
bull Timelinendash Requirements and Architecture completed 3Q2012ndash Spec ready for Consistency Review 2Q2013ndash Candidate Approval expected 3Q2013
2 CoRE WG IETF-86 Orlando
Architecture
3
Scope of LWM2M
CoRE WG IETF-86 Orlando
Object Model
bull A Client has one or more Object Instancesbull An Object is a collection of Resourcesbull A Resource is an atomic piece of information
ndash Read Written or Executed
bull Resources can have multiple instancesbull Objects and Resources are identified by a
16-bit Integer Instances by an 8-bit Integerbull ObjectsResources are accessed with
simple URIs Object IDObject InstanceResource ID
eg 1213
4 CoRE WG IETF-86 Orlando
CoRE WG IETF-86 Orlando
CoRE Resource Directory
draft-shelby-core-resource-directory-05
Z Shelby C Bormann S Krco
Backgroundbull Not a new concept
ndash think web search engine or any link directorybull Defines the interfaces to a Resource Directorybull Based on Web Linking framework and the CoRE Link Formatbull Generic REST design for use over HTTP and CoAPbull Used by OMA Lightweight M2Mbull Has already been deployed
ndash In traffic monitoring systemsndash In street lighting systemsndash For vehicular asset trackingndash By a major Cellular M2M operator
Changes since -04
bull Restricted Update to parameter updatesbull Added pagination support for the Lookup interfacebull Changed rt= to et= for the registration amp update
interfacebull Added group support
Group Management
bull RD now includes group management featuresbull New Group Function Set
ndash Register a groupbull Group name domain multicast address endpoint members
ndash Remove a groupbull Group lookup using the Lookup Function Set
ndash List registered groupsndash Find the members of a groupndash Find groups with certain endpoints or resources
Registering a Group
EP RD
| |
| - POST rd-groupgp=lights ltgtep=node1 --gt |
| |
| |
| lt---- 201 Created Location rd-group12 ---- |
| |
Req POST coaprdexamplecomrd-groupgp=lights
Payload
ltgtep=node1
ltgtep=node2
Res 201 Created
Location rd-group12
Looking up Group Members
Client RD
| |
| ----- GET rd-lookupepgp=lights1 ----------------------gt |
| |
| |
| lt-- 205 Content ltrdgtd=domain1ltrdgtd=domain2 --------- |
| |
Req GET rd-lookupepgp=lights1
Res 205 Content
ltcoaphostportgtep=node1
ltcoaphostportgtep=node2rdquo
Things for the futurebull Support for JSON representation of Web Links
ndash httptoolsietforgiddraft-bormann-core-links-json-02txtbull Registry for RD registration query parameters
ndash Already OMA Lightweight has defined some new onesbull More examples
Group 3 ldquonew workrdquo(continued)
109
drar-shy‐greevenbosch-shy‐core-shy‐profile-shy‐descripon-shy‐01Bert13 GreevenboschJeroen13 Hoebeke
Isam13 IshaqFloris13 Van13 den13 Abeele
Descripon
bull JSON13 format13 for13 signalling13 the13 servers13 capabilies
bull Signalling13 of13 supported13 opons13 media13 types13 and13 block13 sizendash Other13 items13 can13 be13 added
bull Filtering13 on13 specific13 fields13 through13 URI-shy‐Querybull Link13 hqpdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐profile-shy‐descripon
well-shy‐knownprofile
bull To13 acquire13 profile13 data13 of13 resources13 on13 a13 parcular13 service13 the13 well-shy‐knownprofile13 URI-shy‐path13 is13 introduced
bull For13 example13 to13 get13 all13 informaon13 from13 sensors13 served13 by13 wwwexampleorg13 we13 can13 do13 a13 GET13 to13 coapwwwexampleorgwell-shy‐knownprofile
bull Filtering13 on13 parcular13 resources13 is13 done13 through13 URI-shy‐Queries
Format
bull Currently13 the13 following13 fields13 are13 definedndash ldquopathrdquo13 contains13 the13 URI-shy‐path13 associated13 with13 a13 resource
ndash ldquooprdquo13 a13 numerical13 list13 of13 supported13 opon13 numbers
ndash ldquocfrdquo13 a13 numerical13 list13 of13 supported13 content-shy‐format13 numbers
ndash ldquob1srdquo13 ldquob2srdquo13 supported13 block13 sizes13 for13 Block113 and13 Block213 respecvely
Examplebull On13 the13 right13 is13 an13 example13 of13 a13 camera13 sensor13 at13 coapwwwexampleorgcam13 that13 supports13 the13 Uri-shy‐Host13 (3)13 ETag13 (4)13 Uri-shy‐Port13 (7)13 Uri-shy‐Path13 (11)13 Content-shy‐Format13 (12)13 Token13 (19)13 Block213 (23)13 and13 Proxy-shy‐Uri13 (35)13 opons
bull The13 supported13 content13 formats13 are13 textplain13 (0)13 applicaon13 link-shy‐format13 (40)13 and13 applicaonjson13 (50)
bull The13 supported13 Block213 can13 use13 25613 or13 51213 byte13 blocks
Req13 GET13 coapwwwexampleorgwell-shy‐knownprofile13 Res13 20513 Content13 (applicationjson)13 13 13 13 profile13 13 13 13 13 13 13 13 pathcam13 13 13 13 op[3471112192335]13 13 13 13 13 cf[04050]13 13 13 13 13 b2s[45]13 13 13 13
Filtering13 through13 use13 of13 URI-shy‐Query
bull Filtering13 can13 be13 done13 through13 the13 URI-shy‐Querybull Query13 format13 N=V
ndash N13 is13 a13 profile13 fieldndash V13 is13 the13 desired13 value
bull Examplesndash To13 find13 resources13 that13 support13 content13 format13 ldquoapplicaonjsonrdquo
13 GET13 wwwexampleorgwell-shy‐knownprofilecf=50ndash To13 get13 informaon13 about13 the13 camera
13 GET13 wwwexampleorgwell-shy‐knownprofilepath=cam
Open13 issues
bull Which13 other13 profile13 data13 needs13 signallingndash Content-shy‐type13 for13 different13 methods
bull Fix13 the13 order13 in13 which13 the13 profile13 fields13 must13 appearndash Non-shy‐fixed13 order13 easier13 extensible
bull Inheritance13 of13 a13 profile13 descriponbull Extend13 usage13 to13 signal13 the13 client13 profilebull Integraon13 with13 link13 format
Thank13 youQuesons
drar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval-shy‐00
Bert13 Greevenbosch
Descripon
bull The13 ldquoMinimumRequestInterval13 opon13 can13 be13 used13 to13 indicate13 the13 minimum13 me13 between13 two13 requests13 in13 a13 transacon
bull Originally13 intended13 for13 Block13 but13 also13 usable13 for13 other13 transaconsndash Example13 browsing13 a13 server
bull The13 goal13 is13 to13 reduce13 the13 server13 load13 and13 network13 traffic
bull Link13 hqpsdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval
Usage
bull The13 client13 keeps13 the13 server13 informed13 about13 its13 request13 speed13 through13 inclusion13 of13 the13 ldquoMinimumRequestIntervalrdquo13 opon
bull In13 responses13 the13 server13 fixes13 the13 minimum13 request13 interval13 through13 the13 same13 opon
bull The13 client13 obeys13 the13 speed13 indicated13 by13 the13 server
bull The13 client13 can13 send13 slower13 but13 not13 faster
Advantages
bull The13 server13 has13 means13 to13 limit13 the13 amount13 of13 incoming13 traffic
bull The13 server13 can13 prevent13 to13 become13 overloaded13 with13 too13 many13 tasks
bull The13 server13 does13 not13 need13 arficially13 slow13 down13 the13 client13 by13 sending13 late13 ACKsndash No13 need13 to13 keep13 track13 of13 delayed13 ACKsndash The13 server13 can13 perform13 other13 tasks13 instead
bull Reduced13 network13 traffic
Thank13 youQuesons
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-links-json-02txt
123
RFC 6690 (link-format) documents are somewhat foreign to many web app developerssect would prefer to have them in JSON format
There is no standard way to represent link-format documents in applicationssect but everyone knows how to handle JSON
Define a standard JSON translation for link-format
Itrsquos
not
rock
et
scien
ce
ltsensorsgtct=40title=Sensor Index ltsensorstempgtrt=temperature-cif=sensor ltsensorslightgtrt=light-luxif=sensor lthttpwwwexamplecomsensorst123gt anchor=sensorstemprel=describedby lttgtanchor=sensorstemprel=alternate [hrefsensorsct40titleSensor Index hrefsensorstemprttemperature-cifsensor hrefsensorslightrtlight-luxifsensor hrefhttpwwwexamplecomsensorst123 anchorsensorstempreldescribedby hreftanchorsensorstemprelalternate]
124
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-ipsec-for-coap-00txt
IPsec definitions for CoAP Mostly placeholder at this time Who has implementation experience with this
125
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-cross-reverse-convention-00txt
This draft has two lines of payload(based on a WGLC comment by Cullen Jennings)
coap12344567foobara=3
httpwwwproxycomwellknowncore-translate1234_4567foobara=3
Is that a useful convention to have
126
Insert CI slides here
127
128
0
5
10
15
20
25
30
35
40
10 20 30 40 50 60 70
good
put (
pps)
pps
Goodput vs pps (Econotags)
goodput
[Khattak preliminary]
Congestion Control
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-cocoa-00txt
ldquoadvancedrdquo cc (The draft is just a first shot) Others may have better ideas
129
Insert post-WGLC discussion slides here
130
Stop Continue Start
131
An Agile Retrospective
http6lowappnet coreIETF86 2013-03-12-13
Stop
132
Endless new CoAP optionssect instead use RESTful as much as possible
Move general security lifecycle out Looking at theoretical problems
http6lowappnet coreIETF86 2013-03-12-13
Continue
Interops Running code Look at real-world examples and deployments Solve their actual problems
sect Unilateral enhancements eg higher performance congestion control
sect Transports (SMS hellip)sect Make Web linking and Directories more and more usefulsect RESTful Design Paradigms for real-world problems
133
http6lowappnet coreIETF86 2013-03-12-13
Start
Further push into the (browser) web world (HTML5 browser security)
Specific supporting worksect SenMLsect URI work (dev URN hellip)sect Security Processes (next slide)
Spin outsect (We donrsquot really get to decide where this is done)
134
http6lowappnet coreIETF86 2013-03-12-13
Security
Integrate Application Network Group Keyingsect Tunnel-free setup
Donrsquot redo what has been done alreadysect ZigBee IP is finesect But what about other scenarios
Simple REST interfaces for working with keying materials and authorizationsect Start with defining objectives
Object Security for Constrained Nodes135
Re-chartering CoREWhat do we want to do now that wersquore grown up
Zach ShelbyCoRE WG IETF-86 Orlando
What is the scope
bull So we have a protocol and Web Linking what next
bull Keep with what we know besthellip1 Enhancements around CoAP2 New transports for CoAP3 New representations for Web Links4 General application layer solutions
CoRE WG IETF-86 Orlando 2
Enhancements around CoAP
bull Advanced congestion control
CoRE WG IETF-86 Orlando 3
New Transports for CoAP
bull Infrastructure for CoAP over foondash httptoolsietforgiddraft-silverajan-core-
coap-alternative-transports-01txtbull CoAP over SMS
ndash httptoolsietforgiddraft-becker-core-coap-sms-gprs-03txt
ndash OMA Lightweightbull CoAP over TCP
ndash httptoolsietforgiddraft-li-core-coap-payload-length-option-01txt
CoRE WG IETF-86 Orlando 4
New support for Web Links
bull JSON Web Linksndash httptoolsietforgiddraft-bormann-core-links-
json-02txt
2332010 CoRE WG IETF-77 Anaheim 5
General application layer solutions
bull Resource Directoryndash httptoolsietforgiddraft-shelby-core-
resource-directory-05txtndash OMA Lightweight
2332010 CoRE WG IETF-77 Anaheim 6
Proposal ndash RD Based Sleep Tracking (34)
These attributes are all server (node) level and are new parameters added to the RD URI Template Variables
Finally we also define a new lookup-type (ss) for the RD lookup interface specified in [I-Dshelby-core-resource-directory] This new lookup-type supports looking up the
ldquoSleepStaterdquo (ss) of a specified end-point
Proposal ndash RD Based Sleep Tracking (44)
The three time based parameters (SleepDuration TimeSleeping NextSleep) can be based on either an absolute network time (for a time synchronized network) or a relative local time (measured at the local node)
Following the approach of [I-Dietf-core-link-format] and [I-Dshelby-core-resource-directory] sleep parameters for sleepy servers can be stored by the server in the RD and accessed by all interested clients
Examples of using these parameters in a synchronous or asynchronous manner are shown in the I-D
http6lowappnet coreIETF86 2013-03-12-13
We assume people have read the drafts
Meetings serve to advance difficult issues by making good use of face-to-face communications
Note Well Be aware of the IPR principles according to RFC 3979 and its updates
uumlBlue sheetsuumlScribe(s)
96
drar-shy‐iep-shy‐core-shy‐coapsubmiqed13 to13 IESG
2013-shy‐03-shy‐13
97
OMA Lightweight M2M Overview(A new standard using lots of IETF specs including DTLS
CoAP Block Observe Resource Directory SenMLhellip)
Zach ShelbyCoRE WG IETF-86 Orlando
OMA Lightweight M2Mbull Open Mobile Alliance is well known for Device Management (DM)bull OMA Lightweight M2M is a new standard from the alliance
ndash Focused on constrained Cellular and sensor network M2M devicesndash Driven by leading operators and vendors
bull Scopendash Interfaces protocol amp security between Device and Serverndash Object and Resource modelndash Bootstrap Device Access Control Connectivity and Firmware Objects
bull Draft Specifications are availablendash httpmemberopenmobileallianceorgftpPublic_documentsDM
LightweightM2MPermanent_documentsOMA-TS-LightweightM2M-V1_0_0-20130301-Dzip
bull Timelinendash Requirements and Architecture completed 3Q2012ndash Spec ready for Consistency Review 2Q2013ndash Candidate Approval expected 3Q2013
2 CoRE WG IETF-86 Orlando
Architecture
3
Scope of LWM2M
CoRE WG IETF-86 Orlando
Object Model
bull A Client has one or more Object Instancesbull An Object is a collection of Resourcesbull A Resource is an atomic piece of information
ndash Read Written or Executed
bull Resources can have multiple instancesbull Objects and Resources are identified by a
16-bit Integer Instances by an 8-bit Integerbull ObjectsResources are accessed with
simple URIs Object IDObject InstanceResource ID
eg 1213
4 CoRE WG IETF-86 Orlando
CoRE WG IETF-86 Orlando
CoRE Resource Directory
draft-shelby-core-resource-directory-05
Z Shelby C Bormann S Krco
Backgroundbull Not a new concept
ndash think web search engine or any link directorybull Defines the interfaces to a Resource Directorybull Based on Web Linking framework and the CoRE Link Formatbull Generic REST design for use over HTTP and CoAPbull Used by OMA Lightweight M2Mbull Has already been deployed
ndash In traffic monitoring systemsndash In street lighting systemsndash For vehicular asset trackingndash By a major Cellular M2M operator
Changes since -04
bull Restricted Update to parameter updatesbull Added pagination support for the Lookup interfacebull Changed rt= to et= for the registration amp update
interfacebull Added group support
Group Management
bull RD now includes group management featuresbull New Group Function Set
ndash Register a groupbull Group name domain multicast address endpoint members
ndash Remove a groupbull Group lookup using the Lookup Function Set
ndash List registered groupsndash Find the members of a groupndash Find groups with certain endpoints or resources
Registering a Group
EP RD
| |
| - POST rd-groupgp=lights ltgtep=node1 --gt |
| |
| |
| lt---- 201 Created Location rd-group12 ---- |
| |
Req POST coaprdexamplecomrd-groupgp=lights
Payload
ltgtep=node1
ltgtep=node2
Res 201 Created
Location rd-group12
Looking up Group Members
Client RD
| |
| ----- GET rd-lookupepgp=lights1 ----------------------gt |
| |
| |
| lt-- 205 Content ltrdgtd=domain1ltrdgtd=domain2 --------- |
| |
Req GET rd-lookupepgp=lights1
Res 205 Content
ltcoaphostportgtep=node1
ltcoaphostportgtep=node2rdquo
Things for the futurebull Support for JSON representation of Web Links
ndash httptoolsietforgiddraft-bormann-core-links-json-02txtbull Registry for RD registration query parameters
ndash Already OMA Lightweight has defined some new onesbull More examples
Group 3 ldquonew workrdquo(continued)
109
drar-shy‐greevenbosch-shy‐core-shy‐profile-shy‐descripon-shy‐01Bert13 GreevenboschJeroen13 Hoebeke
Isam13 IshaqFloris13 Van13 den13 Abeele
Descripon
bull JSON13 format13 for13 signalling13 the13 servers13 capabilies
bull Signalling13 of13 supported13 opons13 media13 types13 and13 block13 sizendash Other13 items13 can13 be13 added
bull Filtering13 on13 specific13 fields13 through13 URI-shy‐Querybull Link13 hqpdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐profile-shy‐descripon
well-shy‐knownprofile
bull To13 acquire13 profile13 data13 of13 resources13 on13 a13 parcular13 service13 the13 well-shy‐knownprofile13 URI-shy‐path13 is13 introduced
bull For13 example13 to13 get13 all13 informaon13 from13 sensors13 served13 by13 wwwexampleorg13 we13 can13 do13 a13 GET13 to13 coapwwwexampleorgwell-shy‐knownprofile
bull Filtering13 on13 parcular13 resources13 is13 done13 through13 URI-shy‐Queries
Format
bull Currently13 the13 following13 fields13 are13 definedndash ldquopathrdquo13 contains13 the13 URI-shy‐path13 associated13 with13 a13 resource
ndash ldquooprdquo13 a13 numerical13 list13 of13 supported13 opon13 numbers
ndash ldquocfrdquo13 a13 numerical13 list13 of13 supported13 content-shy‐format13 numbers
ndash ldquob1srdquo13 ldquob2srdquo13 supported13 block13 sizes13 for13 Block113 and13 Block213 respecvely
Examplebull On13 the13 right13 is13 an13 example13 of13 a13 camera13 sensor13 at13 coapwwwexampleorgcam13 that13 supports13 the13 Uri-shy‐Host13 (3)13 ETag13 (4)13 Uri-shy‐Port13 (7)13 Uri-shy‐Path13 (11)13 Content-shy‐Format13 (12)13 Token13 (19)13 Block213 (23)13 and13 Proxy-shy‐Uri13 (35)13 opons
bull The13 supported13 content13 formats13 are13 textplain13 (0)13 applicaon13 link-shy‐format13 (40)13 and13 applicaonjson13 (50)
bull The13 supported13 Block213 can13 use13 25613 or13 51213 byte13 blocks
Req13 GET13 coapwwwexampleorgwell-shy‐knownprofile13 Res13 20513 Content13 (applicationjson)13 13 13 13 profile13 13 13 13 13 13 13 13 pathcam13 13 13 13 op[3471112192335]13 13 13 13 13 cf[04050]13 13 13 13 13 b2s[45]13 13 13 13
Filtering13 through13 use13 of13 URI-shy‐Query
bull Filtering13 can13 be13 done13 through13 the13 URI-shy‐Querybull Query13 format13 N=V
ndash N13 is13 a13 profile13 fieldndash V13 is13 the13 desired13 value
bull Examplesndash To13 find13 resources13 that13 support13 content13 format13 ldquoapplicaonjsonrdquo
13 GET13 wwwexampleorgwell-shy‐knownprofilecf=50ndash To13 get13 informaon13 about13 the13 camera
13 GET13 wwwexampleorgwell-shy‐knownprofilepath=cam
Open13 issues
bull Which13 other13 profile13 data13 needs13 signallingndash Content-shy‐type13 for13 different13 methods
bull Fix13 the13 order13 in13 which13 the13 profile13 fields13 must13 appearndash Non-shy‐fixed13 order13 easier13 extensible
bull Inheritance13 of13 a13 profile13 descriponbull Extend13 usage13 to13 signal13 the13 client13 profilebull Integraon13 with13 link13 format
Thank13 youQuesons
drar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval-shy‐00
Bert13 Greevenbosch
Descripon
bull The13 ldquoMinimumRequestInterval13 opon13 can13 be13 used13 to13 indicate13 the13 minimum13 me13 between13 two13 requests13 in13 a13 transacon
bull Originally13 intended13 for13 Block13 but13 also13 usable13 for13 other13 transaconsndash Example13 browsing13 a13 server
bull The13 goal13 is13 to13 reduce13 the13 server13 load13 and13 network13 traffic
bull Link13 hqpsdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval
Usage
bull The13 client13 keeps13 the13 server13 informed13 about13 its13 request13 speed13 through13 inclusion13 of13 the13 ldquoMinimumRequestIntervalrdquo13 opon
bull In13 responses13 the13 server13 fixes13 the13 minimum13 request13 interval13 through13 the13 same13 opon
bull The13 client13 obeys13 the13 speed13 indicated13 by13 the13 server
bull The13 client13 can13 send13 slower13 but13 not13 faster
Advantages
bull The13 server13 has13 means13 to13 limit13 the13 amount13 of13 incoming13 traffic
bull The13 server13 can13 prevent13 to13 become13 overloaded13 with13 too13 many13 tasks
bull The13 server13 does13 not13 need13 arficially13 slow13 down13 the13 client13 by13 sending13 late13 ACKsndash No13 need13 to13 keep13 track13 of13 delayed13 ACKsndash The13 server13 can13 perform13 other13 tasks13 instead
bull Reduced13 network13 traffic
Thank13 youQuesons
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-links-json-02txt
123
RFC 6690 (link-format) documents are somewhat foreign to many web app developerssect would prefer to have them in JSON format
There is no standard way to represent link-format documents in applicationssect but everyone knows how to handle JSON
Define a standard JSON translation for link-format
Itrsquos
not
rock
et
scien
ce
ltsensorsgtct=40title=Sensor Index ltsensorstempgtrt=temperature-cif=sensor ltsensorslightgtrt=light-luxif=sensor lthttpwwwexamplecomsensorst123gt anchor=sensorstemprel=describedby lttgtanchor=sensorstemprel=alternate [hrefsensorsct40titleSensor Index hrefsensorstemprttemperature-cifsensor hrefsensorslightrtlight-luxifsensor hrefhttpwwwexamplecomsensorst123 anchorsensorstempreldescribedby hreftanchorsensorstemprelalternate]
124
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-ipsec-for-coap-00txt
IPsec definitions for CoAP Mostly placeholder at this time Who has implementation experience with this
125
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-cross-reverse-convention-00txt
This draft has two lines of payload(based on a WGLC comment by Cullen Jennings)
coap12344567foobara=3
httpwwwproxycomwellknowncore-translate1234_4567foobara=3
Is that a useful convention to have
126
Insert CI slides here
127
128
0
5
10
15
20
25
30
35
40
10 20 30 40 50 60 70
good
put (
pps)
pps
Goodput vs pps (Econotags)
goodput
[Khattak preliminary]
Congestion Control
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-cocoa-00txt
ldquoadvancedrdquo cc (The draft is just a first shot) Others may have better ideas
129
Insert post-WGLC discussion slides here
130
Stop Continue Start
131
An Agile Retrospective
http6lowappnet coreIETF86 2013-03-12-13
Stop
132
Endless new CoAP optionssect instead use RESTful as much as possible
Move general security lifecycle out Looking at theoretical problems
http6lowappnet coreIETF86 2013-03-12-13
Continue
Interops Running code Look at real-world examples and deployments Solve their actual problems
sect Unilateral enhancements eg higher performance congestion control
sect Transports (SMS hellip)sect Make Web linking and Directories more and more usefulsect RESTful Design Paradigms for real-world problems
133
http6lowappnet coreIETF86 2013-03-12-13
Start
Further push into the (browser) web world (HTML5 browser security)
Specific supporting worksect SenMLsect URI work (dev URN hellip)sect Security Processes (next slide)
Spin outsect (We donrsquot really get to decide where this is done)
134
http6lowappnet coreIETF86 2013-03-12-13
Security
Integrate Application Network Group Keyingsect Tunnel-free setup
Donrsquot redo what has been done alreadysect ZigBee IP is finesect But what about other scenarios
Simple REST interfaces for working with keying materials and authorizationsect Start with defining objectives
Object Security for Constrained Nodes135
Re-chartering CoREWhat do we want to do now that wersquore grown up
Zach ShelbyCoRE WG IETF-86 Orlando
What is the scope
bull So we have a protocol and Web Linking what next
bull Keep with what we know besthellip1 Enhancements around CoAP2 New transports for CoAP3 New representations for Web Links4 General application layer solutions
CoRE WG IETF-86 Orlando 2
Enhancements around CoAP
bull Advanced congestion control
CoRE WG IETF-86 Orlando 3
New Transports for CoAP
bull Infrastructure for CoAP over foondash httptoolsietforgiddraft-silverajan-core-
coap-alternative-transports-01txtbull CoAP over SMS
ndash httptoolsietforgiddraft-becker-core-coap-sms-gprs-03txt
ndash OMA Lightweightbull CoAP over TCP
ndash httptoolsietforgiddraft-li-core-coap-payload-length-option-01txt
CoRE WG IETF-86 Orlando 4
New support for Web Links
bull JSON Web Linksndash httptoolsietforgiddraft-bormann-core-links-
json-02txt
2332010 CoRE WG IETF-77 Anaheim 5
General application layer solutions
bull Resource Directoryndash httptoolsietforgiddraft-shelby-core-
resource-directory-05txtndash OMA Lightweight
2332010 CoRE WG IETF-77 Anaheim 6
Proposal ndash RD Based Sleep Tracking (44)
The three time based parameters (SleepDuration TimeSleeping NextSleep) can be based on either an absolute network time (for a time synchronized network) or a relative local time (measured at the local node)
Following the approach of [I-Dietf-core-link-format] and [I-Dshelby-core-resource-directory] sleep parameters for sleepy servers can be stored by the server in the RD and accessed by all interested clients
Examples of using these parameters in a synchronous or asynchronous manner are shown in the I-D
http6lowappnet coreIETF86 2013-03-12-13
We assume people have read the drafts
Meetings serve to advance difficult issues by making good use of face-to-face communications
Note Well Be aware of the IPR principles according to RFC 3979 and its updates
uumlBlue sheetsuumlScribe(s)
96
drar-shy‐iep-shy‐core-shy‐coapsubmiqed13 to13 IESG
2013-shy‐03-shy‐13
97
OMA Lightweight M2M Overview(A new standard using lots of IETF specs including DTLS
CoAP Block Observe Resource Directory SenMLhellip)
Zach ShelbyCoRE WG IETF-86 Orlando
OMA Lightweight M2Mbull Open Mobile Alliance is well known for Device Management (DM)bull OMA Lightweight M2M is a new standard from the alliance
ndash Focused on constrained Cellular and sensor network M2M devicesndash Driven by leading operators and vendors
bull Scopendash Interfaces protocol amp security between Device and Serverndash Object and Resource modelndash Bootstrap Device Access Control Connectivity and Firmware Objects
bull Draft Specifications are availablendash httpmemberopenmobileallianceorgftpPublic_documentsDM
LightweightM2MPermanent_documentsOMA-TS-LightweightM2M-V1_0_0-20130301-Dzip
bull Timelinendash Requirements and Architecture completed 3Q2012ndash Spec ready for Consistency Review 2Q2013ndash Candidate Approval expected 3Q2013
2 CoRE WG IETF-86 Orlando
Architecture
3
Scope of LWM2M
CoRE WG IETF-86 Orlando
Object Model
bull A Client has one or more Object Instancesbull An Object is a collection of Resourcesbull A Resource is an atomic piece of information
ndash Read Written or Executed
bull Resources can have multiple instancesbull Objects and Resources are identified by a
16-bit Integer Instances by an 8-bit Integerbull ObjectsResources are accessed with
simple URIs Object IDObject InstanceResource ID
eg 1213
4 CoRE WG IETF-86 Orlando
CoRE WG IETF-86 Orlando
CoRE Resource Directory
draft-shelby-core-resource-directory-05
Z Shelby C Bormann S Krco
Backgroundbull Not a new concept
ndash think web search engine or any link directorybull Defines the interfaces to a Resource Directorybull Based on Web Linking framework and the CoRE Link Formatbull Generic REST design for use over HTTP and CoAPbull Used by OMA Lightweight M2Mbull Has already been deployed
ndash In traffic monitoring systemsndash In street lighting systemsndash For vehicular asset trackingndash By a major Cellular M2M operator
Changes since -04
bull Restricted Update to parameter updatesbull Added pagination support for the Lookup interfacebull Changed rt= to et= for the registration amp update
interfacebull Added group support
Group Management
bull RD now includes group management featuresbull New Group Function Set
ndash Register a groupbull Group name domain multicast address endpoint members
ndash Remove a groupbull Group lookup using the Lookup Function Set
ndash List registered groupsndash Find the members of a groupndash Find groups with certain endpoints or resources
Registering a Group
EP RD
| |
| - POST rd-groupgp=lights ltgtep=node1 --gt |
| |
| |
| lt---- 201 Created Location rd-group12 ---- |
| |
Req POST coaprdexamplecomrd-groupgp=lights
Payload
ltgtep=node1
ltgtep=node2
Res 201 Created
Location rd-group12
Looking up Group Members
Client RD
| |
| ----- GET rd-lookupepgp=lights1 ----------------------gt |
| |
| |
| lt-- 205 Content ltrdgtd=domain1ltrdgtd=domain2 --------- |
| |
Req GET rd-lookupepgp=lights1
Res 205 Content
ltcoaphostportgtep=node1
ltcoaphostportgtep=node2rdquo
Things for the futurebull Support for JSON representation of Web Links
ndash httptoolsietforgiddraft-bormann-core-links-json-02txtbull Registry for RD registration query parameters
ndash Already OMA Lightweight has defined some new onesbull More examples
Group 3 ldquonew workrdquo(continued)
109
drar-shy‐greevenbosch-shy‐core-shy‐profile-shy‐descripon-shy‐01Bert13 GreevenboschJeroen13 Hoebeke
Isam13 IshaqFloris13 Van13 den13 Abeele
Descripon
bull JSON13 format13 for13 signalling13 the13 servers13 capabilies
bull Signalling13 of13 supported13 opons13 media13 types13 and13 block13 sizendash Other13 items13 can13 be13 added
bull Filtering13 on13 specific13 fields13 through13 URI-shy‐Querybull Link13 hqpdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐profile-shy‐descripon
well-shy‐knownprofile
bull To13 acquire13 profile13 data13 of13 resources13 on13 a13 parcular13 service13 the13 well-shy‐knownprofile13 URI-shy‐path13 is13 introduced
bull For13 example13 to13 get13 all13 informaon13 from13 sensors13 served13 by13 wwwexampleorg13 we13 can13 do13 a13 GET13 to13 coapwwwexampleorgwell-shy‐knownprofile
bull Filtering13 on13 parcular13 resources13 is13 done13 through13 URI-shy‐Queries
Format
bull Currently13 the13 following13 fields13 are13 definedndash ldquopathrdquo13 contains13 the13 URI-shy‐path13 associated13 with13 a13 resource
ndash ldquooprdquo13 a13 numerical13 list13 of13 supported13 opon13 numbers
ndash ldquocfrdquo13 a13 numerical13 list13 of13 supported13 content-shy‐format13 numbers
ndash ldquob1srdquo13 ldquob2srdquo13 supported13 block13 sizes13 for13 Block113 and13 Block213 respecvely
Examplebull On13 the13 right13 is13 an13 example13 of13 a13 camera13 sensor13 at13 coapwwwexampleorgcam13 that13 supports13 the13 Uri-shy‐Host13 (3)13 ETag13 (4)13 Uri-shy‐Port13 (7)13 Uri-shy‐Path13 (11)13 Content-shy‐Format13 (12)13 Token13 (19)13 Block213 (23)13 and13 Proxy-shy‐Uri13 (35)13 opons
bull The13 supported13 content13 formats13 are13 textplain13 (0)13 applicaon13 link-shy‐format13 (40)13 and13 applicaonjson13 (50)
bull The13 supported13 Block213 can13 use13 25613 or13 51213 byte13 blocks
Req13 GET13 coapwwwexampleorgwell-shy‐knownprofile13 Res13 20513 Content13 (applicationjson)13 13 13 13 profile13 13 13 13 13 13 13 13 pathcam13 13 13 13 op[3471112192335]13 13 13 13 13 cf[04050]13 13 13 13 13 b2s[45]13 13 13 13
Filtering13 through13 use13 of13 URI-shy‐Query
bull Filtering13 can13 be13 done13 through13 the13 URI-shy‐Querybull Query13 format13 N=V
ndash N13 is13 a13 profile13 fieldndash V13 is13 the13 desired13 value
bull Examplesndash To13 find13 resources13 that13 support13 content13 format13 ldquoapplicaonjsonrdquo
13 GET13 wwwexampleorgwell-shy‐knownprofilecf=50ndash To13 get13 informaon13 about13 the13 camera
13 GET13 wwwexampleorgwell-shy‐knownprofilepath=cam
Open13 issues
bull Which13 other13 profile13 data13 needs13 signallingndash Content-shy‐type13 for13 different13 methods
bull Fix13 the13 order13 in13 which13 the13 profile13 fields13 must13 appearndash Non-shy‐fixed13 order13 easier13 extensible
bull Inheritance13 of13 a13 profile13 descriponbull Extend13 usage13 to13 signal13 the13 client13 profilebull Integraon13 with13 link13 format
Thank13 youQuesons
drar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval-shy‐00
Bert13 Greevenbosch
Descripon
bull The13 ldquoMinimumRequestInterval13 opon13 can13 be13 used13 to13 indicate13 the13 minimum13 me13 between13 two13 requests13 in13 a13 transacon
bull Originally13 intended13 for13 Block13 but13 also13 usable13 for13 other13 transaconsndash Example13 browsing13 a13 server
bull The13 goal13 is13 to13 reduce13 the13 server13 load13 and13 network13 traffic
bull Link13 hqpsdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval
Usage
bull The13 client13 keeps13 the13 server13 informed13 about13 its13 request13 speed13 through13 inclusion13 of13 the13 ldquoMinimumRequestIntervalrdquo13 opon
bull In13 responses13 the13 server13 fixes13 the13 minimum13 request13 interval13 through13 the13 same13 opon
bull The13 client13 obeys13 the13 speed13 indicated13 by13 the13 server
bull The13 client13 can13 send13 slower13 but13 not13 faster
Advantages
bull The13 server13 has13 means13 to13 limit13 the13 amount13 of13 incoming13 traffic
bull The13 server13 can13 prevent13 to13 become13 overloaded13 with13 too13 many13 tasks
bull The13 server13 does13 not13 need13 arficially13 slow13 down13 the13 client13 by13 sending13 late13 ACKsndash No13 need13 to13 keep13 track13 of13 delayed13 ACKsndash The13 server13 can13 perform13 other13 tasks13 instead
bull Reduced13 network13 traffic
Thank13 youQuesons
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-links-json-02txt
123
RFC 6690 (link-format) documents are somewhat foreign to many web app developerssect would prefer to have them in JSON format
There is no standard way to represent link-format documents in applicationssect but everyone knows how to handle JSON
Define a standard JSON translation for link-format
Itrsquos
not
rock
et
scien
ce
ltsensorsgtct=40title=Sensor Index ltsensorstempgtrt=temperature-cif=sensor ltsensorslightgtrt=light-luxif=sensor lthttpwwwexamplecomsensorst123gt anchor=sensorstemprel=describedby lttgtanchor=sensorstemprel=alternate [hrefsensorsct40titleSensor Index hrefsensorstemprttemperature-cifsensor hrefsensorslightrtlight-luxifsensor hrefhttpwwwexamplecomsensorst123 anchorsensorstempreldescribedby hreftanchorsensorstemprelalternate]
124
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-ipsec-for-coap-00txt
IPsec definitions for CoAP Mostly placeholder at this time Who has implementation experience with this
125
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-cross-reverse-convention-00txt
This draft has two lines of payload(based on a WGLC comment by Cullen Jennings)
coap12344567foobara=3
httpwwwproxycomwellknowncore-translate1234_4567foobara=3
Is that a useful convention to have
126
Insert CI slides here
127
128
0
5
10
15
20
25
30
35
40
10 20 30 40 50 60 70
good
put (
pps)
pps
Goodput vs pps (Econotags)
goodput
[Khattak preliminary]
Congestion Control
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-cocoa-00txt
ldquoadvancedrdquo cc (The draft is just a first shot) Others may have better ideas
129
Insert post-WGLC discussion slides here
130
Stop Continue Start
131
An Agile Retrospective
http6lowappnet coreIETF86 2013-03-12-13
Stop
132
Endless new CoAP optionssect instead use RESTful as much as possible
Move general security lifecycle out Looking at theoretical problems
http6lowappnet coreIETF86 2013-03-12-13
Continue
Interops Running code Look at real-world examples and deployments Solve their actual problems
sect Unilateral enhancements eg higher performance congestion control
sect Transports (SMS hellip)sect Make Web linking and Directories more and more usefulsect RESTful Design Paradigms for real-world problems
133
http6lowappnet coreIETF86 2013-03-12-13
Start
Further push into the (browser) web world (HTML5 browser security)
Specific supporting worksect SenMLsect URI work (dev URN hellip)sect Security Processes (next slide)
Spin outsect (We donrsquot really get to decide where this is done)
134
http6lowappnet coreIETF86 2013-03-12-13
Security
Integrate Application Network Group Keyingsect Tunnel-free setup
Donrsquot redo what has been done alreadysect ZigBee IP is finesect But what about other scenarios
Simple REST interfaces for working with keying materials and authorizationsect Start with defining objectives
Object Security for Constrained Nodes135
Re-chartering CoREWhat do we want to do now that wersquore grown up
Zach ShelbyCoRE WG IETF-86 Orlando
What is the scope
bull So we have a protocol and Web Linking what next
bull Keep with what we know besthellip1 Enhancements around CoAP2 New transports for CoAP3 New representations for Web Links4 General application layer solutions
CoRE WG IETF-86 Orlando 2
Enhancements around CoAP
bull Advanced congestion control
CoRE WG IETF-86 Orlando 3
New Transports for CoAP
bull Infrastructure for CoAP over foondash httptoolsietforgiddraft-silverajan-core-
coap-alternative-transports-01txtbull CoAP over SMS
ndash httptoolsietforgiddraft-becker-core-coap-sms-gprs-03txt
ndash OMA Lightweightbull CoAP over TCP
ndash httptoolsietforgiddraft-li-core-coap-payload-length-option-01txt
CoRE WG IETF-86 Orlando 4
New support for Web Links
bull JSON Web Linksndash httptoolsietforgiddraft-bormann-core-links-
json-02txt
2332010 CoRE WG IETF-77 Anaheim 5
General application layer solutions
bull Resource Directoryndash httptoolsietforgiddraft-shelby-core-
resource-directory-05txtndash OMA Lightweight
2332010 CoRE WG IETF-77 Anaheim 6
http6lowappnet coreIETF86 2013-03-12-13
We assume people have read the drafts
Meetings serve to advance difficult issues by making good use of face-to-face communications
Note Well Be aware of the IPR principles according to RFC 3979 and its updates
uumlBlue sheetsuumlScribe(s)
96
drar-shy‐iep-shy‐core-shy‐coapsubmiqed13 to13 IESG
2013-shy‐03-shy‐13
97
OMA Lightweight M2M Overview(A new standard using lots of IETF specs including DTLS
CoAP Block Observe Resource Directory SenMLhellip)
Zach ShelbyCoRE WG IETF-86 Orlando
OMA Lightweight M2Mbull Open Mobile Alliance is well known for Device Management (DM)bull OMA Lightweight M2M is a new standard from the alliance
ndash Focused on constrained Cellular and sensor network M2M devicesndash Driven by leading operators and vendors
bull Scopendash Interfaces protocol amp security between Device and Serverndash Object and Resource modelndash Bootstrap Device Access Control Connectivity and Firmware Objects
bull Draft Specifications are availablendash httpmemberopenmobileallianceorgftpPublic_documentsDM
LightweightM2MPermanent_documentsOMA-TS-LightweightM2M-V1_0_0-20130301-Dzip
bull Timelinendash Requirements and Architecture completed 3Q2012ndash Spec ready for Consistency Review 2Q2013ndash Candidate Approval expected 3Q2013
2 CoRE WG IETF-86 Orlando
Architecture
3
Scope of LWM2M
CoRE WG IETF-86 Orlando
Object Model
bull A Client has one or more Object Instancesbull An Object is a collection of Resourcesbull A Resource is an atomic piece of information
ndash Read Written or Executed
bull Resources can have multiple instancesbull Objects and Resources are identified by a
16-bit Integer Instances by an 8-bit Integerbull ObjectsResources are accessed with
simple URIs Object IDObject InstanceResource ID
eg 1213
4 CoRE WG IETF-86 Orlando
CoRE WG IETF-86 Orlando
CoRE Resource Directory
draft-shelby-core-resource-directory-05
Z Shelby C Bormann S Krco
Backgroundbull Not a new concept
ndash think web search engine or any link directorybull Defines the interfaces to a Resource Directorybull Based on Web Linking framework and the CoRE Link Formatbull Generic REST design for use over HTTP and CoAPbull Used by OMA Lightweight M2Mbull Has already been deployed
ndash In traffic monitoring systemsndash In street lighting systemsndash For vehicular asset trackingndash By a major Cellular M2M operator
Changes since -04
bull Restricted Update to parameter updatesbull Added pagination support for the Lookup interfacebull Changed rt= to et= for the registration amp update
interfacebull Added group support
Group Management
bull RD now includes group management featuresbull New Group Function Set
ndash Register a groupbull Group name domain multicast address endpoint members
ndash Remove a groupbull Group lookup using the Lookup Function Set
ndash List registered groupsndash Find the members of a groupndash Find groups with certain endpoints or resources
Registering a Group
EP RD
| |
| - POST rd-groupgp=lights ltgtep=node1 --gt |
| |
| |
| lt---- 201 Created Location rd-group12 ---- |
| |
Req POST coaprdexamplecomrd-groupgp=lights
Payload
ltgtep=node1
ltgtep=node2
Res 201 Created
Location rd-group12
Looking up Group Members
Client RD
| |
| ----- GET rd-lookupepgp=lights1 ----------------------gt |
| |
| |
| lt-- 205 Content ltrdgtd=domain1ltrdgtd=domain2 --------- |
| |
Req GET rd-lookupepgp=lights1
Res 205 Content
ltcoaphostportgtep=node1
ltcoaphostportgtep=node2rdquo
Things for the futurebull Support for JSON representation of Web Links
ndash httptoolsietforgiddraft-bormann-core-links-json-02txtbull Registry for RD registration query parameters
ndash Already OMA Lightweight has defined some new onesbull More examples
Group 3 ldquonew workrdquo(continued)
109
drar-shy‐greevenbosch-shy‐core-shy‐profile-shy‐descripon-shy‐01Bert13 GreevenboschJeroen13 Hoebeke
Isam13 IshaqFloris13 Van13 den13 Abeele
Descripon
bull JSON13 format13 for13 signalling13 the13 servers13 capabilies
bull Signalling13 of13 supported13 opons13 media13 types13 and13 block13 sizendash Other13 items13 can13 be13 added
bull Filtering13 on13 specific13 fields13 through13 URI-shy‐Querybull Link13 hqpdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐profile-shy‐descripon
well-shy‐knownprofile
bull To13 acquire13 profile13 data13 of13 resources13 on13 a13 parcular13 service13 the13 well-shy‐knownprofile13 URI-shy‐path13 is13 introduced
bull For13 example13 to13 get13 all13 informaon13 from13 sensors13 served13 by13 wwwexampleorg13 we13 can13 do13 a13 GET13 to13 coapwwwexampleorgwell-shy‐knownprofile
bull Filtering13 on13 parcular13 resources13 is13 done13 through13 URI-shy‐Queries
Format
bull Currently13 the13 following13 fields13 are13 definedndash ldquopathrdquo13 contains13 the13 URI-shy‐path13 associated13 with13 a13 resource
ndash ldquooprdquo13 a13 numerical13 list13 of13 supported13 opon13 numbers
ndash ldquocfrdquo13 a13 numerical13 list13 of13 supported13 content-shy‐format13 numbers
ndash ldquob1srdquo13 ldquob2srdquo13 supported13 block13 sizes13 for13 Block113 and13 Block213 respecvely
Examplebull On13 the13 right13 is13 an13 example13 of13 a13 camera13 sensor13 at13 coapwwwexampleorgcam13 that13 supports13 the13 Uri-shy‐Host13 (3)13 ETag13 (4)13 Uri-shy‐Port13 (7)13 Uri-shy‐Path13 (11)13 Content-shy‐Format13 (12)13 Token13 (19)13 Block213 (23)13 and13 Proxy-shy‐Uri13 (35)13 opons
bull The13 supported13 content13 formats13 are13 textplain13 (0)13 applicaon13 link-shy‐format13 (40)13 and13 applicaonjson13 (50)
bull The13 supported13 Block213 can13 use13 25613 or13 51213 byte13 blocks
Req13 GET13 coapwwwexampleorgwell-shy‐knownprofile13 Res13 20513 Content13 (applicationjson)13 13 13 13 profile13 13 13 13 13 13 13 13 pathcam13 13 13 13 op[3471112192335]13 13 13 13 13 cf[04050]13 13 13 13 13 b2s[45]13 13 13 13
Filtering13 through13 use13 of13 URI-shy‐Query
bull Filtering13 can13 be13 done13 through13 the13 URI-shy‐Querybull Query13 format13 N=V
ndash N13 is13 a13 profile13 fieldndash V13 is13 the13 desired13 value
bull Examplesndash To13 find13 resources13 that13 support13 content13 format13 ldquoapplicaonjsonrdquo
13 GET13 wwwexampleorgwell-shy‐knownprofilecf=50ndash To13 get13 informaon13 about13 the13 camera
13 GET13 wwwexampleorgwell-shy‐knownprofilepath=cam
Open13 issues
bull Which13 other13 profile13 data13 needs13 signallingndash Content-shy‐type13 for13 different13 methods
bull Fix13 the13 order13 in13 which13 the13 profile13 fields13 must13 appearndash Non-shy‐fixed13 order13 easier13 extensible
bull Inheritance13 of13 a13 profile13 descriponbull Extend13 usage13 to13 signal13 the13 client13 profilebull Integraon13 with13 link13 format
Thank13 youQuesons
drar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval-shy‐00
Bert13 Greevenbosch
Descripon
bull The13 ldquoMinimumRequestInterval13 opon13 can13 be13 used13 to13 indicate13 the13 minimum13 me13 between13 two13 requests13 in13 a13 transacon
bull Originally13 intended13 for13 Block13 but13 also13 usable13 for13 other13 transaconsndash Example13 browsing13 a13 server
bull The13 goal13 is13 to13 reduce13 the13 server13 load13 and13 network13 traffic
bull Link13 hqpsdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval
Usage
bull The13 client13 keeps13 the13 server13 informed13 about13 its13 request13 speed13 through13 inclusion13 of13 the13 ldquoMinimumRequestIntervalrdquo13 opon
bull In13 responses13 the13 server13 fixes13 the13 minimum13 request13 interval13 through13 the13 same13 opon
bull The13 client13 obeys13 the13 speed13 indicated13 by13 the13 server
bull The13 client13 can13 send13 slower13 but13 not13 faster
Advantages
bull The13 server13 has13 means13 to13 limit13 the13 amount13 of13 incoming13 traffic
bull The13 server13 can13 prevent13 to13 become13 overloaded13 with13 too13 many13 tasks
bull The13 server13 does13 not13 need13 arficially13 slow13 down13 the13 client13 by13 sending13 late13 ACKsndash No13 need13 to13 keep13 track13 of13 delayed13 ACKsndash The13 server13 can13 perform13 other13 tasks13 instead
bull Reduced13 network13 traffic
Thank13 youQuesons
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-links-json-02txt
123
RFC 6690 (link-format) documents are somewhat foreign to many web app developerssect would prefer to have them in JSON format
There is no standard way to represent link-format documents in applicationssect but everyone knows how to handle JSON
Define a standard JSON translation for link-format
Itrsquos
not
rock
et
scien
ce
ltsensorsgtct=40title=Sensor Index ltsensorstempgtrt=temperature-cif=sensor ltsensorslightgtrt=light-luxif=sensor lthttpwwwexamplecomsensorst123gt anchor=sensorstemprel=describedby lttgtanchor=sensorstemprel=alternate [hrefsensorsct40titleSensor Index hrefsensorstemprttemperature-cifsensor hrefsensorslightrtlight-luxifsensor hrefhttpwwwexamplecomsensorst123 anchorsensorstempreldescribedby hreftanchorsensorstemprelalternate]
124
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-ipsec-for-coap-00txt
IPsec definitions for CoAP Mostly placeholder at this time Who has implementation experience with this
125
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-cross-reverse-convention-00txt
This draft has two lines of payload(based on a WGLC comment by Cullen Jennings)
coap12344567foobara=3
httpwwwproxycomwellknowncore-translate1234_4567foobara=3
Is that a useful convention to have
126
Insert CI slides here
127
128
0
5
10
15
20
25
30
35
40
10 20 30 40 50 60 70
good
put (
pps)
pps
Goodput vs pps (Econotags)
goodput
[Khattak preliminary]
Congestion Control
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-cocoa-00txt
ldquoadvancedrdquo cc (The draft is just a first shot) Others may have better ideas
129
Insert post-WGLC discussion slides here
130
Stop Continue Start
131
An Agile Retrospective
http6lowappnet coreIETF86 2013-03-12-13
Stop
132
Endless new CoAP optionssect instead use RESTful as much as possible
Move general security lifecycle out Looking at theoretical problems
http6lowappnet coreIETF86 2013-03-12-13
Continue
Interops Running code Look at real-world examples and deployments Solve their actual problems
sect Unilateral enhancements eg higher performance congestion control
sect Transports (SMS hellip)sect Make Web linking and Directories more and more usefulsect RESTful Design Paradigms for real-world problems
133
http6lowappnet coreIETF86 2013-03-12-13
Start
Further push into the (browser) web world (HTML5 browser security)
Specific supporting worksect SenMLsect URI work (dev URN hellip)sect Security Processes (next slide)
Spin outsect (We donrsquot really get to decide where this is done)
134
http6lowappnet coreIETF86 2013-03-12-13
Security
Integrate Application Network Group Keyingsect Tunnel-free setup
Donrsquot redo what has been done alreadysect ZigBee IP is finesect But what about other scenarios
Simple REST interfaces for working with keying materials and authorizationsect Start with defining objectives
Object Security for Constrained Nodes135
Re-chartering CoREWhat do we want to do now that wersquore grown up
Zach ShelbyCoRE WG IETF-86 Orlando
What is the scope
bull So we have a protocol and Web Linking what next
bull Keep with what we know besthellip1 Enhancements around CoAP2 New transports for CoAP3 New representations for Web Links4 General application layer solutions
CoRE WG IETF-86 Orlando 2
Enhancements around CoAP
bull Advanced congestion control
CoRE WG IETF-86 Orlando 3
New Transports for CoAP
bull Infrastructure for CoAP over foondash httptoolsietforgiddraft-silverajan-core-
coap-alternative-transports-01txtbull CoAP over SMS
ndash httptoolsietforgiddraft-becker-core-coap-sms-gprs-03txt
ndash OMA Lightweightbull CoAP over TCP
ndash httptoolsietforgiddraft-li-core-coap-payload-length-option-01txt
CoRE WG IETF-86 Orlando 4
New support for Web Links
bull JSON Web Linksndash httptoolsietforgiddraft-bormann-core-links-
json-02txt
2332010 CoRE WG IETF-77 Anaheim 5
General application layer solutions
bull Resource Directoryndash httptoolsietforgiddraft-shelby-core-
resource-directory-05txtndash OMA Lightweight
2332010 CoRE WG IETF-77 Anaheim 6
drar-shy‐iep-shy‐core-shy‐coapsubmiqed13 to13 IESG
2013-shy‐03-shy‐13
97
OMA Lightweight M2M Overview(A new standard using lots of IETF specs including DTLS
CoAP Block Observe Resource Directory SenMLhellip)
Zach ShelbyCoRE WG IETF-86 Orlando
OMA Lightweight M2Mbull Open Mobile Alliance is well known for Device Management (DM)bull OMA Lightweight M2M is a new standard from the alliance
ndash Focused on constrained Cellular and sensor network M2M devicesndash Driven by leading operators and vendors
bull Scopendash Interfaces protocol amp security between Device and Serverndash Object and Resource modelndash Bootstrap Device Access Control Connectivity and Firmware Objects
bull Draft Specifications are availablendash httpmemberopenmobileallianceorgftpPublic_documentsDM
LightweightM2MPermanent_documentsOMA-TS-LightweightM2M-V1_0_0-20130301-Dzip
bull Timelinendash Requirements and Architecture completed 3Q2012ndash Spec ready for Consistency Review 2Q2013ndash Candidate Approval expected 3Q2013
2 CoRE WG IETF-86 Orlando
Architecture
3
Scope of LWM2M
CoRE WG IETF-86 Orlando
Object Model
bull A Client has one or more Object Instancesbull An Object is a collection of Resourcesbull A Resource is an atomic piece of information
ndash Read Written or Executed
bull Resources can have multiple instancesbull Objects and Resources are identified by a
16-bit Integer Instances by an 8-bit Integerbull ObjectsResources are accessed with
simple URIs Object IDObject InstanceResource ID
eg 1213
4 CoRE WG IETF-86 Orlando
CoRE WG IETF-86 Orlando
CoRE Resource Directory
draft-shelby-core-resource-directory-05
Z Shelby C Bormann S Krco
Backgroundbull Not a new concept
ndash think web search engine or any link directorybull Defines the interfaces to a Resource Directorybull Based on Web Linking framework and the CoRE Link Formatbull Generic REST design for use over HTTP and CoAPbull Used by OMA Lightweight M2Mbull Has already been deployed
ndash In traffic monitoring systemsndash In street lighting systemsndash For vehicular asset trackingndash By a major Cellular M2M operator
Changes since -04
bull Restricted Update to parameter updatesbull Added pagination support for the Lookup interfacebull Changed rt= to et= for the registration amp update
interfacebull Added group support
Group Management
bull RD now includes group management featuresbull New Group Function Set
ndash Register a groupbull Group name domain multicast address endpoint members
ndash Remove a groupbull Group lookup using the Lookup Function Set
ndash List registered groupsndash Find the members of a groupndash Find groups with certain endpoints or resources
Registering a Group
EP RD
| |
| - POST rd-groupgp=lights ltgtep=node1 --gt |
| |
| |
| lt---- 201 Created Location rd-group12 ---- |
| |
Req POST coaprdexamplecomrd-groupgp=lights
Payload
ltgtep=node1
ltgtep=node2
Res 201 Created
Location rd-group12
Looking up Group Members
Client RD
| |
| ----- GET rd-lookupepgp=lights1 ----------------------gt |
| |
| |
| lt-- 205 Content ltrdgtd=domain1ltrdgtd=domain2 --------- |
| |
Req GET rd-lookupepgp=lights1
Res 205 Content
ltcoaphostportgtep=node1
ltcoaphostportgtep=node2rdquo
Things for the futurebull Support for JSON representation of Web Links
ndash httptoolsietforgiddraft-bormann-core-links-json-02txtbull Registry for RD registration query parameters
ndash Already OMA Lightweight has defined some new onesbull More examples
Group 3 ldquonew workrdquo(continued)
109
drar-shy‐greevenbosch-shy‐core-shy‐profile-shy‐descripon-shy‐01Bert13 GreevenboschJeroen13 Hoebeke
Isam13 IshaqFloris13 Van13 den13 Abeele
Descripon
bull JSON13 format13 for13 signalling13 the13 servers13 capabilies
bull Signalling13 of13 supported13 opons13 media13 types13 and13 block13 sizendash Other13 items13 can13 be13 added
bull Filtering13 on13 specific13 fields13 through13 URI-shy‐Querybull Link13 hqpdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐profile-shy‐descripon
well-shy‐knownprofile
bull To13 acquire13 profile13 data13 of13 resources13 on13 a13 parcular13 service13 the13 well-shy‐knownprofile13 URI-shy‐path13 is13 introduced
bull For13 example13 to13 get13 all13 informaon13 from13 sensors13 served13 by13 wwwexampleorg13 we13 can13 do13 a13 GET13 to13 coapwwwexampleorgwell-shy‐knownprofile
bull Filtering13 on13 parcular13 resources13 is13 done13 through13 URI-shy‐Queries
Format
bull Currently13 the13 following13 fields13 are13 definedndash ldquopathrdquo13 contains13 the13 URI-shy‐path13 associated13 with13 a13 resource
ndash ldquooprdquo13 a13 numerical13 list13 of13 supported13 opon13 numbers
ndash ldquocfrdquo13 a13 numerical13 list13 of13 supported13 content-shy‐format13 numbers
ndash ldquob1srdquo13 ldquob2srdquo13 supported13 block13 sizes13 for13 Block113 and13 Block213 respecvely
Examplebull On13 the13 right13 is13 an13 example13 of13 a13 camera13 sensor13 at13 coapwwwexampleorgcam13 that13 supports13 the13 Uri-shy‐Host13 (3)13 ETag13 (4)13 Uri-shy‐Port13 (7)13 Uri-shy‐Path13 (11)13 Content-shy‐Format13 (12)13 Token13 (19)13 Block213 (23)13 and13 Proxy-shy‐Uri13 (35)13 opons
bull The13 supported13 content13 formats13 are13 textplain13 (0)13 applicaon13 link-shy‐format13 (40)13 and13 applicaonjson13 (50)
bull The13 supported13 Block213 can13 use13 25613 or13 51213 byte13 blocks
Req13 GET13 coapwwwexampleorgwell-shy‐knownprofile13 Res13 20513 Content13 (applicationjson)13 13 13 13 profile13 13 13 13 13 13 13 13 pathcam13 13 13 13 op[3471112192335]13 13 13 13 13 cf[04050]13 13 13 13 13 b2s[45]13 13 13 13
Filtering13 through13 use13 of13 URI-shy‐Query
bull Filtering13 can13 be13 done13 through13 the13 URI-shy‐Querybull Query13 format13 N=V
ndash N13 is13 a13 profile13 fieldndash V13 is13 the13 desired13 value
bull Examplesndash To13 find13 resources13 that13 support13 content13 format13 ldquoapplicaonjsonrdquo
13 GET13 wwwexampleorgwell-shy‐knownprofilecf=50ndash To13 get13 informaon13 about13 the13 camera
13 GET13 wwwexampleorgwell-shy‐knownprofilepath=cam
Open13 issues
bull Which13 other13 profile13 data13 needs13 signallingndash Content-shy‐type13 for13 different13 methods
bull Fix13 the13 order13 in13 which13 the13 profile13 fields13 must13 appearndash Non-shy‐fixed13 order13 easier13 extensible
bull Inheritance13 of13 a13 profile13 descriponbull Extend13 usage13 to13 signal13 the13 client13 profilebull Integraon13 with13 link13 format
Thank13 youQuesons
drar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval-shy‐00
Bert13 Greevenbosch
Descripon
bull The13 ldquoMinimumRequestInterval13 opon13 can13 be13 used13 to13 indicate13 the13 minimum13 me13 between13 two13 requests13 in13 a13 transacon
bull Originally13 intended13 for13 Block13 but13 also13 usable13 for13 other13 transaconsndash Example13 browsing13 a13 server
bull The13 goal13 is13 to13 reduce13 the13 server13 load13 and13 network13 traffic
bull Link13 hqpsdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval
Usage
bull The13 client13 keeps13 the13 server13 informed13 about13 its13 request13 speed13 through13 inclusion13 of13 the13 ldquoMinimumRequestIntervalrdquo13 opon
bull In13 responses13 the13 server13 fixes13 the13 minimum13 request13 interval13 through13 the13 same13 opon
bull The13 client13 obeys13 the13 speed13 indicated13 by13 the13 server
bull The13 client13 can13 send13 slower13 but13 not13 faster
Advantages
bull The13 server13 has13 means13 to13 limit13 the13 amount13 of13 incoming13 traffic
bull The13 server13 can13 prevent13 to13 become13 overloaded13 with13 too13 many13 tasks
bull The13 server13 does13 not13 need13 arficially13 slow13 down13 the13 client13 by13 sending13 late13 ACKsndash No13 need13 to13 keep13 track13 of13 delayed13 ACKsndash The13 server13 can13 perform13 other13 tasks13 instead
bull Reduced13 network13 traffic
Thank13 youQuesons
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-links-json-02txt
123
RFC 6690 (link-format) documents are somewhat foreign to many web app developerssect would prefer to have them in JSON format
There is no standard way to represent link-format documents in applicationssect but everyone knows how to handle JSON
Define a standard JSON translation for link-format
Itrsquos
not
rock
et
scien
ce
ltsensorsgtct=40title=Sensor Index ltsensorstempgtrt=temperature-cif=sensor ltsensorslightgtrt=light-luxif=sensor lthttpwwwexamplecomsensorst123gt anchor=sensorstemprel=describedby lttgtanchor=sensorstemprel=alternate [hrefsensorsct40titleSensor Index hrefsensorstemprttemperature-cifsensor hrefsensorslightrtlight-luxifsensor hrefhttpwwwexamplecomsensorst123 anchorsensorstempreldescribedby hreftanchorsensorstemprelalternate]
124
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-ipsec-for-coap-00txt
IPsec definitions for CoAP Mostly placeholder at this time Who has implementation experience with this
125
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-cross-reverse-convention-00txt
This draft has two lines of payload(based on a WGLC comment by Cullen Jennings)
coap12344567foobara=3
httpwwwproxycomwellknowncore-translate1234_4567foobara=3
Is that a useful convention to have
126
Insert CI slides here
127
128
0
5
10
15
20
25
30
35
40
10 20 30 40 50 60 70
good
put (
pps)
pps
Goodput vs pps (Econotags)
goodput
[Khattak preliminary]
Congestion Control
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-cocoa-00txt
ldquoadvancedrdquo cc (The draft is just a first shot) Others may have better ideas
129
Insert post-WGLC discussion slides here
130
Stop Continue Start
131
An Agile Retrospective
http6lowappnet coreIETF86 2013-03-12-13
Stop
132
Endless new CoAP optionssect instead use RESTful as much as possible
Move general security lifecycle out Looking at theoretical problems
http6lowappnet coreIETF86 2013-03-12-13
Continue
Interops Running code Look at real-world examples and deployments Solve their actual problems
sect Unilateral enhancements eg higher performance congestion control
sect Transports (SMS hellip)sect Make Web linking and Directories more and more usefulsect RESTful Design Paradigms for real-world problems
133
http6lowappnet coreIETF86 2013-03-12-13
Start
Further push into the (browser) web world (HTML5 browser security)
Specific supporting worksect SenMLsect URI work (dev URN hellip)sect Security Processes (next slide)
Spin outsect (We donrsquot really get to decide where this is done)
134
http6lowappnet coreIETF86 2013-03-12-13
Security
Integrate Application Network Group Keyingsect Tunnel-free setup
Donrsquot redo what has been done alreadysect ZigBee IP is finesect But what about other scenarios
Simple REST interfaces for working with keying materials and authorizationsect Start with defining objectives
Object Security for Constrained Nodes135
Re-chartering CoREWhat do we want to do now that wersquore grown up
Zach ShelbyCoRE WG IETF-86 Orlando
What is the scope
bull So we have a protocol and Web Linking what next
bull Keep with what we know besthellip1 Enhancements around CoAP2 New transports for CoAP3 New representations for Web Links4 General application layer solutions
CoRE WG IETF-86 Orlando 2
Enhancements around CoAP
bull Advanced congestion control
CoRE WG IETF-86 Orlando 3
New Transports for CoAP
bull Infrastructure for CoAP over foondash httptoolsietforgiddraft-silverajan-core-
coap-alternative-transports-01txtbull CoAP over SMS
ndash httptoolsietforgiddraft-becker-core-coap-sms-gprs-03txt
ndash OMA Lightweightbull CoAP over TCP
ndash httptoolsietforgiddraft-li-core-coap-payload-length-option-01txt
CoRE WG IETF-86 Orlando 4
New support for Web Links
bull JSON Web Linksndash httptoolsietforgiddraft-bormann-core-links-
json-02txt
2332010 CoRE WG IETF-77 Anaheim 5
General application layer solutions
bull Resource Directoryndash httptoolsietforgiddraft-shelby-core-
resource-directory-05txtndash OMA Lightweight
2332010 CoRE WG IETF-77 Anaheim 6
OMA Lightweight M2M Overview(A new standard using lots of IETF specs including DTLS
CoAP Block Observe Resource Directory SenMLhellip)
Zach ShelbyCoRE WG IETF-86 Orlando
OMA Lightweight M2Mbull Open Mobile Alliance is well known for Device Management (DM)bull OMA Lightweight M2M is a new standard from the alliance
ndash Focused on constrained Cellular and sensor network M2M devicesndash Driven by leading operators and vendors
bull Scopendash Interfaces protocol amp security between Device and Serverndash Object and Resource modelndash Bootstrap Device Access Control Connectivity and Firmware Objects
bull Draft Specifications are availablendash httpmemberopenmobileallianceorgftpPublic_documentsDM
LightweightM2MPermanent_documentsOMA-TS-LightweightM2M-V1_0_0-20130301-Dzip
bull Timelinendash Requirements and Architecture completed 3Q2012ndash Spec ready for Consistency Review 2Q2013ndash Candidate Approval expected 3Q2013
2 CoRE WG IETF-86 Orlando
Architecture
3
Scope of LWM2M
CoRE WG IETF-86 Orlando
Object Model
bull A Client has one or more Object Instancesbull An Object is a collection of Resourcesbull A Resource is an atomic piece of information
ndash Read Written or Executed
bull Resources can have multiple instancesbull Objects and Resources are identified by a
16-bit Integer Instances by an 8-bit Integerbull ObjectsResources are accessed with
simple URIs Object IDObject InstanceResource ID
eg 1213
4 CoRE WG IETF-86 Orlando
CoRE WG IETF-86 Orlando
CoRE Resource Directory
draft-shelby-core-resource-directory-05
Z Shelby C Bormann S Krco
Backgroundbull Not a new concept
ndash think web search engine or any link directorybull Defines the interfaces to a Resource Directorybull Based on Web Linking framework and the CoRE Link Formatbull Generic REST design for use over HTTP and CoAPbull Used by OMA Lightweight M2Mbull Has already been deployed
ndash In traffic monitoring systemsndash In street lighting systemsndash For vehicular asset trackingndash By a major Cellular M2M operator
Changes since -04
bull Restricted Update to parameter updatesbull Added pagination support for the Lookup interfacebull Changed rt= to et= for the registration amp update
interfacebull Added group support
Group Management
bull RD now includes group management featuresbull New Group Function Set
ndash Register a groupbull Group name domain multicast address endpoint members
ndash Remove a groupbull Group lookup using the Lookup Function Set
ndash List registered groupsndash Find the members of a groupndash Find groups with certain endpoints or resources
Registering a Group
EP RD
| |
| - POST rd-groupgp=lights ltgtep=node1 --gt |
| |
| |
| lt---- 201 Created Location rd-group12 ---- |
| |
Req POST coaprdexamplecomrd-groupgp=lights
Payload
ltgtep=node1
ltgtep=node2
Res 201 Created
Location rd-group12
Looking up Group Members
Client RD
| |
| ----- GET rd-lookupepgp=lights1 ----------------------gt |
| |
| |
| lt-- 205 Content ltrdgtd=domain1ltrdgtd=domain2 --------- |
| |
Req GET rd-lookupepgp=lights1
Res 205 Content
ltcoaphostportgtep=node1
ltcoaphostportgtep=node2rdquo
Things for the futurebull Support for JSON representation of Web Links
ndash httptoolsietforgiddraft-bormann-core-links-json-02txtbull Registry for RD registration query parameters
ndash Already OMA Lightweight has defined some new onesbull More examples
Group 3 ldquonew workrdquo(continued)
109
drar-shy‐greevenbosch-shy‐core-shy‐profile-shy‐descripon-shy‐01Bert13 GreevenboschJeroen13 Hoebeke
Isam13 IshaqFloris13 Van13 den13 Abeele
Descripon
bull JSON13 format13 for13 signalling13 the13 servers13 capabilies
bull Signalling13 of13 supported13 opons13 media13 types13 and13 block13 sizendash Other13 items13 can13 be13 added
bull Filtering13 on13 specific13 fields13 through13 URI-shy‐Querybull Link13 hqpdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐profile-shy‐descripon
well-shy‐knownprofile
bull To13 acquire13 profile13 data13 of13 resources13 on13 a13 parcular13 service13 the13 well-shy‐knownprofile13 URI-shy‐path13 is13 introduced
bull For13 example13 to13 get13 all13 informaon13 from13 sensors13 served13 by13 wwwexampleorg13 we13 can13 do13 a13 GET13 to13 coapwwwexampleorgwell-shy‐knownprofile
bull Filtering13 on13 parcular13 resources13 is13 done13 through13 URI-shy‐Queries
Format
bull Currently13 the13 following13 fields13 are13 definedndash ldquopathrdquo13 contains13 the13 URI-shy‐path13 associated13 with13 a13 resource
ndash ldquooprdquo13 a13 numerical13 list13 of13 supported13 opon13 numbers
ndash ldquocfrdquo13 a13 numerical13 list13 of13 supported13 content-shy‐format13 numbers
ndash ldquob1srdquo13 ldquob2srdquo13 supported13 block13 sizes13 for13 Block113 and13 Block213 respecvely
Examplebull On13 the13 right13 is13 an13 example13 of13 a13 camera13 sensor13 at13 coapwwwexampleorgcam13 that13 supports13 the13 Uri-shy‐Host13 (3)13 ETag13 (4)13 Uri-shy‐Port13 (7)13 Uri-shy‐Path13 (11)13 Content-shy‐Format13 (12)13 Token13 (19)13 Block213 (23)13 and13 Proxy-shy‐Uri13 (35)13 opons
bull The13 supported13 content13 formats13 are13 textplain13 (0)13 applicaon13 link-shy‐format13 (40)13 and13 applicaonjson13 (50)
bull The13 supported13 Block213 can13 use13 25613 or13 51213 byte13 blocks
Req13 GET13 coapwwwexampleorgwell-shy‐knownprofile13 Res13 20513 Content13 (applicationjson)13 13 13 13 profile13 13 13 13 13 13 13 13 pathcam13 13 13 13 op[3471112192335]13 13 13 13 13 cf[04050]13 13 13 13 13 b2s[45]13 13 13 13
Filtering13 through13 use13 of13 URI-shy‐Query
bull Filtering13 can13 be13 done13 through13 the13 URI-shy‐Querybull Query13 format13 N=V
ndash N13 is13 a13 profile13 fieldndash V13 is13 the13 desired13 value
bull Examplesndash To13 find13 resources13 that13 support13 content13 format13 ldquoapplicaonjsonrdquo
13 GET13 wwwexampleorgwell-shy‐knownprofilecf=50ndash To13 get13 informaon13 about13 the13 camera
13 GET13 wwwexampleorgwell-shy‐knownprofilepath=cam
Open13 issues
bull Which13 other13 profile13 data13 needs13 signallingndash Content-shy‐type13 for13 different13 methods
bull Fix13 the13 order13 in13 which13 the13 profile13 fields13 must13 appearndash Non-shy‐fixed13 order13 easier13 extensible
bull Inheritance13 of13 a13 profile13 descriponbull Extend13 usage13 to13 signal13 the13 client13 profilebull Integraon13 with13 link13 format
Thank13 youQuesons
drar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval-shy‐00
Bert13 Greevenbosch
Descripon
bull The13 ldquoMinimumRequestInterval13 opon13 can13 be13 used13 to13 indicate13 the13 minimum13 me13 between13 two13 requests13 in13 a13 transacon
bull Originally13 intended13 for13 Block13 but13 also13 usable13 for13 other13 transaconsndash Example13 browsing13 a13 server
bull The13 goal13 is13 to13 reduce13 the13 server13 load13 and13 network13 traffic
bull Link13 hqpsdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval
Usage
bull The13 client13 keeps13 the13 server13 informed13 about13 its13 request13 speed13 through13 inclusion13 of13 the13 ldquoMinimumRequestIntervalrdquo13 opon
bull In13 responses13 the13 server13 fixes13 the13 minimum13 request13 interval13 through13 the13 same13 opon
bull The13 client13 obeys13 the13 speed13 indicated13 by13 the13 server
bull The13 client13 can13 send13 slower13 but13 not13 faster
Advantages
bull The13 server13 has13 means13 to13 limit13 the13 amount13 of13 incoming13 traffic
bull The13 server13 can13 prevent13 to13 become13 overloaded13 with13 too13 many13 tasks
bull The13 server13 does13 not13 need13 arficially13 slow13 down13 the13 client13 by13 sending13 late13 ACKsndash No13 need13 to13 keep13 track13 of13 delayed13 ACKsndash The13 server13 can13 perform13 other13 tasks13 instead
bull Reduced13 network13 traffic
Thank13 youQuesons
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-links-json-02txt
123
RFC 6690 (link-format) documents are somewhat foreign to many web app developerssect would prefer to have them in JSON format
There is no standard way to represent link-format documents in applicationssect but everyone knows how to handle JSON
Define a standard JSON translation for link-format
Itrsquos
not
rock
et
scien
ce
ltsensorsgtct=40title=Sensor Index ltsensorstempgtrt=temperature-cif=sensor ltsensorslightgtrt=light-luxif=sensor lthttpwwwexamplecomsensorst123gt anchor=sensorstemprel=describedby lttgtanchor=sensorstemprel=alternate [hrefsensorsct40titleSensor Index hrefsensorstemprttemperature-cifsensor hrefsensorslightrtlight-luxifsensor hrefhttpwwwexamplecomsensorst123 anchorsensorstempreldescribedby hreftanchorsensorstemprelalternate]
124
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-ipsec-for-coap-00txt
IPsec definitions for CoAP Mostly placeholder at this time Who has implementation experience with this
125
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-cross-reverse-convention-00txt
This draft has two lines of payload(based on a WGLC comment by Cullen Jennings)
coap12344567foobara=3
httpwwwproxycomwellknowncore-translate1234_4567foobara=3
Is that a useful convention to have
126
Insert CI slides here
127
128
0
5
10
15
20
25
30
35
40
10 20 30 40 50 60 70
good
put (
pps)
pps
Goodput vs pps (Econotags)
goodput
[Khattak preliminary]
Congestion Control
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-cocoa-00txt
ldquoadvancedrdquo cc (The draft is just a first shot) Others may have better ideas
129
Insert post-WGLC discussion slides here
130
Stop Continue Start
131
An Agile Retrospective
http6lowappnet coreIETF86 2013-03-12-13
Stop
132
Endless new CoAP optionssect instead use RESTful as much as possible
Move general security lifecycle out Looking at theoretical problems
http6lowappnet coreIETF86 2013-03-12-13
Continue
Interops Running code Look at real-world examples and deployments Solve their actual problems
sect Unilateral enhancements eg higher performance congestion control
sect Transports (SMS hellip)sect Make Web linking and Directories more and more usefulsect RESTful Design Paradigms for real-world problems
133
http6lowappnet coreIETF86 2013-03-12-13
Start
Further push into the (browser) web world (HTML5 browser security)
Specific supporting worksect SenMLsect URI work (dev URN hellip)sect Security Processes (next slide)
Spin outsect (We donrsquot really get to decide where this is done)
134
http6lowappnet coreIETF86 2013-03-12-13
Security
Integrate Application Network Group Keyingsect Tunnel-free setup
Donrsquot redo what has been done alreadysect ZigBee IP is finesect But what about other scenarios
Simple REST interfaces for working with keying materials and authorizationsect Start with defining objectives
Object Security for Constrained Nodes135
Re-chartering CoREWhat do we want to do now that wersquore grown up
Zach ShelbyCoRE WG IETF-86 Orlando
What is the scope
bull So we have a protocol and Web Linking what next
bull Keep with what we know besthellip1 Enhancements around CoAP2 New transports for CoAP3 New representations for Web Links4 General application layer solutions
CoRE WG IETF-86 Orlando 2
Enhancements around CoAP
bull Advanced congestion control
CoRE WG IETF-86 Orlando 3
New Transports for CoAP
bull Infrastructure for CoAP over foondash httptoolsietforgiddraft-silverajan-core-
coap-alternative-transports-01txtbull CoAP over SMS
ndash httptoolsietforgiddraft-becker-core-coap-sms-gprs-03txt
ndash OMA Lightweightbull CoAP over TCP
ndash httptoolsietforgiddraft-li-core-coap-payload-length-option-01txt
CoRE WG IETF-86 Orlando 4
New support for Web Links
bull JSON Web Linksndash httptoolsietforgiddraft-bormann-core-links-
json-02txt
2332010 CoRE WG IETF-77 Anaheim 5
General application layer solutions
bull Resource Directoryndash httptoolsietforgiddraft-shelby-core-
resource-directory-05txtndash OMA Lightweight
2332010 CoRE WG IETF-77 Anaheim 6
OMA Lightweight M2Mbull Open Mobile Alliance is well known for Device Management (DM)bull OMA Lightweight M2M is a new standard from the alliance
ndash Focused on constrained Cellular and sensor network M2M devicesndash Driven by leading operators and vendors
bull Scopendash Interfaces protocol amp security between Device and Serverndash Object and Resource modelndash Bootstrap Device Access Control Connectivity and Firmware Objects
bull Draft Specifications are availablendash httpmemberopenmobileallianceorgftpPublic_documentsDM
LightweightM2MPermanent_documentsOMA-TS-LightweightM2M-V1_0_0-20130301-Dzip
bull Timelinendash Requirements and Architecture completed 3Q2012ndash Spec ready for Consistency Review 2Q2013ndash Candidate Approval expected 3Q2013
2 CoRE WG IETF-86 Orlando
Architecture
3
Scope of LWM2M
CoRE WG IETF-86 Orlando
Object Model
bull A Client has one or more Object Instancesbull An Object is a collection of Resourcesbull A Resource is an atomic piece of information
ndash Read Written or Executed
bull Resources can have multiple instancesbull Objects and Resources are identified by a
16-bit Integer Instances by an 8-bit Integerbull ObjectsResources are accessed with
simple URIs Object IDObject InstanceResource ID
eg 1213
4 CoRE WG IETF-86 Orlando
CoRE WG IETF-86 Orlando
CoRE Resource Directory
draft-shelby-core-resource-directory-05
Z Shelby C Bormann S Krco
Backgroundbull Not a new concept
ndash think web search engine or any link directorybull Defines the interfaces to a Resource Directorybull Based on Web Linking framework and the CoRE Link Formatbull Generic REST design for use over HTTP and CoAPbull Used by OMA Lightweight M2Mbull Has already been deployed
ndash In traffic monitoring systemsndash In street lighting systemsndash For vehicular asset trackingndash By a major Cellular M2M operator
Changes since -04
bull Restricted Update to parameter updatesbull Added pagination support for the Lookup interfacebull Changed rt= to et= for the registration amp update
interfacebull Added group support
Group Management
bull RD now includes group management featuresbull New Group Function Set
ndash Register a groupbull Group name domain multicast address endpoint members
ndash Remove a groupbull Group lookup using the Lookup Function Set
ndash List registered groupsndash Find the members of a groupndash Find groups with certain endpoints or resources
Registering a Group
EP RD
| |
| - POST rd-groupgp=lights ltgtep=node1 --gt |
| |
| |
| lt---- 201 Created Location rd-group12 ---- |
| |
Req POST coaprdexamplecomrd-groupgp=lights
Payload
ltgtep=node1
ltgtep=node2
Res 201 Created
Location rd-group12
Looking up Group Members
Client RD
| |
| ----- GET rd-lookupepgp=lights1 ----------------------gt |
| |
| |
| lt-- 205 Content ltrdgtd=domain1ltrdgtd=domain2 --------- |
| |
Req GET rd-lookupepgp=lights1
Res 205 Content
ltcoaphostportgtep=node1
ltcoaphostportgtep=node2rdquo
Things for the futurebull Support for JSON representation of Web Links
ndash httptoolsietforgiddraft-bormann-core-links-json-02txtbull Registry for RD registration query parameters
ndash Already OMA Lightweight has defined some new onesbull More examples
Group 3 ldquonew workrdquo(continued)
109
drar-shy‐greevenbosch-shy‐core-shy‐profile-shy‐descripon-shy‐01Bert13 GreevenboschJeroen13 Hoebeke
Isam13 IshaqFloris13 Van13 den13 Abeele
Descripon
bull JSON13 format13 for13 signalling13 the13 servers13 capabilies
bull Signalling13 of13 supported13 opons13 media13 types13 and13 block13 sizendash Other13 items13 can13 be13 added
bull Filtering13 on13 specific13 fields13 through13 URI-shy‐Querybull Link13 hqpdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐profile-shy‐descripon
well-shy‐knownprofile
bull To13 acquire13 profile13 data13 of13 resources13 on13 a13 parcular13 service13 the13 well-shy‐knownprofile13 URI-shy‐path13 is13 introduced
bull For13 example13 to13 get13 all13 informaon13 from13 sensors13 served13 by13 wwwexampleorg13 we13 can13 do13 a13 GET13 to13 coapwwwexampleorgwell-shy‐knownprofile
bull Filtering13 on13 parcular13 resources13 is13 done13 through13 URI-shy‐Queries
Format
bull Currently13 the13 following13 fields13 are13 definedndash ldquopathrdquo13 contains13 the13 URI-shy‐path13 associated13 with13 a13 resource
ndash ldquooprdquo13 a13 numerical13 list13 of13 supported13 opon13 numbers
ndash ldquocfrdquo13 a13 numerical13 list13 of13 supported13 content-shy‐format13 numbers
ndash ldquob1srdquo13 ldquob2srdquo13 supported13 block13 sizes13 for13 Block113 and13 Block213 respecvely
Examplebull On13 the13 right13 is13 an13 example13 of13 a13 camera13 sensor13 at13 coapwwwexampleorgcam13 that13 supports13 the13 Uri-shy‐Host13 (3)13 ETag13 (4)13 Uri-shy‐Port13 (7)13 Uri-shy‐Path13 (11)13 Content-shy‐Format13 (12)13 Token13 (19)13 Block213 (23)13 and13 Proxy-shy‐Uri13 (35)13 opons
bull The13 supported13 content13 formats13 are13 textplain13 (0)13 applicaon13 link-shy‐format13 (40)13 and13 applicaonjson13 (50)
bull The13 supported13 Block213 can13 use13 25613 or13 51213 byte13 blocks
Req13 GET13 coapwwwexampleorgwell-shy‐knownprofile13 Res13 20513 Content13 (applicationjson)13 13 13 13 profile13 13 13 13 13 13 13 13 pathcam13 13 13 13 op[3471112192335]13 13 13 13 13 cf[04050]13 13 13 13 13 b2s[45]13 13 13 13
Filtering13 through13 use13 of13 URI-shy‐Query
bull Filtering13 can13 be13 done13 through13 the13 URI-shy‐Querybull Query13 format13 N=V
ndash N13 is13 a13 profile13 fieldndash V13 is13 the13 desired13 value
bull Examplesndash To13 find13 resources13 that13 support13 content13 format13 ldquoapplicaonjsonrdquo
13 GET13 wwwexampleorgwell-shy‐knownprofilecf=50ndash To13 get13 informaon13 about13 the13 camera
13 GET13 wwwexampleorgwell-shy‐knownprofilepath=cam
Open13 issues
bull Which13 other13 profile13 data13 needs13 signallingndash Content-shy‐type13 for13 different13 methods
bull Fix13 the13 order13 in13 which13 the13 profile13 fields13 must13 appearndash Non-shy‐fixed13 order13 easier13 extensible
bull Inheritance13 of13 a13 profile13 descriponbull Extend13 usage13 to13 signal13 the13 client13 profilebull Integraon13 with13 link13 format
Thank13 youQuesons
drar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval-shy‐00
Bert13 Greevenbosch
Descripon
bull The13 ldquoMinimumRequestInterval13 opon13 can13 be13 used13 to13 indicate13 the13 minimum13 me13 between13 two13 requests13 in13 a13 transacon
bull Originally13 intended13 for13 Block13 but13 also13 usable13 for13 other13 transaconsndash Example13 browsing13 a13 server
bull The13 goal13 is13 to13 reduce13 the13 server13 load13 and13 network13 traffic
bull Link13 hqpsdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval
Usage
bull The13 client13 keeps13 the13 server13 informed13 about13 its13 request13 speed13 through13 inclusion13 of13 the13 ldquoMinimumRequestIntervalrdquo13 opon
bull In13 responses13 the13 server13 fixes13 the13 minimum13 request13 interval13 through13 the13 same13 opon
bull The13 client13 obeys13 the13 speed13 indicated13 by13 the13 server
bull The13 client13 can13 send13 slower13 but13 not13 faster
Advantages
bull The13 server13 has13 means13 to13 limit13 the13 amount13 of13 incoming13 traffic
bull The13 server13 can13 prevent13 to13 become13 overloaded13 with13 too13 many13 tasks
bull The13 server13 does13 not13 need13 arficially13 slow13 down13 the13 client13 by13 sending13 late13 ACKsndash No13 need13 to13 keep13 track13 of13 delayed13 ACKsndash The13 server13 can13 perform13 other13 tasks13 instead
bull Reduced13 network13 traffic
Thank13 youQuesons
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-links-json-02txt
123
RFC 6690 (link-format) documents are somewhat foreign to many web app developerssect would prefer to have them in JSON format
There is no standard way to represent link-format documents in applicationssect but everyone knows how to handle JSON
Define a standard JSON translation for link-format
Itrsquos
not
rock
et
scien
ce
ltsensorsgtct=40title=Sensor Index ltsensorstempgtrt=temperature-cif=sensor ltsensorslightgtrt=light-luxif=sensor lthttpwwwexamplecomsensorst123gt anchor=sensorstemprel=describedby lttgtanchor=sensorstemprel=alternate [hrefsensorsct40titleSensor Index hrefsensorstemprttemperature-cifsensor hrefsensorslightrtlight-luxifsensor hrefhttpwwwexamplecomsensorst123 anchorsensorstempreldescribedby hreftanchorsensorstemprelalternate]
124
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-ipsec-for-coap-00txt
IPsec definitions for CoAP Mostly placeholder at this time Who has implementation experience with this
125
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-cross-reverse-convention-00txt
This draft has two lines of payload(based on a WGLC comment by Cullen Jennings)
coap12344567foobara=3
httpwwwproxycomwellknowncore-translate1234_4567foobara=3
Is that a useful convention to have
126
Insert CI slides here
127
128
0
5
10
15
20
25
30
35
40
10 20 30 40 50 60 70
good
put (
pps)
pps
Goodput vs pps (Econotags)
goodput
[Khattak preliminary]
Congestion Control
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-cocoa-00txt
ldquoadvancedrdquo cc (The draft is just a first shot) Others may have better ideas
129
Insert post-WGLC discussion slides here
130
Stop Continue Start
131
An Agile Retrospective
http6lowappnet coreIETF86 2013-03-12-13
Stop
132
Endless new CoAP optionssect instead use RESTful as much as possible
Move general security lifecycle out Looking at theoretical problems
http6lowappnet coreIETF86 2013-03-12-13
Continue
Interops Running code Look at real-world examples and deployments Solve their actual problems
sect Unilateral enhancements eg higher performance congestion control
sect Transports (SMS hellip)sect Make Web linking and Directories more and more usefulsect RESTful Design Paradigms for real-world problems
133
http6lowappnet coreIETF86 2013-03-12-13
Start
Further push into the (browser) web world (HTML5 browser security)
Specific supporting worksect SenMLsect URI work (dev URN hellip)sect Security Processes (next slide)
Spin outsect (We donrsquot really get to decide where this is done)
134
http6lowappnet coreIETF86 2013-03-12-13
Security
Integrate Application Network Group Keyingsect Tunnel-free setup
Donrsquot redo what has been done alreadysect ZigBee IP is finesect But what about other scenarios
Simple REST interfaces for working with keying materials and authorizationsect Start with defining objectives
Object Security for Constrained Nodes135
Re-chartering CoREWhat do we want to do now that wersquore grown up
Zach ShelbyCoRE WG IETF-86 Orlando
What is the scope
bull So we have a protocol and Web Linking what next
bull Keep with what we know besthellip1 Enhancements around CoAP2 New transports for CoAP3 New representations for Web Links4 General application layer solutions
CoRE WG IETF-86 Orlando 2
Enhancements around CoAP
bull Advanced congestion control
CoRE WG IETF-86 Orlando 3
New Transports for CoAP
bull Infrastructure for CoAP over foondash httptoolsietforgiddraft-silverajan-core-
coap-alternative-transports-01txtbull CoAP over SMS
ndash httptoolsietforgiddraft-becker-core-coap-sms-gprs-03txt
ndash OMA Lightweightbull CoAP over TCP
ndash httptoolsietforgiddraft-li-core-coap-payload-length-option-01txt
CoRE WG IETF-86 Orlando 4
New support for Web Links
bull JSON Web Linksndash httptoolsietforgiddraft-bormann-core-links-
json-02txt
2332010 CoRE WG IETF-77 Anaheim 5
General application layer solutions
bull Resource Directoryndash httptoolsietforgiddraft-shelby-core-
resource-directory-05txtndash OMA Lightweight
2332010 CoRE WG IETF-77 Anaheim 6
Architecture
3
Scope of LWM2M
CoRE WG IETF-86 Orlando
Object Model
bull A Client has one or more Object Instancesbull An Object is a collection of Resourcesbull A Resource is an atomic piece of information
ndash Read Written or Executed
bull Resources can have multiple instancesbull Objects and Resources are identified by a
16-bit Integer Instances by an 8-bit Integerbull ObjectsResources are accessed with
simple URIs Object IDObject InstanceResource ID
eg 1213
4 CoRE WG IETF-86 Orlando
CoRE WG IETF-86 Orlando
CoRE Resource Directory
draft-shelby-core-resource-directory-05
Z Shelby C Bormann S Krco
Backgroundbull Not a new concept
ndash think web search engine or any link directorybull Defines the interfaces to a Resource Directorybull Based on Web Linking framework and the CoRE Link Formatbull Generic REST design for use over HTTP and CoAPbull Used by OMA Lightweight M2Mbull Has already been deployed
ndash In traffic monitoring systemsndash In street lighting systemsndash For vehicular asset trackingndash By a major Cellular M2M operator
Changes since -04
bull Restricted Update to parameter updatesbull Added pagination support for the Lookup interfacebull Changed rt= to et= for the registration amp update
interfacebull Added group support
Group Management
bull RD now includes group management featuresbull New Group Function Set
ndash Register a groupbull Group name domain multicast address endpoint members
ndash Remove a groupbull Group lookup using the Lookup Function Set
ndash List registered groupsndash Find the members of a groupndash Find groups with certain endpoints or resources
Registering a Group
EP RD
| |
| - POST rd-groupgp=lights ltgtep=node1 --gt |
| |
| |
| lt---- 201 Created Location rd-group12 ---- |
| |
Req POST coaprdexamplecomrd-groupgp=lights
Payload
ltgtep=node1
ltgtep=node2
Res 201 Created
Location rd-group12
Looking up Group Members
Client RD
| |
| ----- GET rd-lookupepgp=lights1 ----------------------gt |
| |
| |
| lt-- 205 Content ltrdgtd=domain1ltrdgtd=domain2 --------- |
| |
Req GET rd-lookupepgp=lights1
Res 205 Content
ltcoaphostportgtep=node1
ltcoaphostportgtep=node2rdquo
Things for the futurebull Support for JSON representation of Web Links
ndash httptoolsietforgiddraft-bormann-core-links-json-02txtbull Registry for RD registration query parameters
ndash Already OMA Lightweight has defined some new onesbull More examples
Group 3 ldquonew workrdquo(continued)
109
drar-shy‐greevenbosch-shy‐core-shy‐profile-shy‐descripon-shy‐01Bert13 GreevenboschJeroen13 Hoebeke
Isam13 IshaqFloris13 Van13 den13 Abeele
Descripon
bull JSON13 format13 for13 signalling13 the13 servers13 capabilies
bull Signalling13 of13 supported13 opons13 media13 types13 and13 block13 sizendash Other13 items13 can13 be13 added
bull Filtering13 on13 specific13 fields13 through13 URI-shy‐Querybull Link13 hqpdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐profile-shy‐descripon
well-shy‐knownprofile
bull To13 acquire13 profile13 data13 of13 resources13 on13 a13 parcular13 service13 the13 well-shy‐knownprofile13 URI-shy‐path13 is13 introduced
bull For13 example13 to13 get13 all13 informaon13 from13 sensors13 served13 by13 wwwexampleorg13 we13 can13 do13 a13 GET13 to13 coapwwwexampleorgwell-shy‐knownprofile
bull Filtering13 on13 parcular13 resources13 is13 done13 through13 URI-shy‐Queries
Format
bull Currently13 the13 following13 fields13 are13 definedndash ldquopathrdquo13 contains13 the13 URI-shy‐path13 associated13 with13 a13 resource
ndash ldquooprdquo13 a13 numerical13 list13 of13 supported13 opon13 numbers
ndash ldquocfrdquo13 a13 numerical13 list13 of13 supported13 content-shy‐format13 numbers
ndash ldquob1srdquo13 ldquob2srdquo13 supported13 block13 sizes13 for13 Block113 and13 Block213 respecvely
Examplebull On13 the13 right13 is13 an13 example13 of13 a13 camera13 sensor13 at13 coapwwwexampleorgcam13 that13 supports13 the13 Uri-shy‐Host13 (3)13 ETag13 (4)13 Uri-shy‐Port13 (7)13 Uri-shy‐Path13 (11)13 Content-shy‐Format13 (12)13 Token13 (19)13 Block213 (23)13 and13 Proxy-shy‐Uri13 (35)13 opons
bull The13 supported13 content13 formats13 are13 textplain13 (0)13 applicaon13 link-shy‐format13 (40)13 and13 applicaonjson13 (50)
bull The13 supported13 Block213 can13 use13 25613 or13 51213 byte13 blocks
Req13 GET13 coapwwwexampleorgwell-shy‐knownprofile13 Res13 20513 Content13 (applicationjson)13 13 13 13 profile13 13 13 13 13 13 13 13 pathcam13 13 13 13 op[3471112192335]13 13 13 13 13 cf[04050]13 13 13 13 13 b2s[45]13 13 13 13
Filtering13 through13 use13 of13 URI-shy‐Query
bull Filtering13 can13 be13 done13 through13 the13 URI-shy‐Querybull Query13 format13 N=V
ndash N13 is13 a13 profile13 fieldndash V13 is13 the13 desired13 value
bull Examplesndash To13 find13 resources13 that13 support13 content13 format13 ldquoapplicaonjsonrdquo
13 GET13 wwwexampleorgwell-shy‐knownprofilecf=50ndash To13 get13 informaon13 about13 the13 camera
13 GET13 wwwexampleorgwell-shy‐knownprofilepath=cam
Open13 issues
bull Which13 other13 profile13 data13 needs13 signallingndash Content-shy‐type13 for13 different13 methods
bull Fix13 the13 order13 in13 which13 the13 profile13 fields13 must13 appearndash Non-shy‐fixed13 order13 easier13 extensible
bull Inheritance13 of13 a13 profile13 descriponbull Extend13 usage13 to13 signal13 the13 client13 profilebull Integraon13 with13 link13 format
Thank13 youQuesons
drar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval-shy‐00
Bert13 Greevenbosch
Descripon
bull The13 ldquoMinimumRequestInterval13 opon13 can13 be13 used13 to13 indicate13 the13 minimum13 me13 between13 two13 requests13 in13 a13 transacon
bull Originally13 intended13 for13 Block13 but13 also13 usable13 for13 other13 transaconsndash Example13 browsing13 a13 server
bull The13 goal13 is13 to13 reduce13 the13 server13 load13 and13 network13 traffic
bull Link13 hqpsdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval
Usage
bull The13 client13 keeps13 the13 server13 informed13 about13 its13 request13 speed13 through13 inclusion13 of13 the13 ldquoMinimumRequestIntervalrdquo13 opon
bull In13 responses13 the13 server13 fixes13 the13 minimum13 request13 interval13 through13 the13 same13 opon
bull The13 client13 obeys13 the13 speed13 indicated13 by13 the13 server
bull The13 client13 can13 send13 slower13 but13 not13 faster
Advantages
bull The13 server13 has13 means13 to13 limit13 the13 amount13 of13 incoming13 traffic
bull The13 server13 can13 prevent13 to13 become13 overloaded13 with13 too13 many13 tasks
bull The13 server13 does13 not13 need13 arficially13 slow13 down13 the13 client13 by13 sending13 late13 ACKsndash No13 need13 to13 keep13 track13 of13 delayed13 ACKsndash The13 server13 can13 perform13 other13 tasks13 instead
bull Reduced13 network13 traffic
Thank13 youQuesons
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-links-json-02txt
123
RFC 6690 (link-format) documents are somewhat foreign to many web app developerssect would prefer to have them in JSON format
There is no standard way to represent link-format documents in applicationssect but everyone knows how to handle JSON
Define a standard JSON translation for link-format
Itrsquos
not
rock
et
scien
ce
ltsensorsgtct=40title=Sensor Index ltsensorstempgtrt=temperature-cif=sensor ltsensorslightgtrt=light-luxif=sensor lthttpwwwexamplecomsensorst123gt anchor=sensorstemprel=describedby lttgtanchor=sensorstemprel=alternate [hrefsensorsct40titleSensor Index hrefsensorstemprttemperature-cifsensor hrefsensorslightrtlight-luxifsensor hrefhttpwwwexamplecomsensorst123 anchorsensorstempreldescribedby hreftanchorsensorstemprelalternate]
124
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-ipsec-for-coap-00txt
IPsec definitions for CoAP Mostly placeholder at this time Who has implementation experience with this
125
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-cross-reverse-convention-00txt
This draft has two lines of payload(based on a WGLC comment by Cullen Jennings)
coap12344567foobara=3
httpwwwproxycomwellknowncore-translate1234_4567foobara=3
Is that a useful convention to have
126
Insert CI slides here
127
128
0
5
10
15
20
25
30
35
40
10 20 30 40 50 60 70
good
put (
pps)
pps
Goodput vs pps (Econotags)
goodput
[Khattak preliminary]
Congestion Control
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-cocoa-00txt
ldquoadvancedrdquo cc (The draft is just a first shot) Others may have better ideas
129
Insert post-WGLC discussion slides here
130
Stop Continue Start
131
An Agile Retrospective
http6lowappnet coreIETF86 2013-03-12-13
Stop
132
Endless new CoAP optionssect instead use RESTful as much as possible
Move general security lifecycle out Looking at theoretical problems
http6lowappnet coreIETF86 2013-03-12-13
Continue
Interops Running code Look at real-world examples and deployments Solve their actual problems
sect Unilateral enhancements eg higher performance congestion control
sect Transports (SMS hellip)sect Make Web linking and Directories more and more usefulsect RESTful Design Paradigms for real-world problems
133
http6lowappnet coreIETF86 2013-03-12-13
Start
Further push into the (browser) web world (HTML5 browser security)
Specific supporting worksect SenMLsect URI work (dev URN hellip)sect Security Processes (next slide)
Spin outsect (We donrsquot really get to decide where this is done)
134
http6lowappnet coreIETF86 2013-03-12-13
Security
Integrate Application Network Group Keyingsect Tunnel-free setup
Donrsquot redo what has been done alreadysect ZigBee IP is finesect But what about other scenarios
Simple REST interfaces for working with keying materials and authorizationsect Start with defining objectives
Object Security for Constrained Nodes135
Re-chartering CoREWhat do we want to do now that wersquore grown up
Zach ShelbyCoRE WG IETF-86 Orlando
What is the scope
bull So we have a protocol and Web Linking what next
bull Keep with what we know besthellip1 Enhancements around CoAP2 New transports for CoAP3 New representations for Web Links4 General application layer solutions
CoRE WG IETF-86 Orlando 2
Enhancements around CoAP
bull Advanced congestion control
CoRE WG IETF-86 Orlando 3
New Transports for CoAP
bull Infrastructure for CoAP over foondash httptoolsietforgiddraft-silverajan-core-
coap-alternative-transports-01txtbull CoAP over SMS
ndash httptoolsietforgiddraft-becker-core-coap-sms-gprs-03txt
ndash OMA Lightweightbull CoAP over TCP
ndash httptoolsietforgiddraft-li-core-coap-payload-length-option-01txt
CoRE WG IETF-86 Orlando 4
New support for Web Links
bull JSON Web Linksndash httptoolsietforgiddraft-bormann-core-links-
json-02txt
2332010 CoRE WG IETF-77 Anaheim 5
General application layer solutions
bull Resource Directoryndash httptoolsietforgiddraft-shelby-core-
resource-directory-05txtndash OMA Lightweight
2332010 CoRE WG IETF-77 Anaheim 6
Object Model
bull A Client has one or more Object Instancesbull An Object is a collection of Resourcesbull A Resource is an atomic piece of information
ndash Read Written or Executed
bull Resources can have multiple instancesbull Objects and Resources are identified by a
16-bit Integer Instances by an 8-bit Integerbull ObjectsResources are accessed with
simple URIs Object IDObject InstanceResource ID
eg 1213
4 CoRE WG IETF-86 Orlando
CoRE WG IETF-86 Orlando
CoRE Resource Directory
draft-shelby-core-resource-directory-05
Z Shelby C Bormann S Krco
Backgroundbull Not a new concept
ndash think web search engine or any link directorybull Defines the interfaces to a Resource Directorybull Based on Web Linking framework and the CoRE Link Formatbull Generic REST design for use over HTTP and CoAPbull Used by OMA Lightweight M2Mbull Has already been deployed
ndash In traffic monitoring systemsndash In street lighting systemsndash For vehicular asset trackingndash By a major Cellular M2M operator
Changes since -04
bull Restricted Update to parameter updatesbull Added pagination support for the Lookup interfacebull Changed rt= to et= for the registration amp update
interfacebull Added group support
Group Management
bull RD now includes group management featuresbull New Group Function Set
ndash Register a groupbull Group name domain multicast address endpoint members
ndash Remove a groupbull Group lookup using the Lookup Function Set
ndash List registered groupsndash Find the members of a groupndash Find groups with certain endpoints or resources
Registering a Group
EP RD
| |
| - POST rd-groupgp=lights ltgtep=node1 --gt |
| |
| |
| lt---- 201 Created Location rd-group12 ---- |
| |
Req POST coaprdexamplecomrd-groupgp=lights
Payload
ltgtep=node1
ltgtep=node2
Res 201 Created
Location rd-group12
Looking up Group Members
Client RD
| |
| ----- GET rd-lookupepgp=lights1 ----------------------gt |
| |
| |
| lt-- 205 Content ltrdgtd=domain1ltrdgtd=domain2 --------- |
| |
Req GET rd-lookupepgp=lights1
Res 205 Content
ltcoaphostportgtep=node1
ltcoaphostportgtep=node2rdquo
Things for the futurebull Support for JSON representation of Web Links
ndash httptoolsietforgiddraft-bormann-core-links-json-02txtbull Registry for RD registration query parameters
ndash Already OMA Lightweight has defined some new onesbull More examples
Group 3 ldquonew workrdquo(continued)
109
drar-shy‐greevenbosch-shy‐core-shy‐profile-shy‐descripon-shy‐01Bert13 GreevenboschJeroen13 Hoebeke
Isam13 IshaqFloris13 Van13 den13 Abeele
Descripon
bull JSON13 format13 for13 signalling13 the13 servers13 capabilies
bull Signalling13 of13 supported13 opons13 media13 types13 and13 block13 sizendash Other13 items13 can13 be13 added
bull Filtering13 on13 specific13 fields13 through13 URI-shy‐Querybull Link13 hqpdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐profile-shy‐descripon
well-shy‐knownprofile
bull To13 acquire13 profile13 data13 of13 resources13 on13 a13 parcular13 service13 the13 well-shy‐knownprofile13 URI-shy‐path13 is13 introduced
bull For13 example13 to13 get13 all13 informaon13 from13 sensors13 served13 by13 wwwexampleorg13 we13 can13 do13 a13 GET13 to13 coapwwwexampleorgwell-shy‐knownprofile
bull Filtering13 on13 parcular13 resources13 is13 done13 through13 URI-shy‐Queries
Format
bull Currently13 the13 following13 fields13 are13 definedndash ldquopathrdquo13 contains13 the13 URI-shy‐path13 associated13 with13 a13 resource
ndash ldquooprdquo13 a13 numerical13 list13 of13 supported13 opon13 numbers
ndash ldquocfrdquo13 a13 numerical13 list13 of13 supported13 content-shy‐format13 numbers
ndash ldquob1srdquo13 ldquob2srdquo13 supported13 block13 sizes13 for13 Block113 and13 Block213 respecvely
Examplebull On13 the13 right13 is13 an13 example13 of13 a13 camera13 sensor13 at13 coapwwwexampleorgcam13 that13 supports13 the13 Uri-shy‐Host13 (3)13 ETag13 (4)13 Uri-shy‐Port13 (7)13 Uri-shy‐Path13 (11)13 Content-shy‐Format13 (12)13 Token13 (19)13 Block213 (23)13 and13 Proxy-shy‐Uri13 (35)13 opons
bull The13 supported13 content13 formats13 are13 textplain13 (0)13 applicaon13 link-shy‐format13 (40)13 and13 applicaonjson13 (50)
bull The13 supported13 Block213 can13 use13 25613 or13 51213 byte13 blocks
Req13 GET13 coapwwwexampleorgwell-shy‐knownprofile13 Res13 20513 Content13 (applicationjson)13 13 13 13 profile13 13 13 13 13 13 13 13 pathcam13 13 13 13 op[3471112192335]13 13 13 13 13 cf[04050]13 13 13 13 13 b2s[45]13 13 13 13
Filtering13 through13 use13 of13 URI-shy‐Query
bull Filtering13 can13 be13 done13 through13 the13 URI-shy‐Querybull Query13 format13 N=V
ndash N13 is13 a13 profile13 fieldndash V13 is13 the13 desired13 value
bull Examplesndash To13 find13 resources13 that13 support13 content13 format13 ldquoapplicaonjsonrdquo
13 GET13 wwwexampleorgwell-shy‐knownprofilecf=50ndash To13 get13 informaon13 about13 the13 camera
13 GET13 wwwexampleorgwell-shy‐knownprofilepath=cam
Open13 issues
bull Which13 other13 profile13 data13 needs13 signallingndash Content-shy‐type13 for13 different13 methods
bull Fix13 the13 order13 in13 which13 the13 profile13 fields13 must13 appearndash Non-shy‐fixed13 order13 easier13 extensible
bull Inheritance13 of13 a13 profile13 descriponbull Extend13 usage13 to13 signal13 the13 client13 profilebull Integraon13 with13 link13 format
Thank13 youQuesons
drar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval-shy‐00
Bert13 Greevenbosch
Descripon
bull The13 ldquoMinimumRequestInterval13 opon13 can13 be13 used13 to13 indicate13 the13 minimum13 me13 between13 two13 requests13 in13 a13 transacon
bull Originally13 intended13 for13 Block13 but13 also13 usable13 for13 other13 transaconsndash Example13 browsing13 a13 server
bull The13 goal13 is13 to13 reduce13 the13 server13 load13 and13 network13 traffic
bull Link13 hqpsdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval
Usage
bull The13 client13 keeps13 the13 server13 informed13 about13 its13 request13 speed13 through13 inclusion13 of13 the13 ldquoMinimumRequestIntervalrdquo13 opon
bull In13 responses13 the13 server13 fixes13 the13 minimum13 request13 interval13 through13 the13 same13 opon
bull The13 client13 obeys13 the13 speed13 indicated13 by13 the13 server
bull The13 client13 can13 send13 slower13 but13 not13 faster
Advantages
bull The13 server13 has13 means13 to13 limit13 the13 amount13 of13 incoming13 traffic
bull The13 server13 can13 prevent13 to13 become13 overloaded13 with13 too13 many13 tasks
bull The13 server13 does13 not13 need13 arficially13 slow13 down13 the13 client13 by13 sending13 late13 ACKsndash No13 need13 to13 keep13 track13 of13 delayed13 ACKsndash The13 server13 can13 perform13 other13 tasks13 instead
bull Reduced13 network13 traffic
Thank13 youQuesons
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-links-json-02txt
123
RFC 6690 (link-format) documents are somewhat foreign to many web app developerssect would prefer to have them in JSON format
There is no standard way to represent link-format documents in applicationssect but everyone knows how to handle JSON
Define a standard JSON translation for link-format
Itrsquos
not
rock
et
scien
ce
ltsensorsgtct=40title=Sensor Index ltsensorstempgtrt=temperature-cif=sensor ltsensorslightgtrt=light-luxif=sensor lthttpwwwexamplecomsensorst123gt anchor=sensorstemprel=describedby lttgtanchor=sensorstemprel=alternate [hrefsensorsct40titleSensor Index hrefsensorstemprttemperature-cifsensor hrefsensorslightrtlight-luxifsensor hrefhttpwwwexamplecomsensorst123 anchorsensorstempreldescribedby hreftanchorsensorstemprelalternate]
124
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-ipsec-for-coap-00txt
IPsec definitions for CoAP Mostly placeholder at this time Who has implementation experience with this
125
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-cross-reverse-convention-00txt
This draft has two lines of payload(based on a WGLC comment by Cullen Jennings)
coap12344567foobara=3
httpwwwproxycomwellknowncore-translate1234_4567foobara=3
Is that a useful convention to have
126
Insert CI slides here
127
128
0
5
10
15
20
25
30
35
40
10 20 30 40 50 60 70
good
put (
pps)
pps
Goodput vs pps (Econotags)
goodput
[Khattak preliminary]
Congestion Control
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-cocoa-00txt
ldquoadvancedrdquo cc (The draft is just a first shot) Others may have better ideas
129
Insert post-WGLC discussion slides here
130
Stop Continue Start
131
An Agile Retrospective
http6lowappnet coreIETF86 2013-03-12-13
Stop
132
Endless new CoAP optionssect instead use RESTful as much as possible
Move general security lifecycle out Looking at theoretical problems
http6lowappnet coreIETF86 2013-03-12-13
Continue
Interops Running code Look at real-world examples and deployments Solve their actual problems
sect Unilateral enhancements eg higher performance congestion control
sect Transports (SMS hellip)sect Make Web linking and Directories more and more usefulsect RESTful Design Paradigms for real-world problems
133
http6lowappnet coreIETF86 2013-03-12-13
Start
Further push into the (browser) web world (HTML5 browser security)
Specific supporting worksect SenMLsect URI work (dev URN hellip)sect Security Processes (next slide)
Spin outsect (We donrsquot really get to decide where this is done)
134
http6lowappnet coreIETF86 2013-03-12-13
Security
Integrate Application Network Group Keyingsect Tunnel-free setup
Donrsquot redo what has been done alreadysect ZigBee IP is finesect But what about other scenarios
Simple REST interfaces for working with keying materials and authorizationsect Start with defining objectives
Object Security for Constrained Nodes135
Re-chartering CoREWhat do we want to do now that wersquore grown up
Zach ShelbyCoRE WG IETF-86 Orlando
What is the scope
bull So we have a protocol and Web Linking what next
bull Keep with what we know besthellip1 Enhancements around CoAP2 New transports for CoAP3 New representations for Web Links4 General application layer solutions
CoRE WG IETF-86 Orlando 2
Enhancements around CoAP
bull Advanced congestion control
CoRE WG IETF-86 Orlando 3
New Transports for CoAP
bull Infrastructure for CoAP over foondash httptoolsietforgiddraft-silverajan-core-
coap-alternative-transports-01txtbull CoAP over SMS
ndash httptoolsietforgiddraft-becker-core-coap-sms-gprs-03txt
ndash OMA Lightweightbull CoAP over TCP
ndash httptoolsietforgiddraft-li-core-coap-payload-length-option-01txt
CoRE WG IETF-86 Orlando 4
New support for Web Links
bull JSON Web Linksndash httptoolsietforgiddraft-bormann-core-links-
json-02txt
2332010 CoRE WG IETF-77 Anaheim 5
General application layer solutions
bull Resource Directoryndash httptoolsietforgiddraft-shelby-core-
resource-directory-05txtndash OMA Lightweight
2332010 CoRE WG IETF-77 Anaheim 6
CoRE WG IETF-86 Orlando
CoRE Resource Directory
draft-shelby-core-resource-directory-05
Z Shelby C Bormann S Krco
Backgroundbull Not a new concept
ndash think web search engine or any link directorybull Defines the interfaces to a Resource Directorybull Based on Web Linking framework and the CoRE Link Formatbull Generic REST design for use over HTTP and CoAPbull Used by OMA Lightweight M2Mbull Has already been deployed
ndash In traffic monitoring systemsndash In street lighting systemsndash For vehicular asset trackingndash By a major Cellular M2M operator
Changes since -04
bull Restricted Update to parameter updatesbull Added pagination support for the Lookup interfacebull Changed rt= to et= for the registration amp update
interfacebull Added group support
Group Management
bull RD now includes group management featuresbull New Group Function Set
ndash Register a groupbull Group name domain multicast address endpoint members
ndash Remove a groupbull Group lookup using the Lookup Function Set
ndash List registered groupsndash Find the members of a groupndash Find groups with certain endpoints or resources
Registering a Group
EP RD
| |
| - POST rd-groupgp=lights ltgtep=node1 --gt |
| |
| |
| lt---- 201 Created Location rd-group12 ---- |
| |
Req POST coaprdexamplecomrd-groupgp=lights
Payload
ltgtep=node1
ltgtep=node2
Res 201 Created
Location rd-group12
Looking up Group Members
Client RD
| |
| ----- GET rd-lookupepgp=lights1 ----------------------gt |
| |
| |
| lt-- 205 Content ltrdgtd=domain1ltrdgtd=domain2 --------- |
| |
Req GET rd-lookupepgp=lights1
Res 205 Content
ltcoaphostportgtep=node1
ltcoaphostportgtep=node2rdquo
Things for the futurebull Support for JSON representation of Web Links
ndash httptoolsietforgiddraft-bormann-core-links-json-02txtbull Registry for RD registration query parameters
ndash Already OMA Lightweight has defined some new onesbull More examples
Group 3 ldquonew workrdquo(continued)
109
drar-shy‐greevenbosch-shy‐core-shy‐profile-shy‐descripon-shy‐01Bert13 GreevenboschJeroen13 Hoebeke
Isam13 IshaqFloris13 Van13 den13 Abeele
Descripon
bull JSON13 format13 for13 signalling13 the13 servers13 capabilies
bull Signalling13 of13 supported13 opons13 media13 types13 and13 block13 sizendash Other13 items13 can13 be13 added
bull Filtering13 on13 specific13 fields13 through13 URI-shy‐Querybull Link13 hqpdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐profile-shy‐descripon
well-shy‐knownprofile
bull To13 acquire13 profile13 data13 of13 resources13 on13 a13 parcular13 service13 the13 well-shy‐knownprofile13 URI-shy‐path13 is13 introduced
bull For13 example13 to13 get13 all13 informaon13 from13 sensors13 served13 by13 wwwexampleorg13 we13 can13 do13 a13 GET13 to13 coapwwwexampleorgwell-shy‐knownprofile
bull Filtering13 on13 parcular13 resources13 is13 done13 through13 URI-shy‐Queries
Format
bull Currently13 the13 following13 fields13 are13 definedndash ldquopathrdquo13 contains13 the13 URI-shy‐path13 associated13 with13 a13 resource
ndash ldquooprdquo13 a13 numerical13 list13 of13 supported13 opon13 numbers
ndash ldquocfrdquo13 a13 numerical13 list13 of13 supported13 content-shy‐format13 numbers
ndash ldquob1srdquo13 ldquob2srdquo13 supported13 block13 sizes13 for13 Block113 and13 Block213 respecvely
Examplebull On13 the13 right13 is13 an13 example13 of13 a13 camera13 sensor13 at13 coapwwwexampleorgcam13 that13 supports13 the13 Uri-shy‐Host13 (3)13 ETag13 (4)13 Uri-shy‐Port13 (7)13 Uri-shy‐Path13 (11)13 Content-shy‐Format13 (12)13 Token13 (19)13 Block213 (23)13 and13 Proxy-shy‐Uri13 (35)13 opons
bull The13 supported13 content13 formats13 are13 textplain13 (0)13 applicaon13 link-shy‐format13 (40)13 and13 applicaonjson13 (50)
bull The13 supported13 Block213 can13 use13 25613 or13 51213 byte13 blocks
Req13 GET13 coapwwwexampleorgwell-shy‐knownprofile13 Res13 20513 Content13 (applicationjson)13 13 13 13 profile13 13 13 13 13 13 13 13 pathcam13 13 13 13 op[3471112192335]13 13 13 13 13 cf[04050]13 13 13 13 13 b2s[45]13 13 13 13
Filtering13 through13 use13 of13 URI-shy‐Query
bull Filtering13 can13 be13 done13 through13 the13 URI-shy‐Querybull Query13 format13 N=V
ndash N13 is13 a13 profile13 fieldndash V13 is13 the13 desired13 value
bull Examplesndash To13 find13 resources13 that13 support13 content13 format13 ldquoapplicaonjsonrdquo
13 GET13 wwwexampleorgwell-shy‐knownprofilecf=50ndash To13 get13 informaon13 about13 the13 camera
13 GET13 wwwexampleorgwell-shy‐knownprofilepath=cam
Open13 issues
bull Which13 other13 profile13 data13 needs13 signallingndash Content-shy‐type13 for13 different13 methods
bull Fix13 the13 order13 in13 which13 the13 profile13 fields13 must13 appearndash Non-shy‐fixed13 order13 easier13 extensible
bull Inheritance13 of13 a13 profile13 descriponbull Extend13 usage13 to13 signal13 the13 client13 profilebull Integraon13 with13 link13 format
Thank13 youQuesons
drar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval-shy‐00
Bert13 Greevenbosch
Descripon
bull The13 ldquoMinimumRequestInterval13 opon13 can13 be13 used13 to13 indicate13 the13 minimum13 me13 between13 two13 requests13 in13 a13 transacon
bull Originally13 intended13 for13 Block13 but13 also13 usable13 for13 other13 transaconsndash Example13 browsing13 a13 server
bull The13 goal13 is13 to13 reduce13 the13 server13 load13 and13 network13 traffic
bull Link13 hqpsdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval
Usage
bull The13 client13 keeps13 the13 server13 informed13 about13 its13 request13 speed13 through13 inclusion13 of13 the13 ldquoMinimumRequestIntervalrdquo13 opon
bull In13 responses13 the13 server13 fixes13 the13 minimum13 request13 interval13 through13 the13 same13 opon
bull The13 client13 obeys13 the13 speed13 indicated13 by13 the13 server
bull The13 client13 can13 send13 slower13 but13 not13 faster
Advantages
bull The13 server13 has13 means13 to13 limit13 the13 amount13 of13 incoming13 traffic
bull The13 server13 can13 prevent13 to13 become13 overloaded13 with13 too13 many13 tasks
bull The13 server13 does13 not13 need13 arficially13 slow13 down13 the13 client13 by13 sending13 late13 ACKsndash No13 need13 to13 keep13 track13 of13 delayed13 ACKsndash The13 server13 can13 perform13 other13 tasks13 instead
bull Reduced13 network13 traffic
Thank13 youQuesons
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-links-json-02txt
123
RFC 6690 (link-format) documents are somewhat foreign to many web app developerssect would prefer to have them in JSON format
There is no standard way to represent link-format documents in applicationssect but everyone knows how to handle JSON
Define a standard JSON translation for link-format
Itrsquos
not
rock
et
scien
ce
ltsensorsgtct=40title=Sensor Index ltsensorstempgtrt=temperature-cif=sensor ltsensorslightgtrt=light-luxif=sensor lthttpwwwexamplecomsensorst123gt anchor=sensorstemprel=describedby lttgtanchor=sensorstemprel=alternate [hrefsensorsct40titleSensor Index hrefsensorstemprttemperature-cifsensor hrefsensorslightrtlight-luxifsensor hrefhttpwwwexamplecomsensorst123 anchorsensorstempreldescribedby hreftanchorsensorstemprelalternate]
124
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-ipsec-for-coap-00txt
IPsec definitions for CoAP Mostly placeholder at this time Who has implementation experience with this
125
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-cross-reverse-convention-00txt
This draft has two lines of payload(based on a WGLC comment by Cullen Jennings)
coap12344567foobara=3
httpwwwproxycomwellknowncore-translate1234_4567foobara=3
Is that a useful convention to have
126
Insert CI slides here
127
128
0
5
10
15
20
25
30
35
40
10 20 30 40 50 60 70
good
put (
pps)
pps
Goodput vs pps (Econotags)
goodput
[Khattak preliminary]
Congestion Control
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-cocoa-00txt
ldquoadvancedrdquo cc (The draft is just a first shot) Others may have better ideas
129
Insert post-WGLC discussion slides here
130
Stop Continue Start
131
An Agile Retrospective
http6lowappnet coreIETF86 2013-03-12-13
Stop
132
Endless new CoAP optionssect instead use RESTful as much as possible
Move general security lifecycle out Looking at theoretical problems
http6lowappnet coreIETF86 2013-03-12-13
Continue
Interops Running code Look at real-world examples and deployments Solve their actual problems
sect Unilateral enhancements eg higher performance congestion control
sect Transports (SMS hellip)sect Make Web linking and Directories more and more usefulsect RESTful Design Paradigms for real-world problems
133
http6lowappnet coreIETF86 2013-03-12-13
Start
Further push into the (browser) web world (HTML5 browser security)
Specific supporting worksect SenMLsect URI work (dev URN hellip)sect Security Processes (next slide)
Spin outsect (We donrsquot really get to decide where this is done)
134
http6lowappnet coreIETF86 2013-03-12-13
Security
Integrate Application Network Group Keyingsect Tunnel-free setup
Donrsquot redo what has been done alreadysect ZigBee IP is finesect But what about other scenarios
Simple REST interfaces for working with keying materials and authorizationsect Start with defining objectives
Object Security for Constrained Nodes135
Re-chartering CoREWhat do we want to do now that wersquore grown up
Zach ShelbyCoRE WG IETF-86 Orlando
What is the scope
bull So we have a protocol and Web Linking what next
bull Keep with what we know besthellip1 Enhancements around CoAP2 New transports for CoAP3 New representations for Web Links4 General application layer solutions
CoRE WG IETF-86 Orlando 2
Enhancements around CoAP
bull Advanced congestion control
CoRE WG IETF-86 Orlando 3
New Transports for CoAP
bull Infrastructure for CoAP over foondash httptoolsietforgiddraft-silverajan-core-
coap-alternative-transports-01txtbull CoAP over SMS
ndash httptoolsietforgiddraft-becker-core-coap-sms-gprs-03txt
ndash OMA Lightweightbull CoAP over TCP
ndash httptoolsietforgiddraft-li-core-coap-payload-length-option-01txt
CoRE WG IETF-86 Orlando 4
New support for Web Links
bull JSON Web Linksndash httptoolsietforgiddraft-bormann-core-links-
json-02txt
2332010 CoRE WG IETF-77 Anaheim 5
General application layer solutions
bull Resource Directoryndash httptoolsietforgiddraft-shelby-core-
resource-directory-05txtndash OMA Lightweight
2332010 CoRE WG IETF-77 Anaheim 6
Backgroundbull Not a new concept
ndash think web search engine or any link directorybull Defines the interfaces to a Resource Directorybull Based on Web Linking framework and the CoRE Link Formatbull Generic REST design for use over HTTP and CoAPbull Used by OMA Lightweight M2Mbull Has already been deployed
ndash In traffic monitoring systemsndash In street lighting systemsndash For vehicular asset trackingndash By a major Cellular M2M operator
Changes since -04
bull Restricted Update to parameter updatesbull Added pagination support for the Lookup interfacebull Changed rt= to et= for the registration amp update
interfacebull Added group support
Group Management
bull RD now includes group management featuresbull New Group Function Set
ndash Register a groupbull Group name domain multicast address endpoint members
ndash Remove a groupbull Group lookup using the Lookup Function Set
ndash List registered groupsndash Find the members of a groupndash Find groups with certain endpoints or resources
Registering a Group
EP RD
| |
| - POST rd-groupgp=lights ltgtep=node1 --gt |
| |
| |
| lt---- 201 Created Location rd-group12 ---- |
| |
Req POST coaprdexamplecomrd-groupgp=lights
Payload
ltgtep=node1
ltgtep=node2
Res 201 Created
Location rd-group12
Looking up Group Members
Client RD
| |
| ----- GET rd-lookupepgp=lights1 ----------------------gt |
| |
| |
| lt-- 205 Content ltrdgtd=domain1ltrdgtd=domain2 --------- |
| |
Req GET rd-lookupepgp=lights1
Res 205 Content
ltcoaphostportgtep=node1
ltcoaphostportgtep=node2rdquo
Things for the futurebull Support for JSON representation of Web Links
ndash httptoolsietforgiddraft-bormann-core-links-json-02txtbull Registry for RD registration query parameters
ndash Already OMA Lightweight has defined some new onesbull More examples
Group 3 ldquonew workrdquo(continued)
109
drar-shy‐greevenbosch-shy‐core-shy‐profile-shy‐descripon-shy‐01Bert13 GreevenboschJeroen13 Hoebeke
Isam13 IshaqFloris13 Van13 den13 Abeele
Descripon
bull JSON13 format13 for13 signalling13 the13 servers13 capabilies
bull Signalling13 of13 supported13 opons13 media13 types13 and13 block13 sizendash Other13 items13 can13 be13 added
bull Filtering13 on13 specific13 fields13 through13 URI-shy‐Querybull Link13 hqpdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐profile-shy‐descripon
well-shy‐knownprofile
bull To13 acquire13 profile13 data13 of13 resources13 on13 a13 parcular13 service13 the13 well-shy‐knownprofile13 URI-shy‐path13 is13 introduced
bull For13 example13 to13 get13 all13 informaon13 from13 sensors13 served13 by13 wwwexampleorg13 we13 can13 do13 a13 GET13 to13 coapwwwexampleorgwell-shy‐knownprofile
bull Filtering13 on13 parcular13 resources13 is13 done13 through13 URI-shy‐Queries
Format
bull Currently13 the13 following13 fields13 are13 definedndash ldquopathrdquo13 contains13 the13 URI-shy‐path13 associated13 with13 a13 resource
ndash ldquooprdquo13 a13 numerical13 list13 of13 supported13 opon13 numbers
ndash ldquocfrdquo13 a13 numerical13 list13 of13 supported13 content-shy‐format13 numbers
ndash ldquob1srdquo13 ldquob2srdquo13 supported13 block13 sizes13 for13 Block113 and13 Block213 respecvely
Examplebull On13 the13 right13 is13 an13 example13 of13 a13 camera13 sensor13 at13 coapwwwexampleorgcam13 that13 supports13 the13 Uri-shy‐Host13 (3)13 ETag13 (4)13 Uri-shy‐Port13 (7)13 Uri-shy‐Path13 (11)13 Content-shy‐Format13 (12)13 Token13 (19)13 Block213 (23)13 and13 Proxy-shy‐Uri13 (35)13 opons
bull The13 supported13 content13 formats13 are13 textplain13 (0)13 applicaon13 link-shy‐format13 (40)13 and13 applicaonjson13 (50)
bull The13 supported13 Block213 can13 use13 25613 or13 51213 byte13 blocks
Req13 GET13 coapwwwexampleorgwell-shy‐knownprofile13 Res13 20513 Content13 (applicationjson)13 13 13 13 profile13 13 13 13 13 13 13 13 pathcam13 13 13 13 op[3471112192335]13 13 13 13 13 cf[04050]13 13 13 13 13 b2s[45]13 13 13 13
Filtering13 through13 use13 of13 URI-shy‐Query
bull Filtering13 can13 be13 done13 through13 the13 URI-shy‐Querybull Query13 format13 N=V
ndash N13 is13 a13 profile13 fieldndash V13 is13 the13 desired13 value
bull Examplesndash To13 find13 resources13 that13 support13 content13 format13 ldquoapplicaonjsonrdquo
13 GET13 wwwexampleorgwell-shy‐knownprofilecf=50ndash To13 get13 informaon13 about13 the13 camera
13 GET13 wwwexampleorgwell-shy‐knownprofilepath=cam
Open13 issues
bull Which13 other13 profile13 data13 needs13 signallingndash Content-shy‐type13 for13 different13 methods
bull Fix13 the13 order13 in13 which13 the13 profile13 fields13 must13 appearndash Non-shy‐fixed13 order13 easier13 extensible
bull Inheritance13 of13 a13 profile13 descriponbull Extend13 usage13 to13 signal13 the13 client13 profilebull Integraon13 with13 link13 format
Thank13 youQuesons
drar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval-shy‐00
Bert13 Greevenbosch
Descripon
bull The13 ldquoMinimumRequestInterval13 opon13 can13 be13 used13 to13 indicate13 the13 minimum13 me13 between13 two13 requests13 in13 a13 transacon
bull Originally13 intended13 for13 Block13 but13 also13 usable13 for13 other13 transaconsndash Example13 browsing13 a13 server
bull The13 goal13 is13 to13 reduce13 the13 server13 load13 and13 network13 traffic
bull Link13 hqpsdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval
Usage
bull The13 client13 keeps13 the13 server13 informed13 about13 its13 request13 speed13 through13 inclusion13 of13 the13 ldquoMinimumRequestIntervalrdquo13 opon
bull In13 responses13 the13 server13 fixes13 the13 minimum13 request13 interval13 through13 the13 same13 opon
bull The13 client13 obeys13 the13 speed13 indicated13 by13 the13 server
bull The13 client13 can13 send13 slower13 but13 not13 faster
Advantages
bull The13 server13 has13 means13 to13 limit13 the13 amount13 of13 incoming13 traffic
bull The13 server13 can13 prevent13 to13 become13 overloaded13 with13 too13 many13 tasks
bull The13 server13 does13 not13 need13 arficially13 slow13 down13 the13 client13 by13 sending13 late13 ACKsndash No13 need13 to13 keep13 track13 of13 delayed13 ACKsndash The13 server13 can13 perform13 other13 tasks13 instead
bull Reduced13 network13 traffic
Thank13 youQuesons
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-links-json-02txt
123
RFC 6690 (link-format) documents are somewhat foreign to many web app developerssect would prefer to have them in JSON format
There is no standard way to represent link-format documents in applicationssect but everyone knows how to handle JSON
Define a standard JSON translation for link-format
Itrsquos
not
rock
et
scien
ce
ltsensorsgtct=40title=Sensor Index ltsensorstempgtrt=temperature-cif=sensor ltsensorslightgtrt=light-luxif=sensor lthttpwwwexamplecomsensorst123gt anchor=sensorstemprel=describedby lttgtanchor=sensorstemprel=alternate [hrefsensorsct40titleSensor Index hrefsensorstemprttemperature-cifsensor hrefsensorslightrtlight-luxifsensor hrefhttpwwwexamplecomsensorst123 anchorsensorstempreldescribedby hreftanchorsensorstemprelalternate]
124
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-ipsec-for-coap-00txt
IPsec definitions for CoAP Mostly placeholder at this time Who has implementation experience with this
125
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-cross-reverse-convention-00txt
This draft has two lines of payload(based on a WGLC comment by Cullen Jennings)
coap12344567foobara=3
httpwwwproxycomwellknowncore-translate1234_4567foobara=3
Is that a useful convention to have
126
Insert CI slides here
127
128
0
5
10
15
20
25
30
35
40
10 20 30 40 50 60 70
good
put (
pps)
pps
Goodput vs pps (Econotags)
goodput
[Khattak preliminary]
Congestion Control
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-cocoa-00txt
ldquoadvancedrdquo cc (The draft is just a first shot) Others may have better ideas
129
Insert post-WGLC discussion slides here
130
Stop Continue Start
131
An Agile Retrospective
http6lowappnet coreIETF86 2013-03-12-13
Stop
132
Endless new CoAP optionssect instead use RESTful as much as possible
Move general security lifecycle out Looking at theoretical problems
http6lowappnet coreIETF86 2013-03-12-13
Continue
Interops Running code Look at real-world examples and deployments Solve their actual problems
sect Unilateral enhancements eg higher performance congestion control
sect Transports (SMS hellip)sect Make Web linking and Directories more and more usefulsect RESTful Design Paradigms for real-world problems
133
http6lowappnet coreIETF86 2013-03-12-13
Start
Further push into the (browser) web world (HTML5 browser security)
Specific supporting worksect SenMLsect URI work (dev URN hellip)sect Security Processes (next slide)
Spin outsect (We donrsquot really get to decide where this is done)
134
http6lowappnet coreIETF86 2013-03-12-13
Security
Integrate Application Network Group Keyingsect Tunnel-free setup
Donrsquot redo what has been done alreadysect ZigBee IP is finesect But what about other scenarios
Simple REST interfaces for working with keying materials and authorizationsect Start with defining objectives
Object Security for Constrained Nodes135
Re-chartering CoREWhat do we want to do now that wersquore grown up
Zach ShelbyCoRE WG IETF-86 Orlando
What is the scope
bull So we have a protocol and Web Linking what next
bull Keep with what we know besthellip1 Enhancements around CoAP2 New transports for CoAP3 New representations for Web Links4 General application layer solutions
CoRE WG IETF-86 Orlando 2
Enhancements around CoAP
bull Advanced congestion control
CoRE WG IETF-86 Orlando 3
New Transports for CoAP
bull Infrastructure for CoAP over foondash httptoolsietforgiddraft-silverajan-core-
coap-alternative-transports-01txtbull CoAP over SMS
ndash httptoolsietforgiddraft-becker-core-coap-sms-gprs-03txt
ndash OMA Lightweightbull CoAP over TCP
ndash httptoolsietforgiddraft-li-core-coap-payload-length-option-01txt
CoRE WG IETF-86 Orlando 4
New support for Web Links
bull JSON Web Linksndash httptoolsietforgiddraft-bormann-core-links-
json-02txt
2332010 CoRE WG IETF-77 Anaheim 5
General application layer solutions
bull Resource Directoryndash httptoolsietforgiddraft-shelby-core-
resource-directory-05txtndash OMA Lightweight
2332010 CoRE WG IETF-77 Anaheim 6
Changes since -04
bull Restricted Update to parameter updatesbull Added pagination support for the Lookup interfacebull Changed rt= to et= for the registration amp update
interfacebull Added group support
Group Management
bull RD now includes group management featuresbull New Group Function Set
ndash Register a groupbull Group name domain multicast address endpoint members
ndash Remove a groupbull Group lookup using the Lookup Function Set
ndash List registered groupsndash Find the members of a groupndash Find groups with certain endpoints or resources
Registering a Group
EP RD
| |
| - POST rd-groupgp=lights ltgtep=node1 --gt |
| |
| |
| lt---- 201 Created Location rd-group12 ---- |
| |
Req POST coaprdexamplecomrd-groupgp=lights
Payload
ltgtep=node1
ltgtep=node2
Res 201 Created
Location rd-group12
Looking up Group Members
Client RD
| |
| ----- GET rd-lookupepgp=lights1 ----------------------gt |
| |
| |
| lt-- 205 Content ltrdgtd=domain1ltrdgtd=domain2 --------- |
| |
Req GET rd-lookupepgp=lights1
Res 205 Content
ltcoaphostportgtep=node1
ltcoaphostportgtep=node2rdquo
Things for the futurebull Support for JSON representation of Web Links
ndash httptoolsietforgiddraft-bormann-core-links-json-02txtbull Registry for RD registration query parameters
ndash Already OMA Lightweight has defined some new onesbull More examples
Group 3 ldquonew workrdquo(continued)
109
drar-shy‐greevenbosch-shy‐core-shy‐profile-shy‐descripon-shy‐01Bert13 GreevenboschJeroen13 Hoebeke
Isam13 IshaqFloris13 Van13 den13 Abeele
Descripon
bull JSON13 format13 for13 signalling13 the13 servers13 capabilies
bull Signalling13 of13 supported13 opons13 media13 types13 and13 block13 sizendash Other13 items13 can13 be13 added
bull Filtering13 on13 specific13 fields13 through13 URI-shy‐Querybull Link13 hqpdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐profile-shy‐descripon
well-shy‐knownprofile
bull To13 acquire13 profile13 data13 of13 resources13 on13 a13 parcular13 service13 the13 well-shy‐knownprofile13 URI-shy‐path13 is13 introduced
bull For13 example13 to13 get13 all13 informaon13 from13 sensors13 served13 by13 wwwexampleorg13 we13 can13 do13 a13 GET13 to13 coapwwwexampleorgwell-shy‐knownprofile
bull Filtering13 on13 parcular13 resources13 is13 done13 through13 URI-shy‐Queries
Format
bull Currently13 the13 following13 fields13 are13 definedndash ldquopathrdquo13 contains13 the13 URI-shy‐path13 associated13 with13 a13 resource
ndash ldquooprdquo13 a13 numerical13 list13 of13 supported13 opon13 numbers
ndash ldquocfrdquo13 a13 numerical13 list13 of13 supported13 content-shy‐format13 numbers
ndash ldquob1srdquo13 ldquob2srdquo13 supported13 block13 sizes13 for13 Block113 and13 Block213 respecvely
Examplebull On13 the13 right13 is13 an13 example13 of13 a13 camera13 sensor13 at13 coapwwwexampleorgcam13 that13 supports13 the13 Uri-shy‐Host13 (3)13 ETag13 (4)13 Uri-shy‐Port13 (7)13 Uri-shy‐Path13 (11)13 Content-shy‐Format13 (12)13 Token13 (19)13 Block213 (23)13 and13 Proxy-shy‐Uri13 (35)13 opons
bull The13 supported13 content13 formats13 are13 textplain13 (0)13 applicaon13 link-shy‐format13 (40)13 and13 applicaonjson13 (50)
bull The13 supported13 Block213 can13 use13 25613 or13 51213 byte13 blocks
Req13 GET13 coapwwwexampleorgwell-shy‐knownprofile13 Res13 20513 Content13 (applicationjson)13 13 13 13 profile13 13 13 13 13 13 13 13 pathcam13 13 13 13 op[3471112192335]13 13 13 13 13 cf[04050]13 13 13 13 13 b2s[45]13 13 13 13
Filtering13 through13 use13 of13 URI-shy‐Query
bull Filtering13 can13 be13 done13 through13 the13 URI-shy‐Querybull Query13 format13 N=V
ndash N13 is13 a13 profile13 fieldndash V13 is13 the13 desired13 value
bull Examplesndash To13 find13 resources13 that13 support13 content13 format13 ldquoapplicaonjsonrdquo
13 GET13 wwwexampleorgwell-shy‐knownprofilecf=50ndash To13 get13 informaon13 about13 the13 camera
13 GET13 wwwexampleorgwell-shy‐knownprofilepath=cam
Open13 issues
bull Which13 other13 profile13 data13 needs13 signallingndash Content-shy‐type13 for13 different13 methods
bull Fix13 the13 order13 in13 which13 the13 profile13 fields13 must13 appearndash Non-shy‐fixed13 order13 easier13 extensible
bull Inheritance13 of13 a13 profile13 descriponbull Extend13 usage13 to13 signal13 the13 client13 profilebull Integraon13 with13 link13 format
Thank13 youQuesons
drar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval-shy‐00
Bert13 Greevenbosch
Descripon
bull The13 ldquoMinimumRequestInterval13 opon13 can13 be13 used13 to13 indicate13 the13 minimum13 me13 between13 two13 requests13 in13 a13 transacon
bull Originally13 intended13 for13 Block13 but13 also13 usable13 for13 other13 transaconsndash Example13 browsing13 a13 server
bull The13 goal13 is13 to13 reduce13 the13 server13 load13 and13 network13 traffic
bull Link13 hqpsdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval
Usage
bull The13 client13 keeps13 the13 server13 informed13 about13 its13 request13 speed13 through13 inclusion13 of13 the13 ldquoMinimumRequestIntervalrdquo13 opon
bull In13 responses13 the13 server13 fixes13 the13 minimum13 request13 interval13 through13 the13 same13 opon
bull The13 client13 obeys13 the13 speed13 indicated13 by13 the13 server
bull The13 client13 can13 send13 slower13 but13 not13 faster
Advantages
bull The13 server13 has13 means13 to13 limit13 the13 amount13 of13 incoming13 traffic
bull The13 server13 can13 prevent13 to13 become13 overloaded13 with13 too13 many13 tasks
bull The13 server13 does13 not13 need13 arficially13 slow13 down13 the13 client13 by13 sending13 late13 ACKsndash No13 need13 to13 keep13 track13 of13 delayed13 ACKsndash The13 server13 can13 perform13 other13 tasks13 instead
bull Reduced13 network13 traffic
Thank13 youQuesons
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-links-json-02txt
123
RFC 6690 (link-format) documents are somewhat foreign to many web app developerssect would prefer to have them in JSON format
There is no standard way to represent link-format documents in applicationssect but everyone knows how to handle JSON
Define a standard JSON translation for link-format
Itrsquos
not
rock
et
scien
ce
ltsensorsgtct=40title=Sensor Index ltsensorstempgtrt=temperature-cif=sensor ltsensorslightgtrt=light-luxif=sensor lthttpwwwexamplecomsensorst123gt anchor=sensorstemprel=describedby lttgtanchor=sensorstemprel=alternate [hrefsensorsct40titleSensor Index hrefsensorstemprttemperature-cifsensor hrefsensorslightrtlight-luxifsensor hrefhttpwwwexamplecomsensorst123 anchorsensorstempreldescribedby hreftanchorsensorstemprelalternate]
124
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-ipsec-for-coap-00txt
IPsec definitions for CoAP Mostly placeholder at this time Who has implementation experience with this
125
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-cross-reverse-convention-00txt
This draft has two lines of payload(based on a WGLC comment by Cullen Jennings)
coap12344567foobara=3
httpwwwproxycomwellknowncore-translate1234_4567foobara=3
Is that a useful convention to have
126
Insert CI slides here
127
128
0
5
10
15
20
25
30
35
40
10 20 30 40 50 60 70
good
put (
pps)
pps
Goodput vs pps (Econotags)
goodput
[Khattak preliminary]
Congestion Control
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-cocoa-00txt
ldquoadvancedrdquo cc (The draft is just a first shot) Others may have better ideas
129
Insert post-WGLC discussion slides here
130
Stop Continue Start
131
An Agile Retrospective
http6lowappnet coreIETF86 2013-03-12-13
Stop
132
Endless new CoAP optionssect instead use RESTful as much as possible
Move general security lifecycle out Looking at theoretical problems
http6lowappnet coreIETF86 2013-03-12-13
Continue
Interops Running code Look at real-world examples and deployments Solve their actual problems
sect Unilateral enhancements eg higher performance congestion control
sect Transports (SMS hellip)sect Make Web linking and Directories more and more usefulsect RESTful Design Paradigms for real-world problems
133
http6lowappnet coreIETF86 2013-03-12-13
Start
Further push into the (browser) web world (HTML5 browser security)
Specific supporting worksect SenMLsect URI work (dev URN hellip)sect Security Processes (next slide)
Spin outsect (We donrsquot really get to decide where this is done)
134
http6lowappnet coreIETF86 2013-03-12-13
Security
Integrate Application Network Group Keyingsect Tunnel-free setup
Donrsquot redo what has been done alreadysect ZigBee IP is finesect But what about other scenarios
Simple REST interfaces for working with keying materials and authorizationsect Start with defining objectives
Object Security for Constrained Nodes135
Re-chartering CoREWhat do we want to do now that wersquore grown up
Zach ShelbyCoRE WG IETF-86 Orlando
What is the scope
bull So we have a protocol and Web Linking what next
bull Keep with what we know besthellip1 Enhancements around CoAP2 New transports for CoAP3 New representations for Web Links4 General application layer solutions
CoRE WG IETF-86 Orlando 2
Enhancements around CoAP
bull Advanced congestion control
CoRE WG IETF-86 Orlando 3
New Transports for CoAP
bull Infrastructure for CoAP over foondash httptoolsietforgiddraft-silverajan-core-
coap-alternative-transports-01txtbull CoAP over SMS
ndash httptoolsietforgiddraft-becker-core-coap-sms-gprs-03txt
ndash OMA Lightweightbull CoAP over TCP
ndash httptoolsietforgiddraft-li-core-coap-payload-length-option-01txt
CoRE WG IETF-86 Orlando 4
New support for Web Links
bull JSON Web Linksndash httptoolsietforgiddraft-bormann-core-links-
json-02txt
2332010 CoRE WG IETF-77 Anaheim 5
General application layer solutions
bull Resource Directoryndash httptoolsietforgiddraft-shelby-core-
resource-directory-05txtndash OMA Lightweight
2332010 CoRE WG IETF-77 Anaheim 6
Group Management
bull RD now includes group management featuresbull New Group Function Set
ndash Register a groupbull Group name domain multicast address endpoint members
ndash Remove a groupbull Group lookup using the Lookup Function Set
ndash List registered groupsndash Find the members of a groupndash Find groups with certain endpoints or resources
Registering a Group
EP RD
| |
| - POST rd-groupgp=lights ltgtep=node1 --gt |
| |
| |
| lt---- 201 Created Location rd-group12 ---- |
| |
Req POST coaprdexamplecomrd-groupgp=lights
Payload
ltgtep=node1
ltgtep=node2
Res 201 Created
Location rd-group12
Looking up Group Members
Client RD
| |
| ----- GET rd-lookupepgp=lights1 ----------------------gt |
| |
| |
| lt-- 205 Content ltrdgtd=domain1ltrdgtd=domain2 --------- |
| |
Req GET rd-lookupepgp=lights1
Res 205 Content
ltcoaphostportgtep=node1
ltcoaphostportgtep=node2rdquo
Things for the futurebull Support for JSON representation of Web Links
ndash httptoolsietforgiddraft-bormann-core-links-json-02txtbull Registry for RD registration query parameters
ndash Already OMA Lightweight has defined some new onesbull More examples
Group 3 ldquonew workrdquo(continued)
109
drar-shy‐greevenbosch-shy‐core-shy‐profile-shy‐descripon-shy‐01Bert13 GreevenboschJeroen13 Hoebeke
Isam13 IshaqFloris13 Van13 den13 Abeele
Descripon
bull JSON13 format13 for13 signalling13 the13 servers13 capabilies
bull Signalling13 of13 supported13 opons13 media13 types13 and13 block13 sizendash Other13 items13 can13 be13 added
bull Filtering13 on13 specific13 fields13 through13 URI-shy‐Querybull Link13 hqpdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐profile-shy‐descripon
well-shy‐knownprofile
bull To13 acquire13 profile13 data13 of13 resources13 on13 a13 parcular13 service13 the13 well-shy‐knownprofile13 URI-shy‐path13 is13 introduced
bull For13 example13 to13 get13 all13 informaon13 from13 sensors13 served13 by13 wwwexampleorg13 we13 can13 do13 a13 GET13 to13 coapwwwexampleorgwell-shy‐knownprofile
bull Filtering13 on13 parcular13 resources13 is13 done13 through13 URI-shy‐Queries
Format
bull Currently13 the13 following13 fields13 are13 definedndash ldquopathrdquo13 contains13 the13 URI-shy‐path13 associated13 with13 a13 resource
ndash ldquooprdquo13 a13 numerical13 list13 of13 supported13 opon13 numbers
ndash ldquocfrdquo13 a13 numerical13 list13 of13 supported13 content-shy‐format13 numbers
ndash ldquob1srdquo13 ldquob2srdquo13 supported13 block13 sizes13 for13 Block113 and13 Block213 respecvely
Examplebull On13 the13 right13 is13 an13 example13 of13 a13 camera13 sensor13 at13 coapwwwexampleorgcam13 that13 supports13 the13 Uri-shy‐Host13 (3)13 ETag13 (4)13 Uri-shy‐Port13 (7)13 Uri-shy‐Path13 (11)13 Content-shy‐Format13 (12)13 Token13 (19)13 Block213 (23)13 and13 Proxy-shy‐Uri13 (35)13 opons
bull The13 supported13 content13 formats13 are13 textplain13 (0)13 applicaon13 link-shy‐format13 (40)13 and13 applicaonjson13 (50)
bull The13 supported13 Block213 can13 use13 25613 or13 51213 byte13 blocks
Req13 GET13 coapwwwexampleorgwell-shy‐knownprofile13 Res13 20513 Content13 (applicationjson)13 13 13 13 profile13 13 13 13 13 13 13 13 pathcam13 13 13 13 op[3471112192335]13 13 13 13 13 cf[04050]13 13 13 13 13 b2s[45]13 13 13 13
Filtering13 through13 use13 of13 URI-shy‐Query
bull Filtering13 can13 be13 done13 through13 the13 URI-shy‐Querybull Query13 format13 N=V
ndash N13 is13 a13 profile13 fieldndash V13 is13 the13 desired13 value
bull Examplesndash To13 find13 resources13 that13 support13 content13 format13 ldquoapplicaonjsonrdquo
13 GET13 wwwexampleorgwell-shy‐knownprofilecf=50ndash To13 get13 informaon13 about13 the13 camera
13 GET13 wwwexampleorgwell-shy‐knownprofilepath=cam
Open13 issues
bull Which13 other13 profile13 data13 needs13 signallingndash Content-shy‐type13 for13 different13 methods
bull Fix13 the13 order13 in13 which13 the13 profile13 fields13 must13 appearndash Non-shy‐fixed13 order13 easier13 extensible
bull Inheritance13 of13 a13 profile13 descriponbull Extend13 usage13 to13 signal13 the13 client13 profilebull Integraon13 with13 link13 format
Thank13 youQuesons
drar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval-shy‐00
Bert13 Greevenbosch
Descripon
bull The13 ldquoMinimumRequestInterval13 opon13 can13 be13 used13 to13 indicate13 the13 minimum13 me13 between13 two13 requests13 in13 a13 transacon
bull Originally13 intended13 for13 Block13 but13 also13 usable13 for13 other13 transaconsndash Example13 browsing13 a13 server
bull The13 goal13 is13 to13 reduce13 the13 server13 load13 and13 network13 traffic
bull Link13 hqpsdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval
Usage
bull The13 client13 keeps13 the13 server13 informed13 about13 its13 request13 speed13 through13 inclusion13 of13 the13 ldquoMinimumRequestIntervalrdquo13 opon
bull In13 responses13 the13 server13 fixes13 the13 minimum13 request13 interval13 through13 the13 same13 opon
bull The13 client13 obeys13 the13 speed13 indicated13 by13 the13 server
bull The13 client13 can13 send13 slower13 but13 not13 faster
Advantages
bull The13 server13 has13 means13 to13 limit13 the13 amount13 of13 incoming13 traffic
bull The13 server13 can13 prevent13 to13 become13 overloaded13 with13 too13 many13 tasks
bull The13 server13 does13 not13 need13 arficially13 slow13 down13 the13 client13 by13 sending13 late13 ACKsndash No13 need13 to13 keep13 track13 of13 delayed13 ACKsndash The13 server13 can13 perform13 other13 tasks13 instead
bull Reduced13 network13 traffic
Thank13 youQuesons
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-links-json-02txt
123
RFC 6690 (link-format) documents are somewhat foreign to many web app developerssect would prefer to have them in JSON format
There is no standard way to represent link-format documents in applicationssect but everyone knows how to handle JSON
Define a standard JSON translation for link-format
Itrsquos
not
rock
et
scien
ce
ltsensorsgtct=40title=Sensor Index ltsensorstempgtrt=temperature-cif=sensor ltsensorslightgtrt=light-luxif=sensor lthttpwwwexamplecomsensorst123gt anchor=sensorstemprel=describedby lttgtanchor=sensorstemprel=alternate [hrefsensorsct40titleSensor Index hrefsensorstemprttemperature-cifsensor hrefsensorslightrtlight-luxifsensor hrefhttpwwwexamplecomsensorst123 anchorsensorstempreldescribedby hreftanchorsensorstemprelalternate]
124
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-ipsec-for-coap-00txt
IPsec definitions for CoAP Mostly placeholder at this time Who has implementation experience with this
125
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-cross-reverse-convention-00txt
This draft has two lines of payload(based on a WGLC comment by Cullen Jennings)
coap12344567foobara=3
httpwwwproxycomwellknowncore-translate1234_4567foobara=3
Is that a useful convention to have
126
Insert CI slides here
127
128
0
5
10
15
20
25
30
35
40
10 20 30 40 50 60 70
good
put (
pps)
pps
Goodput vs pps (Econotags)
goodput
[Khattak preliminary]
Congestion Control
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-cocoa-00txt
ldquoadvancedrdquo cc (The draft is just a first shot) Others may have better ideas
129
Insert post-WGLC discussion slides here
130
Stop Continue Start
131
An Agile Retrospective
http6lowappnet coreIETF86 2013-03-12-13
Stop
132
Endless new CoAP optionssect instead use RESTful as much as possible
Move general security lifecycle out Looking at theoretical problems
http6lowappnet coreIETF86 2013-03-12-13
Continue
Interops Running code Look at real-world examples and deployments Solve their actual problems
sect Unilateral enhancements eg higher performance congestion control
sect Transports (SMS hellip)sect Make Web linking and Directories more and more usefulsect RESTful Design Paradigms for real-world problems
133
http6lowappnet coreIETF86 2013-03-12-13
Start
Further push into the (browser) web world (HTML5 browser security)
Specific supporting worksect SenMLsect URI work (dev URN hellip)sect Security Processes (next slide)
Spin outsect (We donrsquot really get to decide where this is done)
134
http6lowappnet coreIETF86 2013-03-12-13
Security
Integrate Application Network Group Keyingsect Tunnel-free setup
Donrsquot redo what has been done alreadysect ZigBee IP is finesect But what about other scenarios
Simple REST interfaces for working with keying materials and authorizationsect Start with defining objectives
Object Security for Constrained Nodes135
Re-chartering CoREWhat do we want to do now that wersquore grown up
Zach ShelbyCoRE WG IETF-86 Orlando
What is the scope
bull So we have a protocol and Web Linking what next
bull Keep with what we know besthellip1 Enhancements around CoAP2 New transports for CoAP3 New representations for Web Links4 General application layer solutions
CoRE WG IETF-86 Orlando 2
Enhancements around CoAP
bull Advanced congestion control
CoRE WG IETF-86 Orlando 3
New Transports for CoAP
bull Infrastructure for CoAP over foondash httptoolsietforgiddraft-silverajan-core-
coap-alternative-transports-01txtbull CoAP over SMS
ndash httptoolsietforgiddraft-becker-core-coap-sms-gprs-03txt
ndash OMA Lightweightbull CoAP over TCP
ndash httptoolsietforgiddraft-li-core-coap-payload-length-option-01txt
CoRE WG IETF-86 Orlando 4
New support for Web Links
bull JSON Web Linksndash httptoolsietforgiddraft-bormann-core-links-
json-02txt
2332010 CoRE WG IETF-77 Anaheim 5
General application layer solutions
bull Resource Directoryndash httptoolsietforgiddraft-shelby-core-
resource-directory-05txtndash OMA Lightweight
2332010 CoRE WG IETF-77 Anaheim 6
Registering a Group
EP RD
| |
| - POST rd-groupgp=lights ltgtep=node1 --gt |
| |
| |
| lt---- 201 Created Location rd-group12 ---- |
| |
Req POST coaprdexamplecomrd-groupgp=lights
Payload
ltgtep=node1
ltgtep=node2
Res 201 Created
Location rd-group12
Looking up Group Members
Client RD
| |
| ----- GET rd-lookupepgp=lights1 ----------------------gt |
| |
| |
| lt-- 205 Content ltrdgtd=domain1ltrdgtd=domain2 --------- |
| |
Req GET rd-lookupepgp=lights1
Res 205 Content
ltcoaphostportgtep=node1
ltcoaphostportgtep=node2rdquo
Things for the futurebull Support for JSON representation of Web Links
ndash httptoolsietforgiddraft-bormann-core-links-json-02txtbull Registry for RD registration query parameters
ndash Already OMA Lightweight has defined some new onesbull More examples
Group 3 ldquonew workrdquo(continued)
109
drar-shy‐greevenbosch-shy‐core-shy‐profile-shy‐descripon-shy‐01Bert13 GreevenboschJeroen13 Hoebeke
Isam13 IshaqFloris13 Van13 den13 Abeele
Descripon
bull JSON13 format13 for13 signalling13 the13 servers13 capabilies
bull Signalling13 of13 supported13 opons13 media13 types13 and13 block13 sizendash Other13 items13 can13 be13 added
bull Filtering13 on13 specific13 fields13 through13 URI-shy‐Querybull Link13 hqpdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐profile-shy‐descripon
well-shy‐knownprofile
bull To13 acquire13 profile13 data13 of13 resources13 on13 a13 parcular13 service13 the13 well-shy‐knownprofile13 URI-shy‐path13 is13 introduced
bull For13 example13 to13 get13 all13 informaon13 from13 sensors13 served13 by13 wwwexampleorg13 we13 can13 do13 a13 GET13 to13 coapwwwexampleorgwell-shy‐knownprofile
bull Filtering13 on13 parcular13 resources13 is13 done13 through13 URI-shy‐Queries
Format
bull Currently13 the13 following13 fields13 are13 definedndash ldquopathrdquo13 contains13 the13 URI-shy‐path13 associated13 with13 a13 resource
ndash ldquooprdquo13 a13 numerical13 list13 of13 supported13 opon13 numbers
ndash ldquocfrdquo13 a13 numerical13 list13 of13 supported13 content-shy‐format13 numbers
ndash ldquob1srdquo13 ldquob2srdquo13 supported13 block13 sizes13 for13 Block113 and13 Block213 respecvely
Examplebull On13 the13 right13 is13 an13 example13 of13 a13 camera13 sensor13 at13 coapwwwexampleorgcam13 that13 supports13 the13 Uri-shy‐Host13 (3)13 ETag13 (4)13 Uri-shy‐Port13 (7)13 Uri-shy‐Path13 (11)13 Content-shy‐Format13 (12)13 Token13 (19)13 Block213 (23)13 and13 Proxy-shy‐Uri13 (35)13 opons
bull The13 supported13 content13 formats13 are13 textplain13 (0)13 applicaon13 link-shy‐format13 (40)13 and13 applicaonjson13 (50)
bull The13 supported13 Block213 can13 use13 25613 or13 51213 byte13 blocks
Req13 GET13 coapwwwexampleorgwell-shy‐knownprofile13 Res13 20513 Content13 (applicationjson)13 13 13 13 profile13 13 13 13 13 13 13 13 pathcam13 13 13 13 op[3471112192335]13 13 13 13 13 cf[04050]13 13 13 13 13 b2s[45]13 13 13 13
Filtering13 through13 use13 of13 URI-shy‐Query
bull Filtering13 can13 be13 done13 through13 the13 URI-shy‐Querybull Query13 format13 N=V
ndash N13 is13 a13 profile13 fieldndash V13 is13 the13 desired13 value
bull Examplesndash To13 find13 resources13 that13 support13 content13 format13 ldquoapplicaonjsonrdquo
13 GET13 wwwexampleorgwell-shy‐knownprofilecf=50ndash To13 get13 informaon13 about13 the13 camera
13 GET13 wwwexampleorgwell-shy‐knownprofilepath=cam
Open13 issues
bull Which13 other13 profile13 data13 needs13 signallingndash Content-shy‐type13 for13 different13 methods
bull Fix13 the13 order13 in13 which13 the13 profile13 fields13 must13 appearndash Non-shy‐fixed13 order13 easier13 extensible
bull Inheritance13 of13 a13 profile13 descriponbull Extend13 usage13 to13 signal13 the13 client13 profilebull Integraon13 with13 link13 format
Thank13 youQuesons
drar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval-shy‐00
Bert13 Greevenbosch
Descripon
bull The13 ldquoMinimumRequestInterval13 opon13 can13 be13 used13 to13 indicate13 the13 minimum13 me13 between13 two13 requests13 in13 a13 transacon
bull Originally13 intended13 for13 Block13 but13 also13 usable13 for13 other13 transaconsndash Example13 browsing13 a13 server
bull The13 goal13 is13 to13 reduce13 the13 server13 load13 and13 network13 traffic
bull Link13 hqpsdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval
Usage
bull The13 client13 keeps13 the13 server13 informed13 about13 its13 request13 speed13 through13 inclusion13 of13 the13 ldquoMinimumRequestIntervalrdquo13 opon
bull In13 responses13 the13 server13 fixes13 the13 minimum13 request13 interval13 through13 the13 same13 opon
bull The13 client13 obeys13 the13 speed13 indicated13 by13 the13 server
bull The13 client13 can13 send13 slower13 but13 not13 faster
Advantages
bull The13 server13 has13 means13 to13 limit13 the13 amount13 of13 incoming13 traffic
bull The13 server13 can13 prevent13 to13 become13 overloaded13 with13 too13 many13 tasks
bull The13 server13 does13 not13 need13 arficially13 slow13 down13 the13 client13 by13 sending13 late13 ACKsndash No13 need13 to13 keep13 track13 of13 delayed13 ACKsndash The13 server13 can13 perform13 other13 tasks13 instead
bull Reduced13 network13 traffic
Thank13 youQuesons
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-links-json-02txt
123
RFC 6690 (link-format) documents are somewhat foreign to many web app developerssect would prefer to have them in JSON format
There is no standard way to represent link-format documents in applicationssect but everyone knows how to handle JSON
Define a standard JSON translation for link-format
Itrsquos
not
rock
et
scien
ce
ltsensorsgtct=40title=Sensor Index ltsensorstempgtrt=temperature-cif=sensor ltsensorslightgtrt=light-luxif=sensor lthttpwwwexamplecomsensorst123gt anchor=sensorstemprel=describedby lttgtanchor=sensorstemprel=alternate [hrefsensorsct40titleSensor Index hrefsensorstemprttemperature-cifsensor hrefsensorslightrtlight-luxifsensor hrefhttpwwwexamplecomsensorst123 anchorsensorstempreldescribedby hreftanchorsensorstemprelalternate]
124
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-ipsec-for-coap-00txt
IPsec definitions for CoAP Mostly placeholder at this time Who has implementation experience with this
125
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-cross-reverse-convention-00txt
This draft has two lines of payload(based on a WGLC comment by Cullen Jennings)
coap12344567foobara=3
httpwwwproxycomwellknowncore-translate1234_4567foobara=3
Is that a useful convention to have
126
Insert CI slides here
127
128
0
5
10
15
20
25
30
35
40
10 20 30 40 50 60 70
good
put (
pps)
pps
Goodput vs pps (Econotags)
goodput
[Khattak preliminary]
Congestion Control
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-cocoa-00txt
ldquoadvancedrdquo cc (The draft is just a first shot) Others may have better ideas
129
Insert post-WGLC discussion slides here
130
Stop Continue Start
131
An Agile Retrospective
http6lowappnet coreIETF86 2013-03-12-13
Stop
132
Endless new CoAP optionssect instead use RESTful as much as possible
Move general security lifecycle out Looking at theoretical problems
http6lowappnet coreIETF86 2013-03-12-13
Continue
Interops Running code Look at real-world examples and deployments Solve their actual problems
sect Unilateral enhancements eg higher performance congestion control
sect Transports (SMS hellip)sect Make Web linking and Directories more and more usefulsect RESTful Design Paradigms for real-world problems
133
http6lowappnet coreIETF86 2013-03-12-13
Start
Further push into the (browser) web world (HTML5 browser security)
Specific supporting worksect SenMLsect URI work (dev URN hellip)sect Security Processes (next slide)
Spin outsect (We donrsquot really get to decide where this is done)
134
http6lowappnet coreIETF86 2013-03-12-13
Security
Integrate Application Network Group Keyingsect Tunnel-free setup
Donrsquot redo what has been done alreadysect ZigBee IP is finesect But what about other scenarios
Simple REST interfaces for working with keying materials and authorizationsect Start with defining objectives
Object Security for Constrained Nodes135
Re-chartering CoREWhat do we want to do now that wersquore grown up
Zach ShelbyCoRE WG IETF-86 Orlando
What is the scope
bull So we have a protocol and Web Linking what next
bull Keep with what we know besthellip1 Enhancements around CoAP2 New transports for CoAP3 New representations for Web Links4 General application layer solutions
CoRE WG IETF-86 Orlando 2
Enhancements around CoAP
bull Advanced congestion control
CoRE WG IETF-86 Orlando 3
New Transports for CoAP
bull Infrastructure for CoAP over foondash httptoolsietforgiddraft-silverajan-core-
coap-alternative-transports-01txtbull CoAP over SMS
ndash httptoolsietforgiddraft-becker-core-coap-sms-gprs-03txt
ndash OMA Lightweightbull CoAP over TCP
ndash httptoolsietforgiddraft-li-core-coap-payload-length-option-01txt
CoRE WG IETF-86 Orlando 4
New support for Web Links
bull JSON Web Linksndash httptoolsietforgiddraft-bormann-core-links-
json-02txt
2332010 CoRE WG IETF-77 Anaheim 5
General application layer solutions
bull Resource Directoryndash httptoolsietforgiddraft-shelby-core-
resource-directory-05txtndash OMA Lightweight
2332010 CoRE WG IETF-77 Anaheim 6
Looking up Group Members
Client RD
| |
| ----- GET rd-lookupepgp=lights1 ----------------------gt |
| |
| |
| lt-- 205 Content ltrdgtd=domain1ltrdgtd=domain2 --------- |
| |
Req GET rd-lookupepgp=lights1
Res 205 Content
ltcoaphostportgtep=node1
ltcoaphostportgtep=node2rdquo
Things for the futurebull Support for JSON representation of Web Links
ndash httptoolsietforgiddraft-bormann-core-links-json-02txtbull Registry for RD registration query parameters
ndash Already OMA Lightweight has defined some new onesbull More examples
Group 3 ldquonew workrdquo(continued)
109
drar-shy‐greevenbosch-shy‐core-shy‐profile-shy‐descripon-shy‐01Bert13 GreevenboschJeroen13 Hoebeke
Isam13 IshaqFloris13 Van13 den13 Abeele
Descripon
bull JSON13 format13 for13 signalling13 the13 servers13 capabilies
bull Signalling13 of13 supported13 opons13 media13 types13 and13 block13 sizendash Other13 items13 can13 be13 added
bull Filtering13 on13 specific13 fields13 through13 URI-shy‐Querybull Link13 hqpdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐profile-shy‐descripon
well-shy‐knownprofile
bull To13 acquire13 profile13 data13 of13 resources13 on13 a13 parcular13 service13 the13 well-shy‐knownprofile13 URI-shy‐path13 is13 introduced
bull For13 example13 to13 get13 all13 informaon13 from13 sensors13 served13 by13 wwwexampleorg13 we13 can13 do13 a13 GET13 to13 coapwwwexampleorgwell-shy‐knownprofile
bull Filtering13 on13 parcular13 resources13 is13 done13 through13 URI-shy‐Queries
Format
bull Currently13 the13 following13 fields13 are13 definedndash ldquopathrdquo13 contains13 the13 URI-shy‐path13 associated13 with13 a13 resource
ndash ldquooprdquo13 a13 numerical13 list13 of13 supported13 opon13 numbers
ndash ldquocfrdquo13 a13 numerical13 list13 of13 supported13 content-shy‐format13 numbers
ndash ldquob1srdquo13 ldquob2srdquo13 supported13 block13 sizes13 for13 Block113 and13 Block213 respecvely
Examplebull On13 the13 right13 is13 an13 example13 of13 a13 camera13 sensor13 at13 coapwwwexampleorgcam13 that13 supports13 the13 Uri-shy‐Host13 (3)13 ETag13 (4)13 Uri-shy‐Port13 (7)13 Uri-shy‐Path13 (11)13 Content-shy‐Format13 (12)13 Token13 (19)13 Block213 (23)13 and13 Proxy-shy‐Uri13 (35)13 opons
bull The13 supported13 content13 formats13 are13 textplain13 (0)13 applicaon13 link-shy‐format13 (40)13 and13 applicaonjson13 (50)
bull The13 supported13 Block213 can13 use13 25613 or13 51213 byte13 blocks
Req13 GET13 coapwwwexampleorgwell-shy‐knownprofile13 Res13 20513 Content13 (applicationjson)13 13 13 13 profile13 13 13 13 13 13 13 13 pathcam13 13 13 13 op[3471112192335]13 13 13 13 13 cf[04050]13 13 13 13 13 b2s[45]13 13 13 13
Filtering13 through13 use13 of13 URI-shy‐Query
bull Filtering13 can13 be13 done13 through13 the13 URI-shy‐Querybull Query13 format13 N=V
ndash N13 is13 a13 profile13 fieldndash V13 is13 the13 desired13 value
bull Examplesndash To13 find13 resources13 that13 support13 content13 format13 ldquoapplicaonjsonrdquo
13 GET13 wwwexampleorgwell-shy‐knownprofilecf=50ndash To13 get13 informaon13 about13 the13 camera
13 GET13 wwwexampleorgwell-shy‐knownprofilepath=cam
Open13 issues
bull Which13 other13 profile13 data13 needs13 signallingndash Content-shy‐type13 for13 different13 methods
bull Fix13 the13 order13 in13 which13 the13 profile13 fields13 must13 appearndash Non-shy‐fixed13 order13 easier13 extensible
bull Inheritance13 of13 a13 profile13 descriponbull Extend13 usage13 to13 signal13 the13 client13 profilebull Integraon13 with13 link13 format
Thank13 youQuesons
drar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval-shy‐00
Bert13 Greevenbosch
Descripon
bull The13 ldquoMinimumRequestInterval13 opon13 can13 be13 used13 to13 indicate13 the13 minimum13 me13 between13 two13 requests13 in13 a13 transacon
bull Originally13 intended13 for13 Block13 but13 also13 usable13 for13 other13 transaconsndash Example13 browsing13 a13 server
bull The13 goal13 is13 to13 reduce13 the13 server13 load13 and13 network13 traffic
bull Link13 hqpsdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval
Usage
bull The13 client13 keeps13 the13 server13 informed13 about13 its13 request13 speed13 through13 inclusion13 of13 the13 ldquoMinimumRequestIntervalrdquo13 opon
bull In13 responses13 the13 server13 fixes13 the13 minimum13 request13 interval13 through13 the13 same13 opon
bull The13 client13 obeys13 the13 speed13 indicated13 by13 the13 server
bull The13 client13 can13 send13 slower13 but13 not13 faster
Advantages
bull The13 server13 has13 means13 to13 limit13 the13 amount13 of13 incoming13 traffic
bull The13 server13 can13 prevent13 to13 become13 overloaded13 with13 too13 many13 tasks
bull The13 server13 does13 not13 need13 arficially13 slow13 down13 the13 client13 by13 sending13 late13 ACKsndash No13 need13 to13 keep13 track13 of13 delayed13 ACKsndash The13 server13 can13 perform13 other13 tasks13 instead
bull Reduced13 network13 traffic
Thank13 youQuesons
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-links-json-02txt
123
RFC 6690 (link-format) documents are somewhat foreign to many web app developerssect would prefer to have them in JSON format
There is no standard way to represent link-format documents in applicationssect but everyone knows how to handle JSON
Define a standard JSON translation for link-format
Itrsquos
not
rock
et
scien
ce
ltsensorsgtct=40title=Sensor Index ltsensorstempgtrt=temperature-cif=sensor ltsensorslightgtrt=light-luxif=sensor lthttpwwwexamplecomsensorst123gt anchor=sensorstemprel=describedby lttgtanchor=sensorstemprel=alternate [hrefsensorsct40titleSensor Index hrefsensorstemprttemperature-cifsensor hrefsensorslightrtlight-luxifsensor hrefhttpwwwexamplecomsensorst123 anchorsensorstempreldescribedby hreftanchorsensorstemprelalternate]
124
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-ipsec-for-coap-00txt
IPsec definitions for CoAP Mostly placeholder at this time Who has implementation experience with this
125
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-cross-reverse-convention-00txt
This draft has two lines of payload(based on a WGLC comment by Cullen Jennings)
coap12344567foobara=3
httpwwwproxycomwellknowncore-translate1234_4567foobara=3
Is that a useful convention to have
126
Insert CI slides here
127
128
0
5
10
15
20
25
30
35
40
10 20 30 40 50 60 70
good
put (
pps)
pps
Goodput vs pps (Econotags)
goodput
[Khattak preliminary]
Congestion Control
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-cocoa-00txt
ldquoadvancedrdquo cc (The draft is just a first shot) Others may have better ideas
129
Insert post-WGLC discussion slides here
130
Stop Continue Start
131
An Agile Retrospective
http6lowappnet coreIETF86 2013-03-12-13
Stop
132
Endless new CoAP optionssect instead use RESTful as much as possible
Move general security lifecycle out Looking at theoretical problems
http6lowappnet coreIETF86 2013-03-12-13
Continue
Interops Running code Look at real-world examples and deployments Solve their actual problems
sect Unilateral enhancements eg higher performance congestion control
sect Transports (SMS hellip)sect Make Web linking and Directories more and more usefulsect RESTful Design Paradigms for real-world problems
133
http6lowappnet coreIETF86 2013-03-12-13
Start
Further push into the (browser) web world (HTML5 browser security)
Specific supporting worksect SenMLsect URI work (dev URN hellip)sect Security Processes (next slide)
Spin outsect (We donrsquot really get to decide where this is done)
134
http6lowappnet coreIETF86 2013-03-12-13
Security
Integrate Application Network Group Keyingsect Tunnel-free setup
Donrsquot redo what has been done alreadysect ZigBee IP is finesect But what about other scenarios
Simple REST interfaces for working with keying materials and authorizationsect Start with defining objectives
Object Security for Constrained Nodes135
Re-chartering CoREWhat do we want to do now that wersquore grown up
Zach ShelbyCoRE WG IETF-86 Orlando
What is the scope
bull So we have a protocol and Web Linking what next
bull Keep with what we know besthellip1 Enhancements around CoAP2 New transports for CoAP3 New representations for Web Links4 General application layer solutions
CoRE WG IETF-86 Orlando 2
Enhancements around CoAP
bull Advanced congestion control
CoRE WG IETF-86 Orlando 3
New Transports for CoAP
bull Infrastructure for CoAP over foondash httptoolsietforgiddraft-silverajan-core-
coap-alternative-transports-01txtbull CoAP over SMS
ndash httptoolsietforgiddraft-becker-core-coap-sms-gprs-03txt
ndash OMA Lightweightbull CoAP over TCP
ndash httptoolsietforgiddraft-li-core-coap-payload-length-option-01txt
CoRE WG IETF-86 Orlando 4
New support for Web Links
bull JSON Web Linksndash httptoolsietforgiddraft-bormann-core-links-
json-02txt
2332010 CoRE WG IETF-77 Anaheim 5
General application layer solutions
bull Resource Directoryndash httptoolsietforgiddraft-shelby-core-
resource-directory-05txtndash OMA Lightweight
2332010 CoRE WG IETF-77 Anaheim 6
Things for the futurebull Support for JSON representation of Web Links
ndash httptoolsietforgiddraft-bormann-core-links-json-02txtbull Registry for RD registration query parameters
ndash Already OMA Lightweight has defined some new onesbull More examples
Group 3 ldquonew workrdquo(continued)
109
drar-shy‐greevenbosch-shy‐core-shy‐profile-shy‐descripon-shy‐01Bert13 GreevenboschJeroen13 Hoebeke
Isam13 IshaqFloris13 Van13 den13 Abeele
Descripon
bull JSON13 format13 for13 signalling13 the13 servers13 capabilies
bull Signalling13 of13 supported13 opons13 media13 types13 and13 block13 sizendash Other13 items13 can13 be13 added
bull Filtering13 on13 specific13 fields13 through13 URI-shy‐Querybull Link13 hqpdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐profile-shy‐descripon
well-shy‐knownprofile
bull To13 acquire13 profile13 data13 of13 resources13 on13 a13 parcular13 service13 the13 well-shy‐knownprofile13 URI-shy‐path13 is13 introduced
bull For13 example13 to13 get13 all13 informaon13 from13 sensors13 served13 by13 wwwexampleorg13 we13 can13 do13 a13 GET13 to13 coapwwwexampleorgwell-shy‐knownprofile
bull Filtering13 on13 parcular13 resources13 is13 done13 through13 URI-shy‐Queries
Format
bull Currently13 the13 following13 fields13 are13 definedndash ldquopathrdquo13 contains13 the13 URI-shy‐path13 associated13 with13 a13 resource
ndash ldquooprdquo13 a13 numerical13 list13 of13 supported13 opon13 numbers
ndash ldquocfrdquo13 a13 numerical13 list13 of13 supported13 content-shy‐format13 numbers
ndash ldquob1srdquo13 ldquob2srdquo13 supported13 block13 sizes13 for13 Block113 and13 Block213 respecvely
Examplebull On13 the13 right13 is13 an13 example13 of13 a13 camera13 sensor13 at13 coapwwwexampleorgcam13 that13 supports13 the13 Uri-shy‐Host13 (3)13 ETag13 (4)13 Uri-shy‐Port13 (7)13 Uri-shy‐Path13 (11)13 Content-shy‐Format13 (12)13 Token13 (19)13 Block213 (23)13 and13 Proxy-shy‐Uri13 (35)13 opons
bull The13 supported13 content13 formats13 are13 textplain13 (0)13 applicaon13 link-shy‐format13 (40)13 and13 applicaonjson13 (50)
bull The13 supported13 Block213 can13 use13 25613 or13 51213 byte13 blocks
Req13 GET13 coapwwwexampleorgwell-shy‐knownprofile13 Res13 20513 Content13 (applicationjson)13 13 13 13 profile13 13 13 13 13 13 13 13 pathcam13 13 13 13 op[3471112192335]13 13 13 13 13 cf[04050]13 13 13 13 13 b2s[45]13 13 13 13
Filtering13 through13 use13 of13 URI-shy‐Query
bull Filtering13 can13 be13 done13 through13 the13 URI-shy‐Querybull Query13 format13 N=V
ndash N13 is13 a13 profile13 fieldndash V13 is13 the13 desired13 value
bull Examplesndash To13 find13 resources13 that13 support13 content13 format13 ldquoapplicaonjsonrdquo
13 GET13 wwwexampleorgwell-shy‐knownprofilecf=50ndash To13 get13 informaon13 about13 the13 camera
13 GET13 wwwexampleorgwell-shy‐knownprofilepath=cam
Open13 issues
bull Which13 other13 profile13 data13 needs13 signallingndash Content-shy‐type13 for13 different13 methods
bull Fix13 the13 order13 in13 which13 the13 profile13 fields13 must13 appearndash Non-shy‐fixed13 order13 easier13 extensible
bull Inheritance13 of13 a13 profile13 descriponbull Extend13 usage13 to13 signal13 the13 client13 profilebull Integraon13 with13 link13 format
Thank13 youQuesons
drar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval-shy‐00
Bert13 Greevenbosch
Descripon
bull The13 ldquoMinimumRequestInterval13 opon13 can13 be13 used13 to13 indicate13 the13 minimum13 me13 between13 two13 requests13 in13 a13 transacon
bull Originally13 intended13 for13 Block13 but13 also13 usable13 for13 other13 transaconsndash Example13 browsing13 a13 server
bull The13 goal13 is13 to13 reduce13 the13 server13 load13 and13 network13 traffic
bull Link13 hqpsdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval
Usage
bull The13 client13 keeps13 the13 server13 informed13 about13 its13 request13 speed13 through13 inclusion13 of13 the13 ldquoMinimumRequestIntervalrdquo13 opon
bull In13 responses13 the13 server13 fixes13 the13 minimum13 request13 interval13 through13 the13 same13 opon
bull The13 client13 obeys13 the13 speed13 indicated13 by13 the13 server
bull The13 client13 can13 send13 slower13 but13 not13 faster
Advantages
bull The13 server13 has13 means13 to13 limit13 the13 amount13 of13 incoming13 traffic
bull The13 server13 can13 prevent13 to13 become13 overloaded13 with13 too13 many13 tasks
bull The13 server13 does13 not13 need13 arficially13 slow13 down13 the13 client13 by13 sending13 late13 ACKsndash No13 need13 to13 keep13 track13 of13 delayed13 ACKsndash The13 server13 can13 perform13 other13 tasks13 instead
bull Reduced13 network13 traffic
Thank13 youQuesons
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-links-json-02txt
123
RFC 6690 (link-format) documents are somewhat foreign to many web app developerssect would prefer to have them in JSON format
There is no standard way to represent link-format documents in applicationssect but everyone knows how to handle JSON
Define a standard JSON translation for link-format
Itrsquos
not
rock
et
scien
ce
ltsensorsgtct=40title=Sensor Index ltsensorstempgtrt=temperature-cif=sensor ltsensorslightgtrt=light-luxif=sensor lthttpwwwexamplecomsensorst123gt anchor=sensorstemprel=describedby lttgtanchor=sensorstemprel=alternate [hrefsensorsct40titleSensor Index hrefsensorstemprttemperature-cifsensor hrefsensorslightrtlight-luxifsensor hrefhttpwwwexamplecomsensorst123 anchorsensorstempreldescribedby hreftanchorsensorstemprelalternate]
124
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-ipsec-for-coap-00txt
IPsec definitions for CoAP Mostly placeholder at this time Who has implementation experience with this
125
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-cross-reverse-convention-00txt
This draft has two lines of payload(based on a WGLC comment by Cullen Jennings)
coap12344567foobara=3
httpwwwproxycomwellknowncore-translate1234_4567foobara=3
Is that a useful convention to have
126
Insert CI slides here
127
128
0
5
10
15
20
25
30
35
40
10 20 30 40 50 60 70
good
put (
pps)
pps
Goodput vs pps (Econotags)
goodput
[Khattak preliminary]
Congestion Control
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-cocoa-00txt
ldquoadvancedrdquo cc (The draft is just a first shot) Others may have better ideas
129
Insert post-WGLC discussion slides here
130
Stop Continue Start
131
An Agile Retrospective
http6lowappnet coreIETF86 2013-03-12-13
Stop
132
Endless new CoAP optionssect instead use RESTful as much as possible
Move general security lifecycle out Looking at theoretical problems
http6lowappnet coreIETF86 2013-03-12-13
Continue
Interops Running code Look at real-world examples and deployments Solve their actual problems
sect Unilateral enhancements eg higher performance congestion control
sect Transports (SMS hellip)sect Make Web linking and Directories more and more usefulsect RESTful Design Paradigms for real-world problems
133
http6lowappnet coreIETF86 2013-03-12-13
Start
Further push into the (browser) web world (HTML5 browser security)
Specific supporting worksect SenMLsect URI work (dev URN hellip)sect Security Processes (next slide)
Spin outsect (We donrsquot really get to decide where this is done)
134
http6lowappnet coreIETF86 2013-03-12-13
Security
Integrate Application Network Group Keyingsect Tunnel-free setup
Donrsquot redo what has been done alreadysect ZigBee IP is finesect But what about other scenarios
Simple REST interfaces for working with keying materials and authorizationsect Start with defining objectives
Object Security for Constrained Nodes135
Re-chartering CoREWhat do we want to do now that wersquore grown up
Zach ShelbyCoRE WG IETF-86 Orlando
What is the scope
bull So we have a protocol and Web Linking what next
bull Keep with what we know besthellip1 Enhancements around CoAP2 New transports for CoAP3 New representations for Web Links4 General application layer solutions
CoRE WG IETF-86 Orlando 2
Enhancements around CoAP
bull Advanced congestion control
CoRE WG IETF-86 Orlando 3
New Transports for CoAP
bull Infrastructure for CoAP over foondash httptoolsietforgiddraft-silverajan-core-
coap-alternative-transports-01txtbull CoAP over SMS
ndash httptoolsietforgiddraft-becker-core-coap-sms-gprs-03txt
ndash OMA Lightweightbull CoAP over TCP
ndash httptoolsietforgiddraft-li-core-coap-payload-length-option-01txt
CoRE WG IETF-86 Orlando 4
New support for Web Links
bull JSON Web Linksndash httptoolsietforgiddraft-bormann-core-links-
json-02txt
2332010 CoRE WG IETF-77 Anaheim 5
General application layer solutions
bull Resource Directoryndash httptoolsietforgiddraft-shelby-core-
resource-directory-05txtndash OMA Lightweight
2332010 CoRE WG IETF-77 Anaheim 6
Group 3 ldquonew workrdquo(continued)
109
drar-shy‐greevenbosch-shy‐core-shy‐profile-shy‐descripon-shy‐01Bert13 GreevenboschJeroen13 Hoebeke
Isam13 IshaqFloris13 Van13 den13 Abeele
Descripon
bull JSON13 format13 for13 signalling13 the13 servers13 capabilies
bull Signalling13 of13 supported13 opons13 media13 types13 and13 block13 sizendash Other13 items13 can13 be13 added
bull Filtering13 on13 specific13 fields13 through13 URI-shy‐Querybull Link13 hqpdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐profile-shy‐descripon
well-shy‐knownprofile
bull To13 acquire13 profile13 data13 of13 resources13 on13 a13 parcular13 service13 the13 well-shy‐knownprofile13 URI-shy‐path13 is13 introduced
bull For13 example13 to13 get13 all13 informaon13 from13 sensors13 served13 by13 wwwexampleorg13 we13 can13 do13 a13 GET13 to13 coapwwwexampleorgwell-shy‐knownprofile
bull Filtering13 on13 parcular13 resources13 is13 done13 through13 URI-shy‐Queries
Format
bull Currently13 the13 following13 fields13 are13 definedndash ldquopathrdquo13 contains13 the13 URI-shy‐path13 associated13 with13 a13 resource
ndash ldquooprdquo13 a13 numerical13 list13 of13 supported13 opon13 numbers
ndash ldquocfrdquo13 a13 numerical13 list13 of13 supported13 content-shy‐format13 numbers
ndash ldquob1srdquo13 ldquob2srdquo13 supported13 block13 sizes13 for13 Block113 and13 Block213 respecvely
Examplebull On13 the13 right13 is13 an13 example13 of13 a13 camera13 sensor13 at13 coapwwwexampleorgcam13 that13 supports13 the13 Uri-shy‐Host13 (3)13 ETag13 (4)13 Uri-shy‐Port13 (7)13 Uri-shy‐Path13 (11)13 Content-shy‐Format13 (12)13 Token13 (19)13 Block213 (23)13 and13 Proxy-shy‐Uri13 (35)13 opons
bull The13 supported13 content13 formats13 are13 textplain13 (0)13 applicaon13 link-shy‐format13 (40)13 and13 applicaonjson13 (50)
bull The13 supported13 Block213 can13 use13 25613 or13 51213 byte13 blocks
Req13 GET13 coapwwwexampleorgwell-shy‐knownprofile13 Res13 20513 Content13 (applicationjson)13 13 13 13 profile13 13 13 13 13 13 13 13 pathcam13 13 13 13 op[3471112192335]13 13 13 13 13 cf[04050]13 13 13 13 13 b2s[45]13 13 13 13
Filtering13 through13 use13 of13 URI-shy‐Query
bull Filtering13 can13 be13 done13 through13 the13 URI-shy‐Querybull Query13 format13 N=V
ndash N13 is13 a13 profile13 fieldndash V13 is13 the13 desired13 value
bull Examplesndash To13 find13 resources13 that13 support13 content13 format13 ldquoapplicaonjsonrdquo
13 GET13 wwwexampleorgwell-shy‐knownprofilecf=50ndash To13 get13 informaon13 about13 the13 camera
13 GET13 wwwexampleorgwell-shy‐knownprofilepath=cam
Open13 issues
bull Which13 other13 profile13 data13 needs13 signallingndash Content-shy‐type13 for13 different13 methods
bull Fix13 the13 order13 in13 which13 the13 profile13 fields13 must13 appearndash Non-shy‐fixed13 order13 easier13 extensible
bull Inheritance13 of13 a13 profile13 descriponbull Extend13 usage13 to13 signal13 the13 client13 profilebull Integraon13 with13 link13 format
Thank13 youQuesons
drar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval-shy‐00
Bert13 Greevenbosch
Descripon
bull The13 ldquoMinimumRequestInterval13 opon13 can13 be13 used13 to13 indicate13 the13 minimum13 me13 between13 two13 requests13 in13 a13 transacon
bull Originally13 intended13 for13 Block13 but13 also13 usable13 for13 other13 transaconsndash Example13 browsing13 a13 server
bull The13 goal13 is13 to13 reduce13 the13 server13 load13 and13 network13 traffic
bull Link13 hqpsdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval
Usage
bull The13 client13 keeps13 the13 server13 informed13 about13 its13 request13 speed13 through13 inclusion13 of13 the13 ldquoMinimumRequestIntervalrdquo13 opon
bull In13 responses13 the13 server13 fixes13 the13 minimum13 request13 interval13 through13 the13 same13 opon
bull The13 client13 obeys13 the13 speed13 indicated13 by13 the13 server
bull The13 client13 can13 send13 slower13 but13 not13 faster
Advantages
bull The13 server13 has13 means13 to13 limit13 the13 amount13 of13 incoming13 traffic
bull The13 server13 can13 prevent13 to13 become13 overloaded13 with13 too13 many13 tasks
bull The13 server13 does13 not13 need13 arficially13 slow13 down13 the13 client13 by13 sending13 late13 ACKsndash No13 need13 to13 keep13 track13 of13 delayed13 ACKsndash The13 server13 can13 perform13 other13 tasks13 instead
bull Reduced13 network13 traffic
Thank13 youQuesons
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-links-json-02txt
123
RFC 6690 (link-format) documents are somewhat foreign to many web app developerssect would prefer to have them in JSON format
There is no standard way to represent link-format documents in applicationssect but everyone knows how to handle JSON
Define a standard JSON translation for link-format
Itrsquos
not
rock
et
scien
ce
ltsensorsgtct=40title=Sensor Index ltsensorstempgtrt=temperature-cif=sensor ltsensorslightgtrt=light-luxif=sensor lthttpwwwexamplecomsensorst123gt anchor=sensorstemprel=describedby lttgtanchor=sensorstemprel=alternate [hrefsensorsct40titleSensor Index hrefsensorstemprttemperature-cifsensor hrefsensorslightrtlight-luxifsensor hrefhttpwwwexamplecomsensorst123 anchorsensorstempreldescribedby hreftanchorsensorstemprelalternate]
124
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-ipsec-for-coap-00txt
IPsec definitions for CoAP Mostly placeholder at this time Who has implementation experience with this
125
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-cross-reverse-convention-00txt
This draft has two lines of payload(based on a WGLC comment by Cullen Jennings)
coap12344567foobara=3
httpwwwproxycomwellknowncore-translate1234_4567foobara=3
Is that a useful convention to have
126
Insert CI slides here
127
128
0
5
10
15
20
25
30
35
40
10 20 30 40 50 60 70
good
put (
pps)
pps
Goodput vs pps (Econotags)
goodput
[Khattak preliminary]
Congestion Control
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-cocoa-00txt
ldquoadvancedrdquo cc (The draft is just a first shot) Others may have better ideas
129
Insert post-WGLC discussion slides here
130
Stop Continue Start
131
An Agile Retrospective
http6lowappnet coreIETF86 2013-03-12-13
Stop
132
Endless new CoAP optionssect instead use RESTful as much as possible
Move general security lifecycle out Looking at theoretical problems
http6lowappnet coreIETF86 2013-03-12-13
Continue
Interops Running code Look at real-world examples and deployments Solve their actual problems
sect Unilateral enhancements eg higher performance congestion control
sect Transports (SMS hellip)sect Make Web linking and Directories more and more usefulsect RESTful Design Paradigms for real-world problems
133
http6lowappnet coreIETF86 2013-03-12-13
Start
Further push into the (browser) web world (HTML5 browser security)
Specific supporting worksect SenMLsect URI work (dev URN hellip)sect Security Processes (next slide)
Spin outsect (We donrsquot really get to decide where this is done)
134
http6lowappnet coreIETF86 2013-03-12-13
Security
Integrate Application Network Group Keyingsect Tunnel-free setup
Donrsquot redo what has been done alreadysect ZigBee IP is finesect But what about other scenarios
Simple REST interfaces for working with keying materials and authorizationsect Start with defining objectives
Object Security for Constrained Nodes135
Re-chartering CoREWhat do we want to do now that wersquore grown up
Zach ShelbyCoRE WG IETF-86 Orlando
What is the scope
bull So we have a protocol and Web Linking what next
bull Keep with what we know besthellip1 Enhancements around CoAP2 New transports for CoAP3 New representations for Web Links4 General application layer solutions
CoRE WG IETF-86 Orlando 2
Enhancements around CoAP
bull Advanced congestion control
CoRE WG IETF-86 Orlando 3
New Transports for CoAP
bull Infrastructure for CoAP over foondash httptoolsietforgiddraft-silverajan-core-
coap-alternative-transports-01txtbull CoAP over SMS
ndash httptoolsietforgiddraft-becker-core-coap-sms-gprs-03txt
ndash OMA Lightweightbull CoAP over TCP
ndash httptoolsietforgiddraft-li-core-coap-payload-length-option-01txt
CoRE WG IETF-86 Orlando 4
New support for Web Links
bull JSON Web Linksndash httptoolsietforgiddraft-bormann-core-links-
json-02txt
2332010 CoRE WG IETF-77 Anaheim 5
General application layer solutions
bull Resource Directoryndash httptoolsietforgiddraft-shelby-core-
resource-directory-05txtndash OMA Lightweight
2332010 CoRE WG IETF-77 Anaheim 6
drar-shy‐greevenbosch-shy‐core-shy‐profile-shy‐descripon-shy‐01Bert13 GreevenboschJeroen13 Hoebeke
Isam13 IshaqFloris13 Van13 den13 Abeele
Descripon
bull JSON13 format13 for13 signalling13 the13 servers13 capabilies
bull Signalling13 of13 supported13 opons13 media13 types13 and13 block13 sizendash Other13 items13 can13 be13 added
bull Filtering13 on13 specific13 fields13 through13 URI-shy‐Querybull Link13 hqpdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐profile-shy‐descripon
well-shy‐knownprofile
bull To13 acquire13 profile13 data13 of13 resources13 on13 a13 parcular13 service13 the13 well-shy‐knownprofile13 URI-shy‐path13 is13 introduced
bull For13 example13 to13 get13 all13 informaon13 from13 sensors13 served13 by13 wwwexampleorg13 we13 can13 do13 a13 GET13 to13 coapwwwexampleorgwell-shy‐knownprofile
bull Filtering13 on13 parcular13 resources13 is13 done13 through13 URI-shy‐Queries
Format
bull Currently13 the13 following13 fields13 are13 definedndash ldquopathrdquo13 contains13 the13 URI-shy‐path13 associated13 with13 a13 resource
ndash ldquooprdquo13 a13 numerical13 list13 of13 supported13 opon13 numbers
ndash ldquocfrdquo13 a13 numerical13 list13 of13 supported13 content-shy‐format13 numbers
ndash ldquob1srdquo13 ldquob2srdquo13 supported13 block13 sizes13 for13 Block113 and13 Block213 respecvely
Examplebull On13 the13 right13 is13 an13 example13 of13 a13 camera13 sensor13 at13 coapwwwexampleorgcam13 that13 supports13 the13 Uri-shy‐Host13 (3)13 ETag13 (4)13 Uri-shy‐Port13 (7)13 Uri-shy‐Path13 (11)13 Content-shy‐Format13 (12)13 Token13 (19)13 Block213 (23)13 and13 Proxy-shy‐Uri13 (35)13 opons
bull The13 supported13 content13 formats13 are13 textplain13 (0)13 applicaon13 link-shy‐format13 (40)13 and13 applicaonjson13 (50)
bull The13 supported13 Block213 can13 use13 25613 or13 51213 byte13 blocks
Req13 GET13 coapwwwexampleorgwell-shy‐knownprofile13 Res13 20513 Content13 (applicationjson)13 13 13 13 profile13 13 13 13 13 13 13 13 pathcam13 13 13 13 op[3471112192335]13 13 13 13 13 cf[04050]13 13 13 13 13 b2s[45]13 13 13 13
Filtering13 through13 use13 of13 URI-shy‐Query
bull Filtering13 can13 be13 done13 through13 the13 URI-shy‐Querybull Query13 format13 N=V
ndash N13 is13 a13 profile13 fieldndash V13 is13 the13 desired13 value
bull Examplesndash To13 find13 resources13 that13 support13 content13 format13 ldquoapplicaonjsonrdquo
13 GET13 wwwexampleorgwell-shy‐knownprofilecf=50ndash To13 get13 informaon13 about13 the13 camera
13 GET13 wwwexampleorgwell-shy‐knownprofilepath=cam
Open13 issues
bull Which13 other13 profile13 data13 needs13 signallingndash Content-shy‐type13 for13 different13 methods
bull Fix13 the13 order13 in13 which13 the13 profile13 fields13 must13 appearndash Non-shy‐fixed13 order13 easier13 extensible
bull Inheritance13 of13 a13 profile13 descriponbull Extend13 usage13 to13 signal13 the13 client13 profilebull Integraon13 with13 link13 format
Thank13 youQuesons
drar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval-shy‐00
Bert13 Greevenbosch
Descripon
bull The13 ldquoMinimumRequestInterval13 opon13 can13 be13 used13 to13 indicate13 the13 minimum13 me13 between13 two13 requests13 in13 a13 transacon
bull Originally13 intended13 for13 Block13 but13 also13 usable13 for13 other13 transaconsndash Example13 browsing13 a13 server
bull The13 goal13 is13 to13 reduce13 the13 server13 load13 and13 network13 traffic
bull Link13 hqpsdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval
Usage
bull The13 client13 keeps13 the13 server13 informed13 about13 its13 request13 speed13 through13 inclusion13 of13 the13 ldquoMinimumRequestIntervalrdquo13 opon
bull In13 responses13 the13 server13 fixes13 the13 minimum13 request13 interval13 through13 the13 same13 opon
bull The13 client13 obeys13 the13 speed13 indicated13 by13 the13 server
bull The13 client13 can13 send13 slower13 but13 not13 faster
Advantages
bull The13 server13 has13 means13 to13 limit13 the13 amount13 of13 incoming13 traffic
bull The13 server13 can13 prevent13 to13 become13 overloaded13 with13 too13 many13 tasks
bull The13 server13 does13 not13 need13 arficially13 slow13 down13 the13 client13 by13 sending13 late13 ACKsndash No13 need13 to13 keep13 track13 of13 delayed13 ACKsndash The13 server13 can13 perform13 other13 tasks13 instead
bull Reduced13 network13 traffic
Thank13 youQuesons
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-links-json-02txt
123
RFC 6690 (link-format) documents are somewhat foreign to many web app developerssect would prefer to have them in JSON format
There is no standard way to represent link-format documents in applicationssect but everyone knows how to handle JSON
Define a standard JSON translation for link-format
Itrsquos
not
rock
et
scien
ce
ltsensorsgtct=40title=Sensor Index ltsensorstempgtrt=temperature-cif=sensor ltsensorslightgtrt=light-luxif=sensor lthttpwwwexamplecomsensorst123gt anchor=sensorstemprel=describedby lttgtanchor=sensorstemprel=alternate [hrefsensorsct40titleSensor Index hrefsensorstemprttemperature-cifsensor hrefsensorslightrtlight-luxifsensor hrefhttpwwwexamplecomsensorst123 anchorsensorstempreldescribedby hreftanchorsensorstemprelalternate]
124
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-ipsec-for-coap-00txt
IPsec definitions for CoAP Mostly placeholder at this time Who has implementation experience with this
125
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-cross-reverse-convention-00txt
This draft has two lines of payload(based on a WGLC comment by Cullen Jennings)
coap12344567foobara=3
httpwwwproxycomwellknowncore-translate1234_4567foobara=3
Is that a useful convention to have
126
Insert CI slides here
127
128
0
5
10
15
20
25
30
35
40
10 20 30 40 50 60 70
good
put (
pps)
pps
Goodput vs pps (Econotags)
goodput
[Khattak preliminary]
Congestion Control
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-cocoa-00txt
ldquoadvancedrdquo cc (The draft is just a first shot) Others may have better ideas
129
Insert post-WGLC discussion slides here
130
Stop Continue Start
131
An Agile Retrospective
http6lowappnet coreIETF86 2013-03-12-13
Stop
132
Endless new CoAP optionssect instead use RESTful as much as possible
Move general security lifecycle out Looking at theoretical problems
http6lowappnet coreIETF86 2013-03-12-13
Continue
Interops Running code Look at real-world examples and deployments Solve their actual problems
sect Unilateral enhancements eg higher performance congestion control
sect Transports (SMS hellip)sect Make Web linking and Directories more and more usefulsect RESTful Design Paradigms for real-world problems
133
http6lowappnet coreIETF86 2013-03-12-13
Start
Further push into the (browser) web world (HTML5 browser security)
Specific supporting worksect SenMLsect URI work (dev URN hellip)sect Security Processes (next slide)
Spin outsect (We donrsquot really get to decide where this is done)
134
http6lowappnet coreIETF86 2013-03-12-13
Security
Integrate Application Network Group Keyingsect Tunnel-free setup
Donrsquot redo what has been done alreadysect ZigBee IP is finesect But what about other scenarios
Simple REST interfaces for working with keying materials and authorizationsect Start with defining objectives
Object Security for Constrained Nodes135
Re-chartering CoREWhat do we want to do now that wersquore grown up
Zach ShelbyCoRE WG IETF-86 Orlando
What is the scope
bull So we have a protocol and Web Linking what next
bull Keep with what we know besthellip1 Enhancements around CoAP2 New transports for CoAP3 New representations for Web Links4 General application layer solutions
CoRE WG IETF-86 Orlando 2
Enhancements around CoAP
bull Advanced congestion control
CoRE WG IETF-86 Orlando 3
New Transports for CoAP
bull Infrastructure for CoAP over foondash httptoolsietforgiddraft-silverajan-core-
coap-alternative-transports-01txtbull CoAP over SMS
ndash httptoolsietforgiddraft-becker-core-coap-sms-gprs-03txt
ndash OMA Lightweightbull CoAP over TCP
ndash httptoolsietforgiddraft-li-core-coap-payload-length-option-01txt
CoRE WG IETF-86 Orlando 4
New support for Web Links
bull JSON Web Linksndash httptoolsietforgiddraft-bormann-core-links-
json-02txt
2332010 CoRE WG IETF-77 Anaheim 5
General application layer solutions
bull Resource Directoryndash httptoolsietforgiddraft-shelby-core-
resource-directory-05txtndash OMA Lightweight
2332010 CoRE WG IETF-77 Anaheim 6
Descripon
bull JSON13 format13 for13 signalling13 the13 servers13 capabilies
bull Signalling13 of13 supported13 opons13 media13 types13 and13 block13 sizendash Other13 items13 can13 be13 added
bull Filtering13 on13 specific13 fields13 through13 URI-shy‐Querybull Link13 hqpdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐profile-shy‐descripon
well-shy‐knownprofile
bull To13 acquire13 profile13 data13 of13 resources13 on13 a13 parcular13 service13 the13 well-shy‐knownprofile13 URI-shy‐path13 is13 introduced
bull For13 example13 to13 get13 all13 informaon13 from13 sensors13 served13 by13 wwwexampleorg13 we13 can13 do13 a13 GET13 to13 coapwwwexampleorgwell-shy‐knownprofile
bull Filtering13 on13 parcular13 resources13 is13 done13 through13 URI-shy‐Queries
Format
bull Currently13 the13 following13 fields13 are13 definedndash ldquopathrdquo13 contains13 the13 URI-shy‐path13 associated13 with13 a13 resource
ndash ldquooprdquo13 a13 numerical13 list13 of13 supported13 opon13 numbers
ndash ldquocfrdquo13 a13 numerical13 list13 of13 supported13 content-shy‐format13 numbers
ndash ldquob1srdquo13 ldquob2srdquo13 supported13 block13 sizes13 for13 Block113 and13 Block213 respecvely
Examplebull On13 the13 right13 is13 an13 example13 of13 a13 camera13 sensor13 at13 coapwwwexampleorgcam13 that13 supports13 the13 Uri-shy‐Host13 (3)13 ETag13 (4)13 Uri-shy‐Port13 (7)13 Uri-shy‐Path13 (11)13 Content-shy‐Format13 (12)13 Token13 (19)13 Block213 (23)13 and13 Proxy-shy‐Uri13 (35)13 opons
bull The13 supported13 content13 formats13 are13 textplain13 (0)13 applicaon13 link-shy‐format13 (40)13 and13 applicaonjson13 (50)
bull The13 supported13 Block213 can13 use13 25613 or13 51213 byte13 blocks
Req13 GET13 coapwwwexampleorgwell-shy‐knownprofile13 Res13 20513 Content13 (applicationjson)13 13 13 13 profile13 13 13 13 13 13 13 13 pathcam13 13 13 13 op[3471112192335]13 13 13 13 13 cf[04050]13 13 13 13 13 b2s[45]13 13 13 13
Filtering13 through13 use13 of13 URI-shy‐Query
bull Filtering13 can13 be13 done13 through13 the13 URI-shy‐Querybull Query13 format13 N=V
ndash N13 is13 a13 profile13 fieldndash V13 is13 the13 desired13 value
bull Examplesndash To13 find13 resources13 that13 support13 content13 format13 ldquoapplicaonjsonrdquo
13 GET13 wwwexampleorgwell-shy‐knownprofilecf=50ndash To13 get13 informaon13 about13 the13 camera
13 GET13 wwwexampleorgwell-shy‐knownprofilepath=cam
Open13 issues
bull Which13 other13 profile13 data13 needs13 signallingndash Content-shy‐type13 for13 different13 methods
bull Fix13 the13 order13 in13 which13 the13 profile13 fields13 must13 appearndash Non-shy‐fixed13 order13 easier13 extensible
bull Inheritance13 of13 a13 profile13 descriponbull Extend13 usage13 to13 signal13 the13 client13 profilebull Integraon13 with13 link13 format
Thank13 youQuesons
drar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval-shy‐00
Bert13 Greevenbosch
Descripon
bull The13 ldquoMinimumRequestInterval13 opon13 can13 be13 used13 to13 indicate13 the13 minimum13 me13 between13 two13 requests13 in13 a13 transacon
bull Originally13 intended13 for13 Block13 but13 also13 usable13 for13 other13 transaconsndash Example13 browsing13 a13 server
bull The13 goal13 is13 to13 reduce13 the13 server13 load13 and13 network13 traffic
bull Link13 hqpsdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval
Usage
bull The13 client13 keeps13 the13 server13 informed13 about13 its13 request13 speed13 through13 inclusion13 of13 the13 ldquoMinimumRequestIntervalrdquo13 opon
bull In13 responses13 the13 server13 fixes13 the13 minimum13 request13 interval13 through13 the13 same13 opon
bull The13 client13 obeys13 the13 speed13 indicated13 by13 the13 server
bull The13 client13 can13 send13 slower13 but13 not13 faster
Advantages
bull The13 server13 has13 means13 to13 limit13 the13 amount13 of13 incoming13 traffic
bull The13 server13 can13 prevent13 to13 become13 overloaded13 with13 too13 many13 tasks
bull The13 server13 does13 not13 need13 arficially13 slow13 down13 the13 client13 by13 sending13 late13 ACKsndash No13 need13 to13 keep13 track13 of13 delayed13 ACKsndash The13 server13 can13 perform13 other13 tasks13 instead
bull Reduced13 network13 traffic
Thank13 youQuesons
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-links-json-02txt
123
RFC 6690 (link-format) documents are somewhat foreign to many web app developerssect would prefer to have them in JSON format
There is no standard way to represent link-format documents in applicationssect but everyone knows how to handle JSON
Define a standard JSON translation for link-format
Itrsquos
not
rock
et
scien
ce
ltsensorsgtct=40title=Sensor Index ltsensorstempgtrt=temperature-cif=sensor ltsensorslightgtrt=light-luxif=sensor lthttpwwwexamplecomsensorst123gt anchor=sensorstemprel=describedby lttgtanchor=sensorstemprel=alternate [hrefsensorsct40titleSensor Index hrefsensorstemprttemperature-cifsensor hrefsensorslightrtlight-luxifsensor hrefhttpwwwexamplecomsensorst123 anchorsensorstempreldescribedby hreftanchorsensorstemprelalternate]
124
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-ipsec-for-coap-00txt
IPsec definitions for CoAP Mostly placeholder at this time Who has implementation experience with this
125
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-cross-reverse-convention-00txt
This draft has two lines of payload(based on a WGLC comment by Cullen Jennings)
coap12344567foobara=3
httpwwwproxycomwellknowncore-translate1234_4567foobara=3
Is that a useful convention to have
126
Insert CI slides here
127
128
0
5
10
15
20
25
30
35
40
10 20 30 40 50 60 70
good
put (
pps)
pps
Goodput vs pps (Econotags)
goodput
[Khattak preliminary]
Congestion Control
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-cocoa-00txt
ldquoadvancedrdquo cc (The draft is just a first shot) Others may have better ideas
129
Insert post-WGLC discussion slides here
130
Stop Continue Start
131
An Agile Retrospective
http6lowappnet coreIETF86 2013-03-12-13
Stop
132
Endless new CoAP optionssect instead use RESTful as much as possible
Move general security lifecycle out Looking at theoretical problems
http6lowappnet coreIETF86 2013-03-12-13
Continue
Interops Running code Look at real-world examples and deployments Solve their actual problems
sect Unilateral enhancements eg higher performance congestion control
sect Transports (SMS hellip)sect Make Web linking and Directories more and more usefulsect RESTful Design Paradigms for real-world problems
133
http6lowappnet coreIETF86 2013-03-12-13
Start
Further push into the (browser) web world (HTML5 browser security)
Specific supporting worksect SenMLsect URI work (dev URN hellip)sect Security Processes (next slide)
Spin outsect (We donrsquot really get to decide where this is done)
134
http6lowappnet coreIETF86 2013-03-12-13
Security
Integrate Application Network Group Keyingsect Tunnel-free setup
Donrsquot redo what has been done alreadysect ZigBee IP is finesect But what about other scenarios
Simple REST interfaces for working with keying materials and authorizationsect Start with defining objectives
Object Security for Constrained Nodes135
Re-chartering CoREWhat do we want to do now that wersquore grown up
Zach ShelbyCoRE WG IETF-86 Orlando
What is the scope
bull So we have a protocol and Web Linking what next
bull Keep with what we know besthellip1 Enhancements around CoAP2 New transports for CoAP3 New representations for Web Links4 General application layer solutions
CoRE WG IETF-86 Orlando 2
Enhancements around CoAP
bull Advanced congestion control
CoRE WG IETF-86 Orlando 3
New Transports for CoAP
bull Infrastructure for CoAP over foondash httptoolsietforgiddraft-silverajan-core-
coap-alternative-transports-01txtbull CoAP over SMS
ndash httptoolsietforgiddraft-becker-core-coap-sms-gprs-03txt
ndash OMA Lightweightbull CoAP over TCP
ndash httptoolsietforgiddraft-li-core-coap-payload-length-option-01txt
CoRE WG IETF-86 Orlando 4
New support for Web Links
bull JSON Web Linksndash httptoolsietforgiddraft-bormann-core-links-
json-02txt
2332010 CoRE WG IETF-77 Anaheim 5
General application layer solutions
bull Resource Directoryndash httptoolsietforgiddraft-shelby-core-
resource-directory-05txtndash OMA Lightweight
2332010 CoRE WG IETF-77 Anaheim 6
well-shy‐knownprofile
bull To13 acquire13 profile13 data13 of13 resources13 on13 a13 parcular13 service13 the13 well-shy‐knownprofile13 URI-shy‐path13 is13 introduced
bull For13 example13 to13 get13 all13 informaon13 from13 sensors13 served13 by13 wwwexampleorg13 we13 can13 do13 a13 GET13 to13 coapwwwexampleorgwell-shy‐knownprofile
bull Filtering13 on13 parcular13 resources13 is13 done13 through13 URI-shy‐Queries
Format
bull Currently13 the13 following13 fields13 are13 definedndash ldquopathrdquo13 contains13 the13 URI-shy‐path13 associated13 with13 a13 resource
ndash ldquooprdquo13 a13 numerical13 list13 of13 supported13 opon13 numbers
ndash ldquocfrdquo13 a13 numerical13 list13 of13 supported13 content-shy‐format13 numbers
ndash ldquob1srdquo13 ldquob2srdquo13 supported13 block13 sizes13 for13 Block113 and13 Block213 respecvely
Examplebull On13 the13 right13 is13 an13 example13 of13 a13 camera13 sensor13 at13 coapwwwexampleorgcam13 that13 supports13 the13 Uri-shy‐Host13 (3)13 ETag13 (4)13 Uri-shy‐Port13 (7)13 Uri-shy‐Path13 (11)13 Content-shy‐Format13 (12)13 Token13 (19)13 Block213 (23)13 and13 Proxy-shy‐Uri13 (35)13 opons
bull The13 supported13 content13 formats13 are13 textplain13 (0)13 applicaon13 link-shy‐format13 (40)13 and13 applicaonjson13 (50)
bull The13 supported13 Block213 can13 use13 25613 or13 51213 byte13 blocks
Req13 GET13 coapwwwexampleorgwell-shy‐knownprofile13 Res13 20513 Content13 (applicationjson)13 13 13 13 profile13 13 13 13 13 13 13 13 pathcam13 13 13 13 op[3471112192335]13 13 13 13 13 cf[04050]13 13 13 13 13 b2s[45]13 13 13 13
Filtering13 through13 use13 of13 URI-shy‐Query
bull Filtering13 can13 be13 done13 through13 the13 URI-shy‐Querybull Query13 format13 N=V
ndash N13 is13 a13 profile13 fieldndash V13 is13 the13 desired13 value
bull Examplesndash To13 find13 resources13 that13 support13 content13 format13 ldquoapplicaonjsonrdquo
13 GET13 wwwexampleorgwell-shy‐knownprofilecf=50ndash To13 get13 informaon13 about13 the13 camera
13 GET13 wwwexampleorgwell-shy‐knownprofilepath=cam
Open13 issues
bull Which13 other13 profile13 data13 needs13 signallingndash Content-shy‐type13 for13 different13 methods
bull Fix13 the13 order13 in13 which13 the13 profile13 fields13 must13 appearndash Non-shy‐fixed13 order13 easier13 extensible
bull Inheritance13 of13 a13 profile13 descriponbull Extend13 usage13 to13 signal13 the13 client13 profilebull Integraon13 with13 link13 format
Thank13 youQuesons
drar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval-shy‐00
Bert13 Greevenbosch
Descripon
bull The13 ldquoMinimumRequestInterval13 opon13 can13 be13 used13 to13 indicate13 the13 minimum13 me13 between13 two13 requests13 in13 a13 transacon
bull Originally13 intended13 for13 Block13 but13 also13 usable13 for13 other13 transaconsndash Example13 browsing13 a13 server
bull The13 goal13 is13 to13 reduce13 the13 server13 load13 and13 network13 traffic
bull Link13 hqpsdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval
Usage
bull The13 client13 keeps13 the13 server13 informed13 about13 its13 request13 speed13 through13 inclusion13 of13 the13 ldquoMinimumRequestIntervalrdquo13 opon
bull In13 responses13 the13 server13 fixes13 the13 minimum13 request13 interval13 through13 the13 same13 opon
bull The13 client13 obeys13 the13 speed13 indicated13 by13 the13 server
bull The13 client13 can13 send13 slower13 but13 not13 faster
Advantages
bull The13 server13 has13 means13 to13 limit13 the13 amount13 of13 incoming13 traffic
bull The13 server13 can13 prevent13 to13 become13 overloaded13 with13 too13 many13 tasks
bull The13 server13 does13 not13 need13 arficially13 slow13 down13 the13 client13 by13 sending13 late13 ACKsndash No13 need13 to13 keep13 track13 of13 delayed13 ACKsndash The13 server13 can13 perform13 other13 tasks13 instead
bull Reduced13 network13 traffic
Thank13 youQuesons
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-links-json-02txt
123
RFC 6690 (link-format) documents are somewhat foreign to many web app developerssect would prefer to have them in JSON format
There is no standard way to represent link-format documents in applicationssect but everyone knows how to handle JSON
Define a standard JSON translation for link-format
Itrsquos
not
rock
et
scien
ce
ltsensorsgtct=40title=Sensor Index ltsensorstempgtrt=temperature-cif=sensor ltsensorslightgtrt=light-luxif=sensor lthttpwwwexamplecomsensorst123gt anchor=sensorstemprel=describedby lttgtanchor=sensorstemprel=alternate [hrefsensorsct40titleSensor Index hrefsensorstemprttemperature-cifsensor hrefsensorslightrtlight-luxifsensor hrefhttpwwwexamplecomsensorst123 anchorsensorstempreldescribedby hreftanchorsensorstemprelalternate]
124
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-ipsec-for-coap-00txt
IPsec definitions for CoAP Mostly placeholder at this time Who has implementation experience with this
125
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-cross-reverse-convention-00txt
This draft has two lines of payload(based on a WGLC comment by Cullen Jennings)
coap12344567foobara=3
httpwwwproxycomwellknowncore-translate1234_4567foobara=3
Is that a useful convention to have
126
Insert CI slides here
127
128
0
5
10
15
20
25
30
35
40
10 20 30 40 50 60 70
good
put (
pps)
pps
Goodput vs pps (Econotags)
goodput
[Khattak preliminary]
Congestion Control
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-cocoa-00txt
ldquoadvancedrdquo cc (The draft is just a first shot) Others may have better ideas
129
Insert post-WGLC discussion slides here
130
Stop Continue Start
131
An Agile Retrospective
http6lowappnet coreIETF86 2013-03-12-13
Stop
132
Endless new CoAP optionssect instead use RESTful as much as possible
Move general security lifecycle out Looking at theoretical problems
http6lowappnet coreIETF86 2013-03-12-13
Continue
Interops Running code Look at real-world examples and deployments Solve their actual problems
sect Unilateral enhancements eg higher performance congestion control
sect Transports (SMS hellip)sect Make Web linking and Directories more and more usefulsect RESTful Design Paradigms for real-world problems
133
http6lowappnet coreIETF86 2013-03-12-13
Start
Further push into the (browser) web world (HTML5 browser security)
Specific supporting worksect SenMLsect URI work (dev URN hellip)sect Security Processes (next slide)
Spin outsect (We donrsquot really get to decide where this is done)
134
http6lowappnet coreIETF86 2013-03-12-13
Security
Integrate Application Network Group Keyingsect Tunnel-free setup
Donrsquot redo what has been done alreadysect ZigBee IP is finesect But what about other scenarios
Simple REST interfaces for working with keying materials and authorizationsect Start with defining objectives
Object Security for Constrained Nodes135
Re-chartering CoREWhat do we want to do now that wersquore grown up
Zach ShelbyCoRE WG IETF-86 Orlando
What is the scope
bull So we have a protocol and Web Linking what next
bull Keep with what we know besthellip1 Enhancements around CoAP2 New transports for CoAP3 New representations for Web Links4 General application layer solutions
CoRE WG IETF-86 Orlando 2
Enhancements around CoAP
bull Advanced congestion control
CoRE WG IETF-86 Orlando 3
New Transports for CoAP
bull Infrastructure for CoAP over foondash httptoolsietforgiddraft-silverajan-core-
coap-alternative-transports-01txtbull CoAP over SMS
ndash httptoolsietforgiddraft-becker-core-coap-sms-gprs-03txt
ndash OMA Lightweightbull CoAP over TCP
ndash httptoolsietforgiddraft-li-core-coap-payload-length-option-01txt
CoRE WG IETF-86 Orlando 4
New support for Web Links
bull JSON Web Linksndash httptoolsietforgiddraft-bormann-core-links-
json-02txt
2332010 CoRE WG IETF-77 Anaheim 5
General application layer solutions
bull Resource Directoryndash httptoolsietforgiddraft-shelby-core-
resource-directory-05txtndash OMA Lightweight
2332010 CoRE WG IETF-77 Anaheim 6
Format
bull Currently13 the13 following13 fields13 are13 definedndash ldquopathrdquo13 contains13 the13 URI-shy‐path13 associated13 with13 a13 resource
ndash ldquooprdquo13 a13 numerical13 list13 of13 supported13 opon13 numbers
ndash ldquocfrdquo13 a13 numerical13 list13 of13 supported13 content-shy‐format13 numbers
ndash ldquob1srdquo13 ldquob2srdquo13 supported13 block13 sizes13 for13 Block113 and13 Block213 respecvely
Examplebull On13 the13 right13 is13 an13 example13 of13 a13 camera13 sensor13 at13 coapwwwexampleorgcam13 that13 supports13 the13 Uri-shy‐Host13 (3)13 ETag13 (4)13 Uri-shy‐Port13 (7)13 Uri-shy‐Path13 (11)13 Content-shy‐Format13 (12)13 Token13 (19)13 Block213 (23)13 and13 Proxy-shy‐Uri13 (35)13 opons
bull The13 supported13 content13 formats13 are13 textplain13 (0)13 applicaon13 link-shy‐format13 (40)13 and13 applicaonjson13 (50)
bull The13 supported13 Block213 can13 use13 25613 or13 51213 byte13 blocks
Req13 GET13 coapwwwexampleorgwell-shy‐knownprofile13 Res13 20513 Content13 (applicationjson)13 13 13 13 profile13 13 13 13 13 13 13 13 pathcam13 13 13 13 op[3471112192335]13 13 13 13 13 cf[04050]13 13 13 13 13 b2s[45]13 13 13 13
Filtering13 through13 use13 of13 URI-shy‐Query
bull Filtering13 can13 be13 done13 through13 the13 URI-shy‐Querybull Query13 format13 N=V
ndash N13 is13 a13 profile13 fieldndash V13 is13 the13 desired13 value
bull Examplesndash To13 find13 resources13 that13 support13 content13 format13 ldquoapplicaonjsonrdquo
13 GET13 wwwexampleorgwell-shy‐knownprofilecf=50ndash To13 get13 informaon13 about13 the13 camera
13 GET13 wwwexampleorgwell-shy‐knownprofilepath=cam
Open13 issues
bull Which13 other13 profile13 data13 needs13 signallingndash Content-shy‐type13 for13 different13 methods
bull Fix13 the13 order13 in13 which13 the13 profile13 fields13 must13 appearndash Non-shy‐fixed13 order13 easier13 extensible
bull Inheritance13 of13 a13 profile13 descriponbull Extend13 usage13 to13 signal13 the13 client13 profilebull Integraon13 with13 link13 format
Thank13 youQuesons
drar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval-shy‐00
Bert13 Greevenbosch
Descripon
bull The13 ldquoMinimumRequestInterval13 opon13 can13 be13 used13 to13 indicate13 the13 minimum13 me13 between13 two13 requests13 in13 a13 transacon
bull Originally13 intended13 for13 Block13 but13 also13 usable13 for13 other13 transaconsndash Example13 browsing13 a13 server
bull The13 goal13 is13 to13 reduce13 the13 server13 load13 and13 network13 traffic
bull Link13 hqpsdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval
Usage
bull The13 client13 keeps13 the13 server13 informed13 about13 its13 request13 speed13 through13 inclusion13 of13 the13 ldquoMinimumRequestIntervalrdquo13 opon
bull In13 responses13 the13 server13 fixes13 the13 minimum13 request13 interval13 through13 the13 same13 opon
bull The13 client13 obeys13 the13 speed13 indicated13 by13 the13 server
bull The13 client13 can13 send13 slower13 but13 not13 faster
Advantages
bull The13 server13 has13 means13 to13 limit13 the13 amount13 of13 incoming13 traffic
bull The13 server13 can13 prevent13 to13 become13 overloaded13 with13 too13 many13 tasks
bull The13 server13 does13 not13 need13 arficially13 slow13 down13 the13 client13 by13 sending13 late13 ACKsndash No13 need13 to13 keep13 track13 of13 delayed13 ACKsndash The13 server13 can13 perform13 other13 tasks13 instead
bull Reduced13 network13 traffic
Thank13 youQuesons
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-links-json-02txt
123
RFC 6690 (link-format) documents are somewhat foreign to many web app developerssect would prefer to have them in JSON format
There is no standard way to represent link-format documents in applicationssect but everyone knows how to handle JSON
Define a standard JSON translation for link-format
Itrsquos
not
rock
et
scien
ce
ltsensorsgtct=40title=Sensor Index ltsensorstempgtrt=temperature-cif=sensor ltsensorslightgtrt=light-luxif=sensor lthttpwwwexamplecomsensorst123gt anchor=sensorstemprel=describedby lttgtanchor=sensorstemprel=alternate [hrefsensorsct40titleSensor Index hrefsensorstemprttemperature-cifsensor hrefsensorslightrtlight-luxifsensor hrefhttpwwwexamplecomsensorst123 anchorsensorstempreldescribedby hreftanchorsensorstemprelalternate]
124
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-ipsec-for-coap-00txt
IPsec definitions for CoAP Mostly placeholder at this time Who has implementation experience with this
125
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-cross-reverse-convention-00txt
This draft has two lines of payload(based on a WGLC comment by Cullen Jennings)
coap12344567foobara=3
httpwwwproxycomwellknowncore-translate1234_4567foobara=3
Is that a useful convention to have
126
Insert CI slides here
127
128
0
5
10
15
20
25
30
35
40
10 20 30 40 50 60 70
good
put (
pps)
pps
Goodput vs pps (Econotags)
goodput
[Khattak preliminary]
Congestion Control
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-cocoa-00txt
ldquoadvancedrdquo cc (The draft is just a first shot) Others may have better ideas
129
Insert post-WGLC discussion slides here
130
Stop Continue Start
131
An Agile Retrospective
http6lowappnet coreIETF86 2013-03-12-13
Stop
132
Endless new CoAP optionssect instead use RESTful as much as possible
Move general security lifecycle out Looking at theoretical problems
http6lowappnet coreIETF86 2013-03-12-13
Continue
Interops Running code Look at real-world examples and deployments Solve their actual problems
sect Unilateral enhancements eg higher performance congestion control
sect Transports (SMS hellip)sect Make Web linking and Directories more and more usefulsect RESTful Design Paradigms for real-world problems
133
http6lowappnet coreIETF86 2013-03-12-13
Start
Further push into the (browser) web world (HTML5 browser security)
Specific supporting worksect SenMLsect URI work (dev URN hellip)sect Security Processes (next slide)
Spin outsect (We donrsquot really get to decide where this is done)
134
http6lowappnet coreIETF86 2013-03-12-13
Security
Integrate Application Network Group Keyingsect Tunnel-free setup
Donrsquot redo what has been done alreadysect ZigBee IP is finesect But what about other scenarios
Simple REST interfaces for working with keying materials and authorizationsect Start with defining objectives
Object Security for Constrained Nodes135
Re-chartering CoREWhat do we want to do now that wersquore grown up
Zach ShelbyCoRE WG IETF-86 Orlando
What is the scope
bull So we have a protocol and Web Linking what next
bull Keep with what we know besthellip1 Enhancements around CoAP2 New transports for CoAP3 New representations for Web Links4 General application layer solutions
CoRE WG IETF-86 Orlando 2
Enhancements around CoAP
bull Advanced congestion control
CoRE WG IETF-86 Orlando 3
New Transports for CoAP
bull Infrastructure for CoAP over foondash httptoolsietforgiddraft-silverajan-core-
coap-alternative-transports-01txtbull CoAP over SMS
ndash httptoolsietforgiddraft-becker-core-coap-sms-gprs-03txt
ndash OMA Lightweightbull CoAP over TCP
ndash httptoolsietforgiddraft-li-core-coap-payload-length-option-01txt
CoRE WG IETF-86 Orlando 4
New support for Web Links
bull JSON Web Linksndash httptoolsietforgiddraft-bormann-core-links-
json-02txt
2332010 CoRE WG IETF-77 Anaheim 5
General application layer solutions
bull Resource Directoryndash httptoolsietforgiddraft-shelby-core-
resource-directory-05txtndash OMA Lightweight
2332010 CoRE WG IETF-77 Anaheim 6
Examplebull On13 the13 right13 is13 an13 example13 of13 a13 camera13 sensor13 at13 coapwwwexampleorgcam13 that13 supports13 the13 Uri-shy‐Host13 (3)13 ETag13 (4)13 Uri-shy‐Port13 (7)13 Uri-shy‐Path13 (11)13 Content-shy‐Format13 (12)13 Token13 (19)13 Block213 (23)13 and13 Proxy-shy‐Uri13 (35)13 opons
bull The13 supported13 content13 formats13 are13 textplain13 (0)13 applicaon13 link-shy‐format13 (40)13 and13 applicaonjson13 (50)
bull The13 supported13 Block213 can13 use13 25613 or13 51213 byte13 blocks
Req13 GET13 coapwwwexampleorgwell-shy‐knownprofile13 Res13 20513 Content13 (applicationjson)13 13 13 13 profile13 13 13 13 13 13 13 13 pathcam13 13 13 13 op[3471112192335]13 13 13 13 13 cf[04050]13 13 13 13 13 b2s[45]13 13 13 13
Filtering13 through13 use13 of13 URI-shy‐Query
bull Filtering13 can13 be13 done13 through13 the13 URI-shy‐Querybull Query13 format13 N=V
ndash N13 is13 a13 profile13 fieldndash V13 is13 the13 desired13 value
bull Examplesndash To13 find13 resources13 that13 support13 content13 format13 ldquoapplicaonjsonrdquo
13 GET13 wwwexampleorgwell-shy‐knownprofilecf=50ndash To13 get13 informaon13 about13 the13 camera
13 GET13 wwwexampleorgwell-shy‐knownprofilepath=cam
Open13 issues
bull Which13 other13 profile13 data13 needs13 signallingndash Content-shy‐type13 for13 different13 methods
bull Fix13 the13 order13 in13 which13 the13 profile13 fields13 must13 appearndash Non-shy‐fixed13 order13 easier13 extensible
bull Inheritance13 of13 a13 profile13 descriponbull Extend13 usage13 to13 signal13 the13 client13 profilebull Integraon13 with13 link13 format
Thank13 youQuesons
drar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval-shy‐00
Bert13 Greevenbosch
Descripon
bull The13 ldquoMinimumRequestInterval13 opon13 can13 be13 used13 to13 indicate13 the13 minimum13 me13 between13 two13 requests13 in13 a13 transacon
bull Originally13 intended13 for13 Block13 but13 also13 usable13 for13 other13 transaconsndash Example13 browsing13 a13 server
bull The13 goal13 is13 to13 reduce13 the13 server13 load13 and13 network13 traffic
bull Link13 hqpsdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval
Usage
bull The13 client13 keeps13 the13 server13 informed13 about13 its13 request13 speed13 through13 inclusion13 of13 the13 ldquoMinimumRequestIntervalrdquo13 opon
bull In13 responses13 the13 server13 fixes13 the13 minimum13 request13 interval13 through13 the13 same13 opon
bull The13 client13 obeys13 the13 speed13 indicated13 by13 the13 server
bull The13 client13 can13 send13 slower13 but13 not13 faster
Advantages
bull The13 server13 has13 means13 to13 limit13 the13 amount13 of13 incoming13 traffic
bull The13 server13 can13 prevent13 to13 become13 overloaded13 with13 too13 many13 tasks
bull The13 server13 does13 not13 need13 arficially13 slow13 down13 the13 client13 by13 sending13 late13 ACKsndash No13 need13 to13 keep13 track13 of13 delayed13 ACKsndash The13 server13 can13 perform13 other13 tasks13 instead
bull Reduced13 network13 traffic
Thank13 youQuesons
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-links-json-02txt
123
RFC 6690 (link-format) documents are somewhat foreign to many web app developerssect would prefer to have them in JSON format
There is no standard way to represent link-format documents in applicationssect but everyone knows how to handle JSON
Define a standard JSON translation for link-format
Itrsquos
not
rock
et
scien
ce
ltsensorsgtct=40title=Sensor Index ltsensorstempgtrt=temperature-cif=sensor ltsensorslightgtrt=light-luxif=sensor lthttpwwwexamplecomsensorst123gt anchor=sensorstemprel=describedby lttgtanchor=sensorstemprel=alternate [hrefsensorsct40titleSensor Index hrefsensorstemprttemperature-cifsensor hrefsensorslightrtlight-luxifsensor hrefhttpwwwexamplecomsensorst123 anchorsensorstempreldescribedby hreftanchorsensorstemprelalternate]
124
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-ipsec-for-coap-00txt
IPsec definitions for CoAP Mostly placeholder at this time Who has implementation experience with this
125
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-cross-reverse-convention-00txt
This draft has two lines of payload(based on a WGLC comment by Cullen Jennings)
coap12344567foobara=3
httpwwwproxycomwellknowncore-translate1234_4567foobara=3
Is that a useful convention to have
126
Insert CI slides here
127
128
0
5
10
15
20
25
30
35
40
10 20 30 40 50 60 70
good
put (
pps)
pps
Goodput vs pps (Econotags)
goodput
[Khattak preliminary]
Congestion Control
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-cocoa-00txt
ldquoadvancedrdquo cc (The draft is just a first shot) Others may have better ideas
129
Insert post-WGLC discussion slides here
130
Stop Continue Start
131
An Agile Retrospective
http6lowappnet coreIETF86 2013-03-12-13
Stop
132
Endless new CoAP optionssect instead use RESTful as much as possible
Move general security lifecycle out Looking at theoretical problems
http6lowappnet coreIETF86 2013-03-12-13
Continue
Interops Running code Look at real-world examples and deployments Solve their actual problems
sect Unilateral enhancements eg higher performance congestion control
sect Transports (SMS hellip)sect Make Web linking and Directories more and more usefulsect RESTful Design Paradigms for real-world problems
133
http6lowappnet coreIETF86 2013-03-12-13
Start
Further push into the (browser) web world (HTML5 browser security)
Specific supporting worksect SenMLsect URI work (dev URN hellip)sect Security Processes (next slide)
Spin outsect (We donrsquot really get to decide where this is done)
134
http6lowappnet coreIETF86 2013-03-12-13
Security
Integrate Application Network Group Keyingsect Tunnel-free setup
Donrsquot redo what has been done alreadysect ZigBee IP is finesect But what about other scenarios
Simple REST interfaces for working with keying materials and authorizationsect Start with defining objectives
Object Security for Constrained Nodes135
Re-chartering CoREWhat do we want to do now that wersquore grown up
Zach ShelbyCoRE WG IETF-86 Orlando
What is the scope
bull So we have a protocol and Web Linking what next
bull Keep with what we know besthellip1 Enhancements around CoAP2 New transports for CoAP3 New representations for Web Links4 General application layer solutions
CoRE WG IETF-86 Orlando 2
Enhancements around CoAP
bull Advanced congestion control
CoRE WG IETF-86 Orlando 3
New Transports for CoAP
bull Infrastructure for CoAP over foondash httptoolsietforgiddraft-silverajan-core-
coap-alternative-transports-01txtbull CoAP over SMS
ndash httptoolsietforgiddraft-becker-core-coap-sms-gprs-03txt
ndash OMA Lightweightbull CoAP over TCP
ndash httptoolsietforgiddraft-li-core-coap-payload-length-option-01txt
CoRE WG IETF-86 Orlando 4
New support for Web Links
bull JSON Web Linksndash httptoolsietforgiddraft-bormann-core-links-
json-02txt
2332010 CoRE WG IETF-77 Anaheim 5
General application layer solutions
bull Resource Directoryndash httptoolsietforgiddraft-shelby-core-
resource-directory-05txtndash OMA Lightweight
2332010 CoRE WG IETF-77 Anaheim 6
Filtering13 through13 use13 of13 URI-shy‐Query
bull Filtering13 can13 be13 done13 through13 the13 URI-shy‐Querybull Query13 format13 N=V
ndash N13 is13 a13 profile13 fieldndash V13 is13 the13 desired13 value
bull Examplesndash To13 find13 resources13 that13 support13 content13 format13 ldquoapplicaonjsonrdquo
13 GET13 wwwexampleorgwell-shy‐knownprofilecf=50ndash To13 get13 informaon13 about13 the13 camera
13 GET13 wwwexampleorgwell-shy‐knownprofilepath=cam
Open13 issues
bull Which13 other13 profile13 data13 needs13 signallingndash Content-shy‐type13 for13 different13 methods
bull Fix13 the13 order13 in13 which13 the13 profile13 fields13 must13 appearndash Non-shy‐fixed13 order13 easier13 extensible
bull Inheritance13 of13 a13 profile13 descriponbull Extend13 usage13 to13 signal13 the13 client13 profilebull Integraon13 with13 link13 format
Thank13 youQuesons
drar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval-shy‐00
Bert13 Greevenbosch
Descripon
bull The13 ldquoMinimumRequestInterval13 opon13 can13 be13 used13 to13 indicate13 the13 minimum13 me13 between13 two13 requests13 in13 a13 transacon
bull Originally13 intended13 for13 Block13 but13 also13 usable13 for13 other13 transaconsndash Example13 browsing13 a13 server
bull The13 goal13 is13 to13 reduce13 the13 server13 load13 and13 network13 traffic
bull Link13 hqpsdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval
Usage
bull The13 client13 keeps13 the13 server13 informed13 about13 its13 request13 speed13 through13 inclusion13 of13 the13 ldquoMinimumRequestIntervalrdquo13 opon
bull In13 responses13 the13 server13 fixes13 the13 minimum13 request13 interval13 through13 the13 same13 opon
bull The13 client13 obeys13 the13 speed13 indicated13 by13 the13 server
bull The13 client13 can13 send13 slower13 but13 not13 faster
Advantages
bull The13 server13 has13 means13 to13 limit13 the13 amount13 of13 incoming13 traffic
bull The13 server13 can13 prevent13 to13 become13 overloaded13 with13 too13 many13 tasks
bull The13 server13 does13 not13 need13 arficially13 slow13 down13 the13 client13 by13 sending13 late13 ACKsndash No13 need13 to13 keep13 track13 of13 delayed13 ACKsndash The13 server13 can13 perform13 other13 tasks13 instead
bull Reduced13 network13 traffic
Thank13 youQuesons
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-links-json-02txt
123
RFC 6690 (link-format) documents are somewhat foreign to many web app developerssect would prefer to have them in JSON format
There is no standard way to represent link-format documents in applicationssect but everyone knows how to handle JSON
Define a standard JSON translation for link-format
Itrsquos
not
rock
et
scien
ce
ltsensorsgtct=40title=Sensor Index ltsensorstempgtrt=temperature-cif=sensor ltsensorslightgtrt=light-luxif=sensor lthttpwwwexamplecomsensorst123gt anchor=sensorstemprel=describedby lttgtanchor=sensorstemprel=alternate [hrefsensorsct40titleSensor Index hrefsensorstemprttemperature-cifsensor hrefsensorslightrtlight-luxifsensor hrefhttpwwwexamplecomsensorst123 anchorsensorstempreldescribedby hreftanchorsensorstemprelalternate]
124
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-ipsec-for-coap-00txt
IPsec definitions for CoAP Mostly placeholder at this time Who has implementation experience with this
125
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-cross-reverse-convention-00txt
This draft has two lines of payload(based on a WGLC comment by Cullen Jennings)
coap12344567foobara=3
httpwwwproxycomwellknowncore-translate1234_4567foobara=3
Is that a useful convention to have
126
Insert CI slides here
127
128
0
5
10
15
20
25
30
35
40
10 20 30 40 50 60 70
good
put (
pps)
pps
Goodput vs pps (Econotags)
goodput
[Khattak preliminary]
Congestion Control
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-cocoa-00txt
ldquoadvancedrdquo cc (The draft is just a first shot) Others may have better ideas
129
Insert post-WGLC discussion slides here
130
Stop Continue Start
131
An Agile Retrospective
http6lowappnet coreIETF86 2013-03-12-13
Stop
132
Endless new CoAP optionssect instead use RESTful as much as possible
Move general security lifecycle out Looking at theoretical problems
http6lowappnet coreIETF86 2013-03-12-13
Continue
Interops Running code Look at real-world examples and deployments Solve their actual problems
sect Unilateral enhancements eg higher performance congestion control
sect Transports (SMS hellip)sect Make Web linking and Directories more and more usefulsect RESTful Design Paradigms for real-world problems
133
http6lowappnet coreIETF86 2013-03-12-13
Start
Further push into the (browser) web world (HTML5 browser security)
Specific supporting worksect SenMLsect URI work (dev URN hellip)sect Security Processes (next slide)
Spin outsect (We donrsquot really get to decide where this is done)
134
http6lowappnet coreIETF86 2013-03-12-13
Security
Integrate Application Network Group Keyingsect Tunnel-free setup
Donrsquot redo what has been done alreadysect ZigBee IP is finesect But what about other scenarios
Simple REST interfaces for working with keying materials and authorizationsect Start with defining objectives
Object Security for Constrained Nodes135
Re-chartering CoREWhat do we want to do now that wersquore grown up
Zach ShelbyCoRE WG IETF-86 Orlando
What is the scope
bull So we have a protocol and Web Linking what next
bull Keep with what we know besthellip1 Enhancements around CoAP2 New transports for CoAP3 New representations for Web Links4 General application layer solutions
CoRE WG IETF-86 Orlando 2
Enhancements around CoAP
bull Advanced congestion control
CoRE WG IETF-86 Orlando 3
New Transports for CoAP
bull Infrastructure for CoAP over foondash httptoolsietforgiddraft-silverajan-core-
coap-alternative-transports-01txtbull CoAP over SMS
ndash httptoolsietforgiddraft-becker-core-coap-sms-gprs-03txt
ndash OMA Lightweightbull CoAP over TCP
ndash httptoolsietforgiddraft-li-core-coap-payload-length-option-01txt
CoRE WG IETF-86 Orlando 4
New support for Web Links
bull JSON Web Linksndash httptoolsietforgiddraft-bormann-core-links-
json-02txt
2332010 CoRE WG IETF-77 Anaheim 5
General application layer solutions
bull Resource Directoryndash httptoolsietforgiddraft-shelby-core-
resource-directory-05txtndash OMA Lightweight
2332010 CoRE WG IETF-77 Anaheim 6
Open13 issues
bull Which13 other13 profile13 data13 needs13 signallingndash Content-shy‐type13 for13 different13 methods
bull Fix13 the13 order13 in13 which13 the13 profile13 fields13 must13 appearndash Non-shy‐fixed13 order13 easier13 extensible
bull Inheritance13 of13 a13 profile13 descriponbull Extend13 usage13 to13 signal13 the13 client13 profilebull Integraon13 with13 link13 format
Thank13 youQuesons
drar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval-shy‐00
Bert13 Greevenbosch
Descripon
bull The13 ldquoMinimumRequestInterval13 opon13 can13 be13 used13 to13 indicate13 the13 minimum13 me13 between13 two13 requests13 in13 a13 transacon
bull Originally13 intended13 for13 Block13 but13 also13 usable13 for13 other13 transaconsndash Example13 browsing13 a13 server
bull The13 goal13 is13 to13 reduce13 the13 server13 load13 and13 network13 traffic
bull Link13 hqpsdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval
Usage
bull The13 client13 keeps13 the13 server13 informed13 about13 its13 request13 speed13 through13 inclusion13 of13 the13 ldquoMinimumRequestIntervalrdquo13 opon
bull In13 responses13 the13 server13 fixes13 the13 minimum13 request13 interval13 through13 the13 same13 opon
bull The13 client13 obeys13 the13 speed13 indicated13 by13 the13 server
bull The13 client13 can13 send13 slower13 but13 not13 faster
Advantages
bull The13 server13 has13 means13 to13 limit13 the13 amount13 of13 incoming13 traffic
bull The13 server13 can13 prevent13 to13 become13 overloaded13 with13 too13 many13 tasks
bull The13 server13 does13 not13 need13 arficially13 slow13 down13 the13 client13 by13 sending13 late13 ACKsndash No13 need13 to13 keep13 track13 of13 delayed13 ACKsndash The13 server13 can13 perform13 other13 tasks13 instead
bull Reduced13 network13 traffic
Thank13 youQuesons
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-links-json-02txt
123
RFC 6690 (link-format) documents are somewhat foreign to many web app developerssect would prefer to have them in JSON format
There is no standard way to represent link-format documents in applicationssect but everyone knows how to handle JSON
Define a standard JSON translation for link-format
Itrsquos
not
rock
et
scien
ce
ltsensorsgtct=40title=Sensor Index ltsensorstempgtrt=temperature-cif=sensor ltsensorslightgtrt=light-luxif=sensor lthttpwwwexamplecomsensorst123gt anchor=sensorstemprel=describedby lttgtanchor=sensorstemprel=alternate [hrefsensorsct40titleSensor Index hrefsensorstemprttemperature-cifsensor hrefsensorslightrtlight-luxifsensor hrefhttpwwwexamplecomsensorst123 anchorsensorstempreldescribedby hreftanchorsensorstemprelalternate]
124
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-ipsec-for-coap-00txt
IPsec definitions for CoAP Mostly placeholder at this time Who has implementation experience with this
125
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-cross-reverse-convention-00txt
This draft has two lines of payload(based on a WGLC comment by Cullen Jennings)
coap12344567foobara=3
httpwwwproxycomwellknowncore-translate1234_4567foobara=3
Is that a useful convention to have
126
Insert CI slides here
127
128
0
5
10
15
20
25
30
35
40
10 20 30 40 50 60 70
good
put (
pps)
pps
Goodput vs pps (Econotags)
goodput
[Khattak preliminary]
Congestion Control
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-cocoa-00txt
ldquoadvancedrdquo cc (The draft is just a first shot) Others may have better ideas
129
Insert post-WGLC discussion slides here
130
Stop Continue Start
131
An Agile Retrospective
http6lowappnet coreIETF86 2013-03-12-13
Stop
132
Endless new CoAP optionssect instead use RESTful as much as possible
Move general security lifecycle out Looking at theoretical problems
http6lowappnet coreIETF86 2013-03-12-13
Continue
Interops Running code Look at real-world examples and deployments Solve their actual problems
sect Unilateral enhancements eg higher performance congestion control
sect Transports (SMS hellip)sect Make Web linking and Directories more and more usefulsect RESTful Design Paradigms for real-world problems
133
http6lowappnet coreIETF86 2013-03-12-13
Start
Further push into the (browser) web world (HTML5 browser security)
Specific supporting worksect SenMLsect URI work (dev URN hellip)sect Security Processes (next slide)
Spin outsect (We donrsquot really get to decide where this is done)
134
http6lowappnet coreIETF86 2013-03-12-13
Security
Integrate Application Network Group Keyingsect Tunnel-free setup
Donrsquot redo what has been done alreadysect ZigBee IP is finesect But what about other scenarios
Simple REST interfaces for working with keying materials and authorizationsect Start with defining objectives
Object Security for Constrained Nodes135
Re-chartering CoREWhat do we want to do now that wersquore grown up
Zach ShelbyCoRE WG IETF-86 Orlando
What is the scope
bull So we have a protocol and Web Linking what next
bull Keep with what we know besthellip1 Enhancements around CoAP2 New transports for CoAP3 New representations for Web Links4 General application layer solutions
CoRE WG IETF-86 Orlando 2
Enhancements around CoAP
bull Advanced congestion control
CoRE WG IETF-86 Orlando 3
New Transports for CoAP
bull Infrastructure for CoAP over foondash httptoolsietforgiddraft-silverajan-core-
coap-alternative-transports-01txtbull CoAP over SMS
ndash httptoolsietforgiddraft-becker-core-coap-sms-gprs-03txt
ndash OMA Lightweightbull CoAP over TCP
ndash httptoolsietforgiddraft-li-core-coap-payload-length-option-01txt
CoRE WG IETF-86 Orlando 4
New support for Web Links
bull JSON Web Linksndash httptoolsietforgiddraft-bormann-core-links-
json-02txt
2332010 CoRE WG IETF-77 Anaheim 5
General application layer solutions
bull Resource Directoryndash httptoolsietforgiddraft-shelby-core-
resource-directory-05txtndash OMA Lightweight
2332010 CoRE WG IETF-77 Anaheim 6
Thank13 youQuesons
drar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval-shy‐00
Bert13 Greevenbosch
Descripon
bull The13 ldquoMinimumRequestInterval13 opon13 can13 be13 used13 to13 indicate13 the13 minimum13 me13 between13 two13 requests13 in13 a13 transacon
bull Originally13 intended13 for13 Block13 but13 also13 usable13 for13 other13 transaconsndash Example13 browsing13 a13 server
bull The13 goal13 is13 to13 reduce13 the13 server13 load13 and13 network13 traffic
bull Link13 hqpsdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval
Usage
bull The13 client13 keeps13 the13 server13 informed13 about13 its13 request13 speed13 through13 inclusion13 of13 the13 ldquoMinimumRequestIntervalrdquo13 opon
bull In13 responses13 the13 server13 fixes13 the13 minimum13 request13 interval13 through13 the13 same13 opon
bull The13 client13 obeys13 the13 speed13 indicated13 by13 the13 server
bull The13 client13 can13 send13 slower13 but13 not13 faster
Advantages
bull The13 server13 has13 means13 to13 limit13 the13 amount13 of13 incoming13 traffic
bull The13 server13 can13 prevent13 to13 become13 overloaded13 with13 too13 many13 tasks
bull The13 server13 does13 not13 need13 arficially13 slow13 down13 the13 client13 by13 sending13 late13 ACKsndash No13 need13 to13 keep13 track13 of13 delayed13 ACKsndash The13 server13 can13 perform13 other13 tasks13 instead
bull Reduced13 network13 traffic
Thank13 youQuesons
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-links-json-02txt
123
RFC 6690 (link-format) documents are somewhat foreign to many web app developerssect would prefer to have them in JSON format
There is no standard way to represent link-format documents in applicationssect but everyone knows how to handle JSON
Define a standard JSON translation for link-format
Itrsquos
not
rock
et
scien
ce
ltsensorsgtct=40title=Sensor Index ltsensorstempgtrt=temperature-cif=sensor ltsensorslightgtrt=light-luxif=sensor lthttpwwwexamplecomsensorst123gt anchor=sensorstemprel=describedby lttgtanchor=sensorstemprel=alternate [hrefsensorsct40titleSensor Index hrefsensorstemprttemperature-cifsensor hrefsensorslightrtlight-luxifsensor hrefhttpwwwexamplecomsensorst123 anchorsensorstempreldescribedby hreftanchorsensorstemprelalternate]
124
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-ipsec-for-coap-00txt
IPsec definitions for CoAP Mostly placeholder at this time Who has implementation experience with this
125
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-cross-reverse-convention-00txt
This draft has two lines of payload(based on a WGLC comment by Cullen Jennings)
coap12344567foobara=3
httpwwwproxycomwellknowncore-translate1234_4567foobara=3
Is that a useful convention to have
126
Insert CI slides here
127
128
0
5
10
15
20
25
30
35
40
10 20 30 40 50 60 70
good
put (
pps)
pps
Goodput vs pps (Econotags)
goodput
[Khattak preliminary]
Congestion Control
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-cocoa-00txt
ldquoadvancedrdquo cc (The draft is just a first shot) Others may have better ideas
129
Insert post-WGLC discussion slides here
130
Stop Continue Start
131
An Agile Retrospective
http6lowappnet coreIETF86 2013-03-12-13
Stop
132
Endless new CoAP optionssect instead use RESTful as much as possible
Move general security lifecycle out Looking at theoretical problems
http6lowappnet coreIETF86 2013-03-12-13
Continue
Interops Running code Look at real-world examples and deployments Solve their actual problems
sect Unilateral enhancements eg higher performance congestion control
sect Transports (SMS hellip)sect Make Web linking and Directories more and more usefulsect RESTful Design Paradigms for real-world problems
133
http6lowappnet coreIETF86 2013-03-12-13
Start
Further push into the (browser) web world (HTML5 browser security)
Specific supporting worksect SenMLsect URI work (dev URN hellip)sect Security Processes (next slide)
Spin outsect (We donrsquot really get to decide where this is done)
134
http6lowappnet coreIETF86 2013-03-12-13
Security
Integrate Application Network Group Keyingsect Tunnel-free setup
Donrsquot redo what has been done alreadysect ZigBee IP is finesect But what about other scenarios
Simple REST interfaces for working with keying materials and authorizationsect Start with defining objectives
Object Security for Constrained Nodes135
Re-chartering CoREWhat do we want to do now that wersquore grown up
Zach ShelbyCoRE WG IETF-86 Orlando
What is the scope
bull So we have a protocol and Web Linking what next
bull Keep with what we know besthellip1 Enhancements around CoAP2 New transports for CoAP3 New representations for Web Links4 General application layer solutions
CoRE WG IETF-86 Orlando 2
Enhancements around CoAP
bull Advanced congestion control
CoRE WG IETF-86 Orlando 3
New Transports for CoAP
bull Infrastructure for CoAP over foondash httptoolsietforgiddraft-silverajan-core-
coap-alternative-transports-01txtbull CoAP over SMS
ndash httptoolsietforgiddraft-becker-core-coap-sms-gprs-03txt
ndash OMA Lightweightbull CoAP over TCP
ndash httptoolsietforgiddraft-li-core-coap-payload-length-option-01txt
CoRE WG IETF-86 Orlando 4
New support for Web Links
bull JSON Web Linksndash httptoolsietforgiddraft-bormann-core-links-
json-02txt
2332010 CoRE WG IETF-77 Anaheim 5
General application layer solutions
bull Resource Directoryndash httptoolsietforgiddraft-shelby-core-
resource-directory-05txtndash OMA Lightweight
2332010 CoRE WG IETF-77 Anaheim 6
drar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval-shy‐00
Bert13 Greevenbosch
Descripon
bull The13 ldquoMinimumRequestInterval13 opon13 can13 be13 used13 to13 indicate13 the13 minimum13 me13 between13 two13 requests13 in13 a13 transacon
bull Originally13 intended13 for13 Block13 but13 also13 usable13 for13 other13 transaconsndash Example13 browsing13 a13 server
bull The13 goal13 is13 to13 reduce13 the13 server13 load13 and13 network13 traffic
bull Link13 hqpsdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval
Usage
bull The13 client13 keeps13 the13 server13 informed13 about13 its13 request13 speed13 through13 inclusion13 of13 the13 ldquoMinimumRequestIntervalrdquo13 opon
bull In13 responses13 the13 server13 fixes13 the13 minimum13 request13 interval13 through13 the13 same13 opon
bull The13 client13 obeys13 the13 speed13 indicated13 by13 the13 server
bull The13 client13 can13 send13 slower13 but13 not13 faster
Advantages
bull The13 server13 has13 means13 to13 limit13 the13 amount13 of13 incoming13 traffic
bull The13 server13 can13 prevent13 to13 become13 overloaded13 with13 too13 many13 tasks
bull The13 server13 does13 not13 need13 arficially13 slow13 down13 the13 client13 by13 sending13 late13 ACKsndash No13 need13 to13 keep13 track13 of13 delayed13 ACKsndash The13 server13 can13 perform13 other13 tasks13 instead
bull Reduced13 network13 traffic
Thank13 youQuesons
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-links-json-02txt
123
RFC 6690 (link-format) documents are somewhat foreign to many web app developerssect would prefer to have them in JSON format
There is no standard way to represent link-format documents in applicationssect but everyone knows how to handle JSON
Define a standard JSON translation for link-format
Itrsquos
not
rock
et
scien
ce
ltsensorsgtct=40title=Sensor Index ltsensorstempgtrt=temperature-cif=sensor ltsensorslightgtrt=light-luxif=sensor lthttpwwwexamplecomsensorst123gt anchor=sensorstemprel=describedby lttgtanchor=sensorstemprel=alternate [hrefsensorsct40titleSensor Index hrefsensorstemprttemperature-cifsensor hrefsensorslightrtlight-luxifsensor hrefhttpwwwexamplecomsensorst123 anchorsensorstempreldescribedby hreftanchorsensorstemprelalternate]
124
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-ipsec-for-coap-00txt
IPsec definitions for CoAP Mostly placeholder at this time Who has implementation experience with this
125
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-cross-reverse-convention-00txt
This draft has two lines of payload(based on a WGLC comment by Cullen Jennings)
coap12344567foobara=3
httpwwwproxycomwellknowncore-translate1234_4567foobara=3
Is that a useful convention to have
126
Insert CI slides here
127
128
0
5
10
15
20
25
30
35
40
10 20 30 40 50 60 70
good
put (
pps)
pps
Goodput vs pps (Econotags)
goodput
[Khattak preliminary]
Congestion Control
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-cocoa-00txt
ldquoadvancedrdquo cc (The draft is just a first shot) Others may have better ideas
129
Insert post-WGLC discussion slides here
130
Stop Continue Start
131
An Agile Retrospective
http6lowappnet coreIETF86 2013-03-12-13
Stop
132
Endless new CoAP optionssect instead use RESTful as much as possible
Move general security lifecycle out Looking at theoretical problems
http6lowappnet coreIETF86 2013-03-12-13
Continue
Interops Running code Look at real-world examples and deployments Solve their actual problems
sect Unilateral enhancements eg higher performance congestion control
sect Transports (SMS hellip)sect Make Web linking and Directories more and more usefulsect RESTful Design Paradigms for real-world problems
133
http6lowappnet coreIETF86 2013-03-12-13
Start
Further push into the (browser) web world (HTML5 browser security)
Specific supporting worksect SenMLsect URI work (dev URN hellip)sect Security Processes (next slide)
Spin outsect (We donrsquot really get to decide where this is done)
134
http6lowappnet coreIETF86 2013-03-12-13
Security
Integrate Application Network Group Keyingsect Tunnel-free setup
Donrsquot redo what has been done alreadysect ZigBee IP is finesect But what about other scenarios
Simple REST interfaces for working with keying materials and authorizationsect Start with defining objectives
Object Security for Constrained Nodes135
Re-chartering CoREWhat do we want to do now that wersquore grown up
Zach ShelbyCoRE WG IETF-86 Orlando
What is the scope
bull So we have a protocol and Web Linking what next
bull Keep with what we know besthellip1 Enhancements around CoAP2 New transports for CoAP3 New representations for Web Links4 General application layer solutions
CoRE WG IETF-86 Orlando 2
Enhancements around CoAP
bull Advanced congestion control
CoRE WG IETF-86 Orlando 3
New Transports for CoAP
bull Infrastructure for CoAP over foondash httptoolsietforgiddraft-silverajan-core-
coap-alternative-transports-01txtbull CoAP over SMS
ndash httptoolsietforgiddraft-becker-core-coap-sms-gprs-03txt
ndash OMA Lightweightbull CoAP over TCP
ndash httptoolsietforgiddraft-li-core-coap-payload-length-option-01txt
CoRE WG IETF-86 Orlando 4
New support for Web Links
bull JSON Web Linksndash httptoolsietforgiddraft-bormann-core-links-
json-02txt
2332010 CoRE WG IETF-77 Anaheim 5
General application layer solutions
bull Resource Directoryndash httptoolsietforgiddraft-shelby-core-
resource-directory-05txtndash OMA Lightweight
2332010 CoRE WG IETF-77 Anaheim 6
Descripon
bull The13 ldquoMinimumRequestInterval13 opon13 can13 be13 used13 to13 indicate13 the13 minimum13 me13 between13 two13 requests13 in13 a13 transacon
bull Originally13 intended13 for13 Block13 but13 also13 usable13 for13 other13 transaconsndash Example13 browsing13 a13 server
bull The13 goal13 is13 to13 reduce13 the13 server13 load13 and13 network13 traffic
bull Link13 hqpsdatatrackerieporgdocdrar-shy‐greevenbosch-shy‐core-shy‐minimum-shy‐request-shy‐interval
Usage
bull The13 client13 keeps13 the13 server13 informed13 about13 its13 request13 speed13 through13 inclusion13 of13 the13 ldquoMinimumRequestIntervalrdquo13 opon
bull In13 responses13 the13 server13 fixes13 the13 minimum13 request13 interval13 through13 the13 same13 opon
bull The13 client13 obeys13 the13 speed13 indicated13 by13 the13 server
bull The13 client13 can13 send13 slower13 but13 not13 faster
Advantages
bull The13 server13 has13 means13 to13 limit13 the13 amount13 of13 incoming13 traffic
bull The13 server13 can13 prevent13 to13 become13 overloaded13 with13 too13 many13 tasks
bull The13 server13 does13 not13 need13 arficially13 slow13 down13 the13 client13 by13 sending13 late13 ACKsndash No13 need13 to13 keep13 track13 of13 delayed13 ACKsndash The13 server13 can13 perform13 other13 tasks13 instead
bull Reduced13 network13 traffic
Thank13 youQuesons
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-links-json-02txt
123
RFC 6690 (link-format) documents are somewhat foreign to many web app developerssect would prefer to have them in JSON format
There is no standard way to represent link-format documents in applicationssect but everyone knows how to handle JSON
Define a standard JSON translation for link-format
Itrsquos
not
rock
et
scien
ce
ltsensorsgtct=40title=Sensor Index ltsensorstempgtrt=temperature-cif=sensor ltsensorslightgtrt=light-luxif=sensor lthttpwwwexamplecomsensorst123gt anchor=sensorstemprel=describedby lttgtanchor=sensorstemprel=alternate [hrefsensorsct40titleSensor Index hrefsensorstemprttemperature-cifsensor hrefsensorslightrtlight-luxifsensor hrefhttpwwwexamplecomsensorst123 anchorsensorstempreldescribedby hreftanchorsensorstemprelalternate]
124
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-ipsec-for-coap-00txt
IPsec definitions for CoAP Mostly placeholder at this time Who has implementation experience with this
125
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-cross-reverse-convention-00txt
This draft has two lines of payload(based on a WGLC comment by Cullen Jennings)
coap12344567foobara=3
httpwwwproxycomwellknowncore-translate1234_4567foobara=3
Is that a useful convention to have
126
Insert CI slides here
127
128
0
5
10
15
20
25
30
35
40
10 20 30 40 50 60 70
good
put (
pps)
pps
Goodput vs pps (Econotags)
goodput
[Khattak preliminary]
Congestion Control
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-cocoa-00txt
ldquoadvancedrdquo cc (The draft is just a first shot) Others may have better ideas
129
Insert post-WGLC discussion slides here
130
Stop Continue Start
131
An Agile Retrospective
http6lowappnet coreIETF86 2013-03-12-13
Stop
132
Endless new CoAP optionssect instead use RESTful as much as possible
Move general security lifecycle out Looking at theoretical problems
http6lowappnet coreIETF86 2013-03-12-13
Continue
Interops Running code Look at real-world examples and deployments Solve their actual problems
sect Unilateral enhancements eg higher performance congestion control
sect Transports (SMS hellip)sect Make Web linking and Directories more and more usefulsect RESTful Design Paradigms for real-world problems
133
http6lowappnet coreIETF86 2013-03-12-13
Start
Further push into the (browser) web world (HTML5 browser security)
Specific supporting worksect SenMLsect URI work (dev URN hellip)sect Security Processes (next slide)
Spin outsect (We donrsquot really get to decide where this is done)
134
http6lowappnet coreIETF86 2013-03-12-13
Security
Integrate Application Network Group Keyingsect Tunnel-free setup
Donrsquot redo what has been done alreadysect ZigBee IP is finesect But what about other scenarios
Simple REST interfaces for working with keying materials and authorizationsect Start with defining objectives
Object Security for Constrained Nodes135
Re-chartering CoREWhat do we want to do now that wersquore grown up
Zach ShelbyCoRE WG IETF-86 Orlando
What is the scope
bull So we have a protocol and Web Linking what next
bull Keep with what we know besthellip1 Enhancements around CoAP2 New transports for CoAP3 New representations for Web Links4 General application layer solutions
CoRE WG IETF-86 Orlando 2
Enhancements around CoAP
bull Advanced congestion control
CoRE WG IETF-86 Orlando 3
New Transports for CoAP
bull Infrastructure for CoAP over foondash httptoolsietforgiddraft-silverajan-core-
coap-alternative-transports-01txtbull CoAP over SMS
ndash httptoolsietforgiddraft-becker-core-coap-sms-gprs-03txt
ndash OMA Lightweightbull CoAP over TCP
ndash httptoolsietforgiddraft-li-core-coap-payload-length-option-01txt
CoRE WG IETF-86 Orlando 4
New support for Web Links
bull JSON Web Linksndash httptoolsietforgiddraft-bormann-core-links-
json-02txt
2332010 CoRE WG IETF-77 Anaheim 5
General application layer solutions
bull Resource Directoryndash httptoolsietforgiddraft-shelby-core-
resource-directory-05txtndash OMA Lightweight
2332010 CoRE WG IETF-77 Anaheim 6
Usage
bull The13 client13 keeps13 the13 server13 informed13 about13 its13 request13 speed13 through13 inclusion13 of13 the13 ldquoMinimumRequestIntervalrdquo13 opon
bull In13 responses13 the13 server13 fixes13 the13 minimum13 request13 interval13 through13 the13 same13 opon
bull The13 client13 obeys13 the13 speed13 indicated13 by13 the13 server
bull The13 client13 can13 send13 slower13 but13 not13 faster
Advantages
bull The13 server13 has13 means13 to13 limit13 the13 amount13 of13 incoming13 traffic
bull The13 server13 can13 prevent13 to13 become13 overloaded13 with13 too13 many13 tasks
bull The13 server13 does13 not13 need13 arficially13 slow13 down13 the13 client13 by13 sending13 late13 ACKsndash No13 need13 to13 keep13 track13 of13 delayed13 ACKsndash The13 server13 can13 perform13 other13 tasks13 instead
bull Reduced13 network13 traffic
Thank13 youQuesons
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-links-json-02txt
123
RFC 6690 (link-format) documents are somewhat foreign to many web app developerssect would prefer to have them in JSON format
There is no standard way to represent link-format documents in applicationssect but everyone knows how to handle JSON
Define a standard JSON translation for link-format
Itrsquos
not
rock
et
scien
ce
ltsensorsgtct=40title=Sensor Index ltsensorstempgtrt=temperature-cif=sensor ltsensorslightgtrt=light-luxif=sensor lthttpwwwexamplecomsensorst123gt anchor=sensorstemprel=describedby lttgtanchor=sensorstemprel=alternate [hrefsensorsct40titleSensor Index hrefsensorstemprttemperature-cifsensor hrefsensorslightrtlight-luxifsensor hrefhttpwwwexamplecomsensorst123 anchorsensorstempreldescribedby hreftanchorsensorstemprelalternate]
124
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-ipsec-for-coap-00txt
IPsec definitions for CoAP Mostly placeholder at this time Who has implementation experience with this
125
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-cross-reverse-convention-00txt
This draft has two lines of payload(based on a WGLC comment by Cullen Jennings)
coap12344567foobara=3
httpwwwproxycomwellknowncore-translate1234_4567foobara=3
Is that a useful convention to have
126
Insert CI slides here
127
128
0
5
10
15
20
25
30
35
40
10 20 30 40 50 60 70
good
put (
pps)
pps
Goodput vs pps (Econotags)
goodput
[Khattak preliminary]
Congestion Control
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-cocoa-00txt
ldquoadvancedrdquo cc (The draft is just a first shot) Others may have better ideas
129
Insert post-WGLC discussion slides here
130
Stop Continue Start
131
An Agile Retrospective
http6lowappnet coreIETF86 2013-03-12-13
Stop
132
Endless new CoAP optionssect instead use RESTful as much as possible
Move general security lifecycle out Looking at theoretical problems
http6lowappnet coreIETF86 2013-03-12-13
Continue
Interops Running code Look at real-world examples and deployments Solve their actual problems
sect Unilateral enhancements eg higher performance congestion control
sect Transports (SMS hellip)sect Make Web linking and Directories more and more usefulsect RESTful Design Paradigms for real-world problems
133
http6lowappnet coreIETF86 2013-03-12-13
Start
Further push into the (browser) web world (HTML5 browser security)
Specific supporting worksect SenMLsect URI work (dev URN hellip)sect Security Processes (next slide)
Spin outsect (We donrsquot really get to decide where this is done)
134
http6lowappnet coreIETF86 2013-03-12-13
Security
Integrate Application Network Group Keyingsect Tunnel-free setup
Donrsquot redo what has been done alreadysect ZigBee IP is finesect But what about other scenarios
Simple REST interfaces for working with keying materials and authorizationsect Start with defining objectives
Object Security for Constrained Nodes135
Re-chartering CoREWhat do we want to do now that wersquore grown up
Zach ShelbyCoRE WG IETF-86 Orlando
What is the scope
bull So we have a protocol and Web Linking what next
bull Keep with what we know besthellip1 Enhancements around CoAP2 New transports for CoAP3 New representations for Web Links4 General application layer solutions
CoRE WG IETF-86 Orlando 2
Enhancements around CoAP
bull Advanced congestion control
CoRE WG IETF-86 Orlando 3
New Transports for CoAP
bull Infrastructure for CoAP over foondash httptoolsietforgiddraft-silverajan-core-
coap-alternative-transports-01txtbull CoAP over SMS
ndash httptoolsietforgiddraft-becker-core-coap-sms-gprs-03txt
ndash OMA Lightweightbull CoAP over TCP
ndash httptoolsietforgiddraft-li-core-coap-payload-length-option-01txt
CoRE WG IETF-86 Orlando 4
New support for Web Links
bull JSON Web Linksndash httptoolsietforgiddraft-bormann-core-links-
json-02txt
2332010 CoRE WG IETF-77 Anaheim 5
General application layer solutions
bull Resource Directoryndash httptoolsietforgiddraft-shelby-core-
resource-directory-05txtndash OMA Lightweight
2332010 CoRE WG IETF-77 Anaheim 6
Advantages
bull The13 server13 has13 means13 to13 limit13 the13 amount13 of13 incoming13 traffic
bull The13 server13 can13 prevent13 to13 become13 overloaded13 with13 too13 many13 tasks
bull The13 server13 does13 not13 need13 arficially13 slow13 down13 the13 client13 by13 sending13 late13 ACKsndash No13 need13 to13 keep13 track13 of13 delayed13 ACKsndash The13 server13 can13 perform13 other13 tasks13 instead
bull Reduced13 network13 traffic
Thank13 youQuesons
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-links-json-02txt
123
RFC 6690 (link-format) documents are somewhat foreign to many web app developerssect would prefer to have them in JSON format
There is no standard way to represent link-format documents in applicationssect but everyone knows how to handle JSON
Define a standard JSON translation for link-format
Itrsquos
not
rock
et
scien
ce
ltsensorsgtct=40title=Sensor Index ltsensorstempgtrt=temperature-cif=sensor ltsensorslightgtrt=light-luxif=sensor lthttpwwwexamplecomsensorst123gt anchor=sensorstemprel=describedby lttgtanchor=sensorstemprel=alternate [hrefsensorsct40titleSensor Index hrefsensorstemprttemperature-cifsensor hrefsensorslightrtlight-luxifsensor hrefhttpwwwexamplecomsensorst123 anchorsensorstempreldescribedby hreftanchorsensorstemprelalternate]
124
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-ipsec-for-coap-00txt
IPsec definitions for CoAP Mostly placeholder at this time Who has implementation experience with this
125
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-cross-reverse-convention-00txt
This draft has two lines of payload(based on a WGLC comment by Cullen Jennings)
coap12344567foobara=3
httpwwwproxycomwellknowncore-translate1234_4567foobara=3
Is that a useful convention to have
126
Insert CI slides here
127
128
0
5
10
15
20
25
30
35
40
10 20 30 40 50 60 70
good
put (
pps)
pps
Goodput vs pps (Econotags)
goodput
[Khattak preliminary]
Congestion Control
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-cocoa-00txt
ldquoadvancedrdquo cc (The draft is just a first shot) Others may have better ideas
129
Insert post-WGLC discussion slides here
130
Stop Continue Start
131
An Agile Retrospective
http6lowappnet coreIETF86 2013-03-12-13
Stop
132
Endless new CoAP optionssect instead use RESTful as much as possible
Move general security lifecycle out Looking at theoretical problems
http6lowappnet coreIETF86 2013-03-12-13
Continue
Interops Running code Look at real-world examples and deployments Solve their actual problems
sect Unilateral enhancements eg higher performance congestion control
sect Transports (SMS hellip)sect Make Web linking and Directories more and more usefulsect RESTful Design Paradigms for real-world problems
133
http6lowappnet coreIETF86 2013-03-12-13
Start
Further push into the (browser) web world (HTML5 browser security)
Specific supporting worksect SenMLsect URI work (dev URN hellip)sect Security Processes (next slide)
Spin outsect (We donrsquot really get to decide where this is done)
134
http6lowappnet coreIETF86 2013-03-12-13
Security
Integrate Application Network Group Keyingsect Tunnel-free setup
Donrsquot redo what has been done alreadysect ZigBee IP is finesect But what about other scenarios
Simple REST interfaces for working with keying materials and authorizationsect Start with defining objectives
Object Security for Constrained Nodes135
Re-chartering CoREWhat do we want to do now that wersquore grown up
Zach ShelbyCoRE WG IETF-86 Orlando
What is the scope
bull So we have a protocol and Web Linking what next
bull Keep with what we know besthellip1 Enhancements around CoAP2 New transports for CoAP3 New representations for Web Links4 General application layer solutions
CoRE WG IETF-86 Orlando 2
Enhancements around CoAP
bull Advanced congestion control
CoRE WG IETF-86 Orlando 3
New Transports for CoAP
bull Infrastructure for CoAP over foondash httptoolsietforgiddraft-silverajan-core-
coap-alternative-transports-01txtbull CoAP over SMS
ndash httptoolsietforgiddraft-becker-core-coap-sms-gprs-03txt
ndash OMA Lightweightbull CoAP over TCP
ndash httptoolsietforgiddraft-li-core-coap-payload-length-option-01txt
CoRE WG IETF-86 Orlando 4
New support for Web Links
bull JSON Web Linksndash httptoolsietforgiddraft-bormann-core-links-
json-02txt
2332010 CoRE WG IETF-77 Anaheim 5
General application layer solutions
bull Resource Directoryndash httptoolsietforgiddraft-shelby-core-
resource-directory-05txtndash OMA Lightweight
2332010 CoRE WG IETF-77 Anaheim 6
Thank13 youQuesons
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-links-json-02txt
123
RFC 6690 (link-format) documents are somewhat foreign to many web app developerssect would prefer to have them in JSON format
There is no standard way to represent link-format documents in applicationssect but everyone knows how to handle JSON
Define a standard JSON translation for link-format
Itrsquos
not
rock
et
scien
ce
ltsensorsgtct=40title=Sensor Index ltsensorstempgtrt=temperature-cif=sensor ltsensorslightgtrt=light-luxif=sensor lthttpwwwexamplecomsensorst123gt anchor=sensorstemprel=describedby lttgtanchor=sensorstemprel=alternate [hrefsensorsct40titleSensor Index hrefsensorstemprttemperature-cifsensor hrefsensorslightrtlight-luxifsensor hrefhttpwwwexamplecomsensorst123 anchorsensorstempreldescribedby hreftanchorsensorstemprelalternate]
124
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-ipsec-for-coap-00txt
IPsec definitions for CoAP Mostly placeholder at this time Who has implementation experience with this
125
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-cross-reverse-convention-00txt
This draft has two lines of payload(based on a WGLC comment by Cullen Jennings)
coap12344567foobara=3
httpwwwproxycomwellknowncore-translate1234_4567foobara=3
Is that a useful convention to have
126
Insert CI slides here
127
128
0
5
10
15
20
25
30
35
40
10 20 30 40 50 60 70
good
put (
pps)
pps
Goodput vs pps (Econotags)
goodput
[Khattak preliminary]
Congestion Control
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-cocoa-00txt
ldquoadvancedrdquo cc (The draft is just a first shot) Others may have better ideas
129
Insert post-WGLC discussion slides here
130
Stop Continue Start
131
An Agile Retrospective
http6lowappnet coreIETF86 2013-03-12-13
Stop
132
Endless new CoAP optionssect instead use RESTful as much as possible
Move general security lifecycle out Looking at theoretical problems
http6lowappnet coreIETF86 2013-03-12-13
Continue
Interops Running code Look at real-world examples and deployments Solve their actual problems
sect Unilateral enhancements eg higher performance congestion control
sect Transports (SMS hellip)sect Make Web linking and Directories more and more usefulsect RESTful Design Paradigms for real-world problems
133
http6lowappnet coreIETF86 2013-03-12-13
Start
Further push into the (browser) web world (HTML5 browser security)
Specific supporting worksect SenMLsect URI work (dev URN hellip)sect Security Processes (next slide)
Spin outsect (We donrsquot really get to decide where this is done)
134
http6lowappnet coreIETF86 2013-03-12-13
Security
Integrate Application Network Group Keyingsect Tunnel-free setup
Donrsquot redo what has been done alreadysect ZigBee IP is finesect But what about other scenarios
Simple REST interfaces for working with keying materials and authorizationsect Start with defining objectives
Object Security for Constrained Nodes135
Re-chartering CoREWhat do we want to do now that wersquore grown up
Zach ShelbyCoRE WG IETF-86 Orlando
What is the scope
bull So we have a protocol and Web Linking what next
bull Keep with what we know besthellip1 Enhancements around CoAP2 New transports for CoAP3 New representations for Web Links4 General application layer solutions
CoRE WG IETF-86 Orlando 2
Enhancements around CoAP
bull Advanced congestion control
CoRE WG IETF-86 Orlando 3
New Transports for CoAP
bull Infrastructure for CoAP over foondash httptoolsietforgiddraft-silverajan-core-
coap-alternative-transports-01txtbull CoAP over SMS
ndash httptoolsietforgiddraft-becker-core-coap-sms-gprs-03txt
ndash OMA Lightweightbull CoAP over TCP
ndash httptoolsietforgiddraft-li-core-coap-payload-length-option-01txt
CoRE WG IETF-86 Orlando 4
New support for Web Links
bull JSON Web Linksndash httptoolsietforgiddraft-bormann-core-links-
json-02txt
2332010 CoRE WG IETF-77 Anaheim 5
General application layer solutions
bull Resource Directoryndash httptoolsietforgiddraft-shelby-core-
resource-directory-05txtndash OMA Lightweight
2332010 CoRE WG IETF-77 Anaheim 6
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-links-json-02txt
123
RFC 6690 (link-format) documents are somewhat foreign to many web app developerssect would prefer to have them in JSON format
There is no standard way to represent link-format documents in applicationssect but everyone knows how to handle JSON
Define a standard JSON translation for link-format
Itrsquos
not
rock
et
scien
ce
ltsensorsgtct=40title=Sensor Index ltsensorstempgtrt=temperature-cif=sensor ltsensorslightgtrt=light-luxif=sensor lthttpwwwexamplecomsensorst123gt anchor=sensorstemprel=describedby lttgtanchor=sensorstemprel=alternate [hrefsensorsct40titleSensor Index hrefsensorstemprttemperature-cifsensor hrefsensorslightrtlight-luxifsensor hrefhttpwwwexamplecomsensorst123 anchorsensorstempreldescribedby hreftanchorsensorstemprelalternate]
124
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-ipsec-for-coap-00txt
IPsec definitions for CoAP Mostly placeholder at this time Who has implementation experience with this
125
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-cross-reverse-convention-00txt
This draft has two lines of payload(based on a WGLC comment by Cullen Jennings)
coap12344567foobara=3
httpwwwproxycomwellknowncore-translate1234_4567foobara=3
Is that a useful convention to have
126
Insert CI slides here
127
128
0
5
10
15
20
25
30
35
40
10 20 30 40 50 60 70
good
put (
pps)
pps
Goodput vs pps (Econotags)
goodput
[Khattak preliminary]
Congestion Control
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-cocoa-00txt
ldquoadvancedrdquo cc (The draft is just a first shot) Others may have better ideas
129
Insert post-WGLC discussion slides here
130
Stop Continue Start
131
An Agile Retrospective
http6lowappnet coreIETF86 2013-03-12-13
Stop
132
Endless new CoAP optionssect instead use RESTful as much as possible
Move general security lifecycle out Looking at theoretical problems
http6lowappnet coreIETF86 2013-03-12-13
Continue
Interops Running code Look at real-world examples and deployments Solve their actual problems
sect Unilateral enhancements eg higher performance congestion control
sect Transports (SMS hellip)sect Make Web linking and Directories more and more usefulsect RESTful Design Paradigms for real-world problems
133
http6lowappnet coreIETF86 2013-03-12-13
Start
Further push into the (browser) web world (HTML5 browser security)
Specific supporting worksect SenMLsect URI work (dev URN hellip)sect Security Processes (next slide)
Spin outsect (We donrsquot really get to decide where this is done)
134
http6lowappnet coreIETF86 2013-03-12-13
Security
Integrate Application Network Group Keyingsect Tunnel-free setup
Donrsquot redo what has been done alreadysect ZigBee IP is finesect But what about other scenarios
Simple REST interfaces for working with keying materials and authorizationsect Start with defining objectives
Object Security for Constrained Nodes135
Re-chartering CoREWhat do we want to do now that wersquore grown up
Zach ShelbyCoRE WG IETF-86 Orlando
What is the scope
bull So we have a protocol and Web Linking what next
bull Keep with what we know besthellip1 Enhancements around CoAP2 New transports for CoAP3 New representations for Web Links4 General application layer solutions
CoRE WG IETF-86 Orlando 2
Enhancements around CoAP
bull Advanced congestion control
CoRE WG IETF-86 Orlando 3
New Transports for CoAP
bull Infrastructure for CoAP over foondash httptoolsietforgiddraft-silverajan-core-
coap-alternative-transports-01txtbull CoAP over SMS
ndash httptoolsietforgiddraft-becker-core-coap-sms-gprs-03txt
ndash OMA Lightweightbull CoAP over TCP
ndash httptoolsietforgiddraft-li-core-coap-payload-length-option-01txt
CoRE WG IETF-86 Orlando 4
New support for Web Links
bull JSON Web Linksndash httptoolsietforgiddraft-bormann-core-links-
json-02txt
2332010 CoRE WG IETF-77 Anaheim 5
General application layer solutions
bull Resource Directoryndash httptoolsietforgiddraft-shelby-core-
resource-directory-05txtndash OMA Lightweight
2332010 CoRE WG IETF-77 Anaheim 6
ltsensorsgtct=40title=Sensor Index ltsensorstempgtrt=temperature-cif=sensor ltsensorslightgtrt=light-luxif=sensor lthttpwwwexamplecomsensorst123gt anchor=sensorstemprel=describedby lttgtanchor=sensorstemprel=alternate [hrefsensorsct40titleSensor Index hrefsensorstemprttemperature-cifsensor hrefsensorslightrtlight-luxifsensor hrefhttpwwwexamplecomsensorst123 anchorsensorstempreldescribedby hreftanchorsensorstemprelalternate]
124
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-ipsec-for-coap-00txt
IPsec definitions for CoAP Mostly placeholder at this time Who has implementation experience with this
125
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-cross-reverse-convention-00txt
This draft has two lines of payload(based on a WGLC comment by Cullen Jennings)
coap12344567foobara=3
httpwwwproxycomwellknowncore-translate1234_4567foobara=3
Is that a useful convention to have
126
Insert CI slides here
127
128
0
5
10
15
20
25
30
35
40
10 20 30 40 50 60 70
good
put (
pps)
pps
Goodput vs pps (Econotags)
goodput
[Khattak preliminary]
Congestion Control
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-cocoa-00txt
ldquoadvancedrdquo cc (The draft is just a first shot) Others may have better ideas
129
Insert post-WGLC discussion slides here
130
Stop Continue Start
131
An Agile Retrospective
http6lowappnet coreIETF86 2013-03-12-13
Stop
132
Endless new CoAP optionssect instead use RESTful as much as possible
Move general security lifecycle out Looking at theoretical problems
http6lowappnet coreIETF86 2013-03-12-13
Continue
Interops Running code Look at real-world examples and deployments Solve their actual problems
sect Unilateral enhancements eg higher performance congestion control
sect Transports (SMS hellip)sect Make Web linking and Directories more and more usefulsect RESTful Design Paradigms for real-world problems
133
http6lowappnet coreIETF86 2013-03-12-13
Start
Further push into the (browser) web world (HTML5 browser security)
Specific supporting worksect SenMLsect URI work (dev URN hellip)sect Security Processes (next slide)
Spin outsect (We donrsquot really get to decide where this is done)
134
http6lowappnet coreIETF86 2013-03-12-13
Security
Integrate Application Network Group Keyingsect Tunnel-free setup
Donrsquot redo what has been done alreadysect ZigBee IP is finesect But what about other scenarios
Simple REST interfaces for working with keying materials and authorizationsect Start with defining objectives
Object Security for Constrained Nodes135
Re-chartering CoREWhat do we want to do now that wersquore grown up
Zach ShelbyCoRE WG IETF-86 Orlando
What is the scope
bull So we have a protocol and Web Linking what next
bull Keep with what we know besthellip1 Enhancements around CoAP2 New transports for CoAP3 New representations for Web Links4 General application layer solutions
CoRE WG IETF-86 Orlando 2
Enhancements around CoAP
bull Advanced congestion control
CoRE WG IETF-86 Orlando 3
New Transports for CoAP
bull Infrastructure for CoAP over foondash httptoolsietforgiddraft-silverajan-core-
coap-alternative-transports-01txtbull CoAP over SMS
ndash httptoolsietforgiddraft-becker-core-coap-sms-gprs-03txt
ndash OMA Lightweightbull CoAP over TCP
ndash httptoolsietforgiddraft-li-core-coap-payload-length-option-01txt
CoRE WG IETF-86 Orlando 4
New support for Web Links
bull JSON Web Linksndash httptoolsietforgiddraft-bormann-core-links-
json-02txt
2332010 CoRE WG IETF-77 Anaheim 5
General application layer solutions
bull Resource Directoryndash httptoolsietforgiddraft-shelby-core-
resource-directory-05txtndash OMA Lightweight
2332010 CoRE WG IETF-77 Anaheim 6
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-ipsec-for-coap-00txt
IPsec definitions for CoAP Mostly placeholder at this time Who has implementation experience with this
125
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-cross-reverse-convention-00txt
This draft has two lines of payload(based on a WGLC comment by Cullen Jennings)
coap12344567foobara=3
httpwwwproxycomwellknowncore-translate1234_4567foobara=3
Is that a useful convention to have
126
Insert CI slides here
127
128
0
5
10
15
20
25
30
35
40
10 20 30 40 50 60 70
good
put (
pps)
pps
Goodput vs pps (Econotags)
goodput
[Khattak preliminary]
Congestion Control
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-cocoa-00txt
ldquoadvancedrdquo cc (The draft is just a first shot) Others may have better ideas
129
Insert post-WGLC discussion slides here
130
Stop Continue Start
131
An Agile Retrospective
http6lowappnet coreIETF86 2013-03-12-13
Stop
132
Endless new CoAP optionssect instead use RESTful as much as possible
Move general security lifecycle out Looking at theoretical problems
http6lowappnet coreIETF86 2013-03-12-13
Continue
Interops Running code Look at real-world examples and deployments Solve their actual problems
sect Unilateral enhancements eg higher performance congestion control
sect Transports (SMS hellip)sect Make Web linking and Directories more and more usefulsect RESTful Design Paradigms for real-world problems
133
http6lowappnet coreIETF86 2013-03-12-13
Start
Further push into the (browser) web world (HTML5 browser security)
Specific supporting worksect SenMLsect URI work (dev URN hellip)sect Security Processes (next slide)
Spin outsect (We donrsquot really get to decide where this is done)
134
http6lowappnet coreIETF86 2013-03-12-13
Security
Integrate Application Network Group Keyingsect Tunnel-free setup
Donrsquot redo what has been done alreadysect ZigBee IP is finesect But what about other scenarios
Simple REST interfaces for working with keying materials and authorizationsect Start with defining objectives
Object Security for Constrained Nodes135
Re-chartering CoREWhat do we want to do now that wersquore grown up
Zach ShelbyCoRE WG IETF-86 Orlando
What is the scope
bull So we have a protocol and Web Linking what next
bull Keep with what we know besthellip1 Enhancements around CoAP2 New transports for CoAP3 New representations for Web Links4 General application layer solutions
CoRE WG IETF-86 Orlando 2
Enhancements around CoAP
bull Advanced congestion control
CoRE WG IETF-86 Orlando 3
New Transports for CoAP
bull Infrastructure for CoAP over foondash httptoolsietforgiddraft-silverajan-core-
coap-alternative-transports-01txtbull CoAP over SMS
ndash httptoolsietforgiddraft-becker-core-coap-sms-gprs-03txt
ndash OMA Lightweightbull CoAP over TCP
ndash httptoolsietforgiddraft-li-core-coap-payload-length-option-01txt
CoRE WG IETF-86 Orlando 4
New support for Web Links
bull JSON Web Linksndash httptoolsietforgiddraft-bormann-core-links-
json-02txt
2332010 CoRE WG IETF-77 Anaheim 5
General application layer solutions
bull Resource Directoryndash httptoolsietforgiddraft-shelby-core-
resource-directory-05txtndash OMA Lightweight
2332010 CoRE WG IETF-77 Anaheim 6
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-core-cross-reverse-convention-00txt
This draft has two lines of payload(based on a WGLC comment by Cullen Jennings)
coap12344567foobara=3
httpwwwproxycomwellknowncore-translate1234_4567foobara=3
Is that a useful convention to have
126
Insert CI slides here
127
128
0
5
10
15
20
25
30
35
40
10 20 30 40 50 60 70
good
put (
pps)
pps
Goodput vs pps (Econotags)
goodput
[Khattak preliminary]
Congestion Control
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-cocoa-00txt
ldquoadvancedrdquo cc (The draft is just a first shot) Others may have better ideas
129
Insert post-WGLC discussion slides here
130
Stop Continue Start
131
An Agile Retrospective
http6lowappnet coreIETF86 2013-03-12-13
Stop
132
Endless new CoAP optionssect instead use RESTful as much as possible
Move general security lifecycle out Looking at theoretical problems
http6lowappnet coreIETF86 2013-03-12-13
Continue
Interops Running code Look at real-world examples and deployments Solve their actual problems
sect Unilateral enhancements eg higher performance congestion control
sect Transports (SMS hellip)sect Make Web linking and Directories more and more usefulsect RESTful Design Paradigms for real-world problems
133
http6lowappnet coreIETF86 2013-03-12-13
Start
Further push into the (browser) web world (HTML5 browser security)
Specific supporting worksect SenMLsect URI work (dev URN hellip)sect Security Processes (next slide)
Spin outsect (We donrsquot really get to decide where this is done)
134
http6lowappnet coreIETF86 2013-03-12-13
Security
Integrate Application Network Group Keyingsect Tunnel-free setup
Donrsquot redo what has been done alreadysect ZigBee IP is finesect But what about other scenarios
Simple REST interfaces for working with keying materials and authorizationsect Start with defining objectives
Object Security for Constrained Nodes135
Re-chartering CoREWhat do we want to do now that wersquore grown up
Zach ShelbyCoRE WG IETF-86 Orlando
What is the scope
bull So we have a protocol and Web Linking what next
bull Keep with what we know besthellip1 Enhancements around CoAP2 New transports for CoAP3 New representations for Web Links4 General application layer solutions
CoRE WG IETF-86 Orlando 2
Enhancements around CoAP
bull Advanced congestion control
CoRE WG IETF-86 Orlando 3
New Transports for CoAP
bull Infrastructure for CoAP over foondash httptoolsietforgiddraft-silverajan-core-
coap-alternative-transports-01txtbull CoAP over SMS
ndash httptoolsietforgiddraft-becker-core-coap-sms-gprs-03txt
ndash OMA Lightweightbull CoAP over TCP
ndash httptoolsietforgiddraft-li-core-coap-payload-length-option-01txt
CoRE WG IETF-86 Orlando 4
New support for Web Links
bull JSON Web Linksndash httptoolsietforgiddraft-bormann-core-links-
json-02txt
2332010 CoRE WG IETF-77 Anaheim 5
General application layer solutions
bull Resource Directoryndash httptoolsietforgiddraft-shelby-core-
resource-directory-05txtndash OMA Lightweight
2332010 CoRE WG IETF-77 Anaheim 6
Insert CI slides here
127
128
0
5
10
15
20
25
30
35
40
10 20 30 40 50 60 70
good
put (
pps)
pps
Goodput vs pps (Econotags)
goodput
[Khattak preliminary]
Congestion Control
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-cocoa-00txt
ldquoadvancedrdquo cc (The draft is just a first shot) Others may have better ideas
129
Insert post-WGLC discussion slides here
130
Stop Continue Start
131
An Agile Retrospective
http6lowappnet coreIETF86 2013-03-12-13
Stop
132
Endless new CoAP optionssect instead use RESTful as much as possible
Move general security lifecycle out Looking at theoretical problems
http6lowappnet coreIETF86 2013-03-12-13
Continue
Interops Running code Look at real-world examples and deployments Solve their actual problems
sect Unilateral enhancements eg higher performance congestion control
sect Transports (SMS hellip)sect Make Web linking and Directories more and more usefulsect RESTful Design Paradigms for real-world problems
133
http6lowappnet coreIETF86 2013-03-12-13
Start
Further push into the (browser) web world (HTML5 browser security)
Specific supporting worksect SenMLsect URI work (dev URN hellip)sect Security Processes (next slide)
Spin outsect (We donrsquot really get to decide where this is done)
134
http6lowappnet coreIETF86 2013-03-12-13
Security
Integrate Application Network Group Keyingsect Tunnel-free setup
Donrsquot redo what has been done alreadysect ZigBee IP is finesect But what about other scenarios
Simple REST interfaces for working with keying materials and authorizationsect Start with defining objectives
Object Security for Constrained Nodes135
Re-chartering CoREWhat do we want to do now that wersquore grown up
Zach ShelbyCoRE WG IETF-86 Orlando
What is the scope
bull So we have a protocol and Web Linking what next
bull Keep with what we know besthellip1 Enhancements around CoAP2 New transports for CoAP3 New representations for Web Links4 General application layer solutions
CoRE WG IETF-86 Orlando 2
Enhancements around CoAP
bull Advanced congestion control
CoRE WG IETF-86 Orlando 3
New Transports for CoAP
bull Infrastructure for CoAP over foondash httptoolsietforgiddraft-silverajan-core-
coap-alternative-transports-01txtbull CoAP over SMS
ndash httptoolsietforgiddraft-becker-core-coap-sms-gprs-03txt
ndash OMA Lightweightbull CoAP over TCP
ndash httptoolsietforgiddraft-li-core-coap-payload-length-option-01txt
CoRE WG IETF-86 Orlando 4
New support for Web Links
bull JSON Web Linksndash httptoolsietforgiddraft-bormann-core-links-
json-02txt
2332010 CoRE WG IETF-77 Anaheim 5
General application layer solutions
bull Resource Directoryndash httptoolsietforgiddraft-shelby-core-
resource-directory-05txtndash OMA Lightweight
2332010 CoRE WG IETF-77 Anaheim 6
128
0
5
10
15
20
25
30
35
40
10 20 30 40 50 60 70
good
put (
pps)
pps
Goodput vs pps (Econotags)
goodput
[Khattak preliminary]
Congestion Control
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-cocoa-00txt
ldquoadvancedrdquo cc (The draft is just a first shot) Others may have better ideas
129
Insert post-WGLC discussion slides here
130
Stop Continue Start
131
An Agile Retrospective
http6lowappnet coreIETF86 2013-03-12-13
Stop
132
Endless new CoAP optionssect instead use RESTful as much as possible
Move general security lifecycle out Looking at theoretical problems
http6lowappnet coreIETF86 2013-03-12-13
Continue
Interops Running code Look at real-world examples and deployments Solve their actual problems
sect Unilateral enhancements eg higher performance congestion control
sect Transports (SMS hellip)sect Make Web linking and Directories more and more usefulsect RESTful Design Paradigms for real-world problems
133
http6lowappnet coreIETF86 2013-03-12-13
Start
Further push into the (browser) web world (HTML5 browser security)
Specific supporting worksect SenMLsect URI work (dev URN hellip)sect Security Processes (next slide)
Spin outsect (We donrsquot really get to decide where this is done)
134
http6lowappnet coreIETF86 2013-03-12-13
Security
Integrate Application Network Group Keyingsect Tunnel-free setup
Donrsquot redo what has been done alreadysect ZigBee IP is finesect But what about other scenarios
Simple REST interfaces for working with keying materials and authorizationsect Start with defining objectives
Object Security for Constrained Nodes135
Re-chartering CoREWhat do we want to do now that wersquore grown up
Zach ShelbyCoRE WG IETF-86 Orlando
What is the scope
bull So we have a protocol and Web Linking what next
bull Keep with what we know besthellip1 Enhancements around CoAP2 New transports for CoAP3 New representations for Web Links4 General application layer solutions
CoRE WG IETF-86 Orlando 2
Enhancements around CoAP
bull Advanced congestion control
CoRE WG IETF-86 Orlando 3
New Transports for CoAP
bull Infrastructure for CoAP over foondash httptoolsietforgiddraft-silverajan-core-
coap-alternative-transports-01txtbull CoAP over SMS
ndash httptoolsietforgiddraft-becker-core-coap-sms-gprs-03txt
ndash OMA Lightweightbull CoAP over TCP
ndash httptoolsietforgiddraft-li-core-coap-payload-length-option-01txt
CoRE WG IETF-86 Orlando 4
New support for Web Links
bull JSON Web Linksndash httptoolsietforgiddraft-bormann-core-links-
json-02txt
2332010 CoRE WG IETF-77 Anaheim 5
General application layer solutions
bull Resource Directoryndash httptoolsietforgiddraft-shelby-core-
resource-directory-05txtndash OMA Lightweight
2332010 CoRE WG IETF-77 Anaheim 6
http6lowappnet coreIETF86 2013-03-12-13
draft-bormann-cocoa-00txt
ldquoadvancedrdquo cc (The draft is just a first shot) Others may have better ideas
129
Insert post-WGLC discussion slides here
130
Stop Continue Start
131
An Agile Retrospective
http6lowappnet coreIETF86 2013-03-12-13
Stop
132
Endless new CoAP optionssect instead use RESTful as much as possible
Move general security lifecycle out Looking at theoretical problems
http6lowappnet coreIETF86 2013-03-12-13
Continue
Interops Running code Look at real-world examples and deployments Solve their actual problems
sect Unilateral enhancements eg higher performance congestion control
sect Transports (SMS hellip)sect Make Web linking and Directories more and more usefulsect RESTful Design Paradigms for real-world problems
133
http6lowappnet coreIETF86 2013-03-12-13
Start
Further push into the (browser) web world (HTML5 browser security)
Specific supporting worksect SenMLsect URI work (dev URN hellip)sect Security Processes (next slide)
Spin outsect (We donrsquot really get to decide where this is done)
134
http6lowappnet coreIETF86 2013-03-12-13
Security
Integrate Application Network Group Keyingsect Tunnel-free setup
Donrsquot redo what has been done alreadysect ZigBee IP is finesect But what about other scenarios
Simple REST interfaces for working with keying materials and authorizationsect Start with defining objectives
Object Security for Constrained Nodes135
Re-chartering CoREWhat do we want to do now that wersquore grown up
Zach ShelbyCoRE WG IETF-86 Orlando
What is the scope
bull So we have a protocol and Web Linking what next
bull Keep with what we know besthellip1 Enhancements around CoAP2 New transports for CoAP3 New representations for Web Links4 General application layer solutions
CoRE WG IETF-86 Orlando 2
Enhancements around CoAP
bull Advanced congestion control
CoRE WG IETF-86 Orlando 3
New Transports for CoAP
bull Infrastructure for CoAP over foondash httptoolsietforgiddraft-silverajan-core-
coap-alternative-transports-01txtbull CoAP over SMS
ndash httptoolsietforgiddraft-becker-core-coap-sms-gprs-03txt
ndash OMA Lightweightbull CoAP over TCP
ndash httptoolsietforgiddraft-li-core-coap-payload-length-option-01txt
CoRE WG IETF-86 Orlando 4
New support for Web Links
bull JSON Web Linksndash httptoolsietforgiddraft-bormann-core-links-
json-02txt
2332010 CoRE WG IETF-77 Anaheim 5
General application layer solutions
bull Resource Directoryndash httptoolsietforgiddraft-shelby-core-
resource-directory-05txtndash OMA Lightweight
2332010 CoRE WG IETF-77 Anaheim 6
Insert post-WGLC discussion slides here
130
Stop Continue Start
131
An Agile Retrospective
http6lowappnet coreIETF86 2013-03-12-13
Stop
132
Endless new CoAP optionssect instead use RESTful as much as possible
Move general security lifecycle out Looking at theoretical problems
http6lowappnet coreIETF86 2013-03-12-13
Continue
Interops Running code Look at real-world examples and deployments Solve their actual problems
sect Unilateral enhancements eg higher performance congestion control
sect Transports (SMS hellip)sect Make Web linking and Directories more and more usefulsect RESTful Design Paradigms for real-world problems
133
http6lowappnet coreIETF86 2013-03-12-13
Start
Further push into the (browser) web world (HTML5 browser security)
Specific supporting worksect SenMLsect URI work (dev URN hellip)sect Security Processes (next slide)
Spin outsect (We donrsquot really get to decide where this is done)
134
http6lowappnet coreIETF86 2013-03-12-13
Security
Integrate Application Network Group Keyingsect Tunnel-free setup
Donrsquot redo what has been done alreadysect ZigBee IP is finesect But what about other scenarios
Simple REST interfaces for working with keying materials and authorizationsect Start with defining objectives
Object Security for Constrained Nodes135
Re-chartering CoREWhat do we want to do now that wersquore grown up
Zach ShelbyCoRE WG IETF-86 Orlando
What is the scope
bull So we have a protocol and Web Linking what next
bull Keep with what we know besthellip1 Enhancements around CoAP2 New transports for CoAP3 New representations for Web Links4 General application layer solutions
CoRE WG IETF-86 Orlando 2
Enhancements around CoAP
bull Advanced congestion control
CoRE WG IETF-86 Orlando 3
New Transports for CoAP
bull Infrastructure for CoAP over foondash httptoolsietforgiddraft-silverajan-core-
coap-alternative-transports-01txtbull CoAP over SMS
ndash httptoolsietforgiddraft-becker-core-coap-sms-gprs-03txt
ndash OMA Lightweightbull CoAP over TCP
ndash httptoolsietforgiddraft-li-core-coap-payload-length-option-01txt
CoRE WG IETF-86 Orlando 4
New support for Web Links
bull JSON Web Linksndash httptoolsietforgiddraft-bormann-core-links-
json-02txt
2332010 CoRE WG IETF-77 Anaheim 5
General application layer solutions
bull Resource Directoryndash httptoolsietforgiddraft-shelby-core-
resource-directory-05txtndash OMA Lightweight
2332010 CoRE WG IETF-77 Anaheim 6
Stop Continue Start
131
An Agile Retrospective
http6lowappnet coreIETF86 2013-03-12-13
Stop
132
Endless new CoAP optionssect instead use RESTful as much as possible
Move general security lifecycle out Looking at theoretical problems
http6lowappnet coreIETF86 2013-03-12-13
Continue
Interops Running code Look at real-world examples and deployments Solve their actual problems
sect Unilateral enhancements eg higher performance congestion control
sect Transports (SMS hellip)sect Make Web linking and Directories more and more usefulsect RESTful Design Paradigms for real-world problems
133
http6lowappnet coreIETF86 2013-03-12-13
Start
Further push into the (browser) web world (HTML5 browser security)
Specific supporting worksect SenMLsect URI work (dev URN hellip)sect Security Processes (next slide)
Spin outsect (We donrsquot really get to decide where this is done)
134
http6lowappnet coreIETF86 2013-03-12-13
Security
Integrate Application Network Group Keyingsect Tunnel-free setup
Donrsquot redo what has been done alreadysect ZigBee IP is finesect But what about other scenarios
Simple REST interfaces for working with keying materials and authorizationsect Start with defining objectives
Object Security for Constrained Nodes135
Re-chartering CoREWhat do we want to do now that wersquore grown up
Zach ShelbyCoRE WG IETF-86 Orlando
What is the scope
bull So we have a protocol and Web Linking what next
bull Keep with what we know besthellip1 Enhancements around CoAP2 New transports for CoAP3 New representations for Web Links4 General application layer solutions
CoRE WG IETF-86 Orlando 2
Enhancements around CoAP
bull Advanced congestion control
CoRE WG IETF-86 Orlando 3
New Transports for CoAP
bull Infrastructure for CoAP over foondash httptoolsietforgiddraft-silverajan-core-
coap-alternative-transports-01txtbull CoAP over SMS
ndash httptoolsietforgiddraft-becker-core-coap-sms-gprs-03txt
ndash OMA Lightweightbull CoAP over TCP
ndash httptoolsietforgiddraft-li-core-coap-payload-length-option-01txt
CoRE WG IETF-86 Orlando 4
New support for Web Links
bull JSON Web Linksndash httptoolsietforgiddraft-bormann-core-links-
json-02txt
2332010 CoRE WG IETF-77 Anaheim 5
General application layer solutions
bull Resource Directoryndash httptoolsietforgiddraft-shelby-core-
resource-directory-05txtndash OMA Lightweight
2332010 CoRE WG IETF-77 Anaheim 6
http6lowappnet coreIETF86 2013-03-12-13
Stop
132
Endless new CoAP optionssect instead use RESTful as much as possible
Move general security lifecycle out Looking at theoretical problems
http6lowappnet coreIETF86 2013-03-12-13
Continue
Interops Running code Look at real-world examples and deployments Solve their actual problems
sect Unilateral enhancements eg higher performance congestion control
sect Transports (SMS hellip)sect Make Web linking and Directories more and more usefulsect RESTful Design Paradigms for real-world problems
133
http6lowappnet coreIETF86 2013-03-12-13
Start
Further push into the (browser) web world (HTML5 browser security)
Specific supporting worksect SenMLsect URI work (dev URN hellip)sect Security Processes (next slide)
Spin outsect (We donrsquot really get to decide where this is done)
134
http6lowappnet coreIETF86 2013-03-12-13
Security
Integrate Application Network Group Keyingsect Tunnel-free setup
Donrsquot redo what has been done alreadysect ZigBee IP is finesect But what about other scenarios
Simple REST interfaces for working with keying materials and authorizationsect Start with defining objectives
Object Security for Constrained Nodes135
Re-chartering CoREWhat do we want to do now that wersquore grown up
Zach ShelbyCoRE WG IETF-86 Orlando
What is the scope
bull So we have a protocol and Web Linking what next
bull Keep with what we know besthellip1 Enhancements around CoAP2 New transports for CoAP3 New representations for Web Links4 General application layer solutions
CoRE WG IETF-86 Orlando 2
Enhancements around CoAP
bull Advanced congestion control
CoRE WG IETF-86 Orlando 3
New Transports for CoAP
bull Infrastructure for CoAP over foondash httptoolsietforgiddraft-silverajan-core-
coap-alternative-transports-01txtbull CoAP over SMS
ndash httptoolsietforgiddraft-becker-core-coap-sms-gprs-03txt
ndash OMA Lightweightbull CoAP over TCP
ndash httptoolsietforgiddraft-li-core-coap-payload-length-option-01txt
CoRE WG IETF-86 Orlando 4
New support for Web Links
bull JSON Web Linksndash httptoolsietforgiddraft-bormann-core-links-
json-02txt
2332010 CoRE WG IETF-77 Anaheim 5
General application layer solutions
bull Resource Directoryndash httptoolsietforgiddraft-shelby-core-
resource-directory-05txtndash OMA Lightweight
2332010 CoRE WG IETF-77 Anaheim 6
http6lowappnet coreIETF86 2013-03-12-13
Continue
Interops Running code Look at real-world examples and deployments Solve their actual problems
sect Unilateral enhancements eg higher performance congestion control
sect Transports (SMS hellip)sect Make Web linking and Directories more and more usefulsect RESTful Design Paradigms for real-world problems
133
http6lowappnet coreIETF86 2013-03-12-13
Start
Further push into the (browser) web world (HTML5 browser security)
Specific supporting worksect SenMLsect URI work (dev URN hellip)sect Security Processes (next slide)
Spin outsect (We donrsquot really get to decide where this is done)
134
http6lowappnet coreIETF86 2013-03-12-13
Security
Integrate Application Network Group Keyingsect Tunnel-free setup
Donrsquot redo what has been done alreadysect ZigBee IP is finesect But what about other scenarios
Simple REST interfaces for working with keying materials and authorizationsect Start with defining objectives
Object Security for Constrained Nodes135
Re-chartering CoREWhat do we want to do now that wersquore grown up
Zach ShelbyCoRE WG IETF-86 Orlando
What is the scope
bull So we have a protocol and Web Linking what next
bull Keep with what we know besthellip1 Enhancements around CoAP2 New transports for CoAP3 New representations for Web Links4 General application layer solutions
CoRE WG IETF-86 Orlando 2
Enhancements around CoAP
bull Advanced congestion control
CoRE WG IETF-86 Orlando 3
New Transports for CoAP
bull Infrastructure for CoAP over foondash httptoolsietforgiddraft-silverajan-core-
coap-alternative-transports-01txtbull CoAP over SMS
ndash httptoolsietforgiddraft-becker-core-coap-sms-gprs-03txt
ndash OMA Lightweightbull CoAP over TCP
ndash httptoolsietforgiddraft-li-core-coap-payload-length-option-01txt
CoRE WG IETF-86 Orlando 4
New support for Web Links
bull JSON Web Linksndash httptoolsietforgiddraft-bormann-core-links-
json-02txt
2332010 CoRE WG IETF-77 Anaheim 5
General application layer solutions
bull Resource Directoryndash httptoolsietforgiddraft-shelby-core-
resource-directory-05txtndash OMA Lightweight
2332010 CoRE WG IETF-77 Anaheim 6
http6lowappnet coreIETF86 2013-03-12-13
Start
Further push into the (browser) web world (HTML5 browser security)
Specific supporting worksect SenMLsect URI work (dev URN hellip)sect Security Processes (next slide)
Spin outsect (We donrsquot really get to decide where this is done)
134
http6lowappnet coreIETF86 2013-03-12-13
Security
Integrate Application Network Group Keyingsect Tunnel-free setup
Donrsquot redo what has been done alreadysect ZigBee IP is finesect But what about other scenarios
Simple REST interfaces for working with keying materials and authorizationsect Start with defining objectives
Object Security for Constrained Nodes135
Re-chartering CoREWhat do we want to do now that wersquore grown up
Zach ShelbyCoRE WG IETF-86 Orlando
What is the scope
bull So we have a protocol and Web Linking what next
bull Keep with what we know besthellip1 Enhancements around CoAP2 New transports for CoAP3 New representations for Web Links4 General application layer solutions
CoRE WG IETF-86 Orlando 2
Enhancements around CoAP
bull Advanced congestion control
CoRE WG IETF-86 Orlando 3
New Transports for CoAP
bull Infrastructure for CoAP over foondash httptoolsietforgiddraft-silverajan-core-
coap-alternative-transports-01txtbull CoAP over SMS
ndash httptoolsietforgiddraft-becker-core-coap-sms-gprs-03txt
ndash OMA Lightweightbull CoAP over TCP
ndash httptoolsietforgiddraft-li-core-coap-payload-length-option-01txt
CoRE WG IETF-86 Orlando 4
New support for Web Links
bull JSON Web Linksndash httptoolsietforgiddraft-bormann-core-links-
json-02txt
2332010 CoRE WG IETF-77 Anaheim 5
General application layer solutions
bull Resource Directoryndash httptoolsietforgiddraft-shelby-core-
resource-directory-05txtndash OMA Lightweight
2332010 CoRE WG IETF-77 Anaheim 6
http6lowappnet coreIETF86 2013-03-12-13
Security
Integrate Application Network Group Keyingsect Tunnel-free setup
Donrsquot redo what has been done alreadysect ZigBee IP is finesect But what about other scenarios
Simple REST interfaces for working with keying materials and authorizationsect Start with defining objectives
Object Security for Constrained Nodes135
Re-chartering CoREWhat do we want to do now that wersquore grown up
Zach ShelbyCoRE WG IETF-86 Orlando
What is the scope
bull So we have a protocol and Web Linking what next
bull Keep with what we know besthellip1 Enhancements around CoAP2 New transports for CoAP3 New representations for Web Links4 General application layer solutions
CoRE WG IETF-86 Orlando 2
Enhancements around CoAP
bull Advanced congestion control
CoRE WG IETF-86 Orlando 3
New Transports for CoAP
bull Infrastructure for CoAP over foondash httptoolsietforgiddraft-silverajan-core-
coap-alternative-transports-01txtbull CoAP over SMS
ndash httptoolsietforgiddraft-becker-core-coap-sms-gprs-03txt
ndash OMA Lightweightbull CoAP over TCP
ndash httptoolsietforgiddraft-li-core-coap-payload-length-option-01txt
CoRE WG IETF-86 Orlando 4
New support for Web Links
bull JSON Web Linksndash httptoolsietforgiddraft-bormann-core-links-
json-02txt
2332010 CoRE WG IETF-77 Anaheim 5
General application layer solutions
bull Resource Directoryndash httptoolsietforgiddraft-shelby-core-
resource-directory-05txtndash OMA Lightweight
2332010 CoRE WG IETF-77 Anaheim 6
Re-chartering CoREWhat do we want to do now that wersquore grown up
Zach ShelbyCoRE WG IETF-86 Orlando
What is the scope
bull So we have a protocol and Web Linking what next
bull Keep with what we know besthellip1 Enhancements around CoAP2 New transports for CoAP3 New representations for Web Links4 General application layer solutions
CoRE WG IETF-86 Orlando 2
Enhancements around CoAP
bull Advanced congestion control
CoRE WG IETF-86 Orlando 3
New Transports for CoAP
bull Infrastructure for CoAP over foondash httptoolsietforgiddraft-silverajan-core-
coap-alternative-transports-01txtbull CoAP over SMS
ndash httptoolsietforgiddraft-becker-core-coap-sms-gprs-03txt
ndash OMA Lightweightbull CoAP over TCP
ndash httptoolsietforgiddraft-li-core-coap-payload-length-option-01txt
CoRE WG IETF-86 Orlando 4
New support for Web Links
bull JSON Web Linksndash httptoolsietforgiddraft-bormann-core-links-
json-02txt
2332010 CoRE WG IETF-77 Anaheim 5
General application layer solutions
bull Resource Directoryndash httptoolsietforgiddraft-shelby-core-
resource-directory-05txtndash OMA Lightweight
2332010 CoRE WG IETF-77 Anaheim 6
What is the scope
bull So we have a protocol and Web Linking what next
bull Keep with what we know besthellip1 Enhancements around CoAP2 New transports for CoAP3 New representations for Web Links4 General application layer solutions
CoRE WG IETF-86 Orlando 2
Enhancements around CoAP
bull Advanced congestion control
CoRE WG IETF-86 Orlando 3
New Transports for CoAP
bull Infrastructure for CoAP over foondash httptoolsietforgiddraft-silverajan-core-
coap-alternative-transports-01txtbull CoAP over SMS
ndash httptoolsietforgiddraft-becker-core-coap-sms-gprs-03txt
ndash OMA Lightweightbull CoAP over TCP
ndash httptoolsietforgiddraft-li-core-coap-payload-length-option-01txt
CoRE WG IETF-86 Orlando 4
New support for Web Links
bull JSON Web Linksndash httptoolsietforgiddraft-bormann-core-links-
json-02txt
2332010 CoRE WG IETF-77 Anaheim 5
General application layer solutions
bull Resource Directoryndash httptoolsietforgiddraft-shelby-core-
resource-directory-05txtndash OMA Lightweight
2332010 CoRE WG IETF-77 Anaheim 6
Enhancements around CoAP
bull Advanced congestion control
CoRE WG IETF-86 Orlando 3
New Transports for CoAP
bull Infrastructure for CoAP over foondash httptoolsietforgiddraft-silverajan-core-
coap-alternative-transports-01txtbull CoAP over SMS
ndash httptoolsietforgiddraft-becker-core-coap-sms-gprs-03txt
ndash OMA Lightweightbull CoAP over TCP
ndash httptoolsietforgiddraft-li-core-coap-payload-length-option-01txt
CoRE WG IETF-86 Orlando 4
New support for Web Links
bull JSON Web Linksndash httptoolsietforgiddraft-bormann-core-links-
json-02txt
2332010 CoRE WG IETF-77 Anaheim 5
General application layer solutions
bull Resource Directoryndash httptoolsietforgiddraft-shelby-core-
resource-directory-05txtndash OMA Lightweight
2332010 CoRE WG IETF-77 Anaheim 6
New Transports for CoAP
bull Infrastructure for CoAP over foondash httptoolsietforgiddraft-silverajan-core-
coap-alternative-transports-01txtbull CoAP over SMS
ndash httptoolsietforgiddraft-becker-core-coap-sms-gprs-03txt
ndash OMA Lightweightbull CoAP over TCP
ndash httptoolsietforgiddraft-li-core-coap-payload-length-option-01txt
CoRE WG IETF-86 Orlando 4
New support for Web Links
bull JSON Web Linksndash httptoolsietforgiddraft-bormann-core-links-
json-02txt
2332010 CoRE WG IETF-77 Anaheim 5
General application layer solutions
bull Resource Directoryndash httptoolsietforgiddraft-shelby-core-
resource-directory-05txtndash OMA Lightweight
2332010 CoRE WG IETF-77 Anaheim 6
New support for Web Links
bull JSON Web Linksndash httptoolsietforgiddraft-bormann-core-links-
json-02txt
2332010 CoRE WG IETF-77 Anaheim 5
General application layer solutions
bull Resource Directoryndash httptoolsietforgiddraft-shelby-core-
resource-directory-05txtndash OMA Lightweight
2332010 CoRE WG IETF-77 Anaheim 6
General application layer solutions
bull Resource Directoryndash httptoolsietforgiddraft-shelby-core-
resource-directory-05txtndash OMA Lightweight
2332010 CoRE WG IETF-77 Anaheim 6