From nobody Mon Mar 2 00:04:18 2015 Return-Path: X-Original-To: detnet@ietfa.amsl.com Delivered-To: detnet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8E461A1F20; Mon, 2 Mar 2015 00:04:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 dNzKQ2nrxRSm; Mon, 2 Mar 2015 00:04:14 -0800 (PST) Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7B091A1EF4; Mon, 2 Mar 2015 00:04:13 -0800 (PST) Received: by widem10 with SMTP id em10so12694404wid.5; Mon, 02 Mar 2015 00:04:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=rdkS1yffT/2mHTw8w1Tnp+78mFwqqKnRUAb+ASX4llE=; b=ri7uy2JVVzgPAzKPhw7qLQRIEZlnuJxyk0cunuYXOJ4outvff16nSFS19AqEZKLyb8 4QOLYe81tH/lFDwBHcVsP3yBZDm9GCdYGMcYvYB/+eREqspC97T6kAnoOriysljz2LUl 9EAbcTnu6DoktFJgl2iqlXUoW0P+4AsvrstQ6x57hRjCN9k6s8NDZBTA7dIIH7/FDtSg RTFIRvIu/j9caKZVknzxRMFUjnXhxtC6/u5jdbUTyv1aHz9EDTy2uEUQwr+1clsa6N1f GJsD7Q5P/rNwPqBopkVw1tabB83JlWVJa/0nlyW9DyGAQLGU9AWlci9NjY2zBXJubT2Z ghfQ== X-Received: by 10.194.156.202 with SMTP id wg10mr53292410wjb.70.1425283452535; Mon, 02 Mar 2015 00:04:12 -0800 (PST) MIME-Version: 1.0 Sender: twatteyne@gmail.com Received: by 10.194.82.39 with HTTP; Mon, 2 Mar 2015 00:03:52 -0800 (PST) In-Reply-To: References: From: Thomas Watteyne Date: Mon, 2 Mar 2015 09:03:52 +0100 X-Google-Sender-Auth: 2b4tyBeXquMF26sWrGAny1rG8LQ Message-ID: To: "6tisch@ietf.org" <6tisch@ietf.org>, "detnet@ietf.org" Content-Type: multipart/alternative; boundary=089e0122ebd2e488c9051049a901 Archived-At: Cc: "Adrian Farrel \(adrian@olddog.co.uk\)" , "Pascal Thubert \(pthubert\)" , "Wang, Chonggang" Subject: Re: [Detnet] IETF92- Request for 6TiSCH WG Agenda items X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussions on Deterministic Networking, characterized by 1\) resource reservation; 2\) 0 congestion loss and guaranteed latency; 3\) over L2-only and mixed L2 and L3 networks; and 5\) 1+1 replication/deletion." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2015 08:04:15 -0000 --089e0122ebd2e488c9051049a901 Content-Type: text/plain; charset=UTF-8 All, Final agenda for IETF92 at https://datatracker.ietf.org/meeting/92/agenda.html. The 6TiSCH sessions remain the same as in the draft agenda. Please send requests for agenda items per e-mail below. Thomas On Mon, Feb 23, 2015 at 10:54 AM, Pascal Thubert (pthubert) < pthubert@cisco.com> wrote: > Dear All: > > For the next IETF in Dallas, we are going to have 2 6TiSCH sessions, one 90 > minutes for unchartered work (including DetNet) and one 150 minutes for > chartered work. > Our goal is to split the sessions as follows: > > Day Time Room Topic > Monday Afternoon Session II 1520-1650 CDT Continental DetNet, IoT > PCE, Dynamic Scheduling, re-chartering > Thursday Morning Session I 0900-1130 CDT Continental WG Docs, > 6top, ETSI Plugtest, Security, more re-chartering > > On Monday, we'd wish to see discussions on: > - DetNet: Gap analysis - need for IETF work, problem statement and > architecture, requirement drafts > - IoT PCE: Gap analysis vs. 6TiSCH needs, Barcelona workshop highlights, > 6TiSCH requirements for PCE and TEAS. > - Dynamic Scheduling: OTF draft status, local vs. distributed > optimizations, > chunk appropriation and fairness. > - Rechartering: what of the above should be suggested as charter items. > Call > for intent to actually produce related work. > > On Thursday: > - Last calls on TSCH and architecture drafts. > - Minimal draft publication > - Status on 6top related drafts, chartered and non-chartered > - ETSI plugtest coverage. What's basic support and what's stretched > - Security: Status of join process work. Suggestions for chartered work. > Positioning vs. SEC area WGs. > - More rechartering: summary of the Monday session. Same questions > including > the items above. > > We are now calling for the agenda items for both WG sessions. > Please send your requests to 6tisch-chairs@tools.ietf.org and Chonggang > Chonggang.Wang@InterDigital.com, and include the following information: > . Name and link to your draft, paper, or web page. > . A brief description of your presentation topic > . Requested time (5 to 20 minutes) > . Session (Monday vs. Thursday) > > We are going to evaluate the requests based on WG items, charters, WG > interests and issues that require face-to-face resolution and allocate time > as we see fit. > > Thanks for all! > > Thomas and Pascal > > _______________________________________________ > detnet mailing list > detnet@ietf.org > https://www.ietf.org/mailman/listinfo/detnet > > --089e0122ebd2e488c9051049a901 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
All,

Final agenda for IETF92 at=C2=A0https://datatracker.ietf.org/meeting/92/agenda.html. The 6TiSCH se= ssions remain the same as in the draft agenda.

Ple= ase send requests for agenda items per e-mail below.

Thomas

On Mon, Feb 23, 2015 at 10:54 AM, Pascal Thubert (pthubert) <pthubert@c= isco.com> wrote:
Dear All= :

For the next IETF in Dallas, we are going to have 2 6TiSCH sessions, one 90=
minutes for unchartered work (including DetNet) and one 150 minutes for
chartered work.
Our goal is to split the sessions as follows:

Day=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Time=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 Room=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Topic
Monday Afternoon Session II=C2=A0 =C2=A0 =C2=A01520-1650 CDT=C2=A0 =C2=A0Co= ntinental=C2=A0 =C2=A0 =C2=A0DetNet, IoT
PCE, Dynamic Scheduling, re-chartering
Thursday Morning Session I=C2=A0 =C2=A0 =C2=A0 0900-1130 CDT=C2=A0 =C2=A0Co= ntinental=C2=A0 =C2=A0 =C2=A0WG Docs,
6top, ETSI Plugtest, Security, more re-chartering

On Monday, we'd wish to see discussions on:
- DetNet: Gap analysis - need for IETF work, problem statement and
architecture, requirement drafts
- IoT PCE: Gap analysis vs. 6TiSCH needs, Barcelona workshop highlights, 6TiSCH requirements for PCE and TEAS.
- Dynamic Scheduling: OTF draft status, local vs. distributed optimizations= ,
chunk appropriation and fairness.
- Rechartering: what of the above should be suggested as charter items. Cal= l
for intent to actually produce related work.

On Thursday:
- Last calls on TSCH and architecture drafts.
- Minimal draft publication
- Status on 6top related drafts, chartered and non-chartered
- ETSI plugtest coverage. What's basic support and what's stretched=
- Security: Status of join process work. Suggestions for chartered work. Positioning vs. SEC area WGs.
- More rechartering: summary of the Monday session. Same questions includin= g
the items above.

We are now calling for the agenda items for both WG sessions.
Please send your requests to 6tisch-chairs@tools.ietf.org and Chonggang
Chonggang.Wang@InterDigital.com, and include the following information:
.=C2=A0 =C2=A0 =C2=A0 =C2=A0Name and link to your draft, paper, or web page= .
.=C2=A0 =C2=A0 =C2=A0 =C2=A0A brief description of=C2=A0 your presentation = topic
.=C2=A0 =C2=A0 =C2=A0 =C2=A0Requested time (5 to 20 minutes)
.=C2=A0 =C2=A0 =C2=A0 =C2=A0Session (Monday vs. Thursday)

We are going to evaluate the requests based on WG items, charters, WG
interests and issues that require face-to-face resolution and allocate time=
as we see fit.

Thanks for all!

Thomas and Pascal

_______________________________________________
detnet mailing list
detnet@ietf.org = https://www.ietf.org/mailman/listinfo/detnet


--089e0122ebd2e488c9051049a901-- From nobody Mon Mar 2 05:52:39 2015 Return-Path: X-Original-To: detnet@ietfa.amsl.com Delivered-To: detnet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E502E1A8763; Mon, 2 Mar 2015 05:52:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 SSJS0AQuF6ea; Mon, 2 Mar 2015 05:52:33 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4FF471A8770; Mon, 2 Mar 2015 05:52:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10623; q=dns/txt; s=iport; t=1425304352; x=1426513952; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=/5fM03OkRuNYKpfiPylxRSaRVA7fAJxd4qtIWQtX/fA=; b=AkDR0V0zc12QEvmyo0rE8L/xRSm2Bdt4l0lv29J3f+uNsocclCiVITzk 3uycwF74YNTyNf+2zUWAHs6ad1dhQ42g8kIkHGVfnHpkRf4kI/iYAGWQw EUhFA01eT1iTmysTwHG87R2620nm4k6rQOqTcDV/0ZflO2laZuslWoxQy A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CKBgChavRU/4MNJK1aDoIxQ1Jevw+CJgEJhSdJAoEgTQEBAQEBAXyEDwEBAQQBAQEaUQsQAgEIEQECAQIoBycLFAMGCAIEAQ0FiC8N1UwBAQEBAQEBAQEBAQEBAQEBAQEBAQETBIsShF0NBAcChCkFjXuBfYNghWeBGoMghl2FBYM+I4MxPW8BgUN/AQEB X-IronPort-AV: E=Sophos;i="5.09,675,1418083200"; d="scan'208,217";a="397105070" Received: from alln-core-1.cisco.com ([173.36.13.131]) by rcdn-iport-9.cisco.com with ESMTP; 02 Mar 2015 13:52:31 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id t22DqV7k020199 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 2 Mar 2015 13:52:31 GMT Received: from xmb-rcd-x03.cisco.com ([169.254.7.147]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.03.0195.001; Mon, 2 Mar 2015 07:52:31 -0600 From: "Patrick Wetterwald (pwetterw)" To: Thomas Watteyne , "6tisch@ietf.org" <6tisch@ietf.org>, "detnet@ietf.org" Thread-Topic: [Detnet] IETF92- Request for 6TiSCH WG Agenda items Thread-Index: AQHQVPAgymq8z8TQcEe/8GM0NR0w+A== Date: Mon, 2 Mar 2015 13:52:30 +0000 Message-ID: References: In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.8.150116 x-originating-ip: [10.49.80.52] Content-Type: multipart/alternative; boundary="_000_D11A287A507D0pwetterwciscocom_" MIME-Version: 1.0 Archived-At: Cc: "Adrian Farrel \(adrian@olddog.co.uk\)" , "Pascal Thubert \(pthubert\)" , "Wang, Chonggang" Subject: Re: [Detnet] IETF92- Request for 6TiSCH WG Agenda items X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussions on Deterministic Networking, characterized by 1\) resource reservation; 2\) 0 congestion loss and guaranteed latency; 3\) over L2-only and mixed L2 and L3 networks; and 5\) 1+1 replication/deletion." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2015 13:52:36 -0000 --_000_D11A287A507D0pwetterwciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Pascal, Thomas, Chonggang, I would like to present the Utility=92s requirement draft for DetNet: https://tools.ietf.org/html/draft-wetterwald-detnet-utilities-reqs-01 10 mn should be sufficient. I will cover use cases, topologies and specific= network requirements on behalf of the utilities and regarding Deterministi= c Networking. I understand that it will on Monday. Many thanks, Patrick From: Thomas Watteyne > Date: Monday 2 March 2015 09:03 To: "6tisch@ietf.org" <6tisch@ietf.org>, "detnet@ietf.org" > Cc: "Adrian Farrel (adrian@olddog.co.uk)" >, Pascal THUBERT >, "Wang, Chonggang" > Subject: Re: [Detnet] IETF92- Request for 6TiSCH WG Agenda items All, Final agenda for IETF92 at https://datatracker.ietf.org/meeting/92/agenda.h= tml. The 6TiSCH sessions remain the same as in the draft agenda. Please send requests for agenda items per e-mail below. Thomas On Mon, Feb 23, 2015 at 10:54 AM, Pascal Thubert (pthubert) > wrote: Dear All: For the next IETF in Dallas, we are going to have 2 6TiSCH sessions, one 90 minutes for unchartered work (including DetNet) and one 150 minutes for chartered work. Our goal is to split the sessions as follows: Day Time Room Topic Monday Afternoon Session II 1520-1650 CDT Continental DetNet, IoT PCE, Dynamic Scheduling, re-chartering Thursday Morning Session I 0900-1130 CDT Continental WG Docs, 6top, ETSI Plugtest, Security, more re-chartering On Monday, we'd wish to see discussions on: - DetNet: Gap analysis - need for IETF work, problem statement and architecture, requirement drafts - IoT PCE: Gap analysis vs. 6TiSCH needs, Barcelona workshop highlights, 6TiSCH requirements for PCE and TEAS. - Dynamic Scheduling: OTF draft status, local vs. distributed optimizations= , chunk appropriation and fairness. - Rechartering: what of the above should be suggested as charter items. Cal= l for intent to actually produce related work. On Thursday: - Last calls on TSCH and architecture drafts. - Minimal draft publication - Status on 6top related drafts, chartered and non-chartered - ETSI plugtest coverage. What's basic support and what's stretched - Security: Status of join process work. Suggestions for chartered work. Positioning vs. SEC area WGs. - More rechartering: summary of the Monday session. Same questions includin= g the items above. We are now calling for the agenda items for both WG sessions. Please send your requests to 6tisch-chairs@tools.ietf.org and Chonggang Chonggang.Wang@InterDigital.com, an= d include the following information: . Name and link to your draft, paper, or web page. . A brief description of your presentation topic . Requested time (5 to 20 minutes) . Session (Monday vs. Thursday) We are going to evaluate the requests based on WG items, charters, WG interests and issues that require face-to-face resolution and allocate time as we see fit. Thanks for all! Thomas and Pascal _______________________________________________ detnet mailing list detnet@ietf.org https://www.ietf.org/mailman/listinfo/detnet --_000_D11A287A507D0pwetterwciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi Pascal, Thomas, Chonggang,

I would like to present the Utility=92s requirement draft for DetNet:<= /div>
10 mn should be sufficient. I will cover use cases, topologies and spe= cific network requirements on behalf of the utilities and regarding Determi= nistic Networking.

I understand that it will on Monday.

Many thanks,

Patrick

From: Thomas Watteyne <watteyne@eecs.berkeley.edu> Date: Monday 2 March 2015 09:03
To: "6tisch@ietf.org" <= 6tisch@ietf.org>, "detnet@ie= tf.org" <detnet@ietf.org= >
Cc: "Adrian Farrel (adrian@olddog.co.uk)" <adrian@olddog.co.uk>, Pascal THUBERT <= ;pthubert@cisco.com>, "Wang, Chonggang" <Chonggang.Wang@interdigital.com>
Subject: Re: [Detnet] IETF92- Reque= st for 6TiSCH WG Agenda items

All,

Final agenda for IETF92 at https://datatracker.ietf.org/me= eting/92/agenda.html. The 6TiSCH sessions remain the same as in the dra= ft agenda.

Please send requests for agenda items per e-mail below.

Thomas

On Mon, Feb 23, 2015 at 10:54 AM, Pascal Thubert= (pthubert) <pthubert@cisco.com> wrote:
Dear All:

For the next IETF in Dallas, we are going to have 2 6TiSCH sessions, one 90=
minutes for unchartered work (including DetNet) and one 150 minutes for
chartered work.
Our goal is to split the sessions as follows:

Day                    &n= bsp;        Time          &nbs= p; Room            Topic
Monday Afternoon Session II     1520-1650 CDT   Co= ntinental     DetNet, IoT
PCE, Dynamic Scheduling, re-chartering
Thursday Morning Session I      0900-1130 CDT   Co= ntinental     WG Docs,
6top, ETSI Plugtest, Security, more re-chartering

On Monday, we'd wish to see discussions on:
- DetNet: Gap analysis - need for IETF work, problem statement and
architecture, requirement drafts
- IoT PCE: Gap analysis vs. 6TiSCH needs, Barcelona workshop highlights, 6TiSCH requirements for PCE and TEAS.
- Dynamic Scheduling: OTF draft status, local vs. distributed optimizations= ,
chunk appropriation and fairness.
- Rechartering: what of the above should be suggested as charter items. Cal= l
for intent to actually produce related work.

On Thursday:
- Last calls on TSCH and architecture drafts.
- Minimal draft publication
- Status on 6top related drafts, chartered and non-chartered
- ETSI plugtest coverage. What's basic support and what's stretched
- Security: Status of join process work. Suggestions for chartered work. Positioning vs. SEC area WGs.
- More rechartering: summary of the Monday session. Same questions includin= g
the items above.

We are now calling for the agenda items for both WG sessions.
Please send your requests to 6tisch-chairs@tools.ietf.org and Chonggang
Chonggang.Wang@InterDigi= tal.com, and include the following information:
.       Name and link to your draft, paper, or web page= .
.       A brief description of  your presentation = topic
.       Requested time (5 to 20 minutes)
.       Session (Monday vs. Thursday)

We are going to evaluate the requests based on WG items, charters, WG
interests and issues that require face-to-face resolution and allocate time=
as we see fit.

Thanks for all!

Thomas and Pascal

_______________________________________________
detnet mailing list
detnet@ietf.org = https://www.ietf.org/mailman/listinfo/detnet


 --_000_D11A287A507D0pwetterwciscocom_-- From nobody Mon Mar 2 05:57:50 2015 Return-Path: X-Original-To: detnet@ietfa.amsl.com Delivered-To: detnet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F2311A8771; Mon, 2 Mar 2015 05:57:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 BIptX2QbSHiX; Mon, 2 Mar 2015 05:57:46 -0800 (PST) Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34E1C1A8763; Mon, 2 Mar 2015 05:57:46 -0800 (PST) Received: by widex7 with SMTP id ex7so14995008wid.0; Mon, 02 Mar 2015 05:57:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=mlph027VZEY6YX4ZjxZ6HIuNkroPq8xNIg1dpjbjetw=; b=CUPxHUvw9+U8hdFDyCAhmyujWYoT/2Q+Aw9QTE3VW9U6f9CJzy0E2H4QojN1LeSxC1 kcFmWjPUfNEe36EV6uExH8R2l3aTkn9xvHcW7GntnkOSU1jXeFUXLuvsN8JYgBS5dzRN 69pWrTd4l/d5QJ5nZY51EbtPEmRdhys7C3IvcEQvOfi6tKED4M0Py4oCeYjoeMNIwwJu mpupzcpb5zZXiJ8h8V5PmQMCnxWClWhG0167M3KKuWFVko3MODZP+LPcIay6xcf96ntK kFKA4WWbjynVZO7Qv5YdRWDgeP9/28d18oTn4ga8QB3t0O/gXtCEcIyLlEX6zER+FGaa o4aw== X-Received: by 10.180.21.174 with SMTP id w14mr36282344wie.86.1425304664752; Mon, 02 Mar 2015 05:57:44 -0800 (PST) MIME-Version: 1.0 Sender: twatteyne@gmail.com Received: by 10.194.82.39 with HTTP; Mon, 2 Mar 2015 05:57:24 -0800 (PST) In-Reply-To: References: From: Thomas Watteyne Date: Mon, 2 Mar 2015 14:57:24 +0100 X-Google-Sender-Auth: 796ZJ5NT8p9K3foXGchK-1e4XK8 Message-ID: To: "Patrick Wetterwald (pwetterw)" Content-Type: multipart/alternative; boundary=047d7b6d9ac83d467505104e9afa Archived-At: Cc: "Adrian Farrel \(adrian@olddog.co.uk\)" , "6tisch@ietf.org" <6tisch@ietf.org>, "detnet@ietf.org" , "Pascal Thubert \(pthubert\)" , "Wang, Chonggang" Subject: Re: [Detnet] IETF92- Request for 6TiSCH WG Agenda items X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussions on Deterministic Networking, characterized by 1\) resource reservation; 2\) 0 congestion loss and guaranteed latency; 3\) over L2-only and mixed L2 and L3 networks; and 5\) 1+1 replication/deletion." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2015 13:57:48 -0000 --047d7b6d9ac83d467505104e9afa Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Patrick, Thanks. We'll add it to the list and discuss a tentative agenda on the 6TiSCH interim call this Friday. This topic indeed be during the Monday session. Thomas On Mon, Mar 2, 2015 at 2:52 PM, Patrick Wetterwald (pwetterw) < pwetterw@cisco.com> wrote: > Hi Pascal, Thomas, Chonggang, > > I would like to present the Utility=E2=80=99s requirement draft for DetN= et: > https://tools.ietf.org/html/draft-wetterwald-detnet-utilities-reqs-01 > 10 mn should be sufficient. I will cover use cases, topologies and > specific network requirements on behalf of the utilities and regarding > Deterministic Networking. > > I understand that it will on Monday. > > Many thanks, > > Patrick > > From: Thomas Watteyne > Date: Monday 2 March 2015 09:03 > To: "6tisch@ietf.org" <6tisch@ietf.org>, "detnet@ietf.org" < > detnet@ietf.org> > Cc: "Adrian Farrel (adrian@olddog.co.uk)" , Pascal > THUBERT , "Wang, Chonggang" < > Chonggang.Wang@interdigital.com> > Subject: Re: [Detnet] IETF92- Request for 6TiSCH WG Agenda items > > All, > > Final agenda for IETF92 at > https://datatracker.ietf.org/meeting/92/agenda.html. The 6TiSCH sessions > remain the same as in the draft agenda. > > Please send requests for agenda items per e-mail below. > > Thomas > > On Mon, Feb 23, 2015 at 10:54 AM, Pascal Thubert (pthubert) < > pthubert@cisco.com> wrote: > >> Dear All: >> >> For the next IETF in Dallas, we are going to have 2 6TiSCH sessions, one >> 90 >> minutes for unchartered work (including DetNet) and one 150 minutes for >> chartered work. >> Our goal is to split the sessions as follows: >> >> Day Time Room Topic >> Monday Afternoon Session II 1520-1650 CDT Continental DetNet, >> IoT >> PCE, Dynamic Scheduling, re-chartering >> Thursday Morning Session I 0900-1130 CDT Continental WG Docs, >> 6top, ETSI Plugtest, Security, more re-chartering >> >> On Monday, we'd wish to see discussions on: >> - DetNet: Gap analysis - need for IETF work, problem statement and >> architecture, requirement drafts >> - IoT PCE: Gap analysis vs. 6TiSCH needs, Barcelona workshop highlights, >> 6TiSCH requirements for PCE and TEAS. >> - Dynamic Scheduling: OTF draft status, local vs. distributed >> optimizations, >> chunk appropriation and fairness. >> - Rechartering: what of the above should be suggested as charter items. >> Call >> for intent to actually produce related work. >> >> On Thursday: >> - Last calls on TSCH and architecture drafts. >> - Minimal draft publication >> - Status on 6top related drafts, chartered and non-chartered >> - ETSI plugtest coverage. What's basic support and what's stretched >> - Security: Status of join process work. Suggestions for chartered work. >> Positioning vs. SEC area WGs. >> - More rechartering: summary of the Monday session. Same questions >> including >> the items above. >> >> We are now calling for the agenda items for both WG sessions. >> Please send your requests to 6tisch-chairs@tools.ietf.org and Chonggang >> Chonggang.Wang@InterDigital.com, and include the following information: >> . Name and link to your draft, paper, or web page. >> . A brief description of your presentation topic >> . Requested time (5 to 20 minutes) >> . Session (Monday vs. Thursday) >> >> We are going to evaluate the requests based on WG items, charters, WG >> interests and issues that require face-to-face resolution and allocate >> time >> as we see fit. >> >> Thanks for all! >> >> Thomas and Pascal >> >> _______________________________________________ >> detnet mailing list >> detnet@ietf.org >> https://www.ietf.org/mailman/listinfo/detnet >> >> > --047d7b6d9ac83d467505104e9afa Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Patrick,

Thanks. We'll add it to th= e list and discuss a tentative agenda on the 6TiSCH interim call this Frida= y. This topic indeed be during the Monday session.

Thomas

On Mon, Mar 2, 2015 at 2:52 PM, Patrick Wetterwald (pwetterw) <pwette= rw@cisco.com> wrote:
Hi Pascal, Thomas, Chonggang,

I would like to present the Utility=E2=80=99s requirement draft for De= tNet:
10 mn should be sufficient. I will cover use cases, topologies and spe= cific network requirements on behalf of the utilities and regarding Determi= nistic Networking.

I understand that it will on Monday.

Many thanks,

Patrick

From: Thomas Watteyne <watteyne@eecs.berk= eley.edu>
Date: Monday 2 March 2015 09:03
To: "6tisch@ietf.org" <6tisch@ietf.org>, "detnet@ietf.org" <= ;detnet@ietf.org&g= t;
Cc: "Adrian Farrel (adrian@olddog.co.uk)&quo= t; <adrian@oldd= og.co.uk>, Pascal THUBERT <pthubert@cisco.com>, "Wang, Chonggang" <Chonggang.Wang@interdigital.com>
Subject: Re: [Detnet] IETF92- Reque= st for 6TiSCH WG Agenda items

All,

Final agenda for IETF92 at=C2=A0https://datatracker.ietf.org/me= eting/92/agenda.html. The 6TiSCH sessions remain the same as in the dra= ft agenda.

Please send requests for agenda items per e-mail below.

Thomas

On Mon, Feb 23, 2015 at 10:54 AM, Pascal Thubert= (pthubert) <pthubert@cisco.com> wrote:
Dear All:

For the next IETF in Dallas, we are going to have 2 6TiSCH sessions, one 90=
minutes for unchartered work (including DetNet) and one 150 minutes for
chartered work.
Our goal is to split the sessions as follows:

Day=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Time=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 Room=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Topic
Monday Afternoon Session II=C2=A0 =C2=A0 =C2=A01520-1650 CDT=C2=A0 =C2=A0Co= ntinental=C2=A0 =C2=A0 =C2=A0DetNet, IoT
PCE, Dynamic Scheduling, re-chartering
Thursday Morning Session I=C2=A0 =C2=A0 =C2=A0 0900-1130 CDT=C2=A0 =C2=A0Co= ntinental=C2=A0 =C2=A0 =C2=A0WG Docs,
6top, ETSI Plugtest, Security, more re-chartering

On Monday, we'd wish to see discussions on:
- DetNet: Gap analysis - need for IETF work, problem statement and
architecture, requirement drafts
- IoT PCE: Gap analysis vs. 6TiSCH needs, Barcelona workshop highlights, 6TiSCH requirements for PCE and TEAS.
- Dynamic Scheduling: OTF draft status, local vs. distributed optimizations= ,
chunk appropriation and fairness.
- Rechartering: what of the above should be suggested as charter items. Cal= l
for intent to actually produce related work.

On Thursday:
- Last calls on TSCH and architecture drafts.
- Minimal draft publication
- Status on 6top related drafts, chartered and non-chartered
- ETSI plugtest coverage. What's basic support and what's stretched=
- Security: Status of join process work. Suggestions for chartered work. Positioning vs. SEC area WGs.
- More rechartering: summary of the Monday session. Same questions includin= g
the items above.

We are now calling for the agenda items for both WG sessions.
Please send your requests to 6tisch-chairs@tools.ietf.org and Chonggang
Chongg= ang.Wang@InterDigital.com, and include the following information:
.=C2=A0 =C2=A0 =C2=A0 =C2=A0Name and link to your draft, paper, or web page= .
.=C2=A0 =C2=A0 =C2=A0 =C2=A0A brief description of=C2=A0 your presentation = topic
.=C2=A0 =C2=A0 =C2=A0 =C2=A0Requested time (5 to 20 minutes)
.=C2=A0 =C2=A0 =C2=A0 =C2=A0Session (Monday vs. Thursday)

We are going to evaluate the requests based on WG items, charters, WG
interests and issues that require face-to-face resolution and allocate time=
as we see fit.

Thanks for all!

Thomas and Pascal

_______________________________________________
detnet mailing list
detnet@ietf.org = https://www.ietf.org/mailman/listinfo/detnet

--047d7b6d9ac83d467505104e9afa-- From nobody Mon Mar 9 03:48:27 2015 Return-Path: X-Original-To: detnet@ietfa.amsl.com Delivered-To: detnet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62FBF1A87BD; Mon, 9 Mar 2015 03:48:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 EUt51dImXgRE; Mon, 9 Mar 2015 03:48:14 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8C2E1A87C5; Mon, 9 Mar 2015 03:48:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8632; q=dns/txt; s=iport; t=1425898094; x=1427107694; h=from:to:cc:subject:date:message-id:mime-version; bh=xe79+tuIxQzzJTI18hG2BGdbDDTVW5TnA/wMxvIF4L8=; b=GvQ6CL3N4UE556JrXBwirwm3Do+d4cbtSnfzQoZTMi9P4xq7HbroAxGm Y8hPSueV11ho65ZWFR1blR3CPaW0o8R4+ZeQc+KFs9f5c4AWt/Af44ovx fZqzg+fx8xVm61b42a9R9KA9psIefhhvD3kqQSYKG78qyMZCXW1rejvAK 4=; X-Files: smime.p7s : 4831 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0B4GgC7ef1U/49dJa1agwZSWgS8VoNIgjaFcAKBKE0BAQEBAQF8hBEBAgJ5EgEaECYwFw8BBAENDQaIIQ3DKgEBAQEBAQEBAQEBAQEBAQEBAQEBAReCTI0IMYMegRYFijuFVIFlgS5RhXCBGTmCb48yI4NubwGBQ38BAQE X-IronPort-AV: E=Sophos;i="5.11,367,1422921600"; d="p7s'?scan'208";a="130172859" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by alln-iport-4.cisco.com with ESMTP; 09 Mar 2015 10:48:13 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id t29AmDKB017447 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 9 Mar 2015 10:48:13 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.110]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.03.0195.001; Mon, 9 Mar 2015 05:48:12 -0500 From: "Pascal Thubert (pthubert)" To: "6tisch@ietf.org" <6tisch@ietf.org>, "detnet@ietf.org" Thread-Topic: 6TiSCH (inviting DetNet) agenda for IETF 92 Thread-Index: AdBaVlQJpaeD/yO5Q26TfxoYufysJQ== Date: Mon, 9 Mar 2015 10:48:10 +0000 Deferred-Delivery: Mon, 9 Mar 2015 10:47:00 +0000 Message-ID: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.49.80.27] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_001A_01D05A5E.B83FD0C0" MIME-Version: 1.0 Archived-At: Cc: Thomas Watteyne , "Jouni Korhonen \(jouni.korhonen@broadcom.com\)" Subject: [Detnet] 6TiSCH (inviting DetNet) agenda for IETF 92 X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussions on Deterministic Networking, characterized by 1\) resource reservation; 2\) 0 congestion loss and guaranteed latency; 3\) over L2-only and mixed L2 and L3 networks; and 5\) 1+1 replication/deletion." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2015 10:48:20 -0000 ------=_NextPart_000_001A_01D05A5E.B83FD0C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear all: We published the draft agenda on the IETF site: http://datatracker.ietf.org/meeting/agenda/=20 Compiled drafts: http://datatracker.ietf.org/meeting/92/agenda/6tisch-drafts.pdf=20 Monday ------ Distributed Scheduling OTF (Diego) [30 min] DetNet=20 draft-finn-detnet-architecture (Norm) [20 min] draft-gunther-detnet-proaudio-req (Craig) [10 min] draft-wetterwald-detnet-utilities-reqs (Patrick) [10 min] 6TiSCH reqs (Chonggang) [10 min] Wrap up for rechartering [10 min] Thursday -------- Last Call Status [40 mins] draft-ietf-6tisch-tsch(Thomas) draft-ietf-6tisch-minimal (Xavi) draft-ietf-6tisch-architecture (Pascal) draft-ietf-6tisch-terminology (Maria-Rita) Other Drafts [30 mins] draft-ietf-6tisch-6top-interface (Qin/Xavi) draft-wang-6tisch-6top (Qin/Xavi) draft-ietf-6tisch-coap (Raghuram/Pouria) Plugtest [10 mins] Security [30 mins] DT status and design goals (Michael) draft-struik-6tisch-security-architecture-elements (Ren=E9) Rechartering [40 mins] Summary of Monday's meeting Scheduling goals and deliverables Security goals and deliverables Please let us know if we need to make a change by the end of this week. Cheers, Thomas et Pascal ------=_NextPart_000_001A_01D05A5E.B83FD0C0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOLTCCBDYw ggMeoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwbzELMAkGA1UEBhMCU0UxFDASBgNVBAoTC0FkZFRy dXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBUVFAgTmV0d29yazEiMCAGA1UEAxMZ QWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0wMDA1MzAxMDQ4MzhaFw0yMDA1MzAxMDQ4Mzha MG8xCzAJBgNVBAYTAlNFMRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQGA1UECxMdQWRkVHJ1c3Qg RXh0ZXJuYWwgVFRQIE5ldHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0IEV4dGVybmFsIENBIFJvb3Qw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC39xoz5vIABC054E5b7R+8bA/Ntfojts7e mxEzl6QpTH2Tn71KvJPtAxrjj8/lbVBa1pcplFqAsEl62y6V/bjKvzc4LR4+kUGtcFbH8E8/6DKe dMrIkFTpxl8PeJ2aQDwOrGGqXhSPnoehalDc15pOrwWzpnGUnHGzUGAKxxOdOAeGAqjpqGkmGJCr TLBPI6s6T4TY386f4Wlvu9dC12tE5Met7m1BX3JacQg3s3llpFmglDf3AC8NwpJy2tA4ctsUqEXE XSp9t7TWxO6szRNEt8kr3UMAJfphuWlqWCMRt6czj1Z1WfXNKddGtworZbbTQm8Vsrh7++/pXVPV NFonAgMBAAGjgdwwgdkwHQYDVR0OBBYEFK29mHo0tCb3+sQmVO8DveAky1QaMAsGA1UdDwQEAwIB BjAPBgNVHRMBAf8EBTADAQH/MIGZBgNVHSMEgZEwgY6AFK29mHo0tCb3+sQmVO8DveAky1QaoXOk cTBvMQswCQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0 IEV4dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290 ggEBMA0GCSqGSIb3DQEBBQUAA4IBAQCwm+CFJcLWI+IPlgaSnUGYnNmEeYHZHlsUByM2ZY+w2He7 rEFsR2CDUbD5Mj3n/PYmE8eAFqW/WvyHz3h5iSGa4kwHCoY1vPLeUcTSlrfcfk7ucP0cOesMAlEU LY69FuDB30Z15ySt7PRCtIWTcBBnup0GNUoY0yt6zFFCoXpj0ea7ocUrwja+Ew3mvWN+eXunCQ1A q2rdj4rD9vaMGkIFUdRF9Z+nYiFoFSBDPJnnfL0k2KmRF3OIP1YbMTgYtHEPms3IDp6OLhvhjJiD yx8x8URMxgRzSXZgD8f4vReAay7pzEwOWpp5DyAKLtWeYyYeVZKU2IIXWnvQvMePToYEMIIErzCC A5egAwIBAgIRAOAjyxUSg1OJrWFuelRnayEwDQYJKoZIhvcNAQELBQAwbzELMAkGA1UEBhMCU0Ux FDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBUVFAgTmV0 d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0xNDEyMjIwMDAwMDBa Fw0yMDA1MzAxMDQ4MzhaMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVz dGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UE AxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwg Q0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCJsQ3aelMZTnBSHbxWpgYmt7hJ4Jbn Uavx8FoTSRWjtIwbYLx6UUKneYykIt8XYU6R1XYjChTTSgJ/th0JgG6lBD3ZursW/qGHqS5DUkMW fK8yUMimT1rpCNjPkyWce4joMGTmpPhWgP0qJBQzF5msROVpi6NGBkvCM9TpQJ8GsLGsk0C5tQiT OpwqU6MQ2z0gYTxVA47ZTnYlAiEp+qN8cXZP7uFfgen7VIDbw3s1UreE3iI9LDAtMX9ZvVI3sDNp LUPr+tal8Zd3Z1GM2e4n67ylBzh2jKSpOP/fjPUDrEm+yvdzmToPMquclToTPQ5GOld0YVC+xkA/ y+Tin6IhAgMBAAGjggEXMIIBEzAfBgNVHSMEGDAWgBStvZh6NLQm9/rEJlTvA73gJMtUGjAdBgNV HQ4EFgQUkmFrguGioKpP7GfxwqP3tIAAwewwDgYDVR0PAQH/BAQDAgGGMBIGA1UdEwEB/wQIMAYB Af8CAQAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMBEGA1UdIAQKMAgwBgYEVR0gADBE BgNVHR8EPTA7MDmgN6A1hjNodHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vQWRkVHJ1c3RFeHRlcm5h bENBUm9vdC5jcmwwNQYIKwYBBQUHAQEEKTAnMCUGCCsGAQUFBzABhhlodHRwOi8vb2NzcC51c2Vy dHJ1c3QuY29tMA0GCSqGSIb3DQEBCwUAA4IBAQAbKm6sVcE6q4jF2O3NVfOqa2ErwAkQI5kPxWZq b7H1tLV3Xg8CYQDffQX+ErOkgIAA/PsdW2pyAgpBvAW6wVjVJsLq1U2E+/6CmM9YG+MiY5xS+LsF Nqt9WKXeqztj5drVc+/s4Pt74qP/8EIjnMq2jU0+5EsYA7KoLdTYu0JLkGmFENumNzToe+ABEKWc yjrHn0+ING6KZdAairup3MrKNtH0/MJkKTWv1rGncRHSA0Oxjz6a7J4yU/R2ksqGNAe5LMrmHErY mQ3BhuKQkvtaQmojIRDpZcf11bt+6oyFIAJi6tE6ByxZxZkz8jiJ5bbpFnofeRT2ShAaJvp8ivub MIIFPDCCBCSgAwIBAgIRAImdrrrSrE1TMdXIyvE0qYEwDQYJKoZIhvcNAQELBQAwgZsxCzAJBgNV BAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAY BgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQg QXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xNTAyMDMwMDAwMDBaFw0xNjAy MDMyMzU5NTlaMCMxITAfBgkqhkiG9w0BCQEWEnB0aHViZXJ0QGNpc2NvLmNvbTCCASIwDQYJKoZI hvcNAQEBBQADggEPADCCAQoCggEBALTqoFHH36vHzOLhXp5Wv28HBpYWouQolX/OzHVrZbIEblHp NAxFdrnNSWULDP5gT8hp/t4P0XO3YEnaQxpPUu0wWFlLrDC690s0y3T0hATowmfycNcLX+hddBDL 8ChyZdJAVhxl0vnxORmcciJmXmWOJ+4lzEqaDbm5lZUHgi3kc0t9/IFOOJ6yq1kjttHu1MFPZZUc lUnlpXmD+2/GzxeCHlQgLvw232No6lrAS34PQxbu7rnfw25Spd3CFP7RymWZnNL26rIvt3J4rpv8 xy0EedfU3AUo5scNpr7Mb1npOgVU7N+K07atmjh71wpvfnpvwIxPA+OOHcXwOS5JsosCAwEAAaOC AfAwggHsMB8GA1UdIwQYMBaAFJJha4LhoqCqT+xn8cKj97SAAMHsMB0GA1UdDgQWBBS2xFsxMSdl ViqpYN1OZcdW6Bg4OTAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggr BgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYB BAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMF0G A1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET1NIQTI1NkNsaWVu dEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgZAGCCsGAQUFBwEBBIGDMIGAMFgG CCsGAQUFBzAChkxodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9TSEEyNTZDbGllbnRBdXRo ZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5j b21vZG9jYS5jb20wHQYDVR0RBBYwFIEScHRodWJlcnRAY2lzY28uY29tMA0GCSqGSIb3DQEBCwUA A4IBAQABMkoJZJ5HHnG3Sl0jOpl8Emhb5fjpyW2eK26Zy8e62uqUL7ExSBChD97N1lCYUFY4TqIR zCmaObFC+fDgG3IDQ7ZOJDVu6ZK8TAGiBF6sSYcg5rSfIKPxJUQvTciSrTE+XHEVONmU6xQrMIYY 4/T4iho50oQmNpTSNmGc19ZZ9mQtbRGsjdwILm5NvIyI3X088GidfVJqifQ9dRmSikzELdvlmdBs TFdAM1zx3CscylrUPQyy3lrLuvWf9arpPHV7sex+cwkLKOGHl26mXMoOPwvEYcpJJ3phmR/aqxbC mZwz4LugVrqvC0sFERLSjfarSBQxKL7XSxxS6JYEL3LpMYIEdDCCBHACAQEwgbEwgZsxCzAJBgNV BAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAY BgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQg QXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAImdrrrSrE1TMdXIyvE0qYEwCQYF Kw4DAhoFAKCCApcwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTUw MzA5MTA0NjQ1WjAjBgkqhkiG9w0BCQQxFgQU0MQDIRE/ArBtJmCLjPxPgcK3ZjgwgasGCSqGSIb3 DQEJDzGBnTCBmjALBglghkgBZQMEASowCwYJYIZIAWUDBAEWMAoGCCqGSIb3DQMHMAsGCWCGSAFl AwQBAjAOBggqhkiG9w0DAgICAIAwBwYFKw4DAgcwDQYIKoZIhvcNAwICAUAwDQYIKoZIhvcNAwIC ASgwBwYFKw4DAhowCwYJYIZIAWUDBAIDMAsGCWCGSAFlAwQCAjALBglghkgBZQMEAgEwgcIGCSsG AQQBgjcQBDGBtDCBsTCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3Rl cjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMT OENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENB AhEAiZ2uutKsTVMx1cjK8TSpgTCBxAYLKoZIhvcNAQkQAgsxgbSggbEwgZsxCzAJBgNVBAYTAkdC MRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoT EUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAImdrrrSrE1TMdXIyvE0qYEwDQYJKoZIhvcN AQEBBQAEggEAEgEbPlphpBjBFyiK7A55LKy6JHANRr4Fu6r/+5o9AxKzI1VHK+JXm1uuDBqPnR4a x+vTor1pCjWBgLTNMI6zimkqv2AN4BWLDSM09xPnQLJ6unnbv5f/+cGPl7ffDm3ArEEl2x4RedJb ms1jBVEzcEz3tEBcMRNV+f+UrSXs+VavsJmMXNg0mM3oPnuvY6G4fWtDzux5JNXSE778W9yNfGtg Bp5VGzR3Xzoqa1krON3jcItYBxARdg6s5hId5+dQXcixfsELbTXHT5bREjJ/T4v19Mj0iDR6F6bm He60wILUTh2aDP3zEGE87kTj8/VEnDDfPXXZdtOzQ/gwORgNfgAAAAAAAA== ------=_NextPart_000_001A_01D05A5E.B83FD0C0-- From nobody Mon Mar 9 11:30:52 2015 Return-Path: X-Original-To: detnet@ietfa.amsl.com Delivered-To: detnet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AA641A9253; Mon, 9 Mar 2015 11:30:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 fhtY9Tx8NtK5; Mon, 9 Mar 2015 11:30:40 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4DBFA1A9239; Mon, 9 Mar 2015 11:30:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10271; q=dns/txt; s=iport; t=1425925820; x=1427135420; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=RtgBEzjBJE/atRgpMlHpoOjKEXgXbARnu7ZKCRXlbrY=; b=ab25Dy07TmPjajh+vt3lTpVVeMd2PB0AyQL7oiDSqYkBYL8mhTYvQdQf uDOVFPfabn6yHKbzGfql5c0Pr9TC0ytrmQnsGcHE13g+tmPynnRkb7Y2R H0t+VW0ArvVcG3dEk/EnyeZhyqukTvllezx6cLJ9wHbB0cxiN60mJLOkN o=; X-Files: smime.p7s : 4831 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0B2GwB95v1U/4sNJK1bgwZSWgS8a4NIgjaFcAKBKk0BAQEBAQF8hA8BAQECAnkMBAIBCBEBAwEBCx0HAjAUAwYIAQEEAQ0FCAaIIQ3BNwEBAQEBAQEBAQEBAQEBAQEBAQEBAReCTIhLhD0xBwaDEYEWBYo7hVSBZYEuUYVwgRk5gm+PMiODbm8BgUN/AQEB X-IronPort-AV: E=Sophos;i="5.11,369,1422921600"; d="p7s'?scan'208";a="130308020" Received: from alln-core-6.cisco.com ([173.36.13.139]) by alln-iport-3.cisco.com with ESMTP; 09 Mar 2015 18:30:19 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id t29IUJFR015376 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 9 Mar 2015 18:30:19 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.110]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.03.0195.001; Mon, 9 Mar 2015 13:30:19 -0500 From: "Pascal Thubert (pthubert)" To: "6tisch@ietf.org" <6tisch@ietf.org>, "detnet@ietf.org" Thread-Topic: 6TiSCH (inviting DetNet) agenda for IETF 92 Thread-Index: AdBaVlQJpaeD/yO5Q26TfxoYufysJQAQECvA Date: Mon, 9 Mar 2015 18:30:18 +0000 Deferred-Delivery: Mon, 9 Mar 2015 18:29:00 +0000 Message-ID: References: In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.61.105.35] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0048_01D05A9F.2C52ACE0" MIME-Version: 1.0 Archived-At: Cc: Thomas Watteyne , "Jouni Korhonen \(jouni.korhonen@broadcom.com\)" Subject: Re: [Detnet] 6TiSCH (inviting DetNet) agenda for IETF 92 X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussions on Deterministic Networking, characterized by 1\) resource reservation; 2\) 0 congestion loss and guaranteed latency; 3\) over L2-only and mixed L2 and L3 networks; and 5\) 1+1 replication/deletion." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2015 18:30:46 -0000 ------=_NextPart_000_0048_01D05A9F.2C52ACE0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear all: Due to a collision with security, we propose to move the agenda as = follows: Monday ------ DetNet=20 draft-finn-detnet-architecture (Norm) [20 mn] draft-gunther-detnet-proaudio-req (Craig) [10 mn] draft-wetterwald-detnet-utilities-reqs (Patrick) [10 mn] draft-wang-6tisch-track-use-cases (Chonggang) [10 mn] Security [30 mn] DT status and design goals (Michael) draft-struik-6tisch-security-architecture-elements (Ren=E9) Wrap up for rechartering [10 mn] Thursday -------- Last Call Status [40 mn] draft-ietf-6tisch-tsch(Thomas) draft-ietf-6tisch-minimal (Xavi) draft-ietf-6tisch-architecture (Pascal) draft-ietf-6tisch-terminology (Maria-Rita) Other Drafts [30 mn] draft-ietf-6tisch-6top-interface (Qin/Xavi) draft-wang-6tisch-6top (Qin/Xavi) draft-ietf-6tisch-coap (Raghuram/Pouria) Plugtest [10 mn] Distributed Scheduling OTF (Diego) [30 mn] Rechartering [40 mn] Summary of Monday's meeting Scheduling goals and deliverables Security goals and deliverables Any objection? Pascal > -----Original Message----- > From: detnet [mailto:detnet-bounces@ietf.org] On Behalf Of Pascal = Thubert > (pthubert) > Sent: lundi 9 mars 2015 11:48 > To: 6tisch@ietf.org; detnet@ietf.org > Cc: Thomas Watteyne; Jouni Korhonen (jouni.korhonen@broadcom.com) > Subject: [Detnet] 6TiSCH (inviting DetNet) agenda for IETF 92 >=20 > Dear all: >=20 > We published the draft agenda on the IETF site: > http://datatracker.ietf.org/meeting/agenda/ >=20 > Compiled drafts: > http://datatracker.ietf.org/meeting/92/agenda/6tisch-drafts.pdf >=20 > Monday > ------ > Distributed Scheduling > OTF (Diego) [30 > min] > DetNet > draft-finn-detnet-architecture (Norm) [20 min] > draft-gunther-detnet-proaudio-req (Craig) [10 min] > draft-wetterwald-detnet-utilities-reqs (Patrick) [10 min] > 6TiSCH reqs (Chonggang) [10 min] > Wrap up for rechartering [10 min] >=20 >=20 > Thursday > -------- > Last Call Status [40 > mins] > draft-ietf-6tisch-tsch(Thomas) > draft-ietf-6tisch-minimal (Xavi) > draft-ietf-6tisch-architecture (Pascal) > draft-ietf-6tisch-terminology (Maria-Rita) > Other Drafts [30 > mins] > draft-ietf-6tisch-6top-interface (Qin/Xavi) > draft-wang-6tisch-6top (Qin/Xavi) > draft-ietf-6tisch-coap (Raghuram/Pouria) > Plugtest [10 > mins] > Security [30 > mins] > DT status and design goals (Michael) > draft-struik-6tisch-security-architecture-elements (Ren=E9) > Rechartering [40 > mins] > Summary of Monday's meeting > Scheduling goals and deliverables > Security goals and deliverables >=20 > Please let us know if we need to make a change by the end of this = week. >=20 > Cheers, >=20 > Thomas et Pascal ------=_NextPart_000_0048_01D05A9F.2C52ACE0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOLTCCBDYw ggMeoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwbzELMAkGA1UEBhMCU0UxFDASBgNVBAoTC0FkZFRy dXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBUVFAgTmV0d29yazEiMCAGA1UEAxMZ QWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0wMDA1MzAxMDQ4MzhaFw0yMDA1MzAxMDQ4Mzha MG8xCzAJBgNVBAYTAlNFMRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQGA1UECxMdQWRkVHJ1c3Qg RXh0ZXJuYWwgVFRQIE5ldHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0IEV4dGVybmFsIENBIFJvb3Qw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC39xoz5vIABC054E5b7R+8bA/Ntfojts7e mxEzl6QpTH2Tn71KvJPtAxrjj8/lbVBa1pcplFqAsEl62y6V/bjKvzc4LR4+kUGtcFbH8E8/6DKe dMrIkFTpxl8PeJ2aQDwOrGGqXhSPnoehalDc15pOrwWzpnGUnHGzUGAKxxOdOAeGAqjpqGkmGJCr TLBPI6s6T4TY386f4Wlvu9dC12tE5Met7m1BX3JacQg3s3llpFmglDf3AC8NwpJy2tA4ctsUqEXE XSp9t7TWxO6szRNEt8kr3UMAJfphuWlqWCMRt6czj1Z1WfXNKddGtworZbbTQm8Vsrh7++/pXVPV NFonAgMBAAGjgdwwgdkwHQYDVR0OBBYEFK29mHo0tCb3+sQmVO8DveAky1QaMAsGA1UdDwQEAwIB BjAPBgNVHRMBAf8EBTADAQH/MIGZBgNVHSMEgZEwgY6AFK29mHo0tCb3+sQmVO8DveAky1QaoXOk cTBvMQswCQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0 IEV4dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290 ggEBMA0GCSqGSIb3DQEBBQUAA4IBAQCwm+CFJcLWI+IPlgaSnUGYnNmEeYHZHlsUByM2ZY+w2He7 rEFsR2CDUbD5Mj3n/PYmE8eAFqW/WvyHz3h5iSGa4kwHCoY1vPLeUcTSlrfcfk7ucP0cOesMAlEU LY69FuDB30Z15ySt7PRCtIWTcBBnup0GNUoY0yt6zFFCoXpj0ea7ocUrwja+Ew3mvWN+eXunCQ1A q2rdj4rD9vaMGkIFUdRF9Z+nYiFoFSBDPJnnfL0k2KmRF3OIP1YbMTgYtHEPms3IDp6OLhvhjJiD yx8x8URMxgRzSXZgD8f4vReAay7pzEwOWpp5DyAKLtWeYyYeVZKU2IIXWnvQvMePToYEMIIErzCC A5egAwIBAgIRAOAjyxUSg1OJrWFuelRnayEwDQYJKoZIhvcNAQELBQAwbzELMAkGA1UEBhMCU0Ux FDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBUVFAgTmV0 d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0xNDEyMjIwMDAwMDBa Fw0yMDA1MzAxMDQ4MzhaMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVz dGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UE AxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwg Q0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCJsQ3aelMZTnBSHbxWpgYmt7hJ4Jbn Uavx8FoTSRWjtIwbYLx6UUKneYykIt8XYU6R1XYjChTTSgJ/th0JgG6lBD3ZursW/qGHqS5DUkMW fK8yUMimT1rpCNjPkyWce4joMGTmpPhWgP0qJBQzF5msROVpi6NGBkvCM9TpQJ8GsLGsk0C5tQiT OpwqU6MQ2z0gYTxVA47ZTnYlAiEp+qN8cXZP7uFfgen7VIDbw3s1UreE3iI9LDAtMX9ZvVI3sDNp LUPr+tal8Zd3Z1GM2e4n67ylBzh2jKSpOP/fjPUDrEm+yvdzmToPMquclToTPQ5GOld0YVC+xkA/ y+Tin6IhAgMBAAGjggEXMIIBEzAfBgNVHSMEGDAWgBStvZh6NLQm9/rEJlTvA73gJMtUGjAdBgNV HQ4EFgQUkmFrguGioKpP7GfxwqP3tIAAwewwDgYDVR0PAQH/BAQDAgGGMBIGA1UdEwEB/wQIMAYB Af8CAQAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMBEGA1UdIAQKMAgwBgYEVR0gADBE BgNVHR8EPTA7MDmgN6A1hjNodHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vQWRkVHJ1c3RFeHRlcm5h bENBUm9vdC5jcmwwNQYIKwYBBQUHAQEEKTAnMCUGCCsGAQUFBzABhhlodHRwOi8vb2NzcC51c2Vy dHJ1c3QuY29tMA0GCSqGSIb3DQEBCwUAA4IBAQAbKm6sVcE6q4jF2O3NVfOqa2ErwAkQI5kPxWZq b7H1tLV3Xg8CYQDffQX+ErOkgIAA/PsdW2pyAgpBvAW6wVjVJsLq1U2E+/6CmM9YG+MiY5xS+LsF Nqt9WKXeqztj5drVc+/s4Pt74qP/8EIjnMq2jU0+5EsYA7KoLdTYu0JLkGmFENumNzToe+ABEKWc yjrHn0+ING6KZdAairup3MrKNtH0/MJkKTWv1rGncRHSA0Oxjz6a7J4yU/R2ksqGNAe5LMrmHErY mQ3BhuKQkvtaQmojIRDpZcf11bt+6oyFIAJi6tE6ByxZxZkz8jiJ5bbpFnofeRT2ShAaJvp8ivub MIIFPDCCBCSgAwIBAgIRAImdrrrSrE1TMdXIyvE0qYEwDQYJKoZIhvcNAQELBQAwgZsxCzAJBgNV BAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAY BgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQg QXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xNTAyMDMwMDAwMDBaFw0xNjAy MDMyMzU5NTlaMCMxITAfBgkqhkiG9w0BCQEWEnB0aHViZXJ0QGNpc2NvLmNvbTCCASIwDQYJKoZI hvcNAQEBBQADggEPADCCAQoCggEBALTqoFHH36vHzOLhXp5Wv28HBpYWouQolX/OzHVrZbIEblHp NAxFdrnNSWULDP5gT8hp/t4P0XO3YEnaQxpPUu0wWFlLrDC690s0y3T0hATowmfycNcLX+hddBDL 8ChyZdJAVhxl0vnxORmcciJmXmWOJ+4lzEqaDbm5lZUHgi3kc0t9/IFOOJ6yq1kjttHu1MFPZZUc lUnlpXmD+2/GzxeCHlQgLvw232No6lrAS34PQxbu7rnfw25Spd3CFP7RymWZnNL26rIvt3J4rpv8 xy0EedfU3AUo5scNpr7Mb1npOgVU7N+K07atmjh71wpvfnpvwIxPA+OOHcXwOS5JsosCAwEAAaOC AfAwggHsMB8GA1UdIwQYMBaAFJJha4LhoqCqT+xn8cKj97SAAMHsMB0GA1UdDgQWBBS2xFsxMSdl ViqpYN1OZcdW6Bg4OTAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggr BgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYB BAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMF0G A1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET1NIQTI1NkNsaWVu dEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgZAGCCsGAQUFBwEBBIGDMIGAMFgG CCsGAQUFBzAChkxodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9TSEEyNTZDbGllbnRBdXRo ZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5j b21vZG9jYS5jb20wHQYDVR0RBBYwFIEScHRodWJlcnRAY2lzY28uY29tMA0GCSqGSIb3DQEBCwUA A4IBAQABMkoJZJ5HHnG3Sl0jOpl8Emhb5fjpyW2eK26Zy8e62uqUL7ExSBChD97N1lCYUFY4TqIR zCmaObFC+fDgG3IDQ7ZOJDVu6ZK8TAGiBF6sSYcg5rSfIKPxJUQvTciSrTE+XHEVONmU6xQrMIYY 4/T4iho50oQmNpTSNmGc19ZZ9mQtbRGsjdwILm5NvIyI3X088GidfVJqifQ9dRmSikzELdvlmdBs TFdAM1zx3CscylrUPQyy3lrLuvWf9arpPHV7sex+cwkLKOGHl26mXMoOPwvEYcpJJ3phmR/aqxbC mZwz4LugVrqvC0sFERLSjfarSBQxKL7XSxxS6JYEL3LpMYIEdDCCBHACAQEwgbEwgZsxCzAJBgNV BAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAY BgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQg QXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAImdrrrSrE1TMdXIyvE0qYEwCQYF Kw4DAhoFAKCCApcwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTUw MzA5MTgyODA4WjAjBgkqhkiG9w0BCQQxFgQUuuAlXaTpTf5ugYMt8ebD/JN/Fg4wgasGCSqGSIb3 DQEJDzGBnTCBmjALBglghkgBZQMEASowCwYJYIZIAWUDBAEWMAoGCCqGSIb3DQMHMAsGCWCGSAFl AwQBAjAOBggqhkiG9w0DAgICAIAwBwYFKw4DAgcwDQYIKoZIhvcNAwICAUAwDQYIKoZIhvcNAwIC ASgwBwYFKw4DAhowCwYJYIZIAWUDBAIDMAsGCWCGSAFlAwQCAjALBglghkgBZQMEAgEwgcIGCSsG AQQBgjcQBDGBtDCBsTCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3Rl cjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMT OENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENB AhEAiZ2uutKsTVMx1cjK8TSpgTCBxAYLKoZIhvcNAQkQAgsxgbSggbEwgZsxCzAJBgNVBAYTAkdC MRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoT EUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAImdrrrSrE1TMdXIyvE0qYEwDQYJKoZIhvcN AQEBBQAEggEAeJ1HsQAmkSLxyUmOZrPwWAsb7QSdy7wmh/OCwomoWC9o54M4LLv3X+r2pd+ltGJL D1hPHCKqtlPCL8EIdw0aMOFjxKONnwicfvdHO84xSqvpqu3Au4EcgXOe44hX1/BNolLQc/2HVw4v UDwkPi1X99pdCB3VQk5ksO2hIckLjpBvxvdyWm4MtUCOd5jSFYiHU/SI2kuT+gArdFcTJt7N27cT zTsjWo4ou4AD+N1QCAPhDAs0e5UTO8lEXLgrMwbHdiy3UdWVpPkw/eQZA76QIdykvEtMXftc4TDQ LIKb2g+U9C2hUPo3DuPWPJH613+4XOXF8ALUk+xBXDkHYJr1wQAAAAAAAA== ------=_NextPart_000_0048_01D05A9F.2C52ACE0-- From nobody Mon Mar 9 13:12:47 2015 Return-Path: X-Original-To: detnet@ietfa.amsl.com Delivered-To: detnet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A051C1AC3E7; Mon, 9 Mar 2015 13:12:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 I0Y-7_tPHVPn; Mon, 9 Mar 2015 13:12:39 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A97EB1A9026; Mon, 9 Mar 2015 13:12:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10912; q=dns/txt; s=iport; t=1425931955; x=1427141555; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=8uKCw4J//J8OuCyACanY6G6iLEjgOTadVmNVq/vTKXs=; b=W6EtEpl446nZ852gIyAvOAzJ2nuGcTczfjCwPknXph8krvuJj3iStJGM arzLnkjEGS68bSaOWTjBxbh8JHlNCResacB9QEJR2cCL8Eawol1hpuVnP S1l8q334HQUBEw8X1WZy11Pk1wl5oSq31lYgVfQQV0dDWJ0/R9Kj2g5ok E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AODQA1/v1U/5RdJa1ZA4MGUlrAOoIsAQmFJ0kCgStNAQEBAQEBfIQPAQEBAgIBAQFrCwwEAgEIDgMBAwEBKAchBgsUAwYIAQEEDgWIGwMRDbx2DYU0AQEBAQEBAQEBAQEBAQEBAQEBAQEBF4JMiEuCRIFIEQFAEAcGC4MGgRYFijuCP4MVg2SEJ4FIgRo5gm+JH4YTI4NubwGBCoE4AQEB X-IronPort-AV: E=Sophos;i="5.11,369,1422921600"; d="scan'208,217";a="130345171" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by alln-iport-4.cisco.com with ESMTP; 09 Mar 2015 20:12:34 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id t29KCYoD017064 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 9 Mar 2015 20:12:34 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.110]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.03.0195.001; Mon, 9 Mar 2015 15:12:34 -0500 From: "Pascal Thubert (pthubert)" To: Rene Struik Thread-Topic: [6tisch] 6TiSCH (inviting DetNet) agenda for IETF 92 Thread-Index: AdBaVlQJpaeD/yO5Q26TfxoYufysJQARckTrAAJQ+dU= Date: Mon, 9 Mar 2015 20:12:33 +0000 Message-ID: <9E25942C-B3E3-4CE9-858D-A75BDE998A89@cisco.com> References: , <54FDEF22.8040006@gmail.com> In-Reply-To: <54FDEF22.8040006@gmail.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_9E25942CB3E34CE9858DA75BDE998A89ciscocom_" MIME-Version: 1.0 Archived-At: Cc: Thomas Watteyne , "Jouni Korhonen \(jouni.korhonen@broadcom.com\)" , "6tisch@ietf.org" <6tisch@ietf.org>, "detnet@ietf.org" Subject: Re: [Detnet] [6tisch] 6TiSCH (inviting DetNet) agenda for IETF 92 X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussions on Deterministic Networking, characterized by 1\) resource reservation; 2\) 0 congestion loss and guaranteed latency; 3\) over L2-only and mixed L2 and L3 networks; and 5\) 1+1 replication/deletion." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2015 20:12:42 -0000 --_000_9E25942CB3E34CE9858DA75BDE998A89ciscocom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable TLS it is Rene, Pascal Le 9 mars 2015 =E0 20:06, Rene Struik > a =E9crit : Hi Pascal: Not sure what the pain point is: tls? Originally, the security topics of 6tisch were scheduled for Thu. It seems = beneficial to keep to that schedule for now, thus giving some more room for= face-to-face time and benefiting from feedback from other groups having th= is now on the agenda (e.g., 6lo, Anima). What about keeping the security item on Thu and moving some of the WGLC or,= e.g., distributed scheduling to Monday? Best regards, Rene On 3/9/2015 2:30 PM, Pascal Thubert (pthubert) wrote: Dear all: Due to a collision with security, we propose to move the agenda as follows: Monday ------ DetNet draft-finn-detnet-architecture (Norm) [20 mn] draft-gunther-detnet-proaudio-req (Craig) [10 mn] draft-wetterwald-detnet-utilities-reqs (Patrick) [10 mn] draft-wang-6tisch-track-use-cases (Chonggang) [10 mn] Security [30 mn] DT status and design goals (Michael) draft-struik-6tisch-security-architecture-elements (Ren=E9) Wrap up for rechartering [10 mn] Thursday -------- Last Call Status [40 mn] draft-ietf-6tisch-tsch(Thomas) draft-ietf-6tisch-minimal (Xavi) draft-ietf-6tisch-architecture (Pascal) draft-ietf-6tisch-terminology (Maria-Rita) Other Drafts [30 mn] draft-ietf-6tisch-6top-interface (Qin/Xavi) draft-wang-6tisch-6top (Qin/Xavi) draft-ietf-6tisch-coap (Raghuram/Pouria) Plugtest [10 mn] Distributed Scheduling OTF (Diego) [30 mn] Rechartering [40 mn] Summary of Monday's meeting Scheduling goals and deliverables Security goals and deliverables Any objection? Pascal -----Original Message----- From: detnet [mailto:detnet-bounces@ietf.org] On Behalf Of Pascal Thubert (pthubert) Sent: lundi 9 mars 2015 11:48 To: 6tisch@ietf.org; detnet@ietf.org Cc: Thomas Watteyne; Jouni Korhonen (jouni.korhonen@broadcom.com) Subject: [Detnet] 6TiSCH (inviting DetNet) agenda for IETF 92 Dear all: We published the draft agenda on the IETF site: http://datatracker.ietf.org/meeting/agenda/ Compiled drafts: http://datatracker.ietf.org/meeting/92/agenda/6tisch-drafts.pdf Monday ------ Distributed Scheduling OTF (Diego) [30 min] DetNet draft-finn-detnet-architecture (Norm) [20 min] draft-gunther-detnet-proaudio-req (Craig) [10 min] draft-wetterwald-detnet-utilities-reqs (Patrick) [10 min] 6TiSCH reqs (Chonggang) [10 min] Wrap up for rechartering [10 min] Thursday -------- Last Call Status [40 mins] draft-ietf-6tisch-tsch(Thomas) draft-ietf-6tisch-minimal (Xavi) draft-ietf-6tisch-architecture (Pascal) draft-ietf-6tisch-terminology (Maria-Rita) Other Drafts [30 mins] draft-ietf-6tisch-6top-interface (Qin/Xavi) draft-wang-6tisch-6top (Qin/Xavi) draft-ietf-6tisch-coap (Raghuram/Pouria) Plugtest [10 mins] Security [30 mins] DT status and design goals (Michael) draft-struik-6tisch-security-architecture-elements (Ren=E9) Rechartering [40 mins] Summary of Monday's meeting Scheduling goals and deliverables Security goals and deliverables Please let us know if we need to make a change by the end of this week. Cheers, Thomas et Pascal _______________________________________________ 6tisch mailing list 6tisch@ietf.org https://www.ietf.org/mailman/listinfo/6tisch -- email: rstruik.ext@gmail.com | Skype: rstruik cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 --_000_9E25942CB3E34CE9858DA75BDE998A89ciscocom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
TLS it is Rene,

Pascal

Le 9 mars 2015 =E0 20:06, Rene Struik <rstruik.ext@gmail.com> a =E9crit :

Hi Pascal:

Not sure what the pain point is: tls?

Originally, the security topics of 6tisch were scheduled for Thu. It seems = beneficial to keep to that schedule for now, thus giving some more room for= face-to-face time and benefiting from feedback from other groups having th= is now on the agenda (e.g., 6lo, Anima).

What about keeping the security item on Thu and moving some of the WGLC or,= e.g., distributed scheduling to Monday?

Best regards, Rene


On 3/9/2015 2:30 PM, Pascal Thubert (pthubert) wrote:
Dear all:

Due to a collision with security, we propose to move the agenda as follows:

Monday
------
DetNet=20
   draft-finn-detnet-architecture (Norm)              [20 mn]
   draft-gunther-detnet-proaudio-req (Craig)          [10 mn]
   draft-wetterwald-detnet-utilities-reqs (Patrick)   [10 mn]
   draft-wang-6tisch-track-use-cases (Chonggang)      [10 mn]
Security                                              [30 mn]
   DT status and design goals (Michael)
   draft-struik-6tisch-security-architecture-elements (Ren=E9)
Wrap up for rechartering                              [10 mn]


Thursday
--------
Last Call Status                                      [40 mn]
   draft-ietf-6tisch-tsch(Thomas)
   draft-ietf-6tisch-minimal (Xavi)
   draft-ietf-6tisch-architecture (Pascal)
   draft-ietf-6tisch-terminology (Maria-Rita)
Other Drafts                                          [30 mn]
   draft-ietf-6tisch-6top-interface (Qin/Xavi)
   draft-wang-6tisch-6top (Qin/Xavi)
   draft-ietf-6tisch-coap (Raghuram/Pouria)
Plugtest                                              [10 mn]
Distributed Scheduling
   OTF (Diego)                                        [30 mn]
Rechartering                                          [40 mn]
   Summary of Monday's meeting
   Scheduling goals and deliverables
   Security goals and deliverables

Any objection?

Pascal



-----Original Message-----
From: detnet [mailto:detnet-bounces@ietf.org] On Behalf Of Pascal Thube=
rt
(pthubert)
Sent: lundi 9 mars 2015 11:48
To: 6=
tisch@ietf.org; detnet@ietf.org
Cc: Thomas Watteyne; Jouni Korhonen (jouni.korhonen@broadcom.com=
)
Subject: [Detnet] 6TiSCH (inviting DetNet) agenda for IETF 92

Dear all:

We published the draft agenda on the IETF site:
http://datatracker.ietf.org/meeting/agenda/

Compiled drafts:
http://datatracker.ietf.org/meeting/92/age=
nda/6tisch-drafts.pdf

Monday
------
Distributed Scheduling
   OTF (Diego)

[30

min]
DetNet
   draft-finn-detnet-architecture (Norm)              		[20

min]

   draft-gunther-detnet-proaudio-req (Craig)          	[10 m=
in]
   draft-wetterwald-detnet-utilities-reqs (Patrick)   	[10 min]
   6TiSCH reqs (Chonggang)                            		[10

min]

Wrap up for rechartering                              		[10

min]

Thursday
--------
Last Call Status

[40

mins]
   draft-ietf-6tisch-tsch(Thomas)
   draft-ietf-6tisch-minimal (Xavi)
   draft-ietf-6tisch-architecture (Pascal)
   draft-ietf-6tisch-terminology (Maria-Rita)
Other Drafts

[30

mins]
   draft-ietf-6tisch-6top-interface (Qin/Xavi)
   draft-wang-6tisch-6top (Qin/Xavi)
   draft-ietf-6tisch-coap (Raghuram/Pouria)
Plugtest                                             		 	[10
mins]
Security

[30

mins]
   DT status and design goals (Michael)
   draft-struik-6tisch-security-architecture-elements (Ren=E9)
Rechartering

[40

mins]
   Summary of Monday's meeting
   Scheduling goals and deliverables
   Security goals and deliverables

Please let us know if we need to make a change by the end of this week.

Cheers,

Thomas et Pascal



_______________________________________________
6tisch mailing list
6tisc=
h@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch



--=20
email: rstruik.ext@gmail.com | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363
--_000_9E25942CB3E34CE9858DA75BDE998A89ciscocom_-- From nobody Mon Mar 9 16:49:14 2015 Return-Path: X-Original-To: detnet@ietfa.amsl.com Delivered-To: detnet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FC381ACE57 for ; Mon, 9 Mar 2015 16:49:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 PFgnIjgRv9Gd for ; Mon, 9 Mar 2015 16:49:08 -0700 (PDT) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57DF91ACE4C for ; Mon, 9 Mar 2015 16:49:08 -0700 (PDT) Received: by wiwl15 with SMTP id l15so24490881wiw.1 for ; Mon, 09 Mar 2015 16:49:06 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=OCipLhVamHGIY5GEIP5py4qO+cBudBMBehAwZkls7A4=; b=aCD+OuKpnz+VPNsTrawsQCS8WyQAJ0kd8XfGDNv8z6zLBkOdFeqwJW+y/lSP1eV0EZ KBHLbQ2Nf1cazF4emKKNCZqO4E8c7JkvsG3rVc6ccKDvHnbpNjFmDVhcvpfsV4bvCYKe cq7GWCxWrn8sqNxejENTnt6oDDktTHIBVXJnV4SKmOwEJ2XlxUdBF2X/HnCybjt3ayj1 zZzsFFi6qWFERncaHMarHriqHgJ5aK0f9o4yA4DclKaItrWV7lFLJcl01K/fR5LlizZC xIano1cQ7pKSgULpC+THctu9FdOAiUZcd3z7Tm7Q+ZlaA/7dmPY+O3xO9Obesw7pbPbv B+Tg== X-Gm-Message-State: ALoCoQnrbiCVVIcA+WPL4Nc273LFKXQAPK6y4y+a7TbOBbTPFBecjAbDqTPRU0P2XO/g+kIiuzve MIME-Version: 1.0 X-Received: by 10.194.79.226 with SMTP id m2mr62084977wjx.60.1425944946875; Mon, 09 Mar 2015 16:49:06 -0700 (PDT) Received: by 10.28.220.2 with HTTP; Mon, 9 Mar 2015 16:49:06 -0700 (PDT) In-Reply-To: References: Date: Mon, 9 Mar 2015 20:49:06 -0300 Message-ID: From: "Prof. Diego Dujovne" To: "Pascal Thubert (pthubert)" Content-Type: multipart/alternative; boundary=047d7bf0c5380734600510e3ae45 Archived-At: Cc: "detnet@ietf.org" Subject: Re: [Detnet] Gap analysis X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussions on Deterministic Networking, characterized by 1\) resource reservation; 2\) 0 congestion loss and guaranteed latency; 3\) over L2-only and mixed L2 and L3 networks; and 5\) 1+1 replication/deletion." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2015 23:49:12 -0000 --047d7bf0c5380734600510e3ae45 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Pascal, All, I have submitted a draft with the results of the former discussion about the Gap Analysis for DetNet. Regards, Diego Dujovne 2015-02-24 6:40 GMT-03:00 Pascal Thubert (pthubert) : > Hello Diego: > > > > I think that you can start with the well-understood 6TiSCH gap (industria= l > process control) and expand from there to others such as AVB and vehicule= , > with the aid of the group. > > Please see below: > > Dear all, > > I=C2=B4m currently working on a Gap analysis for > DetNet. I have some preliminary questions though: > > Fantastic! > > > > - Are we targetting specific applicability areas, such > as Flow control systems and/or Real time control > systems on standard industrial plants, mission-critical > > control systems? > > > > This is certainly in scope and we can start there. > > > > - I have gone through the presentations from the detnet > BOF at IETF 91; I can deduce that we are targetting > > a broader view (as Pascal mentioned in a former mail) > > than 6TiSCH to cover a wider range of deterministic > networks (wider than what is covered by 6TiSCH) > > > > - Yes but still 6tiSCH is a good start, mostly if you are presenting at a > 6TiSCH session. > > The IETF will not be conformable if layer2 operations are discussed too > much, since this is beyond our scope. It is really up to cross > participation (which we do have) to ensure that the concepts that we > manipulate are compatible with what IEEE is and will be doing. > > - 6TiSCH needs to install tracks with all the Deterministic capabilities, > scheduled transmissions, path and packet redundancy, etc=E2=80=A6 which m= eans > PCE/SDN operations > > - And then we have identified the need to reuse opportunistically track > slots to forward IPv6 packets and Link bundle slots to forward scheduled > packets that missed their track, which means that IP has a role to play i= n > the DetNet world. > > Certainly what you=E2=80=99ll obtain applies to a larger world than 6TiSC= H, but > you=E2=80=99ll find in 6TiSCH most of the gap that DetNet in general will= have. > > > > > which are not currently IP-enabled, including in-vehicle > > networks, utility control long-range networks and > > general purpose monitoring networks. Here I think > > about the reverse of what I have observed on recent > > commercial adaptations (Profibus, ModBus over IP). > > > > The way we designed today, 6TiSCH tracks can carry any 802.15.4 packet, > but will not allow opportunistic operations for non IP packets. > > In general, if we tag Deterministic payload with MPLS and some variation > of PRP, we can carry anything, and I think we should aim at that. > > > > - I can also think that the main gaps are on the > > *scheduling management side (as 6TiSCH does) > > *network management of timers, queue schedulers and > > buffers > > *anything else? > > > > We need to decide if we want to work on the northbound interface. If we > do, we need some abstraction of the TSPEC, and we need to describe the pu= sh > model where the user agent / app requires a service implementing that TSP= EC > from the PCE (and then the PCE pushes the tracks onto the network over th= e > southbound interface) > > > > We certainly need to work on the southbound interface, > > - what adaptation of TEAS will carry the topology (neighbors, link > quality, interference test..) as well as the capability (buffers, queues, > timers) as seen by individual devices. > > - what adaptation of CCAMP/RSVP-TE can be used to program individual trac= ks > > - what adaptation of PCEP can be used to push a device schedule (PCE is > currently not chartered to push things to individual nodes) > > > > We need to formalize how a packet is identified as pertaining a certain > track (I=E2=80=99d rather not use flow, the word is just too overloaded).= Use of > DiffServ/DSCP and of MPLS have to be evaluated, including G-MPLS for 6TiS= CH. > > Whether NVO3 and SFC may apply also has to be evaluated, and there is no > PRP that I know of at the IETF, so this is probably to be done entirely b= y > DetNet. > > 6TiSCH adds the notion of Generalized for both flow tagging and PRP. The > flow (the track) can be determined from the timeslot in a G-MPLS fashion, > and the PRP sequence number can be determined from the ASN. > > > > And then we need to decide if we want an LMI (a UNI) between the first > network device and the end point to indicate availability and other state > information of a track. > > > > Thank you. > > > > Thank You! > > Diego Dujovne > > > -- > > DIEGO DUJOVNE > Acad=C3=A9mico Escuela de Ingenier=C3=ADa en Inform=C3=A1tica y Telecomun= icaciones > Facultad de Ingenier=C3=ADa UDP > www.ingenieria.udp.cl > (56 2) 676 8125 > --=20 DIEGO DUJOVNE Acad=C3=A9mico Escuela de Ingenier=C3=ADa en Inform=C3=A1tica y Telecomunic= aciones Facultad de Ingenier=C3=ADa UDP www.ingenieria.udp.cl (56 2) 676 8125 --047d7bf0c5380734600510e3ae45 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Pascal, All,
=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 I hav= e submitted a draft with the results of the former
discussion abou= t the Gap Analysis for DetNet.
=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Regards,
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Diego Du= jovne
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0

2015-02-24 6:40 GMT-03:00 Pascal Thubert (pthubert)= <pthubert@cisco.com>:

Hello Diego:

=C2=A0

I think that you can start = with the well-understood 6TiSCH gap (industrial process control) and expand= from there to others such as AVB and vehicule, with the aid of the group.<= u>

P= lease see below:

=

Dear all,

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 I=C2=B4m currently working on a Gap analysis fo= r
DetNet. I have some preliminary questions though:

Fantast= ic!

=C2=A0

-= Are we targetting specific applicability areas, such
as Flow control sy= stems and/or Real time control
systems on standard industrial plants, m= ission-critical

c= ontrol systems?

=C2=A0

This is certainly in scope and we can start there.

= =C2=A0

= - I have gone through the presentations from the detnet
BOF at IETF 91;= I can deduce that we are targetting

a broader view (as Pascal mentioned in a former mail)=

than 6= TiSCH to cover a wider range of deterministic
networks (wider than what= is covered by 6TiSCH) <= /p>

=C2=A0

- Yes but= still 6tiSCH is a good start, mostly if you are presenting at a 6TiSCH ses= sion.

The IETF will not be conformable if layer2 operations are discussed t= oo much, since this is beyond our scope. It is really up to cross participa= tion (which we do have) to ensure that the concepts that we manipulate are = compatible with what IEEE is and will be doing.

- 6TiSCH needs to install tr= acks with all the Deterministic capabilities, scheduled transmissions, path= and packet redundancy, etc=E2=80=A6 which means PCE/SDN operations<= u>

- And th= en we have identified the need to reuse opportunistically track slots to fo= rward IPv6 packets and Link bundle slots to forward scheduled packets that = missed their track, which means that IP has a role to play in the DetNet wo= rld.

Certainly what you=E2=80=99ll obtain applies to a larger world than 6Ti= SCH, but you=E2=80=99ll find in 6TiSCH most of the gap that DetNet in gener= al will have.

=C2=A0


which are not currently IP-enabled, including in-vehicle

netwo= rks, utility control long-range networks and

<= p class=3D"MsoNormal">general purpose monitoring networks. Here I think<= /u>

about the reverse of what I= have observed on recent

commercial adaptations (Profibus, ModBus over IP).=

= =C2=A0

The way we designed today, 6TiSCH tracks can carry any 802.15.4 packe= t, but will not allow opportunistic operations for non IP packets.

In genera= l, if we tag Deterministic payload with MPLS and some variation of PRP, we = can carry anything, and I think we should aim at that.=

=C2=A0<= /span>

- I can also t= hink that the main gaps are on the

*scheduling management side (as 6TiSCH does)

*network management of timers, queue schedu= lers and

buffers<= u>

*anything else?

=C2=A0

We need to decide if we want to work on the northbound interface. If we do= , we need some abstraction of the TSPEC, and we need to describe the push m= odel where the user agent / app requires a service implementing that TSPEC = from the PCE (and then the PCE pushes the tracks onto the network over the = southbound interface)

=C2=A0

= We certainly need to work on the southbound inte= rface,

- what adaptation of TEAS will carry the topology (neighbors, link q= uality, interference test..) as well as the capability (buffers, queues, ti= mers) as seen by individual devices.

- what adaptation of CCAMP/RSVP-TE can = be used to program individual tracks

- what adaptation of PCEP can be used t= o push a device schedule (PCE is currently not chartered to push things to = individual nodes)

=C2=A0

We need to formalize how a packet is identified as p= ertaining a certain track (I=E2=80=99d rather not use flow, the word is jus= t too overloaded). Use of DiffServ/DSCP and of MPLS have to be evaluated, i= ncluding G-MPLS for 6TiSCH.

= Whether NVO3 and SFC may apply also has to be ev= aluated, and there is no PRP that I know of at the IETF, so this is probabl= y to be done entirely by DetNet.

6TiSCH adds the notion of Generalized for b= oth flow tagging and PRP. The flow (the track) can be determined from the t= imeslot in a G-MPLS fashion, and the PRP sequence number can be determined = from the ASN.

=C2=A0

And then we need to decide if we want an LMI (a UNI) bet= ween the first network device and the end point to indicate availability an= d other state information of a track.

=C2=A0

Thank you.

=C2=A0

Thank You!

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 Diego Dujovne


--

DIEGO DUJOVNE
A= cad=C3=A9mico Escuela de Ingenier=C3=ADa en Inform=C3=A1tica y Telecomunica= ciones
Facultad de Ingenier=C3=ADa UDP
www.ingenieria.udp.cl
(56 2) 676 8125




--
DIEGO DUJOVNE
Acad=C3=A9mico Escuela de Ingenier=C3=ADa en Inform=C3= =A1tica y Telecomunicaciones
Facultad de Ingenier=C3=ADa UDP
www.ingenieria.udp.cl
(56 2) 676 8125
--047d7bf0c5380734600510e3ae45-- From nobody Mon Mar 9 16:49:52 2015 Return-Path: X-Original-To: detnet@ietfa.amsl.com Delivered-To: detnet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88A1A1ACE60 for ; Mon, 9 Mar 2015 16:49:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 JME9ayi1HS3i for ; Mon, 9 Mar 2015 16:49:49 -0700 (PDT) Received: from mail-we0-f180.google.com (mail-we0-f180.google.com [74.125.82.180]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 42A241ACE6E for ; Mon, 9 Mar 2015 16:49:39 -0700 (PDT) Received: by wesq59 with SMTP id q59so22411230wes.9 for ; Mon, 09 Mar 2015 16:49:38 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=mjtQyKHLsd1UFEL00sbZi8SnyMzD43gY6rHXdig4G20=; b=hOY1nQjsAuss4eWUfAvZs+RH6nCIz2A/G1id1codr13XWAhdxAh4pF68fCc3vLybD0 z2DT0maOlFXPC8FIDFotwf1A6mRvt1UACLQTgcpjeQeUVeTaFFpYQDxwNhpv0ytKOHDg 7uRtUTHQUCiW8uAjFAUC5mcvZ4X/rNvlsuT2OG44S9r7WP27ER9jllo1g3p/qD2RWfsg MMuhrBSKzIEOJdR5MOcoi6xOTciGQHcbhs4dGqsdlcc1RwzMncFgtFtoLEPDR9CmJ+sw mSkJ+/f0VzO6dkGiPx0ko9T/4n26qWQ1kZyN7dYjmX323JB9usE9L0Jg7LgIRBaQv4aY PUmQ== X-Gm-Message-State: ALoCoQnUqxguMkMGjIU+bzFsdx1ENH6oNa8ADX4AroY/VxU8UzTbYuS21i0j94DVrWzY+pkm550t MIME-Version: 1.0 X-Received: by 10.194.158.39 with SMTP id wr7mr64031694wjb.118.1425944978098; Mon, 09 Mar 2015 16:49:38 -0700 (PDT) Received: by 10.28.220.2 with HTTP; Mon, 9 Mar 2015 16:49:38 -0700 (PDT) In-Reply-To: <20150309234559.30730.48765.idtracker@ietfa.amsl.com> References: <20150309234559.30730.48765.idtracker@ietfa.amsl.com> Date: Mon, 9 Mar 2015 20:49:38 -0300 Message-ID: From: "Prof. Diego Dujovne" To: "detnet@ietf.org" Content-Type: multipart/alternative; boundary=089e01160576e3a0c00510e3af11 Archived-At: Subject: [Detnet] Fwd: New Version Notification for draft-dujovne-detnet-gap-analysis-00.txt X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussions on Deterministic Networking, characterized by 1\) resource reservation; 2\) 0 congestion loss and guaranteed latency; 3\) over L2-only and mixed L2 and L3 networks; and 5\) 1+1 replication/deletion." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2015 23:49:51 -0000 --089e01160576e3a0c00510e3af11 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable ---------- Forwarded message ---------- From: Date: 2015-03-09 20:45 GMT-03:00 Subject: New Version Notification for draft-dujovne-detnet-gap-analysis-00.txt To: Diego Dujovne A new version of I-D, draft-dujovne-detnet-gap-analysis-00.txt has been successfully submitted by Diego Dujovne and posted to the IETF repository. Name: draft-dujovne-detnet-gap-analysis Revision: 00 Title: Deterministic Networks Gap Analysis Document date: 2015-03-09 Group: Individual Submission Pages: 5 URL: http://www.ietf.org/internet-drafts/draft-dujovne-detnet-gap-analysis-00.tx= t Status: https://datatracker.ietf.org/doc/draft-dujovne-detnet-gap-analysis/ Htmlized: http://tools.ietf.org/html/draft-dujovne-detnet-gap-analysis-00 Abstract: This document introduces and describes several conditions and use cases where the use of an IP-based layer-3 and up is required to provide a complete networking solution to deterministic networks. The contents of this work is a gap analysis to contribute to the design and development of a number of complimentary modules to provide IP-enabled networking for deterministic networks. Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --=20 DIEGO DUJOVNE Acad=C3=A9mico Escuela de Ingenier=C3=ADa en Inform=C3=A1tica y Telecomunic= aciones Facultad de Ingenier=C3=ADa UDP www.ingenieria.udp.cl (56 2) 676 8125 --089e01160576e3a0c00510e3af11 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

---------- Forwarded messag= e ----------
From: = <internet-drafts@ietf.org>
Date: 2015-03-09 20:45 GMT-03:00
Subject: New Version No= tification for draft-dujovne-detnet-gap-analysis-00.txt
To: Diego Dujovn= e <diego.dujovne@mail.udp.c= l>



A new version of I-D, draft-dujovne-detnet-gap-analysis-00.txt
has been successfully submitted by Diego Dujovne and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-dujovne-detnet-gap-anal= ysis
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A000
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Deterministic Networks Gap Analysi= s
Document date:=C2=A0 2015-03-09
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 5
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 http://www.ietf.org/internet-drafts/draft-dujovne-detnet-gap-analysis-00= .txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://dat= atracker.ietf.org/doc/draft-dujovne-detnet-gap-analysis/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0http://tools.ietf.or= g/html/draft-dujovne-detnet-gap-analysis-00


Abstract:
=C2=A0 =C2=A0This document introduces and describes several conditions and = use
=C2=A0 =C2=A0cases where the use of an IP-based layer-3 and up is required = to
=C2=A0 =C2=A0provide a complete networking solution to deterministic networ= ks.
=C2=A0 =C2=A0The contents of this work is a gap analysis to contribute to t= he
=C2=A0 =C2=A0design and development of a number of complimentary modules to=
=C2=A0 =C2=A0provide IP-enabled networking for deterministic networks.




Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat




--
DIEGO= DUJOVNE
Acad=C3=A9mico Escuela de Ingenier=C3=ADa en Inform=C3=A1tica y= Telecomunicaciones
Facultad de Ingenier=C3=ADa UDP
www.ingenieria.udp.cl
(56 = 2) 676 8125
--089e01160576e3a0c00510e3af11-- From nobody Tue Mar 10 00:11:17 2015 Return-Path: X-Original-To: detnet@ietfa.amsl.com Delivered-To: detnet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABDEC1B2A08 for ; Tue, 10 Mar 2015 00:11:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 y2McMLs34rvc for ; Tue, 10 Mar 2015 00:11:13 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA2171B2A01 for ; Tue, 10 Mar 2015 00:11:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=248; q=dns/txt; s=iport; t=1425971473; x=1427181073; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=DByHjBAvnzowmBtN0oyd+9mhA6O7FDXX62ao7IxsSXM=; b=OahJ1aMAdd5/cwqG75gHBvb+9ClmsGUrfZifYDhsZaCL3JnNXfAkpEkR hvVQv6tmT6pbrtW9mUitrJxaHhxei9k+IQWxorotq5EVXaxPkjkOtZgfa iz0TWJTrvzMVHde3hVioT1TkZdIqffHK0ZrT/PWsIM68vjkPydbZdub2X s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AJBQCgmP5U/4UNJK1cgwaBMIMGxXyBFE0BAQEBAQF8hBYjEVcBGggCJgIEMBUCEASIQpZ9j0qcDAEBAQcBAQEBHoEhkVOBRQWQD4lTk3Qjg26CM38BAQE X-IronPort-AV: E=Sophos;i="5.11,373,1422921600"; d="scan'208";a="130485971" Received: from alln-core-11.cisco.com ([173.36.13.133]) by alln-iport-2.cisco.com with ESMTP; 10 Mar 2015 07:11:13 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id t2A7BC0c010141 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 10 Mar 2015 07:11:12 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.121]) by xhc-rcd-x04.cisco.com ([173.37.183.78]) with mapi id 14.03.0195.001; Tue, 10 Mar 2015 02:11:12 -0500 From: "Norman Finn (nfinn)" To: "detnet@ietf.org" Thread-Topic: Architecture draft Thread-Index: AQHQWwFj/5aGFqDN60yqfH3m0bUhuw== Date: Tue, 10 Mar 2015 07:10:45 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.7.141117 x-originating-ip: [10.24.31.197] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: [Detnet] Architecture draft X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussions on Deterministic Networking, characterized by 1\) resource reservation; 2\) 0 congestion loss and guaranteed latency; 3\) over L2-only and mixed L2 and L3 networks; and 5\) 1+1 replication/deletion." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2015 07:11:15 -0000 V2UgcHV0IG91dCB0d28gcXVpY2sgdmVyc2lvbnMgb2YgdGhlIGFyY2hpdGVjdHVyZSBkcmFmdDsg c29tZSB0YWJzIGNyZXB0DQppbnRvIHR3byBvZiB0aGUgZGlhZ3JhbXMsIHdlIGhhZCB0byBmaXgg YSBjb3VwbGUgb2YgVVJMcywgYW5kIHRoZXJlIHdhcyBhDQptaXNzaW5nIGF1dGhvci4NCg0K4oCU IE5vcm0NCg0K From nobody Sun Mar 15 18:50:26 2015 Return-Path: X-Original-To: detnet@ietfa.amsl.com Delivered-To: detnet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20EAE1A9122; Mon, 9 Mar 2015 12:06:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 91Olq8NXI0SM; Mon, 9 Mar 2015 12:06:19 -0700 (PDT) Received: from mail-ig0-x22f.google.com (mail-ig0-x22f.google.com [IPv6:2607:f8b0:4001:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E670C1A8AE5; Mon, 9 Mar 2015 12:06:13 -0700 (PDT) Received: by igal13 with SMTP id l13so23862585iga.5; Mon, 09 Mar 2015 12:06:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type; bh=lCjKSEUdfKaF4nLLkBDNvuuj6Dcyx0n5/NvByajZ0mA=; b=MvMRwzCpV3yWWwKBfUMtzbZRqANbGW0JcUV/FSGIZULUEjpUe0J0FQFxyb35y7NYze 7m5WDdRAAlUgAd2jerU0+C+S/YPxfoKIyfWHCxg8PYnyYRWSLMc0hZngJQ74BY5El6ND 0vUQxQwyN064N6QQYSlfkHl9FyxNB+V7ZL2ZVqTEb53ikZH9yjfTY5vM3QQtjCwbN5Ok iUXBeVSrTBuYvik41a1Z3K33xzMgA5UVaMw2mtgGj2etwd+a9KBP07rPIt8PaGTsK4kZ Df+qxwMPW+ECn1V39EZviHzvUyQUq1xp0v1Eku07Nm4SWfc/RGYrkJKYe+ZXDLVRDPuv PCpw== X-Received: by 10.42.85.82 with SMTP id p18mr29003087icl.58.1425927973248; Mon, 09 Mar 2015 12:06:13 -0700 (PDT) Received: from [192.168.0.10] (CPE7cb21b2cb904-CM7cb21b2cb901.cpe.net.cable.rogers.com. [99.231.49.38]) by mx.google.com with ESMTPSA id 130sm12643170ioz.10.2015.03.09.12.06.12 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 09 Mar 2015 12:06:12 -0700 (PDT) Message-ID: <54FDEF22.8040006@gmail.com> Date: Mon, 09 Mar 2015 15:06:10 -0400 From: Rene Struik User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" , "6tisch@ietf.org" <6tisch@ietf.org>, "detnet@ietf.org" References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------010103010100000306000607" Archived-At: X-Mailman-Approved-At: Sun, 15 Mar 2015 18:50:25 -0700 Cc: Thomas Watteyne , "Jouni Korhonen \(jouni.korhonen@broadcom.com\)" Subject: Re: [Detnet] [6tisch] 6TiSCH (inviting DetNet) agenda for IETF 92 X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussions on Deterministic Networking, characterized by 1\) resource reservation; 2\) 0 congestion loss and guaranteed latency; 3\) over L2-only and mixed L2 and L3 networks; and 5\) 1+1 replication/deletion." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2015 19:06:24 -0000 This is a multi-part message in MIME format. --------------010103010100000306000607 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Hi Pascal: Not sure what the pain point is: tls? Originally, the security topics of 6tisch were scheduled for Thu. It seems beneficial to keep to that schedule for now, thus giving some more room for face-to-face time and benefiting from feedback from other groups having this now on the agenda (e.g., 6lo, Anima). What about keeping the security item on Thu and moving some of the WGLC or, e.g., distributed scheduling to Monday? Best regards, Rene On 3/9/2015 2:30 PM, Pascal Thubert (pthubert) wrote: > Dear all: > > Due to a collision with security, we propose to move the agenda as follows: > > Monday > ------ > DetNet > draft-finn-detnet-architecture (Norm) [20 mn] > draft-gunther-detnet-proaudio-req (Craig) [10 mn] > draft-wetterwald-detnet-utilities-reqs (Patrick) [10 mn] > draft-wang-6tisch-track-use-cases (Chonggang) [10 mn] > Security [30 mn] > DT status and design goals (Michael) > draft-struik-6tisch-security-architecture-elements (René) > Wrap up for rechartering [10 mn] > > > Thursday > -------- > Last Call Status [40 mn] > draft-ietf-6tisch-tsch(Thomas) > draft-ietf-6tisch-minimal (Xavi) > draft-ietf-6tisch-architecture (Pascal) > draft-ietf-6tisch-terminology (Maria-Rita) > Other Drafts [30 mn] > draft-ietf-6tisch-6top-interface (Qin/Xavi) > draft-wang-6tisch-6top (Qin/Xavi) > draft-ietf-6tisch-coap (Raghuram/Pouria) > Plugtest [10 mn] > Distributed Scheduling > OTF (Diego) [30 mn] > Rechartering [40 mn] > Summary of Monday's meeting > Scheduling goals and deliverables > Security goals and deliverables > > Any objection? > > Pascal > > >> -----Original Message----- >> From: detnet [mailto:detnet-bounces@ietf.org] On Behalf Of Pascal Thubert >> (pthubert) >> Sent: lundi 9 mars 2015 11:48 >> To: 6tisch@ietf.org; detnet@ietf.org >> Cc: Thomas Watteyne; Jouni Korhonen (jouni.korhonen@broadcom.com) >> Subject: [Detnet] 6TiSCH (inviting DetNet) agenda for IETF 92 >> >> Dear all: >> >> We published the draft agenda on the IETF site: >> http://datatracker.ietf.org/meeting/agenda/ >> >> Compiled drafts: >> http://datatracker.ietf.org/meeting/92/agenda/6tisch-drafts.pdf >> >> Monday >> ------ >> Distributed Scheduling >> OTF (Diego) > [30 >> min] >> DetNet >> draft-finn-detnet-architecture (Norm) [20 > min] >> draft-gunther-detnet-proaudio-req (Craig) [10 min] >> draft-wetterwald-detnet-utilities-reqs (Patrick) [10 min] >> 6TiSCH reqs (Chonggang) [10 > min] >> Wrap up for rechartering [10 > min] >> >> Thursday >> -------- >> Last Call Status > [40 >> mins] >> draft-ietf-6tisch-tsch(Thomas) >> draft-ietf-6tisch-minimal (Xavi) >> draft-ietf-6tisch-architecture (Pascal) >> draft-ietf-6tisch-terminology (Maria-Rita) >> Other Drafts > [30 >> mins] >> draft-ietf-6tisch-6top-interface (Qin/Xavi) >> draft-wang-6tisch-6top (Qin/Xavi) >> draft-ietf-6tisch-coap (Raghuram/Pouria) >> Plugtest [10 >> mins] >> Security > [30 >> mins] >> DT status and design goals (Michael) >> draft-struik-6tisch-security-architecture-elements (René) >> Rechartering > [40 >> mins] >> Summary of Monday's meeting >> Scheduling goals and deliverables >> Security goals and deliverables >> >> Please let us know if we need to make a change by the end of this week. >> >> Cheers, >> >> Thomas et Pascal >> >> >> _______________________________________________ >> 6tisch mailing list >> 6tisch@ietf.org >> https://www.ietf.org/mailman/listinfo/6tisch -- email: rstruik.ext@gmail.com | Skype: rstruik cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 --------------010103010100000306000607 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
Hi Pascal:

Not sure what the pain point is: tls?

Originally, the security topics of 6tisch were scheduled for Thu. It seems beneficial to keep to that schedule for now, thus giving some more room for face-to-face time and benefiting from feedback from other groups having this now on the agenda (e.g., 6lo, Anima).

What about keeping the security item on Thu and moving some of the WGLC or, e.g., distributed scheduling to Monday?

Best regards, Rene


On 3/9/2015 2:30 PM, Pascal Thubert (pthubert) wrote:
Dear all:

Due to a collision with security, we propose to move the agenda as follows:

Monday
------
DetNet 
   draft-finn-detnet-architecture (Norm)              [20 mn]
   draft-gunther-detnet-proaudio-req (Craig)          [10 mn]
   draft-wetterwald-detnet-utilities-reqs (Patrick)   [10 mn]
   draft-wang-6tisch-track-use-cases (Chonggang)      [10 mn]
Security                                              [30 mn]
   DT status and design goals (Michael)
   draft-struik-6tisch-security-architecture-elements (René)
Wrap up for rechartering                              [10 mn]


Thursday
--------
Last Call Status                                      [40 mn]
   draft-ietf-6tisch-tsch(Thomas)
   draft-ietf-6tisch-minimal (Xavi)
   draft-ietf-6tisch-architecture (Pascal)
   draft-ietf-6tisch-terminology (Maria-Rita)
Other Drafts                                          [30 mn]
   draft-ietf-6tisch-6top-interface (Qin/Xavi)
   draft-wang-6tisch-6top (Qin/Xavi)
   draft-ietf-6tisch-coap (Raghuram/Pouria)
Plugtest                                              [10 mn]
Distributed Scheduling
   OTF (Diego)                                        [30 mn]
Rechartering                                          [40 mn]
   Summary of Monday's meeting
   Scheduling goals and deliverables
   Security goals and deliverables

Any objection?

Pascal



-----Original Message-----
From: detnet [mailto:detnet-bounces@ietf.org] On Behalf Of Pascal Thubert
(pthubert)
Sent: lundi 9 mars 2015 11:48
To: 6tisch@ietf.org; detnet@ietf.org
Cc: Thomas Watteyne; Jouni Korhonen (jouni.korhonen@broadcom.com)
Subject: [Detnet] 6TiSCH (inviting DetNet) agenda for IETF 92

Dear all:

We published the draft agenda on the IETF site:
http://datatracker.ietf.org/meeting/agenda/

Compiled drafts:
http://datatracker.ietf.org/meeting/92/agenda/6tisch-drafts.pdf

Monday
------
Distributed Scheduling
   OTF (Diego)

[30

min]
DetNet
   draft-finn-detnet-architecture (Norm)              		[20

min]

   draft-gunther-detnet-proaudio-req (Craig)          	[10 min]
   draft-wetterwald-detnet-utilities-reqs (Patrick)   	[10 min]
   6TiSCH reqs (Chonggang)                            		[10

min]

Wrap up for rechartering                              		[10

min]


Thursday
--------
Last Call Status

[40

mins]
   draft-ietf-6tisch-tsch(Thomas)
   draft-ietf-6tisch-minimal (Xavi)
   draft-ietf-6tisch-architecture (Pascal)
   draft-ietf-6tisch-terminology (Maria-Rita)
Other Drafts

[30

mins]
   draft-ietf-6tisch-6top-interface (Qin/Xavi)
   draft-wang-6tisch-6top (Qin/Xavi)
   draft-ietf-6tisch-coap (Raghuram/Pouria)
Plugtest                                             		 	[10
mins]
Security

[30

mins]
   DT status and design goals (Michael)
   draft-struik-6tisch-security-architecture-elements (René)
Rechartering

[40

mins]
   Summary of Monday's meeting
   Scheduling goals and deliverables
   Security goals and deliverables

Please let us know if we need to make a change by the end of this week.

Cheers,

Thomas et Pascal



_______________________________________________
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch



-- 
email: rstruik.ext@gmail.com | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363
--------------010103010100000306000607-- From nobody Tue Mar 17 00:56:02 2015 Return-Path: X-Original-To: detnet@ietfa.amsl.com Delivered-To: detnet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E52D1A00F1; Tue, 17 Mar 2015 00:56:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 W-B3PxQu1JFw; Tue, 17 Mar 2015 00:55:59 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28E9B1A00F0; Tue, 17 Mar 2015 00:55:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7327; q=dns/txt; s=iport; t=1426578959; x=1427788559; h=from:to:cc:subject:date:message-id:mime-version; bh=hqyc3lc3BYwls9F20uOQR4dw94NKVIBu3h18go5LMHs=; b=lbRA/971F9nVblq8H0dq+vJkZZDpEyGPpZY76Vyrx1O98kHkn/ABPW6j 8qyz2eKmVQyxXXANdPWmAXUF4Zm030TVwkMByvqzRz8KsaetTCvJBV3sJ Ftq9QlHB6hzI2OUnvS4mCQfXB9jrbeJP0PTa7sT7NR18YYZZnjq4eNPov 4=; X-Files: smime.p7s : 4831 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0A9BQAJ3AdV/49dJa1bgwZSXsJ+aYFHhXACgTY4FAEBAQEBAQF8hBEBBHkSASomMCYBBAENDQaIIQ3HPAEBAQEBAQEBAQEBAQEBAQEBAQEBARMEj08xgx6BFAWNeYF9gWCBLlGFZ4EZgx+LXoM+I4NugjN/AQEB X-IronPort-AV: E=Sophos;i="5.11,415,1422921600"; d="p7s'?scan'208";a="132591867" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by alln-iport-8.cisco.com with ESMTP; 17 Mar 2015 07:55:56 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id t2H7tuJY000634 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 17 Mar 2015 07:55:56 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.225]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.03.0195.001; Tue, 17 Mar 2015 02:55:56 -0500 From: "Pascal Thubert (pthubert)" To: "6tisch@ietf.org" <6tisch@ietf.org>, "detnet@ietf.org" Thread-Topic: Proceedings for Dallas sessions Thread-Index: AdBgh5U0XOhOh96nTRmR2B+KxFI/lg== Date: Tue, 17 Mar 2015 07:55:55 +0000 Deferred-Delivery: Tue, 17 Mar 2015 07:55:00 +0000 Message-ID: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.61.109.119] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0016_01D0608F.F7F3BC40" MIME-Version: 1.0 Archived-At: Cc: "Jouni Korhonen \(jouni.korhonen@broadcom.com\)" , "chonggang.wang@interdigital.com" , "6tisch-chairs@tools.ietf.org" <6tisch-chairs@tools.ietf.org> Subject: [Detnet] Proceedings for Dallas sessions X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussions on Deterministic Networking, characterized by 1\) resource reservation; 2\) 0 congestion loss and guaranteed latency; 3\) over L2-only and mixed L2 and L3 networks; and 5\) 1+1 replication/deletion." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Mar 2015 07:56:00 -0000 ------=_NextPart_000_0016_01D0608F.F7F3BC40 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Dear all: The agenda for IETF 92 is now final. For 6TiSCH and DetNet, it is published here: https://datatracker.ietf.org/meeting/92/agenda/6tisch/ Presenters/authors: please send your slides to the cc by Friday, indicating who will present and whether the presentation is on-site or remote. See you in Dallas! The chairs, ------=_NextPart_000_0016_01D0608F.F7F3BC40 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOLTCCBDYw ggMeoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwbzELMAkGA1UEBhMCU0UxFDASBgNVBAoTC0FkZFRy dXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBUVFAgTmV0d29yazEiMCAGA1UEAxMZ QWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0wMDA1MzAxMDQ4MzhaFw0yMDA1MzAxMDQ4Mzha MG8xCzAJBgNVBAYTAlNFMRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQGA1UECxMdQWRkVHJ1c3Qg RXh0ZXJuYWwgVFRQIE5ldHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0IEV4dGVybmFsIENBIFJvb3Qw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC39xoz5vIABC054E5b7R+8bA/Ntfojts7e mxEzl6QpTH2Tn71KvJPtAxrjj8/lbVBa1pcplFqAsEl62y6V/bjKvzc4LR4+kUGtcFbH8E8/6DKe dMrIkFTpxl8PeJ2aQDwOrGGqXhSPnoehalDc15pOrwWzpnGUnHGzUGAKxxOdOAeGAqjpqGkmGJCr TLBPI6s6T4TY386f4Wlvu9dC12tE5Met7m1BX3JacQg3s3llpFmglDf3AC8NwpJy2tA4ctsUqEXE XSp9t7TWxO6szRNEt8kr3UMAJfphuWlqWCMRt6czj1Z1WfXNKddGtworZbbTQm8Vsrh7++/pXVPV NFonAgMBAAGjgdwwgdkwHQYDVR0OBBYEFK29mHo0tCb3+sQmVO8DveAky1QaMAsGA1UdDwQEAwIB BjAPBgNVHRMBAf8EBTADAQH/MIGZBgNVHSMEgZEwgY6AFK29mHo0tCb3+sQmVO8DveAky1QaoXOk cTBvMQswCQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0 IEV4dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290 ggEBMA0GCSqGSIb3DQEBBQUAA4IBAQCwm+CFJcLWI+IPlgaSnUGYnNmEeYHZHlsUByM2ZY+w2He7 rEFsR2CDUbD5Mj3n/PYmE8eAFqW/WvyHz3h5iSGa4kwHCoY1vPLeUcTSlrfcfk7ucP0cOesMAlEU LY69FuDB30Z15ySt7PRCtIWTcBBnup0GNUoY0yt6zFFCoXpj0ea7ocUrwja+Ew3mvWN+eXunCQ1A q2rdj4rD9vaMGkIFUdRF9Z+nYiFoFSBDPJnnfL0k2KmRF3OIP1YbMTgYtHEPms3IDp6OLhvhjJiD yx8x8URMxgRzSXZgD8f4vReAay7pzEwOWpp5DyAKLtWeYyYeVZKU2IIXWnvQvMePToYEMIIErzCC A5egAwIBAgIRAOAjyxUSg1OJrWFuelRnayEwDQYJKoZIhvcNAQELBQAwbzELMAkGA1UEBhMCU0Ux FDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBUVFAgTmV0 d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0xNDEyMjIwMDAwMDBa Fw0yMDA1MzAxMDQ4MzhaMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVz dGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UE AxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwg Q0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCJsQ3aelMZTnBSHbxWpgYmt7hJ4Jbn Uavx8FoTSRWjtIwbYLx6UUKneYykIt8XYU6R1XYjChTTSgJ/th0JgG6lBD3ZursW/qGHqS5DUkMW fK8yUMimT1rpCNjPkyWce4joMGTmpPhWgP0qJBQzF5msROVpi6NGBkvCM9TpQJ8GsLGsk0C5tQiT OpwqU6MQ2z0gYTxVA47ZTnYlAiEp+qN8cXZP7uFfgen7VIDbw3s1UreE3iI9LDAtMX9ZvVI3sDNp LUPr+tal8Zd3Z1GM2e4n67ylBzh2jKSpOP/fjPUDrEm+yvdzmToPMquclToTPQ5GOld0YVC+xkA/ y+Tin6IhAgMBAAGjggEXMIIBEzAfBgNVHSMEGDAWgBStvZh6NLQm9/rEJlTvA73gJMtUGjAdBgNV HQ4EFgQUkmFrguGioKpP7GfxwqP3tIAAwewwDgYDVR0PAQH/BAQDAgGGMBIGA1UdEwEB/wQIMAYB Af8CAQAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMBEGA1UdIAQKMAgwBgYEVR0gADBE BgNVHR8EPTA7MDmgN6A1hjNodHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vQWRkVHJ1c3RFeHRlcm5h bENBUm9vdC5jcmwwNQYIKwYBBQUHAQEEKTAnMCUGCCsGAQUFBzABhhlodHRwOi8vb2NzcC51c2Vy dHJ1c3QuY29tMA0GCSqGSIb3DQEBCwUAA4IBAQAbKm6sVcE6q4jF2O3NVfOqa2ErwAkQI5kPxWZq b7H1tLV3Xg8CYQDffQX+ErOkgIAA/PsdW2pyAgpBvAW6wVjVJsLq1U2E+/6CmM9YG+MiY5xS+LsF Nqt9WKXeqztj5drVc+/s4Pt74qP/8EIjnMq2jU0+5EsYA7KoLdTYu0JLkGmFENumNzToe+ABEKWc yjrHn0+ING6KZdAairup3MrKNtH0/MJkKTWv1rGncRHSA0Oxjz6a7J4yU/R2ksqGNAe5LMrmHErY mQ3BhuKQkvtaQmojIRDpZcf11bt+6oyFIAJi6tE6ByxZxZkz8jiJ5bbpFnofeRT2ShAaJvp8ivub MIIFPDCCBCSgAwIBAgIRAImdrrrSrE1TMdXIyvE0qYEwDQYJKoZIhvcNAQELBQAwgZsxCzAJBgNV BAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAY BgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQg QXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xNTAyMDMwMDAwMDBaFw0xNjAy MDMyMzU5NTlaMCMxITAfBgkqhkiG9w0BCQEWEnB0aHViZXJ0QGNpc2NvLmNvbTCCASIwDQYJKoZI hvcNAQEBBQADggEPADCCAQoCggEBALTqoFHH36vHzOLhXp5Wv28HBpYWouQolX/OzHVrZbIEblHp NAxFdrnNSWULDP5gT8hp/t4P0XO3YEnaQxpPUu0wWFlLrDC690s0y3T0hATowmfycNcLX+hddBDL 8ChyZdJAVhxl0vnxORmcciJmXmWOJ+4lzEqaDbm5lZUHgi3kc0t9/IFOOJ6yq1kjttHu1MFPZZUc lUnlpXmD+2/GzxeCHlQgLvw232No6lrAS34PQxbu7rnfw25Spd3CFP7RymWZnNL26rIvt3J4rpv8 xy0EedfU3AUo5scNpr7Mb1npOgVU7N+K07atmjh71wpvfnpvwIxPA+OOHcXwOS5JsosCAwEAAaOC AfAwggHsMB8GA1UdIwQYMBaAFJJha4LhoqCqT+xn8cKj97SAAMHsMB0GA1UdDgQWBBS2xFsxMSdl ViqpYN1OZcdW6Bg4OTAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggr BgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYB BAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMF0G A1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET1NIQTI1NkNsaWVu dEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgZAGCCsGAQUFBwEBBIGDMIGAMFgG CCsGAQUFBzAChkxodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9TSEEyNTZDbGllbnRBdXRo ZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5j b21vZG9jYS5jb20wHQYDVR0RBBYwFIEScHRodWJlcnRAY2lzY28uY29tMA0GCSqGSIb3DQEBCwUA A4IBAQABMkoJZJ5HHnG3Sl0jOpl8Emhb5fjpyW2eK26Zy8e62uqUL7ExSBChD97N1lCYUFY4TqIR zCmaObFC+fDgG3IDQ7ZOJDVu6ZK8TAGiBF6sSYcg5rSfIKPxJUQvTciSrTE+XHEVONmU6xQrMIYY 4/T4iho50oQmNpTSNmGc19ZZ9mQtbRGsjdwILm5NvIyI3X088GidfVJqifQ9dRmSikzELdvlmdBs TFdAM1zx3CscylrUPQyy3lrLuvWf9arpPHV7sex+cwkLKOGHl26mXMoOPwvEYcpJJ3phmR/aqxbC mZwz4LugVrqvC0sFERLSjfarSBQxKL7XSxxS6JYEL3LpMYIEdDCCBHACAQEwgbEwgZsxCzAJBgNV BAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAY BgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQg QXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAImdrrrSrE1TMdXIyvE0qYEwCQYF Kw4DAhoFAKCCApcwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTUw MzE3MDc1NDI1WjAjBgkqhkiG9w0BCQQxFgQUA+cJpRNtXE2/5o9orJd1SEyeH8kwgasGCSqGSIb3 DQEJDzGBnTCBmjALBglghkgBZQMEASowCwYJYIZIAWUDBAEWMAoGCCqGSIb3DQMHMAsGCWCGSAFl AwQBAjAOBggqhkiG9w0DAgICAIAwBwYFKw4DAgcwDQYIKoZIhvcNAwICAUAwDQYIKoZIhvcNAwIC ASgwBwYFKw4DAhowCwYJYIZIAWUDBAIDMAsGCWCGSAFlAwQCAjALBglghkgBZQMEAgEwgcIGCSsG AQQBgjcQBDGBtDCBsTCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3Rl cjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMT OENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENB AhEAiZ2uutKsTVMx1cjK8TSpgTCBxAYLKoZIhvcNAQkQAgsxgbSggbEwgZsxCzAJBgNVBAYTAkdC MRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoT EUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAImdrrrSrE1TMdXIyvE0qYEwDQYJKoZIhvcN AQEBBQAEggEADewTqPeS29s7YGnzwt6Il82IlVKtqk0l3HICuoplQhXIhaINzy7KlGDwgMRVHQuQ suHKQeZwnwqH1YTe+FO1W1rOxPygTRBicOvdkI4us38/k8iAPP/1ustPPFEmeVmDt8BCFyCPtJK0 FDg+32xPHn6Pxv1F1dF6ffa4vR24jvU4emx5B8et1dBGabFRUkByoRiX//anFZ7Qlm7XfuE8SSEy RExgJYkdUTRIn1KNVmt5lX79Yhpay69OfftmVkX4UC1CIOSggNuTY9IqaDdPEWv+Fx5NMb0q0vQk 9Q4IpK13xCuDRv/PUhKN7CUhgkNiu9BL1VfW6N4AARFcXwnI+AAAAAAAAA== ------=_NextPart_000_0016_01D0608F.F7F3BC40-- From nobody Mon Mar 23 07:03:44 2015 Return-Path: X-Original-To: detnet@ietfa.amsl.com Delivered-To: detnet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FFA41A8AB0 for ; Mon, 23 Mar 2015 07:03:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 dIkAkwVvL1gS for ; Mon, 23 Mar 2015 07:03:40 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD9A91A8AB2 for ; Mon, 23 Mar 2015 07:03:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9483; q=dns/txt; s=iport; t=1427119401; x=1428329001; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=jTjIPq8lQkxkCZ5Runktzwi6Zoelup9jdvEShok+FjU=; b=MZqr6cWCQk5OvniihWoUfad1rcxRS3TvyaIzihjBKDY0tWP0CjCb1yic Jb2mbHRkji/VxOXBVe6ravYathph4wVtl9JVNek0TB5zuS0K7gkvuDBVf TYV4B617vqYBUxZHb5fEpKV41HHWuJWIc57KVC+aAQLS3BKCQ9BWdhTiT A=; X-Files: smime.p7s : 4831 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0C1BgDkHBBV/5ldJa1cgwZSWgTED4IwCoV1AoEmTAEBAQEBAX2EFQEBBAEBAUs7AgEIEgIOAiICJQoBFwQBBgMCBBMIBgYHAgSIDg3IOwEBAQEBAQEBAQEBAQEBAQEBAQEBARMEiyGBPYJlIiAYgxeBFgWQT4FpgTJUhgCUKSKCAhwUgTxvAYEKOX8BAQE X-IronPort-AV: E=Sophos;i="5.11,452,1422921600"; d="p7s'?scan'208";a="134576595" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-4.cisco.com with ESMTP; 23 Mar 2015 14:03:21 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t2NE3KTV019127 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 23 Mar 2015 14:03:20 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.225]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.03.0195.001; Mon, 23 Mar 2015 09:03:20 -0500 From: "Pascal Thubert (pthubert)" To: "detnet@ietf.org" Thread-Topic: RFC 7491 on A PCE-Based Architecture for Application-Based Network Operations Thread-Index: AQHQZL4V4MsAR95nA0OYw7ig11IPVp0p+xLg Date: Mon, 23 Mar 2015 14:03:19 +0000 Deferred-Delivery: Mon, 23 Mar 2015 12:11:00 +0000 Message-ID: References: <20150322163235.4CED3180092@rfc-editor.org> In-Reply-To: <20150322163235.4CED3180092@rfc-editor.org> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.82.250.172] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_004F_01D06530.0361A1B0" MIME-Version: 1.0 Archived-At: Subject: [Detnet] FW: RFC 7491 on A PCE-Based Architecture for Application-Based Network Operations X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussions on Deterministic Networking, characterized by 1\) resource reservation; 2\) 0 congestion loss and guaranteed latency; 3\) over L2-only and mixed L2 and L3 networks; and 5\) 1+1 replication/deletion." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 14:03:42 -0000 ------=_NextPart_000_004F_01D06530.0361A1B0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit A new Request for Comments is now available in online RFC libraries. RFC 7491 Title: A PCE-Based Architecture for Application-Based Network Operations Author: D. King, A. Farrel Status: Informational Stream: IETF Date: March 2015 Mailbox: daniel@olddog.co.uk, adrian@olddog.co.uk Pages: 71 Characters: 163636 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-farrkingel-pce-abno-architecture-16.txt URL: https://www.rfc-editor.org/info/rfc7491 Services such as content distribution, distributed databases, or inter-data center connectivity place a set of new requirements on the operation of networks. They need on-demand and application-specific reservation of network connectivity, reliability, and resources (such as bandwidth) in a variety of network applications (such as point-to-point connectivity, network virtualization, or mobile back-haul) and in a range of network technologies from packet (IP/MPLS) down to optical. An environment that operates to meet these types of requirements is said to have Application-Based Network Operations (ABNO). ABNO brings together many existing technologies and may be seen as the use of a toolbox of existing components enhanced with a few new elements. This document describes an architecture and framework for ABNO, showing how these components fit together. It provides a cookbook of existing technologies to satisfy the architecture and meet the needs of the applications. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC ------=_NextPart_000_004F_01D06530.0361A1B0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOLTCCBDYw ggMeoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwbzELMAkGA1UEBhMCU0UxFDASBgNVBAoTC0FkZFRy dXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBUVFAgTmV0d29yazEiMCAGA1UEAxMZ QWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0wMDA1MzAxMDQ4MzhaFw0yMDA1MzAxMDQ4Mzha MG8xCzAJBgNVBAYTAlNFMRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQGA1UECxMdQWRkVHJ1c3Qg RXh0ZXJuYWwgVFRQIE5ldHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0IEV4dGVybmFsIENBIFJvb3Qw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC39xoz5vIABC054E5b7R+8bA/Ntfojts7e mxEzl6QpTH2Tn71KvJPtAxrjj8/lbVBa1pcplFqAsEl62y6V/bjKvzc4LR4+kUGtcFbH8E8/6DKe dMrIkFTpxl8PeJ2aQDwOrGGqXhSPnoehalDc15pOrwWzpnGUnHGzUGAKxxOdOAeGAqjpqGkmGJCr TLBPI6s6T4TY386f4Wlvu9dC12tE5Met7m1BX3JacQg3s3llpFmglDf3AC8NwpJy2tA4ctsUqEXE XSp9t7TWxO6szRNEt8kr3UMAJfphuWlqWCMRt6czj1Z1WfXNKddGtworZbbTQm8Vsrh7++/pXVPV NFonAgMBAAGjgdwwgdkwHQYDVR0OBBYEFK29mHo0tCb3+sQmVO8DveAky1QaMAsGA1UdDwQEAwIB BjAPBgNVHRMBAf8EBTADAQH/MIGZBgNVHSMEgZEwgY6AFK29mHo0tCb3+sQmVO8DveAky1QaoXOk cTBvMQswCQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0 IEV4dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290 ggEBMA0GCSqGSIb3DQEBBQUAA4IBAQCwm+CFJcLWI+IPlgaSnUGYnNmEeYHZHlsUByM2ZY+w2He7 rEFsR2CDUbD5Mj3n/PYmE8eAFqW/WvyHz3h5iSGa4kwHCoY1vPLeUcTSlrfcfk7ucP0cOesMAlEU LY69FuDB30Z15ySt7PRCtIWTcBBnup0GNUoY0yt6zFFCoXpj0ea7ocUrwja+Ew3mvWN+eXunCQ1A q2rdj4rD9vaMGkIFUdRF9Z+nYiFoFSBDPJnnfL0k2KmRF3OIP1YbMTgYtHEPms3IDp6OLhvhjJiD yx8x8URMxgRzSXZgD8f4vReAay7pzEwOWpp5DyAKLtWeYyYeVZKU2IIXWnvQvMePToYEMIIErzCC A5egAwIBAgIRAOAjyxUSg1OJrWFuelRnayEwDQYJKoZIhvcNAQELBQAwbzELMAkGA1UEBhMCU0Ux FDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBUVFAgTmV0 d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0xNDEyMjIwMDAwMDBa Fw0yMDA1MzAxMDQ4MzhaMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVz dGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UE AxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwg Q0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCJsQ3aelMZTnBSHbxWpgYmt7hJ4Jbn Uavx8FoTSRWjtIwbYLx6UUKneYykIt8XYU6R1XYjChTTSgJ/th0JgG6lBD3ZursW/qGHqS5DUkMW fK8yUMimT1rpCNjPkyWce4joMGTmpPhWgP0qJBQzF5msROVpi6NGBkvCM9TpQJ8GsLGsk0C5tQiT OpwqU6MQ2z0gYTxVA47ZTnYlAiEp+qN8cXZP7uFfgen7VIDbw3s1UreE3iI9LDAtMX9ZvVI3sDNp LUPr+tal8Zd3Z1GM2e4n67ylBzh2jKSpOP/fjPUDrEm+yvdzmToPMquclToTPQ5GOld0YVC+xkA/ y+Tin6IhAgMBAAGjggEXMIIBEzAfBgNVHSMEGDAWgBStvZh6NLQm9/rEJlTvA73gJMtUGjAdBgNV HQ4EFgQUkmFrguGioKpP7GfxwqP3tIAAwewwDgYDVR0PAQH/BAQDAgGGMBIGA1UdEwEB/wQIMAYB Af8CAQAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMBEGA1UdIAQKMAgwBgYEVR0gADBE BgNVHR8EPTA7MDmgN6A1hjNodHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vQWRkVHJ1c3RFeHRlcm5h bENBUm9vdC5jcmwwNQYIKwYBBQUHAQEEKTAnMCUGCCsGAQUFBzABhhlodHRwOi8vb2NzcC51c2Vy dHJ1c3QuY29tMA0GCSqGSIb3DQEBCwUAA4IBAQAbKm6sVcE6q4jF2O3NVfOqa2ErwAkQI5kPxWZq b7H1tLV3Xg8CYQDffQX+ErOkgIAA/PsdW2pyAgpBvAW6wVjVJsLq1U2E+/6CmM9YG+MiY5xS+LsF Nqt9WKXeqztj5drVc+/s4Pt74qP/8EIjnMq2jU0+5EsYA7KoLdTYu0JLkGmFENumNzToe+ABEKWc yjrHn0+ING6KZdAairup3MrKNtH0/MJkKTWv1rGncRHSA0Oxjz6a7J4yU/R2ksqGNAe5LMrmHErY mQ3BhuKQkvtaQmojIRDpZcf11bt+6oyFIAJi6tE6ByxZxZkz8jiJ5bbpFnofeRT2ShAaJvp8ivub MIIFPDCCBCSgAwIBAgIRAImdrrrSrE1TMdXIyvE0qYEwDQYJKoZIhvcNAQELBQAwgZsxCzAJBgNV BAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAY BgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQg QXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xNTAyMDMwMDAwMDBaFw0xNjAy MDMyMzU5NTlaMCMxITAfBgkqhkiG9w0BCQEWEnB0aHViZXJ0QGNpc2NvLmNvbTCCASIwDQYJKoZI hvcNAQEBBQADggEPADCCAQoCggEBALTqoFHH36vHzOLhXp5Wv28HBpYWouQolX/OzHVrZbIEblHp NAxFdrnNSWULDP5gT8hp/t4P0XO3YEnaQxpPUu0wWFlLrDC690s0y3T0hATowmfycNcLX+hddBDL 8ChyZdJAVhxl0vnxORmcciJmXmWOJ+4lzEqaDbm5lZUHgi3kc0t9/IFOOJ6yq1kjttHu1MFPZZUc lUnlpXmD+2/GzxeCHlQgLvw232No6lrAS34PQxbu7rnfw25Spd3CFP7RymWZnNL26rIvt3J4rpv8 xy0EedfU3AUo5scNpr7Mb1npOgVU7N+K07atmjh71wpvfnpvwIxPA+OOHcXwOS5JsosCAwEAAaOC AfAwggHsMB8GA1UdIwQYMBaAFJJha4LhoqCqT+xn8cKj97SAAMHsMB0GA1UdDgQWBBS2xFsxMSdl ViqpYN1OZcdW6Bg4OTAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggr BgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYB BAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMF0G A1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET1NIQTI1NkNsaWVu dEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgZAGCCsGAQUFBwEBBIGDMIGAMFgG CCsGAQUFBzAChkxodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9TSEEyNTZDbGllbnRBdXRo ZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5j b21vZG9jYS5jb20wHQYDVR0RBBYwFIEScHRodWJlcnRAY2lzY28uY29tMA0GCSqGSIb3DQEBCwUA A4IBAQABMkoJZJ5HHnG3Sl0jOpl8Emhb5fjpyW2eK26Zy8e62uqUL7ExSBChD97N1lCYUFY4TqIR zCmaObFC+fDgG3IDQ7ZOJDVu6ZK8TAGiBF6sSYcg5rSfIKPxJUQvTciSrTE+XHEVONmU6xQrMIYY 4/T4iho50oQmNpTSNmGc19ZZ9mQtbRGsjdwILm5NvIyI3X088GidfVJqifQ9dRmSikzELdvlmdBs TFdAM1zx3CscylrUPQyy3lrLuvWf9arpPHV7sex+cwkLKOGHl26mXMoOPwvEYcpJJ3phmR/aqxbC mZwz4LugVrqvC0sFERLSjfarSBQxKL7XSxxS6JYEL3LpMYIEdDCCBHACAQEwgbEwgZsxCzAJBgNV BAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAY BgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQg QXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAImdrrrSrE1TMdXIyvE0qYEwCQYF Kw4DAhoFAKCCApcwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTUw MzIzMTIxMDA4WjAjBgkqhkiG9w0BCQQxFgQUXdS/qsfXANZ8x5nJ2eMs/PpjZ4kwgasGCSqGSIb3 DQEJDzGBnTCBmjALBglghkgBZQMEASowCwYJYIZIAWUDBAEWMAoGCCqGSIb3DQMHMAsGCWCGSAFl AwQBAjAOBggqhkiG9w0DAgICAIAwBwYFKw4DAgcwDQYIKoZIhvcNAwICAUAwDQYIKoZIhvcNAwIC ASgwBwYFKw4DAhowCwYJYIZIAWUDBAIDMAsGCWCGSAFlAwQCAjALBglghkgBZQMEAgEwgcIGCSsG AQQBgjcQBDGBtDCBsTCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3Rl cjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMT OENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENB AhEAiZ2uutKsTVMx1cjK8TSpgTCBxAYLKoZIhvcNAQkQAgsxgbSggbEwgZsxCzAJBgNVBAYTAkdC MRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoT EUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAImdrrrSrE1TMdXIyvE0qYEwDQYJKoZIhvcN AQEBBQAEggEANshy5mk9MXvdR6RkEK3yoz6vPGImtfgPf/JxY4fV6hOQLlPaCpGtx4+lh53TMpR/ bkn3Q34qEzgSX5LjwFcnxeHnS7WbxZNOG+Urf44zLLSHd3Y6YYkRjxJ71PcivptN6svXHAFvVVgj t0gybCrg5rd0d1TB8krryfU6WFM5FNAO/LtZusyyUByysXW10AMegseDldGopQNgokTY/3Tr4uZ5 3BIvYcU9T2DayglXUHDeckfG5ts1Y8V3kJEH6OweB3K6z/hGGlubdjgWtSvuTbc1EMFTV0A/LI7V igmzquZZFTdb+0iGsMnI5iOlkEKxPd2OitiE0JBaavdEqjn4CAAAAAAAAA== ------=_NextPart_000_004F_01D06530.0361A1B0-- From nobody Mon Mar 23 09:45:08 2015 Return-Path: X-Original-To: detnet@ietfa.amsl.com Delivered-To: detnet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC6C11ACD7B; Mon, 23 Mar 2015 09:45:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.622 X-Spam-Level: X-Spam-Status: No, score=0.622 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 qzccEz545dfC; Mon, 23 Mar 2015 09:44:51 -0700 (PDT) Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C41511ACD81; Mon, 23 Mar 2015 09:44:49 -0700 (PDT) Received: by wibdy8 with SMTP id dy8so52642895wib.0; Mon, 23 Mar 2015 09:44:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:from:date:message-id:subject:to:content-type; bh=HxdHScOHUMThr8yjL/G6tOiVr1fwGZDptJNFmV/U1PQ=; b=Hab3nwMxHz94A1Ja+VmosDhgb5UgonZZy25rYEr4LqUFezfmXNTaTXqhi/ajJTZU58 aBlTbp635+3A3TXo6twAtpGc/xuqL/L8Aqgq9zmx4a6zfjmklro/fezqRE6acMe6Cm9n bOpHCCqWoCtByqY0lfXLIZZEV7ob4Sj6IrUadGfR3kn2PxM2cD0wdKR3TfqjDJMYG705 J8Iv5vY0ltXpwd6Tn+LNh+QgqLIF4xo8A9dKlgHGXe/ijqxbXBDYDNJfLoBGrQSIQXxm rWUFZhLnXEdQu9qDNmGjtxBWxuLTpKPdpjrp1h8LuZjZpO0+YUowci3f7wwTHJH4LAtB BX1w== X-Received: by 10.194.92.97 with SMTP id cl1mr19747258wjb.133.1427129088397; Mon, 23 Mar 2015 09:44:48 -0700 (PDT) MIME-Version: 1.0 Sender: twatteyne@gmail.com Received: by 10.28.157.206 with HTTP; Mon, 23 Mar 2015 09:44:28 -0700 (PDT) From: Thomas Watteyne Date: Mon, 23 Mar 2015 11:44:28 -0500 X-Google-Sender-Auth: xhzxcH8R8aNBgax1fgb19ErOZmg Message-ID: To: "detnet@ietf.org" , "6tisch@ietf.org" <6tisch@ietf.org> Content-Type: multipart/alternative; boundary=047d7bfd062a5cd7e60511f762e2 Archived-At: Subject: [Detnet] comments on draft-finn-detnet-architecture-00 X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussions on Deterministic Networking, characterized by 1\) resource reservation; 2\) 0 congestion loss and guaranteed latency; 3\) over L2-only and mixed L2 and L3 networks; and 5\) 1+1 replication/deletion." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 16:45:06 -0000 --047d7bfd062a5cd7e60511f762e2 Content-Type: text/plain; charset=UTF-8 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. Finn Internet-Draft P. Thubert Intended status: Standards Track Cisco Expires: September 10, 2015 March 9, 2015 Deterministic Networking Architecture draft-finn-detnet-architecture-00 Abstract Deterministic Networking (DetNet) provides a capability to carry specified unicast or multicast data streams for real-time applications 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 for individual (or aggregated) DetNet streams in some or all of the relay systems (bridges or routers) along the path of the stream; 2) providing fixed paths for DetNet streams that do not rapidly change with the network topology; and 3) sequentializing, replicating, and eliminating duplicate packets at various points to ensure the availability of at least one path. The capabilities can be managed by configuration, or by manual or automatic network management. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months 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." This Internet-Draft will expire on September 10, 2015. Copyright Notice Copyright (c) 2015 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 Finn & Thubert Expires September 10, 2015 [Page 1] Internet-Draft Deterministic Networking Architecture March 2015 publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Providing the DetNet Quality of Service . . . . . . . . . . . 5 3.1. Zero Congestion Loss . . . . . . . . . . . . . . . . . . 6 3.2. Pinned-down paths . . . . . . . . . . . . . . . . . . . . 7 3.3. Seamless Redundancy . . . . . . . . . . . . . . . . . . . 7 4. DetNet Architecture . . . . . . . . . . . . . . . . . . . . . 8 4.1. The Application Plane . . . . . . . . . . . . . . . . . . 11 4.2. The Controller Plane . . . . . . . . . . . . . . . . . . 11 4.3. The Network Plane . . . . . . . . . . . . . . . . . . . . 12 4.4. Elements of DetNet Architecture . . . . . . . . . . . . . 13 4.5. DetNet streams . . . . . . . . . . . . . . . . . . . . . 14 4.5.1. Talker guarantees . . . . . . . . . . . . . . . . . . 14 4.5.2. Incomplete Networks . . . . . . . . . . . . . . . . . 15 4.6. Data Flow Model through Systems . . . . . . . . . . . . . 16 4.7. Queuing, Shaping, Scheduling, and Preemption . . . . . . 16 4.8. Coexistence with normal traffic . . . . . . . . . . . . . 16 4.9. Fault Mitigation . . . . . . . . . . . . . . . . . . . . 16 4.10. Protocol Stack Model . . . . . . . . . . . . . . . . . . 17 4.11. Advertising resources, capabilities and adjacencies . . . 17 4.12. Provisioning model . . . . . . . . . . . . . . . . . . . 17 4.12.1. Centralized Path Computation and Installation . . . 17 4.12.2. Distributed Path Setup . . . . . . . . . . . . . . . 17 5. Related IETF work . . . . . . . . . . . . . . . . . . . . . . 18 5.1. Deterministic PHB . . . . . . . . . . . . . . . . . . . . 18 5.2. 6TiSCH . . . . . . . . . . . . . . . . . . . . . . . . . 18 6. Security Considerations . . . . . . . . . . . . . . . . . . . 19 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 9. Informative References . . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 1. Introduction Operational Technology (OT) refers to industrial networks that are typically 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., discrete manufacturing). 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 use focusing on highly secure, reliable and deterministic networks, with limited scalability over a bounded area. The convergence of IT and OT technologies, also called the Industrial Internet, represents a major evolution for both sides. The work has already started; in particular, the industrial automation space has been developing a number of Ethernet-based replacements for existing digital control systems, often not packet-based (fieldbus technologies). These replacements are meant to provide similar behavior as the incumbent protocols, and their common focus is to transport TW> "on transporting"? a fully characterized flow over a well-controlled environment (i.e., a factory floor), with a bounded latency, extraordinarily low frame loss, and a very narrow jitter. Examples of such protocols include PROFINET, 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 help In 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 for connectivity and multimedia in transportation in general, the Ethernet AVB technology has become one of the hottest topics, in particular in the automotive connectivity. It is finding application in all elements of the vehicle TW> ":" from head units, to rear seat entertainment modules, to amplifiers and camera modules. While aimed at less critical applications than some industrial networks, AVB networks share the requirement for extremely low packet loss rates and ensured finite latency and jitter. TW> ensure -> guarantee? Other instances of in-vehicle deterministic networks have arisen as well for control networks in cars, trains and buses, as well as avionics, with, for instance, the mission-critical "Avionics Full- Duplex Switched Ethernet" (AFDX) that was designed as part of the ARINC 664 standards. Existing automotive control networks such as the LIN, CAN and TW> would TTP/C fit in this list? FlexRay standards were not designed to cover these increasing demands in terms of bandwidth and scalability that we see with various kinds of Driver Assistance Systems (DAS) and new multiplexing technologies based on Ethernet are now getting traction. The generalization of the needs for more deterministic networks have led to the IEEE 802.1 AVB Task Group becoming the Time-Sensitive Networking (TSN) Task Group (TG), with a much-expanded constituency from the industrial and vehicular markets. Along with this expansion, the networks in consideration are becoming larger and structured, requiring deterministic forwarding beyond the LAN boundaries. For instance, Industrial Automation segregates the network 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, and public infrastructures such as Electricity Automation require deterministic properties over the Wide Area. The realization is now coming 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 IETF and the IEEE and implements an abstract model that can be applicable both at Layer-2 and Layer-3, and along segments of different technologie. TW> typo With 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 be operating at Layer-2 over Ethernet whereas the IP routers may be 6TiSCH nodes operating at Layer-2 and/or Layer-3 over the IEEE 802.15.4e MAC. Many applications of interest to Deterministic Networking require the ability to synchronize the clocks in end systems to a sub-microsecond accuracy. TW> why this accuracy? Some of the queue control techniques defined in Section 4.7 also require time synchronization among relay systems. The means used to achieve time synchronization are not addressed in this document. 2. Terminology The follwing TW> typo special terms are used in this document in order to avoid the assumption that a given element in the archetecture TW> typo does or does not have Internet Protocol stack, functions as a router or a bridge, or otherwise plays a particular role at Layer-3 or higher: TW> I don't get the sentence above bridge A Customer Bridge as defined by IEEE 802.1Q [IEEE802.1Q-2011]. circuit A trail of configuration from talker to listener(s) TW> sender and receiver might be more common at the IETF? through relay systems associated with a DetNet stream, required to deliver the benefits of DetNet. end system Commonly called a "host" in IETF documents, and an "end station" is IEEE 802 documents. End systems of interest to this document are talkers and listeners. listener An 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? stream A DetNet stream is a sequence of packets from a single talker, through some number of relay systems to one or more listeners, that is limited by the talker in its maximum packet size and transmission rate, and can thus be ensured the DetNet Quality of Service (QoS) from the network. talker An 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 of the relay systems and links; o Probability of loss of a packet in the event of the failure of a relay 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, or typical values are of no interest, because they do not affect the ability of a real-time system to perform its tasks. TW> Would it make sense to discuss hard and soft real-time here, in TW> particular in the context of a wireless system? Three techniques are employed by DetNet to achieve these QoS parameters: a. Zero congestion loss (Section 3.1). Network resources such as link bandwidth, buffers, queues, shapers, and scheduled input/ TW> add 6TiSCH cells? output slots are assigned in each relay system to the use of a specific DetNet stream or group of streams. Note that, given a finite amount of buffer space) TW> extra ")" , zero congestion loss necessarily ensures a maximum end-to-end latency. Depending on the method employed, 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 or more listeners can be established, and DetNet streams assigned to follow a particular path or tree. TW> Using a single path in a wireless system will fail, I would recommend TW> 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 eliminate replicated 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 at least one path intact for a DetNet stream. These three techniques can be applied independently, giving eight possible combinations, including none (no DetNet), although some combinations are of wider utility than others. This separation keeps the protocol stack coherent and maximizes interoperability with existing and developing standards in this (IETF) and other Standards Development Organizations. Some examples of typical expected combinations: o Pinned-down paths (a) plus packet replication (b) are exactly the techniques employed by [HSR-PRP]. Pinned-down paths are achieve by limiting the physical topology of the network, and the sequentialization, replication, and duplicate elimination facilitated by packet tags added at the front or the end of Ethernet frames. o Zero congestion loss (a) alone is is offered by IEEE 802.1 Audio Video bridging [IEEE802.1BA-2011]. As long as the network suffers no failures, near-zero (at best, zero) congestion loss can be achieved through the use of a reservation protocol (MSRP) and shapers 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 satisfactory for many applications. However, these methods generally work best in the absence of any significant amount of non-critical traffic in the network (if, indeed, such traffic is supported at all), or work only if the critical traffic constitutes only a small portion of the network's theoretical capacity, or work only if all systems are functioning properly, or in the absence of actions by end systems that disrupt the network's operations. There are any number of methods in use, defined, or in progress for accomplishing each of the above techniques. It is expected that this DetNet Architecture will assist various vendors, users, and/or "vertical" Standards Development Organizations (dedicated to a single industry) to make selections among the available means of implementing DetNet networks. 3.1. Zero Congestion Loss The primary means by which DetNet achieves its QoS assurances is to completely eliminate congestion at an output port as a cause of packet 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 at each hop through the network to ensure that no packets are dropped due to a lack of buffer storage. TW> and the provision the sufficient link bandwidth? Ensuring adequate buffering requires, in turn, that the talker, and every relay system along the path to the listener (or nearly every relay system -- see Section 4.5.2) be careful to regulate its output to not exceed the data rate for any stream, except for brief perios TW> typo when making up for interfering traffic. Any packet sent ahead of its time potentially adds to the number of buffers required by the next hop, and may thus exceed the resources allocated for a particular stream. The low-level mechanisms described in Section 4.7 provide the necessary regulation of transmissions by an edge system or relay system to ensure zero congestion loss. Of course, the reservation of the bandwidth and buffers for a stream requires the provisioning described in Section 4.12. 3.2. Pinned-down paths In networks controlled by typical peer-to-peer protocols such as IEEE 802.1 ISIS bridged networks or ETF OSPF routed networks, a network topology event in one part of the network can impact, at least briefly, the delivery of data in parts of the network remote from the failure or recovery event. Thus, even redundant paths through a network, if controlled by the typical peer-to-peer protocols, do not eliminate 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 minimizes recovery time and easily supports redundant paths. Of course, this comes at the cost of increased hop count, and thus latency, for the typical path. In order to get the advantages of low hop count and still ensure against even brief losses of connectivity, DetNet employs pinned-down paths, where the path taken by a given DetNet stream does not change, at least immediately, and likely not at all, in response to network topology events. When combined with seamless redundancy (Section 3.3), this results in a high likelihood of continuous connectivity. 3.3. Seamless Redundancy After congestion loss has been eliminated, the most important causes of packet loss are random media and/or memory faults and equipment failures. 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 at least two different paths to the listener(s). o Discarding duplicated packets. In the simplest case, this amounts to replicating each packet in a talker that has two interfaces, and conveying them through the network, along separate paths, to the similarly dual-homed listeners, that discard the extras. This ensures that one path (with zero congestion loss) remains, even if some relay system fails. TW> this has some energy cost associated? Alternatively, relay systems in the network can provide replication and elimination facilities at various points in the network, so that multiple failures can be accommodated. This is shown in the following figure, where the two relay systems each replicate (R) the DetNet stream on input, sending the stream to both the other relay system and to the end system, and eliminated duplicates (E) on the output interface to the right-hand end system. Any one links TW> typo in the network can fail, and the Detnet stream can still get through. Furthermore, two links can fail, as long as they are in different segments of the network. > > > > > > > > relay > > > > > > > > > /------------+ R system E +------------\ > > / v + ^ \ > end R + v | ^ + E end system + v | ^ + system > \ v + ^ / > > \------------+ R relay E +------------/ > > > > > > > > > system > > > > > > > > Figure 1 TW> I don't understand what R and E means 4. DetNet Architecture Traffic Engineering Architecture and Signaling (TEAS) [TEAS] defines traffic-engineering architectures for generic applicability across packet and non-packet networks. From TEAS perspective, Traffic Engineering (TE) refers to techniques that enable operators to control how specific traffic flows are treated within their networks. Because if its very nature of establishing pinned-down optimized paths, 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 a separation into planes. The Deterministic Networking architecture is thus composed of three planes, a (User) Application Plane, a Controller Plane, and a Network Plane, which echoes that of Software-Defined Networking (SDN): TW> double ":" Layers and 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 and services. In particular, the Application Plane incorporates the User Agent, a specialized application that interacts with the end user / operator and performs requests for Deterministic Networking services via an abstract Stream Management Entity, (SME) which may or may not be collocated with (one of) the end systems. At the Application Plane, a management interface enables the negotiation of streams between end systems. An abstraction of the stream called a Traffic Specification (TSpec) provides the representation. This abstraction is used to place a reservation over the (Northbound) Service Interface and within the Application plane. It is associated with an abstraction of location, such as IP addresses and DNS names, to identify the end systems and eventually specify intermediate relay systems. 4.2. The Controller Plane The Controller Plane corresponds to the aggregation of the Control and Management Planes in [RFC7426], though Common Control and Measurement Plane (CCAMP) [CCAMP] makes an additional distinction between management and measurement. When the logical separation of the Control, Measurement and other Management entities is not relevant, the term Controller Plane is used for simplicity to represent them all, and the term controller refers to any device operating in that plane, whether is it a Path Computation entity or a Network Management entity (NME). The Path Computation Element (PCE) [PCE] is a core element of a controller, in charge of computing Deterministic paths to be applied in the Network Plane. A (Northbound) Service Interface enables applications in the Application Plane to communicate with the entities in the Controller Plane. TW> could you define NME, SME and PCE in the terminology? One or more PCE(s) collaborate to implement the requests from the SME as Per-Stream Per-Hop Behaviors installed in the relay systems for each individual streams. The PCEs place each stream along a deterministic sequence of relay systems so as to respect per-stream constraints such as security and latency, and optimize the overall result for metrics such as an abstract aggregated cost. The deterministic sequence can typically be more complex than a direct sequence and include redundancy path, with one or more packet replication 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 a whole, regardless of the Layer at which the network devices operate. The network Plane comprises the Network Interface Cards (NIC) in the end systems, which are typically IP hosts, and relay systems, which are typically IP routers and switches. Network-to-Network Interfaces such as used for Traffic Engineering path reservation in [RFC3209], as well as User-to-Network Interfaces (UNI) such as provided by the Local Management Interface (LMI) between network and end systems, are all part of the Network Plane. A Southbound (Network) Interface enables the entities in the Controller Plane to communicate with devices in the Network Plane. This interface leverages and extends TEAS to describe the physical topology and resources in the Network Plane. Stream Management Entity End End System System -+-+-+-+-+-+-+ Northbound -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- PCE PCE PCE PCE -+-+-+-+-+-+-+ Southbound -+-+-+-+-+-+-+-+-+-+--+-+-+-+-+-+- Relay Relay Relay Relay System System System System NIC NIC Relay Relay Relay Relay System System System System Figure 3 The relay systems (and eventually the end systems NIC) expose their capabilities and physical resources to the controller (the PCE), and update the PCE with their dynamic perception of the topology, across the Southbound Interface. In return, the PCE(s) set the per-stream paths up, providing a Stream Characterization that is more tightly coupled to the relay system Operation than a TSpec. At the Network plane, relay systems exchange information regarding the state of the paths, between adjacent systems and eventually with the 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 resort operation such as drop or declassify. This specification focuses on the Southbound interface and the operation of the Network Plane. 4.4. Elements of DetNet Architecture The DetNet architecture has a number of elements, discussed in the following sections: a. A model for the definition, identification, and operation of DetNet streams (Section 4.5), for use by relay systems to classify and process individual packets following per-stream rules. TW> how is a packet "labeled" as part of stream? b. A model for the flow of data from an end system or through a relay system that can be used to predict the bounds for that system's impact on the QoS of a DetNet stream, without significantly constraining the method of implementing that system, for use by the Controllers to configure policing and shaping 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 end system or relay system to control the selection of packets output on an interface. These models must have sufficiently well-defined characteristics, both individually and in the aggregate, to give predictable results for the QoS for DetNet packets (Section 4.7). 2. A model for identifying misbehaving DetNet streams and mitigating their impact on properly functioning streams (Section 4.9). c. A model for the relay system to inform the controller(s) of the information 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. hysical TW> typo resources (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 relay systems, to forward a DetNet stream over a simple or redundant path. The model includes: 1. A model for an abstract relaying operation of either Routing or forwarding packets of a DetNet stream to a next-hop relay system, across Layer boundaries. 2. A model of next-hop(s) information for replicating the packets of a DetNet stream, typically at or near the talker, merging and/or re-replicating those packets at other points in the network, and finally eliminating the duplicates, typically at or near the listener(s), in order to provide high availability (Section 3.3). e. The protocol stack model for an end system and/or a relay system should support the above elements in a manner that maximizes the applicability of existing standards and protocols to the DetNet problem, allows for the creation of new protocols where needed, thus making DetNet an add-on feature to existing networks, rather than a new way to do networking. In particular this protocol stack supports networks in which the path from talker to listener(s) includes bridges and/or routers in any order (Section 4.10). f. A variety of models for the provisioning of DetNet streams can be envisioned, including orchestration by a central controller or by a federation of controllers, provisioning by relay systems and end systems sharing peer-to-peer protocols, by off-line configuration, or by a combination of these methods. The provisioning models are similar to existing Layer-2 and Layer-3 models, in order to minimize the amount of innovation required in this area (Section 4.12). 4.5. DetNet streams 4.5.1. Talker guarantees DetNet streams can by synchronous or asynchronous. The transmission of packets in synchronous DetNet streams uses time synchronization among 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 observation interval. These parameters, together with knowledge of the protocol stack used (and thus the size of the various headers added to a packet), limit the number of bit times per observation interval that the DetNet stream can occupy the physical medium. The talker promises that these limits will not be exceeded. If the talker transmits less data than this limit allows, the unused resources such as link bandwidth can be made available by the system to non-DetNet packets. However, making those resources available to DetNet packets in other streams would serve no purpose. Those other streams have their own dedicated resources, on the assumption that all DetNet streams can use all of their resources over a long period of time. Note that there is no provision in DetNet for throttling streams; the assumption is that a DetNet stream, to be useful, must be delivered in its entirety. That is, while any useful application is written to expect a certain number of lost packets, the real-time applications of interest to DetNet demand that the loss of data due to the network is extraordinarily infrequent. Although DetNet strives to minimize the changes required of an application to allow it to shift from a special-purpose digital network to an Internet Protocol network, one fundamental shift in the behavior of network applications that is impossible to avoid--the reservation of resources before the application starts. In the first place, a network cannot deliver finite latency and practically zero packet loss to an arbitrarily high offered load. Secondly, achieving practically zero packet loss for unthrottled (though bandwidth limited) streams means that bridges and routers have to dedicate buffer resources to specific streams or to classes of streams. The requirements of each reservation have to be translated into the parameters that control each system's queuing, shaping, and scheduling functions and delivered to the hosts, bridges, and routers. 4.5.2. Incomplete Networks The presence in the network of relay systems that are not fully capable of offering DetNet services complicates the ability of the relay systems and/or controller to allocate resources, as extra buffering, and thus extra latency, must be allocated at each point that is downstream from the non-DetNet relay system for some DetNet stream. 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 Group has defined a set of queuing, shaping, and scheduling algorithms that enable each bridge or router to compute the exact number of buffers to 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 the network bandwidth to DetNet streams. But, no matter how much is dedicated for DetNet streams, It is z TW> typo goal of DetNet to not interfere excessively with existing QoS schemes. It is also important that non-DetNet traffic not disrupt the DetNet stream, of course (see Section 4.9 and Section 6). For these reasons: o Bandwidth (transmission opportunities) not utilized by a DetNet stream are available to non-DetNet packets (though not to other DetNet 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 scheduled in detail, then the algorithm constructing the schedule should leave sufficient opportunities for non-DetNet packets to satisfy the needs of the uses of the network. Ideally, the net effect of the presence of DetNet streams in a network on the non-DetNet packets is primarily a reductoin TW> typo in the available bandwidth. 4.9. Fault Mitigation One key to building robust real-time systems is to reduce the infinite variety of possible failures to a number that can be analyzed with reasonable confidence. DetNet aids in the process by providing filters and policers to detect DetNet packets received on the 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 the offending interface. It is also essential that filters and service remarking TW> please define "service remarking" be employed to prevent non-DetNet packets from impinging on the resources allocated 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 of standardization, that can perform these fault mitigation tasks that deliver a high probability that misbehaving systemd TW> typo will have zero impact on well-behaved DetNet streams, except of course, for the receiving interface(s) immediately downstream of the misbehaving device. 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 in progress, 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 model is attractive but a number of issues are left to be solved. In particular: o whether and how the path computation can be installed by 1) an end device or 2) a Network Management entity, o and how the path is set up, either by installing state at each hop with a direct interaction between the forwarding device and the PCE, or along a path by injecting a source-routed request at one end of the path. 4.12.2. Distributed Path Setup Whether a distributed alternative without a PCE can be valuable should be studied as well. Such an alternative could for instance inherit from the Resource ReSerVation Protocol [RFC5127] (RSVP) flows. In a Layer-2 only environment, or as part of a layered approach to a mixed environment, IEEE 802.1 also has work, either completed or in progress. [IEEE802.1Q-2011] Clause 35 describes SRP, a peer-to-peer protocol for Layer-2 roughly analogous to RSVP. Almost complete is [IEEE802.1Qca], which defines how ISIS can provide multiple disjoint paths 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 Differentiated Services 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 service class. The document also describes how the code-point can be mapped into one of the aggregated Diffserv service classes [RFC5127]. 5.2. 6TiSCH Industrial process control already leverages deterministic wireless Low power and Lossy Networks (LLNs) to interconnect critical resource-constrained devices and form wireless mesh networks, with standards such as [ISA100.11a] and [WirelessHART]. These standards rely on variations of the [IEEE802154e] timeSlotted Channel Hopping (TSCH) [I-D.ietf-6tisch-tsch] Medium Access Control (MAC), and a form of centralized Path Computation Element (PCE), to deliver deterministic capabilities. The TSCH MAC benefits include high reliability against interference, low power consumption on characterized streams, and Traffic Engineering capabilities. Typical applications are open and closed control loops, as well as supervisory control streams and management. The 6TiSCH Working Group focuses only on the TSCH mode of the IEEE 802.15.4e standard. The WG currently defines a framework for managing the TSCH schedule. Future work will standardize deterministic operations over so-called tracks as described in [I-D.ietf-6tisch-architecture]. Tracks are an instance of a deterministic path, and the DetNet work is a prerequisite to specify track operations and serve process control applications. [RFC5673] and [I-D.ietf-roll-rpl-industrial-applicability] section 2.1.3. and next discusses application-layer paradigms, such as Source-sink (SS) that is a Multipeer to Multipeer (MP2MP) model that is primarily used for alarms and alerts, Publish-subscribe (PS, or pub/sub) that is typically used for sensor data, as well as Peer-to- peer (P2P) and Peer-to-multipeer (P2MP) communications. Additional considerations on Duocast and its N-cast generalization are also provided 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 added dimension; the time of delivery of a packet can be just as important as the contents of the packet, itself. A man-in-the-middle attack, for example, can impose, and then systematically adjust, additional delays into a link, and thus disrupt or subvert a real-time application 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 of equipment, or even human lives, can be lost if the DetNet QoS is not delivered, one must consider not only simple equipment failures, where the box or wire instantly becomes perfectly silent, but bizarre errors such as can be coused TW> typo by software failures. Because there is essentiall TW> typo no limit to the kinds of failures that can occur, protecting against realistic equipment failures is indistinguishable, in most cases, from protecting against malicious behavior, whether accidental 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, George Swallow, 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, for their various contribution with this work. 9. Informative References [AVnu] http://www.avnu.org/, "The AVnu Alliance tests and certifies devices for interoperability, providing a simple and reliable networking solution for AV network implementation 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", . [HART] www.hartcomm.org, "Highway Addressable Remote Transducer, a group of specifications for industrial process and control devices administered by the HART Foundation", . [HSR-PRP] IEC, "High availability seamless redundancy (HSR) is a further development of the PRP approach, although HSR functions primarily as a protocol for creating media redundancy while PRP, as described in the previous section, creates network redundancy. PRP and HSR are both described in the IEC 62439 3 standard.", . [I-D.finn-detnet-problem-statement] Finn, N. and P. Thubert, "Deterministic Networking Problem Statement", draft-finn-detnet-problem-statement-01 (work in 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 IEEE 802.15.4e", draft-ietf-6tisch-architecture-05 (work in progress), January 2015. [I-D.ietf-6tisch-tsch] Watteyne, T., Palattella, M., and L. Grieco, "Using IEEE802.15.4e TSCH in an IoT context: Overview, Problem Statement and Goals", draft-ietf-6tisch-tsch-05 (work in progress), January 2015. [I-D.ietf-roll-rpl-industrial-applicability] Phinney, T., Thubert, P., and R. Assimiti, "RPL applicability 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 in progress), March 2015. [IEEE802.1AS-2011] IEEE, "Timing and Synchronizations (IEEE 802.1AS-2011)", 2011, . 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, . [IEEE802.1CB] IEEE, "Seamless Redundancy (IEEE Draft P802.1CB)", 2015, . [IEEE802.1Q-2011] IEEE, "MAC Bridges and VLANs (IEEE 802.1Q-2011", 2011, . [IEEE802.1Qat-2010] IEEE, "Stream Reservation Protocol (IEEE 802.1Qat-2010)", 2010, . [IEEE802.1Qav] IEEE, "Forwarding and Queuing (IEEE 802.1Qav-2009)", 2009, . [IEEE802.1Qca] IEEE, "Path Control and Reservation", 2015, . [IEEE802.1Qcc] IEEE, "Stream Reservation Protocol (SRP) Enhancements and Performance Improvements", 2015, . [IEEE802.1TSNTG] IEEE Standards Association, "IEEE 802.1 Time-Sensitive Networks 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-Rate Wireless 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 Area Networks (LR-WPANs) Amendment 1: MAC sublayer", April 2012. [ISA100.11a] ISA/IEC, "ISA100.11a, Wireless Systems for Automation, also IEC 62734", 2011, < http://www.isa100wci.org/en- US/Documents/PDF/3405-ISA100-WirelessSystems-Future-broch- WEB-ETSI.aspx>. [ODVA] http://www.odva.org/, "The organization that supports network technologies built on the Common Industrial Protocol (CIP) including EtherNet/IP.", . [PCE] IETF, "Path Computation Element", . [Profinet] http://us.profinet.com/technology/profinet/, "PROFINET is a standard for industrial networking in automation.", . [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional 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 LSP Tunnels", RFC 3209, December 2001. [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, August 2006. [RFC5127] Chan, K., Babiarz, J., and F. Baker, "Aggregation of Diffserv Service Classes", RFC 5127, February 2008. [RFC5673] Pister, K., Thubert, P., Dwars, S., and T. Phinney, "Industrial Routing Requirements in Low-Power and Lossy Networks", RFC 5673, October 2009. [RFC7384] Mizrahi, T., "Security Requirements of Time Protocols in Packet 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-Defined Networking (SDN): Layers and Architecture Terminology", RFC 7426, January 2015. [TEAS] IETF, "Traffic Engineering Architecture and Signaling", . [WirelessHART] www.hartcomm.org, "Industrial Communication Networks - Wireless Communication Network and Communication Profiles - WirelessHART - IEC 62591", 2010. Authors' Addresses Norm Finn Cisco Systems 170 W Tasman Dr. San Jose, California 95134 USA Phone: +1 408 526 4495 Email: nfinn@cisco.com Pascal Thubert Cisco Systems Village d'Entreprises Green Side 400, Avenue de Roumanille Batiment T3 Biot - Sophia Antipolis 06410 FRANCE Phone: +33 4 97 23 26 34 Email: pthubert@cisco.com Finn & Thubert Expires September 10, 2015 [Page 23] --047d7bfd062a5cd7e60511f762e2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Norm, Pascal,

Please find be= low a number of comment on=C2=A0draft-finn-detnet-architecture-00.

Overall, the draft is very well written and highlights imp= ortant points for deterministic networking.

My gen= eral comments are:
- in the context of a low-power wireless netwo= rk (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 s= ense to discuss the difference between hard and soft real-time, also wrt wi= reless systems?

Thomas

--= -


DetNet =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 N. Fi= nn
Internet-Draft =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0P. Thubert
Intended status: Standards Track =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 Cisco
Expir= es: September 10, 2015 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0March 9, 2015


=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0Deterministic Networking Architecture
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0draft-finn-detnet-architecture-00

Abstract
<= br>
=C2=A0 =C2=A0Deter= ministic Networking (DetNet) provides a capability to carry
=C2=A0 =C2=A0specified unicast or mul= ticast data streams for real-time
=C2=A0 =C2=A0applications with extremely low data loss rates an= d maximum latency.
TW&= gt; it looks like you aim for maximum latency :)
=C2=A0 =C2=A0Techniques used include: 1) reservi= ng data plane resources for
=C2=A0 =C2=A0individual (or aggregated) DetNet streams in some or all= of the relay
=C2=A0 = =C2=A0systems (bridges or routers) along the path of the stream; 2)<= /div>
=C2=A0 =C2=A0providing fixed = paths for DetNet streams that do not rapidly change
=C2=A0 =C2=A0with the network topology; and 3= ) sequentializing, replicating, and
=C2=A0 =C2=A0eliminating duplicate packets at various points = to ensure the
=C2=A0 = =C2=A0availability of at least one path.=C2=A0 The capabilities can be mana= ged
=C2=A0 =C2=A0by co= nfiguration, or by manual or automatic network management.

Status of This Memo

=C2=A0 =C2=A0This Internet-Draft is submitted in full conformance with the=
=C2=A0 =C2=A0provisio= ns of BCP 78 and BCP 79.

=C2=A0 =C2=A0I= nternet-Drafts are working documents of the Internet Engineering
=C2=A0 =C2=A0Task Force (IETF).= =C2=A0 Note that other groups may also distribute
=C2=A0 =C2=A0working documents as Internet-Draf= ts.=C2=A0 The list of current Internet-

<= /font>
=C2=A0 =C2=A0Internet-= Drafts are draft documents valid for a maximum of six months
=C2=A0 =C2=A0and may be updated, rep= laced, or obsoleted by other documents at any
=C2=A0 =C2=A0time.=C2=A0 It is inappropriate to u= se Internet-Drafts as reference
=C2=A0 =C2=A0material or to cite them other than as "work in= progress."

<= /font>
=C2=A0 =C2=A0This Inte= rnet-Draft will expire on September 10, 2015.

Copyright Notice

=C2=A0 =C2=A0= Copyright (c) 2015 IETF Trust and the persons identified as the
=C2=A0 =C2=A0document authors.=C2= =A0 All rights reserved.

=C2=A0 =C2=A0T= his document is subject to BCP 78 and the IETF Trust's Legal
=C2=A0 =C2=A0Provisions Relating= to IETF Documents
=C2= =A0 =C2=A0(http://trustee.ietf.org/license-info) in effect on the date of



Fin= n & Thubert =C2=A0 =C2=A0 =C2=A0 =C2=A0 Expires September 10, 2015 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [Page 1]
=0C=
Internet-Draft =C2=A0 =C2=A0= Deterministic Networking Architecture =C2=A0 =C2=A0 =C2=A0 March 2015


=C2=A0 =C2=A0publication of this document.=C2=A0 Please revie= w these documents
=C2= =A0 =C2=A0carefully, as they describe your rights and restrictions with res= pect
=C2=A0 =C2=A0to t= his document.=C2=A0 Code Components extracted from this document must
=C2=A0 =C2=A0include Simpli= fied BSD License text as described in Section 4.e of
=C2=A0 =C2=A0the Trust Legal Provisions and = are provided without warranty as
=C2=A0 =C2=A0described in the Simplified BSD License.

Table of Contents

=C2=A0 =C2=A01.=C2=A0 Introduction =C2=A0. . . . . . . . . . . . . . .= . . . . . . . . . =C2=A0 2
=C2=A0 =C2=A02.=C2=A0 Terminology . . . . . . . . . . . . . . . . . .= . . . . . . . =C2=A0 4
= =C2=A0 =C2=A0 =C2=A03.1.=C2=A0 Zero Congestion Loss =C2=A0. . . . . . . . .= . . . . . . . . . =C2=A0 6
=C2=A0 =C2=A0 =C2=A03.2.=C2=A0 Pinned-down paths . . . . . . . . . . = . . . . . . . . . . =C2=A0 7
=C2=A0 =C2=A0 =C2=A03.3.=C2=A0 Seamless Redundancy . . . . . . . . .= . . . . . . . . . . =C2=A0 7
=C2=A0 =C2=A04.=C2=A0 DetNet Architecture . . . . . . . . . . . . .= . . . . . . . . =C2=A0 8
=C2=A0 =C2=A0 =C2=A04.1.=C2=A0 The Application Plane . . . . . . . . . = . . . . . . . . . =C2=A011
=C2=A0 =C2=A0 =C2=A04.2.=C2=A0 The Controller Plane =C2=A0. . . . . . = . . . . . . . . . . . . =C2=A011
=C2=A0 =C2=A0 =C2=A04.3.=C2=A0 The Network Plane . . . . . . . .= . . . . . . . . . . . . =C2=A012
=C2=A0 =C2=A0 =C2=A04.4.=C2=A0 Elements of DetNet Architecture = . . . . . . . . . . . . . =C2=A013
=C2=A0 =C2=A0 =C2=A04.5.=C2=A0 DetNet streams =C2=A0. . . . . = . . . . . . . . . . . . . . . . =C2=A014
=C2=A0 =C2=A0 =C2=A0 =C2=A04.5.1.=C2=A0 Talker guarantee= s . . . . . . . . . . . . . . . . . . =C2=A014
=C2=A0 =C2=A0 =C2=A0 =C2=A04.5.2.=C2=A0 Incomplet= e Networks . . . . . . . . . . . . . . . . . =C2=A015
=C2=A0 =C2=A0 =C2=A04.6.=C2=A0 Data Flow Mo= del through Systems . . . . . . . . . . . . . =C2=A016
=C2=A0 =C2=A0 =C2=A04.7.=C2=A0 Queuing, Sh= aping, Scheduling, and Preemption =C2=A0. . . . . . =C2=A016
=C2=A0 =C2=A0 =C2=A04.8.=C2=A0 Coexi= stence with normal traffic . . . . . . . . . . . . . =C2=A016
<= div>=C2=A0 =C2=A0 =C2=A04.9.=C2=A0 Faul= t Mitigation =C2=A0. . . . . . . . . . . . . . . . . . . . =C2=A016<= /div>
=C2=A0 =C2=A0 =C2=A04.10. Pro= tocol Stack Model =C2=A0. . . . . . . . . . . . . . . . . . =C2=A017=
=C2=A0 =C2=A0 =C2=A04.11. Ad= vertising resources, capabilities and adjacencies . . . =C2=A017
=C2=A0 =C2=A0 =C2=A04.12. Provis= ioning model =C2=A0. . . . . . . . . . . . . . . . . . . =C2=A017
=C2=A0 =C2=A0 =C2=A0 =C2=A04.12= .1.=C2=A0 Centralized Path Computation and Installation =C2=A0. . . =C2=A01= 7
=C2=A0 =C2=A0 =C2=A0= =C2=A04.12.2.=C2=A0 Distributed Path Setup . . . . . . . . . . . . . . . = =C2=A017
=C2=A0 =C2=A0= 5.=C2=A0 Related IETF work . . . . . . . . . . . . . . . . . . . . . . =C2= =A018
=C2=A0 =C2=A0 = =C2=A05.1.=C2=A0 Deterministic PHB . . . . . . . . . . . . . . . . . . . . = =C2=A018
=C2=A0 =C2=A0= =C2=A05.2. =C2=A06TiSCH =C2=A0. . . . . . . . . . . . . . . . . . . . . . = . . . =C2=A018
=C2=A0 = =C2=A06.=C2=A0 Security Considerations . . . . . . . . . . . . . . . . . . = . =C2=A019
=C2=A0 =C2= =A07.=C2=A0 IANA Considerations . . . . . . . . . . . . . . . . . . . . . = =C2=A019
=C2=A0 =C2=A0= 8.=C2=A0 Acknowledgements =C2=A0. . . . . . . . . . . . . . . . . . . . . .= =C2=A019
=C2=A0 =C2= =A09.=C2=A0 Informative References =C2=A0. . . . . . . . . . . . . . . . . = . . =C2=A019
=C2=A0 = =C2=A0Authors' Addresses =C2=A0. . . . . . . . . . . . . . . . . . . . = . . . =C2=A023

1.=C2=A0 Introduction

=C2=A0 =C2=A0Operational Technology (OT) = refers to industrial networks that are
=C2=A0 =C2=A0typically used for monitoring systems and sup= porting control loops,
=C2=A0 =C2=A0as well as movement detection systems for use in process cont= rol
=C2=A0 =C2=A0(i.e.= , process manufacturing) and factory automation (i.e., discrete
=C2=A0 =C2=A0manufacturing).=C2= =A0 Due to its different goals, OT has evolved in



Finn & Thubert =C2= =A0 =C2=A0 =C2=A0 =C2=A0 Expires September 10, 2015 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 [Page 2]
=0C
Internet-Draft =C2=A0 =C2=A0Deterministic Netw= orking Architecture =C2=A0 =C2=A0 =C2=A0 March 2015


=C2= =A0 =C2=A0parallel but in a manner that is radically different from IT/ICT,=
TW> define IT and = ICT at first use
=C2= =A0 =C2=A0focusing on highly secure, reliable and deterministic networks, w= ith
=C2=A0 =C2=A0limit= ed scalability over a bounded area.

=C2= =A0 =C2=A0The convergence of IT and OT technologies, also called the Indust= rial
=C2=A0 =C2=A0Inte= rnet, represents a major evolution for both sides.=C2=A0 The work has
=C2=A0 =C2=A0already starte= d; in particular, the industrial automation space has
=C2=A0 =C2=A0been developing a number of Et= hernet-based replacements for existing
=C2=A0 =C2=A0digital control systems, often not packet-bas= ed (fieldbus
=C2=A0 = =C2=A0technologies).
<= br>
=C2=A0 =C2=A0These= replacements are meant to provide similar behavior as the
=C2=A0 =C2=A0incumbent protocols, and = their common focus is to transport
TW> "on transporting"?
=C2=A0 =C2=A0a fully
=C2=A0 =C2=A0characterized flow over a well-contr= olled environment (i.e., a
=C2=A0 =C2=A0factory floor), with a bounded latency, extraordinarily l= ow frame
=C2=A0 =C2=A0= loss, and a very narrow jitter.=C2=A0 Examples of such protocols include
=C2=A0 =C2=A0PROFINET, O= DVA Ethernet/IP, and EtherCAT.
TW> It might be good to quantify the target latency, packet los= s and jitter.
TW> I= appreciate this is not easy, but one representatve example might help
=C2=A0 =C2=A0In parallel, = the need for determinism in professional and home audio/
<= font face=3D"monospace, monospace">=C2=A0 =C2=A0video markets drove the for= mation of the Audio/Video Bridging (AVB)
=C2=A0 =C2=A0standards effort of IEEE 802.1.=C2=A0 With = the explosion of demand for
=C2=A0 =C2=A0connectivity and multimedia in transportation in general= , the
=C2=A0 =C2=A0Eth= ernet AVB technology has become one of the hottest topics, in
<= div>=C2=A0 =C2=A0particular in the auto= motive connectivity.=C2=A0 It is finding application
=C2=A0 =C2=A0in all elements of the vehicle<= /font>
TW> ":"
=C2=A0 =C2=A0from head = units, to rear seat
= =C2=A0 =C2=A0entertainment modules, to amplifiers and camera modules.=C2=A0= While aimed
=C2=A0 = =C2=A0at less critical applications than some industrial networks, AVB
=C2=A0 =C2=A0networks shar= e the requirement for extremely low packet loss rates
=C2=A0 =C2=A0and ensured finite latency and= jitter.
TW> ensure= -> guarantee?

=
=C2=A0 =C2=A0Other in= stances of in-vehicle deterministic networks have arisen as
=C2=A0 =C2=A0well for control network= s in cars, trains and buses, as well as
=C2=A0 =C2=A0avionics, with, for instance, the mission-cr= itical "Avionics Full-
=C2=A0 =C2=A0Duplex Switched Ethernet" (AFDX) that was designed = as part of the
=C2=A0 = =C2=A0ARINC 664 standards.=C2=A0 Existing automotive control networks such = as
=C2=A0 =C2=A0the LI= N, CAN and
TW> woul= d TTP/C fit in this list?
=C2=A0 =C2=A0FlexRay standards were not designed to cover these<= /div>
=C2=A0 =C2=A0increasing deman= ds in terms of bandwidth and scalability that we see
=C2=A0 =C2=A0with various kinds of Driver As= sistance Systems (DAS) and new
=C2=A0 =C2=A0multiplexing technologies based on Ethernet are now g= etting traction.

<= /font>
=C2=A0 =C2=A0The gener= alization of the needs for more deterministic networks have
=C2=A0 =C2=A0led to the IEEE 802.1 AV= B Task Group becoming the Time-Sensitive
=C2=A0 =C2=A0Networking (TSN) Task Group (TG), with a mu= ch-expanded constituency
=C2=A0 =C2=A0from the industrial and vehicular markets.=C2=A0 Along with= this
=C2=A0 =C2=A0exp= ansion, the networks in consideration are becoming larger and
<= div>=C2=A0 =C2=A0structured, requiring = deterministic forwarding beyond the LAN
=C2=A0 =C2=A0boundaries.=C2=A0 For instance, Industrial A= utomation segregates the
=C2=A0 =C2=A0network along the broad lines of the Purdue Enterprise Refe= rence



Finn & Thubert =C2=A0 =C2=A0 =C2=A0 =C2=A0 Expires September 1= 0, 2015 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [Page 3]
=0C
Internet-Draft = =C2=A0 =C2=A0Deterministic Networking Architecture =C2=A0 =C2=A0 =C2=A0 Mar= ch 2015


=C2=A0 =C2=A0Architecture (PERA), using differen= t technologies at each level, and
=C2=A0 =C2=A0public infrastructures such as Electricity Automat= ion require
=C2=A0 =C2= =A0deterministic properties over the Wide Area.=C2=A0 The realization is no= w
=C2=A0 =C2=A0coming = that the convergence of IT and OT networks requires Layer-3,
=C2=A0 =C2=A0as well as Layer-2, cap= abilities.

=
=C2=A0 =C2=A0The present arc= hitecture is the result of a collaboration of the IETF
=C2=A0 =C2=A0and the IEEE and implements a= n abstract model that can be applicable
=C2=A0 =C2=A0both at Layer-2 and Layer-3, and along segme= nts of different
=C2= =A0 =C2=A0technologie.
TW> typo
=C2=A0 = =C2=A0With this new work, a path may span, for instance,
<= font face=3D"monospace, monospace">=C2=A0 =C2=A0across a (limited) number o= f 802.1 bridges and then a (limited)
=C2=A0 =C2=A0number of IP routers.
TW> add somethind like "possibly wirele= ss" somewhere?
= =C2=A0 =C2=A0In that example, the IEEE 802.1 bridges may be
=C2=A0 =C2=A0operating at Layer-2 ove= r Ethernet whereas the IP routers may be
=C2=A0 =C2=A06TiSCH nodes operating at Layer-2 and/or La= yer-3 over the IEEE
= =C2=A0 =C2=A0802.15.4e MAC.

=C2=A0 =C2= =A0Many applications of interest to Deterministic Networking require the
=C2=A0 =C2=A0ability to = synchronize the clocks in end systems to a sub-microsecond
=C2=A0 =C2=A0accuracy.
TW> why this accuracy?
=C2=A0 =C2=A0Some of the queue co= ntrol techniques defined in
=C2=A0 =C2=A0Section 4.7 also require time synchronization among rela= y systems.
=C2=A0 =C2= =A0The means used to achieve time synchronization are not addressed in
=C2=A0 =C2=A0this document= .

2.=C2=A0 Terminology

=C2=A0 =C2=A0The follwing
TW> typo
=C2=A0 =C2=A0special terms are used in this document in ord= er to
=C2=A0 =C2=A0avo= id the assumption that a given element in the archetecture
TW> typo
=C2=A0 =C2=A0does or
=C2=A0 =C2=A0does not have Internet Protocol stac= k, functions as a router or a
=C2=A0 =C2=A0bridge, or otherwise plays a particular role at Layer-= 3 or higher:
TW> I = don't get the sentence above

=C2=A0= =C2=A0bridge
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0A Customer Bridge as defined by IEEE 802.= 1Q
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0[IEEE802.1Q-2011].

=C2=A0 =C2=A0circuit
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0A trail of configuration from t= alker to listener(s)
T= W> sender and receiver might be more common at the IETF?
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0through
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0relay systems associated with a DetNet st= ream, required to
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0deliver the benefits of DetNet.

=C2=A0 =C2=A0end system
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0C= ommonly called a "host" in IETF documents, and an "end
=C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0station" is IEEE 802 documents.=C2=A0 End systems of int= erest to
=C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0this document are talkers and listeners.=

=C2=A0 =C2=A0listener
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0An e= nd system capable of sinking a DetNet stream.

=C2=A0 =C2=A0relay system


=

Finn & Thubert =C2=A0 =C2=A0 =C2= =A0 =C2=A0 Expires September 10, 2015 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 [Page 4]
=0C
Internet-Draft =C2=A0 =C2=A0Deterministic Networking Archite= cture =C2=A0 =C2=A0 =C2=A0 March 2015

<= br>
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0A router or a bridge.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<= /div>
TW> maybe add "layer = 2 bridge" and "layer 3 router" for clarity?
=C2=A0 =C2=A0

=C2=A0 =C2=A0stream
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0A DetNet stream is a seq= uence of packets from a single
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0talker, through some numb= er of relay systems to one or more
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0listeners, that is li= mited by the talker in its maximum
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0packet size and trans= mission rate, and can thus be ensured
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the DetNet Quality= of Service (QoS) from the network.

=C2= =A0 =C2=A0talker
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0An end system capable of sourcing a D= etNet stream.

3.=C2=A0 Providing the De= tNet Quality of Service
=C2=A0 =C2=A0De= tNet Quality of Service is expressed in terms of:

=C2=A0 =C2=A0o =C2=A0Minimum and maximum end-to-end latency from= talker to listener;
<= br>
=C2=A0 =C2=A0o =C2= =A0Probability of loss of a packet, assuming the normal operation of=
=C2=A0 =C2=A0 =C2=A0 the rel= ay systems and links;
=
=C2=A0 =C2=A0o = =C2=A0Probability of loss of a packet in the event of the failure of a
=C2=A0 =C2=A0 =C2=A0 relay= system or link.

<= /font>
=C2=A0 =C2=A0It is a d= istinction of DetNet that it is concerned solely with worst-
=C2=A0 =C2=A0case values for all of = the above parameters.=C2=A0 Average, mean, or
=C2=A0 =C2=A0typical values are of no interest, b= ecause they do not affect the
=C2=A0 =C2=A0ability of a real-time system to perform its tasks.
TW> Would it make sen= se to discuss hard and soft real-time here, in
TW> particular in the context of a wireless sy= stem?
=C2=A0 =C2=A0

=C2=A0 =C2=A0Three techniques are employe= d by DetNet to achieve these QoS
=C2=A0 =C2=A0parameters:

=C2= =A0 =C2=A0a.=C2=A0 Zero congestion loss (Section 3.1).=C2=A0 Network resour= ces such as
=C2=A0 =C2= =A0 =C2=A0 =C2=A0link bandwidth, buffers, queues, shapers, and scheduled in= put/
TW> add 6TiSCH= cells?
=C2=A0 =C2=A0 = =C2=A0 =C2=A0output slots are assigned in each relay system to the use of a=
=C2=A0 =C2=A0 =C2=A0 = =C2=A0specific DetNet stream or group of streams.=C2=A0 Note that, given a<= /font>
=C2=A0 =C2=A0 =C2=A0 = =C2=A0finite amount of buffer space)
TW> extra ")"
=C2=A0 =C2=A0, zero congestion loss necessarily<= /div>
=C2=A0 =C2=A0 =C2=A0 =C2=A0en= sures a maximum end-to-end latency.=C2=A0 Depending on the method
=C2=A0 =C2=A0 =C2=A0 =C2=A0empl= oyed, a minimum latency can also be achieved.

=C2=A0 =C2=A0b.=C2=A0 Pinned-down paths (Section 3.2).=C2=A0 Point= -to-point paths or point-
=C2=A0 =C2=A0 =C2=A0 =C2=A0to-multipoint trees through the network from= a talker to one or
= =C2=A0 =C2=A0 =C2=A0 =C2=A0more listeners can be established, and DetNet st= reams assigned to
=C2= =A0 =C2=A0 =C2=A0 =C2=A0follow a particular path or tree.
= TW> Using a single path in a wireles= s system will fail, I would recommend
TW> discussing here path redundancy, for example through= DAGs

=C2=A0 =C2=A0c.=C2=A0 Packet repl= ication and deletion (Section 3.3).=C2=A0 End systems and/
=C2=A0 =C2=A0 =C2=A0 =C2=A0or relay sy= stems can sequence number, replicate, and eliminate
=C2=A0 =C2=A0 =C2=A0 =C2=A0replicated packets= at multiple points in the network in order to



Finn & Thubert =C2=A0= =C2=A0 =C2=A0 =C2=A0 Expires September 10, 2015 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 [Page 5]
=0C
Internet-Draft =C2=A0 =C2=A0Deterministic Network= ing Architecture =C2=A0 =C2=A0 =C2=A0 March 2015


=C2=A0 = =C2=A0 =C2=A0 =C2=A0ensure that one (or more) equipment failure events stil= l leave at
=C2=A0 =C2= =A0 =C2=A0 =C2=A0least one path intact for a DetNet stream.

=C2=A0 =C2=A0These three techniques can be applied ind= ependently, giving eight
=C2=A0 =C2=A0possible combinations, including none (no DetNet), although= some
=C2=A0 =C2=A0com= binations are of wider utility than others.=C2=A0 This separation keeps
=C2=A0 =C2=A0the protocol= stack coherent and maximizes interoperability with
=C2=A0 =C2=A0existing and developing standard= s in this (IETF) and other Standards
=C2=A0 =C2=A0Development Organizations.=C2=A0 Some examples = of typical expected
= =C2=A0 =C2=A0combinations:

=C2=A0 =C2= =A0o =C2=A0Pinned-down paths (a) plus packet replication (b) are exactly th= e
=C2=A0 =C2=A0 =C2=A0= techniques employed by [HSR-PRP].=C2=A0 Pinned-down paths are achieve
=C2=A0 =C2=A0 =C2=A0 by li= miting the physical topology of the network, and the
=C2=A0 =C2=A0 =C2=A0 sequentialization, repl= ication, and duplicate elimination
=C2=A0 =C2=A0 =C2=A0 facilitated by packet tags added at the f= ront or the end of
=C2= =A0 =C2=A0 =C2=A0 Ethernet frames.

=C2= =A0 =C2=A0o =C2=A0Zero congestion loss (a) alone is is offered by IEEE 802.= 1 Audio
=C2=A0 =C2=A0 = =C2=A0 Video bridging [IEEE802.1BA-2011].=C2=A0 As long as the network suff= ers
=C2=A0 =C2=A0 =C2= =A0 no failures, near-zero (at best, zero) congestion loss can be
=C2=A0 =C2=A0 =C2=A0 achieved t= hrough the use of a reservation protocol (MSRP) and
=C2=A0 =C2=A0 =C2=A0 shapers in every relay s= ystem (bridge).

=C2=A0 =C2=A0o =C2=A0Us= ing all three together gives maximum protection.

=C2=A0 =C2=A0There are, of course, simpler methods available (and= employed, today)
=C2= =A0 =C2=A0to achieve levels of latency and packet loss that are satisfactor= y
=C2=A0 =C2=A0for man= y applications.=C2=A0 However, these methods generally work best in<= /div>
=C2=A0 =C2=A0the absence of a= ny significant amount of non-critical traffic in the
=C2=A0 =C2=A0network (if, indeed, such traff= ic is supported at all), or work only
=C2=A0 =C2=A0if the critical traffic constitutes only a sma= ll portion of the
=C2= =A0 =C2=A0network's theoretical capacity, or work only if all systems a= re
=C2=A0 =C2=A0functi= oning properly, or in the absence of actions by end systems
=C2=A0 =C2=A0that disrupt the network= 's operations.
=C2=A0 =C2=A0There a= re any number of methods in use, defined, or in progress for
=C2=A0 =C2=A0accomplishing each of t= he above techniques.=C2=A0 It is expected that this
=C2=A0 =C2=A0DetNet Architecture will assist = various vendors, users, and/or
=C2=A0 =C2=A0"vertical" Standards Development Organizati= ons (dedicated to a single
=C2=A0 =C2=A0industry) to make selections among the available means of=
=C2=A0 =C2=A0implemen= ting DetNet networks.
=
3.1.=C2=A0 Zero C= ongestion Loss

=C2=A0 =C2=A0The primary= means by which DetNet achieves its QoS assurances is to
<= font face=3D"monospace, monospace">=C2=A0 =C2=A0completely eliminate conges= tion at an output port as a cause of
=C2=A0 =C2=A0packet loss.=C2=A0 Given that a DetNet stream c= annot be throttled, this



Finn & Thubert =C2=A0 =C2=A0 =C2=A0 =C2=A0 E= xpires September 10, 2015 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = [Page 6]
=0C
Internet-Draft =C2=A0 =C2=A0Deterministic Networking Architecture =C2=A0 = =C2=A0 =C2=A0 March 2015


=C2=A0 =C2=A0can be achieved on= ly by the provision of sufficient buffer storage at
=C2=A0 =C2=A0each hop through the network to = ensure that no packets are dropped
=C2=A0 =C2=A0due to a lack of buffer storage.
TW> and the provision the sufficien= t link bandwidth?

=
=C2=A0 =C2=A0Ensuring= adequate buffering requires, in turn, that the talker, and
=C2=A0 =C2=A0every relay system along= the path to the listener (or nearly every
=C2=A0 =C2=A0relay system -- see Section 4.5.2) be car= eful to regulate its output
=C2=A0 =C2=A0to not exceed the data rate for any stream, except for b= rief perios
TW> typ= o
=C2=A0 =C2=A0when ma= king up for interfering traffic.=C2=A0 Any packet sent ahead of its<= /div>
=C2=A0 =C2=A0time potentially= adds to the number of buffers required by the next
=C2=A0 =C2=A0hop, and may thus exceed the res= ources allocated for a particular
=C2=A0 =C2=A0stream.

=C2=A0= =C2=A0The low-level mechanisms described in Section 4.7 provide the=
=C2=A0 =C2=A0necessary regul= ation of transmissions by an edge system or relay
=C2=A0 =C2=A0system to ensure zero congestion l= oss.=C2=A0 Of course, the reservation of
=C2=A0 =C2=A0the bandwidth and buffers for a stream requ= ires the provisioning
= =C2=A0 =C2=A0described in Section 4.12.

3.2.=C2=A0 Pinned-down paths

=C2=A0 = =C2=A0In networks controlled by typical peer-to-peer protocols such as IEEE=
=C2=A0 =C2=A0802.1 IS= IS bridged networks or ETF OSPF routed networks, a network
=C2=A0 =C2=A0topology event in one par= t of the network can impact, at least
=C2=A0 =C2=A0briefly, the delivery of data in parts of the = network remote from the
=C2=A0 =C2= =A0network, if controlled by the typical peer-to-peer protocols, do not
=C2=A0 =C2=A0eliminate th= e chances of brief losses of contact.=C2=A0 For this reason,
=C2=A0 =C2=A0many real-time networks= rely on physical rings of two-port devices,
=C2=A0 =C2=A0with a relatively simple ring control p= rotocol.=C2=A0 This both minimizes
=C2=A0 =C2=A0recovery time and easily supports redundant paths= .=C2=A0 Of course, this
=C2=A0 =C2=A0t= ypical path.

=C2=A0 =C2=A0In order to g= et the advantages of low hop count and still ensure
=C2=A0 =C2=A0against even brief losses of con= nectivity, DetNet employs pinned-down
=C2=A0 =C2=A0paths, where the path taken by a given DetNet = stream does not change,
=C2=A0 =C2=A0t= opology events.=C2=A0 When combined with seamless redundancy
=C2=A0 =C2=A0(Section 3.3), this res= ults in a high likelihood of continuous
=C2=A0 =C2=A0connectivity.

3.3.=C2=A0 Seamless Redundancy

= =C2=A0 =C2=A0After congestion loss has been eliminated, the most important = causes
=C2=A0 =C2=A0of= packet loss are random media and/or memory faults and equipment
=C2=A0 =C2=A0failures.




Finn & Thubert =C2= =A0 =C2=A0 =C2=A0 =C2=A0 Expires September 10, 2015 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 [Page 7]
=0C
Internet-Draft =C2=A0 =C2=A0Deterministic Netw= orking Architecture =C2=A0 =C2=A0 =C2=A0 March 2015


=C2= =A0 =C2=A0Seamless redundancy involves three capabilities:

=C2=A0 =C2=A0o =C2=A0Adding sequence numbers to the pac= kets of a DetNet stream.

=C2=A0 =C2=A0o= =C2=A0Replicating these packets and, typically, sending them along at
=C2=A0 =C2=A0 =C2=A0 least= two different paths to the listener(s).


=C2=A0 =C2=A0In the simplest case, this amounts to replicati= ng each packet in a
= =C2=A0 =C2=A0talker that has two interfaces, and conveying them through the=
=C2=A0 =C2=A0network,= along separate paths, to the similarly dual-homed listeners,
<= div>=C2=A0 =C2=A0that discard the extra= s.=C2=A0 This ensures that one path (with zero
=C2=A0 =C2=A0congestion loss) remains, even if so= me relay system fails.
TW> this has some energy cost associated?
=C2=A0 =C2=A0
=C2=A0 =C2=A0Alternatively, relay systems in the network = can provide replication
=C2=A0 =C2=A0= multiple failures can be accommodated.

= =C2=A0 =C2=A0This is shown in the following figure, where the two relay sys= tems
=C2=A0 =C2=A0each= replicate (R) the DetNet stream on input, sending the stream to
=C2=A0 =C2=A0both the other rela= y system and to the end system, and eliminated
=C2=A0 =C2=A0duplicates (E) on the output interfa= ce to the right-hand end system.
=C2=A0 =C2=A0Any one links
TW> typo
=C2=A0 =C2=A0in the network can fail, and the Detnet stream can
=C2=A0 =C2=A0still get thro= ugh.=C2=A0 Furthermore, two links can fail, as long as they
=C2=A0 =C2=A0are in different segment= s of the network.

=
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > > = > > > > =C2=A0 relay =C2=A0 =C2=A0> > > > > >= > >
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > /---------= ---+ R system E +------------\ >
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0> / =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0v + ^ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 \ ><= /font>
=C2=A0 =C2=A0end =C2= =A0 =C2=A0R + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 v | ^ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+ E= end
=C2=A0 =C2=A0syst= em =C2=A0 + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = v | ^ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+ =C2= =A0 system
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> \ =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0v + ^ =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 / >
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 > \------------+ R relay =C2=A0E +------------/ &g= t;
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > &= gt; > > > > =C2=A0 system =C2=A0 > > > > > > = > >

<= /div>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0Figure 1
TW> I don't understand what R and E means

4.=C2=A0 DetNet Architecture

=C2=A0 =C2=A0Traffic Engineering Architecture and Signaling (TEAS) [TEA= S] defines
=C2=A0 =C2= =A0traffic-engineering architectures for generic applicability across
=C2=A0 =C2=A0packet and non= -packet networks.=C2=A0 From TEAS perspective, Traffic
=C2=A0 =C2=A0Engineering (TE) refers to te= chniques that enable operators to
=C2=A0 =C2=A0control how specific traffic flows are treated wit= hin their networks.
=C2=A0 =C2=A0Becaus= e if its very nature of establishing pinned-down optimized
=C2=A0 =C2=A0paths, Deterministic Netw= orking can be seen as a new, specialized


Finn & Thubert =C2=A0 =C2=A0= =C2=A0 =C2=A0 Expires September 10, 2015 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 [Page 8]
=0C
Internet-Draft =C2=A0 =C2=A0Deterministic Networking Arc= hitecture =C2=A0 =C2=A0 =C2=A0 March 2015


=C2=A0 =C2=A0b= ranch of Traffic Engineering, and inherits its architecture with a
=C2=A0 =C2=A0separation into p= lanes.

=C2=A0 =C2=A0The Deterministic N= etworking architecture is thus composed of three
=C2=A0 =C2=A0planes, a (User) Application Plane,= a Controller Plane, and a Network
=C2=A0 =C2=A0Plane, which echoes that of Software-Defined Netw= orking (SDN):=C2=A0
TW= > double ":"
=C2=A0 =C2=A0Layers








<= br>

<= div>



=




=












=

=







<= br>

<= div>


Finn & = Thubert =C2=A0 =C2=A0 =C2=A0 =C2=A0 Expires September 10, 2015 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [Page 9]
=0C
<= div>Internet-Draft =C2=A0 =C2=A0Determi= nistic Networking Architecture =C2=A0 =C2=A0 =C2=A0 March 2015
=


=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0SDN Layers and Architectu= re Terminology per RFC 7426

=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0o--------= ------------------------o
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0| +-------------+ =C2=A0 +----------+ |
=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| | Application | =C2=A0 | = =C2=A0Service | |
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| = +-------------+ =C2=A0 +----------+ |
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 Application Plane =C2=A0 =C2=A0 =C2= =A0 =C2=A0|
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0o--------= -------Y----------------o
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0 =C2=A0 =C2=A0*-----= ------------------------Y---------------------------------*
=C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 Network Services Abstraction Layer (NSAL) =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 =C2=A0 =C2=A0 =C2=A0*------Y----------------------------= --------------------Y-------*
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0|
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 Service Interface =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0 =C2=A0 =C2=A0o------Y-= -----------------o =C2=A0 =C2=A0 =C2=A0 o---------------------Y------o
=C2=A0 =C2=A0 =C2=A0 =C2= =A0| =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0Control Plane | =C2=A0 =C2=A0 =C2= =A0 | Management Plane =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0 =C2=A0 =C2=A0| +----Y--= --+ =C2=A0 +-----+ =C2=A0 | =C2=A0 =C2=A0 =C2=A0 | =C2=A0+-----+ =C2=A0 =C2= =A0 =C2=A0 +----Y----+ |
=C2=A0 =C2=A0 =C2=A0 =C2=A0| | Service | =C2=A0 | App | =C2=A0 | =C2=A0 = =C2=A0 =C2=A0 | =C2=A0| App | =C2=A0 =C2=A0 =C2=A0 | Service | |
=C2=A0 =C2=A0 =C2=A0 =C2=A0| +--= --Y----+ =C2=A0 +--Y--+ =C2=A0 | =C2=A0 =C2=A0 =C2=A0 | =C2=A0+--Y--+ =C2= =A0 =C2=A0 =C2=A0 +----Y----+ |
=C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 | =C2=A0 = =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 = =C2=A0|
=C2=A0 =C2=A0 = =C2=A0 =C2=A0| *----Y-----------Y----* | =C2=A0 =C2=A0 =C2=A0 | *---Y------= ---------Y----* |
=C2= =A0 =C2=A0 =C2=A0 =C2=A0| | Control Abstraction | | =C2=A0 =C2=A0 =C2=A0 | = | Management Abstraction | |
=C2=A0 =C2=A0 =C2=A0 =C2=A0| | =C2=A0 =C2=A0 Layer (CAL) =C2=A0 =C2= =A0 | | =C2=A0 =C2=A0 =C2=A0 | | =C2=A0 =C2=A0 =C2=A0Layer (MAL) =C2=A0 =C2= =A0 =C2=A0 | |
=C2=A0 = =C2=A0 =C2=A0 =C2=A0| *----------Y----------* | =C2=A0 =C2=A0 =C2=A0 | *---= -------Y-------------* |
=C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 | =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 |
=C2=A0 = =C2=A0 =C2=A0 =C2=A0o------------|------------o =C2=A0 =C2=A0 =C2=A0 o-----= -------|---------------o
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 | CP =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| MP
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 | Southbound =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| Southbound
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 | Interface =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | Interface
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=
=C2=A0 =C2=A0 =C2=A0 =C2=A0*= ------------Y---------------------------------Y----------------*
=C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2= =A0 =C2=A0 =C2=A0 =C2=A0 Device and resource Abstraction Layer (DAL) =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 =C2=A0 =C2=A0 =C2=A0*------------Y-------------------------= --------Y----------------*
=C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0o-------Y----------o =C2=A0 +---= --+ =C2=A0 o--------Y----------o =C2=A0 =C2=A0 |
=C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0| Forw= arding Plane | =C2=A0 | App | =C2=A0 | Operational Plane | =C2=A0 =C2=A0 |<= /font>
=C2=A0 =C2=A0 =C2=A0 = =C2=A0| =C2=A0 =C2=A0o------------------o =C2=A0 +-----+ =C2=A0 o----------= ---------o =C2=A0 =C2=A0 |
=C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Network Device =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|<= /div>
=C2=A0 =C2=A0 =C2=A0 =C2=A0+-= --------------------------------------------------------------+

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Figure= 2





<= /div>


Finn & Thubert =C2=A0 =C2=A0 =C2=A0 =C2=A0 Expires Septembe= r 10, 2015 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[Page 10]=
=0C
Internet-Draft= =C2=A0 =C2=A0Deterministic Networking Architecture =C2=A0 =C2=A0 =C2=A0 Ma= rch 2015


4.1.=C2=A0 The Application Plane

=C2=A0 =C2=A0Per [RFC7426], the Application Plane inc= ludes both applications and
=C2=A0 =C2=A0services.=C2=A0 In particular, the Application Plane inc= orporates the User
=C2= =A0 =C2=A0Agent, a specialized application that interacts with the end user= /
=C2=A0 =C2=A0operat= or and performs requests for Deterministic Networking services
=
=C2=A0 =C2=A0via an abstract Strea= m Management Entity, (SME) which may or may not
=C2=A0 =C2=A0be collocated with (one of) the end = systems.

=C2=A0 =C2=A0At the Applicatio= n Plane, a management interface enables the
=C2=A0 =C2=A0negotiation of streams between end syste= ms.=C2=A0 An abstraction of the
=C2=A0 =C2=A0stream called a Traffic Specification (TSpec) provid= es the
=C2=A0 =C2=A0re= presentation.=C2=A0 This abstraction is used to place a reservation over
=C2=A0 =C2=A0the (Northb= ound) Service Interface and within the Application plane.
= =C2=A0 =C2=A0It is associated with an a= bstraction of location, such as IP
=C2=A0 =C2=A0addresses and DNS names, to identify the end syst= ems and eventually
=C2= =A0 =C2=A0specify intermediate relay systems.

4.2.=C2=A0 The Controller Plane

=C2=A0 =C2=A0an= d Management Planes in [RFC7426], though Common Control and
=C2=A0 =C2=A0Measurement Plane (CCAMP= ) [CCAMP] makes an additional distinction
=C2=A0 =C2=A0between management and measurement.=C2=A0 = When the logical separation of
=C2=A0 =C2=A0the Control, Measurement and other Management entitie= s is not
=C2=A0 =C2=A0= relevant, the term Controller Plane is used for simplicity to
<= div>=C2=A0 =C2=A0represent them all, an= d the term controller refers to any device
=C2=A0 =C2=A0operating in that plane, whether is it a = Path Computation entity or a
=C2=A0 =C2=A0Network Management entity (NME).=C2=A0 The Path Computa= tion Element (PCE)
=C2= =A0 =C2=A0[PCE] is a core element of a controller, in charge of computing
=C2=A0 =C2=A0Determinis= tic paths to be applied in the Network Plane.

=C2=A0 =C2=A0A (Northbound) Service Interface enables applications= in the
=C2=A0 =C2=A0A= pplication Plane to communicate with the entities in the Controller<= /div>
=C2=A0 =C2=A0Plane.


TW> could you define NME, SME and PCE in the terminology?
=C2=A0 =C2=A0
=
=C2=A0 =C2=A0One or more PCE(s) co= llaborate to implement the requests from the SME
=C2=A0 =C2=A0as Per-Stream Per-Hop Behaviors ins= talled in the relay systems for
=C2=A0 =C2=A0each individual streams.=C2=A0 The PCEs place each s= tream along a
=C2=A0 = =C2=A0deterministic sequence of relay systems so as to respect per-stream
=C2=A0 =C2=A0constraint= s such as security and latency, and optimize the overall
<= font face=3D"monospace, monospace">=C2=A0 =C2=A0result for metrics such as = an abstract aggregated cost.=C2=A0 The
=C2=A0 =C2=A0deterministic sequence can typically be more = complex than a direct
= =C2=A0 =C2=A0sequence and include redundancy path, with one or more packet<= /font>
=C2=A0 =C2=A0replicati= on and elimination points.


<= /div>




<= /font>
Finn & Thubert =C2= =A0 =C2=A0 =C2=A0 =C2=A0 Expires September 10, 2015 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0[Page 11]
=0C
Internet-Draft =C2=A0 =C2=A0Deterministic Netw= orking Architecture =C2=A0 =C2=A0 =C2=A0 March 2015


4.3.= =C2=A0 The Network Plane

=C2=A0 =C2=A0T= he Network Plane represents the network devices and protocols as a
=C2=A0 =C2=A0whole, regardless= of the Layer at which the network devices operate.

=C2=A0 =C2=A0The network Plane comprises the Network Interface= Cards (NIC) in the
= =C2=A0 =C2=A0end systems, which are typically IP hosts, and relay systems, = which
=C2=A0 =C2=A0are= typically IP routers and switches.=C2=A0 Network-to-Network Interfaces
=C2=A0 =C2=A0such as used= for Traffic Engineering path reservation in [RFC3209],
=C2=A0 =C2=A0as well as User-to-Network I= nterfaces (UNI) such as provided by the
=C2=A0 =C2=A0Local Management Interface (LMI) between net= work and end systems, are
=C2=A0 =C2=A0all part of the Network Plane.

=C2=A0 =C2=A0A Southbound (Network) Interface enables the entities= in the
=C2=A0 =C2=A0C= ontroller Plane to communicate with devices in the Network Plane.
=C2=A0 =C2=A0This interface lev= erages and extends TEAS to describe the physical
=C2=A0 =C2=A0topology and resources in the Netwo= rk Plane.

<= /div>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Stream Manage= ment Entity

=C2=A0 =C2=A0 =C2=A0 =C2=A0= End =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 End
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0System =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 System

=C2=A0 =C2=A0 =C2=A0 -+-+= -+-+-+-+-+ Northbound -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = PCE =C2=A0 =C2=A0 =C2=A0 =C2=A0 PCE =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0PCE =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0PCE

=C2=A0 =C2=A0 =C2=A0 -+-+-+-+-+-+-+ Southbound -= +-+-+-+-+-+-+-+-+-+--+-+-+-+-+-+-

=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Relay =C2=A0 = =C2=A0 =C2=A0Relay =C2=A0 =C2=A0 =C2=A0Relay =C2=A0 =C2=A0 =C2=A0Relay
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 System =C2=A0 =C2=A0 System =C2=A0 = =C2=A0 System =C2=A0 =C2=A0 System
=C2=A0 =C2=A0 =C2=A0 =C2=A0NIC =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 NIC
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Relay =C2=A0 =C2=A0 =C2=A0= Relay =C2=A0 =C2=A0 =C2=A0Relay =C2=A0 =C2=A0 =C2=A0Relay
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 System =C2=A0 =C2=A0 System =C2=A0 =C2=A0 System = =C2=A0 =C2=A0 System
<= br>
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0Figure 3

=C2= =A0 =C2=A0The relay systems (and eventually the end systems NIC) expose the= ir
=C2=A0 =C2=A0capabi= lities and physical resources to the controller (the PCE), and
=
=C2=A0 =C2=A0update the PCE with t= heir dynamic perception of the topology, across
=C2=A0 =C2=A0the Southbound Interface.=C2=A0 In r= eturn, the PCE(s) set the per-stream
=C2=A0 =C2=A0paths up, providing a Stream Characterization t= hat is more tightly
= =C2=A0 =C2=A0coupled to the relay system Operation than a TSpec.

=C2=A0 =C2=A0At the Network plane, relay systems = exchange information regarding
=C2=A0 =C2=A0the state of the paths, between adjacent systems and = eventually with
=C2=A0= =C2=A0the end systems, and forward packets within constraints associated t= o




Finn & Th= ubert =C2=A0 =C2=A0 =C2=A0 =C2=A0 Expires September 10, 2015 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[Page 12]
=0C
= Internet-Draft =C2=A0 =C2=A0Determinist= ic Networking Architecture =C2=A0 =C2=A0 =C2=A0 March 2015


=C2=A0 =C2=A0each stream, or, when unable to do so, perform a last resor= t
=C2=A0 =C2=A0operati= on such as drop or declassify.

=C2=A0 = =C2=A0This specification focuses on the Southbound interface and the=
=C2=A0 =C2=A0operation of th= e Network Plane.

<= /font>
4.4.=C2=A0 Elements of= DetNet Architecture
<= br>
=C2=A0 =C2=A0The D= etNet architecture has a number of elements, discussed in the
<= div>=C2=A0 =C2=A0following sections:

=C2=A0 =C2=A0a.=C2=A0 A model for the def= inition, identification, and operation of
=C2=A0 =C2=A0 =C2=A0 =C2=A0DetNet streams (Section 4.5)= , for use by relay systems to
=C2=A0 =C2=A0 =C2=A0 =C2=A0classify and process individual packets = following per-stream
= =C2=A0 =C2=A0 =C2=A0 =C2=A0rules.
TW> how is a packet "labeled" as part of stream?

<= font face=3D"monospace, monospace">=C2=A0 =C2=A0b.=C2=A0 A model for the fl= ow of data from an end system or through a
=C2=A0 =C2=A0 =C2=A0 =C2=A0relay system that can be us= ed to predict the bounds for that
=C2=A0 =C2=A0 =C2=A0 =C2=A0system's impact on the QoS of a = DetNet stream, without
=C2=A0 =C2=A0 =C2=A0 =C2=A0significantly constraining the method of implem= enting that
=C2=A0 =C2= =A0 =C2=A0 =C2=A0system, for use by the Controllers to configure policing a= nd
=C2=A0 =C2=A0 =C2= =A0 =C2=A0shaping engines in Network Systems over the Southbound interface.=
=C2=A0 =C2=A0 =C2=A0 = =C2=A0The model includes:

=C2=A0 =C2=A0= =C2=A0 =C2=A01.=C2=A0 A model for queuing, transmission selection, shaping= ,
=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0preemption, and timing resources that can be used by a= n end
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0system or relay system to control the selection = of packets
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0output on an interface.=C2=A0 These models m= ust have sufficiently
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0well-defined characteristics, both= individually and in the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0aggregate, to give predictable = results for the QoS for DetNet
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0packets (Section 4.7).

=C2=A0 =C2=A0 =C2=A0 =C2=A02.=C2=A0 A mod= el for identifying misbehaving DetNet streams and
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0mitiga= ting their impact on properly functioning streams
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(Secti= on 4.9).

=C2=A0 =C2=A0c.=C2=A0 A model = for the relay system to inform the controller(s) of the
=C2=A0 =C2=A0 =C2=A0 =C2=A0information it= needs for adequate path computations including:

=C2=A0 =C2=A0 =C2=A0 =C2=A01.=C2=A0 Systems' individual capab= ilities (e.g. can do replication,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0can do precise time).<= /font>

= =C2=A0 =C2=A0 =C2=A0 =C2=A02.=C2=A0 Lin= k capabilities and resources (e.g. bandwidth, 0 delays,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= hardware deterministic support to the physical layer, ...)

=C2=A0 =C2=A0 =C2=A0 =C2=A03. =C2=A0hysical
TW> typo
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0re= sources (total and available buffers, timers,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0queues, = etc)

=



Finn &am= p; Thubert =C2=A0 =C2=A0 =C2=A0 =C2=A0 Expires September 10, 2015 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[Page 13]
=0C
Internet-Draft =C2=A0 =C2=A0Dete= rministic Networking Architecture =C2=A0 =C2=A0 =C2=A0 March 2015


=C2=A0 =C2=A0 =C2=A0 =C2=A04.=C2=A0 Network Adjacencies (neighbor= s)

=C2=A0 =C2=A0d.=C2=A0 A model for th= e provision of a service, by end systems, or relay
=C2=A0 =C2=A0 =C2=A0 =C2=A0systems, to forward= a DetNet stream over a simple or redundant
=C2=A0 =C2=A0 =C2=A0 =C2=A0path.=C2=A0 The model incl= udes:

=C2=A0 =C2=A0 =C2=A0 =C2=A01.=C2= =A0 A model for an abstract relaying operation of either Routing
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0or forwarding packets of a DetNet stream to a next-hop relay
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0system, across Layer boundaries.

=C2=A0 =C2=A0 =C2=A0 =C2=A02.=C2=A0 A model of next-hop(s) infor= mation for replicating the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0packets of a DetNet stream, t= ypically at or near the talker,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0merging and/or re-replic= ating those packets at other points
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0in the network, and = finally eliminating the duplicates,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0typically at or near= the listener(s), in order to provide
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0high availability = (Section 3.3).

=C2=A0 =C2=A0e.=C2=A0 Th= e protocol stack model for an end system and/or a relay system
=
=C2=A0 =C2=A0 =C2=A0 =C2=A0should = support the above elements in a manner that maximizes the
= =C2=A0 =C2=A0 =C2=A0 =C2=A0applicabilit= y of existing standards and protocols to the DetNet
=C2=A0 =C2=A0 =C2=A0 =C2=A0problem, allows fo= r the creation of new protocols where needed,
=C2=A0 =C2=A0 =C2=A0 =C2=A0thus making DetNet an = add-on feature to existing networks, rather
=C2=A0 =C2=A0 =C2=A0 =C2=A0than a new way to do netwo= rking.=C2=A0 In particular this protocol
=C2=A0 =C2=A0 =C2=A0 =C2=A0stack supports networks in wh= ich the path from talker to
=C2=A0 =C2=A0 =C2=A0 =C2=A0listener(s) includes bridges and/or router= s in any order
=C2=A0 = =C2=A0 =C2=A0 =C2=A0(Section 4.10).

=C2= =A0 =C2=A0f.=C2=A0 A variety of models for the provisioning of DetNet strea= ms can be
=C2=A0 =C2= =A0 =C2=A0 =C2=A0envisioned, including orchestration by a central controlle= r or by
=C2=A0 =C2=A0 = =C2=A0 =C2=A0a federation of controllers, provisioning by relay systems and=
=C2=A0 =C2=A0 =C2=A0 = =C2=A0end systems sharing peer-to-peer protocols, by off-line
<= div>=C2=A0 =C2=A0 =C2=A0 =C2=A0configur= ation, or by a combination of these methods.=C2=A0 The
=C2=A0 =C2=A0 =C2=A0 =C2=A0provisioning mo= dels are similar to existing Layer-2 and Layer-3
=C2=A0 =C2=A0 =C2=A0 =C2=A0models, in order to m= inimize the amount of innovation required in
=C2=A0 =C2=A0 =C2=A0 =C2=A0this area (Section 4.12).=

4.5.=C2=A0 DetNet streams
=

4.5.1.=C2=A0 Talker guarantees
<= font face=3D"monospace, monospace">
=C2=A0 =C2=A0DetNet streams can by synchronous or asynchr= onous.=C2=A0 The transmission
=C2=A0 =C2=A0of packets in synchronous DetNet streams uses time syn= chronization
=C2=A0 = =C2=A0among the end and relay systems to control the flow of packets.
=C2=A0 =C2=A0Asynchronous D= etNet streams are characterized by:

=C2= =A0 =C2=A0o =C2=A0A maximum packet size;




=
Finn & Thubert = =C2=A0 =C2=A0 =C2=A0 =C2=A0 Expires September 10, 2015 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0[Page 14]
=0C
Internet-Draft =C2=A0 =C2=A0Deterministic Net= working Architecture =C2=A0 =C2=A0 =C2=A0 March 2015


=C2= =A0 =C2=A0o =C2=A0A maximum number of transmissions during that observation=
=C2=A0 =C2=A0 =C2=A0 = interval.

<= /div>
=C2=A0 =C2=A0These parameters= , together with knowledge of the protocol stack used
=C2=A0 =C2=A0(and thus the size of the vario= us headers added to a packet), limit
=C2=A0 =C2=A0the number of bit times per observation interva= l that the DetNet
=C2= =A0 =C2=A0stream can occupy the physical medium.

=C2=A0 =C2=A0The talker promises that these limits will not be ex= ceeded.=C2=A0 If the
= =C2=A0 =C2=A0talker transmits less data than this limit allows, the unused<= /font>
=C2=A0 =C2=A0resources= such as link bandwidth can be made available by the system
=C2=A0 =C2=A0to non-DetNet packets.= =C2=A0 However, making those resources available to
=C2=A0 =C2=A0DetNet packets in other streams = would serve no purpose.=C2=A0 Those other
=C2=A0 =C2=A0streams have their own dedicated resources= , on the assumption that
=C2=A0 =C2=A0all DetNet streams can use all of their resources over a lo= ng period
=C2=A0 =C2= =A0of time.

=C2=A0 =C2=A0Note that ther= e is no provision in DetNet for throttling streams; the
=C2=A0 =C2=A0assumption is that a DetNet = stream, to be useful, must be delivered
=C2=A0 =C2=A0in its entirety.=C2=A0 That is, while any us= eful application is written to
=C2=A0 =C2=A0expect a certain number of lost packets, the real-tim= e applications
=C2=A0 = =C2=A0of interest to DetNet demand that the loss of data due to the network=
=C2=A0 =C2=A0is extra= ordinarily infrequent.

=C2=A0 =C2=A0Alt= hough DetNet strives to minimize the changes required of an
=C2=A0 =C2=A0application to allow it = to shift from a special-purpose digital
=C2=A0 =C2=A0network to an Internet Protocol network, one= fundamental shift in the
=C2=A0 =C2=A0behavior of network applications that is impossible to avo= id--the
=C2=A0 =C2=A0r= eservation of resources before the application starts.=C2=A0 In the first
=C2=A0 =C2=A0place, a n= etwork cannot deliver finite latency and practically zero
= =C2=A0 =C2=A0packet loss to an arbitrar= ily high offered load.=C2=A0 Secondly, achieving
=C2=A0 =C2=A0practically zero packet loss for un= throttled (though bandwidth
=C2=A0 =C2=A0limited) streams means that bridges and routers have to = dedicate
=C2=A0 =C2=A0= buffer resources to specific streams or to classes of streams.=C2=A0 The
=C2=A0 =C2=A0requirement= s of each reservation have to be translated into the
=C2=A0 =C2=A0parameters that control each sy= stem's queuing, shaping, and
=C2=A0 =C2=A0scheduling functions and delivered to the hosts, br= idges, and
=C2=A0 =C2= =A0routers.

4.5.2.=C2=A0 Incomplete Net= works

=C2=A0 =C2=A0The presence in the = network of relay systems that are not fully
=C2=A0 =C2=A0capable of offering DetNet services comp= licates the ability of the
=C2=A0 =C2=A0relay systems and/or controller to allocate resources, as= extra
=C2=A0 =C2=A0bu= ffering, and thus extra latency, must be allocated at each point
=C2=A0 =C2=A0that is downstream = from the non-DetNet relay system for some DetNet
=C2=A0 =C2=A0stream.




Finn & Thubert =C2=A0 =C2=A0 =C2=A0 = =C2=A0 Expires September 10, 2015 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0[Page 15]
=0C
Internet-Draft =C2=A0 =C2=A0Deterministic Networking Architecture = =C2=A0 =C2=A0 =C2=A0 March 2015


4.6.=C2=A0 Data Flow Mod= el through Systems
4.7.=C2=A0 Queuing, = Shaping, Scheduling, and Preemption

=C2= =A0 =C2=A0For this reason, the IEEE 802.1 Time-Sensitive Networking Task Gr= oup
=C2=A0 =C2=A0has d= efined a set of queuing, shaping, and scheduling algorithms that
=C2=A0 =C2=A0enable each bridge = or router to compute the exact number of buffers
=C2=A0 =C2=A0to be allocated for each stream or = class of streams.

=
4.8.=C2=A0 Coexistenc= e with normal traffic
=
=C2=A0 =C2=A0A De= tNet network supports the dedication of at least 75% of the
=C2=A0 =C2=A0network bandwidth to Det= Net streams.=C2=A0 But, no matter how much is
=C2=A0 =C2=A0dedicated for DetNet streams, It is = z
TW> typo
=C2=A0 =C2=A0goal of DetNet to= not interfere
=C2=A0 = =C2=A0excessively with existing QoS schemes.=C2=A0 It is also important tha= t
=C2=A0 =C2=A0non-Det= Net traffic not disrupt the DetNet stream, of course (see
= =C2=A0 =C2=A0Section 4.9 and Section 6)= .=C2=A0 For these reasons:

=C2=A0 =C2= =A0o =C2=A0Bandwidth (transmission opportunities) not utilized by a DetNet<= /font>
=C2=A0 =C2=A0 =C2=A0 s= tream are available to non-DetNet packets (though not to other
=
=C2=A0 =C2=A0 =C2=A0 DetNet stream= s).

<= div>=C2=A0 =C2=A0o =C2=A0DetNet streams= can be shaped, in order to ensure that the highest-
=C2=A0 =C2=A0 =C2=A0 priority non-DetNet pac= ket also is ensured a maximum latency.

= =C2=A0 =C2=A0o =C2=A0When transmission opportunities for DetNet streams are= scheduled
=C2=A0 =C2= =A0 =C2=A0 in detail, then the algorithm constructing the schedule should
=C2=A0 =C2=A0 =C2=A0 le= ave sufficient opportunities for non-DetNet packets to satisfy
=
=C2=A0 =C2=A0 =C2=A0 the needs of = the uses of the network.

=C2=A0 =C2=A0I= deally, the net effect of the presence of DetNet streams in a
<= div>=C2=A0 =C2=A0network on the non-Det= Net packets is primarily a reductoin
TW> typo
=C2=A0 =C2=A0in the
=C2=A0 =C2=A0available bandwidth.

4.= 9.=C2=A0 Fault Mitigation

=C2=A0 =C2=A0= One key to building robust real-time systems is to reduce the
<= div>=C2=A0 =C2=A0infinite variety of po= ssible failures to a number that can be
=C2=A0 =C2=A0analyzed with reasonable confidence.=C2=A0 D= etNet aids in the process by
=C2=A0 =C2=A0providing filters and policers to detect DetNet packets= received on
=C2=A0 = =C2=A0the wrong interface, or at the wrong time, or in too great a volume,<= /font>
=C2=A0 =C2=A0and to th= en take actions such as disabling the offending packet,
=C2=A0 =C2=A0shutting down the offending = DetNet stream, or shutting down the
=C2=A0 =C2=A0offending interface.

=C2=A0 =C2=A0It is also essential that filters and service remarki= ng
TW> please defin= e "service remarking"
=C2=A0 =C2=A0be employed
=C2=A0 =C2=A0to prevent non-DetNet packets from impinging on t= he resources
=C2=A0 = =C2=A0allocated to DetNet packets.


=

Finn & Thubert =C2=A0 =C2=A0 =C2= =A0 =C2=A0 Expires September 10, 2015 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0[Page 16]
=0C
Internet-Draft =C2=A0 =C2=A0Deterministic Networking Archite= cture =C2=A0 =C2=A0 =C2=A0 March 2015

<= br>
=C2=A0 =C2=A0There= exist techniques, at present and/or in various stages of
= =C2=A0 =C2=A0standardization, that can = perform these fault mitigation tasks that
=C2=A0 =C2=A0deliver a high probability that misbehavin= g systemd
TW> typo<= /font>
=C2=A0 =C2=A0will have= zero
=C2=A0 =C2=A0imp= act on well-behaved DetNet streams, except of course, for the
<= div>=C2=A0 =C2=A0receiving interface(s)= immediately downstream of the misbehaving
=C2=A0 =C2=A0device.

4.10.=C2=A0 Protocol Stack Model

=C2= =A0 =C2=A0This section will be further developed.=C2=A0 See [IEEE802.1CB], = Annex C,
=C2=A0 =C2=A0= for a description of the protocol stack.=C2=A0 This is very much a work in<= /font>
=C2=A0 =C2=A0progress,= not a standard.=C2=A0 See also [IEEE802.1Qcc].

4.11.=C2=A0 Advertising resources, capabilities and adjacencies

4.12.=C2=A0 Provisioning model

4.12.1.=C2=A0 Centralized Path Computation and In= stallation

=
=C2=A0 =C2=A0A centralized r= outing model, such as provided with a PCE (RFC 4655
=C2=A0 =C2=A0[RFC4655]), enables global and p= er-stream optimizations.=C2=A0 The model
=C2=A0 =C2=A0is attractive but a number of issues are le= ft to be solved.=C2=A0 In
=C2=A0 =C2=A0particular:

=C2=A0 =C2= =A0o =C2=A0whether and how the path computation can be installed by 1) an e= nd
=C2=A0 =C2=A0 =C2= =A0 device or 2) a Network Management entity,

=C2=A0 =C2=A0o =C2=A0and how the path is set up, either by install= ing state at each hop
= =C2=A0 =C2=A0 =C2=A0 with a direct interaction between the forwarding devic= e and the
=C2=A0 =C2= =A0 =C2=A0 PCE, or along a path by injecting a source-routed request at one=
=C2=A0 =C2=A0 =C2=A0 = end of the path.

<= /font>
4.12.2.=C2=A0 Distribu= ted Path Setup

=C2=A0 =C2=A0Whether a d= istributed alternative without a PCE can be valuable
=C2=A0 =C2=A0should be studied as well.=C2= =A0 Such an alternative could for instance
=C2=A0 =C2=A0inherit from the Resource ReSerVation Pro= tocol [RFC5127] (RSVP)
=C2=A0 =C2=A0flows.
<= br>
=C2=A0 =C2=A0In a = Layer-2 only environment, or as part of a layered approach to a
=C2=A0 =C2=A0mixed environment, I= EEE 802.1 also has work, either completed or in
=C2=A0 =C2=A0progress. =C2=A0[IEEE802.1Q-2011] Cl= ause 35 describes SRP, a peer-to-peer
=C2=A0 =C2=A0protocol for Layer-2 roughly analogous to RSVP= .=C2=A0 Almost complete is
=C2=A0 =C2=A0[IEEE802.1Qca], which defines how ISIS can provide multip= le disjoint
=C2=A0 =C2= =A0paths or distribution trees.=C2=A0 Also in progress is [IEEE802.1Qcc],
=C2=A0 =C2=A0which expa= nds the capabilities of SRP.





Fin= n & Thubert =C2=A0 =C2=A0 =C2=A0 =C2=A0 Expires September 10, 2015 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[Page 17]
=0C=
Internet-Draft =C2=A0 =C2=A0= Deterministic Networking Architecture =C2=A0 =C2=A0 =C2=A0 March 2015


5.=C2=A0 Related IETF work


=C2=A0 = =C2=A0[I-D.svshah-tsvwg-deterministic-forwarding] defines a Differentiated<= /font>
=C2=A0 =C2=A0Services = Per-Hop-Behavior (PHB) Group called Deterministic Forwarding
=C2=A0 =C2=A0(DF).=C2=A0 The documen= t describes the purpose and semantics of this PHB.
=C2=A0 =C2=A0It also describes creation and fo= rwarding treatment of the service
=C2=A0 =C2=A0class.=C2=A0 The document also describes how the c= ode-point can be mapped

5.2. =C2=A06TiSCH
<= font face=3D"monospace, monospace">
=C2=A0 =C2=A0Industrial process control already leverages= deterministic wireless
=C2=A0 =C2=A0resource= -constrained devices and form wireless mesh networks, with
=C2=A0 =C2=A0standards such as [ISA100= .11a] and [WirelessHART].

=C2=A0 =C2=A0= These standards rely on variations of the [IEEE802154e] timeSlotted<= /div>
=C2=A0 =C2=A0Channel Hopping = (TSCH) [I-D.ietf-6tisch-tsch] Medium Access Control
=C2=A0 =C2=A0(MAC), and a form of centralized= Path Computation Element (PCE), to
=C2=A0 =C2=A0deliver deterministic capabilities.
=

=C2=A0 =C2=A0The TSCH MAC benefits include high r= eliability against interference,
=C2=A0 =C2=A0low power consumption on characterized streams, and= Traffic
=C2=A0 =C2=A0= Engineering capabilities.=C2=A0 Typical applications are open and closed
=C2=A0 =C2=A0control loo= ps, as well as supervisory control streams and management.

=C2=A0 =C2=A0The 6TiSCH Working Group focuses only on t= he TSCH mode of the IEEE
=C2=A0 =C2=A0802.15.4e standard.=C2=A0 The WG currently defines a framew= ork for
=C2=A0 =C2=A0m= anaging the TSCH schedule.=C2=A0 Future work will standardize
<= div>=C2=A0 =C2=A0deterministic operatio= ns over so-called tracks as described in
=C2=A0 =C2=A0[I-D.ietf-6tisch-architecture].=C2=A0 Track= s are an instance of a
=C2=A0 =C2=A0deterministic path, and the DetNet work is a prerequisite to = specify
=C2=A0 =C2=A0t= rack operations and serve process control applications.

=C2=A0 =C2=A0[RFC5673] and [I-D.ietf-roll-rpl-industrial-a= pplicability] section
= =C2=A0 =C2=A02.1.3. =C2=A0and next discusses application-layer paradigms, s= uch as
=C2=A0 =C2=A0So= urce-sink (SS) that is a Multipeer to Multipeer (MP2MP) model that
=C2=A0 =C2=A0is primarily used= for alarms and alerts, Publish-subscribe (PS, or
=C2=A0 =C2=A0pub/sub) that is typically used fo= r sensor data, as well as Peer-to-
=C2=A0 =C2=A0peer (P2P) and Peer-to-multipeer (P2MP) communica= tions.=C2=A0 Additional
=C2=A0 =C2=A0prov= ided for improved reliability.





<= br>

<= div>Finn & Thubert =C2=A0 =C2=A0 = =C2=A0 =C2=A0 Expires September 10, 2015 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0[Page 18]
=0C
Internet-Draft =C2=A0 =C2=A0Deterministic Networking Archit= ecture =C2=A0 =C2=A0 =C2=A0 March 2015

=
6.=C2=A0 Security= Considerations

=C2=A0 =C2=A0Security i= n the context of Deterministic Networking has an added
=C2=A0 =C2=A0dimension; the time of delive= ry of a packet can be just as important
=C2=A0 =C2=A0as the contents of the packet, itself.=C2=A0= A man-in-the-middle attack,
=C2=A0 =C2=A0for example, can impose, and then systematically adjust= , additional
=C2=A0 = =C2=A0delays into a link, and thus disrupt or subvert a real-time
=C2=A0 =C2=A0application withou= t having to crack any encryption methods employed.
=C2=A0 =C2=A0See [RFC7384] for an exploration = of this issue in a related context.

=C2= =A0 =C2=A0Furthermore, in a control system where millions of dollars of
=C2=A0 =C2=A0equipment, o= r even human lives, can be lost if the DetNet QoS is not
<= font face=3D"monospace, monospace">=C2=A0 =C2=A0delivered, one must conside= r not only simple equipment failures,
=C2=A0 =C2=A0where the box or wire instantly becomes perfec= tly silent, but bizarre
TW> typo
=C2=A0 =C2=A0by software failures.=C2=A0 Because there is
=C2=A0 =C2=A0essentiall
TW> typo
<= div>=C2=A0 =C2=A0no limit to the kinds = of failures that can occur,
=C2=A0 =C2=A0protecting against realistic equipment failures is indis= tinguishable,
=C2=A0 = =C2=A0in most cases, from protecting against malicious behavior, whether
=C2=A0 =C2=A0accidental = or intentional.=C2=A0 See also Section 4.9.

=C2=A0 =C2=A0Security must cover:

= =C2=A0 =C2=A0o =C2=A0the protection of the signaling protocol
<= div>
=C2=A0 =C2=A0o =C2=A0the authentication and authoriz= ation of the controlling systems

=C2=A0= =C2=A0o =C2=A0the identification and shaping of the streams

7.=C2=A0 IANA Considerations

=C2=A0 =C2=A0This document does not require an action from IANA= .

8.=C2=A0 Acknowledgements

=C2=A0 =C2=A0The authors wish to thank Jouni Korh= onen, Erik Nordmark, George
=C2=A0 =C2=A0Swallow, Rudy Klecka, Anca Zamfir, David Black, Thomas W= atteyne,
=C2=A0 =C2=A0= Shitanshu Shah, Craig Gunther, Rodney Cummings, Wilfried Steiner,
=C2=A0 =C2=A0Marcel Kiessling, = Karl Weber, Ethan Grossman and Pat Thaler, for
=C2=A0 =C2=A0their various contribution with this= work.

9.=C2=A0 Informative References<= /font>

= =C2=A0 =C2=A0[AVnu] =C2=A0 =C2=A0 http://www.avnu.org/, &qu= ot;The AVnu Alliance tests and
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 certifies devices= for interoperability, providing a simple
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 and re= liable networking solution for AV network
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 implem= entation based on the Audio Video Bridging (AVB)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= standards.", .
<= br>

<= div>

Finn & Thubert =C2=A0 =C2=A0 =C2=A0 =C2=A0 Expires September 10, = 2015 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[Page 19]
=
=0C
Internet-Draft =C2= =A0 =C2=A0Deterministic Networking Architecture =C2=A0 =C2=A0 =C2=A0 March = 2015

=

=C2=A0 =C2=A0[CCAMP] =C2=A0 =C2=A0IETF, "Com= mon Control and Measurement Plane",
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <https://datatracker.ietf.org/doc/charter-ietf-ccamp/>.

=C2=A0 =C2=A0[HART] =C2=A0 =C2=A0 www.hartcomm.org, "Highwa= y Addressable Remote Transducer,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 a group of spec= ifications for industrial process and
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 control de= vices administered by the HART Foundation", .

=C2=A0 =C2=A0[HSR-PRP] =C2=A0IEC, "High availability seaml= ess redundancy (HSR) is a
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 further development of= the PRP approach, although HSR
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 functions primar= ily as a protocol for creating media
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 redundancy = while PRP, as described in the previous
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 section,= creates network redundancy.=C2=A0 PRP and HSR are both
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 described in the IEC 62439 3 standard.",
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 <http://webstore.iec.ch/webstore/webstore.nsf/
<= div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 artnum/046615!opendocument>.

=C2=A0 =C2=A0[I-D.finn-detnet-problem-statement]
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 Finn, N. and P. Thubert, "Deterministic Networking Problem<= /font>
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 Statement", draft-finn-detnet-problem-stat= ement-01 (work
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 in progress), October 2014.

=C2=A0 =C2=A0[I-D.ietf-6tisch-architecture]<= /font>
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 Thubert, P., Watteyne, T., Struik, R., and M. R= ichardson,
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "An Architecture for IPv6 over = the TSCH mode of IEEE
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 802.15.4e", draft-iet= f-6tisch-architecture-05 (work in
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 progress), Jan= uary 2015.

=
=C2=A0 =C2=A0[I-D.ietf-6tisc= h-tsch]
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Watteyne, T., Palattella, M., and L. Gri= eco, "Using
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 IEEE802.15.4e TSCH in an IoT = context: Overview, Problem
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Statement and Goals&q= uot;, draft-ietf-6tisch-tsch-05 (work in
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 progres= s), January 2015.

=
=C2=A0 =C2=A0[I-D.iet= f-roll-rpl-industrial-applicability]
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Phinney, T.= , Thubert, P., and R. Assimiti, "RPL
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 applic= ability in industrial networks", draft-ietf-roll-
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 rpl-industrial-applicability-02 (work in progress),
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 October 2013.

=C2=A0 =C2=A0[= I-D.svshah-tsvwg-deterministic-forwarding]
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Shah,= S. and P. Thubert, "Deterministic Forwarding PHB",
<= div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 draft-svshah-tsvwg-deterministic-forwarding-03 (work in
=C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 progress), March 2015.

=C2=A0 =C2=A0[IEEE802.1AS-2011]
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 IEEE, &quo= t;Timing and Synchronizations (IEEE 802.1AS-2011)",
<= font face=3D"monospace, monospace">=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 2011, <http://standards.ieee.org/getIEEE802/
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 download/802.1AS-2011.pdf>.

=

=
Finn & Thubert =C2=A0 =C2=A0 = =C2=A0 =C2=A0 Expires September 10, 2015 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0[Page 20]
=0C
Internet-Draft =C2=A0 =C2=A0Deterministic Networking Archit= ecture =C2=A0 =C2=A0 =C2=A0 March 2015

=
=C2=A0 =C2=A0[IEE= E802.1BA-2011]
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 IEEE, "AVB Systems (IEEE 802= .1BA-2011)", 2011,
http://standards.ieee.org/g= etIEEE802/
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 download/802.1BA-2011.pdf>.

=C2=A0 =C2=A0[IEEE802.1CB]
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 IEEE, "Seamless Redundancy (IEEE Draft P802.1CB)", = 2015,
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <http://p8021:go_wildcat= s@www.ieee802.org/1/files/private/
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 cb-drafts= />.

=C2=A0 =C2=A0[IEEE802.1Q-2011]
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 IEEE, "MAC Bridges and VLANs (IEEE 802.1Q-= 2011", 2011,
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <http://standards.ieee.org/getIEE= E802/
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 download/802.1Q-2011.pdf>.=

=C2=A0 =C2=A0[IEEE802.1Qat-2010]
=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 IEEE, "Stream Reservation Protocol (IEEE 802.1Qat-2010)= ",
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 2010, <http://standards.ieee.org/getIEEE802/=
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 download/802.1Qat-2010.pdf>.

=C2=A0 =C2=A0[IEEE802.1Qav]
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 IEEE, "Forwarding and Queuing (IEEE 802.1Qav-2009)", 2009,=
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 <http://standards.ieee.org/getIEEE802/
=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 download/802.1Qav-2009.pdf>.

=C2=A0 =C2=A0[IEEE802.1Qca]
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 IEEE, = "Path Control and Reservation", 2015,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = <http://p8021:go_wildcats@www.ieee802.org/1/files/private/<= /a>

=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 cc-drafts/>.

=C2=A0 =C2=A0[IEEE802.1TSNTG]
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 IEEE Standard= s Association, "IEEE 802.1 Time-Sensitive
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = Networks Task Group", 2013,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <http://www= .IEEE802.org/1/pages/avbridges.html>.

=C2=A0 =C2=A0[IEEE802154]
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 IEEE standard fo= r Information Technology, "IEEE std.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 802.15= .4, Part. 15.4: Wireless Medium Access Control (MAC)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 and Physical Layer (PHY) Specifications for Low-Rate
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 Wireless Personal Area Networks", June 2011.





Finn & Thubert =C2=A0 =C2=A0 =C2=A0 = =C2=A0 Expires September 10, 2015 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0[Page 21]
=0C
Internet-Draft =C2=A0 =C2=A0Deterministic Networking Architecture = =C2=A0 =C2=A0 =C2=A0 March 2015


=C2=A0 =C2=A0[IEEE802154= e]
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 IEEE standard for Information Technology, &= quot;IEEE std.
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 802.15.4e, Part. 15.4: Low-Rate W= ireless Personal Area
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Networks (LR-WPANs) Amendm= ent 1: MAC sublayer", April
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 2012.

=C2=A0 =C2=A0[ISA100.11a]
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 ISA/IEC, "ISA100.11a, Wireless Systems for Automation,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 also IEC 62734", 2011, < http://www.isa100wci.org/en-
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 US/Documents/PDF/3405-ISA100-WirelessSystems-Futur= e-broch-
=C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 WEB-ETSI.aspx>.

=C2=A0 =C2=A0[ODVA] =C2=A0 =C2=A0 http://www.odva.org/, "The organization = that supports
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 network technologies built on the= Common Industrial
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Protocol (CIP) including Ethe= rNet/IP.", .

=
=C2=A0 =C2=A0[PCE] = =C2=A0 =C2=A0 =C2=A0IETF, "Path Computation Element",
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 <https://datatracker.ietf.org/doc/charter-ietf-p= ce/>.

=C2=A0 =C2=A0[Profinet]
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 http://us.profinet.com/technology/profinet/, &q= uot;PROFINET is
=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 a standard for industrial networ= king in automation.",
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <http://us.profinet= .com/technology/profinet/>.

=C2= =A0 =C2=A0[RFC2205] =C2=A0Braden, B., Zhang, L., Berson, S., Herzog, S., an= d S.
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Jamin, "Resource ReSerVation Protocol = (RSVP) -- Version 1
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Functional Specification&q= uot;, RFC 2205, September 1997.

=C2=A0 = =C2=A0[RFC3209] =C2=A0Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan,= V.,
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 and G. Swallow, "RSVP-TE: Extensions t= o RSVP for LSP
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Tunnels", RFC 3209, December= 2001.

=C2=A0 =C2=A0[RFC4655] =C2=A0Far= rel, A., Vasseur, J., and J. Ash, "A Path Computation
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 Element (PCE)-Based Architecture", RFC 4655, August 2006.

<= font face=3D"monospace, monospace">=C2=A0 =C2=A0[RFC5127] =C2=A0Chan, K., B= abiarz, J., and F. Baker, "Aggregation of
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = Diffserv Service Classes", RFC 5127, February 2008.
<= font face=3D"monospace, monospace">
=C2=A0 =C2=A0[RFC5673] =C2=A0Pister, K., Thubert, P., Dwa= rs, S., and T. Phinney,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Networks&qu= ot;, RFC 5673, October 2009.

=C2=A0 =C2= =A0[RFC7384] =C2=A0Mizrahi, T., "Security Requirements of Time Protoco= ls in
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Packet Switched Networks", RFC 7384= , October 2014.


<= font face=3D"monospace, monospace">




Finn & Thubert =C2=A0 =C2=A0 =C2=A0 =C2=A0 Ex= pires September 10, 2015 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[P= age 22]
=0C
= Internet-Draft =C2=A0 =C2=A0Deterministic Networking Architecture =C2=A0 = =C2=A0 =C2=A0 March 2015


=C2=A0 =C2=A0[RFC7426] =C2=A0Ha= leplidis, E., Pentikousis, K., Denazis, S., Hadi Salim,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 J., Meyer, D., and O. Koufopavlou, "Software-Defined
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Networking (SDN): Layers and Architecture Terminology&quo= t;,
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 RFC 7426, January 2015.

=C2=A0 =C2=A0[TEAS] =C2=A0 =C2=A0 IETF, "Traffic Engi= neering Architecture and Signaling",
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <https://datatracker.ietf.org/doc/charter-ietf-teas/>.

=C2=A0 =C2=A0[WirelessHART]
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 www.hartcomm.o= rg, "Industrial Communication Networks -
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 Wireless Communication Network and Communication Profiles
<= div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 - WirelessHART - IEC 62591", 2010.

Authors' Addresses

= =C2=A0 =C2=A0Norm Finn
=C2=A0 =C2=A0Cisco Systems
=C2=A0 =C2=A0170 W Tasman Dr.
=C2=A0 =C2=A0San Jose, California =C2=A095134
=C2=A0 =C2=A0USA

=C2=A0 =C2=A0Phone: +1 408 526 4495
<= div>=C2=A0 =C2=A0Email: nfinn@cisco.com
=

=C2=A0 =C2=A0Cisco Systems
=C2=A0 =C2=A0Village d'Entreprises Green Side
=
=C2=A0 =C2=A0400, Avenue de Rouman= ille
=C2=A0 =C2=A0Bati= ment T3
=C2=A0 =C2=A0B= iot - Sophia Antipolis =C2=A006410
=C2=A0 =C2=A0FRANCE

=C2=A0= =C2=A0Phone: +33 4 97 23 26 34
=C2=A0 =C2=A0Email: pthubert@cisco.com




<= font face=3D"monospace, monospace">










<= br>
Finn & Thubert= =C2=A0 =C2=A0 =C2=A0 =C2=A0 Expires September 10, 2015 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[Page 23]
--047d7bfd062a5cd7e60511f762e2-- From nobody Mon Mar 23 15:50:08 2015 Return-Path: X-Original-To: detnet@ietfa.amsl.com Delivered-To: detnet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AE881A00FE; Mon, 23 Mar 2015 15:50:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.643 X-Spam-Level: X-Spam-Status: No, score=-5.643 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, HTML_TAG_BALANCE_BODY=1.157, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 ZpIfSrR6vt1c; Mon, 23 Mar 2015 15:49:50 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ACCD81A0022; Mon, 23 Mar 2015 15:49:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=269146; q=dns/txt; s=iport; t=1427150989; x=1428360589; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=8yphKrafSqzh7aWA0YCF6enOUzpQRKDfaGPvdM7YicU=; b=LX5F8KqLEuolW+VAL7D3jfbcuohQ7GQjJQ8LJNDGOT0XPWys1UYCbjtn w8wgNddphq2MwqaSyP6MoOASkFf6FZzhzC/taKLMGKoB3IhUulpxzr4yA BIeqkzOTUbeQNW0AQfseLRzVHzeTagHXHrRXf0NmWVk9L3c8Pj6bpPjuT Q=; X-Files: smime.p7s : 4831 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AgBgAGlxBV/4UNJK3JJ4orAgIB X-IronPort-AV: E=Sophos;i="5.11,454,1422921600"; d="p7s'?scan'208,217";a="134683191" Received: from alln-core-11.cisco.com ([173.36.13.133]) by alln-iport-1.cisco.com with ESMTP; 23 Mar 2015 22:49:48 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id t2NMnlZm032431 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 23 Mar 2015 22:49:47 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.225]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.03.0195.001; Mon, 23 Mar 2015 17:49:46 -0500 From: "Pascal Thubert (pthubert)" To: Thomas Watteyne , "detnet@ietf.org" , "6tisch@ietf.org" <6tisch@ietf.org> Thread-Topic: [Detnet] comments on draft-finn-detnet-architecture-00 Thread-Index: AQHQZYi+r+/2RRtLBkOnGfbJTO16iZ0qen8A Date: Mon, 23 Mar 2015 22:49:30 +0000 Deferred-Delivery: Mon, 23 Mar 2015 19:54:00 +0000 Message-ID: References: In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.82.250.102] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0216_01D06570.CCCB9160" MIME-Version: 1.0 Archived-At: Subject: Re: [Detnet] comments on draft-finn-detnet-architecture-00 X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussions on Deterministic Networking, characterized by 1\) resource reservation; 2\) 0 congestion loss and guaranteed latency; 3\) over L2-only and mixed L2 and L3 networks; and 5\) 1+1 replication/deletion." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 22:50:05 -0000 ------=_NextPart_000_0216_01D06570.CCCB9160 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0217_01D06570.CCCB9160" ------=_NextPart_001_0217_01D06570.CCCB9160 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Hello Thomas: I think that this should come from 6TiSCH based on experience from TSCH deployments, and be pushed to DetNet as requirements from the LLN/TSCH side. It is my hope that something like https://tools.ietf.org/html/draft-wang-6tisch-track-use-cases-00 evolves in that direction... Makes sense ? Pascal From: detnet [mailto:detnet-bounces@ietf.org] On Behalf Of Thomas Watteyne Sent: lundi 23 mars 2015 10:44 To: detnet@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. Finn Internet-Draft P. Thubert Intended status: Standards Track Cisco Expires: September 10, 2015 March 9, 2015 Deterministic Networking Architecture draft-finn-detnet-architecture-00 Abstract Deterministic Networking (DetNet) provides a capability to carry specified unicast or multicast data streams for real-time applications 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 for individual (or aggregated) DetNet streams in some or all of the relay systems (bridges or routers) along the path of the stream; 2) providing fixed paths for DetNet streams that do not rapidly change with the network topology; and 3) sequentializing, replicating, and eliminating duplicate packets at various points to ensure the availability of at least one path. The capabilities can be managed by configuration, or by manual or automatic network management. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months 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." This Internet-Draft will expire on September 10, 2015. Copyright Notice Copyright (c) 2015 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 Finn & Thubert Expires September 10, 2015 [Page 1] Internet-Draft Deterministic Networking Architecture March 2015 publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Providing the DetNet Quality of Service . . . . . . . . . . . 5 3.1. Zero Congestion Loss . . . . . . . . . . . . . . . . . . 6 3.2. Pinned-down paths . . . . . . . . . . . . . . . . . . . . 7 3.3. Seamless Redundancy . . . . . . . . . . . . . . . . . . . 7 4. DetNet Architecture . . . . . . . . . . . . . . . . . . . . . 8 4.1. The Application Plane . . . . . . . . . . . . . . . . . . 11 4.2. The Controller Plane . . . . . . . . . . . . . . . . . . 11 4.3. The Network Plane . . . . . . . . . . . . . . . . . . . . 12 4.4. Elements of DetNet Architecture . . . . . . . . . . . . . 13 4.5. DetNet streams . . . . . . . . . . . . . . . . . . . . . 14 4.5.1. Talker guarantees . . . . . . . . . . . . . . . . . . 14 4.5.2. Incomplete Networks . . . . . . . . . . . . . . . . . 15 4.6. Data Flow Model through Systems . . . . . . . . . . . . . 16 4.7. Queuing, Shaping, Scheduling, and Preemption . . . . . . 16 4.8. Coexistence with normal traffic . . . . . . . . . . . . . 16 4.9. Fault Mitigation . . . . . . . . . . . . . . . . . . . . 16 4.10. Protocol Stack Model . . . . . . . . . . . . . . . . . . 17 4.11. Advertising resources, capabilities and adjacencies . . . 17 4.12. Provisioning model . . . . . . . . . . . . . . . . . . . 17 4.12.1. Centralized Path Computation and Installation . . . 17 4.12.2. Distributed Path Setup . . . . . . . . . . . . . . . 17 5. Related IETF work . . . . . . . . . . . . . . . . . . . . . . 18 5.1. Deterministic PHB . . . . . . . . . . . . . . . . . . . . 18 5.2. 6TiSCH . . . . . . . . . . . . . . . . . . . . . . . . . 18 6. Security Considerations . . . . . . . . . . . . . . . . . . . 19 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 9. Informative References . . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 1. Introduction Operational Technology (OT) refers to industrial networks that are typically 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., discrete manufacturing). 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 use focusing on highly secure, reliable and deterministic networks, with limited scalability over a bounded area. The convergence of IT and OT technologies, also called the Industrial Internet, represents a major evolution for both sides. The work has already started; in particular, the industrial automation space has been developing a number of Ethernet-based replacements for existing digital control systems, often not packet-based (fieldbus technologies). These replacements are meant to provide similar behavior as the incumbent protocols, and their common focus is to transport TW> "on transporting"? a fully characterized flow over a well-controlled environment (i.e., a factory floor), with a bounded latency, extraordinarily low frame loss, and a very narrow jitter. Examples of such protocols include PROFINET, 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 help In 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 for connectivity and multimedia in transportation in general, the Ethernet AVB technology has become one of the hottest topics, in particular in the automotive connectivity. It is finding application in all elements of the vehicle TW> ":" from head units, to rear seat entertainment modules, to amplifiers and camera modules. While aimed at less critical applications than some industrial networks, AVB networks share the requirement for extremely low packet loss rates and ensured finite latency and jitter. TW> ensure -> guarantee? Other instances of in-vehicle deterministic networks have arisen as well for control networks in cars, trains and buses, as well as avionics, with, for instance, the mission-critical "Avionics Full- Duplex Switched Ethernet" (AFDX) that was designed as part of the ARINC 664 standards. Existing automotive control networks such as the LIN, CAN and TW> would TTP/C fit in this list? FlexRay standards were not designed to cover these increasing demands in terms of bandwidth and scalability that we see with various kinds of Driver Assistance Systems (DAS) and new multiplexing technologies based on Ethernet are now getting traction. The generalization of the needs for more deterministic networks have led to the IEEE 802.1 AVB Task Group becoming the Time-Sensitive Networking (TSN) Task Group (TG), with a much-expanded constituency from the industrial and vehicular markets. Along with this expansion, the networks in consideration are becoming larger and structured, requiring deterministic forwarding beyond the LAN boundaries. For instance, Industrial Automation segregates the network 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, and public infrastructures such as Electricity Automation require deterministic properties over the Wide Area. The realization is now coming 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 IETF and the IEEE and implements an abstract model that can be applicable both at Layer-2 and Layer-3, and along segments of different technologie. TW> typo With 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 be operating at Layer-2 over Ethernet whereas the IP routers may be 6TiSCH nodes operating at Layer-2 and/or Layer-3 over the IEEE 802.15.4e MAC. Many applications of interest to Deterministic Networking require the ability to synchronize the clocks in end systems to a sub-microsecond accuracy. TW> why this accuracy? Some of the queue control techniques defined in Section 4.7 also require time synchronization among relay systems. The means used to achieve time synchronization are not addressed in this document. 2. Terminology The follwing TW> typo special terms are used in this document in order to avoid the assumption that a given element in the archetecture TW> typo does or does not have Internet Protocol stack, functions as a router or a bridge, or otherwise plays a particular role at Layer-3 or higher: TW> I don't get the sentence above bridge A Customer Bridge as defined by IEEE 802.1Q [IEEE802.1Q-2011]. circuit A trail of configuration from talker to listener(s) TW> sender and receiver might be more common at the IETF? through relay systems associated with a DetNet stream, required to deliver the benefits of DetNet. end system Commonly called a "host" in IETF documents, and an "end station" is IEEE 802 documents. End systems of interest to this document are talkers and listeners. listener An 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? stream A DetNet stream is a sequence of packets from a single talker, through some number of relay systems to one or more listeners, that is limited by the talker in its maximum packet size and transmission rate, and can thus be ensured the DetNet Quality of Service (QoS) from the network. talker An 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 of the relay systems and links; o Probability of loss of a packet in the event of the failure of a relay 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, or typical values are of no interest, because they do not affect the ability of a real-time system to perform its tasks. TW> Would it make sense to discuss hard and soft real-time here, in TW> particular in the context of a wireless system? Three techniques are employed by DetNet to achieve these QoS parameters: a. Zero congestion loss (Section 3.1). Network resources such as link bandwidth, buffers, queues, shapers, and scheduled input/ TW> add 6TiSCH cells? output slots are assigned in each relay system to the use of a specific DetNet stream or group of streams. Note that, given a finite amount of buffer space) TW> extra ")" , zero congestion loss necessarily ensures a maximum end-to-end latency. Depending on the method employed, 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 or more listeners can be established, and DetNet streams assigned to follow a particular path or tree. TW> Using a single path in a wireless system will fail, I would recommend TW> 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 eliminate replicated 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 at least one path intact for a DetNet stream. These three techniques can be applied independently, giving eight possible combinations, including none (no DetNet), although some combinations are of wider utility than others. This separation keeps the protocol stack coherent and maximizes interoperability with existing and developing standards in this (IETF) and other Standards Development Organizations. Some examples of typical expected combinations: o Pinned-down paths (a) plus packet replication (b) are exactly the techniques employed by [HSR-PRP]. Pinned-down paths are achieve by limiting the physical topology of the network, and the sequentialization, replication, and duplicate elimination facilitated by packet tags added at the front or the end of Ethernet frames. o Zero congestion loss (a) alone is is offered by IEEE 802.1 Audio Video bridging [IEEE802.1BA-2011]. As long as the network suffers no failures, near-zero (at best, zero) congestion loss can be achieved through the use of a reservation protocol (MSRP) and shapers 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 satisfactory for many applications. However, these methods generally work best in the absence of any significant amount of non-critical traffic in the network (if, indeed, such traffic is supported at all), or work only if the critical traffic constitutes only a small portion of the network's theoretical capacity, or work only if all systems are functioning properly, or in the absence of actions by end systems that disrupt the network's operations. There are any number of methods in use, defined, or in progress for accomplishing each of the above techniques. It is expected that this DetNet Architecture will assist various vendors, users, and/or "vertical" Standards Development Organizations (dedicated to a single industry) to make selections among the available means of implementing DetNet networks. 3.1. Zero Congestion Loss The primary means by which DetNet achieves its QoS assurances is to completely eliminate congestion at an output port as a cause of packet 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 at each hop through the network to ensure that no packets are dropped due to a lack of buffer storage. TW> and the provision the sufficient link bandwidth? Ensuring adequate buffering requires, in turn, that the talker, and every relay system along the path to the listener (or nearly every relay system -- see Section 4.5.2) be careful to regulate its output to not exceed the data rate for any stream, except for brief perios TW> typo when making up for interfering traffic. Any packet sent ahead of its time potentially adds to the number of buffers required by the next hop, and may thus exceed the resources allocated for a particular stream. The low-level mechanisms described in Section 4.7 provide the necessary regulation of transmissions by an edge system or relay system to ensure zero congestion loss. Of course, the reservation of the bandwidth and buffers for a stream requires the provisioning described in Section 4.12. 3.2. Pinned-down paths In networks controlled by typical peer-to-peer protocols such as IEEE 802.1 ISIS bridged networks or ETF OSPF routed networks, a network topology event in one part of the network can impact, at least briefly, the delivery of data in parts of the network remote from the failure or recovery event. Thus, even redundant paths through a network, if controlled by the typical peer-to-peer protocols, do not eliminate 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 minimizes recovery time and easily supports redundant paths. Of course, this comes at the cost of increased hop count, and thus latency, for the typical path. In order to get the advantages of low hop count and still ensure against even brief losses of connectivity, DetNet employs pinned-down paths, where the path taken by a given DetNet stream does not change, at least immediately, and likely not at all, in response to network topology events. When combined with seamless redundancy (Section 3.3), this results in a high likelihood of continuous connectivity. 3.3. Seamless Redundancy After congestion loss has been eliminated, the most important causes of packet loss are random media and/or memory faults and equipment failures. 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 at least two different paths to the listener(s). o Discarding duplicated packets. In the simplest case, this amounts to replicating each packet in a talker that has two interfaces, and conveying them through the network, along separate paths, to the similarly dual-homed listeners, that discard the extras. This ensures that one path (with zero congestion loss) remains, even if some relay system fails. TW> this has some energy cost associated? Alternatively, relay systems in the network can provide replication and elimination facilities at various points in the network, so that multiple failures can be accommodated. This is shown in the following figure, where the two relay systems each replicate (R) the DetNet stream on input, sending the stream to both the other relay system and to the end system, and eliminated duplicates (E) on the output interface to the right-hand end system. Any one links TW> typo in the network can fail, and the Detnet stream can still get through. Furthermore, two links can fail, as long as they are in different segments of the network. > > > > > > > > relay > > > > > > > > > /------------+ R system E +------------\ > > / v + ^ \ > end R + v | ^ + E end system + v | ^ + system > \ v + ^ / > > \------------+ R relay E +------------/ > > > > > > > > > system > > > > > > > > Figure 1 TW> I don't understand what R and E means 4. DetNet Architecture Traffic Engineering Architecture and Signaling (TEAS) [TEAS] defines traffic-engineering architectures for generic applicability across packet and non-packet networks. From TEAS perspective, Traffic Engineering (TE) refers to techniques that enable operators to control how specific traffic flows are treated within their networks. Because if its very nature of establishing pinned-down optimized paths, 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 a separation into planes. The Deterministic Networking architecture is thus composed of three planes, a (User) Application Plane, a Controller Plane, and a Network Plane, which echoes that of Software-Defined Networking (SDN): TW> double ":" Layers and 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 and services. In particular, the Application Plane incorporates the User Agent, a specialized application that interacts with the end user / operator and performs requests for Deterministic Networking services via an abstract Stream Management Entity, (SME) which may or may not be collocated with (one of) the end systems. At the Application Plane, a management interface enables the negotiation of streams between end systems. An abstraction of the stream called a Traffic Specification (TSpec) provides the representation. This abstraction is used to place a reservation over the (Northbound) Service Interface and within the Application plane. It is associated with an abstraction of location, such as IP addresses and DNS names, to identify the end systems and eventually specify intermediate relay systems. 4.2. The Controller Plane The Controller Plane corresponds to the aggregation of the Control and Management Planes in [RFC7426], though Common Control and Measurement Plane (CCAMP) [CCAMP] makes an additional distinction between management and measurement. When the logical separation of the Control, Measurement and other Management entities is not relevant, the term Controller Plane is used for simplicity to represent them all, and the term controller refers to any device operating in that plane, whether is it a Path Computation entity or a Network Management entity (NME). The Path Computation Element (PCE) [PCE] is a core element of a controller, in charge of computing Deterministic paths to be applied in the Network Plane. A (Northbound) Service Interface enables applications in the Application Plane to communicate with the entities in the Controller Plane. TW> could you define NME, SME and PCE in the terminology? One or more PCE(s) collaborate to implement the requests from the SME as Per-Stream Per-Hop Behaviors installed in the relay systems for each individual streams. The PCEs place each stream along a deterministic sequence of relay systems so as to respect per-stream constraints such as security and latency, and optimize the overall result for metrics such as an abstract aggregated cost. The deterministic sequence can typically be more complex than a direct sequence and include redundancy path, with one or more packet replication 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 a whole, regardless of the Layer at which the network devices operate. The network Plane comprises the Network Interface Cards (NIC) in the end systems, which are typically IP hosts, and relay systems, which are typically IP routers and switches. Network-to-Network Interfaces such as used for Traffic Engineering path reservation in [RFC3209], as well as User-to-Network Interfaces (UNI) such as provided by the Local Management Interface (LMI) between network and end systems, are all part of the Network Plane. A Southbound (Network) Interface enables the entities in the Controller Plane to communicate with devices in the Network Plane. This interface leverages and extends TEAS to describe the physical topology and resources in the Network Plane. Stream Management Entity End End System System -+-+-+-+-+-+-+ Northbound -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- PCE PCE PCE PCE -+-+-+-+-+-+-+ Southbound -+-+-+-+-+-+-+-+-+-+--+-+-+-+-+-+- Relay Relay Relay Relay System System System System NIC NIC Relay Relay Relay Relay System System System System Figure 3 The relay systems (and eventually the end systems NIC) expose their capabilities and physical resources to the controller (the PCE), and update the PCE with their dynamic perception of the topology, across the Southbound Interface. In return, the PCE(s) set the per-stream paths up, providing a Stream Characterization that is more tightly coupled to the relay system Operation than a TSpec. At the Network plane, relay systems exchange information regarding the state of the paths, between adjacent systems and eventually with the 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 resort operation such as drop or declassify. This specification focuses on the Southbound interface and the operation of the Network Plane. 4.4. Elements of DetNet Architecture The DetNet architecture has a number of elements, discussed in the following sections: a. A model for the definition, identification, and operation of DetNet streams (Section 4.5), for use by relay systems to classify and process individual packets following per-stream rules. TW> how is a packet "labeled" as part of stream? b. A model for the flow of data from an end system or through a relay system that can be used to predict the bounds for that system's impact on the QoS of a DetNet stream, without significantly constraining the method of implementing that system, for use by the Controllers to configure policing and shaping 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 end system or relay system to control the selection of packets output on an interface. These models must have sufficiently well-defined characteristics, both individually and in the aggregate, to give predictable results for the QoS for DetNet packets (Section 4.7). 2. A model for identifying misbehaving DetNet streams and mitigating their impact on properly functioning streams (Section 4.9). c. A model for the relay system to inform the controller(s) of the information 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. hysical TW> typo resources (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 relay systems, to forward a DetNet stream over a simple or redundant path. The model includes: 1. A model for an abstract relaying operation of either Routing or forwarding packets of a DetNet stream to a next-hop relay system, across Layer boundaries. 2. A model of next-hop(s) information for replicating the packets of a DetNet stream, typically at or near the talker, merging and/or re-replicating those packets at other points in the network, and finally eliminating the duplicates, typically at or near the listener(s), in order to provide high availability (Section 3.3). e. The protocol stack model for an end system and/or a relay system should support the above elements in a manner that maximizes the applicability of existing standards and protocols to the DetNet problem, allows for the creation of new protocols where needed, thus making DetNet an add-on feature to existing networks, rather than a new way to do networking. In particular this protocol stack supports networks in which the path from talker to listener(s) includes bridges and/or routers in any order (Section 4.10). f. A variety of models for the provisioning of DetNet streams can be envisioned, including orchestration by a central controller or by a federation of controllers, provisioning by relay systems and end systems sharing peer-to-peer protocols, by off-line configuration, or by a combination of these methods. The provisioning models are similar to existing Layer-2 and Layer-3 models, in order to minimize the amount of innovation required in this area (Section 4.12). 4.5. DetNet streams 4.5.1. Talker guarantees DetNet streams can by synchronous or asynchronous. The transmission of packets in synchronous DetNet streams uses time synchronization among 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 observation interval. These parameters, together with knowledge of the protocol stack used (and thus the size of the various headers added to a packet), limit the number of bit times per observation interval that the DetNet stream can occupy the physical medium. The talker promises that these limits will not be exceeded. If the talker transmits less data than this limit allows, the unused resources such as link bandwidth can be made available by the system to non-DetNet packets. However, making those resources available to DetNet packets in other streams would serve no purpose. Those other streams have their own dedicated resources, on the assumption that all DetNet streams can use all of their resources over a long period of time. Note that there is no provision in DetNet for throttling streams; the assumption is that a DetNet stream, to be useful, must be delivered in its entirety. That is, while any useful application is written to expect a certain number of lost packets, the real-time applications of interest to DetNet demand that the loss of data due to the network is extraordinarily infrequent. Although DetNet strives to minimize the changes required of an application to allow it to shift from a special-purpose digital network to an Internet Protocol network, one fundamental shift in the behavior of network applications that is impossible to avoid--the reservation of resources before the application starts. In the first place, a network cannot deliver finite latency and practically zero packet loss to an arbitrarily high offered load. Secondly, achieving practically zero packet loss for unthrottled (though bandwidth limited) streams means that bridges and routers have to dedicate buffer resources to specific streams or to classes of streams. The requirements of each reservation have to be translated into the parameters that control each system's queuing, shaping, and scheduling functions and delivered to the hosts, bridges, and routers. 4.5.2. Incomplete Networks The presence in the network of relay systems that are not fully capable of offering DetNet services complicates the ability of the relay systems and/or controller to allocate resources, as extra buffering, and thus extra latency, must be allocated at each point that is downstream from the non-DetNet relay system for some DetNet stream. 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 Group has defined a set of queuing, shaping, and scheduling algorithms that enable each bridge or router to compute the exact number of buffers to 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 the network bandwidth to DetNet streams. But, no matter how much is dedicated for DetNet streams, It is z TW> typo goal of DetNet to not interfere excessively with existing QoS schemes. It is also important that non-DetNet traffic not disrupt the DetNet stream, of course (see Section 4.9 and Section 6). For these reasons: o Bandwidth (transmission opportunities) not utilized by a DetNet stream are available to non-DetNet packets (though not to other DetNet 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 scheduled in detail, then the algorithm constructing the schedule should leave sufficient opportunities for non-DetNet packets to satisfy the needs of the uses of the network. Ideally, the net effect of the presence of DetNet streams in a network on the non-DetNet packets is primarily a reductoin TW> typo in the available bandwidth. 4.9. Fault Mitigation One key to building robust real-time systems is to reduce the infinite variety of possible failures to a number that can be analyzed with reasonable confidence. DetNet aids in the process by providing filters and policers to detect DetNet packets received on the 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 the offending interface. It is also essential that filters and service remarking TW> please define "service remarking" be employed to prevent non-DetNet packets from impinging on the resources allocated 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 of standardization, that can perform these fault mitigation tasks that deliver a high probability that misbehaving systemd TW> typo will have zero impact on well-behaved DetNet streams, except of course, for the receiving interface(s) immediately downstream of the misbehaving device. 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 in progress, 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 model is attractive but a number of issues are left to be solved. In particular: o whether and how the path computation can be installed by 1) an end device or 2) a Network Management entity, o and how the path is set up, either by installing state at each hop with a direct interaction between the forwarding device and the PCE, or along a path by injecting a source-routed request at one end of the path. 4.12.2. Distributed Path Setup Whether a distributed alternative without a PCE can be valuable should be studied as well. Such an alternative could for instance inherit from the Resource ReSerVation Protocol [RFC5127] (RSVP) flows. In a Layer-2 only environment, or as part of a layered approach to a mixed environment, IEEE 802.1 also has work, either completed or in progress. [IEEE802.1Q-2011] Clause 35 describes SRP, a peer-to-peer protocol for Layer-2 roughly analogous to RSVP. Almost complete is [IEEE802.1Qca], which defines how ISIS can provide multiple disjoint paths 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 Differentiated Services 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 service class. The document also describes how the code-point can be mapped into one of the aggregated Diffserv service classes [RFC5127]. 5.2. 6TiSCH Industrial process control already leverages deterministic wireless Low power and Lossy Networks (LLNs) to interconnect critical resource-constrained devices and form wireless mesh networks, with standards such as [ISA100.11a] and [WirelessHART]. These standards rely on variations of the [IEEE802154e] timeSlotted Channel Hopping (TSCH) [I-D.ietf-6tisch-tsch] Medium Access Control (MAC), and a form of centralized Path Computation Element (PCE), to deliver deterministic capabilities. The TSCH MAC benefits include high reliability against interference, low power consumption on characterized streams, and Traffic Engineering capabilities. Typical applications are open and closed control loops, as well as supervisory control streams and management. The 6TiSCH Working Group focuses only on the TSCH mode of the IEEE 802.15.4e standard. The WG currently defines a framework for managing the TSCH schedule. Future work will standardize deterministic operations over so-called tracks as described in [I-D.ietf-6tisch-architecture]. Tracks are an instance of a deterministic path, and the DetNet work is a prerequisite to specify track operations and serve process control applications. [RFC5673] and [I-D.ietf-roll-rpl-industrial-applicability] section 2.1.3. and next discusses application-layer paradigms, such as Source-sink (SS) that is a Multipeer to Multipeer (MP2MP) model that is primarily used for alarms and alerts, Publish-subscribe (PS, or pub/sub) that is typically used for sensor data, as well as Peer-to- peer (P2P) and Peer-to-multipeer (P2MP) communications. Additional considerations on Duocast and its N-cast generalization are also provided 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 added dimension; the time of delivery of a packet can be just as important as the contents of the packet, itself. A man-in-the-middle attack, for example, can impose, and then systematically adjust, additional delays into a link, and thus disrupt or subvert a real-time application 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 of equipment, or even human lives, can be lost if the DetNet QoS is not delivered, one must consider not only simple equipment failures, where the box or wire instantly becomes perfectly silent, but bizarre errors such as can be coused TW> typo by software failures. Because there is essentiall TW> typo no limit to the kinds of failures that can occur, protecting against realistic equipment failures is indistinguishable, in most cases, from protecting against malicious behavior, whether accidental 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, George Swallow, 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, for their various contribution with this work. 9. Informative References [AVnu] http://www.avnu.org/, "The AVnu Alliance tests and certifies devices for interoperability, providing a simple and reliable networking solution for AV network implementation 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", . [HART] www.hartcomm.org, "Highway Addressable Remote Transducer, a group of specifications for industrial process and control devices administered by the HART Foundation", . [HSR-PRP] IEC, "High availability seamless redundancy (HSR) is a further development of the PRP approach, although HSR functions primarily as a protocol for creating media redundancy while PRP, as described in the previous section, creates network redundancy. PRP and HSR are both described in the IEC 62439 3 standard.", . [I-D.finn-detnet-problem-statement] Finn, N. and P. Thubert, "Deterministic Networking Problem Statement", draft-finn-detnet-problem-statement-01 (work in 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 IEEE 802.15.4e", draft-ietf-6tisch-architecture-05 (work in progress), January 2015. [I-D.ietf-6tisch-tsch] Watteyne, T., Palattella, M., and L. Grieco, "Using IEEE802.15.4e TSCH in an IoT context: Overview, Problem Statement and Goals", draft-ietf-6tisch-tsch-05 (work in progress), January 2015. [I-D.ietf-roll-rpl-industrial-applicability] Phinney, T., Thubert, P., and R. Assimiti, "RPL applicability 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 in progress), March 2015. [IEEE802.1AS-2011] IEEE, "Timing and Synchronizations (IEEE 802.1AS-2011)", 2011, . 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, . [IEEE802.1CB] IEEE, "Seamless Redundancy (IEEE Draft P802.1CB)", 2015, . [IEEE802.1Q-2011] IEEE, "MAC Bridges and VLANs (IEEE 802.1Q-2011", 2011, . [IEEE802.1Qat-2010] IEEE, "Stream Reservation Protocol (IEEE 802.1Qat-2010)", 2010, . [IEEE802.1Qav] IEEE, "Forwarding and Queuing (IEEE 802.1Qav-2009)", 2009, . [IEEE802.1Qca] IEEE, "Path Control and Reservation", 2015, . [IEEE802.1Qcc] IEEE, "Stream Reservation Protocol (SRP) Enhancements and Performance Improvements", 2015, . [IEEE802.1TSNTG] IEEE Standards Association, "IEEE 802.1 Time-Sensitive Networks 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-Rate Wireless 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 Area Networks (LR-WPANs) Amendment 1: MAC sublayer", April 2012. [ISA100.11a] ISA/IEC, "ISA100.11a, Wireless Systems for Automation, also IEC 62734", 2011, < http://www.isa100wci.org/en- US/Documents/PDF/3405-ISA100-WirelessSystems-Future-broch- WEB-ETSI.aspx>. [ODVA] http://www.odva.org/, "The organization that supports network technologies built on the Common Industrial Protocol (CIP) including EtherNet/IP.", . [PCE] IETF, "Path Computation Element", . [Profinet] http://us.profinet.com/technology/profinet/, "PROFINET is a standard for industrial networking in automation.", . [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional 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 LSP Tunnels", RFC 3209, December 2001. [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, August 2006. [RFC5127] Chan, K., Babiarz, J., and F. Baker, "Aggregation of Diffserv Service Classes", RFC 5127, February 2008. [RFC5673] Pister, K., Thubert, P., Dwars, S., and T. Phinney, "Industrial Routing Requirements in Low-Power and Lossy Networks", RFC 5673, October 2009. [RFC7384] Mizrahi, T., "Security Requirements of Time Protocols in Packet 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-Defined Networking (SDN): Layers and Architecture Terminology", RFC 7426, January 2015. [TEAS] IETF, "Traffic Engineering Architecture and Signaling", . [WirelessHART] www.hartcomm.org, "Industrial Communication Networks - Wireless Communication Network and Communication Profiles - WirelessHART - IEC 62591", 2010. Authors' Addresses Norm Finn Cisco Systems 170 W Tasman Dr. San Jose, California 95134 USA Phone: +1 408 526 4495 Email: nfinn@cisco.com Pascal Thubert Cisco Systems Village d'Entreprises Green Side 400, Avenue de Roumanille Batiment T3 Biot - Sophia Antipolis 06410 FRANCE Phone: +33 4 97 23 26 34 Email: pthubert@cisco.com Finn & Thubert Expires September 10, 2015 [Page 23] ------=_NextPart_001_0217_01D06570.CCCB9160 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Hello Thomas:

 

I think that this should come from 6TiSCH based on experience from = TSCH deployments, and be pushed to DetNet as requirements from the = LLN/TSCH side.

It is my hope that something like https://tools.ietf.org/html/draft-wang-6tisch-track-use-cases-00 = evolves in that direction...

 

Makes sense ?

 

Pascal

 

From:= = detnet [mailto:detnet-bounces@ietf.org] On Behalf Of Thomas = Watteyne
Sent: lundi 23 mars 2015 10:44
To: = detnet@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. = Finn

Internet-Draft       =                     =                     =  P. Thubert

Intended = status: Standards Track               =                     = Cisco

Expires: September 10, 2015   =                     =          March 9, = 2015

 

 

  =                Deterministic = Networking Architecture

  =                 =  draft-finn-detnet-architecture-00

<= p class=3DMsoNormal> 

Abstract

 

  =  Deterministic Networking (DetNet) provides a capability to = carry

   specified unicast or = multicast data streams for real-time

  =  applications 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 = for

   individual (or = aggregated) DetNet streams in some or all of the = relay

   systems (bridges or = routers) along the path of the stream; = 2)

   providing fixed paths = for DetNet streams that do not rapidly = change

   with the network = topology; and 3) sequentializing, replicating, = and

   eliminating duplicate = packets at various points to ensure = the

   availability of at = least one path.  The capabilities can be = managed

   by configuration, or by = manual or automatic network = management.

 

Status of = This Memo

 

  =  This Internet-Draft is submitted in full conformance with = the

   provisions of BCP 78 = and BCP 79.

 

  =  Internet-Drafts are working documents of the Internet = Engineering

   Task Force = (IETF).  Note that other groups may also = distribute

   working documents as = Internet-Drafts.  The list of current = Internet-

 

  =  Internet-Drafts are draft documents valid for a maximum of six = months

   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."

 

  =  This Internet-Draft will expire on September 10, = 2015.

 

Copyright = Notice

 

  =  Copyright (c) 2015 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

 

 

 

Finn & = Thubert         Expires September 10, 2015   =             [Page = 1]

Internet-Draft   =  Deterministic Networking Architecture       March = 2015

 

 

  =  publication of this document.  Please review these = documents

   carefully, as they = describe your rights and restrictions with = respect

   to this document.  = Code Components extracted from this document = must

   include Simplified BSD = License text as described in Section 4.e = of

   the Trust Legal = Provisions and are provided without warranty = as

   described in the = Simplified BSD License.

 

Table of = Contents

 

  =  1.  Introduction  . . . . . . . . . . . . . . . . . . . = . . . . .   2

  =  2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . = . .   4

   3.  Providing the = DetNet Quality of Service . . . . . . . . . . .   = 5

     3.1.  Zero = Congestion Loss  . . . . . . . . . . . . . . . . . .   = 6

     3.2.  = Pinned-down paths . . . . . . . . . . . . . . . . . . . .   = 7

     3.3.  = Seamless Redundancy . . . . . . . . . . . . . . . . . . .   = 7

   4.  DetNet = Architecture . . . . . . . . . . . . . . . . . . . . .   = 8

     4.1.  The = Application Plane . . . . . . . . . . . . . . . . . . =  11

     4.2.  The = Controller Plane  . . . . . . . . . . . . . . . . . . =  11

     4.3.  The = Network Plane . . . . . . . . . . . . . . . . . . . . =  12

     4.4.  = Elements of DetNet Architecture . . . . . . . . . . . . . =  13

     4.5.  = DetNet streams  . . . . . . . . . . . . . . . . . . . . . =  14

      =  4.5.1.  Talker guarantees . . . . . . . . . . . . . . . . . . =  14

      =  4.5.2.  Incomplete Networks . . . . . . . . . . . . . . . . . =  15

     4.6.  Data = Flow Model through Systems . . . . . . . . . . . . . =  16

     4.7.  = Queuing, Shaping, Scheduling, and Preemption  . . . . . . =  16

     4.8.  = Coexistence with normal traffic . . . . . . . . . . . . . =  16

     4.9.  Fault = Mitigation  . . . . . . . . . . . . . . . . . . . . =  16

     4.10. Protocol = Stack Model  . . . . . . . . . . . . . . . . . . =  17

     4.11. = Advertising resources, capabilities and adjacencies . . . =  17

     4.12. = Provisioning model  . . . . . . . . . . . . . . . . . . . =  17

      =  4.12.1.  Centralized Path Computation and Installation =  . . .  17

  =      4.12.2.  Distributed Path Setup . . . . . . . . = . . . . . . .  17

  =  5.  Related IETF work . . . . . . . . . . . . . . . . . . . . = . .  18

     5.1.  = Deterministic PHB . . . . . . . . . . . . . . . . . . . . =  18

     5.2. =  6TiSCH  . . . . . . . . . . . . . . . . . . . . . . . . . =  18

   6.  Security = Considerations . . . . . . . . . . . . . . . . . . . =  19

   7.  IANA = Considerations . . . . . . . . . . . . . . . . . . . . . =  19

   8.  = Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . =  19

   9.  Informative = References  . . . . . . . . . . . . . . . . . . . =  19

   Authors' Addresses =  . . . . . . . . . . . . . . . . . . . . . . . =  23

 

1.  = Introduction

 

  =  Operational Technology (OT) refers to industrial networks that = are

   typically 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., = discrete

   manufacturing).  = 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 = use

   focusing on highly = secure, reliable and deterministic networks, = with

   limited scalability = over a bounded area.

 

  =  The convergence of IT and OT technologies, also called the = Industrial

   Internet, represents a = major evolution for both sides.  The work = has

   already started; in = particular, the industrial automation space = has

   been developing a = number of Ethernet-based replacements for = existing

   digital control = systems, often not packet-based = (fieldbus

  =  technologies).

 

  =  These replacements are meant to provide similar behavior as = the

   incumbent protocols, = and their common focus is to = transport

TW> "on = transporting"?

  =  a fully

   characterized flow over = a well-controlled environment (i.e., = a

   factory floor), with a = bounded latency, extraordinarily low = frame

   loss, and a very narrow = jitter.  Examples of such protocols = include

   PROFINET, 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 = help

   In 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 = for

   connectivity and = multimedia in transportation in general, = the

   Ethernet AVB technology = has become one of the hottest topics, = in

   particular in the = automotive connectivity.  It is finding = application

   in all elements of the = vehicle

TW> = ":"

   from head units, to = rear seat

   entertainment modules, = to amplifiers and camera modules.  While = aimed

   at less critical = applications than some industrial networks, = AVB

   networks share the = requirement for extremely low packet loss = rates

   and ensured finite = latency and jitter.

TW> = ensure -> guarantee?

 

  =  Other instances of in-vehicle deterministic networks have arisen = as

   well for control = networks in cars, trains and buses, as well = as

   avionics, with, for = instance, the mission-critical "Avionics = Full-

   Duplex Switched = Ethernet" (AFDX) that was designed as part of = the

   ARINC 664 = standards.  Existing automotive control networks such = as

   the LIN, CAN = and

TW> would TTP/C fit in this = list?

   FlexRay standards were = not designed to cover these

  =  increasing demands in terms of bandwidth and scalability that we = see

   with various kinds of = Driver Assistance Systems (DAS) and = new

   multiplexing = technologies based on Ethernet are now getting = traction.

 

  =  The generalization of the needs for more deterministic networks = have

   led to the IEEE 802.1 = AVB Task Group becoming the = Time-Sensitive

  =  Networking (TSN) Task Group (TG), with a much-expanded = constituency

   from the industrial and = vehicular markets.  Along with = this

   expansion, the networks = in consideration are becoming larger = and

   structured, requiring = deterministic forwarding beyond the = LAN

   boundaries.  For = instance, Industrial Automation segregates = the

   network 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, = and

   public infrastructures = such as Electricity Automation = require

   deterministic = properties over the Wide Area.  The realization is = now

   coming 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 = IETF

   and the IEEE and = implements an abstract model that can be = applicable

   both at Layer-2 and = Layer-3, and along segments of = different

  =  technologie.

TW> = typo

   With 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 be

  =  operating at Layer-2 over Ethernet whereas the IP routers may = be

   6TiSCH nodes operating = at Layer-2 and/or Layer-3 over the = IEEE

   802.15.4e = MAC.

 

  =  Many applications of interest to Deterministic Networking require = the

   ability to synchronize = the clocks in end systems to a = sub-microsecond

  =  accuracy.

TW> why = this accuracy?

  =  Some of the queue control techniques defined = in

   Section 4.7 also = require time synchronization among relay = systems.

   The means used to = achieve time synchronization are not addressed = in

   this = document.

 

2.  = Terminology

 

  =  The follwing

TW> = typo

   special terms are used = in this document in order to

  =  avoid the assumption that a given element in the = archetecture

TW> = typo

   does = or

   does not have Internet = Protocol stack, functions as a router or = a

   bridge, or otherwise = plays a particular role at Layer-3 or = higher:

TW> I don't get the sentence = above

 

  =  bridge

          =  A Customer Bridge as defined by IEEE = 802.1Q

          =  [IEEE802.1Q-2011].

 

  =  circuit

          =  A trail of configuration from talker to = listener(s)

TW> sender and receiver might be = more common at the IETF?

  =         =  through

          =  relay systems associated with a DetNet stream, required = to

          =  deliver the benefits of DetNet.

 

  =  end system

  =          Commonly called a "host" in = IETF documents, and an "end

  =          station" is IEEE 802 = documents.  End systems of interest = to

          =  this document are talkers and = listeners.

 

  =  listener

  =          An 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?

  =  

 

  =  stream

          =  A DetNet stream is a sequence of packets from a = single

          =  talker, through some number of relay systems to one or = more

          =  listeners, that is limited by the talker in its = maximum

          =  packet size and transmission rate, and can thus be = ensured

          =  the DetNet Quality of Service (QoS) from the = network.

 

  =  talker

          =  An 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 of

      the relay = systems and links;

 

  =  o  Probability of loss of a packet in the event of the = failure of a

      relay 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, = or

   typical values are of = no interest, because they do not affect = the

   ability of a real-time = system to perform its tasks.

TW> Would = it make sense to discuss hard and soft real-time here, = in

TW> particular in the context of = a wireless system?

  =  

 

  =  Three techniques are employed by DetNet to achieve these = QoS

  =  parameters:

 

  =  a.  Zero congestion loss (Section 3.1).  Network = resources such as

  =      link bandwidth, buffers, queues, shapers, and = scheduled input/

TW> add = 6TiSCH cells?

       output = slots are assigned in each relay system to the use of = a

       specific = DetNet stream or group of streams.  Note that, given = a

       finite = amount of buffer space)

TW> extra = ")"

   , zero congestion loss = necessarily

       ensures a = maximum end-to-end latency.  Depending on the = method

       employed, = 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 or

  =      more listeners can be established, and DetNet = streams assigned to

  =      follow a particular path or = tree.

TW> Using a single path in a = wireless system will fail, I would = recommend

TW> 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 = eliminate

      =  replicated 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 at

  =      least one path intact for a DetNet = stream.

 

  =  These three techniques can be applied independently, giving = eight

   possible combinations, = including none (no DetNet), although = some

   combinations are of = wider utility than others.  This separation = keeps

   the protocol stack = coherent and maximizes interoperability = with

   existing and developing = standards in this (IETF) and other = Standards

   Development = Organizations.  Some examples of typical = expected

  =  combinations:

 

  =  o  Pinned-down paths (a) plus packet replication (b) are = exactly the

      techniques = employed by [HSR-PRP].  Pinned-down paths are = achieve

      by limiting the = physical topology of the network, and = the

      = sequentialization, replication, and duplicate = elimination

      facilitated by = packet tags added at the front or the end = of

      Ethernet = frames.

 

  =  o  Zero congestion loss (a) alone is is offered by IEEE 802.1 = Audio

      Video bridging = [IEEE802.1BA-2011].  As long as the network = suffers

      no failures, = near-zero (at best, zero) congestion loss can = be

      achieved = through the use of a reservation protocol (MSRP) = and

      shapers 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 = satisfactory

   for many = applications.  However, these methods generally work best = in

   the absence of any = significant amount of non-critical traffic in = the

   network (if, indeed, = such traffic is supported at all), or work = only

   if the critical traffic = constitutes only a small portion of = the

   network's theoretical = capacity, or work only if all systems = are

   functioning properly, = or in the absence of actions by end = systems

   that disrupt the = network's operations.

 

  =  There are any number of methods in use, defined, or in progress = for

   accomplishing each of = the above techniques.  It is expected that = this

   DetNet Architecture = will assist various vendors, users, = and/or

   "vertical" = Standards Development Organizations (dedicated to a = single

   industry) to make = selections among the available means = of

   implementing DetNet = networks.

 

3.1.  = Zero Congestion Loss

 

  =  The primary means by which DetNet achieves its QoS assurances is = to

   completely eliminate = congestion at an output port as a cause = of

   packet 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 = at

   each hop through the = network to ensure that no packets are = dropped

   due to a lack of buffer = storage.

TW> and the provision the = sufficient link bandwidth?

 

  =  Ensuring adequate buffering requires, in turn, that the talker, = and

   every relay system = along the path to the listener (or nearly = every

   relay system -- see = Section 4.5.2) be careful to regulate its = output

   to not exceed the data = rate for any stream, except for brief = perios

TW> = typo

   when making up for = interfering traffic.  Any packet sent ahead of = its

   time potentially adds = to the number of buffers required by the = next

   hop, and may thus = exceed the resources allocated for a = particular

  =  stream.

 

  =  The low-level mechanisms described in Section 4.7 provide = the

   necessary regulation of = transmissions by an edge system or = relay

   system to ensure zero = congestion loss.  Of course, the reservation = of

   the bandwidth and = buffers for a stream requires the = provisioning

   described in Section = 4.12.

 

3.2.  = Pinned-down paths

 

  =  In networks controlled by typical peer-to-peer protocols such as = IEEE

   802.1 ISIS bridged = networks or ETF OSPF routed networks, a = network

   topology event in one = part of the network can impact, at = least

   briefly, the delivery = of data in parts of the network remote from = the

   failure or recovery = event.  Thus, even redundant paths through = a

   network, if controlled = by the typical peer-to-peer protocols, do = not

   eliminate 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 = minimizes

   recovery time and = easily supports redundant paths.  Of course, = this

   comes at the cost of = increased hop count, and thus latency, for = the

   typical = path.

 

  =  In order to get the advantages of low hop count and still = ensure

   against even brief = losses of connectivity, DetNet employs = pinned-down

   paths, where the path = taken by a given DetNet stream does not = change,

   at least immediately, = and likely not at all, in response to = network

   topology events.  = When combined with seamless = redundancy

   (Section 3.3), this = results in a high likelihood of = continuous

  =  connectivity.

 

3.3.  = Seamless Redundancy

 

  =  After congestion loss has been eliminated, the most important = causes

   of packet loss are = random media and/or memory faults and = equipment

  =  failures.

 

 

 

 

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 at

      least two = different paths to the listener(s).

 

  =  o  Discarding duplicated = packets.

 

  =  In the simplest case, this amounts to replicating each packet in = a

   talker that has two = interfaces, and conveying them through = the

   network, along separate = paths, to the similarly dual-homed = listeners,

   that discard the = extras.  This ensures that one path (with = zero

   congestion loss) = remains, even if some relay system = fails.

TW> this has some energy cost = associated?

  =  

   Alternatively, relay = systems in the network can provide = replication

   and elimination = facilities at various points in the network, so = that

   multiple failures can = be accommodated.

 

  =  This is shown in the following figure, where the two relay = systems

   each replicate (R) the = DetNet stream on input, sending the stream = to

   both the other relay = system and to the end system, and = eliminated

   duplicates (E) on the = output interface to the right-hand end = system.

   Any one = links

TW> = typo

   in the network can = fail, and the Detnet stream can

  =  still get through.  Furthermore, two links can fail, as long = as they

   are in different = segments of the network.

 

  =                   =  > > > > > > > >   relay   =  > > > > > > > = >

          =           > /------------+ R system E = +------------\ >

  =                  > / =                  v + ^ =                 \ = >

   end    R + =                   v | ^ =                  + E = end

   system   +   =                 v | ^   =                +   = system

          =          > \         =          v + ^         =         / >

  =                   > = \------------+ R relay  E +------------/ = >

          =            > > > > > > = > >   system   > > > > > > > = >

 

  =                     =            Figure = 1

TW> I don't understand what R and = E means

 

4.  = DetNet Architecture

 

  =  Traffic Engineering Architecture and Signaling (TEAS) [TEAS] = defines

   traffic-engineering = architectures for generic applicability = across

   packet and non-packet = networks.  From TEAS perspective, = Traffic

   Engineering (TE) refers = to techniques that enable operators = to

   control how specific = traffic flows are treated within their = networks.

 

  =  Because if its very nature of establishing pinned-down = optimized

   paths, 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 = a

   separation into = planes.

 

  =  The Deterministic Networking architecture is thus composed of = three

   planes, a (User) = Application Plane, a Controller Plane, and a = Network

   Plane, which echoes = that of Software-Defined Networking = (SDN): 

TW> double = ":"

  =  Layers

   and 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 = and

   services.  In = particular, the Application Plane incorporates the = User

   Agent, a specialized = application that interacts with the end user = /

   operator and performs = requests for Deterministic Networking = services

   via an abstract Stream = Management Entity, (SME) which may or may = not

   be collocated with (one = of) the end systems.

 

  =  At the Application Plane, a management interface enables = the

   negotiation of streams = between end systems.  An abstraction of = the

   stream called a Traffic = Specification (TSpec) provides the

  =  representation.  This abstraction is used to place a = reservation over

  =  the (Northbound) Service Interface and within the Application = plane.

   It is associated with = an abstraction of location, such as = IP

   addresses and DNS = names, to identify the end systems and = eventually

   specify intermediate = relay systems.

 

4.2.  = The Controller Plane

 

  =  The Controller Plane corresponds to the aggregation of the = Control

   and Management Planes = in [RFC7426], though Common Control = and

   Measurement Plane = (CCAMP) [CCAMP] makes an additional = distinction

   between management and = measurement.  When the logical separation = of

   the Control, = Measurement and other Management entities is = not

   relevant, the term = Controller Plane is used for simplicity = to

   represent them all, and = the term controller refers to any = device

   operating in that = plane, whether is it a Path Computation entity or = a

   Network Management = entity (NME).  The Path Computation Element = (PCE)

   [PCE] is a core element = of a controller, in charge of = computing

   Deterministic paths to = be applied in the Network Plane.

 

  =  A (Northbound) Service Interface enables applications in = the

   Application Plane to = communicate with the entities in the = Controller

  =  Plane.

 

 

TW> could = you define NME, SME and PCE in the = terminology?

  =  

   One or more PCE(s) = collaborate to implement the requests from the = SME

   as Per-Stream Per-Hop = Behaviors installed in the relay systems = for

   each individual = streams.  The PCEs place each stream along = a

   deterministic sequence = of relay systems so as to respect = per-stream

   constraints such as = security and latency, and optimize the = overall

   result for metrics such = as an abstract aggregated cost.  = The

   deterministic sequence = can typically be more complex than a = direct

   sequence and include = redundancy path, with one or more = packet

   replication 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 = a

   whole, regardless of = the Layer at which the network devices = operate.

 

  =  The network Plane comprises the Network Interface Cards (NIC) in = the

   end systems, which are = typically IP hosts, and relay systems, = which

   are typically IP = routers and switches.  Network-to-Network = Interfaces

   such as used for = Traffic Engineering path reservation in = [RFC3209],

   as well as = User-to-Network Interfaces (UNI) such as provided by = the

   Local Management = Interface (LMI) between network and end systems, = are

   all part of the Network = Plane.

 

  =  A Southbound (Network) Interface enables the entities in = the

   Controller Plane to = communicate with devices in the Network = Plane.

   This interface = leverages and extends TEAS to describe the = physical

   topology and resources = in the Network Plane.

 

  =                     =    Stream Management Entity

 

  =      End               =                     =                   = End

          =  System                 =                     =           = System

 

  =     -+-+-+-+-+-+-+ Northbound = -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

 

  =               PCE     =     PCE              PCE =             =  PCE

 

  =     -+-+-+-+-+-+-+ Southbound = -+-+-+-+-+-+-+-+-+-+--+-+-+-+-+-+-

 

  =                 Relay   =    Relay      Relay     =  Relay

          =         System     System     = System     System

  =      NIC               =                     =                   = NIC

          =         Relay      Relay   =    Relay     =  Relay

          =         System     System     = System     System

 

  =                     =            Figure = 3

 

  =  The relay systems (and eventually the end systems NIC) expose = their

   capabilities and = physical resources to the controller (the PCE), = and

   update the PCE with = their dynamic perception of the topology, = across

   the Southbound = Interface.  In return, the PCE(s) set the = per-stream

   paths up, providing a = Stream Characterization that is more = tightly

   coupled to the relay = system Operation than a TSpec.

 

  =  At the Network plane, relay systems exchange information = regarding

   the state of the paths, = between adjacent systems and eventually = with

   the 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 = resort

   operation such as drop = or declassify.

 

  =  This specification focuses on the Southbound interface and = the

   operation of the = Network Plane.

 

4.4.  = Elements of DetNet Architecture

 

  =  The DetNet architecture has a number of elements, discussed in = the

   following = sections:

 

  =  a.  A model for the definition, identification, and operation = of

       DetNet = streams (Section 4.5), for use by relay systems = to

       classify = and process individual packets following = per-stream

      =  rules.

TW> how is a packet = "labeled" as part of = stream?

 

  =  b.  A model for the flow of data from an end system or = through a

       relay = system that can be used to predict the bounds for = that

       system's = impact on the QoS of a DetNet stream, = without

      =  significantly constraining the method of implementing = that

       system, = for use by the Controllers to configure policing = and

       shaping = 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 end

  =          system or relay system to control the = selection of packets

  =          output on an interface.  These = models must have sufficiently

  =          well-defined characteristics, both = individually and in the

  =          aggregate, to give predictable results = for the QoS for DetNet

  =          packets (Section = 4.7).

 

  =      2.  A model for identifying misbehaving DetNet = streams and

          =  mitigating their impact on properly functioning = streams

          =  (Section 4.9).

 

  =  c.  A model for the relay system to inform the controller(s) = of the

      =  information 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.  hysical

TW> = typo

          =  resources (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 relay

       systems, = to forward a DetNet stream over a simple or = redundant

      =  path.  The model includes:

 

  =      1.  A model for an abstract relaying operation = of either Routing

  =          or forwarding packets of a DetNet = stream to a next-hop relay

  =          system, across Layer = boundaries.

 

  =      2.  A model of next-hop(s) information for = replicating the

  =          packets of a DetNet stream, typically = at or near the talker,

  =          merging and/or re-replicating those = packets at other points

  =          in the network, and finally = eliminating the duplicates,

  =          typically at or near the listener(s), = in order to provide

  =          high availability (Section = 3.3).

 

  =  e.  The protocol stack model for an end system and/or a relay = system

       should = support the above elements in a manner that maximizes = the

      =  applicability of existing standards and protocols to the = DetNet

       problem, = allows for the creation of new protocols where = needed,

       thus = making DetNet an add-on feature to existing networks, = rather

       than a = new way to do networking.  In particular this = protocol

       stack = supports networks in which the path from talker = to

      =  listener(s) includes bridges and/or routers in any = order

       (Section = 4.10).

 

  =  f.  A variety of models for the provisioning of DetNet = streams can be

  =      envisioned, including orchestration by a central = controller or by

  =      a federation of controllers, provisioning by relay = systems and

       end = systems sharing peer-to-peer protocols, by = off-line

      =  configuration, or by a combination of these methods.  = The

      =  provisioning models are similar to existing Layer-2 and = Layer-3

       models, = in order to minimize the amount of innovation required = in

       this area = (Section 4.12).

 

4.5.  = DetNet streams

 

4.5.1.  = Talker guarantees

 

  =  DetNet streams can by synchronous or asynchronous.  The = transmission

   of packets in = synchronous DetNet streams uses time = synchronization

  =  among 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 = observation

      = interval.

 

  =  These parameters, together with knowledge of the protocol stack = used

   (and thus the size of = the various headers added to a packet), = limit

   the number of bit times = per observation interval that the = DetNet

   stream can occupy the = physical medium.

 

  =  The talker promises that these limits will not be exceeded.  = If the

   talker transmits less = data than this limit allows, the = unused

   resources such as link = bandwidth can be made available by the = system

   to non-DetNet = packets.  However, making those resources available = to

   DetNet packets in other = streams would serve no purpose.  Those = other

   streams have their own = dedicated resources, on the assumption = that

   all DetNet streams can = use all of their resources over a long = period

   of = time.

 

  =  Note that there is no provision in DetNet for throttling streams; = the

   assumption is that a = DetNet stream, to be useful, must be = delivered

   in its entirety.  = That is, while any useful application is written = to

   expect a certain number = of lost packets, the real-time = applications

   of interest to DetNet = demand that the loss of data due to the = network

   is extraordinarily = infrequent.

 

  =  Although DetNet strives to minimize the changes required of = an

   application to allow it = to shift from a special-purpose = digital

   network to an Internet = Protocol network, one fundamental shift in = the

   behavior of network = applications that is impossible to = avoid--the

   reservation of = resources before the application starts.  In the = first

   place, a network cannot = deliver finite latency and practically = zero

   packet loss to an = arbitrarily high offered load.  Secondly, = achieving

   practically zero packet = loss for unthrottled (though = bandwidth

   limited) streams means = that bridges and routers have to = dedicate

   buffer resources to = specific streams or to classes of streams.  = The

   requirements of each = reservation have to be translated into = the

   parameters that control = each system's queuing, shaping, and

  =  scheduling functions and delivered to the hosts, bridges, = and

  =  routers.

 

4.5.2.  = Incomplete Networks

 

  =  The presence in the network of relay systems that are not = fully

   capable of offering = DetNet services complicates the ability of = the

   relay systems and/or = controller to allocate resources, as = extra

   buffering, and thus = extra latency, must be allocated at each = point

   that is downstream from = the non-DetNet relay system for some = DetNet

  =  stream.

 

 

 

 

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 = Group

   has defined a set of = queuing, shaping, and scheduling algorithms = that

   enable each bridge or = router to compute the exact number of = buffers

   to 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 = the

   network bandwidth to = DetNet streams.  But, no matter how much = is

   dedicated for DetNet = streams, It is z

TW> = typo

   goal of DetNet to not = interfere

   excessively with = existing QoS schemes.  It is also important = that

   non-DetNet traffic not = disrupt the DetNet stream, of course = (see

   Section 4.9 and Section = 6).  For these reasons:

 

  =  o  Bandwidth (transmission opportunities) not utilized by a = DetNet

      stream are = available to non-DetNet packets (though not to = other

      DetNet = 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 = scheduled

      in detail, then = the algorithm constructing the schedule = should

      leave = sufficient opportunities for non-DetNet packets to = satisfy

      the needs of = the uses of the network.

 

  =  Ideally, the net effect of the presence of DetNet streams in = a

   network on the = non-DetNet packets is primarily a = reductoin

TW> = typo

   in = the

   available = bandwidth.

 

4.9.  = Fault Mitigation

 

  =  One key to building robust real-time systems is to reduce = the

   infinite variety of = possible failures to a number that can = be

   analyzed with = reasonable confidence.  DetNet aids in the process = by

   providing filters and = policers to detect DetNet packets received = on

   the 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 = the

   offending = interface.

 

  =  It is also essential that filters and service = remarking

TW> please define "service = remarking"

  =  be employed

  =  to prevent non-DetNet packets from impinging on the = resources

   allocated 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 = of

   standardization, that = can perform these fault mitigation tasks = that

   deliver a high = probability that misbehaving systemd

TW> = typo

   will have = zero

   impact on well-behaved = DetNet streams, except of course, for = the

   receiving interface(s) = immediately downstream of the = misbehaving

  =  device.

 

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 = in

   progress, 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 = model

   is attractive but a = number of issues are left to be solved.  = In

  =  particular:

 

  =  o  whether and how the path computation can be installed by = 1) an end

      device or 2) a = Network Management entity,

 

  =  o  and how the path is set up, either by installing state at = each hop

      with a direct = interaction between the forwarding device and = the

      PCE, or along a = path by injecting a source-routed request at = one

      end of the = path.

 

4.12.2.  Distributed Path = Setup

 

  =  Whether a distributed alternative without a PCE can be = valuable

   should be studied as = well.  Such an alternative could for = instance

   inherit from the = Resource ReSerVation Protocol [RFC5127] = (RSVP)

  =  flows.

 

  =  In a Layer-2 only environment, or as part of a layered approach to = a

   mixed environment, IEEE = 802.1 also has work, either completed or = in

   progress. =  [IEEE802.1Q-2011] Clause 35 describes SRP, a = peer-to-peer

   protocol for Layer-2 = roughly analogous to RSVP.  Almost complete = is

   [IEEE802.1Qca], which = defines how ISIS can provide multiple = disjoint

   paths 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 = Differentiated

  =  Services 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 = service

   class.  The = document also describes how the code-point can be = mapped

   into one of the = aggregated Diffserv service classes = [RFC5127].

 

5.2. =  6TiSCH

 

  =  Industrial process control already leverages deterministic = wireless

   Low power and Lossy = Networks (LLNs) to interconnect = critical

   resource-constrained = devices and form wireless mesh networks, = with

   standards such as = [ISA100.11a] and [WirelessHART].

 

  =  These standards rely on variations of the [IEEE802154e] = timeSlotted

   Channel Hopping (TSCH) = [I-D.ietf-6tisch-tsch] Medium Access = Control

   (MAC), and a form of = centralized Path Computation Element (PCE), = to

   deliver deterministic = capabilities.

 

  =  The TSCH MAC benefits include high reliability against = interference,

   low power consumption = on characterized streams, and Traffic

  =  Engineering capabilities.  Typical applications are open and = closed

   control loops, as well = as supervisory control streams and = management.

 

  =  The 6TiSCH Working Group focuses only on the TSCH mode of the = IEEE

   802.15.4e = standard.  The WG currently defines a framework = for

   managing the TSCH = schedule.  Future work will = standardize

   deterministic = operations over so-called tracks as described = in

  =  [I-D.ietf-6tisch-architecture].  Tracks are an instance of = a

   deterministic path, and = the DetNet work is a prerequisite to = specify

   track operations and = serve process control applications.

 

  =  [RFC5673] and [I-D.ietf-roll-rpl-industrial-applicability] = section

   2.1.3.  and next = discusses application-layer paradigms, such = as

   Source-sink (SS) that = is a Multipeer to Multipeer (MP2MP) model = that

   is primarily used for = alarms and alerts, Publish-subscribe (PS, = or

   pub/sub) that is = typically used for sensor data, as well as = Peer-to-

   peer (P2P) and = Peer-to-multipeer (P2MP) communications.  = Additional

   considerations on = Duocast and its N-cast generalization are = also

   provided 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 = added

   dimension; the time of = delivery of a packet can be just as = important

   as the contents of the = packet, itself.  A man-in-the-middle = attack,

   for example, can = impose, and then systematically adjust, = additional

   delays into a link, and = thus disrupt or subvert a real-time

  =  application 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 = of

   equipment, or even = human lives, can be lost if the DetNet QoS is = not

   delivered, one must = consider not only simple equipment = failures,

   where the box or wire = instantly becomes perfectly silent, but = bizarre

   errors such as can be = coused

TW> = typo

   by software = failures.  Because there is

  =  essentiall

TW> = typo

   no limit to the kinds = of failures that can occur,

  =  protecting against realistic equipment failures is = indistinguishable,

  =  in most cases, from protecting against malicious behavior, = whether

   accidental 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, = George

   Swallow, 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, = for

   their various = contribution with this work.

 

9.  = Informative References

 

  =  [AVnu]     http://www.avnu.org/, "The AVnu Alliance = tests and

          =     certifies devices for interoperability, providing a = simple

          =     and reliable networking solution for AV = network

          =     implementation 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",

  =  [HART]     www.hartcomm.org, "Highway Addressable Remote = Transducer,

          =     a group of specifications for industrial process = and

          =     control devices administered by the HART Foundation", = .

 

  =  [HSR-PRP]  IEC, "High availability seamless redundancy = (HSR) is a

          =     further development of the PRP approach, although = HSR

          =     functions primarily as a protocol for creating = media

          =     redundancy while PRP, as described in the = previous

          =     section, creates network redundancy.  PRP and HSR are = both

          =     described in the IEC 62439 3 = standard.",

          =     = artnum/046615!opendocument>.

 

  =  [I-D.finn-detnet-problem-statement]

  =             Finn, N. and P. Thubert, = "Deterministic Networking = Problem

          =     Statement", draft-finn-detnet-problem-statement-01 = (work

          =     in 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 IEEE

  =             802.15.4e", = draft-ietf-6tisch-architecture-05 (work = in

          =     progress), January = 2015.

 

  =  [I-D.ietf-6tisch-tsch]

  =             Watteyne, T., Palattella, M., = and L. Grieco, "Using

  =             IEEE802.15.4e TSCH in an IoT = context: Overview, Problem

  =             Statement and Goals", = draft-ietf-6tisch-tsch-05 (work in

  =             progress), January = 2015.

 

  =  [I-D.ietf-roll-rpl-industrial-applicability]

<= /div>

              Phinney, T., = Thubert, P., and R. Assimiti, = "RPL

          =     applicability 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 = in

          =     progress), March 2015.

 

  =  [IEEE802.1AS-2011]

  =             IEEE, "Timing and = Synchronizations (IEEE = 802.1AS-2011)",

  =             2011, <http://standards.ieee.org/getIEEE802/

          =     = 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,

          =     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)",

  =             2010, <http://standards.ieee.org/getIEEE802/

          =     = 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,

          =     ca-drafts/>.

 

  =  [IEEE802.1Qcc]

  =             IEEE, "Stream Reservation = Protocol (SRP) Enhancements and

  =             Performance = Improvements", 2015,

          =     cc-drafts/>.

 

  =  [IEEE802.1TSNTG]

  =             IEEE Standards Association, = "IEEE 802.1 Time-Sensitive

  =             Networks Task Group", = 2013,

          =     <http://www.IEEE802.org/1/pages/avbridges.html>.<= /span>

 

  =  [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-Rate

  =             Wireless 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 Area

  =             Networks (LR-WPANs) Amendment = 1: MAC sublayer", April

  =             = 2012.

 

  =  [ISA100.11a]

  =             ISA/IEC, "ISA100.11a, = Wireless Systems for Automation,

  =             also IEC 62734", 2011, = < http://www.isa100wci.org/en-

<= /div>

              = US/Documents/PDF/3405-ISA100-WirelessSystems-Future-broch-

          =     WEB-ETSI.aspx>.

 

  =  [ODVA]     http://www.odva.org/, "The organization that = supports

          =     network technologies built on the Common = Industrial

          =     Protocol (CIP) including EtherNet/IP.", = .

 

  =  [PCE]      IETF, "Path Computation = Element",

 

  =  [Profinet]

  =             http://us.profinet.com/technology/profinet/, = "PROFINET is

  =             a standard for industrial = networking in automation.",

 

  =  [RFC2205]  Braden, B., Zhang, L., Berson, S., Herzog, S., and = S.

          =     Jamin, "Resource ReSerVation Protocol (RSVP) -- = Version 1

          =     Functional 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 LSP

  =             Tunnels", RFC 3209, = December 2001.

 

  =  [RFC4655]  Farrel, A., Vasseur, J., and J. Ash, "A Path = Computation

          =     Element (PCE)-Based Architecture", RFC 4655, August = 2006.

 

  =  [RFC5127]  Chan, K., Babiarz, J., and F. Baker, = "Aggregation of

  =             Diffserv Service = Classes", RFC 5127, February = 2008.

 

  =  [RFC5673]  Pister, K., Thubert, P., Dwars, S., and T. = Phinney,

          =     "Industrial Routing Requirements in Low-Power and = Lossy

          =     Networks", RFC 5673, October = 2009.

 

  =  [RFC7384]  Mizrahi, T., "Security Requirements of Time = Protocols in

          =     Packet 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-Defined

  =             Networking (SDN): Layers and = Architecture Terminology",

  =             RFC 7426, January = 2015.

 

  =  [TEAS]     IETF, "Traffic Engineering Architecture = and Signaling",

 

  =  [WirelessHART]

  =             www.hartcomm.org, = "Industrial Communication Networks = -

          =     Wireless Communication Network and Communication = Profiles

          =     - WirelessHART - IEC 62591", = 2010.

 

Authors' = Addresses

 

  =  Norm Finn

  =  Cisco Systems

  =  170 W Tasman Dr.

  =  San Jose, California =  95134

  =  USA

 

  =  Phone: +1 408 526 4495

  =  Email: nfinn@cisco.com

 

 

  =  Pascal Thubert

  =  Cisco Systems

  =  Village d'Entreprises Green = Side

   400, Avenue de = Roumanille

   Batiment = T3

   Biot - Sophia Antipolis =  06410

  =  FRANCE

 

  =  Phone: +33 4 97 23 26 = 34

   Email: pthubert@cisco.com

=

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Finn & = Thubert         Expires September 10, 2015   =            [Page = 23]

------=_NextPart_001_0217_01D06570.CCCB9160-- ------=_NextPart_000_0216_01D06570.CCCB9160 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOLTCCBDYw ggMeoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwbzELMAkGA1UEBhMCU0UxFDASBgNVBAoTC0FkZFRy dXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBUVFAgTmV0d29yazEiMCAGA1UEAxMZ QWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0wMDA1MzAxMDQ4MzhaFw0yMDA1MzAxMDQ4Mzha MG8xCzAJBgNVBAYTAlNFMRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQGA1UECxMdQWRkVHJ1c3Qg RXh0ZXJuYWwgVFRQIE5ldHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0IEV4dGVybmFsIENBIFJvb3Qw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC39xoz5vIABC054E5b7R+8bA/Ntfojts7e mxEzl6QpTH2Tn71KvJPtAxrjj8/lbVBa1pcplFqAsEl62y6V/bjKvzc4LR4+kUGtcFbH8E8/6DKe dMrIkFTpxl8PeJ2aQDwOrGGqXhSPnoehalDc15pOrwWzpnGUnHGzUGAKxxOdOAeGAqjpqGkmGJCr TLBPI6s6T4TY386f4Wlvu9dC12tE5Met7m1BX3JacQg3s3llpFmglDf3AC8NwpJy2tA4ctsUqEXE XSp9t7TWxO6szRNEt8kr3UMAJfphuWlqWCMRt6czj1Z1WfXNKddGtworZbbTQm8Vsrh7++/pXVPV NFonAgMBAAGjgdwwgdkwHQYDVR0OBBYEFK29mHo0tCb3+sQmVO8DveAky1QaMAsGA1UdDwQEAwIB BjAPBgNVHRMBAf8EBTADAQH/MIGZBgNVHSMEgZEwgY6AFK29mHo0tCb3+sQmVO8DveAky1QaoXOk cTBvMQswCQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0 IEV4dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290 ggEBMA0GCSqGSIb3DQEBBQUAA4IBAQCwm+CFJcLWI+IPlgaSnUGYnNmEeYHZHlsUByM2ZY+w2He7 rEFsR2CDUbD5Mj3n/PYmE8eAFqW/WvyHz3h5iSGa4kwHCoY1vPLeUcTSlrfcfk7ucP0cOesMAlEU LY69FuDB30Z15ySt7PRCtIWTcBBnup0GNUoY0yt6zFFCoXpj0ea7ocUrwja+Ew3mvWN+eXunCQ1A q2rdj4rD9vaMGkIFUdRF9Z+nYiFoFSBDPJnnfL0k2KmRF3OIP1YbMTgYtHEPms3IDp6OLhvhjJiD yx8x8URMxgRzSXZgD8f4vReAay7pzEwOWpp5DyAKLtWeYyYeVZKU2IIXWnvQvMePToYEMIIErzCC A5egAwIBAgIRAOAjyxUSg1OJrWFuelRnayEwDQYJKoZIhvcNAQELBQAwbzELMAkGA1UEBhMCU0Ux FDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBUVFAgTmV0 d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0xNDEyMjIwMDAwMDBa Fw0yMDA1MzAxMDQ4MzhaMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVz dGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UE AxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwg Q0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCJsQ3aelMZTnBSHbxWpgYmt7hJ4Jbn Uavx8FoTSRWjtIwbYLx6UUKneYykIt8XYU6R1XYjChTTSgJ/th0JgG6lBD3ZursW/qGHqS5DUkMW fK8yUMimT1rpCNjPkyWce4joMGTmpPhWgP0qJBQzF5msROVpi6NGBkvCM9TpQJ8GsLGsk0C5tQiT OpwqU6MQ2z0gYTxVA47ZTnYlAiEp+qN8cXZP7uFfgen7VIDbw3s1UreE3iI9LDAtMX9ZvVI3sDNp LUPr+tal8Zd3Z1GM2e4n67ylBzh2jKSpOP/fjPUDrEm+yvdzmToPMquclToTPQ5GOld0YVC+xkA/ y+Tin6IhAgMBAAGjggEXMIIBEzAfBgNVHSMEGDAWgBStvZh6NLQm9/rEJlTvA73gJMtUGjAdBgNV HQ4EFgQUkmFrguGioKpP7GfxwqP3tIAAwewwDgYDVR0PAQH/BAQDAgGGMBIGA1UdEwEB/wQIMAYB Af8CAQAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMBEGA1UdIAQKMAgwBgYEVR0gADBE BgNVHR8EPTA7MDmgN6A1hjNodHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vQWRkVHJ1c3RFeHRlcm5h bENBUm9vdC5jcmwwNQYIKwYBBQUHAQEEKTAnMCUGCCsGAQUFBzABhhlodHRwOi8vb2NzcC51c2Vy dHJ1c3QuY29tMA0GCSqGSIb3DQEBCwUAA4IBAQAbKm6sVcE6q4jF2O3NVfOqa2ErwAkQI5kPxWZq b7H1tLV3Xg8CYQDffQX+ErOkgIAA/PsdW2pyAgpBvAW6wVjVJsLq1U2E+/6CmM9YG+MiY5xS+LsF Nqt9WKXeqztj5drVc+/s4Pt74qP/8EIjnMq2jU0+5EsYA7KoLdTYu0JLkGmFENumNzToe+ABEKWc yjrHn0+ING6KZdAairup3MrKNtH0/MJkKTWv1rGncRHSA0Oxjz6a7J4yU/R2ksqGNAe5LMrmHErY mQ3BhuKQkvtaQmojIRDpZcf11bt+6oyFIAJi6tE6ByxZxZkz8jiJ5bbpFnofeRT2ShAaJvp8ivub MIIFPDCCBCSgAwIBAgIRAImdrrrSrE1TMdXIyvE0qYEwDQYJKoZIhvcNAQELBQAwgZsxCzAJBgNV BAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAY BgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQg QXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xNTAyMDMwMDAwMDBaFw0xNjAy MDMyMzU5NTlaMCMxITAfBgkqhkiG9w0BCQEWEnB0aHViZXJ0QGNpc2NvLmNvbTCCASIwDQYJKoZI hvcNAQEBBQADggEPADCCAQoCggEBALTqoFHH36vHzOLhXp5Wv28HBpYWouQolX/OzHVrZbIEblHp NAxFdrnNSWULDP5gT8hp/t4P0XO3YEnaQxpPUu0wWFlLrDC690s0y3T0hATowmfycNcLX+hddBDL 8ChyZdJAVhxl0vnxORmcciJmXmWOJ+4lzEqaDbm5lZUHgi3kc0t9/IFOOJ6yq1kjttHu1MFPZZUc lUnlpXmD+2/GzxeCHlQgLvw232No6lrAS34PQxbu7rnfw25Spd3CFP7RymWZnNL26rIvt3J4rpv8 xy0EedfU3AUo5scNpr7Mb1npOgVU7N+K07atmjh71wpvfnpvwIxPA+OOHcXwOS5JsosCAwEAAaOC AfAwggHsMB8GA1UdIwQYMBaAFJJha4LhoqCqT+xn8cKj97SAAMHsMB0GA1UdDgQWBBS2xFsxMSdl ViqpYN1OZcdW6Bg4OTAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggr BgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYB BAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMF0G A1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET1NIQTI1NkNsaWVu dEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgZAGCCsGAQUFBwEBBIGDMIGAMFgG CCsGAQUFBzAChkxodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9TSEEyNTZDbGllbnRBdXRo ZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5j b21vZG9jYS5jb20wHQYDVR0RBBYwFIEScHRodWJlcnRAY2lzY28uY29tMA0GCSqGSIb3DQEBCwUA A4IBAQABMkoJZJ5HHnG3Sl0jOpl8Emhb5fjpyW2eK26Zy8e62uqUL7ExSBChD97N1lCYUFY4TqIR zCmaObFC+fDgG3IDQ7ZOJDVu6ZK8TAGiBF6sSYcg5rSfIKPxJUQvTciSrTE+XHEVONmU6xQrMIYY 4/T4iho50oQmNpTSNmGc19ZZ9mQtbRGsjdwILm5NvIyI3X088GidfVJqifQ9dRmSikzELdvlmdBs TFdAM1zx3CscylrUPQyy3lrLuvWf9arpPHV7sex+cwkLKOGHl26mXMoOPwvEYcpJJ3phmR/aqxbC mZwz4LugVrqvC0sFERLSjfarSBQxKL7XSxxS6JYEL3LpMYIEdDCCBHACAQEwgbEwgZsxCzAJBgNV BAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAY BgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQg QXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAImdrrrSrE1TMdXIyvE0qYEwCQYF Kw4DAhoFAKCCApcwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTUw MzIzMTk1MzU0WjAjBgkqhkiG9w0BCQQxFgQUGJepPaQSwKAf316Y5jfchUmVUh8wgasGCSqGSIb3 DQEJDzGBnTCBmjALBglghkgBZQMEASowCwYJYIZIAWUDBAEWMAoGCCqGSIb3DQMHMAsGCWCGSAFl AwQBAjAOBggqhkiG9w0DAgICAIAwBwYFKw4DAgcwDQYIKoZIhvcNAwICAUAwDQYIKoZIhvcNAwIC ASgwBwYFKw4DAhowCwYJYIZIAWUDBAIDMAsGCWCGSAFlAwQCAjALBglghkgBZQMEAgEwgcIGCSsG AQQBgjcQBDGBtDCBsTCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3Rl cjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMT OENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENB AhEAiZ2uutKsTVMx1cjK8TSpgTCBxAYLKoZIhvcNAQkQAgsxgbSggbEwgZsxCzAJBgNVBAYTAkdC MRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoT EUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAImdrrrSrE1TMdXIyvE0qYEwDQYJKoZIhvcN AQEBBQAEggEAZhcI+ZBAxQUGRKlyZNdc7Z9clfZ/E04si3Z7xabQ8I6aYDoGAU7M7dFwPD2t+JKe ZQP40gRrlr9186bfPLTWHyGhy0yzNbeAGSCAmXLLQvgA4LavYtn9ieBnVcKiHySlTTUyMsuWawUx WqNx7SgIeOOElAsyf3GpOLdhz7hYHA74Yeka26KjkDj6FmDqnUKjz3HByXqNv/uqAKRpoSA0uGqt /nVKobxXKIi0pj+3cq2LeYfHbfrJBvHFjD8maS5spEp3o0HkvlZmrYu0nnOO+dHDEFXU3y3TQ/Qz LOfm95weyBc77QKgj680geQBM7ReerKcU2AdKMzdXp+9yUgbyQAAAAAAAA== ------=_NextPart_000_0216_01D06570.CCCB9160-- From nobody Mon Mar 23 15:52:01 2015 Return-Path: X-Original-To: detnet@ietfa.amsl.com Delivered-To: detnet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC7C81A0006; Mon, 23 Mar 2015 15:51:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.643 X-Spam-Level: X-Spam-Status: No, score=-5.643 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, HTML_TAG_BALANCE_BODY=1.157, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 EmhpUa9MuhSc; Mon, 23 Mar 2015 15:51:42 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D77AB1A00FE; Mon, 23 Mar 2015 15:51:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=271187; q=dns/txt; s=iport; t=1427151101; x=1428360701; h=from:to:subject:date:message-id:mime-version; bh=y5ocwUyJUosvjGL9Z3k/Dz42jwIjXOccou09eWxO7es=; b=aCHhoy/nZiQ7Y+ifPEllgAMFNGPByyc5pDEdd8/M13NdwUZtvF3Gkikw 1kiqRipWbgaDpOk4+eBbibuU1RGLUhh8Llmy/25+UaFc6nXa8Kjxbpewj TZ3rtqShfCo/SY08y+Vddn142hU0z/1PQel8tvxhiOqEL4I/YBTssoGoH M=; X-Files: smime.p7s : 4831 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AgBgCqmBBV/4kNJK3JJ4orAgIB X-IronPort-AV: E=Sophos;i="5.11,455,1422921600"; d="p7s'?scan'208,217";a="402951028" Received: from alln-core-4.cisco.com ([173.36.13.137]) by rcdn-iport-1.cisco.com with ESMTP; 23 Mar 2015 22:51:40 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id t2NMpdCB024530 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 23 Mar 2015 22:51:40 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.225]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.03.0195.001; Mon, 23 Mar 2015 17:51:39 -0500 From: "Pascal Thubert (pthubert)" To: Thomas Watteyne , "detnet@ietf.org" , "6tisch@ietf.org" <6tisch@ietf.org> Thread-Topic: [Detnet] comments on draft-finn-detnet-architecture-00 Thread-Index: AdBlu6KkMiamjMAtTCmGPXjAcifuWg== Date: Mon, 23 Mar 2015 22:51:38 +0000 Deferred-Delivery: Mon, 23 Mar 2015 22:50:00 +0000 Message-ID: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.82.250.102] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0023_01D06589.5B79D3A0" MIME-Version: 1.0 Archived-At: Subject: Re: [Detnet] comments on draft-finn-detnet-architecture-00 X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussions on Deterministic Networking, characterized by 1\) resource reservation; 2\) 0 congestion loss and guaranteed latency; 3\) over L2-only and mixed L2 and L3 networks; and 5\) 1+1 replication/deletion." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 22:51:59 -0000 ------=_NextPart_000_0023_01D06589.5B79D3A0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0024_01D06589.5B79D3A0" ------=_NextPart_001_0024_01D06589.5B79D3A0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Hello Thomas: I think that this should come from 6TiSCH based on experience from TSCH deployments, and be pushed to DetNet as requirements from the LLN/TSCH side. It is my hope that something like https://tools.ietf.org/html/draft-wang-6tisch-track-use-cases-00 evolves in that direction... Makes sense ? Pascal From: detnet [mailto:detnet-bounces@ietf.org] On Behalf Of Thomas Watteyne Sent: lundi 23 mars 2015 10:44 To: detnet@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. Finn Internet-Draft P. Thubert Intended status: Standards Track Cisco Expires: September 10, 2015 March 9, 2015 Deterministic Networking Architecture draft-finn-detnet-architecture-00 Abstract Deterministic Networking (DetNet) provides a capability to carry specified unicast or multicast data streams for real-time applications 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 for individual (or aggregated) DetNet streams in some or all of the relay systems (bridges or routers) along the path of the stream; 2) providing fixed paths for DetNet streams that do not rapidly change with the network topology; and 3) sequentializing, replicating, and eliminating duplicate packets at various points to ensure the availability of at least one path. The capabilities can be managed by configuration, or by manual or automatic network management. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months 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." This Internet-Draft will expire on September 10, 2015. Copyright Notice Copyright (c) 2015 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 Finn & Thubert Expires September 10, 2015 [Page 1] Internet-Draft Deterministic Networking Architecture March 2015 publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Providing the DetNet Quality of Service . . . . . . . . . . . 5 3.1. Zero Congestion Loss . . . . . . . . . . . . . . . . . . 6 3.2. Pinned-down paths . . . . . . . . . . . . . . . . . . . . 7 3.3. Seamless Redundancy . . . . . . . . . . . . . . . . . . . 7 4. DetNet Architecture . . . . . . . . . . . . . . . . . . . . . 8 4.1. The Application Plane . . . . . . . . . . . . . . . . . . 11 4.2. The Controller Plane . . . . . . . . . . . . . . . . . . 11 4.3. The Network Plane . . . . . . . . . . . . . . . . . . . . 12 4.4. Elements of DetNet Architecture . . . . . . . . . . . . . 13 4.5. DetNet streams . . . . . . . . . . . . . . . . . . . . . 14 4.5.1. Talker guarantees . . . . . . . . . . . . . . . . . . 14 4.5.2. Incomplete Networks . . . . . . . . . . . . . . . . . 15 4.6. Data Flow Model through Systems . . . . . . . . . . . . . 16 4.7. Queuing, Shaping, Scheduling, and Preemption . . . . . . 16 4.8. Coexistence with normal traffic . . . . . . . . . . . . . 16 4.9. Fault Mitigation . . . . . . . . . . . . . . . . . . . . 16 4.10. Protocol Stack Model . . . . . . . . . . . . . . . . . . 17 4.11. Advertising resources, capabilities and adjacencies . . . 17 4.12. Provisioning model . . . . . . . . . . . . . . . . . . . 17 4.12.1. Centralized Path Computation and Installation . . . 17 4.12.2. Distributed Path Setup . . . . . . . . . . . . . . . 17 5. Related IETF work . . . . . . . . . . . . . . . . . . . . . . 18 5.1. Deterministic PHB . . . . . . . . . . . . . . . . . . . . 18 5.2. 6TiSCH . . . . . . . . . . . . . . . . . . . . . . . . . 18 6. Security Considerations . . . . . . . . . . . . . . . . . . . 19 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 9. Informative References . . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 1. Introduction Operational Technology (OT) refers to industrial networks that are typically 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., discrete manufacturing). 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 use focusing on highly secure, reliable and deterministic networks, with limited scalability over a bounded area. The convergence of IT and OT technologies, also called the Industrial Internet, represents a major evolution for both sides. The work has already started; in particular, the industrial automation space has been developing a number of Ethernet-based replacements for existing digital control systems, often not packet-based (fieldbus technologies). These replacements are meant to provide similar behavior as the incumbent protocols, and their common focus is to transport TW> "on transporting"? a fully characterized flow over a well-controlled environment (i.e., a factory floor), with a bounded latency, extraordinarily low frame loss, and a very narrow jitter. Examples of such protocols include PROFINET, 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 help In 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 for connectivity and multimedia in transportation in general, the Ethernet AVB technology has become one of the hottest topics, in particular in the automotive connectivity. It is finding application in all elements of the vehicle TW> ":" from head units, to rear seat entertainment modules, to amplifiers and camera modules. While aimed at less critical applications than some industrial networks, AVB networks share the requirement for extremely low packet loss rates and ensured finite latency and jitter. TW> ensure -> guarantee? Other instances of in-vehicle deterministic networks have arisen as well for control networks in cars, trains and buses, as well as avionics, with, for instance, the mission-critical "Avionics Full- Duplex Switched Ethernet" (AFDX) that was designed as part of the ARINC 664 standards. Existing automotive control networks such as the LIN, CAN and TW> would TTP/C fit in this list? FlexRay standards were not designed to cover these increasing demands in terms of bandwidth and scalability that we see with various kinds of Driver Assistance Systems (DAS) and new multiplexing technologies based on Ethernet are now getting traction. The generalization of the needs for more deterministic networks have led to the IEEE 802.1 AVB Task Group becoming the Time-Sensitive Networking (TSN) Task Group (TG), with a much-expanded constituency from the industrial and vehicular markets. Along with this expansion, the networks in consideration are becoming larger and structured, requiring deterministic forwarding beyond the LAN boundaries. For instance, Industrial Automation segregates the network 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, and public infrastructures such as Electricity Automation require deterministic properties over the Wide Area. The realization is now coming 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 IETF and the IEEE and implements an abstract model that can be applicable both at Layer-2 and Layer-3, and along segments of different technologie. TW> typo With 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 be operating at Layer-2 over Ethernet whereas the IP routers may be 6TiSCH nodes operating at Layer-2 and/or Layer-3 over the IEEE 802.15.4e MAC. Many applications of interest to Deterministic Networking require the ability to synchronize the clocks in end systems to a sub-microsecond accuracy. TW> why this accuracy? Some of the queue control techniques defined in Section 4.7 also require time synchronization among relay systems. The means used to achieve time synchronization are not addressed in this document. 2. Terminology The follwing TW> typo special terms are used in this document in order to avoid the assumption that a given element in the archetecture TW> typo does or does not have Internet Protocol stack, functions as a router or a bridge, or otherwise plays a particular role at Layer-3 or higher: TW> I don't get the sentence above bridge A Customer Bridge as defined by IEEE 802.1Q [IEEE802.1Q-2011]. circuit A trail of configuration from talker to listener(s) TW> sender and receiver might be more common at the IETF? through relay systems associated with a DetNet stream, required to deliver the benefits of DetNet. end system Commonly called a "host" in IETF documents, and an "end station" is IEEE 802 documents. End systems of interest to this document are talkers and listeners. listener An 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? stream A DetNet stream is a sequence of packets from a single talker, through some number of relay systems to one or more listeners, that is limited by the talker in its maximum packet size and transmission rate, and can thus be ensured the DetNet Quality of Service (QoS) from the network. talker An 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 of the relay systems and links; o Probability of loss of a packet in the event of the failure of a relay 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, or typical values are of no interest, because they do not affect the ability of a real-time system to perform its tasks. TW> Would it make sense to discuss hard and soft real-time here, in TW> particular in the context of a wireless system? Three techniques are employed by DetNet to achieve these QoS parameters: a. Zero congestion loss (Section 3.1). Network resources such as link bandwidth, buffers, queues, shapers, and scheduled input/ TW> add 6TiSCH cells? output slots are assigned in each relay system to the use of a specific DetNet stream or group of streams. Note that, given a finite amount of buffer space) TW> extra ")" , zero congestion loss necessarily ensures a maximum end-to-end latency. Depending on the method employed, 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 or more listeners can be established, and DetNet streams assigned to follow a particular path or tree. TW> Using a single path in a wireless system will fail, I would recommend TW> 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 eliminate replicated 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 at least one path intact for a DetNet stream. These three techniques can be applied independently, giving eight possible combinations, including none (no DetNet), although some combinations are of wider utility than others. This separation keeps the protocol stack coherent and maximizes interoperability with existing and developing standards in this (IETF) and other Standards Development Organizations. Some examples of typical expected combinations: o Pinned-down paths (a) plus packet replication (b) are exactly the techniques employed by [HSR-PRP]. Pinned-down paths are achieve by limiting the physical topology of the network, and the sequentialization, replication, and duplicate elimination facilitated by packet tags added at the front or the end of Ethernet frames. o Zero congestion loss (a) alone is is offered by IEEE 802.1 Audio Video bridging [IEEE802.1BA-2011]. As long as the network suffers no failures, near-zero (at best, zero) congestion loss can be achieved through the use of a reservation protocol (MSRP) and shapers 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 satisfactory for many applications. However, these methods generally work best in the absence of any significant amount of non-critical traffic in the network (if, indeed, such traffic is supported at all), or work only if the critical traffic constitutes only a small portion of the network's theoretical capacity, or work only if all systems are functioning properly, or in the absence of actions by end systems that disrupt the network's operations. There are any number of methods in use, defined, or in progress for accomplishing each of the above techniques. It is expected that this DetNet Architecture will assist various vendors, users, and/or "vertical" Standards Development Organizations (dedicated to a single industry) to make selections among the available means of implementing DetNet networks. 3.1. Zero Congestion Loss The primary means by which DetNet achieves its QoS assurances is to completely eliminate congestion at an output port as a cause of packet 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 at each hop through the network to ensure that no packets are dropped due to a lack of buffer storage. TW> and the provision the sufficient link bandwidth? Ensuring adequate buffering requires, in turn, that the talker, and every relay system along the path to the listener (or nearly every relay system -- see Section 4.5.2) be careful to regulate its output to not exceed the data rate for any stream, except for brief perios TW> typo when making up for interfering traffic. Any packet sent ahead of its time potentially adds to the number of buffers required by the next hop, and may thus exceed the resources allocated for a particular stream. The low-level mechanisms described in Section 4.7 provide the necessary regulation of transmissions by an edge system or relay system to ensure zero congestion loss. Of course, the reservation of the bandwidth and buffers for a stream requires the provisioning described in Section 4.12. 3.2. Pinned-down paths In networks controlled by typical peer-to-peer protocols such as IEEE 802.1 ISIS bridged networks or ETF OSPF routed networks, a network topology event in one part of the network can impact, at least briefly, the delivery of data in parts of the network remote from the failure or recovery event. Thus, even redundant paths through a network, if controlled by the typical peer-to-peer protocols, do not eliminate 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 minimizes recovery time and easily supports redundant paths. Of course, this comes at the cost of increased hop count, and thus latency, for the typical path. In order to get the advantages of low hop count and still ensure against even brief losses of connectivity, DetNet employs pinned-down paths, where the path taken by a given DetNet stream does not change, at least immediately, and likely not at all, in response to network topology events. When combined with seamless redundancy (Section 3.3), this results in a high likelihood of continuous connectivity. 3.3. Seamless Redundancy After congestion loss has been eliminated, the most important causes of packet loss are random media and/or memory faults and equipment failures. 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 at least two different paths to the listener(s). o Discarding duplicated packets. In the simplest case, this amounts to replicating each packet in a talker that has two interfaces, and conveying them through the network, along separate paths, to the similarly dual-homed listeners, that discard the extras. This ensures that one path (with zero congestion loss) remains, even if some relay system fails. TW> this has some energy cost associated? Alternatively, relay systems in the network can provide replication and elimination facilities at various points in the network, so that multiple failures can be accommodated. This is shown in the following figure, where the two relay systems each replicate (R) the DetNet stream on input, sending the stream to both the other relay system and to the end system, and eliminated duplicates (E) on the output interface to the right-hand end system. Any one links TW> typo in the network can fail, and the Detnet stream can still get through. Furthermore, two links can fail, as long as they are in different segments of the network. > > > > > > > > relay > > > > > > > > > /------------+ R system E +------------\ > > / v + ^ \ > end R + v | ^ + E end system + v | ^ + system > \ v + ^ / > > \------------+ R relay E +------------/ > > > > > > > > > system > > > > > > > > Figure 1 TW> I don't understand what R and E means 4. DetNet Architecture Traffic Engineering Architecture and Signaling (TEAS) [TEAS] defines traffic-engineering architectures for generic applicability across packet and non-packet networks. From TEAS perspective, Traffic Engineering (TE) refers to techniques that enable operators to control how specific traffic flows are treated within their networks. Because if its very nature of establishing pinned-down optimized paths, 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 a separation into planes. The Deterministic Networking architecture is thus composed of three planes, a (User) Application Plane, a Controller Plane, and a Network Plane, which echoes that of Software-Defined Networking (SDN): TW> double ":" Layers and 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 and services. In particular, the Application Plane incorporates the User Agent, a specialized application that interacts with the end user / operator and performs requests for Deterministic Networking services via an abstract Stream Management Entity, (SME) which may or may not be collocated with (one of) the end systems. At the Application Plane, a management interface enables the negotiation of streams between end systems. An abstraction of the stream called a Traffic Specification (TSpec) provides the representation. This abstraction is used to place a reservation over the (Northbound) Service Interface and within the Application plane. It is associated with an abstraction of location, such as IP addresses and DNS names, to identify the end systems and eventually specify intermediate relay systems. 4.2. The Controller Plane The Controller Plane corresponds to the aggregation of the Control and Management Planes in [RFC7426], though Common Control and Measurement Plane (CCAMP) [CCAMP] makes an additional distinction between management and measurement. When the logical separation of the Control, Measurement and other Management entities is not relevant, the term Controller Plane is used for simplicity to represent them all, and the term controller refers to any device operating in that plane, whether is it a Path Computation entity or a Network Management entity (NME). The Path Computation Element (PCE) [PCE] is a core element of a controller, in charge of computing Deterministic paths to be applied in the Network Plane. A (Northbound) Service Interface enables applications in the Application Plane to communicate with the entities in the Controller Plane. TW> could you define NME, SME and PCE in the terminology? One or more PCE(s) collaborate to implement the requests from the SME as Per-Stream Per-Hop Behaviors installed in the relay systems for each individual streams. The PCEs place each stream along a deterministic sequence of relay systems so as to respect per-stream constraints such as security and latency, and optimize the overall result for metrics such as an abstract aggregated cost. The deterministic sequence can typically be more complex than a direct sequence and include redundancy path, with one or more packet replication 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 a whole, regardless of the Layer at which the network devices operate. The network Plane comprises the Network Interface Cards (NIC) in the end systems, which are typically IP hosts, and relay systems, which are typically IP routers and switches. Network-to-Network Interfaces such as used for Traffic Engineering path reservation in [RFC3209], as well as User-to-Network Interfaces (UNI) such as provided by the Local Management Interface (LMI) between network and end systems, are all part of the Network Plane. A Southbound (Network) Interface enables the entities in the Controller Plane to communicate with devices in the Network Plane. This interface leverages and extends TEAS to describe the physical topology and resources in the Network Plane. Stream Management Entity End End System System -+-+-+-+-+-+-+ Northbound -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- PCE PCE PCE PCE -+-+-+-+-+-+-+ Southbound -+-+-+-+-+-+-+-+-+-+--+-+-+-+-+-+- Relay Relay Relay Relay System System System System NIC NIC Relay Relay Relay Relay System System System System Figure 3 The relay systems (and eventually the end systems NIC) expose their capabilities and physical resources to the controller (the PCE), and update the PCE with their dynamic perception of the topology, across the Southbound Interface. In return, the PCE(s) set the per-stream paths up, providing a Stream Characterization that is more tightly coupled to the relay system Operation than a TSpec. At the Network plane, relay systems exchange information regarding the state of the paths, between adjacent systems and eventually with the 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 resort operation such as drop or declassify. This specification focuses on the Southbound interface and the operation of the Network Plane. 4.4. Elements of DetNet Architecture The DetNet architecture has a number of elements, discussed in the following sections: a. A model for the definition, identification, and operation of DetNet streams (Section 4.5), for use by relay systems to classify and process individual packets following per-stream rules. TW> how is a packet "labeled" as part of stream? b. A model for the flow of data from an end system or through a relay system that can be used to predict the bounds for that system's impact on the QoS of a DetNet stream, without significantly constraining the method of implementing that system, for use by the Controllers to configure policing and shaping 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 end system or relay system to control the selection of packets output on an interface. These models must have sufficiently well-defined characteristics, both individually and in the aggregate, to give predictable results for the QoS for DetNet packets (Section 4.7). 2. A model for identifying misbehaving DetNet streams and mitigating their impact on properly functioning streams (Section 4.9). c. A model for the relay system to inform the controller(s) of the information 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. hysical TW> typo resources (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 relay systems, to forward a DetNet stream over a simple or redundant path. The model includes: 1. A model for an abstract relaying operation of either Routing or forwarding packets of a DetNet stream to a next-hop relay system, across Layer boundaries. 2. A model of next-hop(s) information for replicating the packets of a DetNet stream, typically at or near the talker, merging and/or re-replicating those packets at other points in the network, and finally eliminating the duplicates, typically at or near the listener(s), in order to provide high availability (Section 3.3). e. The protocol stack model for an end system and/or a relay system should support the above elements in a manner that maximizes the applicability of existing standards and protocols to the DetNet problem, allows for the creation of new protocols where needed, thus making DetNet an add-on feature to existing networks, rather than a new way to do networking. In particular this protocol stack supports networks in which the path from talker to listener(s) includes bridges and/or routers in any order (Section 4.10). f. A variety of models for the provisioning of DetNet streams can be envisioned, including orchestration by a central controller or by a federation of controllers, provisioning by relay systems and end systems sharing peer-to-peer protocols, by off-line configuration, or by a combination of these methods. The provisioning models are similar to existing Layer-2 and Layer-3 models, in order to minimize the amount of innovation required in this area (Section 4.12). 4.5. DetNet streams 4.5.1. Talker guarantees DetNet streams can by synchronous or asynchronous. The transmission of packets in synchronous DetNet streams uses time synchronization among 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 observation interval. These parameters, together with knowledge of the protocol stack used (and thus the size of the various headers added to a packet), limit the number of bit times per observation interval that the DetNet stream can occupy the physical medium. The talker promises that these limits will not be exceeded. If the talker transmits less data than this limit allows, the unused resources such as link bandwidth can be made available by the system to non-DetNet packets. However, making those resources available to DetNet packets in other streams would serve no purpose. Those other streams have their own dedicated resources, on the assumption that all DetNet streams can use all of their resources over a long period of time. Note that there is no provision in DetNet for throttling streams; the assumption is that a DetNet stream, to be useful, must be delivered in its entirety. That is, while any useful application is written to expect a certain number of lost packets, the real-time applications of interest to DetNet demand that the loss of data due to the network is extraordinarily infrequent. Although DetNet strives to minimize the changes required of an application to allow it to shift from a special-purpose digital network to an Internet Protocol network, one fundamental shift in the behavior of network applications that is impossible to avoid--the reservation of resources before the application starts. In the first place, a network cannot deliver finite latency and practically zero packet loss to an arbitrarily high offered load. Secondly, achieving practically zero packet loss for unthrottled (though bandwidth limited) streams means that bridges and routers have to dedicate buffer resources to specific streams or to classes of streams. The requirements of each reservation have to be translated into the parameters that control each system's queuing, shaping, and scheduling functions and delivered to the hosts, bridges, and routers. 4.5.2. Incomplete Networks The presence in the network of relay systems that are not fully capable of offering DetNet services complicates the ability of the relay systems and/or controller to allocate resources, as extra buffering, and thus extra latency, must be allocated at each point that is downstream from the non-DetNet relay system for some DetNet stream. 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 Group has defined a set of queuing, shaping, and scheduling algorithms that enable each bridge or router to compute the exact number of buffers to 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 the network bandwidth to DetNet streams. But, no matter how much is dedicated for DetNet streams, It is z TW> typo goal of DetNet to not interfere excessively with existing QoS schemes. It is also important that non-DetNet traffic not disrupt the DetNet stream, of course (see Section 4.9 and Section 6). For these reasons: o Bandwidth (transmission opportunities) not utilized by a DetNet stream are available to non-DetNet packets (though not to other DetNet 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 scheduled in detail, then the algorithm constructing the schedule should leave sufficient opportunities for non-DetNet packets to satisfy the needs of the uses of the network. Ideally, the net effect of the presence of DetNet streams in a network on the non-DetNet packets is primarily a reductoin TW> typo in the available bandwidth. 4.9. Fault Mitigation One key to building robust real-time systems is to reduce the infinite variety of possible failures to a number that can be analyzed with reasonable confidence. DetNet aids in the process by providing filters and policers to detect DetNet packets received on the 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 the offending interface. It is also essential that filters and service remarking TW> please define "service remarking" be employed to prevent non-DetNet packets from impinging on the resources allocated 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 of standardization, that can perform these fault mitigation tasks that deliver a high probability that misbehaving systemd TW> typo will have zero impact on well-behaved DetNet streams, except of course, for the receiving interface(s) immediately downstream of the misbehaving device. 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 in progress, 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 model is attractive but a number of issues are left to be solved. In particular: o whether and how the path computation can be installed by 1) an end device or 2) a Network Management entity, o and how the path is set up, either by installing state at each hop with a direct interaction between the forwarding device and the PCE, or along a path by injecting a source-routed request at one end of the path. 4.12.2. Distributed Path Setup Whether a distributed alternative without a PCE can be valuable should be studied as well. Such an alternative could for instance inherit from the Resource ReSerVation Protocol [RFC5127] (RSVP) flows. In a Layer-2 only environment, or as part of a layered approach to a mixed environment, IEEE 802.1 also has work, either completed or in progress. [IEEE802.1Q-2011] Clause 35 describes SRP, a peer-to-peer protocol for Layer-2 roughly analogous to RSVP. Almost complete is [IEEE802.1Qca], which defines how ISIS can provide multiple disjoint paths 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 Differentiated Services 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 service class. The document also describes how the code-point can be mapped into one of the aggregated Diffserv service classes [RFC5127]. 5.2. 6TiSCH Industrial process control already leverages deterministic wireless Low power and Lossy Networks (LLNs) to interconnect critical resource-constrained devices and form wireless mesh networks, with standards such as [ISA100.11a] and [WirelessHART]. These standards rely on variations of the [IEEE802154e] timeSlotted Channel Hopping (TSCH) [I-D.ietf-6tisch-tsch] Medium Access Control (MAC), and a form of centralized Path Computation Element (PCE), to deliver deterministic capabilities. The TSCH MAC benefits include high reliability against interference, low power consumption on characterized streams, and Traffic Engineering capabilities. Typical applications are open and closed control loops, as well as supervisory control streams and management. The 6TiSCH Working Group focuses only on the TSCH mode of the IEEE 802.15.4e standard. The WG currently defines a framework for managing the TSCH schedule. Future work will standardize deterministic operations over so-called tracks as described in [I-D.ietf-6tisch-architecture]. Tracks are an instance of a deterministic path, and the DetNet work is a prerequisite to specify track operations and serve process control applications. [RFC5673] and [I-D.ietf-roll-rpl-industrial-applicability] section 2.1.3. and next discusses application-layer paradigms, such as Source-sink (SS) that is a Multipeer to Multipeer (MP2MP) model that is primarily used for alarms and alerts, Publish-subscribe (PS, or pub/sub) that is typically used for sensor data, as well as Peer-to- peer (P2P) and Peer-to-multipeer (P2MP) communications. Additional considerations on Duocast and its N-cast generalization are also provided 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 added dimension; the time of delivery of a packet can be just as important as the contents of the packet, itself. A man-in-the-middle attack, for example, can impose, and then systematically adjust, additional delays into a link, and thus disrupt or subvert a real-time application 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 of equipment, or even human lives, can be lost if the DetNet QoS is not delivered, one must consider not only simple equipment failures, where the box or wire instantly becomes perfectly silent, but bizarre errors such as can be coused TW> typo by software failures. Because there is essentiall TW> typo no limit to the kinds of failures that can occur, protecting against realistic equipment failures is indistinguishable, in most cases, from protecting against malicious behavior, whether accidental 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, George Swallow, 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, for their various contribution with this work. 9. Informative References [AVnu] http://www.avnu.org/, "The AVnu Alliance tests and certifies devices for interoperability, providing a simple and reliable networking solution for AV network implementation 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", . [HART] www.hartcomm.org, "Highway Addressable Remote Transducer, a group of specifications for industrial process and control devices administered by the HART Foundation", . [HSR-PRP] IEC, "High availability seamless redundancy (HSR) is a further development of the PRP approach, although HSR functions primarily as a protocol for creating media redundancy while PRP, as described in the previous section, creates network redundancy. PRP and HSR are both described in the IEC 62439 3 standard.", . [I-D.finn-detnet-problem-statement] Finn, N. and P. Thubert, "Deterministic Networking Problem Statement", draft-finn-detnet-problem-statement-01 (work in 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 IEEE 802.15.4e", draft-ietf-6tisch-architecture-05 (work in progress), January 2015. [I-D.ietf-6tisch-tsch] Watteyne, T., Palattella, M., and L. Grieco, "Using IEEE802.15.4e TSCH in an IoT context: Overview, Problem Statement and Goals", draft-ietf-6tisch-tsch-05 (work in progress), January 2015. [I-D.ietf-roll-rpl-industrial-applicability] Phinney, T., Thubert, P., and R. Assimiti, "RPL applicability 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 in progress), March 2015. [IEEE802.1AS-2011] IEEE, "Timing and Synchronizations (IEEE 802.1AS-2011)", 2011, . 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, . [IEEE802.1CB] IEEE, "Seamless Redundancy (IEEE Draft P802.1CB)", 2015, . [IEEE802.1Q-2011] IEEE, "MAC Bridges and VLANs (IEEE 802.1Q-2011", 2011, . [IEEE802.1Qat-2010] IEEE, "Stream Reservation Protocol (IEEE 802.1Qat-2010)", 2010, . [IEEE802.1Qav] IEEE, "Forwarding and Queuing (IEEE 802.1Qav-2009)", 2009, . [IEEE802.1Qca] IEEE, "Path Control and Reservation", 2015, . [IEEE802.1Qcc] IEEE, "Stream Reservation Protocol (SRP) Enhancements and Performance Improvements", 2015, . [IEEE802.1TSNTG] IEEE Standards Association, "IEEE 802.1 Time-Sensitive Networks 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-Rate Wireless 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 Area Networks (LR-WPANs) Amendment 1: MAC sublayer", April 2012. [ISA100.11a] ISA/IEC, "ISA100.11a, Wireless Systems for Automation, also IEC 62734", 2011, < http://www.isa100wci.org/en- US/Documents/PDF/3405-ISA100-WirelessSystems-Future-broch- WEB-ETSI.aspx>. [ODVA] http://www.odva.org/, "The organization that supports network technologies built on the Common Industrial Protocol (CIP) including EtherNet/IP.", . [PCE] IETF, "Path Computation Element", . [Profinet] http://us.profinet.com/technology/profinet/, "PROFINET is a standard for industrial networking in automation.", . [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional 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 LSP Tunnels", RFC 3209, December 2001. [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, August 2006. [RFC5127] Chan, K., Babiarz, J., and F. Baker, "Aggregation of Diffserv Service Classes", RFC 5127, February 2008. [RFC5673] Pister, K., Thubert, P., Dwars, S., and T. Phinney, "Industrial Routing Requirements in Low-Power and Lossy Networks", RFC 5673, October 2009. [RFC7384] Mizrahi, T., "Security Requirements of Time Protocols in Packet 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-Defined Networking (SDN): Layers and Architecture Terminology", RFC 7426, January 2015. [TEAS] IETF, "Traffic Engineering Architecture and Signaling", . [WirelessHART] www.hartcomm.org, "Industrial Communication Networks - Wireless Communication Network and Communication Profiles - WirelessHART - IEC 62591", 2010. Authors' Addresses Norm Finn Cisco Systems 170 W Tasman Dr. San Jose, California 95134 USA Phone: +1 408 526 4495 Email: nfinn@cisco.com Pascal Thubert Cisco Systems Village d'Entreprises Green Side 400, Avenue de Roumanille Batiment T3 Biot - Sophia Antipolis 06410 FRANCE Phone: +33 4 97 23 26 34 Email: pthubert@cisco.com Finn & Thubert Expires September 10, 2015 [Page 23] ------=_NextPart_001_0024_01D06589.5B79D3A0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Hello Thomas:

 

I think that this should come from 6TiSCH based on experience from = TSCH deployments, and be pushed to DetNet as requirements from the = LLN/TSCH side.

It is my hope that something like https://tools.ietf.org/html/draft-wang-6tisch-track-use-cases-00 = evolves in that direction...

 

Makes sense ?

 

Pascal

 

From:= = detnet [mailto:detnet-bounces@ietf.org] On Behalf Of Thomas Watteyne
Sent: lundi 23 mars = 2015 10:44
To: detnet@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. = Finn

Internet-Draft       =                     =                     =  P. Thubert

Intended = status: Standards Track               =                     = Cisco

Expires: September 10, 2015   =                     =          March 9, = 2015

 

 

  =                Deterministic = Networking Architecture

  =                 =  draft-finn-detnet-architecture-00

<= p class=3DMsoNormal> 

Abstract

 

  =  Deterministic Networking (DetNet) provides a capability to = carry

   specified unicast or = multicast data streams for real-time

  =  applications 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 = for

   individual (or = aggregated) DetNet streams in some or all of the = relay

   systems (bridges or = routers) along the path of the stream; = 2)

   providing fixed paths = for DetNet streams that do not rapidly = change

   with the network = topology; and 3) sequentializing, replicating, = and

   eliminating duplicate = packets at various points to ensure = the

   availability of at = least one path.  The capabilities can be = managed

   by configuration, or by = manual or automatic network = management.

 

Status of = This Memo

 

  =  This Internet-Draft is submitted in full conformance with = the

   provisions of BCP 78 = and BCP 79.

 

  =  Internet-Drafts are working documents of the Internet = Engineering

   Task Force = (IETF).  Note that other groups may also = distribute

   working documents as = Internet-Drafts.  The list of current = Internet-

 

  =  Internet-Drafts are draft documents valid for a maximum of six = months

   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."

 

  =  This Internet-Draft will expire on September 10, = 2015.

 

Copyright = Notice

 

  =  Copyright (c) 2015 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

 

 

 

Finn & = Thubert         Expires September 10, 2015   =             [Page = 1]

Internet-Draft   =  Deterministic Networking Architecture       March = 2015

 

 

  =  publication of this document.  Please review these = documents

   carefully, as they = describe your rights and restrictions with = respect

   to this document.  = Code Components extracted from this document = must

   include Simplified BSD = License text as described in Section 4.e = of

   the Trust Legal = Provisions and are provided without warranty = as

   described in the = Simplified BSD License.

 

Table of = Contents

 

  =  1.  Introduction  . . . . . . . . . . . . . . . . . . . = . . . . .   2

  =  2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . = . .   4

   3.  Providing the = DetNet Quality of Service . . . . . . . . . . .   = 5

     3.1.  Zero = Congestion Loss  . . . . . . . . . . . . . . . . . .   = 6

     3.2.  = Pinned-down paths . . . . . . . . . . . . . . . . . . . .   = 7

     3.3.  = Seamless Redundancy . . . . . . . . . . . . . . . . . . .   = 7

   4.  DetNet = Architecture . . . . . . . . . . . . . . . . . . . . .   = 8

     4.1.  The = Application Plane . . . . . . . . . . . . . . . . . . =  11

     4.2.  The = Controller Plane  . . . . . . . . . . . . . . . . . . =  11

     4.3.  The = Network Plane . . . . . . . . . . . . . . . . . . . . =  12

     4.4.  = Elements of DetNet Architecture . . . . . . . . . . . . . =  13

     4.5.  = DetNet streams  . . . . . . . . . . . . . . . . . . . . . =  14

      =  4.5.1.  Talker guarantees . . . . . . . . . . . . . . . . . . =  14

      =  4.5.2.  Incomplete Networks . . . . . . . . . . . . . . . . . =  15

     4.6.  Data = Flow Model through Systems . . . . . . . . . . . . . =  16

     4.7.  = Queuing, Shaping, Scheduling, and Preemption  . . . . . . =  16

     4.8.  = Coexistence with normal traffic . . . . . . . . . . . . . =  16

     4.9.  Fault = Mitigation  . . . . . . . . . . . . . . . . . . . . =  16

     4.10. Protocol = Stack Model  . . . . . . . . . . . . . . . . . . =  17

     4.11. = Advertising resources, capabilities and adjacencies . . . =  17

     4.12. = Provisioning model  . . . . . . . . . . . . . . . . . . . =  17

      =  4.12.1.  Centralized Path Computation and Installation =  . . .  17

  =      4.12.2.  Distributed Path Setup . . . . . . . . = . . . . . . .  17

  =  5.  Related IETF work . . . . . . . . . . . . . . . . . . . . = . .  18

     5.1.  = Deterministic PHB . . . . . . . . . . . . . . . . . . . . =  18

     5.2. =  6TiSCH  . . . . . . . . . . . . . . . . . . . . . . . . . =  18

   6.  Security = Considerations . . . . . . . . . . . . . . . . . . . =  19

   7.  IANA = Considerations . . . . . . . . . . . . . . . . . . . . . =  19

   8.  = Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . =  19

   9.  Informative = References  . . . . . . . . . . . . . . . . . . . =  19

   Authors' Addresses =  . . . . . . . . . . . . . . . . . . . . . . . =  23

 

1.  = Introduction

 

  =  Operational Technology (OT) refers to industrial networks that = are

   typically 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., = discrete

   manufacturing).  = 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 = use

   focusing on highly = secure, reliable and deterministic networks, = with

   limited scalability = over a bounded area.

 

  =  The convergence of IT and OT technologies, also called the = Industrial

   Internet, represents a = major evolution for both sides.  The work = has

   already started; in = particular, the industrial automation space = has

   been developing a = number of Ethernet-based replacements for = existing

   digital control = systems, often not packet-based = (fieldbus

  =  technologies).

 

  =  These replacements are meant to provide similar behavior as = the

   incumbent protocols, = and their common focus is to = transport

TW> "on = transporting"?

  =  a fully

   characterized flow over = a well-controlled environment (i.e., = a

   factory floor), with a = bounded latency, extraordinarily low = frame

   loss, and a very narrow = jitter.  Examples of such protocols = include

   PROFINET, 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 = help

   In 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 = for

   connectivity and = multimedia in transportation in general, = the

   Ethernet AVB technology = has become one of the hottest topics, = in

   particular in the = automotive connectivity.  It is finding = application

   in all elements of the = vehicle

TW> = ":"

   from head units, to = rear seat

   entertainment modules, = to amplifiers and camera modules.  While = aimed

   at less critical = applications than some industrial networks, = AVB

   networks share the = requirement for extremely low packet loss = rates

   and ensured finite = latency and jitter.

TW> = ensure -> guarantee?

 

  =  Other instances of in-vehicle deterministic networks have arisen = as

   well for control = networks in cars, trains and buses, as well = as

   avionics, with, for = instance, the mission-critical "Avionics = Full-

   Duplex Switched = Ethernet" (AFDX) that was designed as part of = the

   ARINC 664 = standards.  Existing automotive control networks such = as

   the LIN, CAN = and

TW> would TTP/C fit in this = list?

   FlexRay standards were = not designed to cover these

  =  increasing demands in terms of bandwidth and scalability that we = see

   with various kinds of = Driver Assistance Systems (DAS) and = new

   multiplexing = technologies based on Ethernet are now getting = traction.

 

  =  The generalization of the needs for more deterministic networks = have

   led to the IEEE 802.1 = AVB Task Group becoming the = Time-Sensitive

  =  Networking (TSN) Task Group (TG), with a much-expanded = constituency

   from the industrial and = vehicular markets.  Along with = this

   expansion, the networks = in consideration are becoming larger = and

   structured, requiring = deterministic forwarding beyond the = LAN

   boundaries.  For = instance, Industrial Automation segregates = the

   network 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, = and

   public infrastructures = such as Electricity Automation = require

   deterministic = properties over the Wide Area.  The realization is = now

   coming 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 = IETF

   and the IEEE and = implements an abstract model that can be = applicable

   both at Layer-2 and = Layer-3, and along segments of = different

  =  technologie.

TW> = typo

   With 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 be

  =  operating at Layer-2 over Ethernet whereas the IP routers may = be

   6TiSCH nodes operating = at Layer-2 and/or Layer-3 over the = IEEE

   802.15.4e = MAC.

 

  =  Many applications of interest to Deterministic Networking require = the

   ability to synchronize = the clocks in end systems to a = sub-microsecond

  =  accuracy.

TW> why = this accuracy?

  =  Some of the queue control techniques defined = in

   Section 4.7 also = require time synchronization among relay = systems.

   The means used to = achieve time synchronization are not addressed = in

   this = document.

 

2.  = Terminology

 

  =  The follwing

TW> = typo

   special terms are used = in this document in order to

  =  avoid the assumption that a given element in the = archetecture

TW> = typo

   does = or

   does not have Internet = Protocol stack, functions as a router or = a

   bridge, or otherwise = plays a particular role at Layer-3 or = higher:

TW> I don't get the sentence = above

 

  =  bridge

          =  A Customer Bridge as defined by IEEE = 802.1Q

          =  [IEEE802.1Q-2011].

 

  =  circuit

          =  A trail of configuration from talker to = listener(s)

TW> sender and receiver might be = more common at the IETF?

  =         =  through

          =  relay systems associated with a DetNet stream, required = to

          =  deliver the benefits of DetNet.

 

  =  end system

  =          Commonly called a "host" in = IETF documents, and an "end

  =          station" is IEEE 802 = documents.  End systems of interest = to

          =  this document are talkers and = listeners.

 

  =  listener

  =          An 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?

  =  

 

  =  stream

          =  A DetNet stream is a sequence of packets from a = single

          =  talker, through some number of relay systems to one or = more

          =  listeners, that is limited by the talker in its = maximum

          =  packet size and transmission rate, and can thus be = ensured

          =  the DetNet Quality of Service (QoS) from the = network.

 

  =  talker

          =  An 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 of

      the relay = systems and links;

 

  =  o  Probability of loss of a packet in the event of the = failure of a

      relay 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, = or

   typical values are of = no interest, because they do not affect = the

   ability of a real-time = system to perform its tasks.

TW> Would = it make sense to discuss hard and soft real-time here, = in

TW> particular in the context of = a wireless system?

  =  

 

  =  Three techniques are employed by DetNet to achieve these = QoS

  =  parameters:

 

  =  a.  Zero congestion loss (Section 3.1).  Network = resources such as

  =      link bandwidth, buffers, queues, shapers, and = scheduled input/

TW> add = 6TiSCH cells?

       output = slots are assigned in each relay system to the use of = a

       specific = DetNet stream or group of streams.  Note that, given = a

       finite = amount of buffer space)

TW> extra = ")"

   , zero congestion loss = necessarily

       ensures a = maximum end-to-end latency.  Depending on the = method

       employed, = 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 or

  =      more listeners can be established, and DetNet = streams assigned to

  =      follow a particular path or = tree.

TW> Using a single path in a = wireless system will fail, I would = recommend

TW> 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 = eliminate

      =  replicated 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 at

  =      least one path intact for a DetNet = stream.

 

  =  These three techniques can be applied independently, giving = eight

   possible combinations, = including none (no DetNet), although = some

   combinations are of = wider utility than others.  This separation = keeps

   the protocol stack = coherent and maximizes interoperability = with

   existing and developing = standards in this (IETF) and other = Standards

   Development = Organizations.  Some examples of typical = expected

  =  combinations:

 

  =  o  Pinned-down paths (a) plus packet replication (b) are = exactly the

      techniques = employed by [HSR-PRP].  Pinned-down paths are = achieve

      by limiting the = physical topology of the network, and = the

      = sequentialization, replication, and duplicate = elimination

      facilitated by = packet tags added at the front or the end = of

      Ethernet = frames.

 

  =  o  Zero congestion loss (a) alone is is offered by IEEE 802.1 = Audio

      Video bridging = [IEEE802.1BA-2011].  As long as the network = suffers

      no failures, = near-zero (at best, zero) congestion loss can = be

      achieved = through the use of a reservation protocol (MSRP) = and

      shapers 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 = satisfactory

   for many = applications.  However, these methods generally work best = in

   the absence of any = significant amount of non-critical traffic in = the

   network (if, indeed, = such traffic is supported at all), or work = only

   if the critical traffic = constitutes only a small portion of = the

   network's theoretical = capacity, or work only if all systems = are

   functioning properly, = or in the absence of actions by end = systems

   that disrupt the = network's operations.

 

  =  There are any number of methods in use, defined, or in progress = for

   accomplishing each of = the above techniques.  It is expected that = this

   DetNet Architecture = will assist various vendors, users, = and/or

   "vertical" = Standards Development Organizations (dedicated to a = single

   industry) to make = selections among the available means = of

   implementing DetNet = networks.

 

3.1.  = Zero Congestion Loss

 

  =  The primary means by which DetNet achieves its QoS assurances is = to

   completely eliminate = congestion at an output port as a cause = of

   packet 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 = at

   each hop through the = network to ensure that no packets are = dropped

   due to a lack of buffer = storage.

TW> and the provision the = sufficient link bandwidth?

 

  =  Ensuring adequate buffering requires, in turn, that the talker, = and

   every relay system = along the path to the listener (or nearly = every

   relay system -- see = Section 4.5.2) be careful to regulate its = output

   to not exceed the data = rate for any stream, except for brief = perios

TW> = typo

   when making up for = interfering traffic.  Any packet sent ahead of = its

   time potentially adds = to the number of buffers required by the = next

   hop, and may thus = exceed the resources allocated for a = particular

  =  stream.

 

  =  The low-level mechanisms described in Section 4.7 provide = the

   necessary regulation of = transmissions by an edge system or = relay

   system to ensure zero = congestion loss.  Of course, the reservation = of

   the bandwidth and = buffers for a stream requires the = provisioning

   described in Section = 4.12.

 

3.2.  = Pinned-down paths

 

  =  In networks controlled by typical peer-to-peer protocols such as = IEEE

   802.1 ISIS bridged = networks or ETF OSPF routed networks, a = network

   topology event in one = part of the network can impact, at = least

   briefly, the delivery = of data in parts of the network remote from = the

   failure or recovery = event.  Thus, even redundant paths through = a

   network, if controlled = by the typical peer-to-peer protocols, do = not

   eliminate 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 = minimizes

   recovery time and = easily supports redundant paths.  Of course, = this

   comes at the cost of = increased hop count, and thus latency, for = the

   typical = path.

 

  =  In order to get the advantages of low hop count and still = ensure

   against even brief = losses of connectivity, DetNet employs = pinned-down

   paths, where the path = taken by a given DetNet stream does not = change,

   at least immediately, = and likely not at all, in response to = network

   topology events.  = When combined with seamless = redundancy

   (Section 3.3), this = results in a high likelihood of = continuous

  =  connectivity.

 

3.3.  = Seamless Redundancy

 

  =  After congestion loss has been eliminated, the most important = causes

   of packet loss are = random media and/or memory faults and = equipment

  =  failures.

 

 

 

 

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 at

      least two = different paths to the listener(s).

 

  =  o  Discarding duplicated = packets.

 

  =  In the simplest case, this amounts to replicating each packet in = a

   talker that has two = interfaces, and conveying them through = the

   network, along separate = paths, to the similarly dual-homed = listeners,

   that discard the = extras.  This ensures that one path (with = zero

   congestion loss) = remains, even if some relay system = fails.

TW> this has some energy cost = associated?

  =  

   Alternatively, relay = systems in the network can provide = replication

   and elimination = facilities at various points in the network, so = that

   multiple failures can = be accommodated.

 

  =  This is shown in the following figure, where the two relay = systems

   each replicate (R) the = DetNet stream on input, sending the stream = to

   both the other relay = system and to the end system, and = eliminated

   duplicates (E) on the = output interface to the right-hand end = system.

   Any one = links

TW> = typo

   in the network can = fail, and the Detnet stream can

  =  still get through.  Furthermore, two links can fail, as long = as they

   are in different = segments of the network.

 

  =                   =  > > > > > > > >   relay   =  > > > > > > > = >

          =           > /------------+ R system E = +------------\ >

  =                  > / =                  v + ^ =                 \ = >

   end    R + =                   v | ^ =                  + E = end

   system   +   =                 v | ^   =                +   = system

          =          > \         =          v + ^         =         / >

  =                   > = \------------+ R relay  E +------------/ = >

          =            > > > > > > = > >   system   > > > > > > > = >

 

  =                     =            Figure = 1

TW> I don't understand what R and = E means

 

4.  = DetNet Architecture

 

  =  Traffic Engineering Architecture and Signaling (TEAS) [TEAS] = defines

   traffic-engineering = architectures for generic applicability = across

   packet and non-packet = networks.  From TEAS perspective, = Traffic

   Engineering (TE) refers = to techniques that enable operators = to

   control how specific = traffic flows are treated within their = networks.

 

  =  Because if its very nature of establishing pinned-down = optimized

   paths, 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 = a

   separation into = planes.

 

  =  The Deterministic Networking architecture is thus composed of = three

   planes, a (User) = Application Plane, a Controller Plane, and a = Network

   Plane, which echoes = that of Software-Defined Networking = (SDN): 

TW> double = ":"

  =  Layers

   and 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 = and

   services.  In = particular, the Application Plane incorporates the = User

   Agent, a specialized = application that interacts with the end user = /

   operator and performs = requests for Deterministic Networking = services

   via an abstract Stream = Management Entity, (SME) which may or may = not

   be collocated with (one = of) the end systems.

 

  =  At the Application Plane, a management interface enables = the

   negotiation of streams = between end systems.  An abstraction of = the

   stream called a Traffic = Specification (TSpec) provides the

  =  representation.  This abstraction is used to place a = reservation over

  =  the (Northbound) Service Interface and within the Application = plane.

   It is associated with = an abstraction of location, such as = IP

   addresses and DNS = names, to identify the end systems and = eventually

   specify intermediate = relay systems.

 

4.2.  = The Controller Plane

 

  =  The Controller Plane corresponds to the aggregation of the = Control

   and Management Planes = in [RFC7426], though Common Control = and

   Measurement Plane = (CCAMP) [CCAMP] makes an additional = distinction

   between management and = measurement.  When the logical separation = of

   the Control, = Measurement and other Management entities is = not

   relevant, the term = Controller Plane is used for simplicity = to

   represent them all, and = the term controller refers to any = device

   operating in that = plane, whether is it a Path Computation entity or = a

   Network Management = entity (NME).  The Path Computation Element = (PCE)

   [PCE] is a core element = of a controller, in charge of = computing

   Deterministic paths to = be applied in the Network Plane.

 

  =  A (Northbound) Service Interface enables applications in = the

   Application Plane to = communicate with the entities in the = Controller

  =  Plane.

 

 

TW> could = you define NME, SME and PCE in the = terminology?

  =  

   One or more PCE(s) = collaborate to implement the requests from the = SME

   as Per-Stream Per-Hop = Behaviors installed in the relay systems = for

   each individual = streams.  The PCEs place each stream along = a

   deterministic sequence = of relay systems so as to respect = per-stream

   constraints such as = security and latency, and optimize the = overall

   result for metrics such = as an abstract aggregated cost.  = The

   deterministic sequence = can typically be more complex than a = direct

   sequence and include = redundancy path, with one or more = packet

   replication 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 = a

   whole, regardless of = the Layer at which the network devices = operate.

 

  =  The network Plane comprises the Network Interface Cards (NIC) in = the

   end systems, which are = typically IP hosts, and relay systems, = which

   are typically IP = routers and switches.  Network-to-Network = Interfaces

   such as used for = Traffic Engineering path reservation in = [RFC3209],

   as well as = User-to-Network Interfaces (UNI) such as provided by = the

   Local Management = Interface (LMI) between network and end systems, = are

   all part of the Network = Plane.

 

  =  A Southbound (Network) Interface enables the entities in = the

   Controller Plane to = communicate with devices in the Network = Plane.

   This interface = leverages and extends TEAS to describe the = physical

   topology and resources = in the Network Plane.

 

  =                     =    Stream Management Entity

 

  =      End               =                     =                   = End

          =  System                 =                     =           = System

 

  =     -+-+-+-+-+-+-+ Northbound = -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

 

  =               PCE     =     PCE              PCE =             =  PCE

 

  =     -+-+-+-+-+-+-+ Southbound = -+-+-+-+-+-+-+-+-+-+--+-+-+-+-+-+-

 

  =                 Relay   =    Relay      Relay     =  Relay

          =         System     System     = System     System

  =      NIC               =                     =                   = NIC

          =         Relay      Relay   =    Relay     =  Relay

          =         System     System     = System     System

 

  =                     =            Figure = 3

 

  =  The relay systems (and eventually the end systems NIC) expose = their

   capabilities and = physical resources to the controller (the PCE), = and

   update the PCE with = their dynamic perception of the topology, = across

   the Southbound = Interface.  In return, the PCE(s) set the = per-stream

   paths up, providing a = Stream Characterization that is more = tightly

   coupled to the relay = system Operation than a TSpec.

 

  =  At the Network plane, relay systems exchange information = regarding

   the state of the paths, = between adjacent systems and eventually = with

   the 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 = resort

   operation such as drop = or declassify.

 

  =  This specification focuses on the Southbound interface and = the

   operation of the = Network Plane.

 

4.4.  = Elements of DetNet Architecture

 

  =  The DetNet architecture has a number of elements, discussed in = the

   following = sections:

 

  =  a.  A model for the definition, identification, and operation = of

       DetNet = streams (Section 4.5), for use by relay systems = to

       classify = and process individual packets following = per-stream

      =  rules.

TW> how is a packet = "labeled" as part of = stream?

 

  =  b.  A model for the flow of data from an end system or = through a

       relay = system that can be used to predict the bounds for = that

       system's = impact on the QoS of a DetNet stream, = without

      =  significantly constraining the method of implementing = that

       system, = for use by the Controllers to configure policing = and

       shaping = 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 end

  =          system or relay system to control the = selection of packets

  =          output on an interface.  These = models must have sufficiently

  =          well-defined characteristics, both = individually and in the

  =          aggregate, to give predictable results = for the QoS for DetNet

  =          packets (Section = 4.7).

 

  =      2.  A model for identifying misbehaving DetNet = streams and

          =  mitigating their impact on properly functioning = streams

          =  (Section 4.9).

 

  =  c.  A model for the relay system to inform the controller(s) = of the

      =  information 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.  hysical

TW> = typo

          =  resources (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 relay

       systems, = to forward a DetNet stream over a simple or = redundant

      =  path.  The model includes:

 

  =      1.  A model for an abstract relaying operation = of either Routing

  =          or forwarding packets of a DetNet = stream to a next-hop relay

  =          system, across Layer = boundaries.

 

  =      2.  A model of next-hop(s) information for = replicating the

  =          packets of a DetNet stream, typically = at or near the talker,

  =          merging and/or re-replicating those = packets at other points

  =          in the network, and finally = eliminating the duplicates,

  =          typically at or near the listener(s), = in order to provide

  =          high availability (Section = 3.3).

 

  =  e.  The protocol stack model for an end system and/or a relay = system

       should = support the above elements in a manner that maximizes = the

      =  applicability of existing standards and protocols to the = DetNet

       problem, = allows for the creation of new protocols where = needed,

       thus = making DetNet an add-on feature to existing networks, = rather

       than a = new way to do networking.  In particular this = protocol

       stack = supports networks in which the path from talker = to

      =  listener(s) includes bridges and/or routers in any = order

       (Section = 4.10).

 

  =  f.  A variety of models for the provisioning of DetNet = streams can be

  =      envisioned, including orchestration by a central = controller or by

  =      a federation of controllers, provisioning by relay = systems and

       end = systems sharing peer-to-peer protocols, by = off-line

      =  configuration, or by a combination of these methods.  = The

      =  provisioning models are similar to existing Layer-2 and = Layer-3

       models, = in order to minimize the amount of innovation required = in

       this area = (Section 4.12).

 

4.5.  = DetNet streams

 

4.5.1.  = Talker guarantees

 

  =  DetNet streams can by synchronous or asynchronous.  The = transmission

   of packets in = synchronous DetNet streams uses time = synchronization

  =  among 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 = observation

      = interval.

 

  =  These parameters, together with knowledge of the protocol stack = used

   (and thus the size of = the various headers added to a packet), = limit

   the number of bit times = per observation interval that the = DetNet

   stream can occupy the = physical medium.

 

  =  The talker promises that these limits will not be exceeded.  = If the

   talker transmits less = data than this limit allows, the = unused

   resources such as link = bandwidth can be made available by the = system

   to non-DetNet = packets.  However, making those resources available = to

   DetNet packets in other = streams would serve no purpose.  Those = other

   streams have their own = dedicated resources, on the assumption = that

   all DetNet streams can = use all of their resources over a long = period

   of = time.

 

  =  Note that there is no provision in DetNet for throttling streams; = the

   assumption is that a = DetNet stream, to be useful, must be = delivered

   in its entirety.  = That is, while any useful application is written = to

   expect a certain number = of lost packets, the real-time = applications

   of interest to DetNet = demand that the loss of data due to the = network

   is extraordinarily = infrequent.

 

  =  Although DetNet strives to minimize the changes required of = an

   application to allow it = to shift from a special-purpose = digital

   network to an Internet = Protocol network, one fundamental shift in = the

   behavior of network = applications that is impossible to = avoid--the

   reservation of = resources before the application starts.  In the = first

   place, a network cannot = deliver finite latency and practically = zero

   packet loss to an = arbitrarily high offered load.  Secondly, = achieving

   practically zero packet = loss for unthrottled (though = bandwidth

   limited) streams means = that bridges and routers have to = dedicate

   buffer resources to = specific streams or to classes of streams.  = The

   requirements of each = reservation have to be translated into = the

   parameters that control = each system's queuing, shaping, and

  =  scheduling functions and delivered to the hosts, bridges, = and

  =  routers.

 

4.5.2.  = Incomplete Networks

 

  =  The presence in the network of relay systems that are not = fully

   capable of offering = DetNet services complicates the ability of = the

   relay systems and/or = controller to allocate resources, as = extra

   buffering, and thus = extra latency, must be allocated at each = point

   that is downstream from = the non-DetNet relay system for some = DetNet

  =  stream.

 

 

 

 

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 = Group

   has defined a set of = queuing, shaping, and scheduling algorithms = that

   enable each bridge or = router to compute the exact number of = buffers

   to 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 = the

   network bandwidth to = DetNet streams.  But, no matter how much = is

   dedicated for DetNet = streams, It is z

TW> = typo

   goal of DetNet to not = interfere

   excessively with = existing QoS schemes.  It is also important = that

   non-DetNet traffic not = disrupt the DetNet stream, of course = (see

   Section 4.9 and Section = 6).  For these reasons:

 

  =  o  Bandwidth (transmission opportunities) not utilized by a = DetNet

      stream are = available to non-DetNet packets (though not to = other

      DetNet = 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 = scheduled

      in detail, then = the algorithm constructing the schedule = should

      leave = sufficient opportunities for non-DetNet packets to = satisfy

      the needs of = the uses of the network.

 

  =  Ideally, the net effect of the presence of DetNet streams in = a

   network on the = non-DetNet packets is primarily a = reductoin

TW> = typo

   in = the

   available = bandwidth.

 

4.9.  = Fault Mitigation

 

  =  One key to building robust real-time systems is to reduce = the

   infinite variety of = possible failures to a number that can = be

   analyzed with = reasonable confidence.  DetNet aids in the process = by

   providing filters and = policers to detect DetNet packets received = on

   the 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 = the

   offending = interface.

 

  =  It is also essential that filters and service = remarking

TW> please define "service = remarking"

  =  be employed

  =  to prevent non-DetNet packets from impinging on the = resources

   allocated 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 = of

   standardization, that = can perform these fault mitigation tasks = that

   deliver a high = probability that misbehaving systemd

TW> = typo

   will have = zero

   impact on well-behaved = DetNet streams, except of course, for = the

   receiving interface(s) = immediately downstream of the = misbehaving

  =  device.

 

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 = in

   progress, 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 = model

   is attractive but a = number of issues are left to be solved.  = In

  =  particular:

 

  =  o  whether and how the path computation can be installed by = 1) an end

      device or 2) a = Network Management entity,

 

  =  o  and how the path is set up, either by installing state at = each hop

      with a direct = interaction between the forwarding device and = the

      PCE, or along a = path by injecting a source-routed request at = one

      end of the = path.

 

4.12.2.  Distributed Path = Setup

 

  =  Whether a distributed alternative without a PCE can be = valuable

   should be studied as = well.  Such an alternative could for = instance

   inherit from the = Resource ReSerVation Protocol [RFC5127] = (RSVP)

  =  flows.

 

  =  In a Layer-2 only environment, or as part of a layered approach to = a

   mixed environment, IEEE = 802.1 also has work, either completed or = in

   progress. =  [IEEE802.1Q-2011] Clause 35 describes SRP, a = peer-to-peer

   protocol for Layer-2 = roughly analogous to RSVP.  Almost complete = is

   [IEEE802.1Qca], which = defines how ISIS can provide multiple = disjoint

   paths 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 = Differentiated

  =  Services 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 = service

   class.  The = document also describes how the code-point can be = mapped

   into one of the = aggregated Diffserv service classes = [RFC5127].

 

5.2. =  6TiSCH

 

  =  Industrial process control already leverages deterministic = wireless

   Low power and Lossy = Networks (LLNs) to interconnect = critical

   resource-constrained = devices and form wireless mesh networks, = with

   standards such as = [ISA100.11a] and [WirelessHART].

 

  =  These standards rely on variations of the [IEEE802154e] = timeSlotted

   Channel Hopping (TSCH) = [I-D.ietf-6tisch-tsch] Medium Access = Control

   (MAC), and a form of = centralized Path Computation Element (PCE), = to

   deliver deterministic = capabilities.

 

  =  The TSCH MAC benefits include high reliability against = interference,

   low power consumption = on characterized streams, and Traffic

  =  Engineering capabilities.  Typical applications are open and = closed

   control loops, as well = as supervisory control streams and = management.

 

  =  The 6TiSCH Working Group focuses only on the TSCH mode of the = IEEE

   802.15.4e = standard.  The WG currently defines a framework = for

   managing the TSCH = schedule.  Future work will = standardize

   deterministic = operations over so-called tracks as described = in

  =  [I-D.ietf-6tisch-architecture].  Tracks are an instance of = a

   deterministic path, and = the DetNet work is a prerequisite to = specify

   track operations and = serve process control applications.

 

  =  [RFC5673] and [I-D.ietf-roll-rpl-industrial-applicability] = section

   2.1.3.  and next = discusses application-layer paradigms, such = as

   Source-sink (SS) that = is a Multipeer to Multipeer (MP2MP) model = that

   is primarily used for = alarms and alerts, Publish-subscribe (PS, = or

   pub/sub) that is = typically used for sensor data, as well as = Peer-to-

   peer (P2P) and = Peer-to-multipeer (P2MP) communications.  = Additional

   considerations on = Duocast and its N-cast generalization are = also

   provided 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 = added

   dimension; the time of = delivery of a packet can be just as = important

   as the contents of the = packet, itself.  A man-in-the-middle = attack,

   for example, can = impose, and then systematically adjust, = additional

   delays into a link, and = thus disrupt or subvert a real-time

  =  application 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 = of

   equipment, or even = human lives, can be lost if the DetNet QoS is = not

   delivered, one must = consider not only simple equipment = failures,

   where the box or wire = instantly becomes perfectly silent, but = bizarre

   errors such as can be = coused

TW> = typo

   by software = failures.  Because there is

  =  essentiall

TW> = typo

   no limit to the kinds = of failures that can occur,

  =  protecting against realistic equipment failures is = indistinguishable,

  =  in most cases, from protecting against malicious behavior, = whether

   accidental 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, = George

   Swallow, 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, = for

   their various = contribution with this work.

 

9.  = Informative References

 

  =  [AVnu]     http://www.avnu.org/, "The AVnu Alliance = tests and

          =     certifies devices for interoperability, providing a = simple

          =     and reliable networking solution for AV = network

          =     implementation 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",

  =  [HART]     www.hartcomm.org, "Highway Addressable Remote = Transducer,

          =     a group of specifications for industrial process = and

          =     control devices administered by the HART Foundation", = .

 

  =  [HSR-PRP]  IEC, "High availability seamless redundancy = (HSR) is a

          =     further development of the PRP approach, although = HSR

          =     functions primarily as a protocol for creating = media

          =     redundancy while PRP, as described in the = previous

          =     section, creates network redundancy.  PRP and HSR are = both

          =     described in the IEC 62439 3 = standard.",

          =     = artnum/046615!opendocument>.

 

  =  [I-D.finn-detnet-problem-statement]

  =             Finn, N. and P. Thubert, = "Deterministic Networking = Problem

          =     Statement", draft-finn-detnet-problem-statement-01 = (work

          =     in 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 IEEE

  =             802.15.4e", = draft-ietf-6tisch-architecture-05 (work = in

          =     progress), January = 2015.

 

  =  [I-D.ietf-6tisch-tsch]

  =             Watteyne, T., Palattella, M., = and L. Grieco, "Using

  =             IEEE802.15.4e TSCH in an IoT = context: Overview, Problem

  =             Statement and Goals", = draft-ietf-6tisch-tsch-05 (work in

  =             progress), January = 2015.

 

  =  [I-D.ietf-roll-rpl-industrial-applicability]

<= /div>

              Phinney, T., = Thubert, P., and R. Assimiti, = "RPL

          =     applicability 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 = in

          =     progress), March 2015.

 

  =  [IEEE802.1AS-2011]

  =             IEEE, "Timing and = Synchronizations (IEEE = 802.1AS-2011)",

  =             2011, <http://standards.ieee.org/getIEEE802/

          =     = 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,

          =     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)",

  =             2010, <http://standards.ieee.org/getIEEE802/

          =     = 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,

          =     ca-drafts/>.

 

  =  [IEEE802.1Qcc]

  =             IEEE, "Stream Reservation = Protocol (SRP) Enhancements and

  =             Performance = Improvements", 2015,

          =     cc-drafts/>.

 

  =  [IEEE802.1TSNTG]

  =             IEEE Standards Association, = "IEEE 802.1 Time-Sensitive

  =             Networks Task Group", = 2013,

          =     <http://www.IEEE802.org/1/pages/avbridges.html>.<= /span>

 

  =  [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-Rate

  =             Wireless 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 Area

  =             Networks (LR-WPANs) Amendment = 1: MAC sublayer", April

  =             = 2012.

 

  =  [ISA100.11a]

  =             ISA/IEC, "ISA100.11a, = Wireless Systems for Automation,

  =             also IEC 62734", 2011, = < http://www.isa100wci.org/en-

<= /div>

              = US/Documents/PDF/3405-ISA100-WirelessSystems-Future-broch-

          =     WEB-ETSI.aspx>.

 

  =  [ODVA]     http://www.odva.org/, "The organization that = supports

          =     network technologies built on the Common = Industrial

          =     Protocol (CIP) including EtherNet/IP.", = .

 

  =  [PCE]      IETF, "Path Computation = Element",

 

  =  [Profinet]

  =             http://us.profinet.com/technology/profinet/, = "PROFINET is

  =             a standard for industrial = networking in automation.",

 

  =  [RFC2205]  Braden, B., Zhang, L., Berson, S., Herzog, S., and = S.

          =     Jamin, "Resource ReSerVation Protocol (RSVP) -- = Version 1

          =     Functional 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 LSP

  =             Tunnels", RFC 3209, = December 2001.

 

  =  [RFC4655]  Farrel, A., Vasseur, J., and J. Ash, "A Path = Computation

          =     Element (PCE)-Based Architecture", RFC 4655, August = 2006.

 

  =  [RFC5127]  Chan, K., Babiarz, J., and F. Baker, = "Aggregation of

  =             Diffserv Service = Classes", RFC 5127, February = 2008.

 

  =  [RFC5673]  Pister, K., Thubert, P., Dwars, S., and T. = Phinney,

          =     "Industrial Routing Requirements in Low-Power and = Lossy

          =     Networks", RFC 5673, October = 2009.

 

  =  [RFC7384]  Mizrahi, T., "Security Requirements of Time = Protocols in

          =     Packet 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-Defined

  =             Networking (SDN): Layers and = Architecture Terminology",

  =             RFC 7426, January = 2015.

 

  =  [TEAS]     IETF, "Traffic Engineering Architecture = and Signaling",

 

  =  [WirelessHART]

  =             www.hartcomm.org, = "Industrial Communication Networks = -

          =     Wireless Communication Network and Communication = Profiles

          =     - WirelessHART - IEC 62591", = 2010.

 

Authors' = Addresses

 

  =  Norm Finn

  =  Cisco Systems

  =  170 W Tasman Dr.

  =  San Jose, California =  95134

  =  USA

 

  =  Phone: +1 408 526 4495

  =  Email: nfinn@cisco.com

 

 

  =  Pascal Thubert

  =  Cisco Systems

  =  Village d'Entreprises Green = Side

   400, Avenue de = Roumanille

   Batiment = T3

   Biot - Sophia Antipolis =  06410

  =  FRANCE

 

  =  Phone: +33 4 97 23 26 = 34

   Email: pthubert@cisco.com

=

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Finn & = Thubert         Expires September 10, 2015   =            [Page = 23]

------=_NextPart_001_0024_01D06589.5B79D3A0-- ------=_NextPart_000_0023_01D06589.5B79D3A0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOLTCCBDYw ggMeoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwbzELMAkGA1UEBhMCU0UxFDASBgNVBAoTC0FkZFRy dXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBUVFAgTmV0d29yazEiMCAGA1UEAxMZ QWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0wMDA1MzAxMDQ4MzhaFw0yMDA1MzAxMDQ4Mzha MG8xCzAJBgNVBAYTAlNFMRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQGA1UECxMdQWRkVHJ1c3Qg RXh0ZXJuYWwgVFRQIE5ldHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0IEV4dGVybmFsIENBIFJvb3Qw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC39xoz5vIABC054E5b7R+8bA/Ntfojts7e mxEzl6QpTH2Tn71KvJPtAxrjj8/lbVBa1pcplFqAsEl62y6V/bjKvzc4LR4+kUGtcFbH8E8/6DKe dMrIkFTpxl8PeJ2aQDwOrGGqXhSPnoehalDc15pOrwWzpnGUnHGzUGAKxxOdOAeGAqjpqGkmGJCr TLBPI6s6T4TY386f4Wlvu9dC12tE5Met7m1BX3JacQg3s3llpFmglDf3AC8NwpJy2tA4ctsUqEXE XSp9t7TWxO6szRNEt8kr3UMAJfphuWlqWCMRt6czj1Z1WfXNKddGtworZbbTQm8Vsrh7++/pXVPV NFonAgMBAAGjgdwwgdkwHQYDVR0OBBYEFK29mHo0tCb3+sQmVO8DveAky1QaMAsGA1UdDwQEAwIB BjAPBgNVHRMBAf8EBTADAQH/MIGZBgNVHSMEgZEwgY6AFK29mHo0tCb3+sQmVO8DveAky1QaoXOk cTBvMQswCQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0 IEV4dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290 ggEBMA0GCSqGSIb3DQEBBQUAA4IBAQCwm+CFJcLWI+IPlgaSnUGYnNmEeYHZHlsUByM2ZY+w2He7 rEFsR2CDUbD5Mj3n/PYmE8eAFqW/WvyHz3h5iSGa4kwHCoY1vPLeUcTSlrfcfk7ucP0cOesMAlEU LY69FuDB30Z15ySt7PRCtIWTcBBnup0GNUoY0yt6zFFCoXpj0ea7ocUrwja+Ew3mvWN+eXunCQ1A q2rdj4rD9vaMGkIFUdRF9Z+nYiFoFSBDPJnnfL0k2KmRF3OIP1YbMTgYtHEPms3IDp6OLhvhjJiD yx8x8URMxgRzSXZgD8f4vReAay7pzEwOWpp5DyAKLtWeYyYeVZKU2IIXWnvQvMePToYEMIIErzCC A5egAwIBAgIRAOAjyxUSg1OJrWFuelRnayEwDQYJKoZIhvcNAQELBQAwbzELMAkGA1UEBhMCU0Ux FDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBUVFAgTmV0 d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0xNDEyMjIwMDAwMDBa Fw0yMDA1MzAxMDQ4MzhaMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVz dGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UE AxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwg Q0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCJsQ3aelMZTnBSHbxWpgYmt7hJ4Jbn Uavx8FoTSRWjtIwbYLx6UUKneYykIt8XYU6R1XYjChTTSgJ/th0JgG6lBD3ZursW/qGHqS5DUkMW fK8yUMimT1rpCNjPkyWce4joMGTmpPhWgP0qJBQzF5msROVpi6NGBkvCM9TpQJ8GsLGsk0C5tQiT OpwqU6MQ2z0gYTxVA47ZTnYlAiEp+qN8cXZP7uFfgen7VIDbw3s1UreE3iI9LDAtMX9ZvVI3sDNp LUPr+tal8Zd3Z1GM2e4n67ylBzh2jKSpOP/fjPUDrEm+yvdzmToPMquclToTPQ5GOld0YVC+xkA/ y+Tin6IhAgMBAAGjggEXMIIBEzAfBgNVHSMEGDAWgBStvZh6NLQm9/rEJlTvA73gJMtUGjAdBgNV HQ4EFgQUkmFrguGioKpP7GfxwqP3tIAAwewwDgYDVR0PAQH/BAQDAgGGMBIGA1UdEwEB/wQIMAYB Af8CAQAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMBEGA1UdIAQKMAgwBgYEVR0gADBE BgNVHR8EPTA7MDmgN6A1hjNodHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vQWRkVHJ1c3RFeHRlcm5h bENBUm9vdC5jcmwwNQYIKwYBBQUHAQEEKTAnMCUGCCsGAQUFBzABhhlodHRwOi8vb2NzcC51c2Vy dHJ1c3QuY29tMA0GCSqGSIb3DQEBCwUAA4IBAQAbKm6sVcE6q4jF2O3NVfOqa2ErwAkQI5kPxWZq b7H1tLV3Xg8CYQDffQX+ErOkgIAA/PsdW2pyAgpBvAW6wVjVJsLq1U2E+/6CmM9YG+MiY5xS+LsF Nqt9WKXeqztj5drVc+/s4Pt74qP/8EIjnMq2jU0+5EsYA7KoLdTYu0JLkGmFENumNzToe+ABEKWc yjrHn0+ING6KZdAairup3MrKNtH0/MJkKTWv1rGncRHSA0Oxjz6a7J4yU/R2ksqGNAe5LMrmHErY mQ3BhuKQkvtaQmojIRDpZcf11bt+6oyFIAJi6tE6ByxZxZkz8jiJ5bbpFnofeRT2ShAaJvp8ivub MIIFPDCCBCSgAwIBAgIRAImdrrrSrE1TMdXIyvE0qYEwDQYJKoZIhvcNAQELBQAwgZsxCzAJBgNV BAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAY BgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQg QXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xNTAyMDMwMDAwMDBaFw0xNjAy MDMyMzU5NTlaMCMxITAfBgkqhkiG9w0BCQEWEnB0aHViZXJ0QGNpc2NvLmNvbTCCASIwDQYJKoZI hvcNAQEBBQADggEPADCCAQoCggEBALTqoFHH36vHzOLhXp5Wv28HBpYWouQolX/OzHVrZbIEblHp NAxFdrnNSWULDP5gT8hp/t4P0XO3YEnaQxpPUu0wWFlLrDC690s0y3T0hATowmfycNcLX+hddBDL 8ChyZdJAVhxl0vnxORmcciJmXmWOJ+4lzEqaDbm5lZUHgi3kc0t9/IFOOJ6yq1kjttHu1MFPZZUc lUnlpXmD+2/GzxeCHlQgLvw232No6lrAS34PQxbu7rnfw25Spd3CFP7RymWZnNL26rIvt3J4rpv8 xy0EedfU3AUo5scNpr7Mb1npOgVU7N+K07atmjh71wpvfnpvwIxPA+OOHcXwOS5JsosCAwEAAaOC AfAwggHsMB8GA1UdIwQYMBaAFJJha4LhoqCqT+xn8cKj97SAAMHsMB0GA1UdDgQWBBS2xFsxMSdl ViqpYN1OZcdW6Bg4OTAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggr BgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYB BAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMF0G A1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET1NIQTI1NkNsaWVu dEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgZAGCCsGAQUFBwEBBIGDMIGAMFgG CCsGAQUFBzAChkxodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9TSEEyNTZDbGllbnRBdXRo ZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5j b21vZG9jYS5jb20wHQYDVR0RBBYwFIEScHRodWJlcnRAY2lzY28uY29tMA0GCSqGSIb3DQEBCwUA A4IBAQABMkoJZJ5HHnG3Sl0jOpl8Emhb5fjpyW2eK26Zy8e62uqUL7ExSBChD97N1lCYUFY4TqIR zCmaObFC+fDgG3IDQ7ZOJDVu6ZK8TAGiBF6sSYcg5rSfIKPxJUQvTciSrTE+XHEVONmU6xQrMIYY 4/T4iho50oQmNpTSNmGc19ZZ9mQtbRGsjdwILm5NvIyI3X088GidfVJqifQ9dRmSikzELdvlmdBs TFdAM1zx3CscylrUPQyy3lrLuvWf9arpPHV7sex+cwkLKOGHl26mXMoOPwvEYcpJJ3phmR/aqxbC mZwz4LugVrqvC0sFERLSjfarSBQxKL7XSxxS6JYEL3LpMYIEdDCCBHACAQEwgbEwgZsxCzAJBgNV BAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAY BgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQg QXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAImdrrrSrE1TMdXIyvE0qYEwCQYF Kw4DAhoFAKCCApcwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTUw MzIzMjI0OTQxWjAjBgkqhkiG9w0BCQQxFgQUbrHFy/jJfPTbNIvhA7M2sxXf4dUwgasGCSqGSIb3 DQEJDzGBnTCBmjALBglghkgBZQMEASowCwYJYIZIAWUDBAEWMAoGCCqGSIb3DQMHMAsGCWCGSAFl AwQBAjAOBggqhkiG9w0DAgICAIAwBwYFKw4DAgcwDQYIKoZIhvcNAwICAUAwDQYIKoZIhvcNAwIC ASgwBwYFKw4DAhowCwYJYIZIAWUDBAIDMAsGCWCGSAFlAwQCAjALBglghkgBZQMEAgEwgcIGCSsG AQQBgjcQBDGBtDCBsTCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3Rl cjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMT OENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENB AhEAiZ2uutKsTVMx1cjK8TSpgTCBxAYLKoZIhvcNAQkQAgsxgbSggbEwgZsxCzAJBgNVBAYTAkdC MRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoT EUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAImdrrrSrE1TMdXIyvE0qYEwDQYJKoZIhvcN AQEBBQAEggEAWsHI99WuGU8uwKhBDQWeuMfTggTA1zZuYNTyCc9qav9vugWhVgxv46FBpIIu0UFf k/nkEBenrKdcsQDVTkTa3UgWMGnFcbQAJo5EhSy3Rs+kTAwOTfoa666pNWIsJTtuWqOFHk82aPBf K1T+8Tbs9F3g65VNqf7nDPDFD0t5j8enUWxjs0E7b4vu11+y88akS3E1Hn6+iAmsnIzkpkQe00Y/ WEq+fbsk0cujjbfGP9vqj+/+H5qTOT/V2hPbVkJ3vPkL01yDe/9EfDyoB+GUAHhsF8tU3QPXBCBD m/xTjOd1X1enpUYypDkQHzcTJJ/eMNjWl7E8CY4vosUbMPUpFQAAAAAAAA== ------=_NextPart_000_0023_01D06589.5B79D3A0-- From nobody Wed Mar 25 08:44:25 2015 Return-Path: X-Original-To: detnet@ietfa.amsl.com Delivered-To: detnet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 050271B2A69 for ; Wed, 25 Mar 2015 08:44:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 qiVBrz-rVX_F for ; Wed, 25 Mar 2015 08:44:24 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E3311B2A75 for ; Wed, 25 Mar 2015 08:44:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15522; q=dns/txt; s=iport; t=1427298263; x=1428507863; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=IAIRcYxZSrNyN1zu5kc4dCpy39X36Vto4o+rirEhcCQ=; b=lVAdwiiDfkOjhhinRF625UGhhm3+FkCz1s9LNdP0dMxwqGa5i+0Dvb2U +mZUzEIqUxTls9VQCExKTmANsc2yRwE6Ln6zSKUgSzr+OTePD9MvHyCWp h50Ayh7c/htiJt1iXiiZcuHJg7Ts4yK+VGn2aVQK47BT1NHOeVL4jaG7M 0=; X-Files: smime.p7m : 11343 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DcCAAj1xJV/4gNJK1cgwaBMMJSiDACgVZMAQECAQF9hBYBBBkbVwEqJjAmAQQbBoghn1OVcJN9AQEBAQEBBAEBAQEBAQEbj2aDT4EWBY5Cgg6BaYEyhlWUKyKDboIzfwEBAQ X-IronPort-AV: E=Sophos;i="5.11,465,1422921600"; d="p7m'?scan'208";a="135251856" Received: from alln-core-3.cisco.com ([173.36.13.136]) by alln-iport-1.cisco.com with ESMTP; 25 Mar 2015 15:44:22 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id t2PFiMpg013743 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 25 Mar 2015 15:44:22 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.104]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.03.0195.001; Wed, 25 Mar 2015 10:44:22 -0500 From: "Pascal Thubert (pthubert)" To: "detnet@ietf.org" Thread-Topic: let us use this ML! Thread-Index: AdBnEoBvmSJrAkD3QP6i0ywpu3UI1Q== Date: Wed, 25 Mar 2015 15:44:21 +0000 Deferred-Delivery: Wed, 25 Mar 2015 15:44:00 +0000 Message-ID: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.61.64.245] Content-Type: application/pkcs7-mime; smime-type=signed-data; name="smime.p7m" Content-Disposition: attachment; filename="smime.p7m" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: [Detnet] let us use this ML! X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussions on Deterministic Networking, characterized by 1\) resource reservation; 2\) 0 congestion loss and guaranteed latency; 3\) over L2-only and mixed L2 and L3 networks; and 5\) 1+1 replication/deletion." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2015 15:44:25 -0000 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAaCAJIAEggR/Q29u dGVudC1UeXBlOiBtdWx0aXBhcnQvbWl4ZWQ7DQoJYm91bmRhcnk9Ii0tLS09X05leHRQYXJ0XzAw MF8wMEExXzAxRDA2NkUwLjM4MDUxOEYwIg0KWC1NUy1UTkVGLUNvcnJlbGF0b3I6IDAwMDAwMDAw NEMxRUY4OEIwNzdEMkQ0MUE4ODM1NkQxMjFGQ0Y0ODEwNzAwQkMyRjdFREMwRjEyMkI0MzlCNEFG MUM2NTZCQTM0RjkwMDAwMDEzQURCRjEwMDAwQUYwMDFEOTgzNTFCM0Y0ODhGNUVDRkQ5NzFBMTEw MTIwMDRCODIzNjBCQ0IwMDAwDQoNClRoaXMgaXMgYSBtdWx0aXBhcnQgbWVzc2FnZSBpbiBNSU1F IGZvcm1hdC4NCg0KLS0tLS0tPV9OZXh0UGFydF8wMDBfMDBBMV8wMUQwNjZFMC4zODA1MThGMA0K Q29udGVudC1UeXBlOiB0ZXh0L3BsYWluOw0KCWNoYXJzZXQ9InVzLWFzY2lpIg0KQ29udGVudC1U cmFuc2Zlci1FbmNvZGluZzogN2JpdA0KDQpEZWFyIGFsbCA6DQoNCiANCg0KSSB3ZW50IHRocm91 Z2ggbXkgKHJhdGhlciB0aGljaykgZGV0bmV0IGZvbGRlciBhbmQgYnkgc2NyZWVuaW5nIGl0IEkN CnJlYWxpemVkIHRoYXQgYSBsYXJnZSBwb3J0aW9uIG9mIHRoZSBtZXNzYWdlcyBJIHN0b3JlIHRo ZXJlIHdlcmUgbm90DQphY3R1YWxseSBjb3BpZWQgdG8gdGhlIGxpc3QuDQoNCkl0IGlzIHJlYWxs eSBjcml0aWNhbCB0aGF0IHVubGVzcyBzb21ldGhpbmcgaXMgcmVhbGx5IHBlcnNvbmFsLCBhY3Rp dml0eQ0KcmVnYXJkaW5nIERldE5ldCBhbmQgb3VyIGRvY3VtZW50IGlzIHNlbnQgdG8gdGhlIGxp c3QuIA0KDQpUaGlzIGdpdmVzIGEgc2Vuc2Ugb2YgdGhlIGFtb3VudCBvZiB3b3JrIGFuZCBkZWRp Y2F0aW9uIHRoYXQgd2UgaGF2ZQ0KZGVwbG95ZWQsIGFuZCB0aGF0IHdpbGwgYmUgY3JpdGljYWwg Zm9yIHRoZSBzdWNjZXNzIG9mIGEgV0cgZm9ybWluZyBCb0YgaW4NClByYWd1ZS4NCg0KIA0KDQpB bGwgdGhlIGJlc3QhDQoNCiANCg0KUGFzY2FsDQoNCiANCg0KDQotLS0tLS09X05leHRQYXJ0XzAw MF8wMEExXzAxRDA2NkUwLjM4MDUxOEYwDQpDb250ZW50LVR5cGU6IGFwcGxpY2F0aW9uL21zLXRu ZWY7DQoJbmFtZT0id2lubWFpbC5kYXQiDQpDb250ZW50LVRyYW5zZmVyLUVuY29kaW5nOiBiYXNl NjQNCkNvbnRlbnQtRGlzcG9zaXRpb246IGF0dGFjaG1lbnQ7DQoJZmlsZW5hbWU9Indpbm1haWwu ZGF0Ig0KDQoEghAAZUo4K0lqc1BBUWFRQ0FBRUFBQUFBQUFCQUFFQUFRZVFCZ0FJQUFBQTVBUUFB QUFBQUFEb0FBRUlnQWNBR0FBQUFFbFFUUzVOYVdOeQ0KYjNOdlpuUWdUV0ZwYkM1T2IzUmxBREVJ QVFPUUJnREVEZ0FBTEFBQUFBc0FBZ0FCQUFBQUF3QW1BQUFBQUFBTEFDa0FBQUFBQUI0QQ0KY0FB QkFBQUFGQUFBQUd4bGRDQjFjeUIxYzJVZ2RHaHBjeUJOVENFQUFnRnhBQUVBQUFBV0FBQUFBZEJu RW9Cdm1TSnJBa0QzUVA2aQ0KMHl3cHUzVUkxUUFBQ3dBQkRnQUFBQUFDQVFvT0FRQUFBQzRBQUFB QUFBQUFUQjc0aXdkOUxVR29nMWJSSWZ6MGdRRUF2QzkrM0E4Uw0KSzBPYlN2SEdWcm8wK1FBQUFU cmI4Z0FBQUFBZUFDZ09BUUFBQUhjQUFBQXdNREF3TURBd01RRjRZMmhqWVhOb1lTNWphWE5qYnk1 ag0KYjIwdmJ6MURhWE5qYnlCVGVYTjBaVzF6TDI5MVBVWnBjbk4wSUVGa2JXbHVhWE4wY21GMGFY WmxJRWR5YjNWd0wyTnVQVkpsWTJsdw0KYVdWdWRITXZZMjQ5Y0hSb2RXSmxjblFCVFdsamNtOXpi MlowSUVWNFkyaGhibWRsQUFBZUFDa09BUUFBQUhjQUFBQXdNREF3TURBdw0KTVFGNFkyaGpZWE5v WVM1amFYTmpieTVqYjIwdmJ6MURhWE5qYnlCVGVYTjBaVzF6TDI5MVBVWnBjbk4wSUVGa2JXbHVh WE4wY21GMA0KYVhabElFZHliM1Z3TDJOdVBWSmxZMmx3YVdWdWRITXZZMjQ5Y0hSb2RXSmxjblFC VFdsamNtOXpiMlowSUVWNFkyaGhibWRsQUFBTA0KQUJZd0FRQUFBQU1BM2orZlRnQUFBd0R4UHd3 RUFBQWVBUG8vQVFBQUFCTUFBQUJ3ZEdoMVltVnlkRUJqYVhOamJ5NWpiMjBBQUFNQQ0KQWxrQUFC WUFBd0FKV1FJQUFBQUxBQkdBQ0NBR0FBQUFBQURBQUFBQUFBQUFSZ0FBQUFBVWhRQUFBUUFBQUFN QUZJQUlJQVlBQUFBQQ0KQU1BQUFBQUFBQUJHQUFBQUFCQ0ZBQUFBQUFBQUN3QWdnQWdnQmdBQUFB QUF3QUFBQUFBQUFFWUFBQUFBQTRVQUFBQUFBQUFEQUZLQQ0KQ0NBR0FBQUFBQURBQUFBQUFBQUFS Z0FBQUFBQmhRQUFBQUFBQUI0QVlJQ0dBd0lBQUFBQUFNQUFBQUFBQUFCR0FRQUFBQm9BQUFCag0K QUc4QWJnQjBBR1VBYmdCMEFDMEFkQUI1QUhBQVpRQUFBQUFBQVFBQUFEMEFBQUJoY0hCc2FXTmhk R2x2Ymk5d2EyTnpOeTF0YVcxbA0KTzNOdGFXMWxMWFI1Y0dVOWMybG5ibVZrTFdSaGRHRTdibUZ0 WlQxemJXbHRaUzV3TjIwQUFBQUFDd0EwZ1FnZ0JnQUFBQUFBd0FBQQ0KQUFBQUFFWUFBQUFBQm9V QUFBQUFBQUFMQURpQkNDQUdBQUFBQUFEQUFBQUFBQUFBUmdBQUFBQU9oUUFBQUFBQUFBTUFPNEVJ SUFZQQ0KQUFBQUFNQUFBQUFBQUFCR0FBQUFBQmlGQUFBQUFBQUFBZ0ZCZ1FnZ0JnQUFBQUFBd0FB QUFBQUFBRVlBQUFBQUlJVUFBQUVBQUFCaw0KQVFBQUFnRUVBQUFBQUFBQUFBVlNaWEJzZVFoSlVF MHVUbTkwWlFkTlpYTnpZV2RsQWxKRkJRQUFBQUFBQUFBQUFRQUFBQUFBQUFBQw0KQUFBQVpnQUFB QUlBQUFBQkFBQUFERkpsY0d4NUlIUnZJRUZzYkFoSlVFMHVUbTkwWlFkTlpYTnpZV2RsQWxKRkJR QUFBQUFBQUFBQQ0KQVFBQUFBQUFBQUFDQUFBQVp3QUFBQU1BQUFBQ0FBQUFCMFp2Y25kaGNtUUlT VkJOTGs1dmRHVUhUV1Z6YzJGblpRSkdWd1VBQUFBQQ0KQUFBQUFBRUFBQUFBQUFBQUFnQUFBR2dB QUFBRUFBQUFBd0FBQUE5U1pYQnNlU0IwYnlCR2IyeGtaWElJU1ZCTkxsQnZjM1FFVUc5eg0KZEFB RkFBQUFBQUFBQUFBQkFBQUFBQUFBQUFJQUFBQnNBQUFBQ0FBQUFBUUJCVklBWlFCd0FHd0FlUUFD VWdCRkFBeFNBR1VBY0FCcw0KQUhrQUlBQjBBRzhBSUFCQkFHd0FiQUFDVWdCRkFBZEdBRzhBY2dC M0FHRUFjZ0JrQUFKR0FGY0FEMUlBWlFCd0FHd0FlUUFnQUhRQQ0KYndBZ0FFWUFid0JzQUdRQVpR QnlBQUFMQUZLQkNDQUdBQUFBQUFEQUFBQUFBQUFBUmdBQUFBQ0NoUUFBQVFBQUFBTUFDNFFIRGdB Ug0KRzdYV1FLOGh5cWhlMnJIUUFBQUFBQlVBQUFBQUFBQUFDd0FmRGdFQUFBQUNBZmdQQVFBQUFC QUFBQUE1ZWthVkdCc21TYnpDTGpDLw0KK094c0FnSDZEd0VBQUFBUUFBQUFUQjc0aXdkOUxVR29n MWJSSWZ6MGdRTUEvZzhGQUFBQUF3QU5OUDAvclE0REFBODAvVCt0RGdJQg0KRkRRQkFBQUFFQUFB QUZTVW9jQXBmeEFicFljSUFDc3FKUmNDQWVKbEFRQUFBQlFBQUFCWlpQZ1lLaEViUXErdGhYczRH WlppQUFFYw0KNEFJQjQyVUJBQUFBRlFBQUFCUlpaUGdZS2hFYlFxK3RoWHM0R1paaUFBRWM0QUFB QUFJQkNSQUJBQUFBbXdjQUFKY0hBQUR6RkFBQQ0KVEZwR2RSWFFvZHNEQUFvQWNtTndaekV5TllJ eUEwTm9kRzFzTVFNeCtHSnBaQVFBQXpBQkF3SDNDb0FuQXFRRDR3SUFZMmdLd0hObA0KK0hRd0lB Y1RBb0FRZ3dCUUJGYS9DRlVIc2hKVkRsRURBUkZYTWdZQSt3YkRFbFV6QkVZUldSTnJFbU1JNzIw Sjl6c1pUdzR3TlJKUw0KREdCalp3QlFDd2tCWkRNMkVlQUxwVFJ5SUJDQ0tsd09zZ0dRRGhBNVpD QThEcklnZUE3UUFJQTZTSFk5SWdod2Jqb0U4R2hpWlFEQQ0KY3kxdERlQURZSE5xYndHQUxRV2di Ui9RRHRBaVhSOTFieC8vSVFraE1HWU40R1Y3SkNVaDVuY2lmeU9QSlhBRnNHUU5JZVp0SlpBTw0K c0hSd09pK3FMeVgxTGlEWExpRnhMeVEwWWk4QjBEQTBMdzRnS25CdEN5SEhLSmQzTExBdWR6TXVB UVd3Wnk5VVVpOVNSWVJETFE2eQ0KTkRBaVBoSmpqUjVuTXg0QUh5QmxZV1F1VFRReE5nN3dQQWVB QVpBZ2JqSmhCNEE5Undud0JKQmhkSzhGc1FXZ0FqQUo4SFFsa0UwZw0KNXFRZ1Z5ZlJJREVlQUNn a1VEY2VzQVNRQ1lBZ0I0QVBVSFZ0RGlrdVBoM3dNTUZ6ZEhsc1JtVTFEekRCSVMwdENxTXZ5Q29n UmdJaA0KSUVRQkVBdUFtR2wwYVFJZ0JDQXFMd3FqMGtBQ0VpMW1BTkJsQ3FRQmtRMERNSHM2RlNE UWJIazZRM2tIUUdsaUJSQWFZRHEzQ3JCdQ0KSVNFUVpTMHhPaFZ3TVRYZUlENEFGWEErUWg0QU16 NXlHbUNPZlRtL09zODcwMVJoYUFOeDl6eWZQYVFPOERZK2t6NEFIZ0FlQURzKw0KNlRoUlV6WlNP TThLd1hBdUdrMGhJRTRGc0FEQWJDd2c5enhBUnVvUFVIWkc2RUE2QU1BdE1HRUxnRG93WTIxQ0dV b1VMWmNHNEFKQQ0KSVlFdUt3QXdNUVV3OTBJWlA2TUFrSG9rZ0VOd1RFQk1uNFU3cGlJOEpTSXNJ bk1BY1V0Tm9BWnlJajhXWVRvOFFHNGFhMGVBY3oxQg0KUnVKSWVYQS9CSkJSMGtsYklTQk5vRFpT TFhEUEJSQUZzRGtnUEFBNU9VSVpHTVB1T2dveVFoa3lZSGdoVUFXRE1lRHhPVUU2ZFc0RQ0KZ1ZI UlZwRlJWbjUyQkFBNUlBbUFVaDlSOERpQWJMMFk0SGNKZ0ZOUFZGOVZibkFJY044TFVGYWZWNjlZ dVViVFFTUndBWkQvTW1CSA0KaG1JM1NJVmlOVnV2WEw5S3lYZGxaMUhTVDhCQ0IwQVk0QUlnSVA1 VVgrRVRVQkdCVVNGSzNVcC9TNC83VGs5TnBEaE9MMDg1UWJSUQ0KWHdxam5Wb1RSUURBQXhCRlF6 RTNaSjkvWmFNMlVGTFFYckFFa0NFZ01VQnMvU0ZpY0QxeGJtOVBmM0I3VlgwRDhQOVlZRnRnWDlK eA0KSzJoVmFOSnBJbksvLzJXak1VSm9QMmxOWlc5bWYyZVBmYWEvYVdwdkgzQXZQeVZHNG40d2NF V2gvR0YxSHJCN3IzUElYK0IxSUFBZw0KL2kwQ0lEdndndzkyZjRVZlAzRUtzTzVuUllBellnWmdZ emt5SENOQWRvdE5zekN3TW00aUlEYzVqeU9CYXM4Nk56QXVPRFdQVW4rUg0KTDVHelB4WklnbzAv UUlXTTRqci9rOG8vRmpmZ05wOGZBU2tRTmw4M2FESmJCcEFnWnpKZ2dTSWdPU2hkUGp3ZmdUNEtv enh2dnlYZw0KRVlCUzBBRUJodUlFSUhhSXdiOHlrVFNSZ3VCYUFROUFBTUI0SlpCUU1UQXlOaUhn TDVzMUw1dWJBamZBV3dud0QxQm1YWmJmNzVtUA0KbXArYnBRdGdlUWhnQlVDY3FxdWJONTJTY0p5 Y1pESGdZWjNodjU1Sm92dWlNSjd2TGx3MkFpOHZmNVVlMERVUjREd0c0R1I1UjVDQg0KQUhCblBV Vk9MVlVGOEgxUjBqMEtNcHlRclJOZXhDNU5PYjFEb0R4SWdUSWdDMkFFRUQyVHl2Y3VRQjV6QUNF Z0FBQ3hOUkhnSGl0Kw0KTmk5QnBXQ3Y1RWIzc1EreUgyZk9PQzlCV2hLc1ZFWlN0SSsxazQ5Rm9G R0NXMEMxN2ladVlsb1FZd0tBdDlkY0oyRUJRTFZYT3ZlZw0KRFM5Qm02QnduKzRPUUtkRHZjNy9q NUNZRWoxQnQ3bTN4eDF4dCtVS292L0JpQXFCdXhjS3NjT1lzazBCd0pnUi83M09zeiswVDhTLw0K dG0rM2Y4bVB2US8vdWIrNno4eXZ2bSsvZjhDUHdaL0Nyei9EdjlFZnhkL0c3OGYvekQ5SklCTmJj RGloZEdnRFlIVm5hUHMwY0t4QQ0KS0RIUkpoQUZ3TjRnRGVCOGF5bEljQkhBTWJBRlFBSVFiT2NF Z1ZHZwSCBN1XR0FnWXF4QUJQRUo0ZmtMZ0djZ09TRGRvUmxRUERGTjBQOHoNCmtONGdNZUJSb0t4 UkxUQkZnSWp5L1RsQklDRXczaEdoc1FlUWk2Q05BUDhFSU4yd21FQUZzRVdBM3dKRmdGdHc3K1V4 UFdEaXdaUWcNCmRYMXhyRUFGb0wrZGdPSmlvZkRrRWp4QW1FQXV6VS8vemwvU1M5WGYxdS9YLzlr UDJoL2JMLy9jUDkxR0JVQVBZZUlDNXJLQUVRM2cNCi93ZEE0b1JnMEs1UUJCRWhJRER4MzJELzRZ THpKM1JtUjREbVVVaVFnQ0hoOGU1bkN4SGhja1dnZEFmQTRzSGdzZk1JWVVod2IyTTANCndOM2lE MkVSc1AvZDh1ZHB6VC9wSCtvdjZ6L3NUKzFmMys1djczL3dqL0dmQUtKVTMyRHpJUDFxVUhZSGtU RWcrY0ZEQU9QV01WRHYNCm81QTRvZVBoSjhGcjRKTVBvQTlRNy9RQTQ1UGlrMXR3SUJHQUJpRGZz ZmtMVUc5NVdkTGdvZ2swY2lEMElMNWlSWUR6dHhBUTN6SkYNCmdITWNBTThrY1BUUjQrRXhJRmRI RERJbWNMSGhnVUp2UnVHZ3kxQlFNZEQrWnhvdzZBLzc3L3ovL2cvL0h3QXYvd0UvQWs4RFh3UnYN CkZPOFAvODh2MEQvL0dhOFJYeEp2RTM4ZHJ4V2ZGcThYdjNzWXp4blFRUXRSNUJJTGdKaEFJZjha L3hzUEh2OGdEeUVmSWk4alB5UlANCi95VmZKbThlSHlsZkcrOGMvek1QS3IvL0s4OHMzemNQTHY4 d0R6RWZNaThPb1Ard0FQUUJNMDgwWHpoUE9WODZienQvL3p5UFBaOCsNCnJ6Ky9OMjlDUHpVL05r Ly9TKzlEbjBTdlJiOVA3MGZmb0VlZUFMMU5FUyt2b2RSL1ZMK3J3RGlxY2J1c0VwL3VONnB5VHlH cFlIMWMNCklBQkFBQThBQU9BVWd4Sm4wQUZBQU84L0FPQVVneEpuMEFFQ0FYOEFBUUFBQUkwQUFB QXdNREF3TURBd01EUkRNVVZHT0RoQ01EYzMNClJESkVOREZCT0Rnek5UWkVNVEl4UmtOR05EZ3hN RGN3TUVKRE1rWTNSVVJETUVZeE1qSkNORE01UWpSQlJqRkROalUyUWtFek5FWTUNCk1EQXdNREF4 TTBGRVFrWXhNREF3TUVGR01EQXhSRGs0TXpVeFFqTkdORGc0UmpWRlEwWkVPVGN4UVRFeE1ERXlN REEwUWpneU16WXcNClFrTkNNREF3TUFBQUFBQURBQVlRQThjSm53TUFCeENDQVFBQUF3QVFFQUFB QUFBREFCRVFBQUFBQUI0QUNCQUJBQUFBWlFBQUFFUkYNClFWSkJURXc2U1ZkRlRsUlVTRkpQVlVk SVRWa29Va0ZVU0VWU1ZFaEpRMHNwUkVWVVRrVlVSazlNUkVWU1FVNUVRbGxUUTFKRlJVNUoNClRr ZEpWRWxTUlVGTVNWcEZSRlJJUVZSQlRFRlNSMFZRVDFKVVNVOU9UMFpVU0VWTlJWTlRRVWNBQUFB QURtaz0NCg0KLS0tLS0tPV9OZXh0UGFydF8wMDBfMDBBMV8wMUQwNjZFMC4zODA1MThGMC0tDQoA AAAAAACggg4tMIIENjCCAx6gAwIBAgIBATANBgkqhkiG9w0BAQUFADBvMQswCQYDVQQGEwJTRTEU MBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4dGVybmFsIFRUUCBOZXR3 b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290MB4XDTAwMDUzMDEwNDgzOFoX DTIwMDUzMDEwNDgzOFowbzELMAkGA1UEBhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYD VQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0 ZXJuYWwgQ0EgUm9vdDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALf3GjPm8gAELTng TlvtH7xsD821+iO2zt6bETOXpClMfZOfvUq8k+0DGuOPz+VtUFrWlymUWoCwSXrbLpX9uMq/Nzgt Hj6RQa1wVsfwTz/oMp50ysiQVOnGXw94nZpAPA6sYapeFI+eh6FqUNzXmk6vBbOmcZSccbNQYArH E504B4YCqOmoaSYYkKtMsE8jqzpPhNjfzp/haW+710LXa0Tkx63ubUFfclpxCDezeWWkWaCUN/cA Lw3CknLa0Dhy2xSoRcRdKn23tNbE7qzNE0S3ySvdQwAl+mG5aWpYIxG3pzOPVnVZ9c0p10a3Citl ttNCbxWyuHv77+ldU9U0WicCAwEAAaOB3DCB2TAdBgNVHQ4EFgQUrb2YejS0Jvf6xCZU7wO94CTL VBowCwYDVR0PBAQDAgEGMA8GA1UdEwEB/wQFMAMBAf8wgZkGA1UdIwSBkTCBjoAUrb2YejS0Jvf6 xCZU7wO94CTLVBqhc6RxMG8xCzAJBgNVBAYTAlNFMRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQG A1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5ldHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0IEV4 dGVybmFsIENBIFJvb3SCAQEwDQYJKoZIhvcNAQEFBQADggEBALCb4IUlwtYj4g+WBpKdQZic2YR5 gdkeWxQHIzZlj7DYd7usQWxHYINRsPkyPef89iYTx4AWpb9a/IfPeHmJIZriTAcKhjW88t5RxNKW t9x+Tu5w/Rw56wwCURQtjr0W4MHfRnXnJK3s9EK0hZNwEGe6nQY1ShjTK3rMUUKhemPR5ruhxSvC Nr4TDea9Y355e6cJDUCrat2PisP29owaQgVR1EX1n6diIWgVIEM8med8vSTYqZEXc4g/VhsxOBi0 cQ+azcgOno4uG+GMmIPLHzHxREzGBHNJdmAPx/i9F4BrLunMTA5amnkPIAou1Z5jJh5VkpTYghda e9C8x49OhgQwggSvMIIDl6ADAgECAhEA4CPLFRKDU4mtYW56VGdrITANBgkqhkiG9w0BAQsFADBv MQswCQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4 dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290MB4X DTE0MTIyMjAwMDAwMFoXDTIwMDUzMDEwNDgzOFowgZsxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJH cmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBM aW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVudGljYXRpb24gYW5k IFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAImxDdp6UxlO cFIdvFamBia3uEngludRq/HwWhNJFaO0jBtgvHpRQqd5jKQi3xdhTpHVdiMKFNNKAn+2HQmAbqUE Pdm6uxb+oYepLkNSQxZ8rzJQyKZPWukI2M+TJZx7iOgwZOak+FaA/SokFDMXmaxE5WmLo0YGS8Iz 1OlAnwawsayTQLm1CJM6nCpToxDbPSBhPFUDjtlOdiUCISn6o3xxdk/u4V+B6ftUgNvDezVSt4Te Ij0sMC0xf1m9UjewM2ktQ+v61qXxl3dnUYzZ7ifrvKUHOHaMpKk4/9+M9QOsSb7K93OZOg8yq5yV OhM9DkY6V3RhUL7GQD/L5OKfoiECAwEAAaOCARcwggETMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQm VO8DveAky1QaMB0GA1UdDgQWBBSSYWuC4aKgqk/sZ/HCo/e0gADB7DAOBgNVHQ8BAf8EBAMCAYYw EgYDVR0TAQH/BAgwBgEB/wIBADAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEQYDVR0g BAowCDAGBgRVHSAAMEQGA1UdHwQ9MDswOaA3oDWGM2h0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9B ZGRUcnVzdEV4dGVybmFsQ0FSb290LmNybDA1BggrBgEFBQcBAQQpMCcwJQYIKwYBBQUHMAGGGWh0 dHA6Ly9vY3NwLnVzZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQELBQADggEBABsqbqxVwTqriMXY7c1V 86prYSvACRAjmQ/FZmpvsfW0tXdeDwJhAN99Bf4Ss6SAgAD8+x1banICCkG8BbrBWNUmwurVTYT7 /oKYz1gb4yJjnFL4uwU2q31Ypd6rO2Pl2tVz7+zg+3vio//wQiOcyraNTT7kSxgDsqgt1Ni7QkuQ aYUQ26Y3NOh74AEQpZzKOsefT4g0bopl0BqKu6ncyso20fT8wmQpNa/WsadxEdIDQ7GPPprsnjJT 9HaSyoY0B7ksyuYcStiZDcGG4pCS+1pCaiMhEOllx/XVu37qjIUgAmLq0ToHLFnFmTPyOInltukW eh95FPZKEBom+nyK+5swggU8MIIEJKADAgECAhEAiZ2uutKsTVMx1cjK8TSpgTANBgkqhkiG9w0B AQsFADCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UE BxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBT SEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTE1MDIw MzAwMDAwMFoXDTE2MDIwMzIzNTk1OVowIzEhMB8GCSqGSIb3DQEJARYScHRodWJlcnRAY2lzY28u Y29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtOqgUcffq8fM4uFenla/bwcGlhai 5CiVf87MdWtlsgRuUek0DEV2uc1JZQsM/mBPyGn+3g/Rc7dgSdpDGk9S7TBYWUusMLr3SzTLdPSE BOjCZ/Jw1wtf6F10EMvwKHJl0kBWHGXS+fE5GZxyImZeZY4n7iXMSpoNubmVlQeCLeRzS338gU44 nrKrWSO20e7UwU9llRyVSeWleYP7b8bPF4IeVCAu/DbfY2jqWsBLfg9DFu7uud/DblKl3cIU/tHK ZZmc0vbqsi+3cnium/zHLQR519TcBSjmxw2mvsxvWek6BVTs34rTtq2aOHvXCm9+em/AjE8D444d xfA5LkmyiwIDAQABo4IB8DCCAewwHwYDVR0jBBgwFoAUkmFrguGioKpP7GfxwqP3tIAAwewwHQYD VR0OBBYEFLbEWzExJ2VWKqlg3U5lx1boGDg5MA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAA MCAGA1UdJQQZMBcGCCsGAQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEEBAMCBSAwRgYD VR0gBD8wPTA7BgwrBgEEAbIxAQIBAQEwKzApBggrBgEFBQcCARYdaHR0cHM6Ly9zZWN1cmUuY29t b2RvLm5ldC9DUFMwXQYDVR0fBFYwVDBSoFCgToZMaHR0cDovL2NybC5jb21vZG9jYS5jb20vQ09N T0RPU0hBMjU2Q2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBkAYIKwYB BQUHAQEEgYMwgYAwWAYIKwYBBQUHMAKGTGh0dHA6Ly9jcnQuY29tb2RvY2EuY29tL0NPTU9ET1NI QTI1NkNsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcnQwJAYIKwYBBQUHMAGG GGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTAdBgNVHREEFjAUgRJwdGh1YmVydEBjaXNjby5jb20w DQYJKoZIhvcNAQELBQADggEBAAEySglknkcecbdKXSM6mXwSaFvl+OnJbZ4rbpnLx7ra6pQvsTFI EKEP3s3WUJhQVjhOohHMKZo5sUL58OAbcgNDtk4kNW7pkrxMAaIEXqxJhyDmtJ8go/ElRC9NyJKt MT5ccRU42ZTrFCswhhjj9PiKGjnShCY2lNI2YZzX1ln2ZC1tEayN3Agubk28jIjdfTzwaJ19UmqJ 9D11GZKKTMQt2+WZ0GxMV0AzXPHcKxzKWtQ9DLLeWsu69Z/1quk8dXux7H5zCQso4YeXbqZcyg4/ C8RhykknemGZH9qrFsKZnDPgu6BWuq8LSwUREtKN9qtIFDEovtdLHFLolgQvcukxggR0MIIEcAIB ATCBsTCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UE BxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBT SEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhEAiZ2uutKs TVMx1cjK8TSpgTAJBgUrDgMCGgUAoIIClzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0xNTAzMjUxNTQzNTlaMCMGCSqGSIb3DQEJBDEWBBROPym+2IH5kBV8mZMnx26Q MlKsjTCBqwYJKoZIhvcNAQkPMYGdMIGaMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYwCgYIKoZI hvcNAwcwCwYJYIZIAWUDBAECMA4GCCqGSIb3DQMCAgIAgDAHBgUrDgMCBzANBggqhkiG9w0DAgIB QDANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjALBglghkgBZQMEAgMwCwYJYIZIAWUDBAICMAsGCWCG SAFlAwQCATCBwgYJKwYBBAGCNxAEMYG0MIGxMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3Jl YXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGlt aXRlZDFBMD8GA1UEAxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBT ZWN1cmUgRW1haWwgQ0ECEQCJna660qxNUzHVyMrxNKmBMIHEBgsqhkiG9w0BCRACCzGBtKCBsTCB mzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2Fs Zm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2 IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhEAiZ2uutKsTVMx1cjK 8TSpgTANBgkqhkiG9w0BAQEFAASCAQAAZW37K8j0qV36MTlL5OARad8LI3yrg355Oad52M6vB0/r Y2330SJcFMRyc5CdjoxYi/RStLE7dhb8tBWLF/c4hKdzFxy1SReRYcPmvSrKJ/FnlgHag/4LpeVj pPnGWemhQ9fh8GGuPhpEQ54pF4kWxgINZrDoDE9iz0YxL4a7qHm4ig++7Uqsj+vJZW7feUQMxQPW 1IcC2KWk++CNaMCMp1LZHRxzCKNGc6WweytRPqYQ4EjHUxOW2azGkwDyyR5PP0hOFjEfm/qv5LPH S4iWDTpRjIwiNwA/NU4PgURShti8Rixv6UHLCpxDeAcgMytP5pzJcN8+IZAaXsRuWq1tAAAAAAAA From nobody Wed Mar 25 08:49:21 2015 Return-Path: X-Original-To: detnet@ietfa.amsl.com Delivered-To: detnet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07EEB1A8860 for ; Wed, 25 Mar 2015 08:49:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.077 X-Spam-Level: X-Spam-Status: No, score=-0.077 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_20=-0.001, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 R-kC45h0-Chy for ; Wed, 25 Mar 2015 08:49:16 -0700 (PDT) Received: from mail-wi0-f175.google.com (mail-wi0-f175.google.com [209.85.212.175]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3AC021ACE86 for ; Wed, 25 Mar 2015 08:49:10 -0700 (PDT) Received: by wixw10 with SMTP id w10so44685361wix.0 for ; Wed, 25 Mar 2015 08:49:08 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=Qs8Hk//lwHmdx84T4a2pcEqlLU9cyNouXSXWqTxwHlI=; b=NMVja4YWTpazvoDzlI1qJpfWgN9NxL6hV1lfyzUjnNjXel+An3o1YiUspjBArl3p0O P2yxreBBANJIquz02SKeJ5l+4OfTdVV8ZgpTVfxLRl10F9Hp7cWwEaZVTG3Zgpys0sMv 0fBQ1xwz7l7HXzHMGZzXgCIzZkO8IBloIIVx4XvZ7jHppXFEZb7q5W5ENnIYZW4ihku7 ZD6+RtdPVNaqKpeY2rmIracEPP9PWEPYGYiYgUUd9ttWakSew5ana+18f0jN3bQ6LMAE h2QJ4qV+g7Qnl33mpYU0n3FV6zmMBpADm9zGqDB24R31rGji6jNHh+d6wDkm95qjyg89 DIEQ== X-Gm-Message-State: ALoCoQnZ3Dt5Z9+DmQDpe4Zej7kWlQGqmcp+R9UL8gm2426+MOSCLjMcEhn3S7rzMmDgJfubJd1X MIME-Version: 1.0 X-Received: by 10.180.109.70 with SMTP id hq6mr38961341wib.16.1427298548413; Wed, 25 Mar 2015 08:49:08 -0700 (PDT) Received: by 10.28.39.135 with HTTP; Wed, 25 Mar 2015 08:49:08 -0700 (PDT) Date: Wed, 25 Mar 2015 10:49:08 -0500 Message-ID: From: "Prof. Diego Dujovne" To: "detnet@ietf.org" Content-Type: multipart/alternative; boundary=e89a8f3baa09f78e1605121ed604 Archived-At: Subject: [Detnet] Looking for partners for Gap Analysis draft X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussions on Deterministic Networking, characterized by 1\) resource reservation; 2\) 0 congestion loss and guaranteed latency; 3\) over L2-only and mixed L2 and L3 networks; and 5\) 1+1 replication/deletion." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2015 15:49:19 -0000 --e89a8f3baa09f78e1605121ed604 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Dear all, I have published the first (-00) version of the Gap Analysis draft: https://tools.ietf.org/html/draft-dujovne-detnet-gap-analysis-00 I'm looking for co-authors to collaborate to build this draft. Let me know through the list if you are interested. Thank you. Diego Dujovne --=20 DIEGO DUJOVNE Acad=C3=A9mico Escuela de Ingenier=C3=ADa en Inform=C3=A1tica y Telecomunic= aciones Facultad de Ingenier=C3=ADa UDP www.ingenieria.udp.cl (56 2) 676 8125 --e89a8f3baa09f78e1605121ed604 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear all,
=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 I have published = the first (-00) version of the
Gap Analysis draft:

https= ://tools.ietf.org/html/draft-dujovne-detnet-gap-analysis-00

=C2= =A0I'm looking for co-authors to collaborate
to build this dra= ft. Let me know through the list
if you are interested.
T= hank you.

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Diego Dujovne

--
DIEGO DUJOVNE
Acad=C3=A9mico Escuela de Ingenier=C3=ADa en Inf= orm=C3=A1tica y Telecomunicaciones
Facultad de Ingenier=C3=ADa UDP
www.ingenieria.udp= .cl
(56 2) 676 8125
--e89a8f3baa09f78e1605121ed604-- From nobody Wed Mar 25 08:49:44 2015 Return-Path: X-Original-To: detnet@ietfa.amsl.com Delivered-To: detnet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 002421A87E3 for ; Wed, 25 Mar 2015 08:49:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 HTf1yFijBAzp for ; Wed, 25 Mar 2015 08:49:41 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4A021A87B1 for ; Wed, 25 Mar 2015 08:49:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7982; q=dns/txt; s=iport; t=1427298581; x=1428508181; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=elwAbKAFuEwcYRFVOFbZcsMYwb4l0gkhgpVeRhraJjM=; b=WN9UymRpW5fbGgumLoxA98qghyAVEPv9PKfyH3oRDW7Ih1+D9W3NP/Pv CJpA+Uvg332CcrNpwzWnDTUFLBc5AMQfYrVeIQmD21yOy5JkDsyLE3jqE 8HPFJ3lIhDHcU5W/Fdiq9rfbMmqHaE3gKI293qCN3b5p+cBERcfMGUiC2 8=; X-Files: smime.p7s : 4831 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DpCAB92BJV/5hdJa1cgwZSWgTCUoIxCoUsSQKBVkwBAQEBAQF9hBQBAQEEAQEBaxcEAgEIEQQBAQsdBwIlCxQJCAEBBBMIBoghDckvAQEBAQEBAQEBAQEBAQEBAQEBAQEBEwSLIYQlAQEeOAaDEYEWBZBQgWmBMoZVlCsig25vgQs5fwEBAQ X-IronPort-AV: E=Sophos;i="5.11,465,1422921600"; d="p7s'?scan'208";a="135305951" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-6.cisco.com with ESMTP; 25 Mar 2015 15:49:41 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id t2PFnesZ027826 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 25 Mar 2015 15:49:41 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.104]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.03.0195.001; Wed, 25 Mar 2015 10:49:40 -0500 From: "Pascal Thubert (pthubert)" To: "detnet@ietf.org" Thread-Topic: let us use this ML! Thread-Index: AdBnEoBvmSJrAkD3QP6i0ywpu3UI1QAAHyjg Date: Wed, 25 Mar 2015 15:49:39 +0000 Deferred-Delivery: Wed, 25 Mar 2015 15:49:00 +0000 Message-ID: References: In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.61.64.245] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_00CA_01D066E0.D7A61E40" MIME-Version: 1.0 Archived-At: Subject: Re: [Detnet] let us use this ML! X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussions on Deterministic Networking, characterized by 1\) resource reservation; 2\) 0 congestion loss and guaranteed latency; 3\) over L2-only and mixed L2 and L3 networks; and 5\) 1+1 replication/deletion." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2015 15:49:43 -0000 ------=_NextPart_000_00CA_01D066E0.D7A61E40 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I seem to have an issue with my mail system, sorry about that: I sent the following and received back an empty mail: " Dear all : I went through my (rather thick) Detnet folder and by screening it I realized that a large portion of the messages I store there were not actually copied to the list. It is really critical that unless something is really personal, activity regarding DetNet and our document is sent to the list. This gives a sense of the amount of work and dedication that we have deployed, and that will be critical for the success of a WG forming BoF in Prague. " Cheers, Pascal > -----Original Message----- > From: detnet [mailto:detnet-bounces@ietf.org] On Behalf Of Pascal Thubert > (pthubert) > Sent: mercredi 25 mars 2015 09:44 > To: detnet@ietf.org > Subject: [Detnet] let us use this ML! > > _______________________________________________ > detnet mailing list > detnet@ietf.org > https://www.ietf.org/mailman/listinfo/detnet ------=_NextPart_000_00CA_01D066E0.D7A61E40 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOLTCCBDYw ggMeoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwbzELMAkGA1UEBhMCU0UxFDASBgNVBAoTC0FkZFRy dXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBUVFAgTmV0d29yazEiMCAGA1UEAxMZ QWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0wMDA1MzAxMDQ4MzhaFw0yMDA1MzAxMDQ4Mzha MG8xCzAJBgNVBAYTAlNFMRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQGA1UECxMdQWRkVHJ1c3Qg RXh0ZXJuYWwgVFRQIE5ldHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0IEV4dGVybmFsIENBIFJvb3Qw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC39xoz5vIABC054E5b7R+8bA/Ntfojts7e mxEzl6QpTH2Tn71KvJPtAxrjj8/lbVBa1pcplFqAsEl62y6V/bjKvzc4LR4+kUGtcFbH8E8/6DKe dMrIkFTpxl8PeJ2aQDwOrGGqXhSPnoehalDc15pOrwWzpnGUnHGzUGAKxxOdOAeGAqjpqGkmGJCr TLBPI6s6T4TY386f4Wlvu9dC12tE5Met7m1BX3JacQg3s3llpFmglDf3AC8NwpJy2tA4ctsUqEXE XSp9t7TWxO6szRNEt8kr3UMAJfphuWlqWCMRt6czj1Z1WfXNKddGtworZbbTQm8Vsrh7++/pXVPV NFonAgMBAAGjgdwwgdkwHQYDVR0OBBYEFK29mHo0tCb3+sQmVO8DveAky1QaMAsGA1UdDwQEAwIB BjAPBgNVHRMBAf8EBTADAQH/MIGZBgNVHSMEgZEwgY6AFK29mHo0tCb3+sQmVO8DveAky1QaoXOk cTBvMQswCQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0 IEV4dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290 ggEBMA0GCSqGSIb3DQEBBQUAA4IBAQCwm+CFJcLWI+IPlgaSnUGYnNmEeYHZHlsUByM2ZY+w2He7 rEFsR2CDUbD5Mj3n/PYmE8eAFqW/WvyHz3h5iSGa4kwHCoY1vPLeUcTSlrfcfk7ucP0cOesMAlEU LY69FuDB30Z15ySt7PRCtIWTcBBnup0GNUoY0yt6zFFCoXpj0ea7ocUrwja+Ew3mvWN+eXunCQ1A q2rdj4rD9vaMGkIFUdRF9Z+nYiFoFSBDPJnnfL0k2KmRF3OIP1YbMTgYtHEPms3IDp6OLhvhjJiD yx8x8URMxgRzSXZgD8f4vReAay7pzEwOWpp5DyAKLtWeYyYeVZKU2IIXWnvQvMePToYEMIIErzCC A5egAwIBAgIRAOAjyxUSg1OJrWFuelRnayEwDQYJKoZIhvcNAQELBQAwbzELMAkGA1UEBhMCU0Ux FDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBUVFAgTmV0 d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0xNDEyMjIwMDAwMDBa Fw0yMDA1MzAxMDQ4MzhaMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVz dGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UE AxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwg Q0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCJsQ3aelMZTnBSHbxWpgYmt7hJ4Jbn Uavx8FoTSRWjtIwbYLx6UUKneYykIt8XYU6R1XYjChTTSgJ/th0JgG6lBD3ZursW/qGHqS5DUkMW fK8yUMimT1rpCNjPkyWce4joMGTmpPhWgP0qJBQzF5msROVpi6NGBkvCM9TpQJ8GsLGsk0C5tQiT OpwqU6MQ2z0gYTxVA47ZTnYlAiEp+qN8cXZP7uFfgen7VIDbw3s1UreE3iI9LDAtMX9ZvVI3sDNp LUPr+tal8Zd3Z1GM2e4n67ylBzh2jKSpOP/fjPUDrEm+yvdzmToPMquclToTPQ5GOld0YVC+xkA/ y+Tin6IhAgMBAAGjggEXMIIBEzAfBgNVHSMEGDAWgBStvZh6NLQm9/rEJlTvA73gJMtUGjAdBgNV HQ4EFgQUkmFrguGioKpP7GfxwqP3tIAAwewwDgYDVR0PAQH/BAQDAgGGMBIGA1UdEwEB/wQIMAYB Af8CAQAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMBEGA1UdIAQKMAgwBgYEVR0gADBE BgNVHR8EPTA7MDmgN6A1hjNodHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vQWRkVHJ1c3RFeHRlcm5h bENBUm9vdC5jcmwwNQYIKwYBBQUHAQEEKTAnMCUGCCsGAQUFBzABhhlodHRwOi8vb2NzcC51c2Vy dHJ1c3QuY29tMA0GCSqGSIb3DQEBCwUAA4IBAQAbKm6sVcE6q4jF2O3NVfOqa2ErwAkQI5kPxWZq b7H1tLV3Xg8CYQDffQX+ErOkgIAA/PsdW2pyAgpBvAW6wVjVJsLq1U2E+/6CmM9YG+MiY5xS+LsF Nqt9WKXeqztj5drVc+/s4Pt74qP/8EIjnMq2jU0+5EsYA7KoLdTYu0JLkGmFENumNzToe+ABEKWc yjrHn0+ING6KZdAairup3MrKNtH0/MJkKTWv1rGncRHSA0Oxjz6a7J4yU/R2ksqGNAe5LMrmHErY mQ3BhuKQkvtaQmojIRDpZcf11bt+6oyFIAJi6tE6ByxZxZkz8jiJ5bbpFnofeRT2ShAaJvp8ivub MIIFPDCCBCSgAwIBAgIRAImdrrrSrE1TMdXIyvE0qYEwDQYJKoZIhvcNAQELBQAwgZsxCzAJBgNV BAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAY BgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQg QXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xNTAyMDMwMDAwMDBaFw0xNjAy MDMyMzU5NTlaMCMxITAfBgkqhkiG9w0BCQEWEnB0aHViZXJ0QGNpc2NvLmNvbTCCASIwDQYJKoZI hvcNAQEBBQADggEPADCCAQoCggEBALTqoFHH36vHzOLhXp5Wv28HBpYWouQolX/OzHVrZbIEblHp NAxFdrnNSWULDP5gT8hp/t4P0XO3YEnaQxpPUu0wWFlLrDC690s0y3T0hATowmfycNcLX+hddBDL 8ChyZdJAVhxl0vnxORmcciJmXmWOJ+4lzEqaDbm5lZUHgi3kc0t9/IFOOJ6yq1kjttHu1MFPZZUc lUnlpXmD+2/GzxeCHlQgLvw232No6lrAS34PQxbu7rnfw25Spd3CFP7RymWZnNL26rIvt3J4rpv8 xy0EedfU3AUo5scNpr7Mb1npOgVU7N+K07atmjh71wpvfnpvwIxPA+OOHcXwOS5JsosCAwEAAaOC AfAwggHsMB8GA1UdIwQYMBaAFJJha4LhoqCqT+xn8cKj97SAAMHsMB0GA1UdDgQWBBS2xFsxMSdl ViqpYN1OZcdW6Bg4OTAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggr BgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYB BAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMF0G A1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET1NIQTI1NkNsaWVu dEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgZAGCCsGAQUFBwEBBIGDMIGAMFgG CCsGAQUFBzAChkxodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9TSEEyNTZDbGllbnRBdXRo ZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5j b21vZG9jYS5jb20wHQYDVR0RBBYwFIEScHRodWJlcnRAY2lzY28uY29tMA0GCSqGSIb3DQEBCwUA A4IBAQABMkoJZJ5HHnG3Sl0jOpl8Emhb5fjpyW2eK26Zy8e62uqUL7ExSBChD97N1lCYUFY4TqIR zCmaObFC+fDgG3IDQ7ZOJDVu6ZK8TAGiBF6sSYcg5rSfIKPxJUQvTciSrTE+XHEVONmU6xQrMIYY 4/T4iho50oQmNpTSNmGc19ZZ9mQtbRGsjdwILm5NvIyI3X088GidfVJqifQ9dRmSikzELdvlmdBs TFdAM1zx3CscylrUPQyy3lrLuvWf9arpPHV7sex+cwkLKOGHl26mXMoOPwvEYcpJJ3phmR/aqxbC mZwz4LugVrqvC0sFERLSjfarSBQxKL7XSxxS6JYEL3LpMYIEdDCCBHACAQEwgbEwgZsxCzAJBgNV BAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAY BgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQg QXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAImdrrrSrE1TMdXIyvE0qYEwCQYF Kw4DAhoFAKCCApcwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTUw MzI1MTU0ODI3WjAjBgkqhkiG9w0BCQQxFgQUiUXQXsA4LH7w5yQ6pYsMmQUkf60wgasGCSqGSIb3 DQEJDzGBnTCBmjALBglghkgBZQMEASowCwYJYIZIAWUDBAEWMAoGCCqGSIb3DQMHMAsGCWCGSAFl AwQBAjAOBggqhkiG9w0DAgICAIAwBwYFKw4DAgcwDQYIKoZIhvcNAwICAUAwDQYIKoZIhvcNAwIC ASgwBwYFKw4DAhowCwYJYIZIAWUDBAIDMAsGCWCGSAFlAwQCAjALBglghkgBZQMEAgEwgcIGCSsG AQQBgjcQBDGBtDCBsTCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3Rl cjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMT OENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENB AhEAiZ2uutKsTVMx1cjK8TSpgTCBxAYLKoZIhvcNAQkQAgsxgbSggbEwgZsxCzAJBgNVBAYTAkdC MRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoT EUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAImdrrrSrE1TMdXIyvE0qYEwDQYJKoZIhvcN AQEBBQAEggEAYhp6CVVCukqFT+IOS7w0W5pkHn0ApZgTi9/G3lLYdeVQmjJpJQWE+adBHqHJWW47 zfm3zSCfq0YwtnfSrkGhEt6nNVZDqdwrkXLtVhsZbtGOTPs2AgMvIWFtEIPWIJGebYkTIRgsu5JG MNxMjuGidBZY2IxMaH4+AS3Z0eOtj3pLWpkSv2voGbjMJpQwSE/+xjPU+EmjUDKiv4Fm3IOyXM3n 8t1WpTHCTl0H7lxMV0u3P89eg9g0L81k+QEHljfBRJ8xakLbLj4eAgcyY97SJWYAOYgK2q2sAIkI QYkbp2t/ZibiRFBRLEsNq7wRTohtldUx6CC6+iOK0uZsgIcsgwAAAAAAAA== ------=_NextPart_000_00CA_01D066E0.D7A61E40-- From nobody Wed Mar 25 09:12:58 2015 Return-Path: X-Original-To: detnet@ietfa.amsl.com Delivered-To: detnet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F058E1A802E for ; Wed, 25 Mar 2015 09:12:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 UDlD8RSYlZpz for ; Wed, 25 Mar 2015 09:12:45 -0700 (PDT) Received: from mail-gw2-out.broadcom.com (mail-gw2-out.broadcom.com [216.31.210.63]) by ietfa.amsl.com (Postfix) with ESMTP id 3EEBC1A88ED for ; Wed, 25 Mar 2015 09:12:10 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.11,465,1422950400"; d="scan'208";a="60377440" Received: from irvexchcas06.broadcom.com (HELO IRVEXCHCAS06.corp.ad.broadcom.com) ([10.9.208.53]) by mail-gw2-out.broadcom.com with ESMTP; 25 Mar 2015 09:15:06 -0700 Received: from SJEXCHCAS04.corp.ad.broadcom.com (10.16.203.10) by IRVEXCHCAS06.corp.ad.broadcom.com (10.9.208.53) with Microsoft SMTP Server (TLS) id 14.3.174.1; Wed, 25 Mar 2015 09:12:09 -0700 Received: from SJEXCHMB09.corp.ad.broadcom.com ([fe80::3da7:665e:cc78:181f]) by SJEXCHCAS04.corp.ad.broadcom.com ([::1]) with mapi id 14.03.0174.001; Wed, 25 Mar 2015 09:12:09 -0700 From: Pat Thaler To: "detnet@ietf.org" Thread-Topic: SPUD BOF Thread-Index: AdBnFiFWsI1hPfHIRhS03ekqaLMntA== Date: Wed, 25 Mar 2015 16:12:08 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.16.203.100] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [Detnet] SPUD BOF X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussions on Deterministic Networking, characterized by 1\) resource reservation; 2\) 0 congestion loss and guaranteed latency; 3\) over L2-only and mixed L2 and L3 networks; and 5\) 1+1 replication/deletion." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2015 16:12:49 -0000 Those working on DETNET might want to take a look at the SPUD BOF presentat= ions. It is proposing an encapsulation to mark flows and something about th= e treatment the packet wants from the network. From nobody Wed Mar 25 13:09:36 2015 Return-Path: X-Original-To: detnet@ietfa.amsl.com Delivered-To: detnet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12B861AD0CC for ; Wed, 25 Mar 2015 13:09:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham 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 VTVgbieGsNBu for ; Wed, 25 Mar 2015 13:09:34 -0700 (PDT) Received: from p3plsmtpa09-08.prod.phx3.secureserver.net (p3plsmtpa09-08.prod.phx3.secureserver.net [173.201.193.237]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8098C1A8AE8 for ; Wed, 25 Mar 2015 13:09:34 -0700 (PDT) Received: from dhcp-b347.meeting.ietf.org ([31.133.179.71]) by p3plsmtpa09-08.prod.phx3.secureserver.net with id 7w9Z1q0081YpC2f01w9ZN9; Wed, 25 Mar 2015 13:09:34 -0700 Content-Type: multipart/alternative; boundary="Apple-Mail=_9C204092-2CD5-4BDD-BA18-6B2AB9600A8A" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Pat Kinney In-Reply-To: Date: Wed, 25 Mar 2015 15:09:33 -0500 Message-Id: <5F413472-4EE7-41EB-8F6E-7FD08386613B@kinneyconsultingllc.com> References: To: "Prof. Diego Dujovne" X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: "detnet@ietf.org" Subject: Re: [Detnet] Looking for partners for Gap Analysis draft X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussions on Deterministic Networking, characterized by 1\) resource reservation; 2\) 0 congestion loss and guaranteed latency; 3\) over L2-only and mixed L2 and L3 networks; and 5\) 1+1 replication/deletion." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2015 20:09:36 -0000 --Apple-Mail=_9C204092-2CD5-4BDD-BA18-6B2AB9600A8A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I would like to assist in this effort, especially towards 4.1 Industrial = Controls. I plan to work with my partners in the ISA organization to = define the basic requirements for these applications. Regards, Pat Pat Kinney Kinney Consulting LLC IEEE 802.15 WG vice chair, TG chair ISA100.11a WG chair O: +1.847.960.3715 pat.kinney@kinneyconsultingllc.com = On 25, Mar2015, at 10:49, Prof. Diego Dujovne = wrote: Dear all, I have published the first (-00) version of the Gap Analysis draft: https://tools.ietf.org/html/draft-dujovne-detnet-gap-analysis-00 = I'm looking for co-authors to collaborate to build this draft. Let me know through the list if you are interested. Thank you. Diego Dujovne --=20 DIEGO DUJOVNE Acad=C3=A9mico Escuela de Ingenier=C3=ADa en Inform=C3=A1tica y = Telecomunicaciones Facultad de Ingenier=C3=ADa UDP www.ingenieria.udp.cl (56 2) 676 8125 _______________________________________________ detnet mailing list detnet@ietf.org https://www.ietf.org/mailman/listinfo/detnet --Apple-Mail=_9C204092-2CD5-4BDD-BA18-6B2AB9600A8A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I would like to assist in this effort, especially towards 4.1 = Industrial Controls.  I plan to work with my partners in the ISA = organization to define the basic requirements for these = applications.

Regards,= Pat

Pat= Kinney
Kinney = Consulting LLC
IEEE 802.15 WG vice chair, = TG chair
ISA100.11a WG chair
O: = +1.847.960.3715
pat.kinney@kinneyconsultingllc.com
=


On 25, Mar2015, at 10:49, Prof. = Diego Dujovne <diego.dujovne@mail.udp.cl> wrote:

Dear all,
         &nb= sp;  I have published the first (-00) version of the
Gap Analysis draft:

https://tools.ietf.org/html/draft-dujovne-detnet-gap-analysis-0= 0

 I'm looking for co-authors to = collaborate
to build this draft. Let me know through = the list
if you are interested.
Thank you.

         &nb= sp;            = ;      Diego Dujovne

--
DIEGO DUJOVNE
Acad=C3=A9mico Escuela de Ingenier=C3=ADa en Inform=C3=A1tica = y Telecomunicaciones
Facultad de Ingenier=C3=ADa UDP
www.ingenieria.udp.cl
(56 2) 676 8125
_______________________________________________
detnet = mailing list
detnet@ietf.org
https://www.ietf.org/mailman/listinfo/detnet

= --Apple-Mail=_9C204092-2CD5-4BDD-BA18-6B2AB9600A8A-- From nobody Wed Mar 25 14:17:23 2015 Return-Path: X-Original-To: detnet@ietfa.amsl.com Delivered-To: detnet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C46F81A044F for ; Wed, 25 Mar 2015 14:17:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.509 X-Spam-Level: X-Spam-Status: No, score=-14.509 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 9LuUNR4hA_PL for ; Wed, 25 Mar 2015 14:17:19 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 856501A0058 for ; Wed, 25 Mar 2015 14:17:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=18446; q=dns/txt; s=iport; t=1427318239; x=1428527839; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=/ptOgVw0woGFdxOpfogHjHyBvvaJkZqf/TqVyLXmcDM=; b=Jv+JnuRBDzNhbAEjOQoKSMnBwAfwZqvQfPXF/eo6EcypZCYIr19hIMG5 a7Gk0iwCZ42vLCarnFUaRgruUqDO4s47KTgns7R5rkDq3GzIlKh+Gh4Kz Li4K+uC9TZliVhIlsBmmsUBZdoF5+jeAOVHA4mU23aGg0hbMQx8aKgLz8 8=; X-Files: smime.p7s : 4831 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BQBgDTJBNV/5FdJa1ZA4JDQ1JaBIMOv0iCMQEJhSxJAoFbTAEBAQEBAX2EFAEBAQQBAQEgChwlAwgQAgEIEQEDAQELHQMCAgIlCxQDBggCBAENBQgGiCENr26aIwEBAQEBAQEBAQEBAQEBAQEBAQEBAReLIYQlAQEeFgsMBAYBCQiCVy+BFgWOQoIOgWmBMlRRhTCBGpMRIoNub4ELOX8BAQE X-IronPort-AV: E=Sophos;i="5.11,467,1422921600"; d="p7s'?scan'208,217";a="406732444" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by rcdn-iport-4.cisco.com with ESMTP; 25 Mar 2015 21:17:18 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id t2PLHISX010746 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 25 Mar 2015 21:17:18 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.104]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.03.0195.001; Wed, 25 Mar 2015 16:17:18 -0500 From: "Pascal Thubert (pthubert)" To: Pat Kinney , "Prof. Diego Dujovne" Thread-Topic: [Detnet] Looking for partners for Gap Analysis draft Thread-Index: AQHQZzeoqeDYRqWk90C8U3IM9tzmcJ0tr79A Date: Wed, 25 Mar 2015 21:17:17 +0000 Deferred-Delivery: Wed, 25 Mar 2015 21:17:00 +0000 Message-ID: References: <5F413472-4EE7-41EB-8F6E-7FD08386613B@kinneyconsultingllc.com> In-Reply-To: <5F413472-4EE7-41EB-8F6E-7FD08386613B@kinneyconsultingllc.com> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.89.12.61] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0007_01D0670E.A3FE75F0" MIME-Version: 1.0 Archived-At: Cc: "detnet@ietf.org" Subject: Re: [Detnet] Looking for partners for Gap Analysis draft X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussions on Deterministic Networking, characterized by 1\) resource reservation; 2\) 0 congestion loss and guaranteed latency; 3\) over L2-only and mixed L2 and L3 networks; and 5\) 1+1 replication/deletion." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2015 21:17:21 -0000 ------=_NextPart_000_0007_01D0670E.A3FE75F0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0008_01D0670E.A3FE75F0" ------=_NextPart_001_0008_01D0670E.A3FE75F0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hello Pat: =20 Thanks a bunch for the offer! =20 If you can convince ISA to participate to a requirements draft that = would look like = https://tools.ietf.org/html/draft-wetterwald-detnet-utilities-reqs-00 = that would be fantastic. >From there we can justify the application of the detnet architecture in = industrial, which in turns would enable a gap analysis from existing = things at the IETF. We figure that detnet requires new work at least from TEAS, CCAMP and = PCE, to implement our resource constraints (time, channels, = buffers=E2=80=A6) as well as the new path capabilities (replication and = elimination). =20 Does that make sense ? =20 Pascal =20 From: detnet [mailto:detnet-bounces@ietf.org] On Behalf Of Pat Kinney Sent: mercredi 25 mars 2015 14:10 To: Prof. Diego Dujovne Cc: detnet@ietf.org Subject: Re: [Detnet] Looking for partners for Gap Analysis draft =20 I would like to assist in this effort, especially towards 4.1 Industrial = Controls. I plan to work with my partners in the ISA organization to = define the basic requirements for these applications. =20 Regards, Pat =20 Pat Kinney Kinney Consulting LLC IEEE 802.15 WG vice chair, TG chair ISA100.11a WG chair O: +1.847.960.3715 = pat.kinney@kinneyconsultingllc.com =20 =20 On 25, Mar2015, at 10:49, Prof. Diego Dujovne = wrote: =20 Dear all, I have published the first (-00) version of the Gap Analysis draft: https://tools.ietf.org/html/draft-dujovne-detnet-gap-analysis-00 I'm looking for co-authors to collaborate to build this draft. Let me know through the list if you are interested. Thank you. Diego Dujovne --=20 DIEGO DUJOVNE Acad=C3=A9mico Escuela de Ingenier=C3=ADa en Inform=C3=A1tica y = Telecomunicaciones Facultad de Ingenier=C3=ADa UDP www.ingenieria.udp.cl =20 (56 2) 676 8125 _______________________________________________ detnet mailing list detnet@ietf.org https://www.ietf.org/mailman/listinfo/detnet =20 ------=_NextPart_001_0008_01D0670E.A3FE75F0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Hello Pat:

 

Thanks a bunch for the offer!

 

If you can convince ISA to participate to a requirements draft that = would look like https://tools.ietf.org/html/draft-wetterwald-detnet-utilities-reqs-= 00=C2=A0 that would be fantastic.

From there we can justify the application of the detnet architecture = in industrial, which in turns would enable a gap analysis from existing = things at the IETF.

We figure that detnet requires new work at least from =C2=A0TEAS, = CCAMP and PCE, to implement our resource constraints (time, channels, = buffers=E2=80=A6) as well as the new path capabilities (replication and = elimination).

 

Does that make sense ?

 

Pascal

 

From:= = detnet [mailto:detnet-bounces@ietf.org] On Behalf Of Pat = Kinney
Sent: mercredi 25 mars 2015 14:10
To: Prof. = Diego Dujovne
Cc: detnet@ietf.org
Subject: Re: = [Detnet] Looking for partners for Gap Analysis = draft

 

I would like = to assist in this effort, especially towards 4.1 Industrial Controls. =  I plan to work with my partners in the ISA organization to define = the basic requirements for these applications.

 

Regards, Pat

 

Pat Kinney

Kinney Consulting LLC

IEEE 802.15 WG vice chair, TG chair

ISA100.11a WG chair

O: +1.847.960.3715

 

 

Dear all,

         &= nbsp;  I have published the first (-00) version of = the

Gap Analysis = draft:

https://tools.ietf.org/html/draft-dujovne-detnet-gap-analysis-00
=
 I'm looking for co-authors to = collaborate

to build this = draft. Let me know through the list

if you are interested.

Thank = you.

         &= nbsp;           &n= bsp;      Diego Dujovne

<= div>


--

DIEGO DUJOVNE
Acad=C3=A9mico Escuela de = Ingenier=C3=ADa en Inform=C3=A1tica y Telecomunicaciones
Facultad de = Ingenier=C3=ADa UDP
www.ingenieria.udp.cl
(56 2) 676 = 8125

=

_______________________________________________
detn= et mailing list
detnet@ietf.org
https://www.ietf.or= g/mailman/listinfo/detnet

 

------=_NextPart_001_0008_01D0670E.A3FE75F0-- ------=_NextPart_000_0007_01D0670E.A3FE75F0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOLTCCBDYw ggMeoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwbzELMAkGA1UEBhMCU0UxFDASBgNVBAoTC0FkZFRy dXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBUVFAgTmV0d29yazEiMCAGA1UEAxMZ QWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0wMDA1MzAxMDQ4MzhaFw0yMDA1MzAxMDQ4Mzha MG8xCzAJBgNVBAYTAlNFMRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQGA1UECxMdQWRkVHJ1c3Qg RXh0ZXJuYWwgVFRQIE5ldHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0IEV4dGVybmFsIENBIFJvb3Qw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC39xoz5vIABC054E5b7R+8bA/Ntfojts7e mxEzl6QpTH2Tn71KvJPtAxrjj8/lbVBa1pcplFqAsEl62y6V/bjKvzc4LR4+kUGtcFbH8E8/6DKe dMrIkFTpxl8PeJ2aQDwOrGGqXhSPnoehalDc15pOrwWzpnGUnHGzUGAKxxOdOAeGAqjpqGkmGJCr TLBPI6s6T4TY386f4Wlvu9dC12tE5Met7m1BX3JacQg3s3llpFmglDf3AC8NwpJy2tA4ctsUqEXE XSp9t7TWxO6szRNEt8kr3UMAJfphuWlqWCMRt6czj1Z1WfXNKddGtworZbbTQm8Vsrh7++/pXVPV NFonAgMBAAGjgdwwgdkwHQYDVR0OBBYEFK29mHo0tCb3+sQmVO8DveAky1QaMAsGA1UdDwQEAwIB BjAPBgNVHRMBAf8EBTADAQH/MIGZBgNVHSMEgZEwgY6AFK29mHo0tCb3+sQmVO8DveAky1QaoXOk cTBvMQswCQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0 IEV4dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290 ggEBMA0GCSqGSIb3DQEBBQUAA4IBAQCwm+CFJcLWI+IPlgaSnUGYnNmEeYHZHlsUByM2ZY+w2He7 rEFsR2CDUbD5Mj3n/PYmE8eAFqW/WvyHz3h5iSGa4kwHCoY1vPLeUcTSlrfcfk7ucP0cOesMAlEU LY69FuDB30Z15ySt7PRCtIWTcBBnup0GNUoY0yt6zFFCoXpj0ea7ocUrwja+Ew3mvWN+eXunCQ1A q2rdj4rD9vaMGkIFUdRF9Z+nYiFoFSBDPJnnfL0k2KmRF3OIP1YbMTgYtHEPms3IDp6OLhvhjJiD yx8x8URMxgRzSXZgD8f4vReAay7pzEwOWpp5DyAKLtWeYyYeVZKU2IIXWnvQvMePToYEMIIErzCC A5egAwIBAgIRAOAjyxUSg1OJrWFuelRnayEwDQYJKoZIhvcNAQELBQAwbzELMAkGA1UEBhMCU0Ux FDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBUVFAgTmV0 d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0xNDEyMjIwMDAwMDBa Fw0yMDA1MzAxMDQ4MzhaMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVz dGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UE AxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwg Q0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCJsQ3aelMZTnBSHbxWpgYmt7hJ4Jbn Uavx8FoTSRWjtIwbYLx6UUKneYykIt8XYU6R1XYjChTTSgJ/th0JgG6lBD3ZursW/qGHqS5DUkMW fK8yUMimT1rpCNjPkyWce4joMGTmpPhWgP0qJBQzF5msROVpi6NGBkvCM9TpQJ8GsLGsk0C5tQiT OpwqU6MQ2z0gYTxVA47ZTnYlAiEp+qN8cXZP7uFfgen7VIDbw3s1UreE3iI9LDAtMX9ZvVI3sDNp LUPr+tal8Zd3Z1GM2e4n67ylBzh2jKSpOP/fjPUDrEm+yvdzmToPMquclToTPQ5GOld0YVC+xkA/ y+Tin6IhAgMBAAGjggEXMIIBEzAfBgNVHSMEGDAWgBStvZh6NLQm9/rEJlTvA73gJMtUGjAdBgNV HQ4EFgQUkmFrguGioKpP7GfxwqP3tIAAwewwDgYDVR0PAQH/BAQDAgGGMBIGA1UdEwEB/wQIMAYB Af8CAQAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMBEGA1UdIAQKMAgwBgYEVR0gADBE BgNVHR8EPTA7MDmgN6A1hjNodHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vQWRkVHJ1c3RFeHRlcm5h bENBUm9vdC5jcmwwNQYIKwYBBQUHAQEEKTAnMCUGCCsGAQUFBzABhhlodHRwOi8vb2NzcC51c2Vy dHJ1c3QuY29tMA0GCSqGSIb3DQEBCwUAA4IBAQAbKm6sVcE6q4jF2O3NVfOqa2ErwAkQI5kPxWZq b7H1tLV3Xg8CYQDffQX+ErOkgIAA/PsdW2pyAgpBvAW6wVjVJsLq1U2E+/6CmM9YG+MiY5xS+LsF Nqt9WKXeqztj5drVc+/s4Pt74qP/8EIjnMq2jU0+5EsYA7KoLdTYu0JLkGmFENumNzToe+ABEKWc yjrHn0+ING6KZdAairup3MrKNtH0/MJkKTWv1rGncRHSA0Oxjz6a7J4yU/R2ksqGNAe5LMrmHErY mQ3BhuKQkvtaQmojIRDpZcf11bt+6oyFIAJi6tE6ByxZxZkz8jiJ5bbpFnofeRT2ShAaJvp8ivub MIIFPDCCBCSgAwIBAgIRAImdrrrSrE1TMdXIyvE0qYEwDQYJKoZIhvcNAQELBQAwgZsxCzAJBgNV BAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAY BgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQg QXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xNTAyMDMwMDAwMDBaFw0xNjAy MDMyMzU5NTlaMCMxITAfBgkqhkiG9w0BCQEWEnB0aHViZXJ0QGNpc2NvLmNvbTCCASIwDQYJKoZI hvcNAQEBBQADggEPADCCAQoCggEBALTqoFHH36vHzOLhXp5Wv28HBpYWouQolX/OzHVrZbIEblHp NAxFdrnNSWULDP5gT8hp/t4P0XO3YEnaQxpPUu0wWFlLrDC690s0y3T0hATowmfycNcLX+hddBDL 8ChyZdJAVhxl0vnxORmcciJmXmWOJ+4lzEqaDbm5lZUHgi3kc0t9/IFOOJ6yq1kjttHu1MFPZZUc lUnlpXmD+2/GzxeCHlQgLvw232No6lrAS34PQxbu7rnfw25Spd3CFP7RymWZnNL26rIvt3J4rpv8 xy0EedfU3AUo5scNpr7Mb1npOgVU7N+K07atmjh71wpvfnpvwIxPA+OOHcXwOS5JsosCAwEAAaOC AfAwggHsMB8GA1UdIwQYMBaAFJJha4LhoqCqT+xn8cKj97SAAMHsMB0GA1UdDgQWBBS2xFsxMSdl ViqpYN1OZcdW6Bg4OTAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggr BgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYB BAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMF0G A1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET1NIQTI1NkNsaWVu dEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgZAGCCsGAQUFBwEBBIGDMIGAMFgG CCsGAQUFBzAChkxodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9TSEEyNTZDbGllbnRBdXRo ZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5j b21vZG9jYS5jb20wHQYDVR0RBBYwFIEScHRodWJlcnRAY2lzY28uY29tMA0GCSqGSIb3DQEBCwUA A4IBAQABMkoJZJ5HHnG3Sl0jOpl8Emhb5fjpyW2eK26Zy8e62uqUL7ExSBChD97N1lCYUFY4TqIR zCmaObFC+fDgG3IDQ7ZOJDVu6ZK8TAGiBF6sSYcg5rSfIKPxJUQvTciSrTE+XHEVONmU6xQrMIYY 4/T4iho50oQmNpTSNmGc19ZZ9mQtbRGsjdwILm5NvIyI3X088GidfVJqifQ9dRmSikzELdvlmdBs TFdAM1zx3CscylrUPQyy3lrLuvWf9arpPHV7sex+cwkLKOGHl26mXMoOPwvEYcpJJ3phmR/aqxbC mZwz4LugVrqvC0sFERLSjfarSBQxKL7XSxxS6JYEL3LpMYIEdDCCBHACAQEwgbEwgZsxCzAJBgNV BAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAY BgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQg QXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAImdrrrSrE1TMdXIyvE0qYEwCQYF Kw4DAhoFAKCCApcwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTUw MzI1MjExNjE3WjAjBgkqhkiG9w0BCQQxFgQUPInJcEHbLZhDz09Ny4r1aZzAOB0wgasGCSqGSIb3 DQEJDzGBnTCBmjALBglghkgBZQMEASowCwYJYIZIAWUDBAEWMAoGCCqGSIb3DQMHMAsGCWCGSAFl AwQBAjAOBggqhkiG9w0DAgICAIAwBwYFKw4DAgcwDQYIKoZIhvcNAwICAUAwDQYIKoZIhvcNAwIC ASgwBwYFKw4DAhowCwYJYIZIAWUDBAIDMAsGCWCGSAFlAwQCAjALBglghkgBZQMEAgEwgcIGCSsG AQQBgjcQBDGBtDCBsTCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3Rl cjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMT OENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENB AhEAiZ2uutKsTVMx1cjK8TSpgTCBxAYLKoZIhvcNAQkQAgsxgbSggbEwgZsxCzAJBgNVBAYTAkdC MRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoT EUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAImdrrrSrE1TMdXIyvE0qYEwDQYJKoZIhvcN AQEBBQAEggEAZmaud+c4L+pyLU9tjfthw7VL0h5iF32nAfadX48zC549F6syyOEoX47OazVQ480B JsS27T0Jf1yQhVvRQpFU+T9HgOPPiCTZHDgvl2nb7JQIagOx/aJ3wQ3CLFz2d/z9Vp8ULkSqFBhH M1Apb+xI1ukIu35oi3K073wxc7rOIW9DMCHQLxIvFfCOBeKSdt95tUkiGSmOJ6atwkoNS3vT7Dp+ r9NobSuVqSMVNAjhdJ7GUEm+6TCWDxpHdzSuvqHuzmryEjCMGM09adJPrOrfzCe3YOyLwhFfyb4L zyC9ivUJJsDTn8m+g8Ac+CfG9tasQbW7gxKEkOez9Dfu2gY4zwAAAAAAAA== ------=_NextPart_000_0007_01D0670E.A3FE75F0-- From nobody Wed Mar 25 15:49:03 2015 Return-Path: X-Original-To: detnet@ietfa.amsl.com Delivered-To: detnet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6DBD1A9114 for ; Wed, 25 Mar 2015 15:49:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 vMRh_hL4uQxu for ; Wed, 25 Mar 2015 15:48:54 -0700 (PDT) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 860611A0063 for ; Wed, 25 Mar 2015 15:48:54 -0700 (PDT) Received: by wibgn9 with SMTP id gn9so60572285wib.1 for ; Wed, 25 Mar 2015 15:48:53 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=G6VppTYcQylMD/0WE6u/8tV+UzOlZoboqVM0n81fvF4=; b=MBQ6uA4+CB2nH9/43B8HGOy4JzvDuajNhHRmONptVWrBQZFBvkTUNItWThO01LHr/r jYrw2vrfUs1rKbXiBIhsNs226hAeoOsUlvZsIwf2S+Q3UXp1aXmvwTwfCkZ22X0ovHW8 lXGhxyXlq5hkpw/US+oqFlGuVCfkRB3Q04fLiBEU9XjgPkCQ/1Kn2oAtzsPCH4XXjmWN Umx5+WMHLxjHYx31nZAMYShSQjb8et7tRRKvxIcbxoSl4Q+5ShdkruKwdJIz+eBVfJc3 8ivqgSI5CMV+rJtey4t5rZuNXuM0Q9SN+vJEIfezrUVvuVFh3O9OTTwfcS35vVgHKzvY 377w== X-Gm-Message-State: ALoCoQnARoZsX0ImPZsDY7PllxvpXCUakpIqlgYVr4W7QQucxPbjNWOQhr67HvMp+Wl0538MBWXy MIME-Version: 1.0 X-Received: by 10.194.91.129 with SMTP id ce1mr22652400wjb.53.1427323732971; Wed, 25 Mar 2015 15:48:52 -0700 (PDT) Received: by 10.28.39.135 with HTTP; Wed, 25 Mar 2015 15:48:52 -0700 (PDT) In-Reply-To: <5F413472-4EE7-41EB-8F6E-7FD08386613B@kinneyconsultingllc.com> References: <5F413472-4EE7-41EB-8F6E-7FD08386613B@kinneyconsultingllc.com> Date: Wed, 25 Mar 2015 17:48:52 -0500 Message-ID: From: "Prof. Diego Dujovne" To: Pat Kinney Content-Type: multipart/alternative; boundary=047d7bfcec48156c5a051224b40c Archived-At: Cc: "detnet@ietf.org" Subject: Re: [Detnet] Looking for partners for Gap Analysis draft X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussions on Deterministic Networking, characterized by 1\) resource reservation; 2\) 0 congestion loss and guaranteed latency; 3\) over L2-only and mixed L2 and L3 networks; and 5\) 1+1 replication/deletion." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2015 22:49:02 -0000 --047d7bfcec48156c5a051224b40c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Pat, Thank you for joining! Regards, Diego 2015-03-25 15:09 GMT-05:00 Pat Kinney : > I would like to assist in this effort, especially towards 4.1 Industrial > Controls. I plan to work with my partners in the ISA organization to > define the basic requirements for these applications. > > Regards, Pat > > Pat Kinney > *Kinney Consulting LLC* > IEEE 802.15 WG vice chair, TG chair > ISA100.11a WG chair > O: +1.847.960.3715 > pat.kinney@kinneyconsultingllc.com > > > On 25, Mar2015, at 10:49, Prof. Diego Dujovne > wrote: > > Dear all, > I have published the first (-00) version of the > Gap Analysis draft: > > https://tools.ietf.org/html/draft-dujovne-detnet-gap-analysis-00 > > I'm looking for co-authors to collaborate > to build this draft. Let me know through the list > if you are interested. > Thank you. > > Diego Dujovne > > -- > DIEGO DUJOVNE > Acad=C3=A9mico Escuela de Ingenier=C3=ADa en Inform=C3=A1tica y Telecomun= icaciones > Facultad de Ingenier=C3=ADa UDP > www.ingenieria.udp.cl > (56 2) 676 8125 > _______________________________________________ > detnet mailing list > detnet@ietf.org > https://www.ietf.org/mailman/listinfo/detnet > > --=20 DIEGO DUJOVNE Acad=C3=A9mico Escuela de Ingenier=C3=ADa en Inform=C3=A1tica y Telecomunic= aciones Facultad de Ingenier=C3=ADa UDP www.ingenieria.udp.cl (56 2) 676 8125 --047d7bfcec48156c5a051224b40c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Pat,
=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 Thank you for joining!
Regards,

=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Diego

2015-03-25 15:09 GMT-05:00 = Pat Kinney <pat.kinney@kinneyconsultingllc.com>:
I would like to assist in this effort, especially towards 4.1 Industrial C= ontrols.=C2=A0 I plan to work with my partners in the ISA organization to d= efine the basic requirements for these applications.

Reg= ards, Pat

<= div style=3D"word-wrap:break-word">
Pat Kinney
<= b>Kinney Consulting LLC
IEEE 802.15 WG vice chair, TG = chair
ISA100.11a WG chair
<= div>pat.kinney@kinneyconsultingllc.com

<= /span>

On 25, Mar2015, at 10:49, Prof. Diego = Dujovne <= diego.dujovne@mail.udp.cl> wrote:

Dear all,
=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 I = have published the first (-00) version of the
Gap Analysis draft:<= br>
https://tools.ietf.org/html/draft-dujovne-detnet= -gap-analysis-00

=C2=A0I'm looking for co-authors to collabo= rate
to build this draft. Let me know through the list
if= you are interested.
Thank you.

=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Diego Du= jovne
--
DIEGO DUJOVNE
Acad=C3=A9mico Escuela de Ingenier=C3=ADa en= Inform=C3=A1tica y Telecomunicaciones
Facultad de Ingenier=C3=ADa UDPwww.ingenieri= a.udp.cl
(56 2) 676 8125
_______________________________________________
detnet mailing list
<= a href=3D"mailto:detnet@ietf.org" target=3D"_blank">detnet@ietf.org
= = https://www.ietf.org/mailman/listinfo/detnet

<= /div>



--
DIEGO DUJOVNE
Acad=C3=A9mico Escuela de Ingenier=C3=ADa en = Inform=C3=A1tica y Telecomunicaciones
Facultad de Ingenier=C3=ADa UDPwww.ingenieria.= udp.cl
(56 2) 676 8125
--047d7bfcec48156c5a051224b40c-- From nobody Thu Mar 26 07:26:16 2015 Return-Path: X-Original-To: detnet@ietfa.amsl.com Delivered-To: detnet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F7431A0110 for ; Thu, 26 Mar 2015 07:26:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, USER_IN_WHITELIST=-100] autolearn=ham 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 npjzvtH7OUT0 for ; Thu, 26 Mar 2015 07:26:13 -0700 (PDT) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27A281A0171 for ; Thu, 26 Mar 2015 07:26:11 -0700 (PDT) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id t2QEQ9wk017642; Thu, 26 Mar 2015 14:26:09 GMT Received: from 950129200 (dhcp-b383.meeting.ietf.org [31.133.179.131]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id t2QEQ7TU017601 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Thu, 26 Mar 2015 14:26:08 GMT From: "Adrian Farrel" To: "'Prof. Diego Dujovne'" , "'Pat Kinney'" References: <5F413472-4EE7-41EB-8F6E-7FD08386613B@kinneyconsultingllc.com> In-Reply-To: Date: Thu, 26 Mar 2015 14:26:05 -0000 Message-ID: <00e801d067d0$ccd62870$66827950$@olddog.co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00E9_01D067D0.CCDD5460" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQDnVEv8L4zBaojKC2jS3OZ+9iR4LQJorvcHAhSwmMqe3Qx9UA== Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1018-21426.006 X-TM-AS-Result: No--13.881-10.0-31-10 X-imss-scan-details: No--13.881-10.0-31-10 X-TMASE-MatchedRID: pS5owHKhBO3tQ6cSfuLp/Fu4M/xm4KZefkuZtv/FS5rgT7/U3eRk34/i b8cdJDD5CxCYCgRCsDOgE4umcRqEtI39U4x946BXZlRzaO1xpJ2tc6proxpBq8IPenBGRWaGPXW oMDYf5ezsxB5pe0toN7rsot85x/xkoVTtFwsfvjB+g0NkxA6mbIkxQSd6gj19VnJHzRH8862hvS 5RKWhhclx8Meb5y4g94NiRgObyaww6WGg4O5YW8Ca1MaKuob8PRdLx1X9BVkACrs2hjvwktFAtQ bCc+q6n+gGDlBYPfiiR5X2z1tiC+hzZnWoBcqzQTK8SuLFQ0YO4lgRKJt7cpKIiUozBB8xr3b+X WgntZKfuX/km0O1YYLtmyq+dP1u+NuVzoZ6LieVwUSK4/EeOxbRfRjDbtW6i5DjmdW0+qbGuwVT xTDkELrK2YHb/kidP/PEgL0tqyq50bnu2kHqixLMsPmSZxbpkE7JInT4wddoTjfkO3pb+WD0msI gSyun3H/Z71HJDNaFacyhB9L1arxJ3qw6ad/ljABhihvAhvAJIeNYTP8OmTPk3SjZMcZFkUlBh+ kbitM8/DUc/B6QpkmRGSnUqeCO9OQRl+99vaMkMH4SsGvRsA1qvZZ9/gpIhZ5yuplze9ps57kFj OTI5JYBMc1fifV0YEE7drCx1oTkh3ud9DyO68BIMDPFEv6Uxs+SyIdviDnwL/50zj0KL7BY+750 9sPX7ZLNHiJlyaWEtY3smclWYCYIiDu0n/+6x2MMmxTWvrZv8Xh935PYSDpd9j+WYn72G89EK+x ictMuW00p9LWWxD65R9aoXimHAl+CeDVkHdm+eAiCmPx4NwGmRqNBHmBve1kTfEkyaZdy1VfZrX 9mxWODSik097xYPz86KcGRp8DQHgV6GsJgAU+rMLLEnNzS5z3y6e+3wnwHOiYSHU0+LElvHLaVI DQ0sHSj9/EHyYwomfgXqNGzcSA== Archived-At: Cc: detnet@ietf.org Subject: Re: [Detnet] Looking for partners for Gap Analysis draft X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: "Discussions on Deterministic Networking, characterized by 1\) resource reservation; 2\) 0 congestion loss and guaranteed latency; 3\) over L2-only and mixed L2 and L3 networks; and 5\) 1+1 replication/deletion." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2015 14:26:15 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00E9_01D067D0.CCDD5460 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hello all, =20 I think this can be useful work, but I am confused about the direction = because it seems that the gaps you can find have to assume an = architectural solution and probably a choice of protocol components. =20 So there may be a need to write an early section on a framework to = provide the context for showing the gaps. =20 Adrian =20 From: detnet [mailto:detnet-bounces@ietf.org] On Behalf Of Prof. Diego = Dujovne Sent: 25 March 2015 22:49 To: Pat Kinney Cc: detnet@ietf.org Subject: Re: [Detnet] Looking for partners for Gap Analysis draft =20 Pat, Thank you for joining Regards, Diego =20 2015-03-25 15:09 GMT-05:00 Pat Kinney = : I would like to assist in this effort, especially towards 4.1 Industrial = Controls. I plan to work with my partners in the ISA organization to = define the basic requirements for these applications. =20 Regards, Pat =20 Pat Kinney Kinney Consulting LLC IEEE 802.15 WG vice chair, TG chair ISA100.11a WG chair O: +1.847.960.3715 =20 = pat.kinney@kinneyconsultingllc.com =20 =20 On 25, Mar2015, at 10:49, Prof. Diego Dujovne = wrote: =20 Dear all, I have published the first (-00) version of the Gap Analysis draft: https://tools.ietf.org/html/draft-dujovne-detnet-gap-analysis-00 I'm looking for co-authors to collaborate to build this draft. Let me know through the list if you are interested. Thank you. Diego Dujovne --=20 DIEGO DUJOVNE Acad=C3=A9mico Escuela de Ingenier=C3=ADa en Inform=C3=A1tica y = Telecomunicaciones Facultad de Ingenier=C3=ADa UDP www.ingenieria.udp.cl =20 (56 2) 676 8125 _______________________________________________ detnet mailing list detnet@ietf.org https://www.ietf.org/mailman/listinfo/detnet =20 --=20 DIEGO DUJOVNE Acad=C3=A9mico Escuela de Ingenier=C3=ADa en Inform=C3=A1tica y = Telecomunicaciones Facultad de Ingenier=C3=ADa UDP www.ingenieria.udp.cl (56 2) 676 8125 ------=_NextPart_000_00E9_01D067D0.CCDD5460 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Hello = all,

 

I think this can be useful = work, but I am confused about the direction because it seems that the = gaps you can find have to assume an architectural solution and probably = a choice of protocol components.

 

So there may be a need to = write an early section on a framework to provide the context for showing = the gaps.

 

Adrian

 

From: detnet = [mailto:detnet-bounces@ietf.org] On Behalf Of Prof. Diego = Dujovne
Sent: 25 March 2015 22:49
To: Pat = Kinney
Cc: detnet@ietf.org
Subject: Re: [Detnet] = Looking for partners for Gap Analysis = draft

 

Pat,

      Thank you for = joining

Regards,

         &= nbsp;           &n= bsp;  Diego

 

2015-03-25 15:09 GMT-05:00 Pat Kinney <pat.kinney@kinneyconsultingllc.com>:<= /p>

I would like to assist in this effort, = especially towards 4.1 Industrial Controls.  I plan to work with my = partners in the ISA organization to define the basic requirements for = these applications.

 

Regards, Pat

 

Pat Kinney

Kinney Consulting LLC

IEEE 802.15 WG vice chair, TG chair

ISA100.11a WG chair

 

 

On 25, Mar2015, at 10:49, Prof. Diego Dujovne <diego.dujovne@mail.udp.cl> = wrote:

 

Dear = all,

         &= nbsp;  I have published the first (-00) version of = the

Gap Analysis = draft:

https://tools.ietf.org/html/draft-dujovne-detnet-gap-an= alysis-00

 I'm looking for co-authors to = collaborate

to build this = draft. Let me know through the list

if you are interested.

Thank = you.

         &= nbsp;           &n= bsp;      Diego Dujovne

=


-- =

DIEGO DUJOVNE
Acad=C3=A9mico = Escuela de Ingenier=C3=ADa en Inform=C3=A1tica y = Telecomunicaciones
Facultad de Ingenier=C3=ADa UDP
www.ingenieria.udp.cl
(56 2) 676 = 8125

=

_______________________________________________
detn= et mailing list
detnet@ietf.org
https://www.ietf.org/mailman/listinfo/detnet

 




--

DIEGO DUJOVNE
Acad=C3=A9mico Escuela de = Ingenier=C3=ADa en Inform=C3=A1tica y Telecomunicaciones
Facultad de = Ingenier=C3=ADa UDP
www.ingenieria.udp.cl
(56 2) 676 = 8125

------=_NextPart_000_00E9_01D067D0.CCDD5460-- From nobody Thu Mar 26 07:31:43 2015 Return-Path: X-Original-To: detnet@ietfa.amsl.com Delivered-To: detnet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 669461A0007 for ; Thu, 26 Mar 2015 07:31:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.208 X-Spam-Level: X-Spam-Status: No, score=-4.208 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 piICpxjG161g for ; Thu, 26 Mar 2015 07:31:40 -0700 (PDT) Received: from mail-gw1-out.broadcom.com (mail-gw1-out.broadcom.com [216.31.210.62]) by ietfa.amsl.com (Postfix) with ESMTP id 402AA1ACE7C for ; Thu, 26 Mar 2015 07:30:57 -0700 (PDT) X-IronPort-AV: E=Sophos; i="5.11,472,1422950400"; d="scan'208,217"; a="60648882" Received: from irvexchcas08.broadcom.com (HELO IRVEXCHCAS08.corp.ad.broadcom.com) ([10.9.208.57]) by mail-gw1-out.broadcom.com with ESMTP; 26 Mar 2015 07:41:18 -0700 Received: from SJEXCHCAS05.corp.ad.broadcom.com (10.16.203.12) by IRVEXCHCAS08.corp.ad.broadcom.com (10.9.208.57) with Microsoft SMTP Server (TLS) id 14.3.174.1; Thu, 26 Mar 2015 07:30:56 -0700 Received: from SJEXCHMB09.corp.ad.broadcom.com ([fe80::3da7:665e:cc78:181f]) by SJEXCHCAS05.corp.ad.broadcom.com ([::1]) with mapi id 14.03.0174.001; Thu, 26 Mar 2015 07:30:56 -0700 From: Jouni Korhonen To: "Prof. Diego Dujovne" Thread-Topic: [Detnet] Looking for partners for Gap Analysis draft Thread-Index: AQHQZxNH8j8mrDx2yky+kcj22Fp+H50u1Mpp Date: Thu, 26 Mar 2015 14:30:55 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: fi-FI X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_ADEA290ED0604F349F8BF7435CF4660Dbroadcomcom_" MIME-Version: 1.0 Archived-At: Cc: "detnet@ietf.org" Subject: Re: [Detnet] Looking for partners for Gap Analysis draft X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussions on Deterministic Networking, characterized by 1\) resource reservation; 2\) 0 congestion loss and guaranteed latency; 3\) over L2-only and mixed L2 and L3 networks; and 5\) 1+1 replication/deletion." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2015 14:31:42 -0000 --_000_ADEA290ED0604F349F8BF7435CF4660Dbroadcomcom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, I am willing to give a hand here. - jouni Sent from a smart phone.. Mind the typos.. Prof. Diego Dujovne > kirjoitti 25.3.2015 kello 10.49: Dear all, I have published the first (-00) version of the Gap Analysis draft: https://tools.ietf.org/html/draft-dujovne-detnet-gap-analysis-00 I'm looking for co-authors to collaborate to build this draft. Let me know through the list if you are interested. Thank you. Diego Dujovne -- DIEGO DUJOVNE Acad=E9mico Escuela de Ingenier=EDa en Inform=E1tica y Telecomunicaciones Facultad de Ingenier=EDa UDP www.ingenieria.udp.cl (56 2) 676 8125 _______________________________________________ detnet mailing list detnet@ietf.org https://www.ietf.org/mailman/listinfo/detnet --_000_ADEA290ED0604F349F8BF7435CF4660Dbroadcomcom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,

I am willing to give a hand here. 

- jouni

Sent from a smart phone.. Mind the typos..

Prof. Diego Dujovne <diego.= dujovne@mail.udp.cl> kirjoitti 25.3.2015 kello 10.49:

Dear all,
            I have p= ublished the first (-00) version of the
Gap Analysis draft:

https://tools.ietf.org/html/draft-dujovne-detnet-gap-analysis-00

 I'm looking for co-authors to collaborate
to build this draft. Let me know through the list
if you are interested.
Thank you.

            &nb= sp;            =    Diego Dujovne

--
DIEGO DUJOVNE
Acad=E9mico Escuela de Ingenier=EDa en Inform=E1tica y Telecomunicaciones Facultad de Ingenier=EDa UDP
www.ingenieria.u= dp.cl
(56 2) 676 8125
_______________________________________________
detnet mailing list
detnet@ietf.org
https://www.= ietf.org/mailman/listinfo/detnet
--_000_ADEA290ED0604F349F8BF7435CF4660Dbroadcomcom_-- From nobody Thu Mar 26 12:18:07 2015 Return-Path: X-Original-To: detnet@ietfa.amsl.com Delivered-To: detnet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C14D21A9162 for ; Thu, 26 Mar 2015 12:18:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 tH1yiBOo9P-9 for ; Thu, 26 Mar 2015 12:17:56 -0700 (PDT) Received: from mail-qg0-x231.google.com (mail-qg0-x231.google.com [IPv6:2607:f8b0:400d:c04::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87B281B2ADC for ; Thu, 26 Mar 2015 12:17:56 -0700 (PDT) Received: by qgep97 with SMTP id p97so113610816qge.1 for ; Thu, 26 Mar 2015 12:17:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ZQ7Ug/hJGPLjM9T9AiMVKkBlRt/AofkRd9i1oJgJT2o=; b=yNyt9BOyyHU4CqvSSXg3cZTFHSzHQoY46cAn7CyIcwY2R/uYJ0YWTQJEEXlGP3yiam bwjLxNTKoLA4+Wl9AlnEMn4ffcqeFK4NgE1P2OGlmtLii46s8w9q9si201mr+7bNUGAO HHQgVtcQOfirHwe3EZInbX9Q9AGCuyd+SF6GPU9tUHjpl+KP1KT0n23pI/IpNeEc/LxK hWDphQoagTpdRI9IlxOceOxxGYEPgZkE+lH6qtEodhCkiDvMPxdCQNqT0nFOVG8/uUPE +fqHbmoOOOlJCJAOObnPHaWFHyHw7C1mHvF7R8AJEDySrJo2MN7JAsI3GYPtsvRUKGXu pRZg== MIME-Version: 1.0 X-Received: by 10.140.43.199 with SMTP id e65mr19800875qga.34.1427397475563; Thu, 26 Mar 2015 12:17:55 -0700 (PDT) Received: by 10.140.19.148 with HTTP; Thu, 26 Mar 2015 12:17:55 -0700 (PDT) In-Reply-To: <00e801d067d0$ccd62870$66827950$@olddog.co.uk> References: <5F413472-4EE7-41EB-8F6E-7FD08386613B@kinneyconsultingllc.com> <00e801d067d0$ccd62870$66827950$@olddog.co.uk> Date: Thu, 26 Mar 2015 20:17:55 +0100 Message-ID: From: Anca Zamfir To: adrian@olddog.co.uk Content-Type: multipart/alternative; boundary=001a113a9baa7c0126051235dfcd Archived-At: Cc: detnet@ietf.org, "Prof. Diego Dujovne" , Pat Kinney Subject: Re: [Detnet] Looking for partners for Gap Analysis draft X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussions on Deterministic Networking, characterized by 1\) resource reservation; 2\) 0 congestion loss and guaranteed latency; 3\) over L2-only and mixed L2 and L3 networks; and 5\) 1+1 replication/deletion." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2015 19:18:01 -0000 --001a113a9baa7c0126051235dfcd Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Adrian, There is an architecture draft started at https://tools.ietf.org/html/draft-finn-detnet-architecture-00. Would a reference to that address your concerns? I was also looking for a similar (gap analysis) type of doc in IETF repo, anyone could point me to one? thanks, -anca On Thu, Mar 26, 2015 at 3:26 PM, Adrian Farrel wrote: > Hello all, > > > > I think this can be useful work, but I am confused about the direction > because it seems that the gaps you can find have to assume an architectur= al > solution and probably a choice of protocol components. > > > > So there may be a need to write an early section on a framework to provid= e > the context for showing the gaps. > > > > Adrian > > > > *From:* detnet [mailto:detnet-bounces@ietf.org] *On Behalf Of *Prof. > Diego Dujovne > *Sent:* 25 March 2015 22:49 > *To:* Pat Kinney > *Cc:* detnet@ietf.org > *Subject:* Re: [Detnet] Looking for partners for Gap Analysis draft > > > > Pat, > > Thank you for joining > > Regards, > > Diego > > > > 2015-03-25 15:09 GMT-05:00 Pat Kinney >: > > I would like to assist in this effort, especially towards 4.1 Industrial > Controls. I plan to work with my partners in the ISA organization to > define the basic requirements for these applications. > > > > Regards, Pat > > > > Pat Kinney > > *Kinney Consulting LLC* > > IEEE 802.15 WG vice chair, TG chair > > ISA100.11a WG chair > > O: +1.847.960.3715 > > pat.kinney@kinneyconsultingllc.com > > > > > > On 25, Mar2015, at 10:49, Prof. Diego Dujovne > wrote: > > > > Dear all, > > I have published the first (-00) version of the > > Gap Analysis draft: > > https://tools.ietf.org/html/draft-dujovne-detnet-gap-analysis-00 > > I'm looking for co-authors to collaborate > > to build this draft. Let me know through the list > > if you are interested. > > Thank you. > > Diego Dujovne > > > -- > > DIEGO DUJOVNE > Acad=C3=A9mico Escuela de Ingenier=C3=ADa en Inform=C3=A1tica y Telecomun= icaciones > Facultad de Ingenier=C3=ADa UDP > www.ingenieria.udp.cl > (56 2) 676 8125 > > _______________________________________________ > detnet mailing list > detnet@ietf.org > https://www.ietf.org/mailman/listinfo/detnet > > > > > > > -- > > DIEGO DUJOVNE > Acad=C3=A9mico Escuela de Ingenier=C3=ADa en Inform=C3=A1tica y Telecomun= icaciones > Facultad de Ingenier=C3=ADa UDP > www.ingenieria.udp.cl > (56 2) 676 8125 > > _______________________________________________ > detnet mailing list > detnet@ietf.org > https://www.ietf.org/mailman/listinfo/detnet > > --001a113a9baa7c0126051235dfcd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Adrian,
There is an architecture draft started at <= a href=3D"https://tools.ietf.org/html/draft-finn-detnet-architecture-00">ht= tps://tools.ietf.org/html/draft-finn-detnet-architecture-00. Would a re= ference to that address your concerns?
I was also looking for a s= imilar (gap analysis) type of doc in IETF repo, anyone could point me to on= e?

thanks,
-anca

On Thu, Mar 26, 2015 at 3:2= 6 PM, Adrian Farrel <adrian@olddog.co.uk> wrote:

Hello all,

= =C2=A0

I= think this can be useful work, but I am confused about the direction becau= se it seems that the gaps you can find have to assume an architectural solu= tion and probably a choice of protocol components.

=

=C2=A0

So there may be a n= eed to write an early section on a framework to provide the context for sho= wing the gaps.

=C2=A0

Adrian

=C2=A0

From:<= span lang=3D"EN-US" style=3D"font-size:10.0pt;font-family:"Tahoma"= ;,"sans-serif""> detnet [mailto:detnet-bounces@ietf.org] On Behalf Of Prof. Diego Dujovne
Sent: 25 March 2015 22:49
To: Pat= Kinney
Cc: detnet@ietf.org
Subject: Re: [Detnet] Lookin= g for partners for Gap Analysis draft

=

=C2=A0

Pat,

=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 Thank you for joining

Regards,<= /p>

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 Diego

<= div>

=C2=A0

2015-03-25 15:09 GMT-05:00 Pat Kinney <pat.kinney@kinneyconsultingllc.c= om>:

I would like to as= sist in this effort, especially towards 4.1 Industrial Controls.=C2=A0 I pl= an to work with my partners in the ISA organization to define the basic req= uirements for these applications.

=C2=A0

Regards, Pat<= u>

=C2=A0

=

Pat Kinney

Kinney Consulting LLC

IEEE 802.15 WG vice chair, TG chair<= u>

=C2=A0

=C2=A0

On 25, Mar2015, at 10:4= 9, Prof. Diego Dujovne <diego.dujovne@mail.udp.cl> wrote:

=C2=A0

Dear all,

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 I have published the first (-00) version = of the

Gap Analysis draft:
https://tools.ietf.org/html/draft-dujovne-detnet-g= ap-analysis-00

=C2=A0I'm looking for co-authors to collabora= te

to build this draft. Let m= e know through the list

if yo= u are interested.

Thank you.

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 Diego Dujovne

=


--

DIEGO DUJOVNE
Acad=C3=A9mico Es= cuela de Ingenier=C3=ADa en Inform=C3=A1tica y Telecomunicaciones
Facult= ad de Ingenier=C3=ADa UDP
www.ingenieria.udp.cl
(56 2) 676 8125

__________________________________________= _____
detnet mailing list
detnet@ietf.org
https://www.ietf.org/mailman/listinfo/de= tnet

=C2=A0<= u>



--

DIEGO DUJOVNE
Acad=C3= =A9mico Escuela de Ingenier=C3=ADa en Inform=C3=A1tica y Telecomunicaciones=
Facultad de Ingenier=C3=ADa UDP
www.ingenieria.udp.cl
(56 2) 676 8125<= u>


___________________= ____________________________
detnet mailing list
detnet@ietf.org
= https://www.ietf.org/mailman/listinfo/detnet


--001a113a9baa7c0126051235dfcd-- From nobody Tue Mar 31 10:38:11 2015 Return-Path: X-Original-To: detnet@ietfa.amsl.com Delivered-To: detnet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77DEA1A1AB2 for ; Tue, 31 Mar 2015 10:38:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.208 X-Spam-Level: X-Spam-Status: No, score=-4.208 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 8s8LF0Euf5zp for ; Tue, 31 Mar 2015 10:38:04 -0700 (PDT) Received: from mail-gw2-out.broadcom.com (mail-gw2-out.broadcom.com [216.31.210.63]) by ietfa.amsl.com (Postfix) with ESMTP id 431371A3B9C for ; Tue, 31 Mar 2015 10:38:03 -0700 (PDT) X-IronPort-AV: E=Sophos; i="5.11,502,1422950400"; d="scan'208,217"; a="60854277" Received: from irvexchcas06.broadcom.com (HELO IRVEXCHCAS06.corp.ad.broadcom.com) ([10.9.208.53]) by mail-gw2-out.broadcom.com with ESMTP; 31 Mar 2015 10:41:51 -0700 Received: from SJEXCHCAS03.corp.ad.broadcom.com (10.16.203.8) by IRVEXCHCAS06.corp.ad.broadcom.com (10.9.208.53) with Microsoft SMTP Server (TLS) id 14.3.174.1; Tue, 31 Mar 2015 10:38:01 -0700 Received: from SJEXCHMB09.corp.ad.broadcom.com ([fe80::3da7:665e:cc78:181f]) by SJEXCHCAS03.corp.ad.broadcom.com ([::1]) with mapi id 14.03.0174.001; Tue, 31 Mar 2015 10:38:01 -0700 From: Jouni Korhonen To: "Prof. Diego Dujovne" , "detnet@ietf.org" Thread-Topic: [Detnet] Looking for partners for Gap Analysis draft Thread-Index: AQHQZxNH8j8mrDx2yky+kcj22Fp+H5023ltg Date: Tue, 31 Mar 2015 17:38:00 +0000 Message-ID: <72CC502C2C615C42B081A9E5FC057D05255DB0@SJEXCHMB09.corp.ad.broadcom.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.16.203.100] Content-Type: multipart/alternative; boundary="_000_72CC502C2C615C42B081A9E5FC057D05255DB0SJEXCHMB09corpadb_" MIME-Version: 1.0 Archived-At: Subject: Re: [Detnet] Looking for partners for Gap Analysis draft X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussions on Deterministic Networking, characterized by 1\) resource reservation; 2\) 0 congestion loss and guaranteed latency; 3\) over L2-only and mixed L2 and L3 networks; and 5\) 1+1 replication/deletion." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Mar 2015 17:38:09 -0000 --_000_72CC502C2C615C42B081A9E5FC057D05255DB0SJEXCHMB09corpadb_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCkkgd2FzIHJlYWRpbmcgdGhlIGRyYWZ0Li4gVGhhbmtzIGZvciBpbml0aWF0aW5nIHRo ZSB3b3JrISBGZXcgcXVpY2sgcXVlc3Rpb25zIGFuZCBjb21tZW50cy4NCg0KSW4gU2VjdGlvbiAz LjIgb3IgYXMgYSBzZXBhcmF0ZSBzZWN0aW9uIHNob3VsZG7igJl0IHdlIGFsc28gcG9pbnQgYXQg SUVFRSA4MDIuMUNCIGFzIGEgTDIgbWVjaGFuaXNtIHRvIHByb3ZpZGUgcmVkdW5kYW5jeS4gQWxz bywgaW5zdGVhZCBvZiByZWZlcnJpbmcgdG8gTVBMUyBJIHdvdWxkIHJhdGhlciB0YWxrIFBXRXMg aW5zdGVhZC4NCg0KVGhlbiBhbm90aGVyIGNvbW1lbnQgc3BlY2lmaWNhbGx5IHJlZ2FyZGluZyBT ZWN0aW9uIDMgZ2FwIGFuYWx5c2lzLiBBcyBpdCBzdGFuZHMgbm93IGl0IGlzIG1vcmUgbGlrZSBh IHJ1bmRvd24gb2Ygc29sdXRpb25zLiBJIGRvIG5vdCBzZWUgYSBnYXAgdG8gYW55dGhpbmcgZGlz Y3Vzc2VkL3BvaW50ZWQgaGVyZT8gRWFjaCBvZiB0aGVzZSBzZWN0aW9ucyBzaG91bGQgbGlzdCB3 aGF0IGlzIG1pc3Npbmcgb3Igd2hhdCBjYW5ub3QgYmUgc3VwcG9ydGVkIGlmIHRyYW5zcG9ydCBn b2VzIG92ZXIgSVAuDQoNCldoYXQgSSB3b3VsZCBkbyBpcyB0byBmaXJzdCBsaXN0IGRvd24gdGhl IGlzc3VlcyAvIGJ1aWxkaW5nIGJsb2NrcyB0aGF0IHdlIGtub3cgYXJlIG11c3QgdG8gaGF2ZSB0 byByZWFsaXplIGEgZGV0ZXJtaW5pc3RpYyBuZXR3b3JraW5nIGF0IEwzLiBBZnRlciB0aGF0IGVh Y2ggdGVjaG5vbG9neSBoYXZlIGEgc2hvcnQgZGVzY3JpcHRpb24sIGZvbGxvd2VkIGJ5IChidWxs ZXQpIGxpc3Qgd2hhdCBjYW4gYmUgc3VwcG9ydGVkIGFuZCB3aGF0IG5vdC4gQW5kIHRoZW4gYSBz aG9ydCBzdW1tYXJ5IGZvciBlYWNoIHRlY2hub2xvZ3kuIENvbW1lbnRzPw0KDQotIEpvdW5pDQoN CkZyb206IGRldG5ldCBbbWFpbHRvOmRldG5ldC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYg T2YgUHJvZi4gRGllZ28gRHVqb3ZuZQ0KU2VudDogV2VkbmVzZGF5LCBNYXJjaCAyNSwgMjAxNSA4 OjQ5IEFNDQpUbzogZGV0bmV0QGlldGYub3JnDQpTdWJqZWN0OiBbRGV0bmV0XSBMb29raW5nIGZv ciBwYXJ0bmVycyBmb3IgR2FwIEFuYWx5c2lzIGRyYWZ0DQoNCkRlYXIgYWxsLA0KICAgICAgICAg ICAgSSBoYXZlIHB1Ymxpc2hlZCB0aGUgZmlyc3QgKC0wMCkgdmVyc2lvbiBvZiB0aGUNCkdhcCBB bmFseXNpcyBkcmFmdDoNCg0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWR1am92 bmUtZGV0bmV0LWdhcC1hbmFseXNpcy0wMA0KDQogSSdtIGxvb2tpbmcgZm9yIGNvLWF1dGhvcnMg dG8gY29sbGFib3JhdGUNCnRvIGJ1aWxkIHRoaXMgZHJhZnQuIExldCBtZSBrbm93IHRocm91Z2gg dGhlIGxpc3QNCmlmIHlvdSBhcmUgaW50ZXJlc3RlZC4NClRoYW5rIHlvdS4NCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICBEaWVnbyBEdWpvdm5lDQoNCi0tDQpESUVHTyBEVUpPVk5FDQpBY2Fk w6ltaWNvIEVzY3VlbGEgZGUgSW5nZW5pZXLDrWEgZW4gSW5mb3Jtw6F0aWNhIHkgVGVsZWNvbXVu aWNhY2lvbmVzDQpGYWN1bHRhZCBkZSBJbmdlbmllcsOtYSBVRFANCnd3dy5pbmdlbmllcmlhLnVk cC5jbDxodHRwOi8vd3d3LmluZ2VuaWVyaWEudWRwLmNsPg0KKDU2IDIpIDY3NiA4MTI1DQo= --_000_72CC502C2C615C42B081A9E5FC057D05255DB0SJEXCHMB09corpadb_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10 eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0K QHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAx LjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24x O30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRz IHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1h cCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRp Zl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVy cGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SGksPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5J IHdhcyByZWFkaW5nIHRoZSBkcmFmdC4uIFRoYW5rcyBmb3IgaW5pdGlhdGluZyB0aGUgd29yayEg RmV3IHF1aWNrIHF1ZXN0aW9ucyBhbmQgY29tbWVudHMuPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JbiBTZWN0aW9uIDMu MiBvciBhcyBhIHNlcGFyYXRlIHNlY3Rpb24gc2hvdWxkbuKAmXQgd2UgYWxzbyBwb2ludCBhdCBJ RUVFIDgwMi4xQ0IgYXMgYSBMMiBtZWNoYW5pc20gdG8gcHJvdmlkZSByZWR1bmRhbmN5LiBBbHNv LCBpbnN0ZWFkIG9mIHJlZmVycmluZyB0byBNUExTDQogSSB3b3VsZCByYXRoZXIgdGFsayBQV0Vz IGluc3RlYWQuIDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhlbiBhbm90aGVyIGNvbW1lbnQgc3BlY2lmaWNhbGx5IHJl Z2FyZGluZyBTZWN0aW9uIDMgZ2FwIGFuYWx5c2lzLiBBcyBpdCBzdGFuZHMgbm93IGl0IGlzIG1v cmUgbGlrZSBhIHJ1bmRvd24gb2Ygc29sdXRpb25zLiBJIGRvIG5vdCBzZWUgYSBnYXAgdG8gYW55 dGhpbmcNCiBkaXNjdXNzZWQvcG9pbnRlZCBoZXJlPyBFYWNoIG9mIHRoZXNlIHNlY3Rpb25zIHNo b3VsZCBsaXN0IHdoYXQgaXMgbWlzc2luZyBvciB3aGF0IGNhbm5vdCBiZSBzdXBwb3J0ZWQgaWYg dHJhbnNwb3J0IGdvZXMgb3ZlciBJUC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPldoYXQgSSB3b3VsZCBkbyBpcyB0byBm aXJzdCBsaXN0IGRvd24gdGhlIGlzc3VlcyAvIGJ1aWxkaW5nIGJsb2NrcyB0aGF0IHdlIGtub3cg YXJlIG11c3QgdG8gaGF2ZSB0byByZWFsaXplIGEgZGV0ZXJtaW5pc3RpYyBuZXR3b3JraW5nIGF0 IEwzLiBBZnRlciB0aGF0IGVhY2gNCiB0ZWNobm9sb2d5IGhhdmUgYSBzaG9ydCBkZXNjcmlwdGlv biwgZm9sbG93ZWQgYnkgKGJ1bGxldCkgbGlzdCB3aGF0IGNhbiBiZSBzdXBwb3J0ZWQgYW5kIHdo YXQgbm90LiBBbmQgdGhlbiBhIHNob3J0IHN1bW1hcnkgZm9yIGVhY2ggdGVjaG5vbG9neS4gQ29t bWVudHM/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj4tIEpvdW5pPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2 Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0 O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+IGRldG5ldCBbbWFpbHRvOmRldG5ldC1ib3VuY2VzQGlldGYub3JnXQ0KPGI+ T24gQmVoYWxmIE9mIDwvYj5Qcm9mLiBEaWVnbyBEdWpvdm5lPGJyPg0KPGI+U2VudDo8L2I+IFdl ZG5lc2RheSwgTWFyY2ggMjUsIDIwMTUgODo0OSBBTTxicj4NCjxiPlRvOjwvYj4gZGV0bmV0QGll dGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFtEZXRuZXRdIExvb2tpbmcgZm9yIHBhcnRuZXJz IGZvciBHYXAgQW5hbHlzaXMgZHJhZnQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0K PGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+RGVhciBhbGwsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyBJIGhhdmUgcHVibGlzaGVkIHRoZSBmaXJzdCAoLTAwKSB2ZXJzaW9uIG9m IHRoZTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5HYXAgQW5h bHlzaXMgZHJhZnQ6PGJyPg0KPGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9o dG1sL2RyYWZ0LWR1am92bmUtZGV0bmV0LWdhcC1hbmFseXNpcy0wMCI+aHR0cHM6Ly90b29scy5p ZXRmLm9yZy9odG1sL2RyYWZ0LWR1am92bmUtZGV0bmV0LWdhcC1hbmFseXNpcy0wMDwvYT48YnI+ DQo8YnI+DQombmJzcDtJJ20gbG9va2luZyBmb3IgY28tYXV0aG9ycyB0byBjb2xsYWJvcmF0ZTxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj50byBidWlsZCB0aGlz IGRyYWZ0LiBMZXQgbWUga25vdyB0aHJvdWdoIHRoZSBsaXN0PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmlmIHlvdSBhcmUgaW50ZXJlc3RlZC48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206 MTIuMHB0Ij5UaGFuayB5b3UuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBE aWVnbyBEdWpvdm5lPGJyIGNsZWFyPSJhbGwiPg0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRp dj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KLS0gPG86cD48L286cD48L3A+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+RElFR08gRFVKT1ZORTxicj4NCkFjYWTDqW1pY28gRXNjdWVs YSBkZSBJbmdlbmllcsOtYSBlbiBJbmZvcm3DoXRpY2EgeSBUZWxlY29tdW5pY2FjaW9uZXM8YnI+ DQpGYWN1bHRhZCBkZSBJbmdlbmllcsOtYSBVRFA8YnI+DQo8YSBocmVmPSJodHRwOi8vd3d3Lmlu Z2VuaWVyaWEudWRwLmNsIiB0YXJnZXQ9Il9ibGFuayI+d3d3LmluZ2VuaWVyaWEudWRwLmNsPC9h Pjxicj4NCig1NiAyKSA2NzYgODEyNTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_72CC502C2C615C42B081A9E5FC057D05255DB0SJEXCHMB09corpadb_--