Subject: [TICTOC] comments on draft-ji-tictoc-1588-telecom-profile-framework-01.txt

From: Kurt Erik Lindqvist <[email-masked]>
Date: Tue, 11 Mar 2008 19:32:50 +0100

So now that there is a working group I guess it's time to start  
discussing the work items and documents.....

So, some comments on the above mentioned draft. First of all, it seems  
'a bit' premature to start with the 1588 profile already given that a  
lot of the WG work items before that are not posted, discussed or even  
adopted by the working-group...

Comments in-line below. There are a bit to many missing references to  
really fully comment on all parts of the doc.

Best regards,

- kurtis -

 >
 >1. Introduction
 >
 >   There are various telecommunications applications that can
 >   potentially be supported by methods of timing distribution. Timing
 >   distribution includes frequency, phase and time synchronization. In
 >   this document we only consider phase or time synchronization
 >   (they may need frequency synchronization also).
 >
 >   To allow IEEE-1588 to satisfy the need(s) of the applications
 >   requiring timing, it is necessary to ensure that all IEEE-1588
 >   capable devices have the features and performance to support the
 >   applications at the appropriate level.  That is, the timing
 >   distribution method must be fit-for-purpose. It's necessary to  
define
 >   a telecom profile immediately.

I think that you want to be a bit more explicit that is document only
applies to applications run over a topolgy that possibly includes 1588
support, i,e an Ethernet topology. That might be obivous but it's more
or less common practice in IETF docs to make the Introduction include
enought background that even someone not familiar with the area
understands the applicability of the document. But that is a pure
style comment.

 >   Some of the considerations in developing the profile are described
 >   below include:
 >
 >      -- Requirement
 >
 >      -- Interface
 >
 >      -- Modeling
 >
 >      -- TOD Distribution
 >
 >2. Requirement
 >
 >   Various of applications in telecom need different kinds of
 >   synchronization. At first, it's important to provide some  
explanatory
 >   information about it. Of course the profile and solution should  
suit
 >   them. ITU-T Recommendation G.8261/Y.1362 summarizes some of it.

This is what appears as a normative reference and then should be
listed as such and must be made available. Or you should enumerate the
issues here.

 >
 >               2.1. Wireless
 >
 >   Within this general use-case category there are several  
applications
 >   of importance. The application, from the viewpoint of timing, is to
 >   deliver the appropriate timing information to a base station (e.g.
 >   Node B).

I interpret Wireless a lot wider than just the cases listed below. I
think you need to describe the sub-set of wireless applications that
requires 'timing' The next issue is 'timing'. I am not convinced that
the terminology 'timing' as used elsewhere in TICTOC documents is
really what you mean and is also quite ambigious. It's a lot more
specific below.

 >2.1.1. CDMA2000 Base Station (frequency and time synchronization)
 >
 >   The relevant CDMA2000 standards are the 3GPP2 C.S0010-B and 3GPP2 C
 >   S0002-B.

Neeeds references.

 >   According to the CDMA2000 specifications the average frequency
 >   difference between the actual CDMA transmit carrier frequency and
 >
 >
 >Ji                     Expires August 3, 2008                 [Page 3]
 >
 >Internet-Draft  IEEE1588V2 telecom profile framework     February 2008
 >
 >
 >   specified CDMA transmit frequency assignment shall be less than 50
 >   ppb.
 >
 >   In the CDMA2000 specifications it is also specified that each base
 >   station shall use a time base reference that is time-aligned to  
CDMA
 >   System Time.  CDMA System Time is synchronous to UTC time (except  
for
 >   leap seconds) and uses the same time origin as GPS time.  All base
 >   stations use the same System Time (within a small error tolerance).
 >   For all base stations, the pilot time alignment error should be  
less
 >   than 3us and shall be less than 10us.

The above does not parse. Is it 3us or 10us? 'less than' and 'shall'
are not really IETF terminology. I suspect you mean MUST for one of
the two values.

 >   Because of the above requirements it is a common practice to equip
 >   CDMA base stations with GPS receivers.
 >
 >2.1.2. UMTS TDD Base Station (frequency and phase synchronization)
 >
 >   The timing requirement applicable to the WCDMA TDD radio interface
 >   can be found in the technical specification TS 125.105 [B5].
 >
 >   The radio interface requirement for UMTS TDD base stations is a
 >   frequency accuracy of 50ppb; for the TDD mode there is the
 >   additional requirement for the phase alignment of neighboring base
 >   stations to within 2.5us.
 >
 >   Note: GSM and UMTS FDD require the frequency accuracy to be less
 >   than 50ppB, but no need for phase alignment.

