Re: [CCAMP] Flexi-Grid control plane requirements - was: Generalized Labels for the Flexi-Grid in LSC Label Switching Routers

Oscar González de Dios <> Wed, 12 February 2014 14:47 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 627281A09A5 for <>; Wed, 12 Feb 2014 06:47:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.449
X-Spam-Status: No, score=-4.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id iAqFXX4xAZub for <>; Wed, 12 Feb 2014 06:46:59 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 2E9B81A09A3 for <>; Wed, 12 Feb 2014 06:46:58 -0800 (PST)
Received: from sbrightmailg01.hi.inet (sbrightmailg01.hi.inet []) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0N0W009AQ128TL@tid.hi.inet> for; Wed, 12 Feb 2014 15:46:56 +0100 (MET)
Received: from dequeue_removeroute (tid.hi.inet []) by sbrightmailg01.hi.inet (Symantec Messaging Gateway) with SMTP id D4.BE.03314.0698BF25; Wed, 12 Feb 2014 15:46:56 +0100 (CET)
Received: from (mailhost.hi.inet []) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0N0W009AM128TL@tid.hi.inet> for; Wed, 12 Feb 2014 15:46:56 +0100 (MET)
Received: from EX10-MB2-MAD.hi.inet ([]) by EX10-HTCAS8-MAD.hi.inet ([fe80::41c8:e965:8a6:de67%11]) with mapi id 14.03.0158.001; Wed, 12 Feb 2014 15:46:55 +0100
Date: Wed, 12 Feb 2014 14:46:55 +0000
From: Oscar González de Dios <>
In-reply-to: <>
X-Originating-IP: []
To: Ramon Casellas <>, "" <>
Message-id: <>
Content-id: <42939A369E59CD4BBBCC642BC71F1E00@hi.inet>
MIME-version: 1.0
Content-type: text/plain; charset="iso-8859-1"
Content-language: es-ES
Content-transfer-encoding: quoted-printable
Accept-Language: es-ES, en-US
Thread-topic: [CCAMP] Flexi-Grid control plane requirements - was: Generalized Labels for the Flexi-Grid in LSC Label Switching Routers
Thread-index: AQHPJkvX7jXqbdqcXkqxp10OFKng7ZqxtfUA
user-agent: Microsoft-MacOutlook/
X-AuditID: 0a5f4068-b7fe58e000000cf2-b0-52fb8960f27e
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrFLMWRmVeSWpSXmKPExsXCFe/ApZvQ+TvIYP1aSYsnc26wODB6LFny kymAMYrLJiU1J7MstUjfLoEro+PDT6aCxc4VzZNnsDQw7jDrYuTkkBAwkXh7+g8zhC0mceHe erYuRi4OIYEDjBIHPv1nhnC+M0p0XN/GClIlJLCRUeLnfhYQm0VAVWLl9VXsIDabgIPEukW9 YN3CAh2MEhvPHmMESXAKqEu8OH+PHWKFgsSfc4/BmkUE/CSalsxiArF5BbQljj7cBFTDwcEs YCYxcRU/RFhQ4sfke2DlzAI6Er3fvzFD2OISc35NZIWwtSWevLsAZjMKyEqsPH+aEeQGEYFO oBvOvWCF2GUk0d2zCmyQqICeRNuxM1D3CEgs2XMe6n1RiZeP/7FOYBSfhXDGLCRnzEJyxiwk Z8xCcsYCRtZVjGLFSUWZ6RkluYmZOekGhnoZmXqZeaklmxgh8ZWxg3H5TpVDjAIcjEo8vIye v4KEWBPLiitzDzFKcDArifAaNf8OEuJNSaysSi3Kjy8qzUktPsTIxMEp1cC4py919syab9zq /dMFtojF72ndz3+HpTSxVNKUV/7y/dnpS5Tue0+fmsdg1vTDYZLlhhVLvdkW+CuLRi29lh5Y MM0mvK1WITjnYnPOTNct93onKJ9jUl92wznpWqXg/IKAbPMgV0Wl9+0axj+jCrqrgrLanYou MuYtdDI49kj6kPA1da8nHkosxRmJhlrMRcWJAIzPS82NAgAA
Subject: Re: [CCAMP] Flexi-Grid control plane requirements - was: Generalized Labels for the Flexi-Grid in LSC Label Switching Routers
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: Wed, 12 Feb 2014 14:47:03 -0000

Dear Iftekhar, Ramon, all

        Further comments inline

>Dear Iftekhar, All,
>Thanks for volunteering to contribute with an initial set of
>requirements. Since I am going through Iftekhar requirements and how to
>map them into the framework document, I would like some clarifications
>(including comments from other authors and contributors). Please, see my
>comments inline
>El 08/02/2014 8:46, Iftekhar Hussain escribió:
>> R1: Single Frequency Slot Network Connection
>> The control plane SHALL be able to support network media channels
>>containing a single frequency slot.
>Ramon> Ok.
>> R2: Frequency Slot Width Range
>>         The control plane protocols SHALL allow flexible range of
>>values for the frequency slot width (m)  parameter. Specifically, the
>>control plane SHALL allow  setting up a network medial channel with
>>frequency slot width (m) ranging from a minimum of 12.5GHz to a maximum
>>of the entire C-band with a slot width granularity of 12.5GHz.
>Ramon> Ok.
>> R3: Finer Granularity Slot Width
>> The control plane SHOULD be architected to allow support network media
>>channels with frequency slot width m ranging from a minimum of 6.25GHz
>>to a maximum of the entire C-band with granularity of 6.25GHz
>Ramon> I would disagree at this point. I don't know how to map this
>requirement in view of the framework text that defines a slot width with
>a minimum of m=1 for SWG= 12.5 GHz. Like in some requirements below, I
>don't think it is a matter of qualifying with SHALL o SHOULD a given
>capability that sticks / does not stick to the current agreed text.
[Oscar] I do not fully understand the requirement as it is written. Do you
mean having, instead of a granularity of 12,5, have other values for the
SWG? Current granularity is set to 12,5 (full stop). There has been a set
of emails in
the ccamp mailing list questioning the need of including a field
Indicating the slot width granularity, and I have not seen agreement yet.
Gabriele reported Optical Modules with very fine granularity, 1 GHz.

