Hi Joel,
When the basic payload is used, the IWF of the ingress PE is storing bits (not
bytes) as they come in, waits until enough bits have been received to fill a
payload and once ready creates a PLE packet and sends it across the PSN. The
IWF of the egress PE is doing the reverse in accordance to the recovered clock
(DCR).
In the end of the day a series of bits make their way across the PSN as is …
i.e. the PLE service makes the two CEs connected to the PLE service think they
are connected via a pair of fibre.
The CEs apply their technology specific pattern sync methods to detect framing
patters, etc without any interaction with the PEs. For Ethernet PCS sync is
done, for SONET A1,A2 framing is performed.
OTN services are a special case because we can’t carry bits as is. The ingress
NSP function must terminate the lowest OTN layer called OTUk as it contains
FEC. This means the egress NSP must create the OTUk/FEC layer, and in order to
do that byte aligning the PLE packet is beneficial.
Regards
Christian
On 18.10.2024, at 20:33, Joel Halpern <j...@joelhalpern.com> wrote:
Thanks. With regard to the non-byte-aligned payload, I am still slightly
confused. I can well believe this is clear to those working in the area.
But... If the payload is not byte aligned, and bytes are sent, how does the
receiver know how many bits in the last byte to ignore?
Thanks,
Joel
On 10/18/2024 1:44 PM, Christian Schmutzer (cschmutz) wrote:
Hi Joel,
Thank you for your review! Let me try to comment/answer here
1) RSV/FRG:
Good catch. We indeed forgot to mention explicitly that payload fragmentation
is not used by PLE. I changed the text for FRG to
These bits MUST be set to zero by the sender and ignored by the receiver as
PLE does not use payload fragmentation
And similar to RFC4553
(https://datatracker.ietf.org/doc/html/rfc4553#section-4.2) I also added the
following sentence to the PW demultiplexing section
The total size of a PLE packet for a specific PW MUST NOT exceed the path
MTU between the pair of PEs terminating this PW.
2) byte aligned payload
For Ethernet and Fibre Channel services, PLE is carrying 66B/64B encoded data
for example. So the payload carried by PLE is not always in bytes. The basic
payload of PLE is designed to be completely structure agnostic without any need
to align the PLE packet generation with the incoming payload data.
For OTN services
(https://datatracker.ietf.org/doc/html/draft-ietf-pals-ple-08#section-4.5) the
CE-bound IWF function must extract the extended ODUk frames from the received
PLE payloads. Based on our discussions with leading OTN technology vendors,
this "search function" is easier to implement under the assumption that the PLE
payload is byte aligned hence we defined this dedicated PLE payload type which
is byte aligned for OTN services.
I hope this addresses your comments. The changes with respect to 1) are
included in the -09 version I just uploaded to data tracker
Regards
Christian
On 11.10.2024, at 16:34, Joel Halpern via Datatracker
<nore...@ietf.org><mailto:nore...@ietf.org> wrote:
Reviewer: Joel Halpern
Review result: Ready with Nits
I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair. Please treat these comments just
like any other last call comments.
For more information, please see the FAQ at
<https://wiki.ietf.org/en/group/gen/GenArtFAQ><https://wiki.ietf.org/en/group/gen/GenArtFAQ>.
Document: draft-ietf-pals-ple-08
Reviewer: Joel Halpern
Review Date: 2024-10-11
IETF LC End Date: 2024-10-23
IESG Telechat date: Not scheduled for a telechat
Summary: This draft is ready for publication as a Proposed Standard
Major issues: N/A
Minor issues: N/A
Nits/editorial comments:
Section 5.2.1 defining the PLEA Control Word describes two pairs of bits,
one pair called RSSV and described in the usual way for describing reserved
bits. A second pair is called FRG and is described more teresely but
appears to be simply more reserved bits. It is unclear why these two
fields are separated, and why the wording is slightly different between
them.
Section 6 desccribes the basic payload and the byte aligned payload. The
description makes it look like there are two different forms. Thinking
about it, the payload is always in bytes, so the sender will fill bits from
the source until it has filled the fixed number of bytes. SO what is the
difference between 6.1 and 6.2?
_______________________________________________
Gen-art mailing list -- gen-art@ietf.org
To unsubscribe send an email to gen-art-le...@ietf.org
