Hi Antti, Just to mention that I have a similar analysis as yours for the phase/time architecture.
And I also agree with Mike's comment: let's first discuss what the architecture will be, and it will automatically determine what to do with the protocols, as well as where there might be issues to be solved. Thanks. BR, Sébastien -----Message d'origine----- De : [email protected] [mailto:[email protected]] De la part de Pietilainen, Antti (NSN - FI/Espoo) Envoyé : mercredi 4 août 2010 09:58 À : ext Shahram Davari; ext Mikael Abrahamsson Cc : [email protected] Objet : Re: [TICTOC] FW: 1588 over MPLS draft Hi Shahram, So let's clarify a little. Unlike in the case of frequency synchronization I don't expect multiple timing flows going across the network in the case of time synchronization. Instead, I expect that the network nodes create a synchronization hierarchy and synchronize the whole network. Probably BCs will be used. Synchronization service will be offered at the edges to customers. My view is based on analogy to Synchronous Ethernet. Note, however, that the architecture has not yet been discussed in depth in Q13 so other architectures are possible too. If the architecture presented above is the way to go, the MPLS layer does not need to do any switching to the timing packets since they are terminated in every node. The timing protocol itself (not MPLS) decides what to do with the next hop. So the transporting problem is reduced to merely getting the packets across a single link. If one can accomplish that without bothering the MPLS layer, then we are all set just with OTN - PTP interaction. There are several choices of physical layer media and L1 protocols. For each protocol and medium one needs to separately solve how the physical layer information is associated with the timing protocol. Best regards, Antti -----Original Message----- From: ext Shahram Davari [mailto:[email protected]] Sent: Tuesday, August 03, 2010 8:29 PM To: Pietilainen, Antti (NSN - FI/Espoo); ext Mikael Abrahamsson Cc: [email protected] Subject: RE: [TICTOC] FW: 1588 over MPLS draft Hi Antti, I don't understand how 1588 over OTN/SONET can solve the problem of transporting 1588 over an MPLS network. Are you saying all networks must use OTN or SONET? Thanks, Shahram -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Pietilainen, Antti (NSN - FI/Espoo) Sent: Tuesday, August 03, 2010 4:54 AM To: ext Mikael Abrahamsson Cc: [email protected] Subject: Re: [TICTOC] FW: 1588 over MPLS draft Hi Mikael, > More and more networks are built with DWDM optics being put directly > into routers/switches, ie no OTN at all. By no OTN at all, do you mean, eg. 10GE interface? Ethernet interfaces should not require any changes to IETF protocols when Q13 is developing the time profile even though IP and UDP protocols might be utilized. As said earlier, the major IP/MPLS vendors are very well presented in Q13, and therefore the IETF and IEEE802 standards have been respected very well there (which, unfortunately cannot be said about some other groups in ITU). Best regards, Antti -----Original Message----- From: ext Mikael Abrahamsson [mailto:[email protected]] Sent: Tuesday, August 03, 2010 1:38 PM To: Pietilainen, Antti (NSN - FI/Espoo) Cc: ext Yaakov Stein; [email protected] Subject: Re: [TICTOC] FW: 1588 over MPLS draft On Tue, 3 Aug 2010, Pietilainen, Antti (NSN - FI/Espoo) wrote: > Tell me if Im wrong but I guess that the dominant client layer of, for > example OTN, is MPLS. If one solves the MPLS case, then one solves the > OTN case for a dominant proportion of OTN cases. On the other hand, if > one solves timing over OTN without using the MPLS layer, then one does > not need to solve how to carry time over MPLS whenever layer 1 is OTN. More and more networks are built with DWDM optics being put directly into routers/switches, ie no OTN at all. Future framers might be switchable between G.709(with FEC), 10GE WAN/LAN phy, and other framing standards, but this is not the case today. So any packet standard addressed by this WG should look at doing the standard over packet (and not just MPLS, it should be over IPv4/IPv6 which might be carried by MPLS, but this should not be a requirement). -- Mikael Abrahamsson email: [email protected] _______________________________________________ TICTOC mailing list [email protected] https://www.ietf.org/mailman/listinfo/tictoc _______________________________________________ TICTOC mailing list [email protected] https://www.ietf.org/mailman/listinfo/tictoc _______________________________________________ TICTOC mailing list [email protected] https://www.ietf.org/mailman/listinfo/tictoc
