TICTOC Meeting at the 70th IETF, Tuesday, December 4, 2007. Timing over IP Connections and Transfer Of Clock Chairs: Yaakov Stein and Stewart Bryant Minute taker : Marshall Jabber scribe : Shane Shepherding AD : Mark Informal web site - www.dspcsp.com/tictoc ----- AGENDA - Agenda bashing - Introduction & Goals of meeting slides 15 min - What is a 1588 profile ? (Silvana) slides 15 min - Relationship between TICTOC and NTP (Karen) slides 15 min - Issues related to AD and TD and master selection (Stewart) slides 15 min - The three use cases (Yaakov) slides 15 min - Charter discussion unofficial web site 60 mins Yaakov : This is the second TICTOC BOF. We had a BOF previously in Prague. Let's quickly go over the agenda. After agenda bashing we will have a discussion of the goals of the meeting, and I can tell you that there is one goal for the meeting, which is to approve the charter Then we will discuss what a 1588 profile is and the relation between Tictoc and NDP. Then we will talk about auto-discovery and master clock discovery. By the way, when I say timing I mean frequency and / or time. We had a BOF in Prague that dealt with problem statements. What we attempted to accomplish then was to prove that there was an interesting problem, and that it is solvable. We then talked about other SDO's working on this problem, and then we had an open mic. At the Prague BOF, we had nearly total agreement on almost all points. People asked for more modularization, and we have written a modularization draft. What's happened since then ? We didn't have a BOF in Chicago. We have a mailing list which has been active. We have 4 and 1/2 drafts out there - the problem statement, the modularization draft, the framework draft and a synchronization draft. The half draft was send to PWE3, and deals with 1588 over pseudowires. The agenda today is very focused. However, in order to understand the charter, there are a few things we have to explain first - 1588 profiles - auto-discovery and master clock discovery - the three use cases. After that we will have discussion. I suggest we go to the first presentation, on 1588 profiles. ----- What is a 1588 profile ? (Silvana) Silvana Rodrigues : I work for Zarlink and I am going to talk about 1588 profiles. The first version of 1588 was finished in 2002 and was mostly designed for industrial automation. In 2003 we started informal meetings to address different use cases. In March 2005, the PAR was approved and we started to work on 1588 version 2. We are almost done and are just finishing the last drafts. Let's talk about telecom profiles. 1588 was developed for industrial automation, military, power industry, telecom, residential networks, etc.. With many users we had to define the defaults for a profile, as all of these users could not define one set of defaults. A profile is a set of options and requirements particular for a device. One thing that I want to stress is that a profile is attached to performance. You have to understand the performance needs for a profile. A profile could be developed by a SDO, a trade organization or even a company. What should a profile have ? A PTP profile should define - best master clock algorithms - configuration management options - path delay measurement options - delay request-response or peer delay - range and default values of all configurable attributes - transport mechanisms (Ethernet, UDP/IP) MPLS transport is not specified in 1588 and this as another area to which the IETF could contribute - node types supported - required/permitted options 1588 is extensible due to its use of TLVs. MIBS are not included in 1588 at all, and I can see that the IETF could contribute MIBS to 1588. I really think that we need more management mechanisms for 1588. In 1588 multicast is mandatory. But in a profile you can define a unicast model, or you can mix them. Today there are two profiles in 1588, but these profiles are probably not sufficient for telecoms. If you are only interested in frequency a profile would be needed for this. Last week at SG15 in the ITU Alcatel Lucent presented a contribution about the ITU developing 1588 profiles. At the ITU there are clear requirements that you have to follow. Other questions are what is the size of the network, the load on the network, what kind of network we are running ? Other things that were discussed - the 1588 network, does it include transparent clocks and boundary clocks, does it include non-1588 bridges and routers ? Also, how many master clocks do we need in the network ? I think that a close relationship between IETF and ITU would be beneficial. Stephen Crasner : Can you carry the messages inside the data ? Silvana : That is one possibility. Yaakov : I would like to stress one thing. The IEEE gives its blessing for the IETF to extend 1588 by developing a profile. Peter Lothberg : Will the ITU drafts be available to IETF community? Karen : We can make then available. Silvana : We can send an official request to the ITU and I am sure that it can be made available. Mark Townsley : There is plenty of precedent for the IETF and the ITU to work together. We have to make this happen. ----- The relationship between tictoc and NTP (Karen O’Donoghue) Karen : NTP grew out of work done by Dave Mills. There are millions of NTP daemons deployed. The NTP WG was chartered in March 2005 to develop the NTPv4 standard. We are really close with finishing this. Is there still work to be done on NTP ? I believe that clearly the answer is yes. There is the whole issue of interoperability between 1588 and NTP. In my opinion, the NTP WG has struggled with a lack of resources and a lack of design authority. Is there enough interest in the IETF to sustain both tictoc and NTP ? My belief is that there is not. What is the relationship between the NTP and a TicToc WG ? I believe that NTP WG should finish its existing items, leaving next generation items should be addressed by tictoc, and that the NTP WG could then be shut down. Mark Townsley : There is no implication that if the NTP WG shuts down that work on NTP in the IETF will stop. The email list can remain. Karen : I personally believe that this should continue. Stewart : Where do minor improvements happen ? Mark : I think that the proposal is that while the NTP WG lives, we should decide on a case by case basis, Kurtis : Should we keep changes in NTPv4 out of tictoc ? Mark : If you need a substantive change, that's NTPv5 and it's done here. ----- Issues related to topology discovery and auto-discovery and master clock discovery (Stewart Bryant) Stewart Bryant : I want to show a problem that IETF is uniquely qualified to address. To acquire time, a client or slave needs to receive a timestamped packet and it needs to estimate the time delay or age of the packet. All of the packet based timing systems we have so far assume that the route is symmetric, and the one-way delay is half of the RTT. There are three approaches to determining the switch / router delay. - the "Lucky packet path." We can look for packets with minimum delay. - We can use boundary clocks, which is the 1588 solution. - Transparent clocks - another 1588 term. At every switch or router on the path the packet is timestamped in and out and an adjustment field inserted to compensate for the router delay. Network topology is usually formed dynamically. But, the best path for data may not be the best path for time transfer. Let's look at these approaches. The "Lucky packet path." The best time path may be the one with fewest hops, may not be available through the IGP, and the return paths may not be symmetric. The boundary clock case (see slides). The optimal data path may be Master - A - B - C - slave, but if B is not a boundary clock this is not optimal for timing. The time path should go through M - A - D - C - slave. Note that the cascade of boundary clocks causes an addition of errors and thus a degradation of time quality. SDH can cope with 20 hops. 1588v1 was less sophisticated and they found that they had substantial error with only 4 hops. That is why they introduced transparent clocks. Stephen Casner : Is there any direct communications between master and slave, or is it as if we had that many strata ? Stewart : It is as if there were that many strata. There are two sorts of transparent clocks Peter Lothberg : What if you are trying to push your timing packets as payload on the wire ? Stewart : Suppose that you timestamp packets as they come in and leave the router. In a one step transparent clock, you change the time stamps by the difference between the input and egress time stamps. In a two step transparent clock, there is a correction packet that has this difference, summed over all of the routers in turn. This is how 1588 does it. It could be done differently. The diverse path is another thing we might want to do. Delivering the clock over a number of paths may have a number of advantages. What about network environments ? Routing protocols are different, and shortest path networks typically have more sophisticated provisioning techniques. In conclusion, it is likely that high quality time distribution will become an important element of network infrastructure, and both clock and path discovery will be needed. Jean-Luc: Presentation is interesting, points that have never been addressed in synchronization. Up to now the opinion of the operators has been that a good network is very stable and timing paths are manually configured. Gabriel : I am curious of economics of routers that include clocks, rather than deploying GPS. Maybe should concentrate on discovery rather than this. Stewart : There has been a lot of discussion of this. There are estimates of thousands of dollars per cell tower for synchronization via GPS. Yaakov : and there are sites that will not use GPS because of policy. Stewart : annd there are issues of GPS jamming. Yaakov : In general operators are willing to pay for an SLA. Kurtis : I think that most telecom operators will buy what it is cheapest. Most paths are not symmetrical, there is load balancing and tunnels. Enterprise networks are not just smaller versions of service provider networks. There is a lot of scary networks out there. Peter Lothberg : We need to improve the way of disseminating the time of day to users. With packet networks, we don't require synchronization. What we are trying to do is to support a bunch of stuff with legacy issues. Yaakov : A lot of customers are willing to pay a lot to get highly accurate time. It is not only legacy, and even the legacy will be around for a long time. Ted Seely : Can you can give us examples of applications which don't work. Yaakov : We want to get rid of SDH metworks and the need for roof access for GPS. This has all been discussed at great length at the first BOF and we have a whole draft on this, the problem statement. Ted : 90% of the users are single homed and so path discovery is not useful. Tim Shepherd : I have heard you say applications, but I haven't heard requirements for them. Stewart : There are a whole set of media stability requirements. DVB and WiMax sites, that need to have [frequency stability]. There are things like one way packet delay measurements. Then the financial guys want order of magnitudes improvement in time stamping. Yaakov : This is not a problem space where no one is interested. Tim : Is it clear which applications are in band and which are not ? Yaakov : Once we become a WG you can submit drafts about this. ----- Use cases (Yaakov) We decided to define 3 use cases in the charter. These are not exhaustive. - The service provider network - a controlled and well engineered network. 1588 is probably preferred here. - On the opposite end of the spectrum, there is the public best effort Internet, where NTP is known to work well. - Then there is the internetworking case - a SP network connecting to a general network, say. Ted : How well secured is 1588 ? Stewart : It is not well secured currently. There is an experimental appendix. Ted : in other cases, we have not accepted unsecured things even in walled gardens. Stewart : The IEEE has no problem with this. And remember this is 1588, and NOT 802. Yaakov : Use case number 1. We assume low packet loss, low delay jitter, possibly boundary clocks and transparent clocks, the security is assumed good. Case 1 is the environment where 1588 rules. Mark : As Dave mentioned, there is a principle that that any protocol that can run over IP has to have security (as if the packets were going on the big I Internet). This should be in phase 1. Yaakov : For case 2, the delay and PDV can be high. You can have false clocks, no on-path support, etc. This is where NTP is widely deployed. Alan : You mentioned PDV. Is that all that is important. Yaakov : You need to look at the PDV's distribution and more importantly its spectrum. Its the long term correlation between packet delays that causes wander. For the third (internetworking) case, let's suppose that there is a network using 1588 that connects to a network using NTP. Dave Oran : Why didn't you chose to model this as a domain that is one NTP hop ? That doesn't involve internetworking, but layering. Yaakov : That depends on the definition you use of interworking. When I use the term it includes (network) interworking (client/server) as well as (service) interworking. But certainly you can use 1588 as a way of constructing an NTP hop. Tony Li : I would like to propose use case 4, where 1588 is embedded between two NTP peers. Karen : I think a more logical case early on is NTP in the core and 1588 at the edges. Karen: NTP and 1588 have roughly similar semantics. Need to think about the 1588 master/slave paradigm and the NTP client/server paradigm. Donald : I am not an expert at the timing stuff, but I think that we need the folks who are using this stuff to say what the problems are. We need to distinguish between practical and theoretical use cases. I am not convinced that boundary clock solution applies - need to make that sort of call early on. If this WG does get formed I think that the problem statements need to be very well stated. Yaakov : I certainly agree that the WG's first task will be to finalize the requirements. There is literature about the issue of boundary clocks. Regarding synchronous Ethernet, if SDH works this can work as well. Yaakov : We are now at the discussion portion of the BOF. We need to discuss - are the use cases clear and sufficient ? - are the goals achievable ? - should Tictoc take on the NG of NTP ? - should the autodiscovery work be in phase 1 ? - is there sufficient support for the new charter ? Mark : That's a lot of questions there. It is clear that there is interest and applications for this work. By putting these two groups of people into one WG, I hope the common aspects can be solved once for both. One of the issues with NTP has always been that everyone is interested in it, but not a lot of people are willing or able to do the work. That was the whole purpose behind the modularity draft. The use cases are not meant to imply that NTP doesn't work on a small network. And the internetworking case is important, it is something that we will always have to fight with. Peter Lothberg : I think that I would like to simplify things. There are people with legacy equipment who want to plug a TDM box into a packet network. Then there are people who want to trust time. Another group has new applications of time. One way is PTP another is NTP. Different people in different networks. Why don't we say, "these are the requirements for one group", and look at IEEE or NTP way of doing it, and it's up to the consumer to pick the technology. Stewart : Yes, we can use NTP for the second case, but also can use 1588 for the first. Don't be under any illusion that 1588 can't tell you what the wall clock is. 1588 has a means of accounting for leap seconds. Yaakov : Frequency is not only for "legacy", it is also needed for modern cellular networks. Peter : You could build state of the art cell phone systems that don't need synchronization. We are staring at today's technology. Everyone here is using 802.11 and that doesn't have a central clock. Yaakov : Yes, but that is not how cellular systems are being built in practice. Stephen Casner : Perhaps people will start building networks in different ways. The question is, is what TICTOC wants to do achievable on any time scale. T Tony Li : I have a strong feeling that I would not like to participate in two separate working groups. Yaakov : How many people would like two working groups ? [apparently only 1 hand raised] Greg : There are charters for the 2 WGs, and they have a large gap. There are definitely applications with requirements that are not being met by the existing protocols. I am worried that there are not enough people to support all of these goals. If you look at the NTP WG, most of the work is on configuration, control, trust, building up groups of elements that need timing. Very different from current focus in TICTOC. Mark : The items that you mentioned should not be lost. Donald : First thing to figure out is what is the problem the WG is going to solve. What is the problem we are going to solve. The two groups do similar stuff, but there is a clear demarcation. Stewart : Fundamental task is producing a step-function improvement on accuracy and consistency in time across the network. Mark : We don't need to spend any more time on the question of 1 vs. 2 WGs. A small rev of the charter I think is definitely in order. Based on something that looks a lot like this charter, how many people think the IETF should take on this work, and create a TICTOC WG? About 20 hands. How many opposed? About 5 hands. Kurtis : Normally at the IETF when we form working groups, there is no protocol already in existance. Mark : Every WG I formed there was a protocol in existence! Kurtis : Normally we do problem statement, requirements, engineering work. I am starting to be worried when we talk about 2 groups rather than 1 WG. Tony : I think we should do the work, but not in a new working group. Recharter NTP. Mark : There will only be overlap of 1 meeting or so with 2 WGs. Tony : We are horrible at closing WGs. This could easily drift into 2 years! Mark : Lets hope not, and take it as motivation to get work done. Peter D : One application is wireless sensor networks. Are you going to use NTP or 1588 ? Steward : Depends on the requirements and specifications. Peter D : Neither is good for the application. Peter Lothberg : Need a requirements document. Stewart : Then we'll say we can't do it. If we can address it with existing protocols we'll do it, otherwise we'll go to Mark and ask if we should recharter or if it is something we shouldn't do. Mark : The existing charter has requirements, 1588 profile (if needed), NTPv4 extensions (if needed), various MIBS, ... I would like to get a feeling as to whether this is sufficient for now. We could put in autodiscovery / topology discovery work too, but every item that you add increases your likelihood of failure. Is this sufficient for now, or should we add more items right away? Jean-Loup : Would like to ask first step, policy statement. Will you list requirements from applications? Mark : Yes. Yaakov : A lot of the stuff you get without the need for a MIB. For example, packet loss. Mark : IETF wants MIBs at same time as protocols. Kurtis : I want to nit. We said either NTP extensions or NTPv5. Mark : How many people think this is a reasonable set of goals? [multiple simultaneous discussions about goals and milestones] Large number of hands. Karen : I do think that the problem statement and modular framework will have to be revisited in terms of NTP. Mark : How many people intend to actively participate ? Roughly 10. Yaakov : We also mentioned setting up an IRTF RG to deal with advanced timing issues. Who here would participate in an IRTF RG ? Roughly 10 (mostly the same people). Kurtis : The time scale is much too aggressive. Yaakov : It wasn't ours! It came from our AD! Kurtis : Add a year. Stewart : That would probably be more realistic. Yaakov : First 2 milestones are in March because we already have a rev1 and rev2 of these. Karen : A lot of material that can be pulled from the NTPv5 requirements effort. Mark : I think that you need to spin the charter one more time, definitely before Friday. Ted : Just for clarity I favor rechartering and doing the work. Yaakov : We're done. Thanks everyone.