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

[[e-mail]]

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