Changeset 40


Ignore:
Timestamp:
Feb 10, 2014, 5:01:38 AM (6 years ago)
Author:
cabo@…
Message:

Submit lwig-terminology -07

Files:
2 edited

Legend:

Unmodified
Added
Removed
  • draft-ietf-lwig-terminology.mkd

    r39 r40  
    22title: Terminology for Constrained Node Networks
    33abbrev: CNN terminology
    4 docname: draft-ietf-lwig-terminology-07pre
    5 date: 2014-02-07
     4docname: draft-ietf-lwig-terminology-07
     5date: 2014-02-10
    66
    77stand_alone: true
     
    309309working group on Routing Over Low power and Lossy networks (ROLL) is
    310310"low-power lossy network" (LLN).  The ROLL terminology document
    311 {{?I-D.ietf-roll-terminology}} defines LLNs as follows:
     311{{?RFC7102}} defines LLNs as follows:
    312312
    313313>    LLN: Low power and Lossy networks (LLNs) are typically composed of
     
    354354technologies {{-btle}} {{-dect-ule}} {{-lowpanz}}.
    355355
    356 -----
    357356
    358357Classes of Constrained Devices {#devclass}
     
    582581time (the "duty cycle").
    583582
    584 {{?I-D.ietf-roll-terminology}} only distinguishes two levels, defining
     583{{?RFC7102}} only distinguishes two levels, defining
    585584a Non-sleepy Node as a node that always remains in a fully powered on
    586585state (always awake) where it has the capability to perform
     
    590589mention of P1.
    591590
    592 -----
    593591
    594592Security Considerations
     
    601599"Constrained node considerations", discusses implications of specific
    602600constraints on the security mechanisms employed.
    603 {{?I-D.ietf-roll-security-threats-06.txt}} provides a security
     601{{?I-D.ietf-roll-security-threats}} provides a security
    604602threat analysis for the RPL routing protocol.
    605603Implementation considerations for security protocols on constrained
     
    625623{{?I-D.ietf-lwig-cellular}} and has been adapted for this document.
    626624
     625-----
    627626
    628627<!--  LocalWords:  interoperability microwatts microjoules bitrate IP
  • draft-ietf-lwig-terminology.xml

    r35 r40  
    55]>
    66
    7 <rfc ipr="trust200902" docName="draft-ietf-lwig-terminology-06" category="info">
     7<rfc ipr="trust200902" docName="draft-ietf-lwig-terminology-07" category="info">
    88
    99<?rfc toc="yes"?>
     
    6464    </author>
    6565
    66     <date year="2013" month="December" day="18"/>
     66    <date year="2014" month="February" day="10"/>
    6767
    6868    <area>Internet</area>
     
    142142<section anchor="core-terminology" title="Core Terminology">
    143143
    144 <t>There are two important aspects to <spanx style='emph'>scaling</spanx> within the Internet of Things:</t>
    145 
    146 <t><list style='symbols'>
     144<t>There are two important aspects to <spanx style="emph">scaling</spanx> within the Internet of Things:</t>
     145
     146<t><list style="symbols">
    147147  <t>Scaling up Internet technologies to a large number <xref target="fifty-billion"/> of
    148148inexpensive nodes, while</t>
     
    153153
    154154<t>The need for scaling down the characteristics of nodes leads to
    155 <spanx style='emph'>constrained nodes</spanx>.</t>
     155<spanx style="emph">constrained nodes</spanx>.</t>
    156156
    157157<section anchor="constrained-nodes" title="Constrained Nodes">
     
    161161expectations on more familiar Internet nodes:</t>
    162162
    163 <t><list style='hanging'>
     163<t><list style="hanging">
    164164  <t hangText='Constrained Node:'>
    165165  A node where some of the characteristics that are otherwise pretty
     
    189189in combination, e.g.:</t>
    190190
    191 <t><list style='symbols'>
     191<t><list style="symbols">
    192192  <t>constraints on the maximum code complexity (ROM/Flash);</t>
    193193  <t>constraints on the size of state and buffers (RAM);</t>
     
    211211constraints on the networks themselves.  However, there may also be
    212212constraints on networks that are largely independent from those of the
    213 nodes.  We therefore distinguish <spanx style='emph'>constrained networks</spanx> and
    214 <spanx style='emph'>constrained node networks</spanx>.</t>
     213nodes.  We therefore distinguish <spanx style="emph">constrained networks</spanx> and
     214<spanx style="emph">constrained node networks</spanx>.</t>
    215215
    216216<!--
     
    223223<t>We define “constrained network” in a similar way:</t>
    224224
    225 <t><list style='hanging'>
     225<t><list style="hanging">
    226226  <t hangText='Constrained Network:'>
    227227  A network where some of the characteristics pretty much taken for
     
    231231</list></t>
    232232
     233<t>Constraints may include:</t>
     234
     235<t><list style="symbols">
     236  <t>low achievable bit rate/throughput (including limits on duty cycle),</t>
     237  <t>high packet loss, high packet loss (delivery rate) variability,</t>
     238  <t>highly asymmetric link characteristics,</t>
     239  <t>severe penalties for using larger packets (e.g., high packet loss
     240due to link layer fragmentation),</t>
     241  <t>limits on reachability over time (a substantial number of devices
     242may power off at any point in time but periodically “wake up” and
     243can communicate for brief periods of time)</t>
     244  <t>lack of (or severe constraints on) advanced services such as IP multicast.</t>
     245</list></t>
     246
     247<t>More generally, we speak of constrained networks whenever at least
     248some of the nodes involved in the network exhibit these
     249characteristics.</t>
     250
    233251<t>Again, there may be several reasons for this:</t>
    234252
    235 <t><list style='symbols'>
     253<t><list style="symbols">
    236254  <t>cost constraints on the network,</t>
    237255  <t>constraints of the nodes (for constrained node networks),</t>
     
    247265</list></t>
    248266
    249 <t>Constraints may include:</t>
    250 
    251 <t><list style='symbols'>
    252   <t>low achievable bit rate (including limits on duty cycle),</t>
    253   <t>high packet loss, packet loss (delivery rate) variability,</t>
    254   <t>highly asymmetric link characteristics,</t>
    255   <t>severe penalties for using larger packets (e.g., high packet loss
    256 due to link layer fragmentation),</t>
    257   <t>lack of (or severe constraints on) advanced services such as IP multicast.</t>
    258 </list></t>
    259 
    260267<section anchor="challenged-networks" title="Challenged Networks">
    261268
    262 <t>A constrained network is not necessarily a <spanx style='emph'>challenged</spanx> network <xref target="FALL"/>:</t>
    263 
    264 <t><list style='hanging'>
     269<t>A constrained network is not necessarily a <spanx style="emph">challenged</spanx> network <xref target="FALL"/>:</t>
     270
     271<t><list style="hanging">
    265272  <t hangText='Challenged Network:'>
    266273  A network that has serious trouble maintaining what an application
     
    268275</list></t>
    269276
    270 <t><list style='symbols'>
     277<t><list style="symbols">
    271278  <t>not being able to offer end-to-end IP connectivity at all;</t>
    272279  <t>exhibiting serious interruptions in end-to-end IP connectivity;</t>
     
    285292<section anchor="constrained-node-networks" title="Constrained Node Networks">
    286293
    287 <t><list style='hanging'>
     294<t><list style="hanging">
    288295  <t hangText='Constrained Node Network:'>
    289296  A network whose characteristics are influenced by being composed of
     
    304311working group on Routing Over Low power and Lossy networks (ROLL) is
    305312“low-power lossy network” (LLN).  The ROLL terminology document
    306 <xref target="I-D.ietf-roll-terminology"/> defines LLNs as follows:</t>
     313<xref target="RFC7102"/> defines LLNs as follows:</t>
    307314
    308315<t><list style='empty'>
     
    322329stability that makes it worthwhile to construct medium-term stable
    323330directed acyclic graphs for routing and do measurements on the edges
    324 such as ETX <xref target="RFC6551"/>.  Actual “low power” does not seem to be
    325 a defining characteristic for an LLN <xref target="I-D.hui-vasseur-roll-rpl-deployment"/>.</t>
     331such as ETX <xref target="RFC6551"/>.  Not all LLNs comprise low power nodes
     332<xref target="I-D.hui-vasseur-roll-rpl-deployment"/>.</t>
    326333
    327334<t>LLNs typically are composed
     
    352359technologies <xref target="I-D.ietf-6lowpan-btle"/> <xref target="I-D.mariager-6lowpan-v6over-dect-ule"/> <xref target="I-D.brandt-6man-lowpanz"/>.</t>
    353360
    354 <t><vspace blankLines='999' /></t>
    355 
    356361</section>
    357362</section>
     
    389394requirements than into continual increases in computing power.</t>
    390395
    391 <t>Class 0 devices are very constrained sensor-like motes.  Most likely
    392 they will not be able to communicate directly with the Internet in a
    393 secure manner.  Class 0 devices will participate in Internet
     396<t>Class 0 devices are very constrained sensor-like motes.  They are so
     397severely constrained in memory and processing capabilities that most
     398likely they will not have the resources required to communicate
     399directly with the Internet in a secure manner (rare heroic, narrowly
     400targeted implementation efforts
     401notwithstanding).  Class 0 devices will participate in Internet
    394402communications with the help of larger devices acting as proxies,
    395403gateways or servers.  Class 0 devices generally cannot be secured or managed
     
    399407signals and send on/off or basic health indications.</t>
    400408
    401 <t>Class 1 devices cannot easily talk to other Internet nodes employing a
     409<t>Class 1 devices are quite constrained in code space and processing
     410capabilities, such that they
     411cannot easily talk to other Internet nodes employing a
    402412full protocol stack such as using HTTP, TLS and related security
    403413protocols and XML-based data representations.  However, they have
     
    411421application usage.</t>
    412422
    413 <t>Class 2 can already support mostly the same protocol stacks as used on
     423<t>Class 2 devides are less constrained and fundamentally capable of
     424supporting most of the same protocol stacks as used on
    414425notebooks or servers.  However, even these devices can benefit from
    415426lightweight and energy-efficient protocols and from consuming less
    416427bandwidth.  Furthermore, using fewer resources for networking leaves
    417428more resources available to applications.  Thus, using the protocol
    418 stacks defined for very constrained devices also on Class 2 devices
     429stacks defined for more constrained devices also on Class 2 devices
    419430might reduce development costs and increase the interoperability.</t>
    420431
     
    548559<t>The general strategies for power usage can be described as follows:</t>
    549560
    550 <t><list style='hanging'>
     561<t><list style="hanging">
    551562  <t hangText='Always-on:'>
    552563  This strategy is most applicable if there is no reason for extreme
     
    607618time (the “duty cycle”).</t>
    608619
    609 <t><xref target="I-D.ietf-roll-terminology"/> only distinguishes two levels, defining
     620<t><xref target="RFC7102"/> only distinguishes two levels, defining
    610621a Non-sleepy Node as a node that always remains in a fully powered on
    611622state (always awake) where it has the capability to perform
     
    615626mention of P1.</t>
    616627
    617 <t><vspace blankLines='999' /></t>
    618 
    619628</section>
    620629</section>
     
    626635context of specific protocols.  For instance, <xref target="I-D.ietf-core-coap"/> section 11.6,
    627636“Constrained node considerations”, discusses implications of specific
    628 constraints on the security mechanisms employed.  A wider view at
    629 security in constrained node networks is provided in <xref target="I-D.garcia-core-security"/>.</t>
     637constraints on the security mechanisms employed.
     638<xref target="I-D.ietf-roll-security-threats"/> provides a security
     639threat analysis for the RPL routing protocol.
     640Implementation considerations for security protocols on constrained
     641nodes are discussed in <xref target="I-D.ietf-lwig-ikev2-minimal"/> and
     642<xref target="I-D.ietf-lwig-tls-minimal"/>.
     643A wider view at security in constrained node networks is provided in
     644<xref target="I-D.garcia-core-security"/>.</t>
    630645
    631646</section>
     
    644659The text for <xref target="poweruse"/> is mostly lifted from a previous version of
    645660<xref target="I-D.ietf-lwig-cellular"/> and has been adapted for this document.</t>
     661
     662<t><vspace blankLines='999' /></t>
    646663
    647664<!--  LocalWords:  interoperability microwatts microjoules bitrate IP
     
    920937
    921938
    922 <reference anchor='I-D.ietf-roll-terminology'>
    923 <front>
    924 <title>Terms used in Routing for Low power And Lossy Networks</title>
    925 
    926 <author initials='J' surname='Vasseur' fullname='JP Vasseur'>
    927     <organization />
    928 </author>
    929 
    930 <date month='October' day='2' year='2013' />
    931 
    932 <abstract><t>The documents provides a glossary of terminology used in routing requirements and solutions for networks referred to as Low power and Lossy Networks (LLN).  An LLN is typically composed of many embedded devices with limited power, memory, and processing resources interconnected by a variety of links.  There is a wide scope of application areas for LLNs, including industrial monitoring, building automation (e.g.  Heating, Ventilating, Air Conditioning, lighting, access control, fire), connected home, healthcare, environmental monitoring, urban sensor networks, energy management, assets tracking, refrigeration.</t></abstract>
    933 
    934 </front>
    935 
    936 <seriesInfo name='Internet-Draft' value='draft-ietf-roll-terminology-13' />
    937 <format type='TXT'
    938         target='http://www.ietf.org/internet-drafts/draft-ietf-roll-terminology-13.txt' />
     939<reference anchor='RFC7102'>
     940
     941<front>
     942<title>Terms Used in Routing for Low-Power and Lossy Networks</title>
     943<author initials='JP.' surname='Vasseur' fullname='JP. Vasseur'>
     944<organization /></author>
     945<date year='2014' month='January' />
     946<abstract>
     947<t>This document provides a glossary of terminology used in routing requirements and solutions for networks referred to as Low-Power and Lossy Networks (LLNs).  An LLN is typically composed of many embedded devices with limited power, memory, and processing resources interconnected by a variety of links.  There is a wide scope of application areas for LLNs, including industrial monitoring, building automation (e.g., heating, ventilation, air conditioning, lighting, access control, fire), connected home, health care, environmental monitoring, urban sensor networks, energy management, assets tracking, and refrigeration.</t></abstract></front>
     948
     949<seriesInfo name='RFC' value='7102' />
     950<format type='TXT' octets='16444' target='http://www.rfc-editor.org/rfc/rfc7102.txt' />
    939951</reference>
    940952
     
    10381050
    10391051
     1052<reference anchor='I-D.ietf-roll-security-threats'>
     1053<front>
     1054<title>A Security Threat Analysis for Routing Protocol for Low-power and lossy networks (RPL)</title>
     1055
     1056<author initials='T' surname='Tsao' fullname='Tzeta Tsao'>
     1057    <organization />
     1058</author>
     1059
     1060<author initials='R' surname='Alexander' fullname='Roger Alexander'>
     1061    <organization />
     1062</author>
     1063
     1064<author initials='M' surname='Dohler' fullname='Mischa Dohler'>
     1065    <organization />
     1066</author>
     1067
     1068<author initials='V' surname='Daza' fullname='Vanesa Daza'>
     1069    <organization />
     1070</author>
     1071
     1072<author initials='A' surname='Lozano' fullname='Angel Lozano'>
     1073    <organization />
     1074</author>
     1075
     1076<author initials='M' surname='Richardson' fullname='Michael Richardson'>
     1077    <organization />
     1078</author>
     1079
     1080<date month='December' day='15' year='2013' />
     1081
     1082<abstract><t>This document presents a security threat analysis for the Routing Protocol for Low-power and lossy networks (RPL, ROLL).  The development builds upon previous work on routing security and adapts the assessments to the issues and constraints specific to low-power and lossy networks.  A systematic approach is used in defining and evaluating the security threats.  Applicable countermeasures are application specific and are addressed in relevant applicability statements.</t></abstract>
     1083
     1084</front>
     1085
     1086<seriesInfo name='Internet-Draft' value='draft-ietf-roll-security-threats-06' />
     1087<format type='TXT'
     1088        target='http://www.ietf.org/internet-drafts/draft-ietf-roll-security-threats-06.txt' />
     1089</reference>
     1090
     1091
     1092
     1093<reference anchor='I-D.ietf-lwig-ikev2-minimal'>
     1094<front>
     1095<title>Minimal IKEv2</title>
     1096
     1097<author initials='T' surname='Kivinen' fullname='Tero Kivinen'>
     1098    <organization />
     1099</author>
     1100
     1101<date month='October' day='17' year='2013' />
     1102
     1103<abstract><t>This document describes minimal version of the Internet Key Exchange version 2 (IKEv2) protocol.  IKEv2 is a component of IPsec used for performing mutual authentication and establishing and maintaining Security Associations (SAs).  IKEv2 includes several optional features, which are not needed in minimal implementations.  This document describes what is required from the minimal implementation, and also describes various optimizations which can be done.  The protocol described here is compliant with full IKEv2 with exception that this document describes mainly shared secret authentication (IKEv2 requires support for certificate authentication in addition to shared secret authentication).  This document does not update or modify RFC 5996, but provides more compact description of the minimal version of the protocol.  If this document and RFC 5996 conflicts then RFC 5996 is the authoritative description.</t></abstract>
     1104
     1105</front>
     1106
     1107<seriesInfo name='Internet-Draft' value='draft-ietf-lwig-ikev2-minimal-01' />
     1108<format type='TXT'
     1109        target='http://www.ietf.org/internet-drafts/draft-ietf-lwig-ikev2-minimal-01.txt' />
     1110</reference>
     1111
     1112
     1113
     1114<reference anchor='I-D.ietf-lwig-tls-minimal'>
     1115<front>
     1116<title>A Hitchhiker's Guide to the (Datagram) Transport Layer Security Protocol for Smart Objects and Constrained Node Networks</title>
     1117
     1118<author initials='S' surname='Kumar' fullname='Sandeep Kumar'>
     1119    <organization />
     1120</author>
     1121
     1122<author initials='S' surname='Keoh' fullname='Sye Keoh'>
     1123    <organization />
     1124</author>
     1125
     1126<author initials='H' surname='Tschofenig' fullname='Hannes Tschofenig'>
     1127    <organization />
     1128</author>
     1129
     1130<date month='September' day='4' year='2013' />
     1131
     1132<abstract><t>Transport Layer Security (TLS) is a widely used security protocol that offers communication security services at the transport layer. The initial design of TLS was focused on the protection of applications running on top of the Transmission Control Protocol (TCP), and was a good match for securing the Hypertext Transfer Protocol (HTTP).  Subsequent standardization efforts lead to the publication of the Datagram Transport Layer Security (DTLS) protocol, which allows the re-use of the TLS security functionality and the payloads to be exchanged on top of the User Datagram Protocol (UDP).  With the work on the Constrained Application Protocol (CoAP), as a specialized web transfer protocol for use with constrained nodes and constrained networks, DTLS is a preferred communication security protocol.  Smart objects are constrained in various ways (e.g., CPU, memory, power consumption) and these limitations may impose restrictions on the protocol stack such a device runs. This document only looks at the security part of that protocol stacks and the ability to customize TLS/DTLS. To offer input for implementers and system architects this document illustrates the costs and benefits of various TLS/DTLS features for use with smart objects and constraint node networks.</t></abstract>
     1133
     1134</front>
     1135
     1136<seriesInfo name='Internet-Draft' value='draft-ietf-lwig-tls-minimal-00' />
     1137<format type='TXT'
     1138        target='http://www.ietf.org/internet-drafts/draft-ietf-lwig-tls-minimal-00.txt' />
     1139</reference>
     1140
     1141
     1142
    10401143<reference anchor='I-D.garcia-core-security'>
    10411144<front>
Note: See TracChangeset for help on using the changeset viewer.