Re: [CCAMP] Questions/comments on OTN signaling

Zhangfatai <zhangfatai@huawei.com> Sat, 24 September 2011 08:23 UTC

Return-Path: <zhangfatai@huawei.com>
X-Original-To: ccamp@ietfa.amsl.com
Delivered-To: ccamp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A52921F86A1 for <ccamp@ietfa.amsl.com>; Sat, 24 Sep 2011 01:23:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.611
X-Spam-Level:
X-Spam-Status: No, score=-3.611 tagged_above=-999 required=5 tests=[AWL=-1.216, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4]
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 2MjaQYY5hH-6 for <ccamp@ietfa.amsl.com>; Sat, 24 Sep 2011 01:23:45 -0700 (PDT)
Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 42BAE21F86A0 for <ccamp@ietf.org>; Sat, 24 Sep 2011 01:23:44 -0700 (PDT)
Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LS00061SQ3VU7@szxga04-in.huawei.com> for ccamp@ietf.org; Sat, 24 Sep 2011 16:26:19 +0800 (CST)
Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LS000M2HQ3PH5@szxga04-in.huawei.com> for ccamp@ietf.org; Sat, 24 Sep 2011 16:26:19 +0800 (CST)
Received: from szxeml208-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AED28583; Sat, 24 Sep 2011 16:26:18 +0800
Received: from SZXEML402-HUB.china.huawei.com (10.82.67.32) by szxeml208-edg.china.huawei.com (172.24.2.60) with Microsoft SMTP Server (TLS) id 14.1.270.1; Sat, 24 Sep 2011 16:26:09 +0800
Received: from SZXEML520-MBX.china.huawei.com ([169.254.1.142]) by szxeml402-hub.china.huawei.com ([10.82.67.32]) with mapi id 14.01.0270.001; Sat, 24 Sep 2011 16:26:11 +0800
Date: Sat, 24 Sep 2011 08:26:10 +0000
From: Zhangfatai <zhangfatai@huawei.com>
In-reply-to: <F01646262154A14BBD2EFB3580FD8B9103C46AE8@rchemxp01.fnc.net.local>
X-Originating-IP: [10.70.76.157]
To: "Gruman, Fred" <fred.gruman@us.fujitsu.com>, "ccamp@ietf.org" <ccamp@ietf.org>
Message-id: <F82A4B6D50F9464B8EBA55651F541CF812BB0FEA@SZXEML520-MBX.china.huawei.com>
MIME-version: 1.0
Content-type: multipart/alternative; boundary="Boundary_(ID_PvVvdEkGRCeoahAN/ysa4A)"
Content-language: en-US
Accept-Language: zh-CN, en-US
Thread-topic: Questions/comments on OTN signaling
Thread-index: Acx5TLK62imqLTNqRbO9SLfzHCpWGgBQ60nA
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
X-CFilter-Loop: Reflected
References: <F01646262154A14BBD2EFB3580FD8B9103C46AE8@rchemxp01.fnc.net.local>
Subject: Re: [CCAMP] Questions/comments on OTN signaling
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion list for the CCAMP working group <ccamp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ccamp>, <mailto:ccamp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ccamp>
List-Post: <mailto:ccamp@ietf.org>
List-Help: <mailto:ccamp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ccamp>, <mailto:ccamp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 24 Sep 2011 08:23:46 -0000

Hi Fred,

Thanks for your useful comments and we will reflect the latest progress of G.709 in the next version.

Please see more in-line below.



Thanks

Fatai

From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Gruman, Fred
Sent: 2011年9月23日 1:26
To: ccamp@ietf.org
Subject: [CCAMP] Questions/comments on OTN signaling

Hello Fatai,

I have some comments/questions on draft-zhang-ccamp-gmpls-evolving-g709-09.

1) I think the draft should discuss the Generalized Label Request object.  Will this object use the new OTN switching capability (Switching Type = 101)?

[Fatai] Yes, agree with you. We have captured this in the FWK document and will update the signaling draft in the next version.

2)  How is ODUflex(GFP) signaled? In general, the draft seems to lack detail on ODUflex(GFP).

