Re: [6tisch] [Detnet] comments on draft-finn-detnet-architecture-00
Tom Phinney <tom.phinney@cox.net> Fri, 10 April 2015 04:05 UTC
Return-Path: <tom.phinney@cox.net>
X-Original-To: 6tisch@ietfa.amsl.com
Delivered-To: 6tisch@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6064C1AC3F8 for <6tisch@ietfa.amsl.com>; Thu, 9 Apr 2015 21:05:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.645
X-Spam-Level: *
X-Spam-Status: No, score=1.645 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FSL_HELO_BARE_IP_2=1.675, HTML_MESSAGE=0.001, HTML_TAG_BALANCE_BODY=1.157, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SuRUJSKJP0WW for <6tisch@ietfa.amsl.com>; Thu, 9 Apr 2015 21:05:10 -0700 (PDT)
Received: from fed1rmfepo101.cox.net (fed1rmfepo101.cox.net [68.230.241.143]) by ietfa.amsl.com (Postfix) with ESMTP id 814781AC3C4 for <6tisch@ietf.org>; Thu, 9 Apr 2015 21:05:09 -0700 (PDT)
Received: from fed1rmimpo110 ([68.230.241.159]) by fed1rmfepo101.cox.net (InterMail vM.8.01.05.15 201-2260-151-145-20131218) with ESMTP id <20150410040508.YGIJ32482.fed1rmfepo101.cox.net@fed1rmimpo110> for <6tisch@ietf.org>; Fri, 10 Apr 2015 00:05:08 -0400
Received: from 192.168.1.110 ([68.110.82.164]) by fed1rmimpo110 with cox id E4551q0013YjG0401456Be; Fri, 10 Apr 2015 00:05:07 -0400
X-CT-Class: Clean
X-CT-Score: 0.00
X-CT-RefID: str=0001.0A020202.55274BF4.00D1,ss=1,re=0.000,fgs=0
X-CT-Spam: 0
X-Authority-Analysis: v=2.0 cv=bZS1ppzB c=1 sm=1 a=/lROMdMM8hnpqyhFWVF1XA==:17 a=CA33sFktnKwA:10 a=IkcTkHD0fZMA:10 a=kviXuzpPAAAA:8 a=CjxXgO3LAAAA:8 a=AUd_NHdVAAAA:8 a=48vgC7mUAAAA:8 a=7Co_eziMAAAA:8 a=uPZudtgEAAAA:8 a=0bwPlpDAAAAA:8 a=o83nqyVRAAAA:8 a=dHJOhkScAAAA:8 a=VX9qjH_wCUPxlYp7tcUA:9 a=QEXdDO2ut3YA:10 a=_W_S_7VecoQA:10 a=Sf_gFPzhefAA:10 a=UdLusSZ9F3OWlHTt:21 a=sx5hE5fTCq8oSxQj:21 a=/lROMdMM8hnpqyhFWVF1XA==:117
X-CM-Score: 0.00
Authentication-Results: cox.net; none
Message-ID: <55274BF1.4010001@cox.net>
Date: Thu, 09 Apr 2015 21:05:05 -0700
From: Tom Phinney <tom.phinney@cox.net>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
To: 6tisch@ietf.org
References: <D14C0BB5.52A8D%pwetterw@cisco.com> <DrA31q00m0xxhYs01rA4Mm>
In-Reply-To: <DrA31q00m0xxhYs01rA4Mm>
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/6tisch/5sJ8yanpy-A0ft4yatcwnzlmOk0>
Subject: Re: [6tisch] [Detnet] comments on draft-finn-detnet-architecture-00
X-BeenThere: 6tisch@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Tom Phinney <tom.phinney@cox.net>
List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:6tisch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/6tisch/>
List-Post: <mailto:6tisch@ietf.org>
List-Help: <mailto:6tisch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:6tisch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 10 Apr 2015 04:05:20 -0000
I believe that you are correct. Communications jitter would directly affect a system only if either the source or destination (or perhaps both) had no buffering. If a microphone output is digitized and streamed immediately to a distant speaker, then jitter IN THE COMMUNICATIONS would be apparent. Otherwise it is the end-to-end jitter between the clocked periodic input to the source buffer and the clocked periodic output of the sink buffer that is significant.
In most closed-loop control systems, it is important that data that is sampled from the controlled process in epoch N be delivered to the computational element that computes the closed-loop correction in epoch N+j, and that the output of that computation be delivered to the controlled effector element (e.g., a valve) in epoch N+k. Usually j and k are equal to zero, but the same logic holds when they are very small integers, 0 <= j <=k.
It is important that the data not be delivered in the wrong epoch, because it is possible to destabilize a control loop without spoofing or losing or reordering any data simply by deliberately jittering the arrival epoch. Honeywell demonstrated this years ago.
However, communications jitter that causes the data to arrive slightly earlier in one epoch than in another is not relevant, provided that the jitter is not so much as to cause the data to arrive in the wrong epoch.
-Tom
====
Hi Patrick,
I don't understand why communication jitter = 0 is so important. Assume DetNet can guarantee the maximum end-to-end latency, and there is a well designed buffer in the Listener device, then I think the Listener can consume data just on time, in another word, from application point of view, jitter =0. Please point out if I'm wrong.
ThanksQin
Norm, Pascal,
Some other comments:
- If you look at https://tools.ietf.org/html/draft-wetterwald-detnet-utilities-reqs">https://tools.ietf.org/html/draft-wetterwald-detnet-utilities-reqs you will see that for some important use cases, the jitter should very close to zero. In the architecture draft, you are mainly focussing on the maximum value of the latency and the packet loss (at least in the text). This is not sufficient for power automation and tele protection use case. We need to be able to deploy deterministic network with Jitter = 0.
- Second: may be good to reference the requirement drafts in the doc. :-)
Thanks,
Patrick
From: Thomas Watteyne <watteyne@eecs.berkeley.edu>
Date: Monday 23 March 2015 18:44
To: "detnet@ietf.org" <detnet@ietf.org>, "6tisch@ietf.org" <6tisch@ietf.org>
Subject: [Detnet] comments on draft-finn-detnet-architecture-00
Norm, Pascal,
Please find below a number of comment on draft-finn-detnet-architecture-00.
Overall, the draft is very well written and highlights important points for deterministic networking.
My general comments are:- in the context of a low-power wireless network (e.g. 6TiSCH), I wonder what you thoughts are on reserving a fixed path. Maybe some extra text on redundancy is needed?- would it make sense to discuss the difference between hard and soft real-time, also wrt wireless systems?
Thomas
---
DetNet N. FinnInternet-Draft P. ThubertIntended status: Standards Track CiscoExpires: September 10, 2015 March 9, 2015
Deterministic Networking Architecturedraft-finn-detnet-architecture-00
Abstract
Deterministic Networking (DetNet) provides a capability to carryspecified unicast or multicast data streams for real-timeapplications with extremely low data loss rates and maximum latency.TW> it looks like you aim for maximum latency :)Techniques used include: 1) reserving data plane resources forindividual (or aggregated) DetNet streams in some or all of the relaysystems (bridges or routers) along the path of the stream; 2)providing fixed paths for DetNet streams that do not rapidly changewith the network topology; and 3) sequentializing, replicating, andeliminating duplicate packets at various points to ensure theavailability of at least one path. The capabilities can be managedby configuration, or by manual or automatic network management.
Status of This Memo
This Internet-Draft is submitted in full conformance with theprovisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet EngineeringTask Force (IETF). Note that other groups may also distributeworking documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/"> http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six monthsand may be updated, replaced, or obsoleted by other documents at anytime. It is inappropriate to use Internet-Drafts as referencematerial or to cite them other than as "work in progress."
This Internet-Draft will expire on September 10, 2015.
Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as thedocument authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's LegalProvisions Relating to IETF Documents(http://trustee.ietf.org/license-info">http://trustee.ietf.org/license-info) in effect on the date of
Finn & Thubert Expires September 10, 2015 [Page 1]Internet-Draft Deterministic Networking Architecture March 2015
publication of this document. Please review these documentscarefully, as they describe your rights and restrictions with respectto this document. Code Components extracted from this document mustinclude Simplified BSD License text as described in Section 4.e ofthe Trust Legal Provisions and are provided without warranty asdescribed in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 22. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 43. Providing the DetNet Quality of Service . . . . . . . . . . . 53.1. Zero Congestion Loss . . . . . . . . . . . . . . . . . . 63.2. Pinned-down paths . . . . . . . . . . . . . . . . . . . . 73.3. Seamless Redundancy . . . . . . . . . . . . . . . . . . . 74. DetNet Architecture . . . . . . . . . . . . . . . . . . . . . 84.1. The Application Plane . . . . . . . . . . . . . . . . . . 114.2. The Controller Plane . . . . . . . . . . . . . . . . . . 114.3. The Network Plane . . . . . . . . . . . . . . . . . . . . 124.4. Elements of DetNet Architecture . . . . . . . . . . . . . 134.5. DetNet streams . . . . . . . . . . . . . . . . . . . . . 144.5.1. Talker guarantees . . . . . . . . . . . . . . . . . . 144.5.2. Incomplete Networks . . . . . . . . . . . . . . . . . 154.6. Data Flow Model through Systems . . . . . . . . . . . . . 164.7. Queuing, Shaping, Scheduling, and Preemption . . . . . . 164.8. Coexistence with normal traffic . . . . . . . . . . . . . 164.9. Fault Mitigation . . . . . . . . . . . . . . . . . . . . 164.10. Protocol Stack Model . . . . . . . . . . . . . . . . . . 174.11. Advertising resources, capabilities and adjacencies . . . 174.12. Provisioning model . . . . . . . . . . . . . . . . . . . 174.12.1. Centralized Path Computation and Installation . . . 174.12.2. Distributed Path Setup . . . . . . . . . . . . . . . 175. Related IETF work . . . . . . . . . . . . . . . . . . . . . . 185.1. Deterministic PHB . . . . . . . . . . . . . . . . . . . . 185.2. 6TiSCH . . . . . . . . . . . . . . . . . . . . . . . . . 186. Security Considerations . . . . . . . . . . . . . . . . . . . 197. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 198. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 199. Informative References . . . . . . . . . . . . . . . . . . . 19Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23
1. Introduction
Operational Technology (OT) refers to industrial networks that aretypically used for monitoring systems and supporting control loops,as well as movement detection systems for use in process control(i.e., process manufacturing) and factory automation (i.e., discretemanufacturing). Due to its different goals, OT has evolved in
Finn & Thubert Expires September 10, 2015 [Page 2]Internet-Draft Deterministic Networking Architecture March 2015
parallel but in a manner that is radically different from IT/ICT,TW> define IT and ICT at first usefocusing on highly secure, reliable and deterministic networks, withlimited scalability over a bounded area.
The convergence of IT and OT technologies, also called the IndustrialInternet, represents a major evolution for both sides. The work hasalready started; in particular, the industrial automation space hasbeen developing a number of Ethernet-based replacements for existingdigital control systems, often not packet-based (fieldbustechnologies).
These replacements are meant to provide similar behavior as theincumbent protocols, and their common focus is to transportTW> "on transporting"?a fullycharacterized flow over a well-controlled environment (i.e., afactory floor), with a bounded latency, extraordinarily low frameloss, and a very narrow jitter. Examples of such protocols includePROFINET, ODVA Ethernet/IP, and EtherCAT.TW> It might be good to quantify the target latency, packet loss and jitter.TW> I appreciate this is not easy, but one representatve example might helpIn parallel, the need for determinism in professional and home audio/video markets drove the formation of the Audio/Video Bridging (AVB)standards effort of IEEE 802.1. With the explosion of demand forconnectivity and multimedia in transportation in general, theEthernet AVB technology has become one of the hottest topics, inparticular in the automotive connectivity. It is finding applicationin all elements of the vehicleTW> ":"from head units, to rear seatentertainment modules, to amplifiers and camera modules. While aimedat less critical applications than some industrial networks, AVBnetworks share the requirement for extremely low packet loss ratesand ensured finite latency and jitter.TW> ensure -> guarantee?
Other instances of in-vehicle deterministic networks have arisen aswell for control networks in cars, trains and buses, as well asavionics, with, for instance, the mission-critical "Avionics Full-Duplex Switched Ethernet" (AFDX) that was designed as part of theARINC 664 standards. Existing automotive control networks such asthe LIN, CAN andTW> would TTP/C fit in this list?FlexRay standards were not designed to cover theseincreasing demands in terms of bandwidth and scalability that we seewith various kinds of Driver Assistance Systems (DAS) and newmultiplexing technologies based on Ethernet are now getting traction.
The generalization of the needs for more deterministic networks haveled to the IEEE 802.1 AVB Task Group becoming the Time-SensitiveNetworking (TSN) Task Group (TG), with a much-expanded constituencyfrom the industrial and vehicular markets. Along with thisexpansion, the networks in consideration are becoming larger andstructured, requiring deterministic forwarding beyond the LANboundaries. For instance, Industrial Automation segregates thenetwork along the broad lines of the Purdue Enterprise Reference
Finn & Thubert Expires September 10, 2015 [Page 3]Internet-Draft Deterministic Networking Architecture March 2015
Architecture (PERA), using different technologies at each level, andpublic infrastructures such as Electricity Automation requiredeterministic properties over the Wide Area. The realization is nowcoming that the convergence of IT and OT networks requires Layer-3,as well as Layer-2, capabilities.
The present architecture is the result of a collaboration of the IETFand the IEEE and implements an abstract model that can be applicableboth at Layer-2 and Layer-3, and along segments of differenttechnologie.TW> typoWith this new work, a path may span, for instance,across a (limited) number of 802.1 bridges and then a (limited)number of IP routers.TW> add somethind like "possibly wireless" somewhere?In that example, the IEEE 802.1 bridges may beoperating at Layer-2 over Ethernet whereas the IP routers may be6TiSCH nodes operating at Layer-2 and/or Layer-3 over the IEEE802.15.4e MAC.
Many applications of interest to Deterministic Networking require theability to synchronize the clocks in end systems to a sub-microsecondaccuracy.TW> why this accuracy?Some of the queue control techniques defined inSection 4.7 also require time synchronization among relay systems.The means used to achieve time synchronization are not addressed inthis document.
2. Terminology
The follwingTW> typospecial terms are used in this document in order toavoid the assumption that a given element in the archetectureTW> typodoes ordoes not have Internet Protocol stack, functions as a router or abridge, or otherwise plays a particular role at Layer-3 or higher:TW> I don't get the sentence above
bridgeA Customer Bridge as defined by IEEE 802.1Q[IEEE802.1Q-2011].
circuitA trail of configuration from talker to listener(s)TW> sender and receiver might be more common at the IETF?throughrelay systems associated with a DetNet stream, required todeliver the benefits of DetNet.
end systemCommonly called a "host" in IETF documents, and an "endstation" is IEEE 802 documents. End systems of interest tothis document are talkers and listeners.
listenerAn end system capable of sinking a DetNet stream.
relay system
Finn & Thubert Expires September 10, 2015 [Page 4]Internet-Draft Deterministic Networking Architecture March 2015
A router or a bridge.TW> maybe add "layer 2 bridge" and "layer 3 router" for clarity?
streamA DetNet stream is a sequence of packets from a singletalker, through some number of relay systems to one or morelisteners, that is limited by the talker in its maximumpacket size and transmission rate, and can thus be ensuredthe DetNet Quality of Service (QoS) from the network.
talkerAn end system capable of sourcing a DetNet stream.
3. Providing the DetNet Quality of Service
DetNet Quality of Service is expressed in terms of:
o Minimum and maximum end-to-end latency from talker to listener;
o Probability of loss of a packet, assuming the normal operation ofthe relay systems and links;
o Probability of loss of a packet in the event of the failure of arelay system or link.
It is a distinction of DetNet that it is concerned solely with worst-case values for all of the above parameters. Average, mean, ortypical values are of no interest, because they do not affect theability of a real-time system to perform its tasks.TW> Would it make sense to discuss hard and soft real-time here, inTW> particular in the context of a wireless system?
Three techniques are employed by DetNet to achieve these QoSparameters:
a. Zero congestion loss (Section 3.1). Network resources such aslink bandwidth, buffers, queues, shapers, and scheduled input/TW> add 6TiSCH cells?output slots are assigned in each relay system to the use of aspecific DetNet stream or group of streams. Note that, given afinite amount of buffer space)TW> extra ")", zero congestion loss necessarilyensures a maximum end-to-end latency. Depending on the methodemployed, a minimum latency can also be achieved.
b. Pinned-down paths (Section 3.2). Point-to-point paths or point-to-multipoint trees through the network from a talker to one ormore listeners can be established, and DetNet streams assigned tofollow a particular path or tree.TW> Using a single path in a wireless system will fail, I would recommendTW> discussing here path redundancy, for example through DAGs
c. Packet replication and deletion (Section 3.3). End systems and/or relay systems can sequence number, replicate, and eliminatereplicated packets at multiple points in the network in order to
Finn & Thubert Expires September 10, 2015 [Page 5]Internet-Draft Deterministic Networking Architecture March 2015
ensure that one (or more) equipment failure events still leave atleast one path intact for a DetNet stream.
These three techniques can be applied independently, giving eightpossible combinations, including none (no DetNet), although somecombinations are of wider utility than others. This separation keepsthe protocol stack coherent and maximizes interoperability withexisting and developing standards in this (IETF) and other StandardsDevelopment Organizations. Some examples of typical expectedcombinations:
o Pinned-down paths (a) plus packet replication (b) are exactly thetechniques employed by [HSR-PRP]. Pinned-down paths are achieveby limiting the physical topology of the network, and thesequentialization, replication, and duplicate eliminationfacilitated by packet tags added at the front or the end ofEthernet frames.
o Zero congestion loss (a) alone is is offered by IEEE 802.1 AudioVideo bridging [IEEE802.1BA-2011]. As long as the network suffersno failures, near-zero (at best, zero) congestion loss can beachieved through the use of a reservation protocol (MSRP) andshapers in every relay system (bridge).
o Using all three together gives maximum protection.
There are, of course, simpler methods available (and employed, today)to achieve levels of latency and packet loss that are satisfactoryfor many applications. However, these methods generally work best inthe absence of any significant amount of non-critical traffic in thenetwork (if, indeed, such traffic is supported at all), or work onlyif the critical traffic constitutes only a small portion of thenetwork's theoretical capacity, or work only if all systems arefunctioning properly, or in the absence of actions by end systemsthat disrupt the network's operations.
There are any number of methods in use, defined, or in progress foraccomplishing each of the above techniques. It is expected that thisDetNet Architecture will assist various vendors, users, and/or"vertical" Standards Development Organizations (dedicated to a singleindustry) to make selections among the available means ofimplementing DetNet networks.
3.1. Zero Congestion Loss
The primary means by which DetNet achieves its QoS assurances is tocompletely eliminate congestion at an output port as a cause ofpacket loss. Given that a DetNet stream cannot be throttled, this
Finn & Thubert Expires September 10, 2015 [Page 6]Internet-Draft Deterministic Networking Architecture March 2015
can be achieved only by the provision of sufficient buffer storage ateach hop through the network to ensure that no packets are droppeddue to a lack of buffer storage.TW> and the provision the sufficient link bandwidth?
Ensuring adequate buffering requires, in turn, that the talker, andevery relay system along the path to the listener (or nearly everyrelay system -- see Section 4.5.2) be careful to regulate its outputto not exceed the data rate for any stream, except for brief periosTW> typowhen making up for interfering traffic. Any packet sent ahead of itstime potentially adds to the number of buffers required by the nexthop, and may thus exceed the resources allocated for a particularstream.
The low-level mechanisms described in Section 4.7 provide thenecessary regulation of transmissions by an edge system or relaysystem to ensure zero congestion loss. Of course, the reservation ofthe bandwidth and buffers for a stream requires the provisioningdescribed in Section 4.12.
3.2. Pinned-down paths
In networks controlled by typical peer-to-peer protocols such as IEEE802.1 ISIS bridged networks or ETF OSPF routed networks, a networktopology event in one part of the network can impact, at leastbriefly, the delivery of data in parts of the network remote from thefailure or recovery event. Thus, even redundant paths through anetwork, if controlled by the typical peer-to-peer protocols, do noteliminate the chances of brief losses of contact. For this reason,many real-time networks rely on physical rings of two-port devices,with a relatively simple ring control protocol. This both minimizesrecovery time and easily supports redundant paths. Of course, thiscomes at the cost of increased hop count, and thus latency, for thetypical path.
In order to get the advantages of low hop count and still ensureagainst even brief losses of connectivity, DetNet employs pinned-downpaths, where the path taken by a given DetNet stream does not change,at least immediately, and likely not at all, in response to networktopology events. When combined with seamless redundancy(Section 3.3), this results in a high likelihood of continuousconnectivity.
3.3. Seamless Redundancy
After congestion loss has been eliminated, the most important causesof packet loss are random media and/or memory faults and equipmentfailures.
Finn & Thubert Expires September 10, 2015 [Page 7]Internet-Draft Deterministic Networking Architecture March 2015
Seamless redundancy involves three capabilities:
o Adding sequence numbers to the packets of a DetNet stream.
o Replicating these packets and, typically, sending them along atleast two different paths to the listener(s).
o Discarding duplicated packets.
In the simplest case, this amounts to replicating each packet in atalker that has two interfaces, and conveying them through thenetwork, along separate paths, to the similarly dual-homed listeners,that discard the extras. This ensures that one path (with zerocongestion loss) remains, even if some relay system fails.TW> this has some energy cost associated?Alternatively, relay systems in the network can provide replicationand elimination facilities at various points in the network, so thatmultiple failures can be accommodated.
This is shown in the following figure, where the two relay systemseach replicate (R) the DetNet stream on input, sending the stream toboth the other relay system and to the end system, and eliminatedduplicates (E) on the output interface to the right-hand end system.Any one linksTW> typoin the network can fail, and the Detnet stream canstill get through. Furthermore, two links can fail, as long as theyare in different segments of the network.
> > > > > > > > relay > > > > > > > >> /------------+ R system E +------------\ >> / v + ^ \ >end R + v | ^ + E endsystem + v | ^ + system> \ v + ^ / >> \------------+ R relay E +------------/ >> > > > > > > > system > > > > > > > >
Figure 1TW> I don't understand what R and E means
4. DetNet Architecture
Traffic Engineering Architecture and Signaling (TEAS) [TEAS] definestraffic-engineering architectures for generic applicability acrosspacket and non-packet networks. From TEAS perspective, TrafficEngineering (TE) refers to techniques that enable operators tocontrol how specific traffic flows are treated within their networks.
Because if its very nature of establishing pinned-down optimizedpaths, Deterministic Networking can be seen as a new, specialized
Finn & Thubert Expires September 10, 2015 [Page 8]Internet-Draft Deterministic Networking Architecture March 2015
branch of Traffic Engineering, and inherits its architecture with aseparation into planes.
The Deterministic Networking architecture is thus composed of threeplanes, a (User) Application Plane, a Controller Plane, and a NetworkPlane, which echoes that of Software-Defined Networking (SDN):TW> double ":"Layersand Architecture Terminology [RFC7426] which is represented below:
Finn & Thubert Expires September 10, 2015 [Page 9]Internet-Draft Deterministic Networking Architecture March 2015
SDN Layers and Architecture Terminology per RFC 7426
o--------------------------------o| || +-------------+ +----------+ || | Application | | Service | || +-------------+ +----------+ || Application Plane |o---------------Y----------------o|*-----------------------------Y---------------------------------*| Network Services Abstraction Layer (NSAL) |*------Y------------------------------------------------Y-------*| || Service Interface || |o------Y------------------o o---------------------Y------o| | Control Plane | | Management Plane | || +----Y----+ +-----+ | | +-----+ +----Y----+ || | Service | | App | | | | App | | Service | || +----Y----+ +--Y--+ | | +--Y--+ +----Y----+ || | | | | | | || *----Y-----------Y----* | | *---Y---------------Y----* || | Control Abstraction | | | | Management Abstraction | || | Layer (CAL) | | | | Layer (MAL) | || *----------Y----------* | | *----------Y-------------* || | | | | |o------------|------------o o------------|---------------o| || CP | MP| Southbound | Southbound| Interface | Interface| |*------------Y---------------------------------Y----------------*| Device and resource Abstraction Layer (DAL) |*------------Y---------------------------------Y----------------*| | | || o-------Y----------o +-----+ o--------Y----------o || | Forwarding Plane | | App | | Operational Plane | || o------------------o +-----+ o-------------------o || Network Device |+---------------------------------------------------------------+
Figure 2
Finn & Thubert Expires September 10, 2015 [Page 10]Internet-Draft Deterministic Networking Architecture March 2015
4.1. The Application Plane
Per [RFC7426], the Application Plane includes both applications andservices. In particular, the Application Plane incorporates the UserAgent, a specialized application that interacts with the end user /operator and performs requests for Deterministic Networking servicesvia an abstract Stream Management Entity, (SME) which may or may notbe collocated with (one of) the end systems.
At the Application Plane, a management interface enables thenegotiation of streams between end systems. An abstraction of thestream called a Traffic Specification (TSpec) provides therepresentation. This abstraction is used to place a reservation overthe (Northbound) Service Interface and within the Application plane.It is associated with an abstraction of location, such as IPaddresses and DNS names, to identify the end systems and eventuallyspecify intermediate relay systems.
4.2. The Controller Plane
The Controller Plane corresponds to the aggregation of the Controland Management Planes in [RFC7426], though Common Control andMeasurement Plane (CCAMP) [CCAMP] makes an additional distinctionbetween management and measurement. When the logical separation ofthe Control, Measurement and other Management entities is notrelevant, the term Controller Plane is used for simplicity torepresent them all, and the term controller refers to any deviceoperating in that plane, whether is it a Path Computation entity or aNetwork Management entity (NME). The Path Computation Element (PCE)[PCE] is a core element of a controller, in charge of computingDeterministic paths to be applied in the Network Plane.
A (Northbound) Service Interface enables applications in theApplication Plane to communicate with the entities in the ControllerPlane.
TW> could you define NME, SME and PCE in the terminology?One or more PCE(s) collaborate to implement the requests from the SMEas Per-Stream Per-Hop Behaviors installed in the relay systems foreach individual streams. The PCEs place each stream along adeterministic sequence of relay systems so as to respect per-streamconstraints such as security and latency, and optimize the overallresult for metrics such as an abstract aggregated cost. Thedeterministic sequence can typically be more complex than a directsequence and include redundancy path, with one or more packetreplication and elimination points.
Finn & Thubert Expires September 10, 2015 [Page 11]Internet-Draft Deterministic Networking Architecture March 2015
4.3. The Network Plane
The Network Plane represents the network devices and protocols as awhole, regardless of the Layer at which the network devices operate.
The network Plane comprises the Network Interface Cards (NIC) in theend systems, which are typically IP hosts, and relay systems, whichare typically IP routers and switches. Network-to-Network Interfacessuch as used for Traffic Engineering path reservation in [RFC3209],as well as User-to-Network Interfaces (UNI) such as provided by theLocal Management Interface (LMI) between network and end systems, areall part of the Network Plane.
A Southbound (Network) Interface enables the entities in theController Plane to communicate with devices in the Network Plane.This interface leverages and extends TEAS to describe the physicaltopology and resources in the Network Plane.
Stream Management Entity
End EndSystem System
-+-+-+-+-+-+-+ Northbound -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
PCE PCE PCE PCE
-+-+-+-+-+-+-+ Southbound -+-+-+-+-+-+-+-+-+-+--+-+-+-+-+-+-
Relay Relay Relay RelaySystem System System SystemNIC NICRelay Relay Relay RelaySystem System System System
Figure 3
The relay systems (and eventually the end systems NIC) expose theircapabilities and physical resources to the controller (the PCE), andupdate the PCE with their dynamic perception of the topology, acrossthe Southbound Interface. In return, the PCE(s) set the per-streampaths up, providing a Stream Characterization that is more tightlycoupled to the relay system Operation than a TSpec.
At the Network plane, relay systems exchange information regardingthe state of the paths, between adjacent systems and eventually withthe end systems, and forward packets within constraints associated to
Finn & Thubert Expires September 10, 2015 [Page 12]Internet-Draft Deterministic Networking Architecture March 2015
each stream, or, when unable to do so, perform a last resortoperation such as drop or declassify.
This specification focuses on the Southbound interface and theoperation of the Network Plane.
4.4. Elements of DetNet Architecture
The DetNet architecture has a number of elements, discussed in thefollowing sections:
a. A model for the definition, identification, and operation ofDetNet streams (Section 4.5), for use by relay systems toclassify and process individual packets following per-streamrules.TW> how is a packet "labeled" as part of stream?
b. A model for the flow of data from an end system or through arelay system that can be used to predict the bounds for thatsystem's impact on the QoS of a DetNet stream, withoutsignificantly constraining the method of implementing thatsystem, for use by the Controllers to configure policing andshaping engines in Network Systems over the Southbound interface.The model includes:
1. A model for queuing, transmission selection, shaping,preemption, and timing resources that can be used by an endsystem or relay system to control the selection of packetsoutput on an interface. These models must have sufficientlywell-defined characteristics, both individually and in theaggregate, to give predictable results for the QoS for DetNetpackets (Section 4.7).
2. A model for identifying misbehaving DetNet streams andmitigating their impact on properly functioning streams(Section 4.9).
c. A model for the relay system to inform the controller(s) of theinformation it needs for adequate path computations including:
1. Systems' individual capabilities (e.g. can do replication,can do precise time).
2. Link capabilities and resources (e.g. bandwidth, 0 delays,hardware deterministic support to the physical layer, ...)
3. hysicalTW> typoresources (total and available buffers, timers,queues, etc)
Finn & Thubert Expires September 10, 2015 [Page 13]Internet-Draft Deterministic Networking Architecture March 2015
4. Network Adjacencies (neighbors)
d. A model for the provision of a service, by end systems, or relaysystems, to forward a DetNet stream over a simple or redundantpath. The model includes:
1. A model for an abstract relaying operation of either Routingor forwarding packets of a DetNet stream to a next-hop relaysystem, across Layer boundaries.
2. A model of next-hop(s) information for replicating thepackets of a DetNet stream, typically at or near the talker,merging and/or re-replicating those packets at other pointsin the network, and finally eliminating the duplicates,typically at or near the listener(s), in order to providehigh availability (Section 3.3).
e. The protocol stack model for an end system and/or a relay systemshould support the above elements in a manner that maximizes theapplicability of existing standards and protocols to the DetNetproblem, allows for the creation of new protocols where needed,thus making DetNet an add-on feature to existing networks, ratherthan a new way to do networking. In particular this protocolstack supports networks in which the path from talker tolistener(s) includes bridges and/or routers in any order(Section 4.10).
f. A variety of models for the provisioning of DetNet streams can beenvisioned, including orchestration by a central controller or bya federation of controllers, provisioning by relay systems andend systems sharing peer-to-peer protocols, by off-lineconfiguration, or by a combination of these methods. Theprovisioning models are similar to existing Layer-2 and Layer-3models, in order to minimize the amount of innovation required inthis area (Section 4.12).
4.5. DetNet streams
4.5.1. Talker guarantees
DetNet streams can by synchronous or asynchronous. The transmissionof packets in synchronous DetNet streams uses time synchronizationamong the end and relay systems to control the flow of packets.Asynchronous DetNet streams are characterized by:
o A maximum packet size;
o An observation interval; and
Finn & Thubert Expires September 10, 2015 [Page 14]Internet-Draft Deterministic Networking Architecture March 2015
o A maximum number of transmissions during that observationinterval.
These parameters, together with knowledge of the protocol stack used(and thus the size of the various headers added to a packet), limitthe number of bit times per observation interval that the DetNetstream can occupy the physical medium.
The talker promises that these limits will not be exceeded. If thetalker transmits less data than this limit allows, the unusedresources such as link bandwidth can be made available by the systemto non-DetNet packets. However, making those resources available toDetNet packets in other streams would serve no purpose. Those otherstreams have their own dedicated resources, on the assumption thatall DetNet streams can use all of their resources over a long periodof time.
Note that there is no provision in DetNet for throttling streams; theassumption is that a DetNet stream, to be useful, must be deliveredin its entirety. That is, while any useful application is written toexpect a certain number of lost packets, the real-time applicationsof interest to DetNet demand that the loss of data due to the networkis extraordinarily infrequent.
Although DetNet strives to minimize the changes required of anapplication to allow it to shift from a special-purpose digitalnetwork to an Internet Protocol network, one fundamental shift in thebehavior of network applications that is impossible to avoid--thereservation of resources before the application starts. In the firstplace, a network cannot deliver finite latency and practically zeropacket loss to an arbitrarily high offered load. Secondly, achievingpractically zero packet loss for unthrottled (though bandwidthlimited) streams means that bridges and routers have to dedicatebuffer resources to specific streams or to classes of streams. Therequirements of each reservation have to be translated into theparameters that control each system's queuing, shaping, andscheduling functions and delivered to the hosts, bridges, androuters.
4.5.2. Incomplete Networks
The presence in the network of relay systems that are not fullycapable of offering DetNet services complicates the ability of therelay systems and/or controller to allocate resources, as extrabuffering, and thus extra latency, must be allocated at each pointthat is downstream from the non-DetNet relay system for some DetNetstream.
Finn & Thubert Expires September 10, 2015 [Page 15]Internet-Draft Deterministic Networking Architecture March 2015
4.6. Data Flow Model through Systems
4.7. Queuing, Shaping, Scheduling, and Preemption
For this reason, the IEEE 802.1 Time-Sensitive Networking Task Grouphas defined a set of queuing, shaping, and scheduling algorithms thatenable each bridge or router to compute the exact number of buffersto be allocated for each stream or class of streams.
4.8. Coexistence with normal traffic
A DetNet network supports the dedication of at least 75% of thenetwork bandwidth to DetNet streams. But, no matter how much isdedicated for DetNet streams, It is zTW> typogoal of DetNet to not interfereexcessively with existing QoS schemes. It is also important thatnon-DetNet traffic not disrupt the DetNet stream, of course (seeSection 4.9 and Section 6). For these reasons:
o Bandwidth (transmission opportunities) not utilized by a DetNetstream are available to non-DetNet packets (though not to otherDetNet streams).
o DetNet streams can be shaped, in order to ensure that the highest-priority non-DetNet packet also is ensured a maximum latency.
o When transmission opportunities for DetNet streams are scheduledin detail, then the algorithm constructing the schedule shouldleave sufficient opportunities for non-DetNet packets to satisfythe needs of the uses of the network.
Ideally, the net effect of the presence of DetNet streams in anetwork on the non-DetNet packets is primarily a reductoinTW> typoin theavailable bandwidth.
4.9. Fault Mitigation
One key to building robust real-time systems is to reduce theinfinite variety of possible failures to a number that can beanalyzed with reasonable confidence. DetNet aids in the process byproviding filters and policers to detect DetNet packets received onthe wrong interface, or at the wrong time, or in too great a volume,and to then take actions such as disabling the offending packet,shutting down the offending DetNet stream, or shutting down theoffending interface.
It is also essential that filters and service remarkingTW> please define "service remarking"be employedto prevent non-DetNet packets from impinging on the resourcesallocated to DetNet packets.
Finn & Thubert Expires September 10, 2015 [Page 16]Internet-Draft Deterministic Networking Architecture March 2015
There exist techniques, at present and/or in various stages ofstandardization, that can perform these fault mitigation tasks thatdeliver a high probability that misbehaving systemdTW> typowill have zeroimpact on well-behaved DetNet streams, except of course, for thereceiving interface(s) immediately downstream of the misbehavingdevice.
4.10. Protocol Stack Model
This section will be further developed. See [IEEE802.1CB], Annex C,for a description of the protocol stack. This is very much a work inprogress, not a standard. See also [IEEE802.1Qcc].
4.11. Advertising resources, capabilities and adjacencies
4.12. Provisioning model
4.12.1. Centralized Path Computation and Installation
A centralized routing model, such as provided with a PCE (RFC 4655[RFC4655]), enables global and per-stream optimizations. The modelis attractive but a number of issues are left to be solved. Inparticular:
o whether and how the path computation can be installed by 1) an enddevice or 2) a Network Management entity,
o and how the path is set up, either by installing state at each hopwith a direct interaction between the forwarding device and thePCE, or along a path by injecting a source-routed request at oneend of the path.
4.12.2. Distributed Path Setup
Whether a distributed alternative without a PCE can be valuableshould be studied as well. Such an alternative could for instanceinherit from the Resource ReSerVation Protocol [RFC5127] (RSVP)flows.
In a Layer-2 only environment, or as part of a layered approach to amixed environment, IEEE 802.1 also has work, either completed or inprogress. [IEEE802.1Q-2011] Clause 35 describes SRP, a peer-to-peerprotocol for Layer-2 roughly analogous to RSVP. Almost complete is[IEEE802.1Qca], which defines how ISIS can provide multiple disjointpaths or distribution trees. Also in progress is [IEEE802.1Qcc],which expands the capabilities of SRP.
Finn & Thubert Expires September 10, 2015 [Page 17]Internet-Draft Deterministic Networking Architecture March 2015
5. Related IETF work
5.1. Deterministic PHB
[I-D.svshah-tsvwg-deterministic-forwarding] defines a DifferentiatedServices Per-Hop-Behavior (PHB) Group called Deterministic Forwarding(DF). The document describes the purpose and semantics of this PHB.It also describes creation and forwarding treatment of the serviceclass. The document also describes how the code-point can be mappedinto one of the aggregated Diffserv service classes [RFC5127].
5.2. 6TiSCH
Industrial process control already leverages deterministic wirelessLow power and Lossy Networks (LLNs) to interconnect criticalresource-constrained devices and form wireless mesh networks, withstandards such as [ISA100.11a] and [WirelessHART].
These standards rely on variations of the [IEEE802154e] timeSlottedChannel Hopping (TSCH) [I-D.ietf-6tisch-tsch] Medium Access Control(MAC), and a form of centralized Path Computation Element (PCE), todeliver deterministic capabilities.
The TSCH MAC benefits include high reliability against interference,low power consumption on characterized streams, and TrafficEngineering capabilities. Typical applications are open and closedcontrol loops, as well as supervisory control streams and management.
The 6TiSCH Working Group focuses only on the TSCH mode of the IEEE802.15.4e standard. The WG currently defines a framework formanaging the TSCH schedule. Future work will standardizedeterministic operations over so-called tracks as described in[I-D.ietf-6tisch-architecture]. Tracks are an instance of adeterministic path, and the DetNet work is a prerequisite to specifytrack operations and serve process control applications.
[RFC5673] and [I-D.ietf-roll-rpl-industrial-applicability] section2.1.3. and next discusses application-layer paradigms, such asSource-sink (SS) that is a Multipeer to Multipeer (MP2MP) model thatis primarily used for alarms and alerts, Publish-subscribe (PS, orpub/sub) that is typically used for sensor data, as well as Peer-to-peer (P2P) and Peer-to-multipeer (P2MP) communications. Additionalconsiderations on Duocast and its N-cast generalization are alsoprovided for improved reliability.
Finn & Thubert Expires September 10, 2015 [Page 18]Internet-Draft Deterministic Networking Architecture March 2015
6. Security Considerations
Security in the context of Deterministic Networking has an addeddimension; the time of delivery of a packet can be just as importantas the contents of the packet, itself. A man-in-the-middle attack,for example, can impose, and then systematically adjust, additionaldelays into a link, and thus disrupt or subvert a real-timeapplication without having to crack any encryption methods employed.See [RFC7384] for an exploration of this issue in a related context.
Furthermore, in a control system where millions of dollars ofequipment, or even human lives, can be lost if the DetNet QoS is notdelivered, one must consider not only simple equipment failures,where the box or wire instantly becomes perfectly silent, but bizarreerrors such as can be cousedTW> typoby software failures. Because there isessentiallTW> typono limit to the kinds of failures that can occur,protecting against realistic equipment failures is indistinguishable,in most cases, from protecting against malicious behavior, whetheraccidental or intentional. See also Section 4.9.
Security must cover:
o the protection of the signaling protocol
o the authentication and authorization of the controlling systems
o the identification and shaping of the streams
7. IANA Considerations
This document does not require an action from IANA.
8. Acknowledgements
The authors wish to thank Jouni Korhonen, Erik Nordmark, GeorgeSwallow, Rudy Klecka, Anca Zamfir, David Black, Thomas Watteyne,Shitanshu Shah, Craig Gunther, Rodney Cummings, Wilfried Steiner,Marcel Kiessling, Karl Weber, Ethan Grossman and Pat Thaler, fortheir various contribution with this work.
9. Informative References
[AVnu] http://www.avnu.org/"> http://www.avnu.org/, "The AVnu Alliance tests andcertifies devices for interoperability, providing a simpleand reliable networking solution for AV networkimplementation based on the Audio Video Bridging (AVB)standards.", .
Finn & Thubert Expires September 10, 2015 [Page 19]Internet-Draft Deterministic Networking Architecture March 2015
[CCAMP] IETF, "Common Control and Measurement Plane",<https://datatracker.ietf.org/doc/charter-ietf-ccamp/">https://datatracker.ietf.org/doc/charter-ietf-ccamp/>.
[HART] http://www.hartcomm.org/"> www.hartcomm.org, "Highway Addressable Remote Transducer,a group of specifications for industrial process andcontrol devices administered by the HART Foundation", .
[HSR-PRP] IEC, "High availability seamless redundancy (HSR) is afurther development of the PRP approach, although HSRfunctions primarily as a protocol for creating mediaredundancy while PRP, as described in the previoussection, creates network redundancy. PRP and HSR are bothdescribed in the IEC 62439 3 standard.",artnum/046615!opendocument>.
[I-D.finn-detnet-problem-statement]Finn, N. and P. Thubert, "Deterministic Networking ProblemStatement", draft-finn-detnet-problem-statement-01 (workin progress), October 2014.
[I-D.ietf-6tisch-architecture]Thubert, P., Watteyne, T., Struik, R., and M. Richardson,"An Architecture for IPv6 over the TSCH mode of IEEE802.15.4e", draft-ietf-6tisch-architecture-05 (work inprogress), January 2015.
[I-D.ietf-6tisch-tsch]Watteyne, T., Palattella, M., and L. Grieco, "UsingIEEE802.15.4e TSCH in an IoT context: Overview, ProblemStatement and Goals", draft-ietf-6tisch-tsch-05 (work inprogress), January 2015.
[I-D.ietf-roll-rpl-industrial-applicability]Phinney, T., Thubert, P., and R. Assimiti, "RPLapplicability in industrial networks", draft-ietf-roll-rpl-industrial-applicability-02 (work in progress),October 2013.
[I-D.svshah-tsvwg-deterministic-forwarding]Shah, S. and P. Thubert, "Deterministic Forwarding PHB",draft-svshah-tsvwg-deterministic-forwarding-03 (work inprogress), March 2015.
[IEEE802.1AS-2011]IEEE, "Timing and Synchronizations (IEEE 802.1AS-2011)",download/802.1AS-2011.pdf>.
Finn & Thubert Expires September 10, 2015 [Page 20]Internet-Draft Deterministic Networking Architecture March 2015
[IEEE802.1BA-2011]IEEE, "AVB Systems (IEEE 802.1BA-2011)", 2011,download/802.1BA-2011.pdf>.
[IEEE802.1CB]IEEE, "Seamless Redundancy (IEEE Draft P802.1CB)", 2015,<http://p8021:go_wildcats@www.ieee802.org/1/files/private/">http://p8021:go_wildcats@www.ieee802.org/1/files/private/cb-drafts/>.
[IEEE802.1Q-2011]IEEE, "MAC Bridges and VLANs (IEEE 802.1Q-2011", 2011,download/802.1Q-2011.pdf>.
[IEEE802.1Qat-2010]IEEE, "Stream Reservation Protocol (IEEE 802.1Qat-2010)",download/802.1Qat-2010.pdf>.
[IEEE802.1Qav]IEEE, "Forwarding and Queuing (IEEE 802.1Qav-2009)", 2009,download/802.1Qav-2009.pdf>.
[IEEE802.1Qca]IEEE, "Path Control and Reservation", 2015,<http://p8021:go_wildcats@www.ieee802.org/1/files/private/">http://p8021:go_wildcats@www.ieee802.org/1/files/private/ca-drafts/>.
[IEEE802.1Qcc]IEEE, "Stream Reservation Protocol (SRP) Enhancements andPerformance Improvements", 2015,<http://p8021:go_wildcats@www.ieee802.org/1/files/private/">http://p8021:go_wildcats@www.ieee802.org/1/files/private/cc-drafts/>.
[IEEE802.1TSNTG]IEEE Standards Association, "IEEE 802.1 Time-SensitiveNetworks Task Group", 2013,
[IEEE802154]IEEE standard for Information Technology, "IEEE std.802.15.4, Part. 15.4: Wireless Medium Access Control (MAC)and Physical Layer (PHY) Specifications for Low-RateWireless Personal Area Networks", June 2011.
Finn & Thubert Expires September 10, 2015 [Page 21]Internet-Draft Deterministic Networking Architecture March 2015
[IEEE802154e]IEEE standard for Information Technology, "IEEE std.802.15.4e, Part. 15.4: Low-Rate Wireless Personal AreaNetworks (LR-WPANs) Amendment 1: MAC sublayer", April2012.
[ISA100.11a]ISA/IEC, "ISA100.11a, Wireless Systems for Automation,also IEC 62734", 2011, < http://www.isa100wci.org/en-"> http://www.isa100wci.org/en-US/Documents/PDF/3405-ISA100-WirelessSystems-Future-broch-WEB-ETSI.aspx>.
[ODVA] http://www.odva.org/"> http://www.odva.org/, "The organization that supportsnetwork technologies built on the Common IndustrialProtocol (CIP) including EtherNet/IP.", .
[PCE] IETF, "Path Computation Element",<https://datatracker.ietf.org/doc/charter-ietf-pce/">https://datatracker.ietf.org/doc/charter-ietf-pce/>.
[Profinet]http://us.profinet.com/technology/profinet/"> http://us.profinet.com/technology/profinet/, "PROFINET isa standard for industrial networking in automation.",
[RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S.Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1Functional Specification", RFC 2205, September 1997.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,and G. Swallow, "RSVP-TE: Extensions to RSVP for LSPTunnels", RFC 3209, December 2001.
[RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path ComputationElement (PCE)-Based Architecture", RFC 4655, August 2006.
[RFC5127] Chan, K., Babiarz, J., and F. Baker, "Aggregation ofDiffserv Service Classes", RFC 5127, February 2008.
[RFC5673] Pister, K., Thubert, P., Dwars, S., and T. Phinney,"Industrial Routing Requirements in Low-Power and LossyNetworks", RFC 5673, October 2009.
[RFC7384] Mizrahi, T., "Security Requirements of Time Protocols inPacket Switched Networks", RFC 7384, October 2014.
Finn & Thubert Expires September 10, 2015 [Page 22]Internet-Draft Deterministic Networking Architecture March 2015
[RFC7426] Haleplidis, E., Pentikousis, K., Denazis, S., Hadi Salim,J., Meyer, D., and O. Koufopavlou, "Software-DefinedNetworking (SDN): Layers and Architecture Terminology",RFC 7426, January 2015.
[TEAS] IETF, "Traffic Engineering Architecture and Signaling",<https://datatracker.ietf.org/doc/charter-ietf-teas/">https://datatracker.ietf.org/doc/charter-ietf-teas/>.
[WirelessHART]http://www.hartcomm.org/"> www.hartcomm.org, "Industrial Communication Networks -Wireless Communication Network and Communication Profiles- WirelessHART - IEC 62591", 2010.
Authors' Addresses
Norm FinnCisco Systems170 W Tasman Dr.San Jose, California 95134USA
Phone: +1 408 526 4495Email: nfinn@cisco.com
Pascal ThubertCisco SystemsVillage d'Entreprises Green Side400, Avenue de RoumanilleBatiment T3Biot - Sophia Antipolis 06410FRANCE
Phone: +33 4 97 23 26 34Email: pthubert@cisco.com
Finn & Thubert Expires September 10, 2015 [Page 23]
_______________________________________________
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch" target="_blank" rel="nofollow">https://www.ietf.org/mailman/listinfo/6tisch
_______________________________________________ 6tisch mailing list 6tisch@ietf.org https://www.ietf.org/mailman/listinfo/6tisch" rel="nofollow">https://www.ietf.org/mailman/listinfo/6tisch
- [6tisch] comments on draft-finn-detnet-architectu… Thomas Watteyne
- Re: [6tisch] [Detnet] comments on draft-finn-detn… Pascal Thubert (pthubert)
- Re: [6tisch] [Detnet] comments on draft-finn-detn… Pascal Thubert (pthubert)
- Re: [6tisch] [Detnet] comments on draft-finn-detn… Norman Finn (nfinn)
- Re: [6tisch] [Detnet] comments on draft-finn-detn… Patrick Wetterwald (pwetterw)
- Re: [6tisch] [Detnet] comments on draft-finn-detn… Qin Wang
- Re: [6tisch] [Detnet] comments on draft-finn-detn… Tom Phinney
- Re: [6tisch] [Detnet] comments on draft-finn-detn… Christian Boiger
- Re: [6tisch] [Detnet] comments on draft-finn-detn… John Grant
- Re: [6tisch] [Detnet] comments on draft-finn-detn… Patrick Wetterwald (pwetterw)
- Re: [6tisch] [Detnet] comments on draft-finn-detn… Norman Finn (nfinn)
- Re: [6tisch] [Detnet] comments on draft-finn-detn… Norman Finn (nfinn)
- Re: [6tisch] [Detnet] comments on draft-finn-detn… Rodney Cummings
- Re: [6tisch] [Detnet] comments on draft-finn-detn… Rodney Cummings
- Re: [6tisch] [Detnet] comments on draft-finn-detn… anand