Yaakov and all, Please note that GAL and, by implication, the ACH header are only looked at by an LSTR if GAL happens to be the top label in the stack (either because it has been the top label in originally received packet, or because all the labels above it have been popped by this LSR).
This leaves two options IMO: 1. You carry PTP directly across physical links using labeled packets that have a label stack of depth 1 containing GAL. In this case you can probably do want you want with the PTP packets' payload, (e.g., support TC), but you need some new mechanism for forwarding PTP packets along a multi-hop path. 2. You can carry PTP across any LSP using GAL at the bottom of the label stack. In this case only the tail end of the LSP will be PTP-aware, i.e., TC will not be supported with this option. I suggest taking a look at http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-data-plane for details regarding MPLS (and MPLS-TP) data plane. Regards, Sasha -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Yaakov Stein Sent: Monday, July 19, 2010 12:06 PM To: Mikael Abrahamsson Cc: [email protected] Subject: Re: [TICTOC] FW: 1588 over MPLS draft No. Not a new Ethertype - we are talking about MPLS NOT Ethernet. There is a protocol type (it's actually called a "channel type") in the Ach control word. See RFC 4385. Right now only a few are defined (raw BFD, IPv4, IPv6). Y(J)S -----Original Message----- From: Mikael Abrahamsson [mailto:[email protected]] Sent: Monday, July 19, 2010 09:48 To: Yaakov Stein Cc: [email protected]; [email protected] Subject: Re: [TICTOC] FW: 1588 over MPLS draft On Sun, 18 Jul 2010, Yaakov Stein wrote: > 1) define a new protocol type (plenty of openings in THAT registry!) New protocol type on what level? Ethernet, so this would involve a new ethertype? If routers generally can look that far into the packet on the correct forwarding level (I doubt it though) then that would be the least intrusive, but having LSRs look for ethertype within MPLS labeled packets sounds kind of advanced to do that early in the receive path? Why not do it more like an MPLS L3 VPN terminated/routed by all involved&&aware routers, then it would signal special labels to its neighbours that would be local significance only? But now we're talking handling it like a tree and that would involve routing protocols as well... Basically this would be like multicast IP and could leverage all the multicast MPLS standards out there. -- 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
