From yaakov_s@rad.com Thu Aug 6 13:01:48 2009 Return-Path: X-Original-To: tictoc@core3.amsl.com Delivered-To: tictoc@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 340323A6850 for ; Thu, 6 Aug 2009 13:01:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.391 X-Spam-Level: X-Spam-Status: No, score=-1.391 tagged_above=-999 required=5 tests=[AWL=-1.207, BAYES_40=-0.185, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VTvtMoBned1z for ; Thu, 6 Aug 2009 13:01:45 -0700 (PDT) Received: from antivir1.rad.co.il (mx1-q.rad.co.il [80.74.100.136]) by core3.amsl.com (Postfix) with ESMTP id 65DB93A681C for ; Thu, 6 Aug 2009 13:01:43 -0700 (PDT) Received: from exrad4.ad.rad.co.il ([192.114.24.47]) by antivir1.rad.co.il with ESMTP; 06 Aug 2009 23:01:25 +0300 Received: from exrad4.ad.rad.co.il ([192.114.24.47]) by exrad4.ad.rad.co.il ([192.114.24.47]) with mapi; Thu, 6 Aug 2009 23:00:57 +0300 From: Yaakov Stein To: "tictoc@ietf.org" , "ntpwg@lists.ntp.isc.org" Date: Thu, 6 Aug 2009 23:00:54 +0300 Thread-Topic: once in a hundred years coincidence tomorrow Thread-Index: AcoW0Jrx3BO0fenESPWTWw1egAPe0Q== Message-ID: <48E7911F78327A449A9FB956376672861D9EEEB3@exrad4.ad.rad.co.il> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_48E7911F78327A449A9FB956376672861D9EEEB3exrad4adradcoil_" MIME-Version: 1.0 Subject: [TICTOC] once in a hundred years coincidence tomorrow X-BeenThere: tictoc@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Timing over IP Connection and Transfer of Clock BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2009 20:01:48 -0000 --_000_48E7911F78327A449A9FB956376672861D9EEEB3exrad4adradcoil_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I just noticed that tomorrow at 34 minutes and 56 seconds past noon, the ToD will be 12:34.56 7/8/09, or for short 123456789. Enjoy the second. Y(J)S --_000_48E7911F78327A449A9FB956376672861D9EEEB3exrad4adradcoil_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I just noticed that tomorrow at 34 minutes and 56 seco= nds past noon,

the ToD will be 12:34.56 7/8/09, or for short 12345678= 9.

 

Enjoy the second.

 

Y(J)S

--_000_48E7911F78327A449A9FB956376672861D9EEEB3exrad4adradcoil_-- From tme@americafree.tv Thu Aug 6 13:10:12 2009 Return-Path: X-Original-To: tictoc@core3.amsl.com Delivered-To: tictoc@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E4FFD3A6E3E for ; Thu, 6 Aug 2009 13:10:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1l47OLalUyqF for ; Thu, 6 Aug 2009 13:10:11 -0700 (PDT) Received: from mail.americafree.tv (rossini.americafree.tv [63.105.122.34]) by core3.amsl.com (Postfix) with ESMTP id 87B6A3A6E3C for ; Thu, 6 Aug 2009 13:09:38 -0700 (PDT) Received: from [IPv6:::1] (rossini.americafree.tv [63.105.122.34]) by mail.americafree.tv (Postfix) with ESMTP id 66B9346B1813; Thu, 6 Aug 2009 16:09:41 -0400 (EDT) Message-Id: <364504E5-127B-4916-B49D-C9B3FBF32473@americafree.tv> From: Marshall Eubanks To: Yaakov Stein In-Reply-To: <48E7911F78327A449A9FB956376672861D9EEEB3@exrad4.ad.rad.co.il> Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Thu, 6 Aug 2009 16:09:40 -0400 References: <48E7911F78327A449A9FB956376672861D9EEEB3@exrad4.ad.rad.co.il> X-Mailer: Apple Mail (2.935.3) Cc: ntpwg@lists.ntp.isc.org, tictoc@ietf.org Subject: Re: [TICTOC] once in a hundred years coincidence tomorrow X-BeenThere: tictoc@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Timing over IP Connection and Transfer of Clock BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2009 20:10:13 -0000 On Aug 6, 2009, at 4:00 PM, Yaakov Stein wrote: > I just noticed that tomorrow at 34 minutes and 56 seconds past noon, > the ToD will be 12:34.56 7/8/09, or for short 123456789. > Of course, in some places this instant of bliss happened last month. Regards Marshall > Enjoy the second. > > Y(J)S > _______________________________________________ > TICTOC mailing list > TICTOC@ietf.org > https://www.ietf.org/mailman/listinfo/tictoc From tfrost@symmetricom.com Fri Aug 7 04:04:54 2009 Return-Path: X-Original-To: tictoc@core3.amsl.com Delivered-To: tictoc@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A01F3A6EE6 for ; Fri, 7 Aug 2009 04:04:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.264 X-Spam-Level: X-Spam-Status: No, score=-2.264 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r5Fcbwv3-qqr for ; Fri, 7 Aug 2009 04:04:51 -0700 (PDT) Received: from mail5.symmetricom.com (mail5.symmetricom.com [69.25.98.10]) by core3.amsl.com (Postfix) with SMTP id C09B728C15B for ; Fri, 7 Aug 2009 04:03:53 -0700 (PDT) X-ASG-Debug-ID: 1249643035-3a8a00000000-4wH9i1 X-ASG-Debug-ID: 1249643035-3a8a00000000-4wH9i1 X-ASG-Debug-ID: 1249643035-3a8a00000000-4wH9i1 X-Barracuda-URL: http://192.168.10.96:80/cgi-bin/mark.cgi Received: from sjowa.symmetricom.com (unknown [192.168.10.41]) by mail5.symmetricom.com (Spam Firewall) with ESMTP id 285BCE588; Fri, 7 Aug 2009 04:03:55 -0700 (PDT) Received: from sjowa.symmetricom.com ([192.168.10.41]) by mail5.symmetricom.com with ESMTP id wlDlTn17Pjbps7pN; Fri, 07 Aug 2009 04:03:55 -0700 (PDT) Received: from sjmail2.symmetricom.com ([192.168.10.66]) by sjowa.symmetricom.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 7 Aug 2009 04:03:54 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA174E.C0F00367" X-ASG-Orig-Subj: RE: [TICTOC] once in a hundred years coincidence tomorrow Date: Fri, 7 Aug 2009 04:03:52 -0700 Message-ID: In-Reply-To: <48E7911F78327A449A9FB956376672861D9EEEB3@exrad4.ad.rad.co.il> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TICTOC] once in a hundred years coincidence tomorrow Thread-Index: AcoW0Jrx3BO0fenESPWTWw1egAPe0QAfZmFg From: "Tim Frost" To: "Yaakov Stein" , , X-OriginalArrivalTime: 07 Aug 2009 11:03:54.0593 (UTC) FILETIME=[C0F94510:01CA174E] X-Barracuda-Connect: UNKNOWN[192.168.10.41] X-Barracuda-Start-Time: 1249643036 X-Barracuda-Virus-Scanned: by Symmetricom Spam Gateway at symmetricom.com X-Barracuda-Spam-Score: -1002.00 X-Barracuda-Spam-Status: No, SCORE=-1002.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=1000.0 Subject: Re: [TICTOC] once in a hundred years coincidence tomorrow X-BeenThere: tictoc@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Timing over IP Connection and Transfer of Clock BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Aug 2009 11:04:54 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA174E.C0F00367 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Can anyone else remember where they were at 12.34 on 5th June 1978? (12345678 for us Europeans - again the Americans were a month out in their chronology) =20 I can (standing in the school quadrangle), and I'm sure it wasn't 100 years ago! And it lasted a whole minute, not just a second! =20 Cheers, Tim ________________________________ From: tictoc-bounces@ietf.org [mailto:tictoc-bounces@ietf.org] On Behalf Of Yaakov Stein Sent: 06 August 2009 21:01 To: tictoc@ietf.org; ntpwg@lists.ntp.isc.org Subject: [TICTOC] once in a hundred years coincidence tomorrow =20 I just noticed that tomorrow at 34 minutes and 56 seconds past noon, the ToD will be 12:34.56 7/8/09, or for short 123456789. =20 Enjoy the second. =20 Y(J)S ------_=_NextPart_001_01CA174E.C0F00367 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Can anyone else remember where they = were at 12.34 on 5th June 1978?  (12345678 for us Europeans = – again the Americans were a month out in their = chronology)

 

I can (standing in the school = quadrangle), and I’m sure it wasn’t 100 years ago! And it lasted a whole = minute, not just a second!

 

Cheers,
Tim

From: tictoc-bounces@ietf.org [mailto:tictoc-bounces@ietf.org] On Behalf Of Yaakov Stein
Sent: 06 August 2009 = 21:01
To: tictoc@ietf.org; ntpwg@lists.ntp.isc.org
Subject: [TICTOC] once in = a hundred years coincidence tomorrow

 

I just noticed that tomorrow at 34 minutes and 56 seconds past = noon,

the ToD will be 12:34.56 7/8/09, or for short = 123456789.

 

Enjoy the second.

 

Y(J)S

------_=_NextPart_001_01CA174E.C0F00367-- From sebastien.jobert@orange-ftgroup.com Tue Aug 18 01:34:54 2009 Return-Path: X-Original-To: tictoc@core3.amsl.com Delivered-To: tictoc@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 81EF83A686C for ; Tue, 18 Aug 2009 01:34:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.39 X-Spam-Level: X-Spam-Status: No, score=-0.39 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RD+-ALKqXAGf for ; Tue, 18 Aug 2009 01:34:53 -0700 (PDT) Received: from R-MAIL2.rd.francetelecom.com (r-mail2.rd.francetelecom.com [217.108.152.42]) by core3.amsl.com (Postfix) with ESMTP id B98D43A63D3 for ; Tue, 18 Aug 2009 01:33:54 -0700 (PDT) Received: from ftrdmel1.rd.francetelecom.fr ([10.192.128.40]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Tue, 18 Aug 2009 10:32:33 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 18 Aug 2009 10:32:31 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Minutes TICTOC IETF 75 Thread-Index: AcoXshdHmDSc0GUlSLusKvhQmco1zgHcNs+QAC3f6qA= From: To: , X-OriginalArrivalTime: 18 Aug 2009 08:32:33.0406 (UTC) FILETIME=[6EB559E0:01CA1FDE] Cc: odonoghue@isoc.org Subject: [TICTOC] Minutes TICTOC IETF 75 X-BeenThere: tictoc@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Timing over IP Connection and Transfer of Clock BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2009 08:34:54 -0000 Dear all, Please find attached the minutes of TICTOC WG meeting during IETF 75 in = Stockholm. Questions and comments are welcome. Best Regards, S=E9bastien JOBERT R&D engineer, network synchronization Orange Labs / France Telecom R&D FT/RD/CORE/MCN/WAN Tel : +33 2 96 05 20 93 - Mob : +33 6 82 69 00 50=20 sebastien.jobert@orange-ftgroup.com =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= IETF TICTOC Working Group Meeting Monday, July 27, 2009, 1740-1940 The jabber log can be found at: http://jabber.ietf.org/logs/tictoc/2009-07-27.txt The meeting was called to order by co-chairs Yaakov Stein and Stewart = Bryant. S=E9bastien Jobert took the minutes. There was no volunteer to = act as jabber scribe; however, Stewart monitored the jabber room and = provided comments from remote attendees. The blue sheets were = distributed, and the agenda was presented with no additions = (http://www.ietf.org/proceedings/75/agenda/tictoc.txt).=20 Status Update, Yaakov Stein =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Slides: tictoc-0 = (http://www.ietf.org/proceedings/75/slides/tictoc-0.ppt) Yaakov presented the status of the current working group work items and = documents. The requirements draft is now officially a WG draft (WG00 draft, = http://www.ietf.org/id/draft-ietf-tictoc-requirements-00.txt). It was pointed out that Silvana Rodrigues, editor of this draft but not = present during this IETF75 meeting, plans to remotely continue editing = this draft. Karen was therefore asked by Yaakov to present the updates = of this draft, on behalf of Silvana, later during the meeting. The architecture draft = (http://tools.ietf.org/html/draft-stein-tictoc-modules) was briefly = discussed; no progress was made since the last IETF meeting. The work regarding other drafts has not started. It was explained that several conference calls have been organised in = order to progress on the requirements draft. During those calls, there = was a feeling that definitions would be needed. Instead of keeping those = definitions within the requirements draft, it was considered preferable = to create a new dedicated document. However, this new document was not = ready (still in early stages) and therefore not presented during IETF 75 = (only slides intending to summarize the discussions have been = presented). Attendees were reminded that conference calls would continue being = organised to progress the work. These calls take place on the first and = third Thursday of each month, and reminders are sent to the list. NTP status update, Karen O'Donoghue =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Slides: tictoc-5 = (http://www.ietf.org/proceedings/75/slides/tictoc-5.ppt) Karen presented the status of NTP on going items: - NTPv4 protocol: IESG evaluation - NTPv4 MIB: IESG evaluation - NTP Autokey: IESG evaluation (AD follow-up) - NTP server DHCPv6: second WG last call (few endorsements) Following this presentation, there has been a short discussion regarding = the DHCP draft. The conclusion was that the NTP DHCPv6 draft needs DHCP = WGs review. Requirements draft update, Karen O'Donoghue (slides prepared by Silvana = Rodrigues) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D Document: http://www.ietf.org/id/draft-ietf-tictoc-requirements-00.txt Slides: tictoc-4 = (http://www.ietf.org/proceedings/75/slides/tictoc-4.ppt) Karen presented the short summary of the requirements document status, = prepared by Silvana. The format of the tables has been changed. It was pointed out that = requirements are still missing for industrial and networking = applications. Comments on the draft are welcome. Definitions draft, Yaakov Stein =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D Slides: tictoc-3 = (http://www.ietf.org/proceedings/75/slides/tictoc-3.ppt) Yaakov presented a short summary of the discussions on definitions which = happened during the TICTOC conference calls. The presentation contains the terms "frequency", "phase", "aligned = phase", "labeled time", and "calibrated time", as well as "stability", = "accuracy", "holdover", and the "on-path support" concept. It was reminded that the intention is to reference the existing = definitions in other SDOs (such as ITU-T Q13/15), when possible. It was also said that the presented definitions were not yet agreed, and = that the work is still on-going. There was a request to submit a document providing the discussed = definitions so that the participants could review them. Then, a long discussion started regarding some terms contained in the = slides, for clarification, especially regarding the concept of "on-path = support". =09 1588v2 time synchronization modules, Fei Su =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Slides: tictoc-2 = (http://www.ietf.org/proceedings/75/slides/tictoc-2.ppt) Fei provided a set of slides discussing how PTPv2 could be used to = deliver time synchronization to base stations (e.g. for TD-SCDMA = systems), together with frequency synchronization (delivered at the = physical layer) support (such as combination with Synchronous Ethernet). = The slides contain a description of different possible modules. Fei = explained that this document has been merged with another I-D previously = presented. There was a remark after the presentation regarding the degree of = overlap of the proposed work with activities already on-going in other = SDOs (such as, for instance, ITU-T Q13/15, which was clearly referenced = in the presentation). Some participants also attending to ITU-T Q13/15 = confirmed that some work is currently on-going in ITU-T regarding the = definition of a PTP profile time-oriented, including the possible = combination with Synchronous Ethernet. The TICTOC chairs clarified that = TICTOC does not wish to duplicate work that is already on-going = elsewhere, but that TICTOC could cover any other aspects which are not = handled and where TICTOC or IETF has expertise. The security aspects of = the PTP profiles were felt as a possible study item for TICTOC. Femto Cell synchronization, Rock Xie =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Slides: tictoc-1 = (http://www.ietf.org/proceedings/75/slides/tictoc-1.ppt) Rock presented an analysis of the femto cells application and its = related implications on synchronization delivery. 3 main challenges regarding synchronization were depicted in the = presentation: security, connectivity, and scalability. The presentation pointed out the potential issues on synchronization = flows (e.g. higher PDV) when using mechanisms such as IP Sec or NAT. Discussion took place as to whether this femtocell application would = need to be added in the requirements draft, or if it is already = sufficiently covered. There was a comment that the Femto Cell Forum, working on femto cell = aspects, has not investigated the synchronization aspects of femto cells = in details. It was however clarified that the Femto Cell Forum had not asked the = IETF to work on this problem, and that this presentation was not an = official request from the Femto Cell Forum. There were short comments on security aspects: it was said that other = security mechanisms than the one discussed in the presentation could = also have been considered for the synchronization flow. It was asked what was the specific synchronization protocol targeted in = this presentation. Rock replied that this presentation did not intend to = discuss a protocol in particular, but rather the general requirements = associated to femto cells. It was said that a similar presentation has = also been done in ITU-T Q13/15, with a clear discussion towards PTP = protocol. But it was also mentioned that many femto cell implementations = rely today on NTP protocol. The meeting was adjourned around 1915.=20 From yaakov_s@rad.com Wed Aug 26 04:45:56 2009 Return-Path: X-Original-To: tictoc@core3.amsl.com Delivered-To: tictoc@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C64263A6960 for ; Wed, 26 Aug 2009 04:45:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.37 X-Spam-Level: X-Spam-Status: No, score=-1.37 tagged_above=-999 required=5 tests=[AWL=-1.372, BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ShuQkwgS9zq2 for ; Wed, 26 Aug 2009 04:45:54 -0700 (PDT) Received: from antivir1.rad.co.il (mx1-q.rad.co.il [80.74.100.136]) by core3.amsl.com (Postfix) with ESMTP id D123F3A68C6 for ; Wed, 26 Aug 2009 04:45:50 -0700 (PDT) Received: from exrad4.ad.rad.co.il ([192.114.24.47]) by antivir1.rad.co.il with ESMTP; 26 Aug 2009 14:36:52 +0300 Received: from exrad4.ad.rad.co.il ([192.114.24.47]) by exrad4.ad.rad.co.il ([192.114.24.47]) with mapi; Wed, 26 Aug 2009 14:36:51 +0300 From: Yaakov Stein To: "tictoc@ietf.org" Date: Wed, 26 Aug 2009 14:36:50 +0300 Thread-Topic: [TICTOC] Adding the Femto Synchronization requirments in requirement document Thread-Index: Acol8nx71Zd+kaTVQmi2/KMS4fDIfgATvikQ Message-ID: <48E7911F78327A449A9FB956376672861DDFD9AF@exrad4.ad.rad.co.il> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_48E7911F78327A449A9FB956376672861DDFD9AFexrad4adradcoil_" MIME-Version: 1.0 Subject: [TICTOC] FW: Adding the Femto Synchronization requirments in requirement document X-BeenThere: tictoc@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Timing over IP Connection and Transfer of Clock BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Aug 2009 11:45:56 -0000 --_000_48E7911F78327A449A9FB956376672861DDFD9AFexrad4adradcoil_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable From: Xie Lei To: tictoc@ietf.org Sent: Wednesday, August 26, 2009 9:50 AM Subject: [TICTOC] Adding the Femto Synchronization requirments in requireme= nt document Dear All As the agreement in IETF75# meeting, we decide to add the femto synchroniza= tion requirements in requirement document. After checking the requirement d= ocument, i think, the best way is to add a new section as following: 3.2.1 Cellular Backhauling of Femtocells Femtocell application may use a portion of the public and private network i= nfrastructure to provide connectivity and backhaul service between the femt= ocell device and gateway. The use of a public network facility implies that= some level of network security is necessary, as compared to the scenarios = presented in Section 3.1.1.x which assumed that the connectivity and backha= ul service is done over a private network (eg., see Note (2)), typically fo= r macrocell application. In addition the number of femtocell devices can ea= sily extend to hundreds of thousands, much higher than the number of macroc= ells. The following requirements should be considered for femtocell deploym= ents: 1. The use of IPSec links in the public network could degrade the transpo= rt of synchronization message and its performance. In order to reduce the i= mpact to synchronization when traversing secured links, it is possible to l= eave some of the synchronization message unprotected. Caution should take p= lace on the use of IPSec and synchronization performance 2. Synchronization messages traversing Network Address Translation (NAT) = functions need to be considered in order to guarantee proper connectivity b= etween a Clock Server and the femtocell device 3. Scalability aspects (large number of femtocells), bandwidth consumptio= n of synchronization messages and the placement of clock servers are to be = considered as the network architecture is developed. Please give your comments on these words, Thanks Best Regards Rock --_000_48E7911F78327A449A9FB956376672861DDFD9AFexrad4adradcoil_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

From: Xie Lei

Sent: Wednesday, August 26, 2009 9:50 AM

Subject:= [TICTOC] Adding the Femto Synchronization requir= ments in requirement document

 

 

Dear All

As the agreement in IETF75# meeting, we decide to add the femto synchronizatio= n requirements in requirement document. After checking the requirement docume= nt, i think, the best way is to add a new section as following:

 

 

3.2= .1 Cellular Backhauling of Femtocells

 

Fem= tocell application may use a portion of the public and private network infrastruct= ure to provide connectivity and backhaul service between the femtocell device a= nd gateway. The use of a public network facility implies that some level of network security is necessary, as compared to the scenarios presented in Section 3.1.1.x which assumed that the connectivity and backhaul service is done over a private network (eg., see Note (2)), typically for macrocell application. In addition the number of femtocell devices can easily extend = to hundreds of thousands, much higher than the number of macrocells. The follo= wing requirements should be considered for femtocell deployments:

 

  1. The use of IPSec links in the public network cou= ld degrade the transport of synchronization message and its performance. = In order to reduce the impact to synchronization when traversing secured links, it is possible to leave some of the synchronization message unprotected. Caution should take place on the use of IPSec and synchronization performance
  2. Synchronization messages traversing Network Addr= ess Translation (NAT) functions need to be considered in order to guarante= e proper connectivity between a Clock Server and the femtocell device
  3. Scalability aspects (large number of femtocells)= , bandwidth consumption of synchronization messages and the placement of clock servers are to be considered as the network architecture is developed.

Please give your comments on these words, Thanks

 

Best Regards

Rock

--_000_48E7911F78327A449A9FB956376672861DDFD9AFexrad4adradcoil_-- From stefano.ruffini@ericsson.com Fri Aug 28 04:20:32 2009 Return-Path: X-Original-To: tictoc@core3.amsl.com Delivered-To: tictoc@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 46F073A6B2E for ; Fri, 28 Aug 2009 04:20:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.248 X-Spam-Level: X-Spam-Status: No, score=-6.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xc9+JoM0g9FP for ; Fri, 28 Aug 2009 04:20:30 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 067813A68F8 for ; Fri, 28 Aug 2009 04:20:29 -0700 (PDT) X-AuditID: c1b4fb3e-b7b24ae000003bbc-23-4a97bd83821a Received: from esealmw129.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id CF.B3.15292.38DB79A4; Fri, 28 Aug 2009 13:20:35 +0200 (CEST) Received: from EITRMMW021.eemea.ericsson.se ([141.137.48.176]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Fri, 28 Aug 2009 13:20:34 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA27D1.8F1B8B69" Date: Fri, 28 Aug 2009 13:20:32 +0200 Message-ID: <7D33CA0905CE1443BADA4BD279ACFC6006DFAC6B@EITRMMW021.eemea.ericsson.se> In-Reply-To: <48E7911F78327A449A9FB956376672861DDFD9AF@exrad4.ad.rad.co.il> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TICTOC] FW: Adding the Femto Synchronization requirments in requirement document Thread-Index: Acol8nx71Zd+kaTVQmi2/KMS4fDIfgATvikQAGKFpLA= References: <48E7911F78327A449A9FB956376672861DDFD9AF@exrad4.ad.rad.co.il> From: "Stefano Ruffini" To: "Yaakov Stein" , X-OriginalArrivalTime: 28 Aug 2009 11:20:34.0720 (UTC) FILETIME=[8FC54A00:01CA27D1] X-Brightmail-Tracker: AAAAAA== Subject: Re: [TICTOC] FW: Adding the Femto Synchronization requirments in requirement document X-BeenThere: tictoc@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Timing over IP Connection and Transfer of Clock BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2009 11:20:32 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA27D1.8F1B8B69 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Yaakov,=20 =20 I would suggests few updates to your proposals also based on some = comments that were made in Stockholm on this subject: =20 1. The femtocells application can be based on one of the technologies = already mentioned in 3.1.1 (and in fact the 250 ppb requirement which is = related to home base stations, which is the way 3GPP calls the = femtocell, is already mentioned in this section). In order to avoid misunderstanding, the new section could be called = 3.1.2, "Specific aspects related to Femtocells application".=20 Some rephrasing in the introductory text might also be needed (e.g. = remove "presented in Section 3.1.1.x " as scenarios that assume private = network). The Notes related to "Private Networks" could be updated as follows: Note 2: assumes a private network, (this may not be true in case of = femtocells) =20 2. The first point on IPSEC is based on still quite vague considerations = (no real study or test has been presented on this topic showing the = actual degradation). I would suggest to be more generic , for instance = saying that the impacts on performances due to IPSEC are under study. =20 3. Regarding alternative solution to IPSEC perhaps rather than refer to = "secure links" (which in case needs to be clarified), it seems more = appropriate to refer to existing solutions (e.g. built in = authentication) =20 The above comments would results in updating the text as follows: " =20 3.1 Cellular Backhauling ... 3.1.1 Cellular Backhauling Requirements ..... =20 3.1.2 Specific aspects related to the Femtocells application =20 Femtocell application may use a portion of the public and private = network infrastructure to provide connectivity and backhaul service = between the femtocell device and gateway. The use of a public network = facility implies that some level of network security is necessary, as = compared to the scenarios which assume that the connectivity and = backhaul service is done over a private network (eg., see Note (2)), = typically for macrocell application. In addition the number of femtocell = devices can easily extend to hundreds of thousands, much higher than the = number of macrocells. The following requirements should be considered = for femtocell deployments: 1. The impact of the use of IPSec links in the public network on the = transport of synchronization message and its performance is under study. = Alternative means to guarantee that timing messages are securely = delivered to the femtocells base stations might be considered (e.g. = built in authentication).=20 2. Synchronization messages traversing Network Address Translation (NAT) = functions need to be considered in order to guarantee proper = connectivity between a Clock Server and the femtocell device=20 3. Scalability aspects (large number of femtocells), bandwidth = consumption of synchronization messages and the placement of clock = servers are to be considered as the network architecture is developed. =20 3.1.3 Cellular Backhaul Requirements Summary ... " =20 Best Regards Stefano =20 ________________________________ From: tictoc-bounces@ietf.org [mailto:tictoc-bounces@ietf.org] On Behalf = Of Yaakov Stein Sent: mercoled=EC 26 agosto 2009 13.37 To: tictoc@ietf.org Subject: [TICTOC] FW: Adding the Femto Synchronization requirments in = requirement document From: Xie Lei =20 To: tictoc@ietf.org=20 Sent: Wednesday, August 26, 2009 9:50 AM Subject: [TICTOC] Adding the Femto Synchronization requirments in = requirement document =20 =20 Dear All As the agreement in IETF75# meeting, we decide to add the femto = synchronization requirements in requirement document. After checking the = requirement document, i think, the best way is to add a new section as = following: =20 =20 3.2.1 Cellular Backhauling of Femtocells =20 Femtocell application may use a portion of the public and private = network infrastructure to provide connectivity and backhaul service = between the femtocell device and gateway. The use of a public network = facility implies that some level of network security is necessary, as = compared to the scenarios presented in Section 3.1.1.x which assumed = that the connectivity and backhaul service is done over a private = network (eg., see Note (2)), typically for macrocell application. In = addition the number of femtocell devices can easily extend to hundreds = of thousands, much higher than the number of macrocells. The following = requirements should be considered for femtocell deployments: =20 1. The use of IPSec links in the public network could degrade the = transport of synchronization message and its performance. In order to = reduce the impact to synchronization when traversing secured links, it = is possible to leave some of the synchronization message unprotected. = Caution should take place on the use of IPSec and synchronization = performance=20 2. Synchronization messages traversing Network Address Translation (NAT) = functions need to be considered in order to guarantee proper = connectivity between a Clock Server and the femtocell device=20 3. Scalability aspects (large number of femtocells), bandwidth = consumption of synchronization messages and the placement of clock = servers are to be considered as the network architecture is developed.=20 Please give your comments on these words, Thanks =20 Best Regards Rock ------_=_NextPart_001_01CA27D1.8F1B8B69 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi=20 Yaakov,
 
I=20 would suggests few updates to your proposals also based on some comments = that=20 were made in Stockholm on this subject:
 
1. The=20 femtocells application can be based on one of the = technologies already=20 mentioned in 3.1.1 (and in fact the 250 ppb requirement which is related = to home=20 base stations, which is the way 3GPP calls the femtocell,  is = already=20 mentioned in this section).
 In order to avoid misunderstanding, =  the new=20 section  could be called 3.1.2, "Specific aspects related to=20 Femtocells application".
Some=20 rephrasing in the introductory text might also be needed (e.g. remove = "presented in Section 3.1.1.x " as scenarios that = assume=20 private network).
The=20 Notes related to "Private Networks" could be updated as=20 follows:
Note=20 2: assumes a private network, (this may = not be true=20 in case of femtocells)
 
2. The=20 first point on IPSEC is based on still quite vague considerations (no = real study=20 or test has been presented on this topic showing the actual = degradation). I=20 would suggest to be more generic ,  for instance saying that the = impacts on=20 performances due to IPSEC are under study.
 
3.=20 Regarding alternative solution to IPSEC perhaps rather than refer to = "secure=20 links" (which in case needs to be clarified), it seems more appropriate = to refer=20 to existing solutions (e.g. built in authentication)
 
The=20 above comments would results in updating the text as=20 follows:
"
 
3.1 = Cellular=20 Backhauling
...
3.1.1 Cellular Backhauling = Requirements
.....
 

3.1.2 Specific aspects=20 related to the Femtocells=20 application

 

Femtocell=20 application may use a portion of the public and private network = infrastructure=20 to provide connectivity and backhaul service between the femtocell = device and=20 gateway. The use of a public network facility implies that some level of = network=20 security is necessary, as compared to the scenarios which assume that = the=20 connectivity and backhaul service is done over a private network (eg., = see Note=20 (2)), typically for macrocell application. In addition the number of = femtocell=20 devices can easily extend to hundreds of thousands, much higher than the = number=20 of macrocells. The following requirements should be considered for = femtocell=20 deployments:

  1. The impact of = the use=20 of IPSec links in the public network on the transport of=20 synchronization message and its performance is under study. Alternative means to guarantee that = timing=20 messages are securely delivered to the femtocells base stations might = be=20 considered (e.g. built in=20 authentication).
  2. Synchronization=20 messages traversing Network Address Translation (NAT) functions need = to be=20 considered in order to guarantee proper connectivity between a Clock = Server=20 and the femtocell device
  3. Scalability aspects=20 (large number of femtocells), bandwidth consumption of synchronization = messages and the placement of clock servers are to be considered as = the=20 network architecture is developed.
 
3.1.3 Cellular = Backhaul=20 Requirements Summary
...
"
 
Best=20 Regards
Stefano
 
From: tictoc-bounces@ietf.org = [mailto:tictoc-bounces@ietf.org]=20 On Behalf Of Yaakov Stein
Sent: mercoled=EC 26 agosto = 2009=20 13.37
To: tictoc@ietf.org
Subject: [TICTOC] FW: = Adding the=20 Femto Synchronization requirments in requirement = document

From: = Xie Lei=20

Sent: Wednesday, August 26, 2009 9:50=20 AM

Subject: [TICTOC] Adding the Femto Synchronization = requirments in=20 requirement document

 

 =20

Dear=20 All

As the = agreement in=20 IETF75# meeting, we decide to add the femto synchronization requirements = in=20 requirement document. After checking the requirement document, i think, = the best=20 way is to add a new section as following:

 

 

3.2.1=20 Cellular Backhauling of Femtocells

 

Femtocell=20 application may use a portion of the public and private network = infrastructure=20 to provide connectivity and backhaul service between the femtocell = device and=20 gateway. The use of a public network facility implies that some level of = network=20 security is necessary, as compared to the scenarios presented in Section = 3.1.1.x=20 which assumed that the connectivity and backhaul service is done over a = private=20 network (eg., see Note (2)), typically for macrocell application. In = addition=20 the number of femtocell devices can easily extend to hundreds of = thousands, much=20 higher than the number of macrocells. The following requirements should = be=20 considered for femtocell deployments:

 

  1. The use = of IPSec=20 links in the public network could degrade the transport of = synchronization=20 message and its performance. In order to reduce the impact to = synchronization=20 when traversing secured links, it is possible to leave some of the=20 synchronization message unprotected. Caution should take place on the = use of=20 IPSec and synchronization performance
  2. Synchronization=20 messages traversing Network Address Translation (NAT) functions need = to be=20 considered in order to guarantee proper connectivity between a Clock = Server=20 and the femtocell device
  3. Scalability aspects=20 (large number of femtocells), bandwidth consumption of synchronization = messages and the placement of clock servers are to be considered as = the=20 network architecture is developed.

Please=20 give your comments on these words, Thanks

 

Best=20 Regards

Rock

= ------_=_NextPart_001_01CA27D1.8F1B8B69-- From yaakov_s@rad.com Mon Aug 31 04:07:10 2009 Return-Path: X-Original-To: tictoc@core3.amsl.com Delivered-To: tictoc@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C8503A69C2 for ; Mon, 31 Aug 2009 04:07:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.256 X-Spam-Level: X-Spam-Status: No, score=-1.256 tagged_above=-999 required=5 tests=[AWL=-1.258, BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id grwk0AAoixSs for ; Mon, 31 Aug 2009 04:07:07 -0700 (PDT) Received: from antivir2.rad.co.il (mx2-q.rad.co.il [80.74.100.144]) by core3.amsl.com (Postfix) with ESMTP id 5E5383A6A86 for ; Mon, 31 Aug 2009 04:07:02 -0700 (PDT) Received: from exrad4.ad.rad.co.il ([192.114.24.47]) by antivir2.rad.co.il with ESMTP; 31 Aug 2009 14:07:12 +0300 Received: from exrad4.ad.rad.co.il ([192.114.24.47]) by exrad4.ad.rad.co.il ([192.114.24.47]) with mapi; Mon, 31 Aug 2009 14:07:11 +0300 From: Yaakov Stein To: Stefano Ruffini , "tictoc@ietf.org" Date: Mon, 31 Aug 2009 14:07:09 +0300 Thread-Topic: [TICTOC] FW: Adding the Femto Synchronization requirments in requirement document Thread-Index: Acol8nx71Zd+kaTVQmi2/KMS4fDIfgATvikQAGKFpLAAl4Vq4A== Message-ID: <48E7911F78327A449A9FB956376672861DEFE579@exrad4.ad.rad.co.il> References: <48E7911F78327A449A9FB956376672861DDFD9AF@exrad4.ad.rad.co.il> <7D33CA0905CE1443BADA4BD279ACFC6006DFAC6B@EITRMMW021.eemea.ericsson.se> In-Reply-To: <7D33CA0905CE1443BADA4BD279ACFC6006DFAC6B@EITRMMW021.eemea.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_48E7911F78327A449A9FB956376672861DEFE579exrad4adradcoil_" MIME-Version: 1.0 Subject: Re: [TICTOC] FW: Adding the Femto Synchronization requirments in requirement document X-BeenThere: tictoc@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Timing over IP Connection and Transfer of Clock BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Aug 2009 11:07:10 -0000 --_000_48E7911F78327A449A9FB956376672861DEFE579exrad4adradcoil_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Stefano I like your idea of treating femtocells by adding a new subsection. Note that while the Iuh interface indeed has important security considerati= ons, the Iub interface is also almost always encrypted. In any case, the importa= nt issue here is to note the security requirements. The middlebox issue is an important one, which needs to be noted. There will also be different scalability concerns, as a FGW needs to handle many more femtocells than an RNC needs to handle NodeBs. Y(J)S From: Stefano Ruffini [mailto:stefano.ruffini@ericsson.com] Sent: Friday, August 28, 2009 14:21 To: Yaakov Stein; tictoc@ietf.org Subject: RE: [TICTOC] FW: Adding the Femto Synchronization requirments in r= equirement document Hi Yaakov, I would suggests few updates to your proposals also based on some comments = that were made in Stockholm on this subject: 1. The femtocells application can be based on one of the technologies alrea= dy mentioned in 3.1.1 (and in fact the 250 ppb requirement which is related= to home base stations, which is the way 3GPP calls the femtocell, is alre= ady mentioned in this section). In order to avoid misunderstanding, the new section could be called 3.1.= 2, "Specific aspects related to Femtocells application". Some rephrasing in the introductory text might also be needed (e.g. remove = "presented in Section 3.1.1.x " as scenarios that assume private network). The Notes related to "Private Networks" could be updated as follows: Note 2: assumes a private network, (this may not be true in case of femtoce= lls) 2. The first point on IPSEC is based on still quite vague considerations (n= o real study or test has been presented on this topic showing the actual de= gradation). I would suggest to be more generic , for instance saying that = the impacts on performances due to IPSEC are under study. 3. Regarding alternative solution to IPSEC perhaps rather than refer to "se= cure links" (which in case needs to be clarified), it seems more appropriat= e to refer to existing solutions (e.g. built in authentication) The above comments would results in updating the text as follows: " 3.1 Cellular Backhauling ... 3.1.1 Cellular Backhauling Requirements ..... 3.1.2 Specific aspects related to the Femtocells application Femtocell application may use a portion of the public and private network i= nfrastructure to provide connectivity and backhaul service between the femt= ocell device and gateway. The use of a public network facility implies that= some level of network security is necessary, as compared to the scenarios = which assume that the connectivity and backhaul service is done over a priv= ate network (eg., see Note (2)), typically for macrocell application. In ad= dition the number of femtocell devices can easily extend to hundreds of tho= usands, much higher than the number of macrocells. The following requiremen= ts should be considered for femtocell deployments: 1. The impact of the use of IPSec links in the public network on the tran= sport of synchronization message and its performance is under study. Altern= ative means to guarantee that timing messages are securely delivered to the= femtocells base stations might be considered (e.g. built in authentication= ). 2. Synchronization messages traversing Network Address Translation (NAT) = functions need to be considered in order to guarantee proper connectivity b= etween a Clock Server and the femtocell device 3. Scalability aspects (large number of femtocells), bandwidth consumptio= n of synchronization messages and the placement of clock servers are to be = considered as the network architecture is developed. 3.1.3 Cellular Backhaul Requirements Summary ... " Best Regards Stefano ________________________________ From: tictoc-bounces@ietf.org [mailto:tictoc-bounces@ietf.org] On Behalf Of= Yaakov Stein Sent: mercoled=EC 26 agosto 2009 13.37 To: tictoc@ietf.org Subject: [TICTOC] FW: Adding the Femto Synchronization requirments in requi= rement document From: Xie Lei To: tictoc@ietf.org Sent: Wednesday, August 26, 2009 9:50 AM Subject: [TICTOC] Adding the Femto Synchronization requirments in requireme= nt document Dear All As the agreement in IETF75# meeting, we decide to add the femto synchroniza= tion requirements in requirement document. After checking the requirement d= ocument, i think, the best way is to add a new section as following: 3.2.1 Cellular Backhauling of Femtocells Femtocell application may use a portion of the public and private network i= nfrastructure to provide connectivity and backhaul service between the femt= ocell device and gateway. The use of a public network facility implies that= some level of network security is necessary, as compared to the scenarios = presented in Section 3.1.1.x which assumed that the connectivity and backha= ul service is done over a private network (eg., see Note (2)), typically fo= r macrocell application. In addition the number of femtocell devices can ea= sily extend to hundreds of thousands, much higher than the number of macroc= ells. The following requirements should be considered for femtocell deploym= ents: 1. The use of IPSec links in the public network could degrade the transpo= rt of synchronization message and its performance. In order to reduce the i= mpact to synchronization when traversing secured links, it is possible to l= eave some of the synchronization message unprotected. Caution should take p= lace on the use of IPSec and synchronization performance 2. Synchronization messages traversing Network Address Translation (NAT) = functions need to be considered in order to guarantee proper connectivity b= etween a Clock Server and the femtocell device 3. Scalability aspects (large number of femtocells), bandwidth consumptio= n of synchronization messages and the placement of clock servers are to be = considered as the network architecture is developed. Please give your comments on these words, Thanks Best Regards Rock --_000_48E7911F78327A449A9FB956376672861DEFE579exrad4adradcoil_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Stefano

 

I like your idea of treating femtocells by adding a new subsection.

 

Note that while the Iuh interface indeed has important secur= ity considerations,

the Iub interface is also almost always encrypted. In any ca= se, the important issue

here is to note the security requirements.=

 

The middlebox issue is an important one, which needs to be noted.

 

There will also be different scalability concerns, as a FGW needs to handle

many more femtocells than an RNC needs to handle NodeBs.

 

Y(J)S

 

From: Stefano Ruffi= ni [mailto:stefano.ruffini@ericsson.com]
Sent: Friday, August 28, 2009 14:21
To: Yaakov Stein; tictoc@ietf.org
Subject: RE: [TICTOC] FW: Adding the Femto Synchronization requirmen= ts in requirement document

 

Hi Yaakov,

=  

I would suggests few updates to your proposals also based on so= me comments that were made in Stockholm on this subject:

=  

1. The femtocells application can be based on one of the technologies already mentioned in 3.1.1 (and in fact the 250 ppb requirement which is related to home base stations, which is the way 3GPP c= alls the femtocell,  is already mentioned in this section).

 In order to avoid misunderstanding,  the new section  could be called 3.1.2, "Specific aspects related to Femtocells application".

Some rephrasing in the introductory text might also be needed (= e.g. remove "presented in Section 3.1.1.x " as scenarios that assum= e private network).The Notes related to "Private Networks" could be upda= ted as follows:

Note 2: assumes a private network, (this may not be true in case of femtocells)

=  

2. The first point on IPSEC is based on still quite vague considerations (no real study or test has been presented on this topic show= ing the actual degradation). I would suggest to be more generic ,  for instance saying that the impacts on performances due to IPSEC are under stu= dy.

=  

3. Regarding alternative solution to IPSEC perhaps rather than refer to "secure links" (which in case needs to be clarified), it seems more appropriate to refer to existing solutions (e.g. built in authentication)

=  

The above comments would results in updating the text as follow= s:

"

=  

3.1 Cellular Backhauling

...

3.1.1 Cellular Backhauling Requirements

.....=  

3.1.2= Spec= ific aspects related to the Femtocells application

 

Fem= tocell application may use a portion of the public and private network infrastruct= ure to provide connectivity and backhaul service between the femtocell device a= nd gateway. The use of a public network facility implies that some level of network security is necessary, as compared to the scenarios which assume th= at the connectivity and backhaul service is done over a private network (eg., = see Note (2)), typically for macrocell application. In addition the number of femtocell devices can easily extend to hundreds of thousands, much higher t= han the number of macrocells. The following requirements should be considered f= or femtocell deployments:

 

  1. The impact of the use of IP= Sec links in the public network on the transport of synchronization message and its performance is under study. Alternative means to guarantee that timing messages are securely delivered to the femtocells base stations might be considered (e.g. built in authentication).
  2. Synchronization messages traversing Network Addr= ess Translation (NAT) functions need to be considered in order to guarante= e proper connectivity between a Clock Server and the femtocell device
  3. Scalability aspects (large number of femtocells)= , bandwidth consumption of synchronization messages and the placement of clock servers are to be considered as the network architecture is developed.

 

3.1.3 Cellular Backhaul Requirements Summary

...

"

=  

Best Regards

Stefano

=  

From: tictoc-bounces@ietf.org [mailto:tictoc-bounces@ietf.org] On Behalf Of Yaakov Stein
Sent: mercoled=EC 26 agosto 2009 13.37
To: tictoc@ietf.org
Subject: [TICTOC] FW: Adding the Femto Synchronization requirments i= n requirement document

From: Xie Lei

Sent: Wednesday, August 26, 2009 9:50 AM

Subject:= [TICTOC] Adding the Femto Synchronization requir= ments in requirement document

 

 

Dear All

As the agreement in IETF75# meeting, we decide to add the femto synchronizatio= n requirements in requirement document. After checking the requirement docume= nt, i think, the best way is to add a new section as following:

 

 

3.2= .1 Cellular Backhauling of Femtocells

 

Fem= tocell application may use a portion of the public and private network infrastruct= ure to provide connectivity and backhaul service between the femtocell device a= nd gateway. The use of a public network facility implies that some level of network security is necessary, as compared to the scenarios presented in Section 3.1.1.x which assumed that the connectivity and backhaul service is done over a private network (eg., see Note (2)), typically for macrocell application. In addition the number of femtocell devices can easily extend = to hundreds of thousands, much higher than the number of macrocells. The follo= wing requirements should be considered for femtocell deployments:

 

  1. The use of IPSec links in the public network cou= ld degrade the transport of synchronization message and its performance. = In order to reduce the impact to synchronization when traversing secured links, it is possible to leave some of the synchronization message unprotected. Caution should take place on the use of IPSec and synchronization performance
  2. Synchronization messages traversing Network Addr= ess Translation (NAT) functions need to be considered in order to guarante= e proper connectivity between a Clock Server and the femtocell device
  3. Scalability aspects (large number of femtocells)= , bandwidth consumption of synchronization messages and the placement of clock servers are to be considered as the network architecture is developed.

Please give your comments on these words, Thanks

 

Best Regards

Rock

--_000_48E7911F78327A449A9FB956376672861DEFE579exrad4adradcoil_-- From mayer@ntp.org Mon Aug 31 19:44:37 2009 Return-Path: X-Original-To: tictoc@core3.amsl.com Delivered-To: tictoc@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 133A028C378 for ; Mon, 31 Aug 2009 19:44:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.147 X-Spam-Level: X-Spam-Status: No, score=-6.147 tagged_above=-999 required=5 tests=[AWL=0.452, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RBUKBrOkUv2E for ; Mon, 31 Aug 2009 19:44:36 -0700 (PDT) Received: from mail2.ntp.org (mail2.ntp.org [204.152.184.138]) by core3.amsl.com (Postfix) with ESMTP id 3E30128C36D for ; Mon, 31 Aug 2009 19:44:36 -0700 (PDT) Received: from firewall.antoniuk.lan (mail.antoniuk.md [65.86.158.146]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail2.ntp.org (Postfix) with ESMTP id 94DD6398E1; Tue, 1 Sep 2009 02:44:45 +0000 (UTC) (envelope-from mayer@ntp.org) Received: from cust-63-209-236-168.bos-dynamic.gis.net ([63.209.236.168] helo=[10.10.10.100]) by firewall.antoniuk.lan with esmtpsa (SSL3.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1MiJMI-00027m-Vb; Mon, 31 Aug 2009 22:44:35 -0400 Message-ID: <4A9C8A88.2070506@ntp.org> Date: Mon, 31 Aug 2009 22:44:24 -0400 From: Danny Mayer Organization: NTP User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Yaakov Stein References: <48E7911F78327A449A9FB956376672861DDFD9AF@exrad4.ad.rad.co.il> In-Reply-To: <48E7911F78327A449A9FB956376672861DDFD9AF@exrad4.ad.rad.co.il> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-kostecke.net-MailScanner: Found to be clean X-kostecke.net-MailScanner-From: mayer@ntp.org Cc: "tictoc@ietf.org" Subject: Re: [TICTOC] FW: Adding the Femto Synchronization requirments in requirement document X-BeenThere: tictoc@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mayer@ntp.org List-Id: Timing over IP Connection and Transfer of Clock BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2009 02:44:37 -0000 Yaakov Stein wrote: > *From:* Xie Lei > > *To:* tictoc@ietf.org > > *Sent:* Wednesday, August 26, 2009 9:50 AM > > *Subject:* [TICTOC] Adding the Femto Synchronization requirments in > requirement document > > > > > > Dear All > > As the agreement in IETF75# meeting, we decide to add the femto > synchronization requirements in requirement document. After checking the > requirement document, i think, the best way is to add a new section as > following: > > 3.2.1 Cellular Backhauling of Femtocells > > Femtocell application may use a portion of the public and private > network infrastructure to provide connectivity and backhaul service > between the femtocell device and gateway. The use of a public network > facility implies that some level of network security is necessary, as > compared to the scenarios presented in Section 3.1.1.x which assumed > that the connectivity and backhaul service is done over a private > network (eg., see Note (2)), typically for macrocell application. In > addition the number of femtocell devices can easily extend to hundreds > of thousands, much higher than the number of macrocells. The following > requirements should be considered for femtocell deployments: > > 1. The use of IPSec links in the public network could degrade the > transport of synchronization message and its performance. In order > to reduce the impact to synchronization when traversing secured > links, it is possible to leave some of the synchronization message > unprotected. Caution should take place on the use of IPSec and > synchronization performance The use of IPSec *will* degrade any NTP packet and I don't expect that any TICTOC packet will be able to do better over IPSec. There is also the issue of the security part requiring each end to have accurate time in the first place defeats the purpose of this. > 2. Synchronization messages traversing Network Address Translation > (NAT) functions need to be considered in order to guarantee proper > connectivity between a Clock Server and the femtocell device NAT destroys the capability of any possibility of verifying the IP address of the sender. You need to disallow NAT devices or provide another way of passing the packets through the device. > 3. Scalability aspects (large number of femtocells), bandwidth > consumption of synchronization messages and the placement of clock > servers are to be considered as the network architecture is > developed. > NTP seems to have no problens with scalability so I cannot imagine what new issue would arise that what be any different. Danny -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.