Subject: Re: [CCAMP] Disscussion and contribution in RWA drafts (encode and info) on the matter of Wavelength Converters and Regenerators

From: Greg Bernstein <[email-masked]>
Date: Tue, 23 Feb 2010 08:18:55 -0800

Hi Pierre and fellow CCAMPers, see response in line below.

Greg

PELOSO, PIERRE (PIERRE) wrote:
> Hi Greg, Young and CCAMP'rs,
>  
> I have read carefully the recents updates on draft-ietf-ccamp-rwa-info and draft-ietf-ccamp-rwa-wson-encode, particulary to all the ones related to the description of O-E-O ressources.
> Some of these updates seem to take converging directions (according to what we discussed earlier this month), specifically:
> 1. Common way of handling: regeneration and wavelength conversion as in fine both these functions are achieved by the same type of equipments and hence their constraints are the same.
>   
--> Yes. This should be able to handle other processing resources such 
as those related to performance monitoring too. Hence we just call these 
resources rather than O-E-O resources, though the initial application 
are to OEO type resources.
> 2. Better distinction is made between the accessibility of these resources and their capabilities especially regarding the wavelength range. (Having a wavelength available to reach an equipment is not equivalent to the fact that this equipment is able to handle this wavelength - one of this piece of information is dynamic the other one is static). This is specifically a critical difference when multiple resources are gathered in a pool.
>
> There are also some areas where I view some enhancements as being beneficial:
> 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.
> Even when examining the ospf derivations of these drafts, I still find difficulties in figuring how this would run.
>   
--> The OSPF versions are not quite up to date with the latest info and 
encoding drafts yet.
> 2. Regarding the dynamic and static information that can be updated with different time-constraints (e.g. draft info p6), I notice that, for example in the node, the dynamic fields of info are inside the sub-TLV if not in sub-sub-TLV. I do not know how IGPs are supposed to handle that. E.g. would OSPF-TE allow the update of a LSA with a only a sub-set of its sub-TLVs, without discarding all the other sub-TLVs?
>   
--> We don't  specify TLV structure in the info draft, but identify 
relatively static versus dynamic information. Hence in section 5.1 where 
we give the resource pool model and it includes the "resource block 
state" information we are giving the complete information model rather 
than specifying which items should be TLVs, sub-TLVs, sub-sub-TLVs, 
etc... Later in the document (section 7) we explicitly point out the 
"dynamic" information. In the encoding drafts this is then used to guide 
the creation of separate TLVs/sub-TLVs.
> To follow a contributive approach, I would propose a slightly different layout of information inside IGP that would address the two points above in a simple fashion.
> 1. Have a "Node information" that holds only static information: It would detail the switching constraints (both spatial and spectral). This Node description would refer to "Link local/remote identifiers" to provide ports references compliants with "Link information" (e.g. link opaque LSA). The switching matrix description would also list the O-E-O pools ports.
>   
--> The encoding draft takes this approach. The text may not be clear 
enough...
> 2. Have an "O-E-O pool information" which would need to be updated only when an allocation/disallocation concerns a ressource in the pool. This "O-E-O pool information" would then be a Top-level TLV, containing description of the ressources of the pool, their availability, their accessibility (in terms of wavelength), and their ports identifiers.  
>   
--> This is what the "resource block state" information is for and it's 
broken out into a separate TLV in the encoding document. Note that exact 
usage would be specified in a protocol specific document, e.g., OSPF.
> I welcome further discussions on this proposal that you can find further detailed hereafter under the form of a piece of text that could be integrated in an ospf-draft.
>
> Regards,
>
> Pierre
> ________________________________________
>
> X. O-E-O Pool Information
> This draft defines a new top-TLV named "O-E-O pool Attribute" TLV. It carries attributes related to a pool of Optical-Electric-Optical regeneration resource, thus allowing route computation to take into account available signal regenerators in the network. Multiple O-E-O ressources are logically gathered in a pool when they share a common transmission media before (and after) entering (exiting) the actual switching matrix of the node. This Node Attribute TLV contains one or more sub-TLVs. 
> The O-E-O pool information related to pools in WSON nodes include Pool ID, lists of available wavelength on the ingress and egress side of the pool, and the features of the O-E-O in the pool on the ingress and egress side of the pool. These pieces of information are defined in this document. The O-E-O pool information would also include some sub-TLVs identical to sub-TLVs of the TE-link top-TLV: TE-metric [rfc3630], Administrative Group [rfc3630], Link Local/Remote Identifiers [rfc4203], Shared-Risk Link Group [rfc4203].
> The following new sub-TLVs are added to the "O-E-O Pool Attribute" TLV. Detailed description for newly defined sub-TLVs is provided at the end of the section.
> Sub-TLV Type	Length	Name
> 	TBD		4 Bytes	Pool ID
> 	TBD		variable	Ingress Available Wavelength
> 	TBD		variable	Egress Available Wavelength
> 	TBD		fixed		Ingress O-E-O Features
> 	TBD		fixed		Egress O-E-O Features
> In "O-E-O Pool Attribute", the sub-TLVs "Ingress Available Wavelength" and "Ingress O-E-O Features" are mandatory, the other sub-TLVs listed above are optional. The omission of egress sub-TLV implies a symmetry status of egress and ingress.
>
> The following sub-TLVs to the "O-E-O Pool Attribute" TLV are identical to the ones defined respectively in [RFC3630] and [RFC4203], and being defined for the TE-link top-TLV. Detailed description for newly defined sub-TLV is provided at the end of the section.
> Sub-TLV Type	Length	Name
> 	TBD		4 Bytes	TE-metric [alike RFC3630]
> 	TBD		4 Bytes	Administrative Group [alike RFC3630]
> 	TBD		8 Bytes	Link Local/Remote Identifiers [alike RFC4203]
> 	TBD		variable	Shared Risk Link Group [alike RFC4203]
> In "O-E-O Pool", the sub-TLV "Link Local/Remote Identifiers" is mandatory as it is needed to ensure the consistency with the Node Information described in Section 2. The other sub-TLVs listed above are optional. 
>
> X.1. Pool ID
> This optional sub-TLV can be used to provide an identifier to the regenerator pool.
>
> X.2. Ingress/Egress Available Wavelength
> These sub-TLVs provide the list of available wavelength respectively to reach the pool from the Node and to reach the Node from the pool (meaning first before and second after the signal crosses the O-E-O). These sub-TLVs share the same format as the Available Wavelength sub-TLVs depicted in [WSON-Encode]. The omission of the egress sub-TLV is depicting a symmetrical usage of wavelength on each side of the pool.
>
> X.3. Ingress/Egress O-E-O Features
> Both these sub-TLVs provide the features of a given O-E-O resource, respectively on its incoming and on its outgoing side. The encoding of this sub-TLV is not provided yet, but is likely to resemble elements of [OSPF-signal-compatibility] and of Wavelength Converter Range define in [WSON-encode]
> Elements of the sub-TLVs:
>  - Signal Type: Modulation Format, Bit-Rate, Modulation parameters, etc...
>  - Wavelength constraints: (alike Wavelength Converter Range).
> A pair of these sub-TLVs is describing a given O-E-O piece of equipment. Hence, there will be an instance of a pair of these sub-TLVs for each O-E-O resource present in the pool, which shall in fine construct a list of these sub-TLVs to describe the list of O-E-O resource.
> The omission of the egress sub-TLV translates symmetry in the features of the O-E-O on its ingress and on its egress side. 
>
>
>   

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

---

From: "PELOSO, PIERRE (PIERRE)" <[email-masked]>
Date: Fri, 26 Feb 2010 23:30:22 +0100

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):
>> [...]
>--> 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?

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? 
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.
    - 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"?
    - 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, 2. the limitations of the resources/devices or 3.the usage of the wavelengths by other resources sharing the same port? 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?

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. 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 ?

Pierre