I miss a clear definition of what the requirement here is? MUST be
2.5us and 50ppb?

 >2.1.3. TD-SCDMA Base Station (frequency and phase synchronization)
 >
 >   The timing requirement applicable to the TD-SCDMA radio interface  
can
 >   be found in the technical specification 3GPP TR 25.836.

Missing reference.

 >   The radio interface requirement for TD-SCDMA base stations is a
 >   frequency accuracy of 50ppb; there is the additional requirement  
for
 >   the phase alignment of neighboring base stations to within 3us  
(this
 >   requirement is then measured comparing the phase between adjacent
 >   Base Stations).
 >
 >   Because of the above requirements it is a common practice to equip
 >   TD-SCDMA base stations with GPS receivers.

Just spit out the requirement! :-)

 >   Note: the requirements listed in the previous clauses apply to the
 >   radio interface. When time or frequency reference is carried by the
 >   network, other requirements apply. These depend on several factors
 >   such as Radio Base Station oscillator characteristics, filter
 >   capability of the Radio Base Station, etc. As an example,
 >
 >
 >Ji                     Expires August 3, 2008                 [Page 4]
 >
 >Internet-Draft  IEEE1588V2 telecom profile framework     February 2008
 >
 >
 >   frequency accuracy significantly better than 50 ppb may be required
 >   for the reference timing signal carried over the network in case of
 >   50 ppb frequency accuracy requirement shall be fulfilled on the  
radio
 >   interface. The value of 16 ppb (ITU-T G.812 Type II frequency
 >   accuracy) has sometimes been mentioned. Similarly, in case accurate
 >   time and/or phase shall be distributed to the Radio Base Stations,
 >   the budget to be allocated to the network might be much smaller  
than
 >   the requirements defined by the wireless standards to be  
fulfilled on
 >   the radio interface. These aspects are for further study.
 >   The things we need to do is cooperation with these standard  
bodies to
 >   specify the phase/time requirement of Base Station network
 >   interface.

I am not convinced that this belongs in here. It does not really give
constraints needed for a profile. I would move it to an appendix - if
include it at all. It's seems more appropriate to discuss this in a
requirements document for timing in general.

 >
 >              2.2. Other domains
 >
 >   Besides wireless application there are other applications that need
 >   phase and/or time synchronization such as DVB, IPTV, etc.
 >   We propose to address wireless application first.

Why?

The WG is tasked with handling both on-path support and non-on path
support, as well as a generic use case. So I would gather the
requirements for applications - and in the case of the 1588 profile,
take the highest requirements and out that in the profile. You can't
just exclude applications and say we will deal with them later. At
least not without water tight reasoning.

 >
 >              2.3. Scenario
 >
 >       +---+---+
 >       | Time  |
 >       + Server+
 >       |       |
 >       +-------+
 >          /
 >         /
 >        /
 >    +--+--+             +--+--+     +----+----+
 >    |     |             |     |     | Base    |
 >    + NE  +-------------+ NE  +-----+ Station +
 >    |     |             |     |     |         |
 >    +-----+             +-----+     +---------+
 >       |                   |
 >       |                   |
 >       |                   |
 >    +--+--+             +--+--+
 >    |     |             |     |
 >    + NE  +-------------+ NE  +
 >    |     |             |     |
 >    +-----+             +-----+
 >       |                   |
 >       |                   |
 >       |                   |
 >    +----+----+         +----+----+
 >    | Base    |         | Base    |
 >    + Station +         + Station +
 >    |         |         |         |
 >    +---------+         +---------+
 >
 >                        Figure1. Wireless application

Nit pick : Network Elemens are not really IETF terminology...

 >Internet-Draft  IEEE1588V2 telecom profile framework     February 2008
 >
 >
 >   Figure 1 shows an example scenario for wireless application. Base
 >   stations get time information from server though backhaul network.
 >   Time server can be an SSU or be integrated in the RNC (BSC).

Spell out abbreviations and describe them.

 >3. Interface
 >
 >   As the Figure 1 shows, there are two important time interfaces
 >   we should consider. One is the interface between time server and
 >   NE (interface A). Another is the interface between Base station
 >   and NE (interface B).
 >
 >              3.1. Interface type
 >
 >   To transport time information, using the Ethernet interface like FE
 >   or GE using IEEE-1588V2 is a natural solution.

....if supported....

 >   2048 kbit/s or 1544 kbit/s interfaces defined in G.703 have been  
