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

[[e-mail]]

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