Stewart, and all,
IMHO and FWIW, there are two valid reasons to deliver PTP (a.k.a. 1588) over
MPLS:
1. Ability to TE the PTP paths, e.g., to use co-routed bi-directional LSPs for
PTP transport.
This would hopefully eliminate potential negative effects of asymmetric
paths on clock
recovered by PTP slaves
2. Ability to employ TC by (somehow) making the intermediate nodes aware of PTP
packets so that
they could update the PTP correction field. The method by which such
awareness is achieved
should meet several important restrictions:
- It should be compatible with the MPLS data plane architecture (RFC 3031).
In particular, it should not
imply any special treatments in the ILM for "generic" labels
- Nodes that do not have TC capabilities should be traversed without
incurring significant additional delay
- Backward compatibility with existing MPLS deployments should be possible
- It should be possible to distinguish between the following situations
along the desired LSP between a PTP
Master and PTP slave:
* All LSR on the path are TC-capable
* Some LSR on the path may be not TC-capable, but all LSR on the path can
forward PTP packets without incurring
significant additional delay
* There is at least one LSR on the desired path that does not support any
TC-specific MPLS forwarding
mechanisms.
Please note that both items above are fully compatible with running PTP over
UDP/IP in labeled packets.
And nothing in these requirements implies IP forwarding in the data plane.
(From my point of view ability to
identify a labeled packet as an IP packet "for me" by the LSP tail-end node is
different for IP forwarding;
e.g., in MPLS-TP this ability is required to facilitate IP-based management
communication.)
My 2c,
Sasha
-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of
Stewart Bryant
Sent: Saturday, July 10, 2010 11:35 AM
To: [email protected]
Subject: Re: [TICTOC] FW: 1588 over MPLS draft
If we ignore issues associated with existing chipsets that support
1588/E and 1588/UDP/IP, my preferred approach would be 1588/MPLS. Indeed
I might be tempted to significantly reduce the protocol options in this
environment. i.e. create a new 1588 protocol mapping which runs over a
PTP FEC.
We need to think whether we would need to translate into one of the more
common client mapping via boundary clock, or whether we could do direct
protocol mapping, but I am concerned at the number of layers that we
need if we retain the Ethernet or the IP headers.
Stewart
--
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html
_______________________________________________
TICTOC mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tictoc
_______________________________________________
TICTOC mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tictoc