use
 >   for a long time for transport frequency information in telecom.  
Is it
 >   necessary to define such a standard time interface?

I not sure exactly what you mean here. I suspect that most deployment
scenarios will depend on available bandwidth, cost of equipment,
etc. I also suspect that today only FE and GigE are the options, while
10GigE is widelyused in aggregation. But that is not yet out to the
network edge, which your model above addresses.

 >              3.2. Performance
 >
 >   The requirements listed above apply to the radio interface in Base
 >   station. Interface B is network interface of Base station. It's
 >   necessary to talk about the requirement of interface B with  
different
 >   wireless standard body. Then we can specify the requirement of
 >   interface A. The budget between interface A and B is the
 >   specification for network equipments.

I am not sure I follow the logic above. Isn't the requirement of B
bounded by the statements in 2.3 above?

Which would the wirless standards body be?

 >4. Modeling
 >
 >   There was discussion on the email reflector about different  
solution.
 >   One key issue is whether or not to use IEEE-1588 on-pass support.
 >
 >              4.1. On-pass support
 >
 >   'IEEE-1588 on-pass support' means that every node in the
 >   synchroization chain from master to slave (server to client) can
 >   support IEEE-1588. Three situations are listed in sections 4.1.1,
 >   4.1.2 and 4.1.3.
 >
 >   In this case, many parameters are required to be specified in a
 >   profile, a list of them is proposed, but it is certainly not yet
 >   exhaustive.
 >
 >      -- Size of the network (number of NEs in a synchronization  
chain).
 >
 >
 >
 >Ji                     Expires August 3, 2008                 [Page 6]
 >
 >Internet-Draft  IEEE1588V2 telecom profile framework     February 2008
 >
 >
 >      -- Characteristic of clocks (bandwidth, tolerance,
 >      noise generation, etc.).
 >
 >      -- Types of IEEE-1588-V2 messages and packet rate.
 >
 >      -- Network Limits (see section 3.2).
 >
 >      -- Availability of a master clock protection mechanism (see
 >      section 5).
 >
 >4.1.1. Boundary Clock
 >
 >   The general concept of delivering time information by Boundary  
Clock
 >   (BC) modeling is given in Figure 2. There may be a number of BC  
nodes
 >   involved in the distribution of the reference time signal. In such
 >   cases, the synchronization function providing filtering and maybe
 >   holdover within these nodes must be able to recover time
 >   synchronization from master. Synchronization is transported one by
 >   one in a similar way to Synchronous Ethernet.
 >
 >       +----+----+       +--+---+       +--+---+       +----+----+
 >       | Time    |       |      |       |      |       |         |
 >       | Server M|<<--->>|S BC M|<<--->>|S BC M|<<--->>|S Client |
 >       |         |       |      |       |      |       |         |
 >       +---------+       +------+       +------+       +---------+
 >
 >                        Figure2. BC modeling
 >
 >   Note: It has been mentioned 1588 can be used combined with Sync-E.
 >   In this case, the different parameters need to be considered.
 >   Shall we consider it?

The figure is somewhat dense...:)

I also remember that there where a lot of pushback to the BC model in
Vancouver that is not addressed in the document.

 >Internet-Draft  IEEE1588V2 telecom profile framework     February 2008
 >
 >
 >4.1.2. End-to-End Transparent Clock
 >
 >   As shows in figure3, the End-to-End Transparent Clock (E2ETC) is
 >   totally different from Boundary Clock. Each E2ETC node involved in
 >   the distribution of the reference time signal doesn't need to
 >   synchronize to the master. They measure the residence time of PTP
 >   event messages (the time the message takes to traverse the
 >   transparent clock node). These residence times are accumulated in
 >   a special field -called Correction Field.
 >
 >       +----+----+       +--+---+       +--+---+       +----+----+
 >       | Time    |       |      |       |      |       |         |
 >       | Server M|<<--->>|T TC T|<<--->>|T TC T|<<--->>|S Client |
 >       |         ||     ||      ||     ^|      |       |         |
 >       +---------+|     |+------+|     ^+------+       +---------+
 >                  |     v        v     ^
 >                  |     v        v     |
 >                  |     +-+-+-+-+-+    |
 >                  |     | Resident|    |
 >                  |     | time    |    |
 >                  v     +-+-+-+-+-+    |
 >                  v      |             |
 >      +-+-+-+-+-+-+-+-+  |   +-+-+-+-+-+-+-+-+
 >      |    ......     |  |   |    ......     |
 >      |               |  |   |               |
 >      +-+-+-+-+-+-+-+-+  |   +-+-+-+-+-+-+-+-+
 >      | PTP paylaod   |  |   | PTP paylaod   |
 >      |               |  v   |               |
 >      +-+-+-+-+-+-+-+-+  v   +-+-+-+-+-+-+-+-+
 >      | Correction    |  v   | Correction    |
 >      | field         |>>+>>>| field         |
 >      +-+-+-+-+-+-+-+-+      +-+-+-+-+-+-+-+-+
 >      |    ......     |      |    ......     |
 >      |               |      |               |
 >      +-+-+-+-+-+-+-+-+      +-+-+-+-+-+-+-+-+
 >
 >                         Figure 3, E2ETC modeling
 >
 >4.1.3. Peer-To-Peer Transparent Clock
 >
 >   The Peer-To-Peer Transparent Clock (P2PTC) differs from the
 >   End-To-End Transparent Clock in the way that it computes the link
 >   delay in addition to the residence time delay. It uses the
 >   Pdelay_Req, Pdelay_Resp, and possibly Pdelay_Resp_Follow_Up  
