Subject: [CCAMP] Disscussion and contribution in RWA drafts (encode and info) on the matter of wavelength converters and regenerators

From: "PELOSO, PIERRE (PIERRE)" <[email-masked]>
Date: Tue, 23 Feb 2010 11:50:09 +0100

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.
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...
Even when examining the ospf derivations of these drafts, I still find difficulties in figuring how this would run.
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?

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

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.