Subject: [TICTOC] Re: TICTOC Digest, Vol 15, Issue 6

From: [email-masked]
Date: Tue, 23 Oct 2007 10:42:39 +0100

Stuart,
You've asked a good question about what is SSM about. SSM always looks like
it can do more than it was designed for, and this is causing some
confusion. SSM has its limitations and it cannot be used for advanced
things like automatically building timing trails - although such things
were proposed, there just wasn't the bandwidth available in the frame.
We'll have to find some other way to do that, and although it may be
loosely linked in with SSM it would be separate from it. Just remember that
SSM only indicates the quality of the sync source currently at the head of
a timing path. It's a way of passing information about a remote timing node
that can't be obtained by inspecting the signal being received (for
example, to a downstream SEC, the quality of a signal timed by an SSU in
holdover would be indistinguishable from one being timed by a PRC - the SSM
tells the SEC what the quality is so that it can compare this trail with
alternatives). The SSM supplements other info that can be obtained locally,
such as LOS, OOF, AIS, all of which are used to disqualify a timing trail.
That's all the SSM can do, really.  Forgive me if I'm going over old
ground.
Now, if we can all agree just what additional information would be needed
for advanced features, then this info could be made available, but it would
be separate from and in addition to the SSM info itself. Points 2 and 3 in
the list in Yaakov's email mention autodiscovery and topology discovery, so
whatever information is needed for these would have to be made available -
but these would be separate to the SSM value.
We would also have to agree the best way to present this extra info - OAM
springs to mind, but is this the only/best way? Personally, I think so. The
ITU have decided to carry SSMs in a slow protocol defined for OAM purposes,
and there is plenty of space in the message for other info. So, the same
messages that are used to carry SSM values could be used to carry
additional info for building timing trails, and so on - but this is not an
additional burden on the SSM flow, and we should strive to keep SSM
separate from these things. (How we relate TICTOC to the ITU is TDB, I
guess.)
Overall, then, we may find that an OAM flow is used for points 2,3 and 4,
but SSM is kept as it is. Note, I'm avoiding the issue of possibly making
SSM obsolete if we have access to other info...that's a topic for later.

Taking up your other point about performance, I think it's important from
day one to recognise that different applications will have different
performance requirements. Maybe each application will need some sort of
individual profile? We will have to define the various performance
requirements in some way (MTIE, TDEV masks? Anything else?). Your point 2
is very important - we should recognise that some network conditions will
be too severe to support the performance requirements. I think this should
be used as part of the timing-trail-selection mechanism so that an
alternative timing path can be selected when the current one goes outside
an agreed behaviour limit. Ultimately, though, this may not be sufficient
to guarantee good timing paths are available, and we may eventually have to
go the traditional way and impose PDV limits on each network element (ie,
switch/router) - that should be fun.

Getting back to metrics, the ITU are also active here, with network
behaviour metrics currently being looked at. By the way (and pardon me for
advertising) but there will be a few presentations on these metrics at the
ITSF next month, if anyone wants to see what's involved
(http://conferences.theiet.org/itsf/).

Cheers
Dave

             tictoc-request@ie                                             
             tf.org                                                        
                                                                        To 
             10/22/2007 07:22          [email-masked]                     
             PM                                                         cc 
                                                                           
                                                                   Subject 
             Please respond to         TICTOC Digest, Vol 15, Issue 6      
              [email-masked]                                              

Send TICTOC mailing list submissions to
             [email-masked]

To subscribe or unsubscribe via the World Wide Web, visit
             https://www1.ietf.org/mailman/listinfo/tictoc
or, via email, send a message with subject or body 'help' to
             [email-masked]

You can reach the person managing the list at
             [email-masked]

When replying, please edit your Subject line so it is more specific
than "Re: Contents of TICTOC digest..."

Today's Topics:

   1. RE:  preparatory material for new TICTOC charter (STUART VENTERS)

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

Message: 1
Date: Mon, 22 Oct 2007 13:18:05 -0500
From: "STUART VENTERS" <[email-masked]>
Subject: RE: [TICTOC] preparatory material for new TICTOC charter
To: "Yaakov Stein" <[email-masked]>
Cc: [email-masked]
Message-ID:

<[email-masked]>
Content-Type: text/plain;            charset="iso-8859-1"

Yaakov,

Looks great overall, I just have a couple of minor nits.

Is SSM about management, automatic clock routing, or more likely both?
  (Although I don't know how to handle it better,
    I'm wondering if mentioning SSM with 4, but not 2 and 3 is misleading.)

Should performance measurement be broken into 2 parts?
    1) Performance of the time/freq reference provided by TICTOC
    2) Performance required from the network TICTOC is running over.