More specifically, the draft states "In case of ODUflex(CBR), the Bit_Rate and Tolerance fields MUST be used together to represent the actual bandwidth of ODUflex" and later "In case of other ODUk signal types, the Bit_Rate and Tolerance fields are not necessary and MUST be set to 0."  It is not clear if this implies that ODUflex(GFP) should set Bit_rate and Tolerance to zero.  I would assume ODUflex(GFP) would need Bit_Rate, but unsure if tolerance is needed.

[Fatai] The bit rates and tolerance of ODUflex(GFP) was not standardized until the G.709 Amd2 was issued, so we didn’t touch it in this draft so far.
In the G.709 Amd2, it says: “Any bit rate is possible for an ODUflex(GFP) signal, however it is suggested for maximum efficiency that the ODUflex(GFP) will fill an integral number of tributary slots of the smallest HO ODUk path over which the ODUflex(GFP) may be carried. The recommended bit-rates to meet this criteria are specified in Table 7-8.”

We can understand that ONLY 80 values are allowed  and the intermediate values are not allowed (see Table 7-8 in G.709 Amd2). Each of the 80 values is rigidly associated to a number of tributary slots and that the tolerance is fixed to +/- 100ppm. Note that the tolerance is already comprised in the 80 values.

So, we agree with you that ODUflex(GFP) would need Bir_Rate, but it does not need tolerance.

We will add some text to address ODUflex(GFP).

3) G.709 Amendment 2 (2011-04) Table 7-9 has a row to cover the generic ODUflex(CBR) with notes to the formulas to calculate the number of tributary slots.  Additionally, this table has specific rows to cover ODUflex(CBR) IB SDR, IB DDR, IB QDR, FC-400, and FC-800 and specifies the explicit number of tributary slot assignments when mapped into ODUflex into HO-OPUk).

It seems that the generic formula for ODUflex(CBR) does not result in the same number of tributary slots for some of these client signals.  For example, IB SDR over HO-OPU3 has nominal bit rate of 2,500,000 kbits/s and bit rate tolerance of +/-100ppm (from G.709 Amend2 Table 17-14).  Using the generic ODUflex(CBR) formula, you get:

N = ceiling [(2500000 * (1+100/1e6)) / ( 1254703.729 * (1-20/1e6)) ]
    = ceiling [2500250 / 1254678.635]
    = ceiling [1.99274135]
    = 2

Table 7-9 shows that IB SDR mapped into ODUflex over HO-OPU3 would use 3 tributary slots, not 2.

Please verify my math but if the generic ODUflex formula does not apply to the IB or FC clients, then we may need to have explicit signal types for these clients.

I found that the IB clients do not match the generic formula for some HO-OPUk but the FC clients do match.  This may mean we only would need explicit signal types for:
- ODUflex(CBR)-IB-SDR
- ODUflex(CBR)-IB-DDR
- ODUflex(CBR)-IB-QDR

[Fatai]  If you also take into account the Transcoding Factor described in G.709 and associated to 8B/10B and 64B/65B, you will find the number of tributary slot is correct for your example.

The formulas described in Table 7-9 of G.709V3(12/2009) are as follows:
Number of tributary slots = Ceiling(ODUflex(CBR) nominal bit rate/(T×ODTU2.ts nominal bit rate) × (1+ODUflex(CBR) bit rate tolerance)/(1-HO OPU2 bit rate tolerance)).
Number of tributary slots = Ceiling(ODUflex(CBR) nominal bit rate/(T×ODTU3.ts nominal bit rate) × (1+ODUflex(CBR) bit rate tolerance)/(1-HO OPU3 bit rate tolerance)).
Number of tributary slots = Ceiling(ODUflex(CBR) nominal bit rate/(T×ODTU4.ts nominal bit rate) × (1+ODUflex(CBR) bit rate tolerance)/(1-HO OPU4 bit rate tolerance)).

WITH T specified as follows:

T=16/15 for 8B/10B encoded CBR clients, T=1027/1024 for 64B/66B encoded CBR clients and T=1 for other clients

We will update this draft with this formula:

Number of tributary slots = Ceiling(ODUflex(CBR) nominal bit rate/(T×ODTUj.ts nominal bit rate) × (1+ODUflex(CBR) bit rate tolerance)/(1-HO OPUj bit rate tolerance)).

Inserting also the meaning of T.

So, we don’t need to introduce the new signal types, we just need to use the updated formula.

Please let me know what you think.

Thanks,
Fred