From nobody Tue Apr 12 01:53:28 2016 Return-Path: X-Original-To: scsn@ietfa.amsl.com Delivered-To: scsn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BFCE12E8B5; Tue, 12 Apr 2016 01:53:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.216 X-Spam-Level: X-Spam-Status: No, score=-5.216 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 XKgPL9d7cdvE; Tue, 12 Apr 2016 01:53:23 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B6ED12E8B1; Tue, 12 Apr 2016 01:53:22 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml707-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CLX82344; Tue, 12 Apr 2016 08:53:19 +0000 (GMT) Received: from SZXEMA412-HUB.china.huawei.com (10.82.72.71) by lhreml707-cah.china.huawei.com (10.201.5.199) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 12 Apr 2016 09:53:17 +0100 Received: from SZXEMA506-MBS.china.huawei.com ([169.254.4.160]) by SZXEMA412-HUB.china.huawei.com ([10.82.72.71]) with mapi id 14.03.0235.001; Tue, 12 Apr 2016 16:53:08 +0800 From: Jiangyuanlong To: "Grossman, Ethan A." , "detnet@ietf.org" Thread-Topic: [Detnet] DetNet Use Case Statements: Providing Synchronized Time Thread-Index: AdGRCKJDoI4EO4AYS9GGhMr+RHKjNgDhxzmg Date: Tue, 12 Apr 2016 08:53:07 +0000 Message-ID: <3B0A1BED22CAD649A1B3E97BE5DDD68B9168837A@szxema506-mbs.china.huawei.com> References: <8583e31212574c81ae93fbae34369b3d@DLB-XCHPW03.dolby.net> In-Reply-To: <8583e31212574c81ae93fbae34369b3d@DLB-XCHPW03.dolby.net> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.76.118] Content-Type: multipart/alternative; boundary="_000_3B0A1BED22CAD649A1B3E97BE5DDD68B9168837Aszxema506mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090202.570CB780.004D, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.4.160, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 4fa66b7bfddeb80868c9fb51328e6b7e Archived-At: Cc: "scsn@ietf.org" Subject: Re: [Scsn] [Detnet] DetNet Use Case Statements: Providing Synchronized Time X-BeenThere: scsn@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Scalable Clock Synchronization Network- Discussion of Scalable Clock Synchronization Network." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2016 08:53:26 -0000 --_000_3B0A1BED22CAD649A1B3E97BE5DDD68B9168837Aszxema506mbschi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Ethan, It seems to me this use case can be further partitioned into two different = problems: 1. Providing sync info within a DetNet, so that all nodes in the DetNet are= synchronized to the same clock, for example, each node runs in the BC mode= of IEEE 1588v2 and an external GPS/GNSS receiver provides the clock source= for all nodes in this DetNet network; 2. Transporting sync info for the 3rd party across a DetNet. This can furth= er be divided into two cases: a) The DetNet is not aware of the timing info, but take it as a low delay s= ervice. b) The DetNet is aware of the timing info, some of the nodes in the DetNet = may provide timing correction for the timing info. For example, several nod= es in the DetNet network can work in the TC mode of IEEE 1588v2. IMO, 2.a) is already in the scope of the DetNet; 1 is essential for DetNet,= but not yet in its scope; 2.b) can be an interesting application for the D= etNet. Regards, Yuanlong From: detnet [mailto:detnet-bounces@ietf.org] On Behalf Of Grossman, Ethan = A. Sent: Friday, April 08, 2016 4:05 AM To: detnet@ietf.org Subject: [Detnet] DetNet Use Case Statements: Providing Synchronized Time Statement: Providing Synchronized Time (not in scope) Discussion: A point came up about whether DetNet streams could serve as a way to delive= r timekeeping packets in a more timely way in order to provide more accurat= e time. We concluded that this was a possible use case for DetNet, and invi= te contributions of use case text on the topic. However since DetNet itself= depends on time sync to function, making timekeeping depend on DetNet is a= circular dependency so doesn't seem feasible. --_000_3B0A1BED22CAD649A1B3E97BE5DDD68B9168837Aszxema506mbschi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Ethan,<= o:p>

 = ;

It seems t= o me this use case can be further partitioned into two different problems:

1. Providi= ng sync info within a DetNet, so that all nodes in the DetNet are synchroni= zed to the same clock, for example, each node runs in the BC mode of IEEE 1588v2 and an external GPS/GNSS receiver provides the cloc= k source for all nodes in this DetNet network;

2. Transpo= rting sync info for the 3rd party across a DetNet. This can furt= her be divided into two cases:

a) The Det= Net is not aware of the timing info, but take it as a low delay service.

b) The Det= Net is aware of the timing info, some of the nodes in the DetNet may provid= e timing correction for the timing info. For example, several nodes in the DetNet network can work in the TC mode of IEEE 1588v2.

 = ;

IMO, 2.a) = is already in the scope of the DetNet; 1 is essential for DetNet, but not yet in its scope; 2.b) can be an interesting application for the DetNe= t.

 = ;

Regards,

Yuanlong



From: detnet [mailto:detnet-bounces@ietf.org] On Behalf Of Grossman, Etha= n A.
Sent: Friday, April 08, 2016 4:05 AM
To: detnet@ietf.org
Subject: [Detnet] DetNet Use Case Statements: Providing Synchronized= Time

 

Statement:

Providing Synchronized Time (not in scope)=

Discussion:

A point came up about whether DetNet streams co= uld serve as a way to deliver timekeeping packets in a more timely way in order to provide more accurate time. We concluded that this was a possi= ble use case for DetNet, and invite contributions of use case text on the t= opic. However since DetNet itself depends on time sync to function, making = timekeeping depend on DetNet is a circular dependency so doesn’t seem feasible.

 

 

--_000_3B0A1BED22CAD649A1B3E97BE5DDD68B9168837Aszxema506mbschi_--