Regards,

Stuart

-----Original Message-----
From: Yaakov Stein [mailto:[email-masked]]
Sent: Monday, October 22, 2007 12:20 PM
To: [email-masked]
Subject: [TICTOC] preparatory material for new TICTOC charter

Hi all,

Today Stewart, Karen and I discussed Mark's request to
quickly focus on which of the "modules" need be in scope for the potential
WG.

We have come up with the following deliverables,
broken down into two phases
(times in parentheses are months from chartering of WG).

Phase 1:

0.  Architecture draft (based on modularization draft)       (INFO)    (6)
1.1 requirements for time/frequency distribution protocol(s) (INFO)    (9)
1.2 analysis of existing protocols in light of 1.1           (INFO)   (12)
1.3 selection and documentation of distribution protocol(s)  (STD)    (24)
2   Autodiscovery (including security aspects)               (STD)    (12)
3   Topology discovery (including security aspects)          (STD)    (24)

Phase 2:

4 OAM including SSM                                          (STD)    (30)
5 Performance measurement                                    (STD)    (33)
6 Ranging techniques                                         (BCP)    (36)
7 MIBs                                                       (STD)    (30)

Additional work, such as BCPs for various algorithms,
detailed requirements for specific applications (e.g. cellular backhaul),
and research topics such as globally converging classless methods,
will be developed based on interest and participation.

We would appreciate feedback from the list on the choice of
milestones, and the times allotted.

Y(J)S

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

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

End of TICTOC Digest, Vol 15, Issue 6
*************************************

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

---

From: "STUART VENTERS" <[email-masked]>
Date: Tue, 23 Oct 2007 10:32:09 -0500

Dave,

Thanks for the reply. I'd like to understand this old ground a little better.
(It sounds a bit like a minefield ;-)

I agree with you that having SSM alone is not sufficient to choose clock paths.
Some additional information is required. (Perhaps a path metric and a priority or source ID,
 which NTP may have in the Precision, Dispersion, and RefID fields.)
The additional bandwidth seems meager compared to the advantage of knowing quickly when an input changes.
If there is a general feeling that quick is not good and so this function should be OAM, then I'd like to better understand it.

I do agree that some functions, like tracing out the clock tree would be fine as OAM.

Regards,

Stuart

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Tuesday, October 23, 2007 4:43 AM
To: [email-masked]
Cc: [email-masked]
Subject: [TICTOC] Re: TICTOC Digest, Vol 15, Issue 6

Stuart,

Cheers
Dave

             tictoc-request@ie                                             
             tf.org                                                        
                                                                        To 
                                                                           
                                                                   Subject 

Today's Topics:

Message: 1

Yaakov,

Regards,

Stuart

-----Original Message-----
From: Yaakov Stein [mailto:[email-masked]]
Sent: Monday, October 22, 2007 12:20 PM
To: [email-masked]
Subject: [TICTOC] preparatory material for new TICTOC charter

Hi all,

Phase 1:

Phase 2:

Y(J)S

---

From: [email-masked]
Date: Tue, 23 Oct 2007 18:03:27 +0100

Hi Stuart,
Looks like I misled you a little. When I said there was no bandwidth for
extra info, I was referring to the TDM frames (DS1, E1, SONET, SDH). For
example, only 4 bits were allocated to carrying the SSM value in SONET/SDH.
Of course, since we got 8000 frames a second, we got 32kbps of SSM (which
had a static 4-bit value for 99.9999....% of the time!), but, in the
interests of design simplicity, it was better to have a value which was
repeated every frame rather than, say, build a more complex message over a
multiframe. Hence, we only got 4 bits to carry info and this had to be
devoted to the SSM value. But it also meant we could detect a new SSM value
very quickly, even when the SSM value was occasionally corrupted, and this
allowed us to react fast when we needed to (given that the new SSM value
may have to go through many nodes before it hit one that was timed from a
better clock). It works well in those circumstances when it works, but it
cannot solve all our problems (it can't fix timing loops all by itself, for
example, so it's not much use in an automated timing path build process -
that little limitation keeps sync engineers in business, of course).