Maybe it is a question to ask our dear ITU data plane folks, whether
SWG are envisioned. In such case, I will be more than happy to include it
as a requirement. Otherwise, I would rather drop it at present.

>> R4.: Flexible Mapping of Media Channels on the ITU-T defined Flexible
>> The control plane SHALL allow mapping of network media channels on any
>>arbitrary nominal central frequency location (i.e., n ) on the ITU
>>defined Flexible Grid.
>Ramon> This seems to me that we would be excluding hardware that has
>some constraints related to nominal central granularity. Am I missing
[Oscar] Maybe a set of requirements can be added to the document
regarding feasible combinations of n and m in the hardware.

>> R5: L-band and S-band
>> The control plane architecture SHOULD allow  for  L-band and S-band
>Ramon> seems ok, any other comment?
>> R6: Resizing of the Frequency Slot Width
>>          The control plane SHALL allow resizing (grow or shrink)
>>frequency slot width of a network media channel. In certain scenarios,
>>the resizing of frequency slot  of a network media channel  MAY cause
>>temporary data plane disruption.
>Ramon> My only comment here is whether SHALL or SHOULD. Isn't resizing a
>somehow optional feature w.r.t a minimum set of functions? - I have no
>strong opinion here, quite willing to hear other views.
[Oscar] It is necessary to add the data plane disruption here? What does
it imply for the control plane? At least, I would like that the change of m
(I guess that is the kind of resizement you refer to) should be hitless
in terms of control plane.

>> R7. Network Media Channel Restoration
>>        The control plane SHALL support network media channel
>> a)   During the restoration process, the control plane SHALL allow to
>>pick a different frequency slots for the media channel, keeping
>>frequency slot width (m) the same
>> b)   During the restoration process, the control plane SHOULD allow
>>changing of m (in coordination with client e.g., needing to change
>>modulation, using different frequency slot width for same capacity to
>>close restoration path)
>Ramon> ok
>> c)   During the restoration process, the control plane SHOULD allow
>>changing from single frequency slot (m) to multiple frequency slots
>>(e.g., m1, m2) (to deal with blocking / fragmentation on possible
>>restoration paths  where m1 + m2 might be greater than or equal to m
>>       d)    Network media channel restoration with optional
>>pre-computed path (with or without resource reservation) SHALL be
>>       e)    Revertive and Non-Revertive restoration options SHALL be
>Ramon> IMHO, we would need to work on this requirement a bit more, from
>a descriptive text perspective, detailing inverse multiplexing of a OTS
>over more than one frequency slot, before adding it as a formal
>requirement. As a general note, I am not in a confident position to tag
>requirements with SHALL/SHOULD. Feedback and comments welcome.
>> R8: Optical Spectrum Network Usage
>> The control plane SHALL be able to keep track of (gather/disseminate)
>>information about optical spectrum usage in the network including (but
>>not limited to):
>>      a)      Available Optical Spectral Slices
>>     b)      Provisioned Optical Spectral Slices
>Ramon> I believe the term slice is undefined. the part regarding routing
>also needs an overhaul in the framework text.  I would be more in favor
>of using the term frequency slot, correct?
>> R9:  Routing of Optical Signals with Different Modulation Formats
>>       The control plane SHALL be capable of placing optical signals
>>with different modulation formats on the Flexible Grid network media
>Ramon> We have not addressed anything regarding  modulation formats or
>the signal layer in general. I wonder whether, at this stage, mentioning
>modulation formats explicitly (out of the descriptive text) is
>> R10: Network Media Channels with Multiple Frequency Slots
>> The control plane architecture SHALL allow network media channels with
>>multiple contiguous or non-contiguous frequency slots. In this scenario,
>>it SHALL be possible to co-route all frequency slots associated with a
>>given network media channel.
>Ramon> The current frawework text, unless mistake from my part, does not
>cover a network media channel over multiple (contiguous or not)
>frequency slots. Should we re-phrase this as a "The control plane
>architecture SHOULD allow multiple media channels to be co-routed and
>logically associated" ?  (editor: I am thinking of association objects,
>or channelsets, etc.)
[Oscar] Agree with Ramon, one minor comment: The 'logical association' of
media channels has no name yet. Do we ask ITU for a term on that? Do we
use an already existing IETF term?

>> R11: Embedded Control Channel for Network Media Channel Routing and
>> The framework SHALL support the standard mechanism for ECC defined in
>>[i.e., OSC based control channel], for OAM features required to be
>>supported between network elements deploying network media channels over
>>Flexible Grid
>Ramon> Could you please provide the [i.e., OSC based control channel]
>reference?  I am not sure of making it a SHALL requirement to support
>OSC based control channel. Also, your requirement mentions "network
>media channel routing and signalling" but the text sticks to OAM. Could
>you please clarify?
>Thanks again for moving this forwqaa
>CCAMP mailing list

[Oscar] We (Ramon and me), as editors of the document, will incorporate
the requirements that have an agreement and publish them for a new
version. Please consider commenting on the set of requirements proposed by
Iktekhar and/or add more requirements.

Best Regards,



Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo.
This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at: