Subject: Re: [CCAMP] Disscussion and contribution in RWA drafts (encode and info) - switching constraints

From: Greg Bernstein <[email-masked]>
Date: Wed, 03 Mar 2010 09:32:12 -0800

Hi Pierre, see comments below. Note that all the updated encoding 
documents and background material is also available at: 
http://www.grotto-networking.com/wsonEncode
Also from the high level to more detailed we have the following documents:
                         WSON Framework
                          WSON Information Modeling for RWA
              General Constraint Encoding                         WSON 
Specific Encoding
               General OSPF Ext (not a WG draft yet)       WSON 
Compatibility OSPF Ext

Regards
Greg

PELOSO, PIERRE (PIERRE) wrote:
> Hi Greg and CCAMPers,
>
> For clarification purposes, I've taken the freedom to clean a bit the original email and separate its content in smaller pieces.
> This one deals specifically with the clarification of the node switching constraints and resource identification:
>
> - Pierre
>
> BERNSTEIN, GREG (wrote):
>   
>> Hi Pierre and fellow CCAMPers, see response in line below.
>>
>> Greg
>>
>> PELOSO, PIERRE (PIERRE) wrote:
>>     
>>> Hi Greg, Young and CCAMP'rs,
>>> [...]
>>> 1. The drafts propose different pieces of information to describe the node internal switching structure (and constraints) and to describe the O-E-O resources inside the node. However, they do not describe how these pieces of information fit together in order to build the global picture of the node internal switching constraints. For example, considering  the list of O-E-O resources how you determine which of those are available from a given incoming link to a given outgoing link, what are the associated wavelength restrictions associated, etc...
>>>  
>>>       
>> --> Hmm, maybe this section needs more explanatory text. It looks like you gave the high level summary in your point "2" above. In more detail: we break the resource pool into the largest blocks possible (with identical ingress, egress and wavelength constraints), we specify the ingress connectivity constraints to the blocks and ingress wavelength constraints to each block. Similarly we specify the egress connectivity constraints from each block and any wavelength constraints associated with those. If needed a minimal amount of state information can be associated with each resource block (number of resources available in each block).  We have a paper in progress that shows this technique used to model a fairly wide collection of different combined switch architectures gathered from the literature. We can make a preliminary draft available to those interested in the details.
>>     
>
> PP: I have no issue with the capabilities of your technique to describe a node and its O-E-O resources whatever the architecture used. I am more concerned with the lack of detail provided in current drafts.
> At this stage, there are too many unspecified details for implementing the drafts in a unique manner.
> E.g. There is supposedly a switching matrix information to depict the node internal switching structure.
> Is it supposed to be in [Gen-Encode] draft under preparation? In previous version of the draft this object was refering to "port ID", are those supposed to be "link local/remote identifiers", I understand yes from your last email but would this appear in the draft? Then should'nt there be a recommendation to use "LLRI" in the Link information object as well?
>   
--> [Gen-Encode] is now published. The "Link Set Field" which is used to 
specify the connectivity matrix uses "Link Identifiers" and supports 
different formats including Link Local Identifier.
> When adding the resource pool, things are getting more complex:
> Can there be more than one Resource pool object in the description of a node? Is this object supposed to be a top-level TLV or is it supposed to be a sub-TLV inside a Node object? 
>   
--> The TLV structuring needs to be given in a protocol specific draft 
such as OSPF or IS-IS extension. Young's WG draft on OSPF compatibility 
will be updated to include this as an optional sub-TLV within a Node 
Attributes TLV (http://www.ietf.org/id/draft-ietf-ospf-te-node-addr-07.txt).
> A "resource pool" object is composed of:
>     - A "resource block info" basically a list of resource ID with their features regarding signal (incoming and outgoing)- is that right? Then I imagine that we will have as many resource block info object as there are different combination of signal features in the node.
>   
--> Yes a list of resource IDs group with descriptions of their 
properties, but NOT a set of all combinations.
>     - A "resource block accessibility" basically a list of (resource blocks, switching constraints on each side of the block). Then I imagine that the resource blocks here have nothing to do with the one used for the "resource block info"? Are the switching constraints to be related to the Link information object, then once again the draft would benefit from refering to "link local/remote identifiers"?
>   
--> These are the same blocks as used in the info. The draft uses a 
general Link Identifier that includes the link local identifier.
>     - A "resource wave constraints" basically a resource block with wavelength constraint on each side of the block. Is that to depict: 1.the wavelength constraints of the architecture, 
Yes.
> 2. the limitations of the resources/devices or 
Yes
> 3.the usage of the wavelengths by other resources sharing the same port? 
No.
> Because some of these elements are dynamic and some are static. And the grouping of resources in blocks will follow different rules depending on what is to be depicted with that (leading certainly to a third list of resource blocks). Hence that is giving me the idea that something is missing, as we would certainly like to depict all these 3 constraints and only one can be depicted there, isn't it?
>   
I'm not sure if your third constraint requires us to carry additional 
internal state, or if not it would seem redundant with the wavelength 
usage state of the ingress or egress ports. For details of modeling 
considerations and application to a wide range of switch architectures 
including regenerators or wavelength converters see a draft of our 
paper: 
http://www.grotto-networking.com/sites/default/files/ModelingSwitchesConvertersRegensV02f.pdf
> To summarize, I end up having the impression that a node and its switching matrix is depicted twice in the same object. A first time for the bypassing traffic and a second one comporting the additional information of the resources. 
--> Yes. Typically a ROADM will not have regenerators or wavelength 
converters so the resource pool would not be used. Or in the case of a 
translucent network with OEO switches the connectivity matrix would not 
be used. In the most general case we have both general switching 
constraints and constraints on how we get to/from processing resources.
> Then I have the feeling that gathering all the information relative to the switching constraints in a unique object with more ports would be more efficient as this object would never change and the ports would be defined once and for all. There would be the external ports that are referring to the "WDM link information" and using the LLRI of the WDM links. And there would be the internal ports corresponding to physical pools of ressources.
> This modification is just a minor adaptation of your technique, using most of the same encodings, did you try this direction ?
>   
--> Two issues here. Separating "dynamic" versus "static" information 
with respect to updates, and how to organize sub-TLVs. The dynamic 
information has been separated from the static in encoding the exact 
packaging depends on the routing protocol. In Fatai's OSPF draft we 
propose a multiple LSA instance approach. In addition with Young's 
Compatibility OSPF extensions we will indicate that the pool related 
sub-TLV get incorporated into the same Node Attributes TLV as in Fatai's 
draft.
> Pierre

-- 
===================================================
Dr Greg Bernstein, Grotto Networking (510) 573-2237