In packet networks, we will only get a few packets per second, but we can
make the most of them because they include error-checking so we can trust
the info they carry, and so we can still get a fast enough response. But we
only use 4 bits out of the packet to carry the SSM value, so there's plenty
of room for new stuff. I know the ITU have adopted the slow protocol for
the OAM specifically for Synchronous Ethernet, but I can't see any reason
why it can't be used for other things - so long as it stays hop-by-hop. If
we want to use the same packet for extra info, then it would be tidier if
we can come up with a name for this packet which does not appear to tie it
too much to SSM.....the problem is, for example, if we call it the SSM
packet, we may confuse future generations when we start to add extra info
in there which is not SSM related. We need a more general-purpose name
which tells you the packet carries sync-related info, of which a part is
SSM. But don't call it a sync packet! Or a Sync Status Message either! Any
ideas?

The sort of info that I've heard proposed to help automatic path builds
include physical location of PRCs, number of hops to the PRC, and port IDs,
but there will be lots more when we get going. Some things might be a bit
esoteric, but we could accommodate them if we have a flexible approach to
the packet layout - such as using TLVs. Same sort of thing for the timing
metrics. The timing metrics could change the priority of each path
dynamically - if a path became too noisy, for example, it could be demoted.
We can do the same thing at the moment - if a path becomes noisy or clock
recovery produces an erratic clock, the path can be demoted.

Best wishes,

dave

             "STUART VENTERS"                                              
             <stuart.venters@a                                             
             dtran.com>                                                 To 
                                       <[email-masked]>                
             10/23/2007 04:34                                           cc 
             PM                        <[email-masked]>                   
                                                                   Subject 
                                       RE: [TICTOC] Clock metrics in       
                                       timing packets versus OAM           

                                                                           

Dave,

Thanks for the reply. I'd like to understand this old ground a little
better.
(It sounds a bit like a minefield ;-)

I agree with you that having SSM alone is not sufficient to choose clock
paths.
Some additional information is required. (Perhaps a path metric and a
priority or source ID,
 which NTP may have in the Precision, Dispersion, and RefID fields.)
The additional bandwidth seems meager compared to the advantage of knowing
quickly when an input changes.
If there is a general feeling that quick is not good and so this function
should be OAM, then I'd like to better understand it.

I do agree that some functions, like tracing out the clock tree would be
fine as OAM.

Regards,

Stuart

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Tuesday, October 23, 2007 4:43 AM
To: [email-masked]
Cc: [email-masked]
Subject: [TICTOC] Re: TICTOC Digest, Vol 15, Issue 6

Stuart,

Cheers
Dave

             tictoc-request@ie
             tf.org
                                                                        To

                                                                   Subject

Today's Topics:

Message: 1

Yaakov,

Regards,

Stuart

-----Original Message-----
From: Yaakov Stein [mailto:[email-masked]]
Sent: Monday, October 22, 2007 12:20 PM
To: [email-masked]
Subject: [TICTOC] preparatory material for new TICTOC charter

Hi all,

Phase 1:

Phase 2:

Y(J)S

---

From: "Laurent Montini (lmontini)" <[email-masked]>
Date: Wed, 24 Oct 2007 11:13:25 +0200

Hi Dave,

Another way to look at SSM.

Actually SSM in SONET/SDH carries a value, the QL (Quality Level) value.

Change of QL value is part of clock selection process.
If SSM is limited to QL value in SONET/SDH, it does not mean it should
for packet network.
For SyncE, we still talk about SSM or ESSM but it was agreed we should
be able to add field extensions. 
The ESSM slow protocol provides this capability. ESSM will have one
mandatory "QL field" and could have other fields (like source ID, hop
count from source, ...).

Another idea would thus be to consider the term SSM "Synchronization
Status Messaging" for a channel providing messages about synchronization
network status or condition and not SSM := QL.

Did I miss something from the old world? :-)

Cheers,
.lm