messages
 >   to compute the link delay.
 >
 >   The P2PTC computes the link delay between two adjacent nodes.
 >   The appropriate Correction Field is updated for both the
 >
 >
 >
 >Ji                     Expires August 3, 2008                 [Page 8]
 >
 >Internet-Draft  IEEE1588V2 telecom profile framework     February 2008
 >
 >
 >   residence time of the message within the P2PTC nodes and for the  
link
 >   delay on the port receiving the message.
 >
 >   Note: performance may be improved if E2ETC or P2PTC nodes implement
 >   frequency synchronization similar to Ordinary Clocks (OC) or
 >   Synchronous  Ethernet.
 >
 >              4.2. No on-pass support
 >
 >   The second methods relies on time information such as IEEE-1588
 >   messages carried by the network without 1588 support (no BCs or  
TCs)
 >   as shown in Figure 5. In case the intermediate nodes does not have
 >   IEEE-1588 support especially where legacy equipment is used, this  
is
 >   the only alternative to achieve time synchronization.

I would not use the term legacy. It can also be network domains where
1588 support is simply not enabled.

I would also like to see the above rewritten to point out that this is
a deployment case where the choice have been made to use 1588 DESPITE
the lack of support.

 >   It's not necessary for the support of a network-wide 1588  
reference.
 >   Therefore the performance is highly impacted by Packet Delay
 >   Variation in the network.

....if or when that occurres. ..

 > In order to minimize the impact from the
 >   packet network, specific algorithms may need to be implemented at  
the
 >   slave side, depending on the required accuracy.

 >
 >   Note: One of the key points is network PDV for this situation which
 >   ITU-T Q13/SG15 is studying.

Reference missing, an not clear what this adds to the document.

 > IEEE-1588 relies on the symmetry of the
 >   network to recover ToD and/or phase, so the asymmetry of the  
network
 >   will affect performance and in this case it may be difficult to
 >   meet the time/phase synchronization for wireless applications. The
 >   support for synchronous Ethernet has to be considered as well.
 >   Synchronous Ethernet can be used to stabilize the local oscillator
 >   time base. In this case, the frequency is stable as it is recovered
 >   using Synchronous Ethernet and IEEE-1588 is used only for ToD and/ 
or
 >   phase.
 >
 >
 >
 >
 >Ji                     Expires August 3, 2008                [Page 10]
 >
 >Internet-Draft  IEEE1588V2 telecom profile framework     February 2008
 >
 >
 >              4.3. Hybrid
 >
 >   Hybrid Networks in this context represents networks where E2ETC
 >   and/or BC are used in conjunction with legacy equipments. It is a
 >   complex architecture, so. we propose to study it later.

Again, don't use the term legacy.

 >>5. Time Distribution
 >
 >   Distribution mechanism is very important for network time
 >   synchronization. BMC introduced in the IEEEE-1588V2 is a solution.
 >   RON Cohen's daft 'PTP over MPLS' is another good suggestion for  
time
 >   distribution in MPLS/IP network.

Missing reference.

 >   A list of aspects may be considered to specify a suitable
 >   telecom mechanism, but it is certainly not yet exhaustive.
 >
 >      -- Find the best grandmaster.

