Hi Matthew
I have taken a look at this draft and think that it needs close review in PALS
and ought to have a review in TICTOC.
It needs a much clearer description of the scenario. For instance in Figure 3
are A and G the same clock domain or is one the master. I think that for this
to work one has to be the master otherwise I cannot see how you can ship an
arbitrary bit stream between them. Even then it will not be easy and you need
to give a lot of thought to the need for bit stuffing and bit slip since it is
unlikely that you will generate perfect sync. In traditional wide area sync
networks the protocols include features that support this action to cope with
long term drift.
Also you talk about SyncE. That is specified to provide a 50bbp frequency
accuracy, so this is going to need careful design and planning.
Also since this is an arbitrary bit stream, you have to comment on what you do
when a packet is dropped.
Since this is PW encapsulation, it probably belongs in PALS, but I do have some
reservations about what is proposed. This is not a turf issue for me, I just
want to make sure it gets the reviewed by the people that designed this type
of technology in the past.
Best regards
Stewart
More comments inline.
=======
Another example is addressing common ethernet
control protocol transparency concerns for carrier ethernet services,
beyond the behavior definitions of MEF specifications.
SB> That is a possible application, and that might include some of the link
layer fragmentation that TSN is doing, but I do have to wonder if the network
would destroy the other properties. This is certainly something worth
discussing in DetNet.
========
To allow the clock of the transported signal to be carried across the
PLE domain in a transparent way the network synchronization reference
model and deployment scenario outlined in section 4.3.2 of [RFC4197]
is applicable.
Gringeri, et al. Expires May 6, 2021 [Page 5]
Internet-Draft PLE November 2020
J
| G
v |
+-----+ +-----+ v
+-----+ |- - -|=================|- - -| +-----+
| |<---------|.............................|<---------| |
| CE1 | | PE1 | VPWS | PE2 | | CE2 |
| |--------->|.............................|--------->| |
+-----+ |- - -|=================|- - -| +-----+
^ +-----+<-------+------->+-----+
| | ^
A +-+ |
|I| E
+-+
Figure 2: Relative Network Scenario Timing
The attachment circuit clock E is generated by PE2 in reference to a
common clock I. For this to work the difference between clock I and
A MUST be explicitly transferred between the PE1 and PE2 using the
timestamp inside the RTP header.
For the reverse direction PE1 does generate the clock J in reference
to clock I and the clock difference between I and G.
SB> OK, so you are assuming that I is fully distributed through the network and
that I does not change as it might if the clock master in I changes.
SB> That is not generally available in an MPLS network and we need to discuss
the implications of providing it.
SB> This does not make sense to me and maybe I do not understand what you have
in mind. CE would normally be a domain rather than a host, so the ingress and
egress from CE1 and CE2 would need to be synchronous, but that is not what you
are showing. However I think you have CE1 syncing CE2 and CE2 syncing CE1. I
don’t think that will work.
===========
4.2.1. PLE Control Word
The format of the PLE control word is inline with the guidance in
[RFC4385] and as shown in the below figure:
SB> You know that you are not required to follow this exact format.
SB> It would be worth losing at the SONET PW to see if that is more convenient.
=========
4.2.2. RTP Header
The RTP header MUST be included and is used for explicit transfer of
timing information. The RTP header is purely a formal reuse and RTP
mechanisms, such as header extensions, contributing source (CSRC)
list, padding, RTP Control Protocol (RTCP), RTP header compression,
Secure Realtime Transport Protocol (SRTP), etc., are not applicable
to PLE VPWS.
SB> RTP is clearly an option, but it is not clear whether it is better or not
than creating custom CW as we did for the SONET PW.
The format of the RTP header is as shown in the below figure:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P|X| CC |M| PT | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Synchronization Source (SSRC) Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: RTP Header
========
Sequence Number
SB> I am not sure we need two sequence numbers in the protocol - on in the CW
and one in the RTP header
The packet sequence number MUST continuously cycle from 0 to
0xFFFF. It is generated and processed in accordance with the
rules established in [RFC3550]. The PLE receiver MUST sequence
packets according to the Sequence Number field of the PLE control
SB> Also By using RTP you are of course tied to its S/N size. It is not clear
to me that this is optimal.
word and MAY verify correct sequencing using RTP Sequence Number
field.
Timestamp
Timestamp values are used in accordance with the rules established
in [RFC3550]. For bit-streams up to 200 Gbps the frequency of the
clock used for generating timestamps MUST be 125 MHz based on a
the common clock I. For bit-streams above 200 Gbps the frequency
MUST be 250 MHz.
SB> I am not sure how the TS is working her, because at a different point in
the document I thought that you said that the TS was being used to convey the
frequency difference between the clock domains.
SB> I think from this text you are only considering Ethernet bit streams. I am
not sure you can describe arbitrary speeds with reference to a 200MHz clock.
This needs a lot more thought.
SB> If you are only supporting syncE you need to say so, and of course
reference the ITU-T material on the subject.
=======
5. PLE Payload Layer
5.1. Constant Bit Rate Payload
For CBR, I am not sure who is handling the clock slip.
========
7. Security Considerations
As PLE is leveraging VPWS as transport mechanism the security
considerations described in [RFC7432] and [RFC3985] are applicable.
SB> I think there is more to it that in this case. For example what about
disruption to the clock service?
===========
10.1. Normative References
SB> I am surprised there are not G.8262 and G.8264 references since these are
part of the SyncE specification.
SB> A lot of the difficulty in designing synchronisation architectures is in
the management of the clock master and the actions to take when access to a
clock fails.
_______________________________________________
TICTOC mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tictoc