> Sent: mardi 23 octobre 2007 19:03
> To: STUART VENTERS
> Cc: [email-masked]
> Subject: RE: [TICTOC] Clock metrics in timing packets versus OAM
> 
> Hi Stuart,
> Looks like I misled you a little. When I said there was no 
> bandwidth for extra info, I was referring to the TDM frames 
> (DS1, E1, SONET, SDH). For example, only 4 bits were 
> allocated to carrying the SSM value in SONET/SDH.
> Of course, since we got 8000 frames a second, we got 32kbps 
> of SSM (which had a static 4-bit value for 99.9999....% of 
> the time!), but, in the interests of design simplicity, it 
> was better to have a value which was repeated every frame 
> rather than, say, build a more complex message over a 
> multiframe. Hence, we only got 4 bits to carry info and this 
> had to be devoted to the SSM value. But it also meant we 
> could detect a new SSM value very quickly, even when the SSM 
> value was occasionally corrupted, and this allowed us to 
> react fast when we needed to (given that the new SSM value 
> may have to go through many nodes before it hit one that was 
> timed from a better clock). It works well in those 
> circumstances when it works, but it cannot solve all our 
> problems (it can't fix timing loops all by itself, for 
> example, so it's not much use in an automated timing path 
> build process - that little limitation keeps sync engineers 
> in business, of course).
> 
> In packet networks, we will only get a few packets per 
> second, but we can make the most of them because they include 
> error-checking so we can trust the info they carry, and so we 
> can still get a fast enough response. But we only use 4 bits 
> out of the packet to carry the SSM value, so there's plenty 
> of room for new stuff. I know the ITU have adopted the slow 
> protocol for the OAM specifically for Synchronous Ethernet, 
> but I can't see any reason why it can't be used for other 
> things - so long as it stays hop-by-hop. If we want to use 
> the same packet for extra info, then it would be tidier if we 
> can come up with a name for this packet which does not appear 
> to tie it too much to SSM.....the problem is, for example, if 
> we call it the SSM packet, we may confuse future generations 
> when we start to add extra info in there which is not SSM 
> related. We need a more general-purpose name which tells you 
> the packet carries sync-related info, of which a part is SSM. 
> But don't call it a sync packet! Or a Sync Status Message 
> either! Any ideas?
> 
> The sort of info that I've heard proposed to help automatic 
> path builds include physical location of PRCs, number of hops 
> to the PRC, and port IDs, but there will be lots more when we 
> get going. Some things might be a bit esoteric, but we could 
> accommodate them if we have a flexible approach to the packet 
> layout - such as using TLVs. Same sort of thing for the 
> timing metrics. The timing metrics could change the priority 
> of each path dynamically - if a path became too noisy, for 
> example, it could be demoted.
> We can do the same thing at the moment - if a path becomes 
> noisy or clock recovery produces an erratic clock, the path 
> can be demoted.
> 
> Best wishes,
> 
> dave
> 
> 
>                                                               
>              
>              "STUART VENTERS"                                 
>              
>              <stuart.venters@a                                
>              
>              dtran.com>                                       
>           To 
>                                        <[email-masked]>   
>              
>              10/23/2007 04:34                                 
>           cc 
>              PM                        <[email-masked]>      
>              
>                                                               
>      Subject 
>                                        RE: [TICTOC] Clock 
> metrics in       
>                                        timing packets versus 
> OAM           
>                                                               
>              
>                                                               
>              
>                                                               
>              
>                                                               
>              
>                                                               
>              
>                                                               
>              
> 
> 
> 
> 
> Dave,
> 
> Some additional information is required. (Perhaps a path 
> metric and a priority or source ID,  which NTP may have in 
> the Precision, Dispersion, and RefID fields.) The additional 
> bandwidth seems meager compared to the advantage of knowing 
> If there is a general feeling that quick is not good and so 
> this function should be OAM, then I'd like to better understand it.
> 
> You've asked a good question about what is SSM about. SSM 
> always looks like it can do more than it was designed for, 
> and this is causing some confusion. SSM has its limitations 
> and it cannot be used for advanced things like automatically 
> building timing trails - although such things were proposed, 
> there just wasn't the bandwidth available in the frame.
> We'll have to find some other way to do that, and although it 
> may be loosely linked in with SSM it would be separate from 
> it. Just remember that SSM only indicates the quality of the 
> sync source currently at the head of a timing path. It's a 
> way of passing information about a remote timing node that 
> can't be obtained by inspecting the signal being received 
> (for example, to a downstream SEC, the quality of a signal 
> timed by an SSU in holdover would be indistinguishable from 
> one being timed by a PRC - the SSM tells the SEC what the 
> quality is so that it can compare this trail with 
> alternatives). The SSM supplements other info that can be 
> obtained locally, such as LOS, OOF, AIS, all of which are 
> used to disqualify a timing trail.
> That's all the SSM can do, really.  Forgive me if I'm going 
> over old ground.
> Now, if we can all agree just what additional information 
> would be needed for advanced features, then this info could 
> be made available, but it would be separate from and in 
> addition to the SSM info itself. Points 2 and 3 in the list 
> in Yaakov's email mention autodiscovery and topology 
> discovery, so whatever information is needed for these would 
> have to be made available - but these would be separate to 
> the SSM value.
> We would also have to agree the best way to present this 
> extra info - OAM springs to mind, but is this the only/best 
> way? Personally, I think so. The ITU have decided to carry 
> SSMs in a slow protocol defined for OAM purposes, and there 
> is plenty of space in the message for other info. So, the 
> same messages that are used to carry SSM values could be used 
> to carry additional info for building timing trails, and so 
> on - but this is not an additional burden on the SSM flow, 
> and we should strive to keep SSM separate from these things. 
> (How we relate TICTOC to the ITU is TDB, I
> guess.)
> Overall, then, we may find that an OAM flow is used for 
> points 2,3 and 4, but SSM is kept as it is. Note, I'm 
> avoiding the issue of possibly making SSM obsolete if we have 
> access to other info...that's a topic for later.
> 
> Taking up your other point about performance, I think it's 
> important from day one to recognise that different 
> applications will have different performance requirements. 
> Maybe each application will need some sort of individual 
> profile? We will have to define the various performance 
> requirements in some way (MTIE, TDEV masks? Anything else?). 
> Your point 2 is very important - we should recognise that 
> some network conditions will be too severe to support the 
> performance requirements. I think this should be used as part 
> of the timing-trail-selection mechanism so that an 
> alternative timing path can be selected when the current one 
> goes outside an agreed behaviour limit. Ultimately, though, 
> this may not be sufficient to guarantee good timing paths are 
> available, and we may eventually have to go the traditional 
> way and impose PDV limits on each network element (ie,
> Getting back to metrics, the ITU are also active here, with 
> network behaviour metrics currently being looked at. By the 
> way (and pardon me for
> advertising) but there will be a few presentations on these 
> metrics at the ITSF next month, if anyone wants to see what's 
> involved (http://conferences.theiet.org/itsf/).
> 
> Cheers
> Dave
> 
> 
> 
> 
>              tictoc-request@ie
>              tf.org
>                                                               
>           To
>              PM                                               
>           cc
> When replying, please edit your Subject line so it is more 
> specific than "Re: Contents of TICTOC digest..."
> 
> 
> Today's Topics:
> 
> quickly focus on which of the "modules" need be in scope for 
> the potential WG.
> 
> We have come up with the following deliverables, broken down 
> into two phases (times in parentheses are months from 
> chartering of WG).
> 
> Phase 1:
> 
> 7 MIBs                                                       
> (STD)    (30)
> detailed requirements for specific applications (e.g. 
> cellular backhaul), and research topics such as globally 
> converging classless methods, will be developed based on 
> interest and participation.
>

---

From: [email-masked]
Date: Wed, 24 Oct 2007 11:08:08 +0100

Hi Laurent,
OK, on the wire, the SSM represents the QL value of the selected source.
But there are QL values which will never be seen on the wire, QL-INVx,
QL-FAILED, etc - these are internal QL values which exist only inside the
network element. The QL used internally in the selection process is arrived
at by combining the SSM value with other quality indicators like LOS, LOF
and AIS. LOS and LOF are generated by the receiver and exist only within
the network element, and this is why the QL can only exist inside the
network element. But the outgoing SSM value still indicates the
quality/accuracy/stability of the timing source that the network element is
locked to (however distant it is) - unless, of course, you want to make
sure the line is not selected for timing by a downstream network element
(then, SSM = DNU). With a 4-bit field, there just aren't enough hex values
to represent all the possible QL values - are you saying we could carry the
whole QL value in a packet-based method? The QL values themselves are left
to the implementers (they can't be 4-bit values anymore), so we'd have to
specify something else. What would we gain?
Since the term SSM has been used for years to carry the QL value, I'd warn
against using it for a new channel or things will really get confusing. We
need a new name for this channel.

Cheers
Dave

Semtech Ltd
Office address:  2-3 Park Court, Premier Way, Abbey Park Ind Est, Romsey,
SO51 9DN
Tel: +44 (0)1794 527600           Fax:  +44 (0)1794 527601

Registered office: 4th Floor, Saltire Court, 20 Castle Terrace, Edinburgh,
EH1 2EN
Registered in Scotland 53259
VAT No. GB572685604

             "Laurent Montini                                              
             (lmontini)"                                                   
             <[email-masked]                                          To 
             om>                       <[email-masked]>                
                                                                        cc 
             10/24/2007 10:15          <[email-masked]>, "STUART VENTERS" 
             AM                        <[email-masked]>         
                                                                   Subject 
                                       RE: [TICTOC] Clock metrics in       
                                       timing packets versus OAM           

                                                                           

Hi Dave,

Cheers,
.lm