I believe we had a long discussion on service discovery in Vancouver
that could be referrenced.

 >
 >      -- Calculating the traceability paths if possible and path
 >      selection.
 >
 >      -- Building a tree like distribution (prevent timing-loop any
 >      time).
 >
 >      -- Fast switching when failure occurs to maintain a degree of
 >      performance.
 >
 >6. Security Considerations
 >
 >   An experimental security protocol is defined in [IEEE-1588v2]. The
 >   IEEE-1588v2 security extension and protocol provide group source
 >   authentication, message integrity, and replay attack protection for
 >   IEEE-1588 messages.

I would like to see more text on what the threat models are, and how
these are planned to be addressed.

'Experimental' won't go far in a sec-dir review :-)

 >      [1588v2]   IEEE, ''IEEE P1588/D2.2 Draft Standard for a  
Precision
 >                 Clock Synchronization Protocol for Networked
 >                 Measurement and Control Systems".
 >
 >      [G.8261]   ITU-T, "G.8261 - Timing and Synchronization aspects  
in
 >                 Packet Networks".

I am still missing access to these specs.

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

---

From: Stewart Bryant <[email-masked]>
Date: Tue, 11 Mar 2008 19:52:39 +0000

> listed as such and must be made available. Or you should enumerate the

ITU-T recommendations in force are now freely available from the ITU-T 
web site.

G.8261 is available here:

http://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-G.8261-200605-I!!PDF-E&type=items

Most of the ITU-T documents that TICTOC will need to consult are 
produced by ITU-T SG15 Q13. The path to SG15 documents is

http://www.itu.int/ITU-T/recommendations/index_sg.aspx?sg=15

and from there follow the tree.

- Stewart

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Tue, 11 Mar 2008 21:26:25 +0100

On 11 mar 2008, at 20.52, Stewart Bryant wrote:

>> >   information about it. Of course the profile and solution  
>> should  suit
> ITU-T recommendations in force are now freely available from the ITU- 
> T web site.
>

My point was that in IETF documents we list normative and non- 
normative references to make sure WHY a standard is listed. Not just  
mentioned in passing.

- kurtis -

---

From: "Laurent Montini (lmontini)" <[email-masked]>
Date: Tue, 11 Mar 2008 22:24:45 +0100

Hi,

Note the latest revision of G.8261 has been consented last Feb during
plenary ITU meeting.
This is the one listing some wireless requirements in Appendix VI.
However this version is not yet available on the ITU-T pages.

The revision of the ITU specifications (date of consent) should be added
in the reference.

.lm 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Stewart Bryant 
> (stbryant)
> Sent: mardi 11 mars 2008 15:53
> To: Kurt Erik Lindqvist
> Cc: [email-masked]
> Subject: Re: [TICTOC] commentson 
> draft-ji-tictoc-1588-telecom-profile-framework-01.txt
> 
> 
> >  >
> >  >2. Requirement
> >  >
> ITU-T recommendations in force are now freely available from 
> the ITU-T web site.
> 
> Most of the ITU-T documents that TICTOC will need to consult 
> are produced by ITU-T SG15 Q13. The path to SG15 documents is
>

---

From: jikuiwen 24438 <[email-masked]>
Date: Wed, 12 Mar 2008 15:40:13 -0400

Hi,

Please see my comments below.

Best regards
Jacky

----- 原邮件 -----
发件人: Kurt Erik Lindqvist <[email-masked]>
日期: 星期二, 三月 11日, 2008 下午2:32
主题: [TICTOC] comments on draft-ji-tictoc-1588-telecom-profile-framework-01.txt

> adopted by the working-group...

Yes, I agree with you that lots of fundamental work should be done in this WG. Actually I believe that “1588 telecom profile” is one of these fundamental works, it’s very important and urgent for time synchronization. This draft talks about some initial framework and consideration. It also lists some aspects we need to focus on, and we need deal with them one by one.

> >   potentially be supported by methods of timing distribution. 
> Timing >   distribution includes frequency, phase and time 
> synchronization. In

I will put the reference for people can easily understand.

> 
> >   Some of the considerations in developing the profile are 
> described >   below include:
> >
> >      -- Requirement
> >
> >      -- Interface
> >
> >      -- Modeling
> >
> >      -- TOD Distribution
> >
> >2. Requirement
> >
> should  

As Stewart and Laurent said, it is a reference from ITU-T Q13/15, it's better to add revision of the reference.

> >   deliver the appropriate timing information to a base station 
> (e.g. >   Node B).
> 

“Wireless” means lots of technologies. We list applications need time/phase and frenquence synchronization both.
The terminology issue will be resolved, in order to consistent with other TICTOC drafts.

