Re: [CCAMP] Draft Text for ITU-T - CCAMP Liason regarding Flexi-grid

Fatai Zhang <> Tue, 18 March 2014 11:46 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 564431A03C9 for <>; Tue, 18 Mar 2014 04:46:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.747
X-Spam-Status: No, score=-4.747 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id KgleFJ-QsUSx for <>; Tue, 18 Mar 2014 04:46:28 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id B47F41A06CC for <>; Tue, 18 Mar 2014 04:46:14 -0700 (PDT)
Received: from (EHLO ([]) by (MOS 4.3.7-GA FastPath queued) with ESMTP id BCE53175; Tue, 18 Mar 2014 11:46:05 +0000 (GMT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Tue, 18 Mar 2014 11:45:53 +0000
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Tue, 18 Mar 2014 11:45:55 +0000
Received: from ([]) by ([]) with mapi id 14.03.0158.001; Tue, 18 Mar 2014 19:45:50 +0800
From: Fatai Zhang <>
To: Ramon Casellas <>, "" <>
Thread-Topic: [CCAMP] Draft Text for ITU-T - CCAMP Liason regarding Flexi-grid
Date: Tue, 18 Mar 2014 11:45:49 +0000
Message-ID: <>
References: <> <> <> <>
In-Reply-To: <>
Accept-Language: zh-CN, en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_F82A4B6D50F9464B8EBA55651F541CF85CAD8F40SZXEMA504MBSchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Subject: Re: [CCAMP] Draft Text for ITU-T - CCAMP Liason regarding Flexi-grid
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussion list for the CCAMP working group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 18 Mar 2014 11:46:32 -0000

Hi Ramon,
You mentioned NCFG and SWG before the question, but you did not specify alternative values for what (e.g, NCFG or SWG or both).
I assume that you meant "Is ITU-T considering alternative values (e.g. 3.125 GHz) of NCFG in the foreseeable future?".
Is ITU-T considering alternative values (e.g. 3.125 GHz) in the foreseeable future?

Best Regards


From: CCAMP [] On Behalf Of Ramon Casellas
Sent: Tuesday, March 18, 2014 6:42 PM
Subject: Re: [CCAMP] Draft Text for ITU-T - CCAMP Liason regarding Flexi-grid

Dear all,

Thanks for your comments. Below a revised text, still open for discussion.

Personally, I am afraid i still don't fully grasp the last bullet, so please elaborate a bit more or re-formulate (Iftekhar, Rajan?)

[Editor: In my limited understanding:
- A NMC as bound to 1 OCh-P by definition of the in-force G.872.
- a Media channel may carry more than 1 OCh-P, but MC != NMC
- With a Optical Tributary Signal (OTS) there is a 1:1 mapping between OTS:NMC.
- A particular case of OTS is an OCh-P
For my understanding, can a OTS group multiple OCh-P?]



In order to progress our work on the draft "Framework and Requirements for GMPLS based control of Flexi-grid DWDM networks" [1] and subsequent solution documents within the IETF CCAMP working group, we would like to receive your comments/clarification as follows (addressing ITU-T experts within Q6, Q12 and Q14):

*    Please comment on future changes regarding the values of nominal central frequency (NCF) granularity [NCFG, currently 6.25 GHz] and slot width granularity [currently 12.5 GHz], as defined in G.694.1. Is ITU-T considering alternative values (e.g. 3.125 GHz) in the foreseeable future? If yes, is it correct to assume, that the following always holds, w.r.t. slot width granularity and NCF granularity?
SWG = 2 * NCFG [Note: changes in these values may require additional code-points within encodings at control plane protocols]

*    Clarification on the maximum values of the slot width (m parameter) and the expected use cases (e.g. to cover the whole C band).
Knowing these values is required since it has an impact on their encoding.

*    Opinion / Clarification on the data plane "hitless" and "hitless" capabilities. Is ITU-T considering any hitless procedure, such as resizing / restoration of a network media channel (in terms of its frequency slot)? Examples of cases where hitless capabilities may be considered are:
o    Case 1: Recovery where the new network media channel uses a diverse path
o    Case 2: shrink / enlarge frequency slot width, invariant NCF (n)
o    Case 3: shift the NCF (n), maintaining the frequency slot width (m)

*    Clarification on the case where an OTUCn is carried by a (co-routed) group of network media channels which must be managed as a single entity (including set up, recovery, and hardware cross-connection). If this is in scope, what is the estimated availability of ITU-T Recommendation covering this new requirement?
[Note: CCAMP has considered so far the following requirement: "The control plane architecture SHOULD allow multiple media channels to be logically associated.  The control plane SHOULD allow the co-routing of a set of media channels logically associated". If ITU-T covers this new requirement, it may have an impact on the control plane representation and related procedures]

*    Current in-force G.872 recommendation defines that a media channel may carry more than one OCh-P signal. It also defines that a network media channel is a specific use of media channel with a single OCh-P.  May a network media channel be defined as associated with more than one OCh-P?