Subject: [PWE3] draft-manhoudt-pwe3-tsop-00.txt and IP

From: Stewart Bryant <[email-masked]>
Date: Tue, 10 Jul 2012 08:56:58 +0100

Do the authors think that running transparent
SONET emulation over IP is likely in practice, or is
this included because SAToP included it?

Stewart
(Speaking as an individual)

---

From: Alexander Vainshtein <[email-masked]>
Date: Tue, 10 Jul 2012 09:01:22 +0000

Hi all,
Several comments on the draft in question:

1. The draft seems to follow closely RFC 4553, including support of IPv4/IPv6 as the PSN, congestion handling etc. I echo Stewart's question regarding usage of IPv4/IPv6 PSN (with limited TE capabilities) for carrying such high-rate CBR flows as STM-1/OC-3 and higher.

2. The draft correctly mentions RFC 4842 as an alternative (and approved by the IETF) method for emulating SONET/SDH over PSN. However, it is worth noting that one of the reasons this method has been preferred to transparent passing of the entire SONET/SDDH bit stream (e.g., as proposed in one of the early precursors of RFC 4553 - see  http://www.watersprings.org/pub/id/draft-vainshtein-cesopsn-01.txt, Annex B) to was elimination of the need to manipulate the S1 byte in the SONET/SDH overhead. The lower nibble of this byte contains encoded quality of the system clock of the SONET/SDH mux that has been used to drive the outgoing SONET/SDH bit stream. Simply passing tits value transparently thru the PSN does not make any sense (and, indeed, potentially violates integrity of clock distribution). The IWF proposed in the draft cannot access this byte because it is unaware of the SONET/SDH boundaries, and neither can this be done by the  OSn_TT_So & OSn/RSn_A_So/  OSn_TT_Sk & OSn/RSn_A_Sk  functional blocks to which the IWF is connected. IMHO the draft should explain in some detail how this issue is resolved. Alternatively, it should state that the SONET/SDH bit stream that has passed thru the TSoP PW MUST NOT be used as the clock source by the CE device.

3. The draft defines only LOS as the mandatory SONET/SDH AC fault to affect setting of the L bit in the PW control word. However, if Loss of Frame defect is encountered (dLOF),  de-scrambling of the incoming SONET/SDH stream cannot be completed, and the payload of the TSoP would become junk; hence IMO LOF must be added as a mandatory trigger for asserting the SF condition in Section 3.1.  (And, while the reference to the ITU-T G.783 functional blocks implies that, it would be nice to explain that the incoming SONET/SDH bit stream is segmented and encapsulated after de-scrambling - for the sake of the readers that do not parse the ITU-T-ish easily:-)

4. The draft seems to imply that TSoP requires, as a pre-requisite, availability of common high-quality clock for the pair of PEs terminating a TSoP PW by both mandating the use of the minimal RTP header in the encapsulation and not recommending usage of adaptive clock recovery for these PWs. However, this important restriction is not reflected in the Applicability Statement section of the draft.

5. The draft mentions the need not to exceed the path MTU between the pair of PEs in the case of IPv4/IPv6 PSN but not in the case of the MPLS PSN (where it obviously applies).

Hopefully these notes will be useful.

Regards,
     Sasha

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Stewart Bryant
> Sent: Tuesday, July 10, 2012 10:57 AM
> To: pwe3
> Subject: [PWE3] draft-manhoudt-pwe3-tsop-00.txt and IP
> 
> _______________________________________________
> pwe3 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pwe3

This e-mail message is intended for the recipient only and contains information which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this transmission in error, please inform us by e-mail, phone or fax, and then delete the original and all copies thereof.

---

From: Yaakov Stein <[email-masked]>
Date: Wed, 11 Jul 2012 16:55:42 +0000

Authors of draft-manhoudt-pwe3-tsop and the rest of PWE3,

This approach was considered a long time ago,

but was not accepted due to a major architectural flaws.

First, as Sasha said, it does not find the S1 byte

and thus lies about the SSM message.

This is not acceptable behavior.

In terms that non-TDM people would understand,

this would be similar to discovering an incorrect header checksum.

but then recalculating it to cover up the loss.

Second, this function is at least a section (in SDH terminology a regenerator section) termination

(since it does not divide up STM-Ns, it is not a line termination).

Section terminations MUST terminate and regenerate the section overhead

(A1, A2, J0, B1, etc.) and optionally SHOULD enable insertion and dropping of

E1, F1, and D1/2/3 Data Communcations Channels.

Once again, by transparently passing these bytes rather than regenerating them,

the emulation "lies" about their values.

Finally, as Sasha already stated, the scrambling mechanism

recovery after a single packet loss is problematic.

This in itself pretty much kills the service usefulness if there is any packet loss.

In addition the clocking is not sufficiently described.

I understand that RTP usage is mandated,

and for some reason that 25 MHz is the nominal frequency.

However, it is not clear what that 25 MHz is locked to.

Is this always "common clock" (differential mode) ?

Also, why is G.709 AIS generated instead of SDH MS-AIS or MSF-AIS ?

I have a funny feeling that someone is trying to trick the SDH end devices

NOT to recognize the fault condition.

G.826 specifies that detecting AIS causes the declaration of a severely errored second (SES)

and that there can be no more than 1/5 of a percent of SESes,

i.e., about 1 AIS event in 500 seconds.

At the default payload size of 810 Bytes, a single STM-1 takes 3 packets,

so that there are 24,000 packets per second,

so we are talking about an packet loss ratio of 1 in 500*24,000 = 12 million,

i.e., about 8E-8.

Nits:

   As with all PWs, TSoP PWs may be manually configured or set up using

   the PWE3 control protocol [RFC4447<http://tools.ietf.org/html/rfc4447>].

well, it will require extensions to 4447.

   The key difference between the CEP approach and the TSoP

   approach is that within CEP an incoming STM-N is terminated and

   demultiplexed to its constituent VCs (Virtual Containers).

I don't agree. While transport of VTs/VCs is allowed,

an STM-1 can be transported directly using CEP without demuxing.

However, the framing is discovered and the CW structure pointer points to the beginning of the SPE.

This is the correct behavior for a regenerator.

Why is G.709 an informative reference, if one needs to generate its AIS pattern ?

Y(J)S

---

From: Alexander Vainshtein <[email-masked]>
Date: Wed, 11 Jul 2012 17:20:55 +0000

Hi all,

I concur with Yaakov's points.

Regards,

     Sasha

________________________________
From: Yaakov Stein [[email-masked]]
Sent: Wednesday, July 11, 2012 6:55 PM
To: Alexander Vainshtein; [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]; pwe3; Ron Cohen
Subject: RE: [PWE3] draft-manhoudt-pwe3-tsop-00.txt and IP

i.e., about 8E-8.

Nits:

Y(J)S

---

From: Gert Manhoudt <[email-masked]>
Date: Wed, 18 Jul 2012 10:33:28 +0200

Stewart, Yaacov and Alexander,

Thanks for your comments on draft-manhoudt-pwe3-tsop-00. It is our 
intent to request the PWE3 WG to accept this document as a working group 
draft. At this stage I want to address those points that could be 
interpreted to  imply that the TSoP approach as such is not acceptable. 
The other comments are of a less principal nature and can be addressed 
later (and can probably be fixed by adapting the text).

1. TSoP does not require the termination of any STM-N overhead:
Yaakov's e-mail contains the statement: "this function is at least a 
section (in SDH terminology a regenerator section) termination". I 
believe that this statement is not true: There is no reason why STM-N 
signals can not be carried transparently over some server layer with 
minimal interaction between client and server (as should always be the 
goal).

The correct architectural analogue would be to compare a TSoP PW section 
to an OTN network that transports an STM-N client signal. The mapping of 
an STM-16/OC-48 in an ODU1 does not require any processing of STM-N 
overhead or even framing for alignment purposes: All STM-16 bits are 
directly written into the OPU1 payload area. This is described in G.709 
section 17.2.1. In terms of functional blocks this is described in G.798 
section 14.3.1. Note that Appendix I.1 of this same Recommendation 
describes the mapping of STM-N in OPU-k using OPTIONAL RS-monitoring, 
just like TSoP.

Because a TSoP PW section (STM-N over PSN) is modeled to behave itself 
in the same way as an STM-N over OTN section, the TSoP decapsulation 
function inserts Generic AIS as defined in G.709, rather than SDH 
multiplex section AIS as defined in G.707, in case the client signal is 
interrupted.

As a side remark: Yaakov's mail also contains the statement: "(since it 
does not divide up STM-Ns, it is not a line termination)". Note that 
this directly contradicts the remark that the S1-byte must be processed. 
If that were really necessary, it would not be sufficient to limit the 
required SDH functionality to a regenerator section termination, but 
rather a full multiplex section termination (SONET: line termination) 
would be necessary, since the S1-byte is located in the MS part of the 
STM-N overhead and not in the RS part: SDH regenerators pass the S1-byte 
transparently.

2. TSoP passes the S1-byte transparently:
The S1-byte in the STM-N multiplex section overhead carries the 
"traceability information" of the STM-N signal, i.e. the quality level 
of the master clock at the beginning of a chain of slaved STM-N systems. 
Normally this quality level is PRC/PRS, but during fault situations, it 
may lower to SSU/ST2 or even SEC/ST3. Downstream STM-N systems can use 
this information to select another reference signal or to go in 
hold-over mode.

The question is now whether the passage of an STM-N signal over a 
TSoP/PSN section should affect the value of the S1-byte. We believe that 
this is not the case: The nature of a passage of an STM-N signal through 
a TSoP Pseudowire is such that the traceability does not change, since 
the (long term average of the) frequency of the STM-N signals before 
entering the TSoP PW and after leaving the TSoP PW is the same: No bits 
are created or deleted from the STM-N client signal. This means that if 
the long term frequency accuracy of an STM-N signal is 1E-11 (i.e. it is 
traceable to PRC/PRS), that this will not change by passing the TSoP PW, 
i.e. the traceability is invariant.

Of course, during a failure, the TSoP decapsulation function substitutes 
the G-AIS signal which is no longer frequency synchronous with the input 
STM-N. In this case the downstream STM-N node will immediately detect 
Loss of Frame and will no longer be able to read the S1-byte. According 
to standard SDH reference selection procedures (see G.781), this node 
will no longer consider such a signal to be an acceptable 
synchronization reference.

3. A TSoP PWE3 can be carried over UDP/IP:
This option has been included in the TSoP draft purely because it is 
present in the SAToP standard and to keep the encapsulation options 
aligned. If experience has shown that transport over an UDP/IP PSN of 
higher bitrate circuit emulation PW's is not recommendable, the authors 
have no problem to remove this option.

Regards,
Gert Manhoudt.

---

From: Yaakov Stein <[email-masked]>
Date: Wed, 18 Jul 2012 08:59:26 +0000

see comments below.

-----Original Message-----
From: Gert Manhoudt [mailto:[email-masked]] 
Sent: Wednesday, July 18, 2012 11:33
To: Alexander Vainshtein; [email-masked]; Yaakov Stein
Cc: [email-masked]; [email-masked]; pwe3; Ron Cohen
Subject: Re: [PWE3] draft-manhoudt-pwe3-tsop-00.txt and IP

draft. 

[YJS] I think that since this draft redefines basic SDH functionality,
at very least we need to liaise with ITU-T before accepting this document.

At this stage I want to address those points that could be 
interpreted to  imply that the TSoP approach as such is not acceptable. 
The other comments are of a less principal nature and can be addressed 
later (and can probably be fixed by adapting the text).

[YJS] Anything that breaks the physical layer continuity, 
is at least a regenerator from the SDH layering point of view.
A simple optical amplifier is less than a regenerator,
since it indeed passes the SDH transparently.
The proposal here is VERY non-transparent, as I pointed out.
In particular, it breaks the timing chain, which is absolutely fundamental to SDH operation. 

The correct architectural analogue would be to compare a TSoP PW section 
to an OTN network that transports an STM-N client signal. 

[YJS] Do you realize that PSNs are not synchronous networks ?

The mapping of an STM-16/OC-48 in an ODU1 does not require any processing of STM-N 

[YJS] The whole purpose of my remark was to point out that this
draft proposes a network element that does not exist in SDH as presently defined,
and thus, as I proposed, needs to be liaised to the SDO holding the pen on SDH.

[YJS] This statement is blatantly incorrectly.
The S1 byte specifically indicates that the bit stream obeys the appropriate
ITU-T timing Recommendation, such as G.811, G.812, or G.813.
This is not limited to very long term FFO constraints,
but also jitter and wander limits.
Were this statement to be true, the entire SDH timing chain would fail
(which is precisely what worries me about the draft).
In particular, were this statement to be true,
we would not have needed to work so hard over the past 10 years on algorithms
and standards for TDM PW synchronization. We could just send everything
using a local 100 ppm crystal and claim that long term the FFO is will be correct.

[YJS] I am not talking about failures.
I am talking about normal operation.
You will be carrying an SSM that states that you are SEC or SSU,
and the downstream network elements will believe this.
Their G.781 will cause this clock to be selected, rejecting better clocks,
and leading to system failures.

[YJS] While this was not my remark, I think that there is a big difference
between an individual E1 and an STM signal.

Regards,
Gert Manhoudt.

---

From: Alexander Vainshtein <[email-masked]>
Date: Wed, 18 Jul 2012 09:02:56 +0000

Gert, and all,
Please see some comments inline below.

Regards,
     Sasha

> Sent: Wednesday, July 18, 2012 11:33 AM
> ([email-masked])
 [[[Sasha]]] I may be running ahead of things, but I would not support adoption of the draft - at least in its present form.

> describes the mapping of STM-N in OPU-k using OPTIONAL RS-monitoring,
[[[Sasha]]] Do you imply that you TSoP carries STM-N unscrambled?
> multiplex section AIS as defined in G.707, in case the client signal is
[[[Sasha]]] To the best of my understanding:
(a) You cannot insert MS-AIS (because you do not know where the MS is)
(b) Any standard SDH framer would recognize the Generic AIS as RS-LOF
(b) inserting "all ones" would actually have the same effect.
> i.e. the traceability is invariant.
[[[Sasha]]] I think that your interpretation of S1 is inaccurate.
In SDH (and SONET) it carries the information about the traceability level of the clock that has been used to generate the current SDH bit-stream.  The TSoP endpoint should do exactly the same IMO.

So what is the quality of the clock that the TSoP endpoint uses? There are at least three factors that affect this clock:
(a) Characteristics of the local oscillator used for clock recovery
(b) Quality of the original clock
(c) Specifics of the clock recovery algorithm. 

(c) above may be not all that relevant with Differential clock recovery that you propose to use for TSoP. For Adaptive clock recovery its impact on wander of the recovered SAToP and CESoPSN  clock is known to be critical - and this in spite of the fact that these protocols do not add or remove any bits!

(a) and (b) are not really under your control, but I would guess that the actual quality of the recovered clock cannot be higher than the worst of these two. So if your incoming SDH stream has been clocked by the PRC, but your common clock used for Differential clock recovery is Stratum 3E, then the quality of the recovered clock would not be better that Stratum 3E - and sending out the S1 value that reports PRC quality would be wrong.

The draft could, of course, indicate (e.g., in its applicability section) that S1 values sent out by the TSoP endpoint should not be believed. It could also recommend synchronizing the two PEs containing a pair of TSoP endpoints to a PRC-class common clock - not a very far-reaching assumption taking into account availability of GPS clock sources. But without these caveats the draft simply looks as containing technically wrong statements.
 
> > 1. The draft seems to follow closely RFC 4553, including support of
> IPv4/IPv6 as the PSN, congestion handling etc. I echo Stewart's question
> regarding usage of IPv4/IPv6 PSN (with limited TE capabilities) for carrying
> such high-rate CBR flows as STM-1/OC-3 and higher.
> >
> > 2. The draft correctly mentions RFC 4842 as an alternative (and approved
> by the IETF) method for emulating SONET/SDH over PSN. However, it is
> worth noting that one of the reasons this method has been preferred to
> transparent passing of the entire SONET/SDDH bit stream (e.g., as proposed
> in one of the early precursors of RFC 4553 - see
> http://www.watersprings.org/pub/id/draft-vainshtein-cesopsn-01.txt, Annex
> B) to was elimination of the need to manipulate the S1 byte in the
> SONET/SDH overhead. The lower nibble of this byte contains encoded quality
> of the system clock of the SONET/SDH mux that has been used to drive the
> outgoing SONET/SDH bit stream. Simply passing tits value transparently thru
> the PSN does not make any sense (and, indeed, potentially violates integrity
> of clock distribution). The IWF proposed in the draft cannot access this byte
> because it is unaware of the SONET/SDH boundaries, and neither can this be
> done by the  OSn_TT_So & OSn/RSn_A_So/  OSn_TT_Sk & OSn/RSn_A_Sk
> functional blocks to which the IWF is connected. IMHO the draft should
> explain in some detail how this issue is resolved. Alternatively, it should state
> that the SONET/SDH bit stream that has passed thru the TSoP PW MUST NOT
> be used as the clock source by the CE device.
> >
> > 3. The draft defines only LOS as the mandatory SONET/SDH AC fault to
> affect setting of the L bit in the PW control word. However, if Loss of Frame
> defect is encountered (dLOF),  de-scrambling of the incoming SONET/SDH
> stream cannot be completed, and the payload of the TSoP would become
> junk; hence IMO LOF must be added as a mandatory trigger for asserting the
> SF condition in Section 3.1.  (And, while the reference to the ITU-T G.783
> functional blocks implies that, it would be nice to explain that the incoming
> SONET/SDH bit stream is segmented and encapsulated after de-scrambling -
> for the sake of the readers that do not parse the ITU-T-ish easily:-)
> >
> > 4. The draft seems to imply that TSoP requires, as a pre-requisite,
> availability of common high-quality clock for the pair of PEs terminating a
> TSoP PW by both mandating the use of the minimal RTP header in the
> encapsulation and not recommending usage of adaptive clock recovery for
> these PWs. However, this important restriction is not reflected in the
> Applicability Statement section of the draft.
> >
> > 5. The draft mentions the need not to exceed the path MTU between the
> pair of PEs in the case of IPv4/IPv6 PSN but not in the case of the MPLS PSN
> (where it obviously applies).
> >
> > This e-mail message is intended for the recipient only and contains
> information which is CONFIDENTIAL and which may be proprietary to ECI
> Telecom. If you have received this transmission in error, please inform us by
> e-mail, phone or fax, and then delete the original and all copies thereof.
> >
> 
>

---

From: Yaakov Stein <[email-masked]>
Date: Wed, 18 Jul 2012 09:25:50 +0000

Gert and all, 

I would like to partially retract what I previously said about the S1 byte and traceability.
I hit the send too quickly, and should have thought over the issue first.

It is true that the SSM message relates information about traceability,
i.e., that after N SDH network elements a certain amount of phase noise has accumulated,
so that the bit stream does not obey the G.81x masks.
However, this is not applicable here.
Here the physical layer traceability is truly broken,
and you are relying on unexplained magic to restore it.

All that your statement about not dropping or adding bits guarantees is
lim_tau->infinity  MTIE(tau) / tau = 0, which is not enough.
The MTIE slope has to obey the constraint at some finite time.

Put in another way, stating that you don't drop or add bits is equivalent
to stating that you are somehow traceable to the original clock,
but since you broke the physical layer, and do not describe any mechanism
for recovery of that physical layer clock, in fact you WILL be forced
to have bit slips at the egress IWF.

So, simply saying that the SSM is correct by definition,
and relying on magic to restore the proper clock,
is not meaningful.

Sorry for my previous incorrect statements.

Y(J)S

---

From: Yaakov Stein <[email-masked]>
Date: Wed, 18 Jul 2012 10:50:51 +0000

Sasha - thank you for wording my concerns in a much better fashion than I was able to!

>From what we understand in the present draft, the clock to which the egress SDH is locked
is a free-running local oscillator (perhaps disciplined to GPS).
This is not reflected in the SSM message.

Y(J)S

---

From: Gert Manhoudt <[email-masked]>
Date: Thu, 19 Jul 2012 11:57:28 +0200

Yaakov, Alexander,

I understand that the key issue that you raise is whether the continuity 
of the "physical layer" when an STM-N signal traverses a TSoP Pseudowire 
is sufficiently guaranteed.

First of all, I assume that "continuity of the physical layer"(during 
normal operation)means that all bits that ingress the Pseudowire also 
egress the Pseudowire in the same order and that there is a certain 
timing relation between these ingress en egress signals. The example of 
an optical amplifier was mentioned as a system that does not break the 
physical layer. That is indeed a clear example. But also more complex 
systems that do process the binary content of the client signals, like 
OTN networks, can be said to leave the physical layer intact. Actually, 
the whole point of Pseudowires is to deliver services that emulate a 
wire as well as possible, but that does not mean that the client signals 
are not "adapted" during transport.

Anyway, I agree that to transport STM-N signals over a Pseudowire in the 
way as proposed in the TSoP draft, requires that not only the STM-N bits 
should remain unaffected, but also a certain timing relation between 
input and output must be satisfied in order not to "lie about the S1 
content".

The way that this is currently specified in the TSoP draft is written in 
section 6.2.2, where it stated for the TSoP decapsulation function, that:
- A reconstructed SDH-type STM-N signal delivered to an Attachment 
Circuit MUST meet [G.825] jitter and wander requirements, or,
- A reconstructed SONET-type OC-M signal delivered to an Attachment 
Circuit MUST meet [GR-253] jitter and wander requirements.

I believe this covers Yaakov's comment that "The MTIE slope has to obey 
the constraint at some finite time", since G.825 and GR-253 exactly 
define all phase noise tolerances in different observation intervals.

The current draft indeed does not specify how this should be achieved. 
This is done on purpose to avoid prescribing a certain implementation: 
The draft allows in principle both adaptive and differential approaches, 
and who knows what other schemes that clever people may dream up in the 
future. As long as the recovered SDH/SONET signal meets all applicable 
G.825/GR-253 jitter and wander specifications, it should be fine from a 
network perspective.

Clearly, meeting the G.825/GR-253 requirements is a lot easier 
whensynchronized clocks are available in the PE ingress and egress 
nodesand differential timing can be used. I agree that it may be useful 
(necessary?) to add some text to the draft in the Applicability 
Statements section that explains these things, referring to the 
different network timing situations described in RFC-4197.

Answering some of the other questions:
- TSoP carries STM-N in scrambled format
- TSoP can not insert MS-AIS, since it does not know where the STM-N 
frame starts. Instead it substitutes G-AIS, just as an OTN network will 
do when it carries an STM-N client and something goes wrong.
- The quality level of the clock at the PE that reconstructs the STM-N 
signal at the PW egress is not prescribed. It depends on the design of 
this circuit and the network synchronization. Again, as long as you meet 
G.825/GR-253 jitter and wander requirements at the egress it should be 
fine. The only other requirement is a +/-20 ppm accuracy when the STM-N 
signal is replaced by G-AIS. Note that in this condition no S1 is 
present any longer, so the downstream SDH/SONET NE can not draw any 
wrong conclusions. In fact it will immediately detect LOF and select 
another reference or fall back into hold-over mode.

Regards,
Gert.

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 19 Jul 2012 11:13:25 +0100

> at very least we need to liaise with ITU-T before accepting this document.
I cannot speak to whether this draft redefines SDH or not, but I agree
that  PWE3 WG needs to liaise with ITU SG15 if it is considers adopting
the draft.

Stewart