--- 1/draft-ietf-roll-indus-routing-reqs-03.txt 2009-01-22 10:12:03.000000000 +0100 +++ 2/draft-ietf-roll-indus-routing-reqs-04.txt 2009-01-22 10:12:03.000000000 +0100 @@ -1,22 +1,22 @@ Networking Working Group K. Pister, Ed. Internet-Draft Dust Networks Intended status: Informational P. Thubert, Ed. -Expires: June 21, 2009 Cisco Systems +Expires: July 26, 2009 Cisco Systems S. Dwars Shell T. Phinney - December 18, 2008 + January 22, 2009 Industrial Routing Requirements in Low Power and Lossy Networks - draft-ietf-roll-indus-routing-reqs-03 + draft-ietf-roll-indus-routing-reqs-04 Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. @@ -25,25 +25,25 @@ and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. - This Internet-Draft will expire on June 21, 2009. + This Internet-Draft will expire on July 26, 2009. Copyright Notice - Copyright (c) 2008 IETF Trust and the persons identified as the + Copyright (c) 2009 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 @@ -66,39 +66,39 @@ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. Table of Contents 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Applications and Traffic Patterns . . . . . . . . . . . . 5 2.2. Network Topology of Industrial Applications . . . . . . . 9 2.2.1. The Physical Topology . . . . . . . . . . . . . . . . 10 - 2.2.2. Logical Topologies . . . . . . . . . . . . . . . . . . 11 + 2.2.2. Logical Topologies . . . . . . . . . . . . . . . . . . 12 3. Traffic Characteristics . . . . . . . . . . . . . . . . . . . 13 - 3.1. Service Parameters . . . . . . . . . . . . . . . . . . . . 13 - 3.2. Configurable Application Requirement . . . . . . . . . . . 14 + 3.1. Service Parameters . . . . . . . . . . . . . . . . . . . . 14 + 3.2. Configurable Application Requirement . . . . . . . . . . . 15 3.3. Different Routes for Different Flows . . . . . . . . . . . 15 4. Reliability Requirements . . . . . . . . . . . . . . . . . . . 15 5. Device-Aware Routing Requirements . . . . . . . . . . . . . . 17 6. Broadcast/Multicast . . . . . . . . . . . . . . . . . . . . . 18 7. Route Establishment Time . . . . . . . . . . . . . . . . . . . 19 8. Mobility . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 9. Manageability . . . . . . . . . . . . . . . . . . . . . . . . 20 10. Security . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 13.1. Normative References . . . . . . . . . . . . . . . . . . . 23 13.2. Informative References . . . . . . . . . . . . . . . . . . 23 13.3. External Informative References . . . . . . . . . . . . . 23 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 1. Terminology This document employes terminology defined in the ROLL terminology document [I-D.ietf-roll-terminology]. This document also refers to industrial standards: HART: "Highway Addressable Remote Transducer", a group of specifications for industrial process and control devices administered by the HART Foundation (see [HART]). The latest version @@ -112,21 +112,24 @@ working on a standard for monitoring and non-critical process control applications. 2. Introduction Wireless, low-power field devices enable industrial users to significantly increase the amount of information collected and the number of control points that can be remotely managed. The deployment of these wireless devices will significantly improve the productivity and safety of the plants while increasing the efficiency - of the plant workers. + of the plant workers. IPv6 is perceived as a key technology to + provide the scalability and interoperability that are required in + that space and is being more and more present in standards and + products under development and early deployments. Cable is perceived as a more proven, safer techhnology, and existing, operational deployments are very stable in time. For these reasons, it is not expected that wireless will replace wire in any foreseeable future; the consensus in the industrial space is rather that wireless will tremendously augment the scope and benefits of automation by enabling the control of devices that were not connected in the past for reasons of cost and/or deployment complexities. But for LLN to be adopted in the industrial environment, the wireless network needs to have three qualities: low power, high reliability, and easy @@ -620,22 +623,23 @@ 3.2. Configurable Application Requirement Time-varying user requirements for latency and bandwidth may require changes in the provisioning of the underlying L2 protocols. A technician may initiate a query/response session or bulk transfer to diagnose or configure a field device. A level sensor device may need to perform a calibration and send a bulk file to a plant. The routing protocol MUST route on paths that are changed to appropriately provision the application requirements. The routing - protocol MUST support the ability to recompute paths based on - underlying link attributes/metric that may change dynamically. + protocol MUST support the ability to recompute paths based on Network + Layer abstractions of the underlying link attributes/metric that may + change dynamically. 3.3. Different Routes for Different Flows Because different services categories have different service requirements, it is often desirable to have different routes for different data flows between the same two endpoints. For example, alarm or periodic data from A to Z may require path diversity with specific latency and reliability. A file transfer between A and Z may not need path diversity. The routing algorithm MUST be able to generate different routes with different characteritics (e.g.