> >   In the CDMA2000 specifications it is also specified that each 
> base >   station shall use a time base reference that is time-
> aligned to  
> CDMA
> >   leap seconds) and uses the same time origin as GPS time.  All 
> base >   stations use the same System Time (within a small error 
> tolerance). >   For all base stations, the pilot time alignment 
> error should be  
> less

In CDMA2000, GPS is used in Base Station due to the high accuracy requirement of time synchronization. When a Base Station gets GPS signal correctly, it should meet 3us requirement. In case of lossing GPS signal, it should meet 10us requirement for a few hours.

> >   Because of the above requirements it is a common practice to 
> equip >   CDMA base stations with GPS receivers.
> >
> >   The timing requirement applicable to the WCDMA TDD radio 
> interface >   can be found in the technical specification TS 
> 125.105 [B5].
> >
> >   additional requirement for the phase alignment of neighboring 
> base >   stations to within 2.5us.
> >

Yes. That’s a requirement.
 
> >   Because of the above requirements it is a common practice to 
> equip >   TD-SCDMA base stations with GPS receivers.
> 

Good suggestion. All the requirements will be listed.

> >   network, other requirements apply. These depend on several 
> factors >   such as Radio Base Station oscillator characteristics, 
> filter >   capability of the Radio Base Station, etc. As an example,
> >
> >
> >   frequency accuracy significantly better than 50 ppb may be 
> required >   for the reference timing signal carried over the 
> network in case of
> >   accuracy) has sometimes been mentioned. Similarly, in case 
> accurate >   time and/or phase shall be distributed to the Radio 
> Base Stations,

Right, it’s better to discuss this in a requirements document and can move it to appendix. I put it here just because we need to define the profile to satisfy the requirements.

> least not without water tight reasoning.

I think the wireless applications are quite clear and urgent, so I want to discuss them first. We may include all the applications.

> Nit pick : Network Elemens are not really IETF terminology...

Telecom industry use Network Element (NE) a lot. Maybe we should use “Node”?

> >   stations get time information from server though backhaul 
> network. >   Time server can be an SSU or be integrated in the RNC 
> (BSC).

Yes, good point.

> network edge, which your model above addresses.

Right, our goal is try to find a simply way to solve the problem. 10GE is included in “Ethernet interface”.

> >              3.2. Performance
> >
> >   The requirements listed above apply to the radio interface in 
> Base >   station. Interface B is network interface of Base 
> station. It's

See section 2.3, Interface A is the interface between Time Server and the Node, and Interface B is the interface between Base Station and the Node.
My intention is try to discuss the requirements of Interface B with other Wireless Standard Development Organizations, such as 3GPP, 3GPP2 etc. 

> >   involved in the distribution of the reference time signal. In 
> such >   cases, the synchronization function providing filtering 
> and maybe

What aspects you perfer to add to describe BC?

> >   Note: performance may be improved if E2ETC or P2PTC nodes 
> implement >   frequency synchronization similar to Ordinary Clocks 
> (OC) or
> >   Synchronous  Ethernet.
> >
> >              4.2. No on-pass support
> >
> >   as shown in Figure 5. In case the intermediate nodes does not 
> have >   IEEE-1588 support especially where legacy equipment is 
> used, this  
> is

Let's talk about it.

> >   Note: One of the key points is network PDV for this situation 
> which >   ITU-T Q13/SG15 is studying.
> 

It’s still under studying and there is no reference yet.

> >   Synchronous Ethernet can be used to stabilize the local 
> oscillator >   time base. In this case, the frequency is stable as 
> it is recovered
> >   synchronization. BMC introduced in the IEEEE-1588V2 is a 
> solution. >   RON Cohen's daft 'PTP over MPLS' is another good 
> suggestion for  
> time

http://www.ietf.org/internet-drafts/draft-ronc-ptp-mpls-00.txt

> that could be referrenced.

Right, what's your proposal? 

> 'Experimental' won't go far in a sec-dir review :-)

Got it! This section should be rewritten, and more security issues should be addressed here.

> I am still missing access to these specs.

******************************************************************************************
 This email and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or em
ail immediately and delete it!
 *****************************************************************************************

----- 原邮件 -----
发件人: "Laurent Montini (lmontini)" <[email-masked]>
日期: 星期二, 三月 11日, 2008 下午5:24
主题: Re: [TICTOC]	commentson draft-ji-tictoc-1588-telecom-profile-framework-01.txt

> The revision of the ITU specifications (date of consent) should be 
> addedin the reference.
> 
> .lm 
>

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Tue, 18 Mar 2008 23:29:12 +0100

