draft-ietf-roll-indus-routing-reqs-02.txt   draft-ietf-roll-indus-routing-reqs-03.txt 
Networking Working Group K. Pister, Ed. Networking Working Group K. Pister, Ed.
Internet-Draft Dust Networks Internet-Draft Dust Networks
Intended status: Informational P. Thubert, Ed. Intended status: Informational P. Thubert, Ed.
Expires: May 4, 2009 Cisco Systems Expires: June 21, 2009 Cisco Systems
S. Dwars S. Dwars
Shell Shell
T. Phinney T. Phinney
October 31, 2008 December 18, 2008
Industrial Routing Requirements in Low Power and Lossy Networks Industrial Routing Requirements in Low Power and Lossy Networks
draft-ietf-roll-indus-routing-reqs-02 draft-ietf-roll-indus-routing-reqs-03
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any This Internet-Draft is submitted to IETF in full conformance with the
applicable patent or other IPR claims of which he or she is aware provisions of BCP 78 and BCP 79.
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on May 4, 2009. This Internet-Draft will expire on June 21, 2009.
Copyright Notice
Copyright (c) 2008 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document.
Abstract Abstract
Wireless, low power field devices enable industrial users to Wireless, low power field devices enable industrial users to
significantly increase the amount of information collected and the significantly increase the amount of information collected and the
number of control points that can be remotely managed. The number of control points that can be remotely managed. The
deployment of these wireless devices will significantly improve the deployment of these wireless devices will significantly improve the
productivity and safety of the plants while increasing the efficiency productivity and safety of the plants while increasing the efficiency
of the plant workers by extending the information set available from of the plant workers by extending the information set available from
wired systems. In an industrial environment, low power, high wired systems. In an industrial environment, low power, high
skipping to change at page 2, line 16 skipping to change at page 3, line 7
and Lossy Networks (LLN) in industrial environments. and Lossy Networks (LLN) in industrial environments.
Requirements Language Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
Table of Contents Table of Contents
1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Applications and Traffic Patterns . . . . . . . . . . . . 4 2.1. Applications and Traffic Patterns . . . . . . . . . . . . 5
2.2. Network Topology of Industrial Applications . . . . . . . 8 2.2. Network Topology of Industrial Applications . . . . . . . 9
2.2.1. The Physical Topology . . . . . . . . . . . . . . . . 9 2.2.1. The Physical Topology . . . . . . . . . . . . . . . . 10
2.2.2. Logical Topologies . . . . . . . . . . . . . . . . . . 10 2.2.2. Logical Topologies . . . . . . . . . . . . . . . . . . 11
3. Traffic Characteristics . . . . . . . . . . . . . . . . . . . 12 3. Traffic Characteristics . . . . . . . . . . . . . . . . . . . 13
3.1. Service Parameters . . . . . . . . . . . . . . . . . . . . 12 3.1. Service Parameters . . . . . . . . . . . . . . . . . . . . 13
3.2. Configurable Application Requirement . . . . . . . . . . . 13 3.2. Configurable Application Requirement . . . . . . . . . . . 14
3.3. Different Routes for Different Flows . . . . . . . . . . . 14 3.3. Different Routes for Different Flows . . . . . . . . . . . 15
4. Reliability Requirements . . . . . . . . . . . . . . . . . . . 14 4. Reliability Requirements . . . . . . . . . . . . . . . . . . . 15
5. Device-Aware Routing Requirements . . . . . . . . . . . . . . 16 5. Device-Aware Routing Requirements . . . . . . . . . . . . . . 17
6. Broadcast/Multicast . . . . . . . . . . . . . . . . . . . . . 17 6. Broadcast/Multicast . . . . . . . . . . . . . . . . . . . . . 18
7. Route Establishment Time . . . . . . . . . . . . . . . . . . . 18 7. Route Establishment Time . . . . . . . . . . . . . . . . . . . 19
8. Mobility . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 8. Mobility . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
9. Manageability . . . . . . . . . . . . . . . . . . . . . . . . 19 9. Manageability . . . . . . . . . . . . . . . . . . . . . . . . 20
10. Security . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 10. Security . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
13.1. Normative References . . . . . . . . . . . . . . . . . . . 22 13.1. Normative References . . . . . . . . . . . . . . . . . . . 23
13.2. Informative References . . . . . . . . . . . . . . . . . . 22 13.2. Informative References . . . . . . . . . . . . . . . . . . 23
13.3. External Informative References . . . . . . . . . . . . . 22 13.3. External Informative References . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23
Intellectual Property and Copyright Statements . . . . . . . . . . 24
1. Terminology 1. Terminology
This document employes terminology defined in the ROLL terminology This document employes terminology defined in the ROLL terminology
document [I-D.vasseur-roll-terminology]. This document also refers document [I-D.ietf-roll-terminology]. This document also refers to
to industrial standards: industrial standards:
HART: "Highway Addressable Remote Transducer", a group of HART: "Highway Addressable Remote Transducer", a group of
specifications for industrial process and control devices specifications for industrial process and control devices
administered by the HART Foundation (see [HART]). The latest version administered by the HART Foundation (see [HART]). The latest version
for the specifications is HART7 which includes the additions for for the specifications is HART7 which includes the additions for
WirelessHART. WirelessHART.
ISA: "International Society of Automation". ISA is an ANSI ISA: "International Society of Automation". ISA is an ANSI
accredited standards-making society. ISA100 is an ISA committee accredited standards-making society. ISA100 is an ISA committee
whose charter includes defining a family of standards for industrial whose charter includes defining a family of standards for industrial
skipping to change at page 15, line 46 skipping to change at page 16, line 46
less than 90% with hours of latency. Most industrial standards, such less than 90% with hours of latency. Most industrial standards, such
as HART7, have set user availability expectations at 99.9%. as HART7, have set user availability expectations at 99.9%.
Regulatory requirements are a driver for some industrial Regulatory requirements are a driver for some industrial
applications. Regulatory monitoring requires high data integrity applications. Regulatory monitoring requires high data integrity
because lost data is assumed to be out of compliance and subject to because lost data is assumed to be out of compliance and subject to
fines. This can drive up either availability, or thrustworthiness fines. This can drive up either availability, or thrustworthiness
requirements. requirements.
Because LLN link stability is often low, path diversity is critical. Because LLN link stability is often low, path diversity is critical.
Hop-by-hop link diversity is used to improve latency-bounded Hop-by-hop link diversity is used to improve latency-bounded
reliability. Additionally, bicasting or pluricasting may be used reliability by sending data over diverse paths.
over multiple non congruent / non overlapping paths to increase the
likelihood that at least one instance of a critical packet be
delivered error free.
Because data from field devices are aggregated and funneled at the Because data from field devices are aggregated and funneled at the
LLN access point before they are routed to plant applications, LLN LLN access point before they are routed to plant applications, LLN
access point redundancy is an important factor in overall access point redundancy is an important factor in overall
availability. A route that connects a field device to a plant availability. A route that connects a field device to a plant
application may have multiple paths that go through more than one LLN application may have multiple paths that go through more than one LLN
access point. The routing protocol MUST be able to compute paths access point. The routing protocol MUST be able to compute paths of
towards different destinations so as to perform load balancing across not-necessarily-equal cost toward a given destination so as to enable
a variety of paths. The availability of each path in a multipath load balancing across a variety of paths. The availability of each
route can change over time. Hence, it is important to measure the path in a multipath route can change over time. Hence, it is
availability on a per-path basis and select a path (or paths) important to measure the availability on a per-path basis and select
according to the availability requirements. a path (or paths) according to the availability requirements.
5. Device-Aware Routing Requirements 5. Device-Aware Routing Requirements
Wireless LLN nodes in industrial environments are powered by a Wireless LLN nodes in industrial environments are powered by a
variety of sources. Battery operated devices with lifetime variety of sources. Battery operated devices with lifetime
requirements of at least five years are the most common. Battery requirements of at least five years are the most common. Battery
operated devices have a cap on their total energy, and typically can operated devices have a cap on their total energy, and typically can
report an estimate of remaining energy, and typically do not have report an estimate of remaining energy, and typically do not have
constraints on the short-term average power consumption. Energy constraints on the short-term average power consumption. Energy
scavenging devices are more complex. These systems contain both a scavenging devices are more complex. These systems contain both a
skipping to change at page 20, line 17 skipping to change at page 21, line 15
There will be many new applications where even without any human There will be many new applications where even without any human
intervention at the plant, devices that have never been on site intervention at the plant, devices that have never been on site
before, should be allowed, based on their credentials and crypto before, should be allowed, based on their credentials and crypto
capabilities, to connect anyway. Examples are 3rd party road capabilities, to connect anyway. Examples are 3rd party road
tankers, rail cargo containers with overfill protection sensors, or tankers, rail cargo containers with overfill protection sensors, or
consumer cars that need to be refueled with hydrogen by robots at consumer cars that need to be refueled with hydrogen by robots at
future petrol stations. future petrol stations.
The routing protocol for LLNs is expected to be easy to deploy and The routing protocol for LLNs is expected to be easy to deploy and
manage. Because the number of field devices in a network is large, manage. Because the number of field devices in a network is large,
provisioning the devices manually may not make sense. Therefore, the provisioning the devices manually may not make sense. The routing
routing protocol MUST support auto-provisioning of field devices. MAY require commissioning of information about the node itself, like
The protocol also MUST support the distribution of configuration from identity, security tokens, radio standards and frequencies, etc. The
a centralized management controller if operator-initiated routing protocol SHOULD NOT require to preprovision information about
configuration change is allowed. the environment where the node will be deployed. The routing
protocol MUST enable the full discovery and setup of the environment
(available links, selected peers, reachable network).The protocol
also MUST support the distribution of configuration from a
centralized management controller if operator-initiated configuration
change is allowed.
10. Security 10. Security
Given that wireless sensor networks in industrial automation operate Given that wireless sensor networks in industrial automation operate
in systems that have substantial financial and human safety in systems that have substantial financial and human safety
implications, security is of considerable concern. Levels of implications, security is of considerable concern. Levels of
security violation that are tolerated as a "cost of doing business" security violation that are tolerated as a "cost of doing business"
in the banking industry are not acceptable when in some cases in the banking industry are not acceptable when in some cases
literally thousands of lives may be at risk. literally thousands of lives may be at risk.
skipping to change at page 22, line 23 skipping to change at page 23, line 24
13. References 13. References
13.1. Normative References 13.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
13.2. Informative References 13.2. Informative References
[I-D.vasseur-roll-terminology] [I-D.ietf-roll-terminology]
Vasseur, J., "Terminology in Low power And Lossy Vasseur, J., "Terminology in Low power And Lossy
Networks", draft-vasseur-roll-terminology-02 (work in Networks", draft-ietf-roll-terminology-00 (work in
progress), September 2008. progress), October 2008.
13.3. External Informative References 13.3. External Informative References
[HART] www.hartcomm.org, "Highway Addressable Remote Transducer", [HART] www.hartcomm.org, "Highway Addressable Remote Transducer",
a group of specifications for industrial process and a group of specifications for industrial process and
control devices administered by the HART Foundation". control devices administered by the HART Foundation".
[ISA100.11a] [ISA100.11a]
ISA, "ISA100, Wireless Systems for Automation", May 2008, ISA, "ISA100, Wireless Systems for Automation", May 2008,
< http://www.isa.org/Community/ < http://www.isa.org/Community/
skipping to change at page 24, line 4 skipping to change at line 1077
Phone: +31 70 447 2660 Phone: +31 70 447 2660
Email: sicco.dwars@shell.com Email: sicco.dwars@shell.com
Tom Phinney Tom Phinney
5012 W. Torrey Pines Circle 5012 W. Torrey Pines Circle
Glendale, AZ 85308-3221 Glendale, AZ 85308-3221
USA USA
Phone: +1 602 938 3163 Phone: +1 602 938 3163
Email: tom.phinney@cox.net Email: tom.phinney@cox.net
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
 End of changes. 13 change blocks. 
53 lines changed or deleted 64 lines changed or added

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