Re: [PWE3] draft-manhoudt-pwe3-tsop-00.txt and IP
Gert Manhoudt <gmanhoudt@aimvalley.nl> Thu, 19 July 2012 09:56 UTC
Return-Path: <gmanhoudt@aimvalley.nl>
X-Original-To: pwe3@ietfa.amsl.com
Delivered-To: pwe3@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6D1721F87A4 for <pwe3@ietfa.amsl.com>; Thu, 19 Jul 2012 02:56:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.504
X-Spam-Level:
X-Spam-Status: No, score=-0.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ABzShtGLL7Sl for <pwe3@ietfa.amsl.com>; Thu, 19 Jul 2012 02:56:57 -0700 (PDT)
Received: from mika.eatserver.nl (mika.eatserver.nl [195.20.9.75]) by ietfa.amsl.com (Postfix) with ESMTP id BBFE021F8783 for <pwe3@ietf.org>; Thu, 19 Jul 2012 02:56:56 -0700 (PDT)
Received: from [195.242.97.150] (qore.networks.above.net [195.242.97.150] (may be forged)) (authenticated bits=0) by mika.eatserver.nl (8.13.8/8.13.8) with ESMTP id q6J9vVfO023387 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 19 Jul 2012 11:57:31 +0200
Received: from localhost (localhost.localhost [127.0.0.1]) by router38.aimvalley.nl (Postfix) with ESMTP id 9BA79818303; Thu, 19 Jul 2012 11:57:31 +0200 (CEST)
X-Virus-Scanned: by Endian Firewall
X-Spam-CTCH-RefID:
Received: from mail3.aimsys.nl (mail.aimsys.nl [10.10.0.114]) by router38.aimvalley.nl (Postfix) with ESMTP id BE493818302; Thu, 19 Jul 2012 11:57:30 +0200 (CEST)
Received: from [10.10.7.15] (pc315.aimsys.nl [10.10.7.15]) (authenticated bits=0) by mail3.aimsys.nl (8.14.2/8.14.2) with ESMTP id q6J9vSo6012111; Thu, 19 Jul 2012 11:57:28 +0200
Message-ID: <5007DA08.1020108@aimvalley.nl>
Date: Thu, 19 Jul 2012 11:57:28 +0200
From: Gert Manhoudt <gmanhoudt@aimvalley.nl>
Organization: AimValley B.V.
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1
MIME-Version: 1.0
To: Yaakov Stein <yaakov_s@rad.com>, Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>
References: <20120709230133.15922.55905.idtracker@ietfa.amsl.com> <4FFBE04A.5010203@cisco.com> <F9336571731ADE42A5397FC831CEAA020997FF@FRIDWPPMB001.ecitele.com> <500674D8.1040601@aimvalley.nl> <07F7D7DED63154409F13298786A2ADC9044E9468@EXRAD5.ad.rad.co.il>
In-Reply-To: <07F7D7DED63154409F13298786A2ADC9044E9468@EXRAD5.ad.rad.co.il>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha1"; boundary="------------ms010604030202060701010703"
Cc: "peter.roberts@alcatel-lucent.com" <peter.roberts@alcatel-lucent.com>, pwe3 <pwe3@ietf.org>, "stephan.roullot@alcatel-lucent.com" <stephan.roullot@alcatel-lucent.com>, "stbryant@cisco.com" <stbryant@cisco.com>
Subject: Re: [PWE3] draft-manhoudt-pwe3-tsop-00.txt and IP
X-BeenThere: pwe3@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: gmanhoudt@aimvalley.nl
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pwe3>, <mailto:pwe3-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pwe3>
List-Post: <mailto:pwe3@ietf.org>
List-Help: <mailto:pwe3-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pwe3>, <mailto:pwe3-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 19 Jul 2012 09:56:58 -0000
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. On 18 jul 2012 11:25, Yaakov Stein wrote: > 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 >
- [PWE3] draft-manhoudt-pwe3-tsop-00.txt and IP Stewart Bryant
- Re: [PWE3] draft-manhoudt-pwe3-tsop-00.txt and IP Alexander Vainshtein
- Re: [PWE3] draft-manhoudt-pwe3-tsop-00.txt and IP Yaakov Stein
- Re: [PWE3] draft-manhoudt-pwe3-tsop-00.txt and IP Alexander Vainshtein
- Re: [PWE3] draft-manhoudt-pwe3-tsop-00.txt and IP Gert Manhoudt
- Re: [PWE3] draft-manhoudt-pwe3-tsop-00.txt and IP Yaakov Stein
- Re: [PWE3] draft-manhoudt-pwe3-tsop-00.txt and IP Alexander Vainshtein
- Re: [PWE3] draft-manhoudt-pwe3-tsop-00.txt and IP Yaakov Stein
- Re: [PWE3] draft-manhoudt-pwe3-tsop-00.txt and IP Yaakov Stein
- Re: [PWE3] draft-manhoudt-pwe3-tsop-00.txt and IP Gert Manhoudt
- Re: [PWE3] draft-manhoudt-pwe3-tsop-00.txt and IP Stewart Bryant