> and from there follow the tree.

On this note, didn't we also in Vancouver talk about the need to make  
the 1588 standard available we are to do work on it?

- kurtis - / Who probably should go back and read what the notes say...
_______________________________________________
TICTOC mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tictoc

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 19 Mar 2008 11:49:09 +0000

Kurt Erik Lindqvist wrote:
>> ITU-T recommendations in force are now freely available from the 
>> ITU-T web site.
>>
Silvana

Do you have any idea what we can do to make this available?

Stewart

---

From: [email-masked]
Date: Wed, 19 Mar 2008 09:13:26 -0400

Stewart,

The draft standard for IEEE-1588 version 2 (P1588/D2.2 Jan 2008)  is 
available via the IEEE website via the following URL link.

http://ieeexplore.ieee.org/xpl/standards.jsp?findtitle=1588&letter=1588&opentree=on&imageField.x=7&imageField.y=6 

Note that this is still a draft standard, it is going through the final 
approval by IEEE RevCom. It is scheduled to be approved by March 26, 2008. 
After it is approved there may be editorial changes, but the editorial 
process from IEEE does not permit any technical change.

I am not sure if there is a process for IETF to ask IEEE for a copy. I 
will enquire John Eidson about that.
Best Regards,
Silvana

Stewart Bryant <[email-masked]> 
03/19/2008 07:49 AM
Please respond to
[email-masked]

To
Kurt Erik Lindqvist <[email-masked]>
cc
[email-masked], Silvana Rodrigues <[email-masked]>
Subject
Re: [TICTOC] comments on 
draft-ji-tictoc-1588-telecom-profile-framework-01.txt

Silvana

Stewart

----------
This email is confidential and may contain information that is privileged and
exempt from disclosure by law.  If you have received it in error, please contact
the sender immediately by return email and then delete it from your system; you
should not copy it or disclose its contents to anyone.  Emails are not secure
and cannot be guaranteed to be error free as they can be intercepted, amended,
lost or destroyed, or contain viruses.  Anyone who communicates with us by email
is taken to accept these risks.
_______________________________________________
TICTOC mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tictoc

---

From: Alexander Vainshtein <[email-masked]>
Date: Wed, 19 Mar 2008 16:01:04 +0200

Silvana,
I've tried the link from your email, it does not lead to the text of the
draft, only to its description.
 
Regards,
            Sasha

________________________________

	From: [email-masked] [mailto:[email-masked]]
On Behalf Of [email-masked]
	Sent: Wednesday, March 19, 2008 3:13 PM
	To: [email-masked]
	Cc: [email-masked]
	Subject: Re: [TICTOC] commentson
draft-ji-tictoc-1588-telecom-profile-framework-01.txt

	Stewart, 

	The draft standard for IEEE-1588 version 2 (P1588/D2.2 Jan 2008)
is available via the IEEE website via the following URL link. 

http://ieeexplore.ieee.org/xpl/standards.jsp?findtitle=1588&letter=1588&
opentree=on&imageField.x=7&imageField.y=6 
	
	Note that this is still a draft standard, it is going through
the final approval by IEEE RevCom. It is scheduled to be approved by
March 26, 2008. After it is approved there may be editorial changes, but
the editorial process from IEEE does not permit any technical change. 
	
	I am not sure if there is a process for IETF to ask IEEE for a
copy. I will enquire John Eidson about that. 

	Best Regards, 

	Silvana

	

03/19/2008 07:49 AM 
Please respond to
[email-masked]

To

should  
the 
	>> G.8261 is available here:
http://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-G.8261-200605-I!!
PDF-E&type=items 
	>> Most of the ITU-T documents that TICTOC will need to consult
are 
	Silvana

	Stewart

	
	----------
	This email is confidential and may contain information that is
privileged and
	exempt from disclosure by law.  If you have received it in
error, please contact
	the sender immediately by return email and then delete it from
your system; you
	should not copy it or disclose its contents to anyone.  Emails
are not secure
	and cannot be guaranteed to be error free as they can be
intercepted, amended,
	lost or destroyed, or contain viruses.  Anyone who communicates
with us by email
	is taken to accept these risks.

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 19 Mar 2008 14:15:21 +0000

Alexander Vainshtein wrote:
> Silvana,
> I've tried the link from your email, it does not lead to the text of 
> the draft, only to its description.
>  
> Regards,
>             Sasha
You need to be able to log onto the IEEE site to get the file. We need 
to find out if the IEEE will pre-release it to the IETF.

Stewart

---

