Subject: Re: [TICTOC] FW: Adding the Femto Synchronization requirments inrequirement document

From: Xie Lei <[email-masked]>
Date: Wed, 02 Sep 2009 19:29:04 +0800

Hi Stefano
I agree that we need more test on the degradation of IPSEC. The words , i think, should specify the vague part of how to using IPSec in synchroinzation, i would suggest add little more words as following in bullet one:

1:The impact of the use of IPSec links in the public network on the transport of partial or whole synchronization messages 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). 

Regards
Rock

----- Original Message ----- 
  From: Stefano Ruffini 
  To: Yaakov Stein ; [email-masked] 
  Sent: Friday, August 28, 2009 7:20 PM
  Subject: Re: [TICTOC] FW: Adding the Femto Synchronization requirments inrequirement 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 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". 
  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)

  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.

  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 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 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). 
    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 
    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: [email-masked] [mailto:[email-masked]] On Behalf Of Yaakov Stein
  Sent: mercoledì 26 agosto 2009 13.37
  To: [email-masked]
  Subject: [TICTOC] FW: Adding the Femto Synchronization requirments in requirement document

  From: Xie Lei 

  To: [email-masked] 

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

------------------------------------------------------------------------------

  _______________________________________________
  TICTOC mailing list
  [email-masked]
  https://www.ietf.org/mailman/listinfo/tictoc

---

From: Yaakov Stein <[email-masked]>
Date: Tue, 8 Sep 2009 07:00:25 +0300

> NTP seems to have no problens with scalability so I cannot imagine what
> new issue would arise that what be any different.

That is because NTP servers do not maintain client state.

Not all timing distribution protocols have that characteristic.

Y(J)S