RE: [TICTOC] Clock metrics in timing packets versus OAM

[[e-mail]]

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: [phone]           Fax:  [phone]

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


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




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


> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
> Sent: mardi 23 octobre 2007 19:03
> To: STUART VENTERS
> Cc: [e-mail]
> 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
>                                        <[e-mail]>
>
>              10/23/2007 04:34
>           cc
>              PM                        <[e-mail]>
>
>
>      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: [e-mail] [mailto:[e-mail]]
> Sent: Tuesday, October 23, 2007 4:43 AM
> To: [e-mail]
> Cc: [e-mail]
> Subject: [TICTOC] Re: TICTOC Digest, Vol 15, Issue 6
>
>
> 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          [e-mail]
>              PM
>           cc
>
>
>      Subject
>              Please respond to         TICTOC Digest, Vol 15, Issue 6
>               [e-mail]
>
>
>
>
>
>
>
>
>
> Send TICTOC mailing list submissions to
>              [e-mail]
>
> 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
>              [e-mail]
>
> You can reach the person managing the list at
>              [e-mail]
>
> 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" <[e-mail]>
> Subject: RE: [TICTOC] preparatory material for new TICTOC charter
> To: "Yaakov Stein" <[e-mail]>
> Cc: [e-mail]
> Message-ID:
>
> <[e-mail]>
> 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:[e-mail]]
> Sent: Monday, October 22, 2007 12:20 PM
> To: [e-mail]
> 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
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/tictoc
>
>
> End of TICTOC Digest, Vol 15, Issue 6
> *************************************
>
>
>
> _______________________________________________
> TICTOC mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/tictoc
>
>
>
> _______________________________________________
> TICTOC mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/tictoc
>



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