From: Marshall Eubanks <[email-masked]>
Date: Wed, 19 Mar 2008 10:36:34 -0400

They should, if we need it, which I think clearly we do.

For IEEE 802, this is all pretty clear :

http://www.ietf.org/rfc/rfc4441.txt

1.2.  Access to IEEE 802 Archives

    Access to IEEE 802 standards more than six months old is provided
    free of charge on the IEEE 802 website via the Get IEEE 802 Program
    [GetIEEE-802].  Access to IEEE 802 work-in-progress has frequently
    arisen as an issue in cooperation between IETF and IEEE 802.  While
    in the past IETF Working Groups (WGs) have successfully negotiated
    access to IEEE 802 work-in-progress, each instance has been handled
    separately and took significant time and effort to complete.  In
    order to more easily enable document access for IETF WGs
    collaborating with IEEE 802, a liaison statement was sent to the  
IETF
    in July 2004 by Paul Nikolich, Chair of IEEE 802 [IEEE-802Liaison],
    describing the process by which IETF WGs can obtain access to IEEE
    802 work-in-progress.  IEEE 802 WG Chairs have the authority to  
grant
    membership in their WGs, and can use this authority to grant
    membership to an IETF WG chair upon request.  The IETF WG chair will
    be provided with access to the username/password for the IEEE 802 WG
    archives, and is permitted to share that information with
    participants in the IETF WG.  Since it is possible to participate in
    IETF without attending meetings, or even joining a mailing list,  
IETF
    WG chairs will provide the information to anyone who requests it.
    However, since IEEE 802 work-in-progress is copyrighted,
    incorporating material into IETF documents or posting the
    username/password on mailing lists or websites is not permitted.

However, I think that 1588 is not part of IEEE 802, so we may have to  
negotiate access.

I would start by talking to the IEEE 802 Liaison,
Bernard Aboba.

Regards
Marshall

---

From: [email-masked]
Date: Wed, 19 Mar 2008 14:55:43 -0400

Sasha,

You will need to log on to the IEEE to get the file. I have asked the 
chairman of 1588 if the IEEE would release a copy to IETF. I have not got 
a reply yet.

Best Regards,

Silvana

Alexander Vainshtein <[email-masked]> 
03/19/2008 10:01 AM

To
<[email-masked]>
cc
<[email-masked]>
Subject
RE: [TICTOC] commentson 
draft-ji-tictoc-1588-telecom-profile-framework-01.txt

Silvana,
 
Regards,
            Sasha

From: [email-masked] [mailto:[email-masked]] On Behalf 
Of [email-masked]
Sent: Wednesday, March 19, 2008 3:13 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [TICTOC] commentson 
draft-ji-tictoc-1588-telecom-profile-framework-01.txt

Stewart, 

Please respond to
[email-masked]

To

Silvana

Stewart

----------
This email is confidential and may contain information that is privileged 
and
exempt from disclosure by law.  If you have received it in error, please 
contact
the sender immediately by return email and then delete it from your 
system; you
should not copy it or disclose its contents to anyone.  Emails are not 
secure
and cannot be guaranteed to be error free as they can be intercepted, 
amended,
lost or destroyed, or contain viruses.  Anyone who communicates with us by 
email
is taken to accept these risks.

---

From: [email-masked]
Date: Thu, 20 Mar 2008 15:36:21 -0400

All,

I got a reply from John Eidson on this subject. 

To get a copy of the latest version of the 1588, the IETF needs to apply 
to the manager of standards licensing and contracts at the IEEE. 

The front page of the 1588 standard reads:

"Prior to submitting this document to another standards development 
organization for standardization activities, permission must first be 
obtained from the Manager, Standards Licensing and Contracts, IEEE 
Standards Activities Department. Other entities seeking permission to 
reproduce this document, in whole or in part, must obtain permission from 
the Manager, Standards Licensing and Contracts, IEEE Standards Activities 
Department.

 IEEE Standards Activities Department
 Standards Licensing and Contracts
445 Hoes Lane, P.O. Box 1331
Piscataway, NJ 08855-1331, USA"

Yaakov and Stewart, could you, please, follow up with the IEEE to get this 
permission?

Thanks,

Silvana

[email-masked] 
Sent by: [email-masked]
03/19/2008 02:55 PM

To
[email-masked]
Re: [TICTOC]    commentson 

Sasha, 

Best Regards, 

Silvana 

To

Silvana, 
  
Regards, 
            Sasha 

Stewart, 

Please respond to
[email-masked]

To

Silvana

Stewart

----------