Internet Engineering Task Force P. Peloso, Ed.
Internet-Draft Alcatel-Lucent
Intended status: Standards Track G. Martinelli
Expires: January 12, 2012 Cisco
J. Meuric
France Telecom
C. Margaria
Nokia Siemens Networks
July 11, 2011
OSPF-TE Extensions for WSON-specific Network Element Constraints
draft-peloso-ccamp-wson-ospf-oeo-04
Abstract
The original content of this internet draft was to propose some
extentions to OSPF encoding in the context of Wavelength Switched
Optical Networks, especially for internal constraints of optical
network elements. General description can be found in the framework
document.
This update of the document still aims at specifying the detailled
structure of OSPF LSAs for WSONs. Nevertheless, the proposed LSA
layout slightly differs from the current content of the information
model and encodings drafts. As a result, the following sections
highlight the differences between both approaches and summarize why
the authors think these CCAMP's drafts would benefit from an update
according to the proposed description.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 12, 2012.
Copyright Notice
Peloso, et al. Expires January 12, 2012 [Page 1]
Internet-Draft OSPF-TE extensions for WSON July 2011
Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Peloso, et al. Expires January 12, 2012 [Page 2]
Internet-Draft OSPF-TE extensions for WSON July 2011
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
2. Information Model . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Summary of Information Model Changes . . . . . . . . . . . 5
2.2. Node Information (WSON specific) . . . . . . . . . . . . . 6
2.2.1. Label Restrictions . . . . . . . . . . . . . . . . . . 6
2.2.2. Resource Pools, Resource Blocks and Resource
Description Containers . . . . . . . . . . . . . . . . 7
2.2.3. Resource Pool Accessibility . . . . . . . . . . . . . 11
2.2.4. Resource Pool ID . . . . . . . . . . . . . . . . . . . 12
2.2.5. Resource Block State . . . . . . . . . . . . . . . . . 12
2.2.6. Resource Description . . . . . . . . . . . . . . . . . 13
2.2.7. Resource Pool Wavelength Constraints . . . . . . . . . 14
2.2.8. Shared Access Available Wavelengths . . . . . . . . . 15
3. Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.1. Node related generic encodings . . . . . . . . . . . . . . 15
3.2. Node related WSON specific encodings . . . . . . . . . . . 16
3.2.1. Label Restrictions . . . . . . . . . . . . . . . . . . 16
3.2.2. Id Set Field . . . . . . . . . . . . . . . . . . . . . 16
3.2.3. Resource Pool Accessibility . . . . . . . . . . . . . 17
3.2.4. Resource Block State . . . . . . . . . . . . . . . . . 18
3.2.5. Resource Description . . . . . . . . . . . . . . . . . 18
3.2.6. Resource Pool Wavelength Constraints . . . . . . . . . 21
3.2.7. Shared Access Available Wavelengths . . . . . . . . . 22
3.2.8. Resource Pool . . . . . . . . . . . . . . . . . . . . 22
3.2.9. Resource Description Container . . . . . . . . . . . . 23
3.3. Link related encodings . . . . . . . . . . . . . . . . . . 23
4. OSPF-TE Extensions . . . . . . . . . . . . . . . . . . . . . . 24
4.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 24
4.2. Link top level TLV . . . . . . . . . . . . . . . . . . . . 25
4.3. Node Attribute top level TLV . . . . . . . . . . . . . . . 26
4.4. Resource Pool top level TLV . . . . . . . . . . . . . . . 26
4.5. Resource Description Container top level TLV . . . . . . . 26
4.5.1. Resource Description sub-TLV . . . . . . . . . . . . . 27
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27
6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 27
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
8. Security Considerations . . . . . . . . . . . . . . . . . . . 28
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28
9.1. Normative References . . . . . . . . . . . . . . . . . . . 28
9.2. Informative References . . . . . . . . . . . . . . . . . . 29
Appendix A. Solution(s) Evaluation . . . . . . . . . . . . . . . 29
A.1. RBNFs Comparison . . . . . . . . . . . . . . . . . . . . . 30
A.2. Depiction of the considered cases for evaluation . . . . . 32
A.3. Comparing evaluation of the solutions . . . . . . . . . . 34
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35
Peloso, et al. Expires January 12, 2012 [Page 3]
Internet-Draft OSPF-TE extensions for WSON July 2011
1. Introduction
The original content of this internet draft was to propose some
extentions to OSPF encoding in the context of Wavelength Switched
Optical Networks, especially for internal constraints of optical
network elements. General description can be found in the framework
document [RFC6163].
This update of the document still aims at specifying the detailled
structure of OSPF LSAs for WSONs. Nevertheless, the proposed LSA
layout slightly differs from the current content of the information
model [I-D.ietf-ccamp-rwa-info] and encodings
[I-D.ietf-ccamp-rwa-wson-encode] drafts. As a result, the following
sections highlight the differences between both approaches and
summarize why the authors think these CCAMP's drafts would benefit
from an update according to the proposed description.
More specifically, the sections below follow the scope of current
documents, namely information model, encodings and OSPF-TE
extensions. Building the latter allowed to identify some
improvements which are described in the two former parts. In both,
the line has been drawn between the optical information that can be
specified by using generic protocol extensions and the one requiring
some WSON-specific objects, as agreed by the working group.
1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
2. Information Model
This section provides a model of information needed by the routing
and wavelength assignment (RWA) process in wavelength switched
optical networks (WSONs). The purpose of the information described
in this model is to facilitate constrained optical path computation
in WSONs. This model takes into account compatibility constraints
between WSON signal attributes and network elements but does not
include constraints due to optical impairments.
The reduced Backus-Naur form (RBNF) syntax of [RFC5511] is used to
aid in defining the RWA information model.
The text in the following reports every WSON information model
modification compared to [I-D.ietf-ccamp-rwa-info]. Whenever a RBNF
term is used without explicit definition we assume the same format
Peloso, et al. Expires January 12, 2012 [Page 4]
Internet-Draft OSPF-TE extensions for WSON July 2011
and semantic of the original information model.
An initial sub section here below reports a summary of changes
introduced by this document.
2.1. Summary of Information Model Changes
In this document, most of the concepts and definitions from
[I-D.ietf-ccamp-rwa-info] remain the same. For instance, a "Resource
Block" is still "a group of devices with same features and same
connectivity constraints".
Compared to the aforementioned document, the following main changes
should be noticed:
1. The Resource Pool entity is introduced into the model, allowing
the definition of several resource entities per node, which can
be advertised independantly. A "Resource Pool" is defined as a
group of resource blocks with same connectivity constraints.
Several Resource Pools can be defined to associate them with
different properties. The goal is to decrease the size of OSPF
advertisement upon LSP changes (setup or tear down).
2. The connectivity matrix, defining the node capabilities on
interconnection of external links, is used in order to describe
connectivity constraints between node-external links and the
resource pools. Two advantages can be stressed. First, it
gathers all the static information into a node LSA, which OSPF-TE
is not required to advertise upon LSP updates. Then it limits
the number of connectivity representations introduced by
[draft-ietf-rwa-info] (which proposes similar TLVs in different
LSAs).
3. The scope of Resource Block Information is reduced, and focuses
only on resource/device description. The described device are
then efficiently instantiated by refering to these defined types.
This allows to separate the physical resource characteristics
from the way they are arranged in the node, thus having the
description completely independent from the node design.
As a result, this method allows to share resource description for all
the identical blocks of a node, thus decreasing the total size of
information. Furthermore, as this information is very static and
common to several resource blocks, it can be advertised and refreshed
independently to any other information.
Peloso, et al. Expires January 12, 2012 [Page 5]
Internet-Draft OSPF-TE extensions for WSON July 2011
2.2. Node Information (WSON specific)
As presented in [RFC6163] a WSON node may contain electro-optical
subsystems such as regenerators, wavelength converters or entire
switching subsystems. The model present here can be used in
characterizing the accessibility and availability of limited
resources such as regenerators or wavelength converters as well as
WSON signal attribute constraints of electro-optical subsystems. As
such this information element is fairly specific to WSON
technologies.
2.2.1. Label Restrictions
This section is a preamble presenting the Label Restriction entity,
which is refered many times later in this document.
Wavelength constraint are used in different part of the information
model, either as static constraints (in the resource pool as
RPWvlConstraints, and the resource block IngressWaveConstraint and
EgressWaveConstraint) or representing dynamic properties of a given
element (SharedAccessWvls in resource pool). In the GMPLS context
Wavelengths are physical instance of Labels.
The wavelength constraints used in this document, although having
different semantic, refer to the same notion of list of wavelength.
Those constraints apply in addition to either the incoming part of a
device (or group of device), the outgoing part or both if the
constraint is the same, which is for instance not unusual for static
wavelength constraint.
To support this concept, this section defines a field:
LABEL_RESTRICTIONS
that carry a label set information and for which direction this label
restriction is valid. The directions considered is upstream,
downstream or both. The label set information is the one defined in
[I-D.ietf-ccamp-rwa-info] as AvailableLabel.
This encoding is reused in different TLV or sub-TLV for different
semantic but do not require to define a TLV per direction.
------
DELTA:
Peloso, et al. Expires January 12, 2012 [Page 6]
Internet-Draft OSPF-TE extensions for WSON July 2011
- Define a generic information for label restrictions
- Reuse generic label set and provide a compact representation
2.2.2. Resource Pools, Resource Blocks and Resource Description
Containers
As presented in [RFC6163], a WSON node may include regenerators or
wavelength converters arranged in shared pools, and can include OEO
based WDM switches as well. There are plenty approaches used in the
design of WDM switches containing regenerator or converters.
However, from the point of view of path computation the following
need to be known:
1. The nodes that support regeneration or wavelength conversion.
2. The accessibility and availability of OEO devices to convert from
a given ingress wavelength on a particular ingress port to a
desired egress wavelength on a particular egress port, which are
summarized under the accessibility constraints.
3. Limitations on the types of signals that can be converted and the
conversions that can be performed, namely the processing
capabilities.
For modeling purposes and encoding efficiency regenerators or
wavelength converters with identical limitations and/or processing
and accessibility constraints are grouped into "blocks". Such blocks
can consist of a single resource, though grouping resources into
blocks leads to more efficient encodings. Then, these resource
blocks are gathered once more into resource pool, for which the
blocks share the same accessibility constraints. OEO devices sharing
accessibility constraints are likely to being multiplexed on a given
piece of equipment (like an Optical Amplifier, a splitter, a
Wavelength Selective Switch port, a length of fiber...).
Definitions:
- Resource Block: A group of resources sharing both the same
processing properties and the same accessibility constraints.
Each Resource Block can contain a different number of ressources,
but all the resources constituting the block are identical
devices.
- Resource Pool: A group of resources sharing the same
accessibility constraints, hence a Resource Pool becomes a group
of Resource Blocks sharing the same accessibility constraints.
Each Resource Pool can contain a different number of blocks, each
Peloso, et al. Expires January 12, 2012 [Page 7]
Internet-Draft OSPF-TE extensions for WSON July 2011
of different size, as long as all the devices in the pool are
subject to the same accessibility constraints regarding the way
these are linked to ingress and egress links of the WSON node
containing the pool.
The following picture represents the model of WSON nodes with the
help of Resource Blocks and Resource Pools entities.
+-----------+
I1 +-----------+ | RP #1 | +-----------+ E1
---->| | | +-------+ | | +---->
I2 | | | | Rb #1 | | | | E2
---->| | | +-------+ | | +---->
| | | +-------+ | | |
| Resource +------+ | | +------+ Resource |
| Ingress | | | Rb #2 | | | Egress |
| Connectiv | | | | | | Connectiv |
| Matrix | | +-------+ | | Matrix |
| | +-----------+ | |
| | +-----------+ | |
I3 | | | RP #2 | | | E3
---->| | | +-------+ | | +---->
I4 | | | | Rb #3 | | | | E4
---->| +------+ +-------+ +------+ +---->
IN | | | +-------+ | | | EM
---->| | | | Rb #P | | | +---->
| | | +-------+ | | |
+-----------+ +-----------+ +-----------+
Figure 1
This figure shows a Resource Ingress Connectivity Matrix and another
one of the egress, the model from [I-D.ietf-ccamp-rwa-info] gathers
both these connectivity matrix inside a Resource Pool Accessibility
item, which would lead to the following definition of a Resource
Pool.
The following picture represents an abstracted model of the preceding
node, that corresponds to the information model chosen in this
document.
Peloso, et al. Expires January 12, 2012 [Page 8]
Internet-Draft OSPF-TE extensions for WSON July 2011
I1 +-----------------+ E1
---->| +---->
I2 | | E2
---->| Connectivity +---->
I3 | Matrix | E3
---->| +---->
I4 | | E4
---->| +---->
IN | | EM
---->| +---->
RPEI#2| |RPII#2
+------->| |>-------+
| RPEI#1| |RPII#1 |
| +--->| |>---+ |
| | +-----------------+ | |
| | | |
| | +-----------+ | |
| | | RP #1 | | |
| | | +-------+ | | |
| | | | Rb #1 | | | |
| | | +-------+ | | |
| | | +-------+ | | |
| +------<+ | | |<------+ |
| | | Rb #2 | | |
| | | | | |
| | +-------+ | |
| +-----------+ |
| +-----------+ |
| | RP #2 | |
| | +-------+ | |
| | | Rb #3 | | |
+----------<+ +-------+ +<----------+
| +-------+ |
| | Rb #P | |
| +-------+ |
+-----------+
Figure 2
Since by definitions Resource Pools indentify wavelength
accessibility to regeneration resources, Section 2.2.3 details how to
deal with accessibility constrains. This lead to the following
definition of a Resource Pool.
<ResourcePool> ::= <ResourcePoolID> ([<SharedAccessWvls>]...)
([<ResourceBlockState>]...)
([<ResourcePoolWvlConstraints>]...)
Peloso, et al. Expires January 12, 2012 [Page 9]
Internet-Draft OSPF-TE extensions for WSON July 2011
- ResourcePoolID a unique (within node scope) number used to
identify the pool,
- SharedAccessWvls represents the dynamic spectral availability
coming from the usage of wavelengths by activated resources
inside the pool,
- ResourceBlockStates are used to provide the dynamic availability
of resources inside the pool.
- ResourcePoolWvlConstraints may be used to define the structural
(static) spectral constraints of accessibility of the pool.
A WSON node having some OEO resource might have from 1 to P resource
pools. The ResourcePool is created as an entity that will fit in a
dedicacted TLV (as sub-TLV) so the case of multiple Resource Pools
will be handled by fitting one or more Reource Pool entity in each
advertisment. The unique identifier ResourcePoolID allows to
distinguish among all available pools.
As this document means to have one Resource Pool entity per physical
pool of resources inside the node, inside a given node there is no
reason for its pools not to share type of resources, hence their
modeled respresentations refer to identical Resource Descriptions
entities. In order to avoid unnecessary information flooding, this
document gathers all these Resource Descriptions inside a dedicated
entity, that is named Resource Description Container.
<ResourceDescriptionContainer> ::= <ResourceDescription>...
The Resource Description Container is a list of Resource Descriptions
which, in turn, defines the features (i.e. physical characteristics)
of each type of resources held inside the pools (of a given node).
------
DELTA:
- Introduced definition of Resource Pool.
- Introduced definition of Resource Pool ID.
- Introduced definition of Resource Description Container.
- Changed accordingly Figure 1 and 2 from
[I-D.ietf-ccamp-rwa-info].
Peloso, et al. Expires January 12, 2012 [Page 10]
Internet-Draft OSPF-TE extensions for WSON July 2011
- Changed the RBNF from [I-D.ietf-ccamp-rwa-info].
- Changed the Resource Block Info into Resource Description (small
semantic change, due to minor internal changes.
- Adapted some pieces of models which were related to Resource
Block, to the Resource Pool level, namely: RPWvlConstraints
2.2.3. Resource Pool Accessibility
Every device inside a Resource Pool shares the same accessibility
constraints, hence the accessibility is a property related to the
pool. In order to depict the accessibility of a given pool, two
pieces of information needs to be described:
- Which ingress links of the node can be connected to the entry of
the Resource Pool,
- Which egress links of the node can be connected to the exit of
the Resource Pool.
Following remarks can be made concerning these accessibility
information:
- These information share the same nature as the one of the
Connectivity Matrix,
- These information are relatively static, changing only when the
switching fabric of the node is changing (either failure or
upgrade),
Hence, the accessibility information of every Resource Pool are
embedded together inside the node own's Connectivity Matrix. The
solution used to do that consists in using both Local Link
Identifiers and Resource Pool Identifiers inside the Link Sets of the
Connectivity Matrix. To keep unchanged the definition of the Link
Set, 32 bits unnumbered IDs for the Resource Pool are needed (see
Section 2.2.4). Thanks to this in the context of a node, the
Connectivity Matrix is then providing associations between:
- On one side a set composed of a mix of: (1) ingress link(s) and
(2) exit(s) of resource pool(s),
- On the other side a set composed of a mix of: (1) egress link(s)
and (2) entry(ies) of resource pool(s).
Then the RBNF for the Connectivity Matrix becomes,
Peloso, et al. Expires January 12, 2012 [Page 11]
Internet-Draft OSPF-TE extensions for WSON July 2011
<ConnectivityMatrix> ::= <MatrixID> <ConnectType>
(<IngressSetOfMixedLink&Pool> <EgressSetOfMixedLink&PoolSet>)...
The Resource Pool Accessibility information are optional, if not
defined, Resource Pool is meant to have no accessibility constraints:
from every node ingress port it's possible to reach the pool and the
pool egress can reach every egress port of the node.
------
DELTA:
This section could be compared to the Resource Block Accessibility
constraint, and this is a major change that is proposed here.
2.2.4. Resource Pool ID
In order to encode directly resource pools accessibility, inside the
node's connectivity matrix, each Resource Pool needs to be identified
alike an internal link with one ID on each side (ingress and egress),
and then requires a Resource Pool ID. For each Resource Pool, WSON
node assigns one identifier to each side of the pool. This
identifier is a non-zero 32-bit number that is unique within the
scope of the WSON node that assigns it, hence the Resource Pool ID is
composed by a couple of unique numbers.
Consider a (resource) pool inside WSON node A. WSON node A chooses
two distincts identifiers for the pool (one for the ingress side and
one for the egress side). Considering these identifiers being unique
inside the scope of the WSON node A, implies that: no other
(resource) pool inside WSON node A may be assigned the value
corresponding to any of these two identifiers, neither any
(unnumbered) link between WSON node A and any other node may be
assigned a link local identifier (from the WSON node A perspective)
value corresponding to any of these two identifiers.
Support for resource pools in routing includes carrying information
about the identifiers of these pools. Specifically, when an LSR
advertises a resource pool, the advertisement carries both the
ingress and the egress identifiers of the link.
<RPoolID> ::= <RESOURCE_INGRESS_ID> <RESOURCE_EGRESS_ID>
2.2.5. Resource Block State
The Resource Block State keep track of the current usage of a
resource block within a resource pool.
The state indicate for the resource the number of available resources
Peloso, et al. Expires January 12, 2012 [Page 12]
Internet-Draft OSPF-TE extensions for WSON July 2011
and optionnaly the total number (or maximum number) of resources.
decoupling ResourceDescription from the the ResourceBlock
configuration and allowing a better aggregation of the
ResourceDescription. The state available in info model is the
following:
Resource Block State definition
<ResourceBlockState> ::= <ResourceBlockID> [<CountMaxResources>]
<CountAvailableResources>
------
DELTA:
This definition of the Resource Block State allow to separate the
total number of resources from the resource description (differing in
this from [I-D.ietf-ccamp-rwa-info]). This enable a sharing of the
resource description between all the pools, while the other solution
requires that each pool holds the same number of devices to share the
same ResourceBlockDescription (see Section 2.2.6).
2.2.6. Resource Description
The resource block information contains the pieces of information
needed to fully identify the resource block static and dynamic
information. The static information consist of the characteristics
that do not depend on the LSPs using the resource block. In
particular the wavelength constraints are the one of the OEO and are
independent of the LSPs. the static information is described by a
ResourceDescription, which can be valid for several resource blocks,
then referenced by their ResourceBlockID.
The ResourceBlockID identifies a resource block, it is a node wide
stable and unique identifier (inside the node context). The
ResourceBlockID is defined in the ResourceBlockState TLV held in the
Resource Pool TLV and used in the Resource Description TLV.
<ResourceDescription> := <ResourceBlockID>... <InputConstraints>
<ProcessingCapabilities> <OutputConstraints>
with,
<InputConstraints> ::= [<IngressWaveConstraint>] [<modulation-list>]
[<fec-list>] [<rate-range-list>] [<client-signal-list>]
<ProcessingCapabilities> ::= <RegenerationCapabilities>
[<FaultPerfMon>] [<VendorSpecific>]
Peloso, et al. Expires January 12, 2012 [Page 13]
Internet-Draft OSPF-TE extensions for WSON July 2011
<OutputConstraints> ::= [<EgressWaveConstraint>] [<modulation-list>]
[<fec-list>]
IngressWaveConstraint and EgressWaveConstraint are described in
Section 2.2.7. The modulation-list and fec-list represent the list
of modulation formats and FEC encoding available within the resource
block. This information MAY be present in the advertisement, the
absence of this information means that potentially all Modulation and
FEC are accepted and possible cranckback may occur.
------
DELTA:
- Split between static (can be in a separate LSA or in the resource
pool) and dynamic information.
- The maximum number of resource is in the state to allow better
summarization of the resourceDescription
- The static information is describing the properties, the
ResourceDescription is more explicit than resourceInfo in this
context
- Changed the RBNF from [I-D.ietf-ccamp-rwa-info], make use of
generic label restriction for the wavelength restrictions.
2.2.7. Resource Pool Wavelength Constraints
This field defines any constraint at wavelength level within a
resource pool, and is meaningful only when a subset of wavelengths
could be configurable within the Pool. This information is static
since it depends on specific physical resources within the pools and
changes only if there is a node reconfiguration (OEO pools added or
removed from an optical node, change in the mux or demuxing devices).
As there is an ingress side and an egress side of a pool, this item
needs to modelize the wavelength usage on each side.
This field takes the format of a Label_Restrictions Section 2.2.1.
At most two instances of this item can be needed: one for each sides
(incoming / outgoing) of the pool.
The field is optional, when this field is not present it means there
are no specific wavelength constraints imposed by pool. As an
example this field is equivalent to the Maximum Bandwidth field
defined within [RFC3630]. As the Maximum Bandwith represents the
true link capacity, the RESOURCE_POOL_WAVELENGTH_CONSTRAINTS
represent the set of wavelengths that can possibly be configured on
Peloso, et al. Expires January 12, 2012 [Page 14]
Internet-Draft OSPF-TE extensions for WSON July 2011
the pool.
Note that the usable set of wavelengths could be limited by other
constraints: e.g. currently in-use wavelength (see Section 2.2.8) or
due to OEO device constraint on compliant wavelengths (see Wavelength
Constraints in Section 2.2.6).
------
DELTA:
Only wavelength constrain. While physical constraints are grouped in
another set.
2.2.8. Shared Access Available Wavelengths
The SHARED_ACCESS_AVAILABLE_WAVELENGTHS represents wavelength usage
in a Resource Pool hence it is related with the Resource Pool dynamic
state.
If a wavelength is in use within a pool, the same wavelength cannot
be reused in the same pool however the pool will be available for a
different wavelength depending on free resource blocks (Resource Pool
defintion as in Section 2.2.2). As there is an ingress side and
egress side of a pool, this item needs to modelize the wavelength
usage on each side. Hence, this representation automatically
considers the case of wavelength conversion happening inside the
pool.
This field takes the format of a Label_Restrictions Section 2.2.1.
At most two instances of this item can be needed: one for each sides
(incoming / outgoing) of the pool.
N.B.: Hence, SHARED_ACCESS_AVAILABLE_WAVELENGTHS has the same format
as RESOURCE_POOL_WAVELENGTH_CONSTRAINTS defined in Section 2.2.7.
------
DELTA:
Only wavelength constraint. While physical constraints are grouped
in another set.
3. Encoding
3.1. Node related generic encodings
In this section we propose modification to
[I-D.ietf-ccamp-general-constraint-encode].
Peloso, et al. Expires January 12, 2012 [Page 15]
Internet-Draft OSPF-TE extensions for WSON July 2011
3.2. Node related WSON specific encodings
This section refer to [I-D.ietf-ccamp-rwa-wson-encode]
3.2.1. Label Restrictions
Relatively to section 2.2 of
[I-D.ietf-ccamp-general-constraint-encode] the LABEL_SET field is
here slightly modified in order to define a Label Restrictions field.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Action|U|D| Num Labels | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Base Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Additional fields as necessary per action |
: :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Although it make sense only using the actions 0-Inclusive List,
2-Inclusive Range or 4-Bitmap. The U bit indicate a label set
restriction valid at the upstream direction/incoming side of a
resource pool/resource block. The D bit indicate a label set
restriction valid at the downstrean/outgoing side of a resource pool/
resource block. At least one of U or D bit MUST be set, both U and D
bit MAY be set.
------
DELTA:
The Num Labels field become 10 bits and this leave room for 1024
labels represented by this encoding. This encoding will be reused in
specific TLVs, in case more than 1024 labels are needed multiple
fields within TLVs can be used.
3.2.2. Id Set Field
With the introduction of resource description describing properties
for a group of resource block we need to efficiently represent a set
of IDs. To do so we introduce an IDSet field which has the same
encoding as the LinkSet field defined in
[I-D.ietf-ccamp-general-constraint-encode] but with a more generic
description.
Peloso, et al. Expires January 12, 2012 [Page 16]
Internet-Draft OSPF-TE extensions for WSON July 2011
ID Set Field
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Action |Dir| Format | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: : :
: : :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Action, Dir have the same encoding as in
[I-D.ietf-ccamp-general-constraint-encode]. The Format field
indicates the format and length of the Identifier:
0 -- 32 Bit unnumbered identifier
1 -- IPv4 identifier
2 -- IPv6 identifier
This field is used later to define a set of resource blocks (e.g. to
list the resource blocks sharing the same resource description).
3.2.3. Resource Pool Accessibility
The Resource Pool Accessibility needs no encoding of its own. As
explained in the Section 2.2.3 this piece of information is merged
inside the Connectivity Matrix object which is actually not impacted
by this solution.
Nota: The Link Sets held inside the Connectivity Matrix are composed
of LINK_LOCAL_IDENTIFIERS (32 bits identifiers), and the solution to
describe the Resource Pool Accessibility consists in using either
RESOURCE_INGRESS_ID or RESOURCE_EGRESS_ID (also 32 bits identifiers)
which are by definition different from the LINK_LOCAL_IDENTIFIERS
(see Section 2.2.4).
------
DELTA: A major change here as the content of this field are moved
inside Connectivity Matrix.
Peloso, et al. Expires January 12, 2012 [Page 17]
Internet-Draft OSPF-TE extensions for WSON July 2011
3.2.4. Resource Block State
This TLV indicate the state of a resource block as defined in
Section 2.2.5. It defines the ResourceBlockId, and provides the
number of free resources and maximum in this resource block. The
ResourceBlockID field is a 32 bit node-wide identifier,
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ResourceBlockID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CountAvailableResources |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CountMaxResources |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The information of the maximum number of resource is optional, this
is encoded with a value of 0 in the CountMaxResource field, or with a
Length value set to 8 instead of 12.
------
DELTA:
This is an adaptation of the resource pool status that fits the new
definition of resource description.
3.2.5. Resource Description
Resource Description sub-TLVs represent the information described in
Section 2.2.6.
The resource description TLV encoding follow the definition from
Section 2.2.6 with a list of sub-sub TLV.
Peloso, et al. Expires January 12, 2012 [Page 18]
Internet-Draft OSPF-TE extensions for WSON July 2011
Resource Description TLV
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ResourceBlockID Set Field |
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-TLVs (opt) |
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The ResourceBlockID Set Field is encoded using the IDSet field
encoding using the ResourceBlockID as identifier with format 0.
The Sub-Sub TLVs are defined as follow, the order does not matter.
Each of the Sub-Sub-TLV defined in this document MAY be repeated more
than once, on receipt all Sub-Sub-TLV MUST be taken into account.
The resulting information is the union of all the element of the Sub-
Sub-TLVs (all Sub-Sub-TLVs of this document describe lists). For
example an implementation may choose to indicate that in total 4
label can be used as 4 Label constraint Sub-Sub-tlv, each of them
with 1 label.
Info model Type Encoding
IngressWaveConstraint Label Label restriction, see
Constraints Section 3.2.1.
Input modulation-list Modulation A list of Modulation Format
List Fields, described in
[I-D.ietf-ccamp-rwa-wson-encode]
section 4.2.1.
Input fec-list FEC List A list of FEC type, described in
[I-D.ietf-ccamp-rwa-wson-encode]
section 4.3.1.
Input rate-range-list Rate Range A list of rate range field,
described in
[I-D.ietf-ccamp-rwa-wson-encode]
section 4.4.1.
Input Client A list of GPids, described in
client-signal-list Signal List [I-D.ietf-ccamp-rwa-wson-encode]
section 4.5.
Peloso, et al. Expires January 12, 2012 [Page 19]
Internet-Draft OSPF-TE extensions for WSON July 2011
ProcessingCapabilities Processing A list of Processing Capabilities
Capabilities Fields, except processing cap
"Number of Resources", described
in
[I-D.ietf-ccamp-rwa-wson-encode]
section 4.6.1.
EgressWaveConstraint Label Label restriction, see
Constraints Section 3.2.1.
Output modulation-list Modulation see Input modulation-list
List
Output fec-list FEC List see Input fec-list
Resource description Sub-Sub-TLVs and relation to info model
The Label Constraints Sub-Sub-TLV is used for IngressWaveConstraint
and EgressWaveConstraint as the Label Restriction field carries the U
and D bit to allow to distinguish a label restriction valid for
incoming, outgoing or both.
The Modulation List Sub-Sub-TLV is similarly used for the input and
output modulation list. The Sub-Sub-TLV contains a list of
Modulation format field, which indicate if they are valid for the
input (I bit set to 1) or for the output (I bit cleared). The list
of Modulation format field MUST contain at least one ingress FEC
modulation format. If no Egress modulation format is present in the
list it is implied that no modulation format conversion is
impossible, the egress modulation list is the same as the ingress
modulation list and modulation format is not performed.
The FEC list Sub-Sub-TLV is also representing both Input and Output
FEC list. The Sub-Sub-TLV is defined as a list of FEC Fields,
conceptually being Sub-Sub-Sub-TLVs indicating via the I bit if they
are valid for ingress or egress. At least one ingress FEC MUST be
present in the list, if no egress modulation format is present in the
list it is implied that the egress FEC list is the same as the
ingress FEC list. In such case FEC format conversion MAY be
performed.
The Processing Capabilities Sub-Sub-TLV is the same as in
[I-D.ietf-ccamp-rwa-wson-encode] section 4.6.1. except for the
maximum number of resource which is represented in the
ResourceBlockState. The FEC and Modulation format conversion
capabilities are expressed via the Modulation and FEC list by not
including any egress modulation/fec in the respective lists.
Bit-Rate Range and Client Signal lists are unchanged from
[I-D.ietf-ccamp-rwa-wson-encode]
Peloso, et al. Expires January 12, 2012 [Page 20]
Internet-Draft OSPF-TE extensions for WSON July 2011
------
DELTA:
- use a common TLV for the label restriction
- use a common TLV for the FEC list
- use a common TLV for the Modulation format list
- re-use indirectly (via ID Set) the general encoding LinkSet for
RBlockId set
- More explicit statement on FEC and Modulation format conversion
capabilities
3.2.6. Resource Pool Wavelength Constraints
This TLV is used to describe static wavelength constraint, it follows
the encoding of Label_Restrictions field Section 3.2.1
RESOURCE_POOL_WAVELENGTH_CONSTRAINTS TLV
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label_Restrictions field(s) |
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Label_Restrictions field might be repeased several times
depending on the U and D bit flags. In case multiple fields with the
same U and D bits set to 1, the final resulting constrain will be the
intersection of all Label_Restrictions. If multiple TLVs are present
the resulting constraint is the intersection of all the TLV.
Example below:
- No RESOURCE_POOL_WAVELENGTH_CONSTRAINTS TLV meaning that these
type of constraints are not described.
- A TLV present with one Label_Restrictions field with both the U
or D bits MUST be set to 1. Which means the same constrains
apply to both sides of the pool.
Peloso, et al. Expires January 12, 2012 [Page 21]
Internet-Draft OSPF-TE extensions for WSON July 2011
- A TLV present with three Label_Restrictions field presents, one
field with U=1 so applicable upstream. The two other fields with
D=1 so applicable downstream
------
DELTA: Small delta, just using the add-on bits to provide a
direction/side semantic.
3.2.7. Shared Access Available Wavelengths
This TLV is used to describe dynamic wavelength availability, it
follows the encoding of Label_Restrictions field. Section 3.2.1
SHARED_ACCESS_AVAILABLE_WAVELENGTH TLV
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label_Restrictions field(s) |
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The same rules and usage defined in Section 3.2.6 apply here.
3.2.8. Resource Pool
The RESOURCE_POOL TLV contains the preceding TLVs.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RESOURCE_INGRESS_ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RESOURCE_EGRESS_ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-TLVs as needed (Opt) |
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Peloso, et al. Expires January 12, 2012 [Page 22]
Internet-Draft OSPF-TE extensions for WSON July 2011
List of possible Sub-TLVs:
Name Static/Dynamic
Resource Block State Dynamic
Shared Access Available Wavelength Dynamic
Resource Pool Wavelength Constraints Static
------
DELTA:
Similar to Resource Pool inside [I-D.ietf-ccamp-rwa-wson-encode] with
a different internal layout that allows for multiple instances.
3.2.9. Resource Description Container
The RESOURCE_DESCRIPTION_CONTAINER is a list of RESOURCE_DESCRIPTION.
This one MAY be used to extract the static content of the previous
TLV, in order to hold all this content inside this purposely defined
static TLV. Then each one can be in separatly flooded entities (e.g.
in separated LSAs see Section 4.1.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RESOURCE_DESCRIPTION |
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RESOURCE_DESCRIPTION |
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
------
DELTA:
New item.
3.3. Link related encodings
This section does not differ from the equivalent in
[I-D.ietf-ccamp-general-constraint-encode]
Peloso, et al. Expires January 12, 2012 [Page 23]
Internet-Draft OSPF-TE extensions for WSON July 2011
4. OSPF-TE Extensions
This section handles OSPF-TE extensions.
It starts with introducing the top view of the extensions provided by
this draft. Then a sub-section dedicated for each top level TLV
details the extensions relevant for this top level TLV.
4.1. Introduction
This introduction provides the layout of the preceding information
model (Section 2) and encodings (Section 3) into top-level TLVs of
opaque LSAs.
[RFC3630] introduces Link top level TLV (type 2). This document
extends its content with the encodings depicted in Section 3.3.
These extensions offer the capability to advertise restrictions on
the list of available labels.
N.B.: This capability is specifically useful when these labels have a
network wide semantic like suggested in a WSON context.
[RFC5786] introduces Node Attribute top level TLV (type 5). This
document extends its content with the encodings depicted in
Section 3.1. These extensions offer the capability to advertise
restrictions on the switching capabilities of the node.
N.B.: This TLV is unique for a given node and contains static
information only, hence no more than one LSA per node is expected to
host such a TLV.
This document introduces a new top level TLV named RESOURCE_POOL
(type value to be defined), which encodings are depicted in
Section 3.2. RESOURCE_POOL TLV offers the capability to advertise
one or multiple pools of OEO devices held in a given node. This
object can carry resource descriptions, the available resources
inside the pool(s) and the availability of wavelengths to reach the
pool (refer to pool definition inside Section 2.2.2).
N.B.: A LSA can contain more than one RESOURCE_POOL top level TLV
(allowing one LSA to advertise the description of all the pools of
the originating node). Alternatively, a node can originate more than
one LSA containing each RESOURCE_POOL top level TLVs (allowing each
LSA to advertise an individual pool). In that case all the
RESOURCE_POOL originated by the same node MUST have different
RESOURCE_POOL_ID. As most of the information contained inside a
RESOURCE_POOL are dynamic, an implementer may well choose to define
one LSA per pool of resources in order to reduce the quantity of
information flooded upon change in resource usage.
This document introduces another new top level TLV named
Peloso, et al. Expires January 12, 2012 [Page 24]
Internet-Draft OSPF-TE extensions for WSON July 2011
RESOURCE_DESCRIPTION_CONTAINER (type value to be defined), which
encoding is depicted in Section 3.2.9.
RESOURCE_DESCRIPTION_CONTAINER TLV contains a list of
RESOURCE_DESCRIPTION valid in the scope of the originating node. A
given node MUST NOT originate more than one LSA containing
RESOURCE_DESCRIPTION_CONTAINER TLV. An LSA containing a
RESOURCE_DESCRIPTION_CONTAINER TLV MUST NOT contain any additional
top level TLV.
N.B.: This TLV is designed to be unique in the scope of the
originating node and to gather all the resource descriptions relevant
in this scope.
Summarizing Table
Top-TLV Type Name Instances Static/Dynamic
2 Link 1 per fiber Mix
5 Node Attribute 1 per Node Static
TBD Resource Pool 1 per Pool Dynamic
TBD Resource Desc Cont 1 per Node Static
------
DELTA:
- Renamed the Node Optical Property tlv into Resource Pool TLV
- Allow multiple instance of Resource Pool TLV
- Introduced an optional new TLV named Resource Description
4.2. Link top level TLV
This section refer to
[I-D.ietf-ccamp-gmpls-general-constraints-ospf-te].
The following new sub-TLVs are added to the Link top level TLV (type
2).
Peloso, et al. Expires January 12, 2012 [Page 25]
Internet-Draft OSPF-TE extensions for WSON July 2011
Sub-TLV Type Length Name
TBD variable Port Label Restrictions
TBD variable Available Wavelengths
TBD variable Shared Backup Wavelengths
In Link TLV, all the sub-TLV listed above are optional.
4.3. Node Attribute top level TLV
This section refer to
[I-D.ietf-ccamp-gmpls-general-constraints-ospf-te].
The following new sub-TLVs are added to the Node Attribute top level
TLV (type 5).
Sub-TLV Type Length Name
TBD variable Connectivity Matrix
TBD variable Port Label Restrictions
TBD variable Shared Risk Node Group
In Node Attribute, all the sub-TLV listed above are optional. None
of them contain sub-TLV.
4.4. Resource Pool top level TLV
This section refer to [I-D.ietf-ccamp-wson-signal-compatibility-ospf]
The following sub-TLVs are created for the Resource Pool top level
TLV.
Sub-TLV Type Length Name
TBD variable Resource Block State
TBD variable Shared Access Available Wavelength
TBD variable Resource Pool Wavelength Constraints
In Resource Pool, all the sub-TLV listed above are optional.
4.5. Resource Description Container top level TLV
This section refer to [I-D.ietf-ccamp-wson-signal-compatibility-ospf]
The following sub-TLVs are created for the Resource Description
Container top level TLV.
Peloso, et al. Expires January 12, 2012 [Page 26]
Internet-Draft OSPF-TE extensions for WSON July 2011
Sub-TLV Type Length Name
TBD variable Resource Description
4.5.1. Resource Description sub-TLV
The following sub-TLVs are created for the Resource Pool top level
TLV.
Sub-TLV Type Length Name
TBD variable Modulation List
TBD variable FEC List
TBD variable Rate Range List
TBD variable Client Signal List
TBD variable Processing Capabilities
TBD variable Label Constraints
In Resource Description, all the sub-TLV listed above are optional.
5. Acknowledgements
This template was derived from an initial version written by Pekka
Savola and contributed by him to the xml2rfc project.
This document shares common material with the documents quoted, which
seems fair as the target of this version is to highlight differences.
The editors wish to thank Ramon Casellas for his constructive
comments.
6. Contributors
Daniele Ceccarelli
Ericsson
Via A. Negrone 1/A
Genova - Sestri Ponente
Italy
Email: daniele.ceccarelli@ericsson.com
7. IANA Considerations
This memo requires many requests to IANA, which will be completed in
a latter version.
Peloso, et al. Expires January 12, 2012 [Page 27]
Internet-Draft OSPF-TE extensions for WSON July 2011
8. Security Considerations
All drafts are required to have a security considerations section.
See RFC 3552 [RFC3552] for a guide.
9. References
9.1. Normative References
[I-D.ietf-ccamp-general-constraint-encode]
Bernstein, G., "General Network Element Constraint
Encoding for GMPLS Controlled Networks",
draft-ietf-ccamp-general-constraint-encode-04 (work in
progress), December 2010.
[I-D.ietf-ccamp-gmpls-general-constraints-ospf-te]
Zhang, F., Lee, Y., Han, J., Bernstein, G., Xu, Y., Zhang,
G., Li, D., Chen, M., and Y. Ye, "OSPF-TE Extensions for
General Network Element Constraints",
draft-ietf-ccamp-gmpls-general-constraints-ospf-te-00
(work in progress), March 2011.
[I-D.ietf-ccamp-rwa-wson-encode]
Bernstein, G., Lee, Y., Li, D., Imajuku, W., and J. Han,
"Routing and Wavelength Assignment Information Encoding
for Wavelength Switched Optical Networks",
draft-ietf-ccamp-rwa-wson-encode-11 (work in progress),
March 2011.
[I-D.ietf-ccamp-wson-signal-compatibility-ospf]
Lee, Y. and G. Bernstein, "OSPF Enhancement for Signal and
Network Element Compatibility for Wavelength Switched
Optical Networks",
draft-ietf-ccamp-wson-signal-compatibility-ospf-04 (work
in progress), March 2011.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
June 1999.
[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC
Text on Security Considerations", BCP 72, RFC 3552,
July 2003.
[RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering
Peloso, et al. Expires January 12, 2012 [Page 28]
Internet-Draft OSPF-TE extensions for WSON July 2011
(TE) Extensions to OSPF Version 2", RFC 3630,
September 2003.
[RFC4202] Kompella, K. and Y. Rekhter, "Routing Extensions in
Support of Generalized Multi-Protocol Label Switching
(GMPLS)", RFC 4202, October 2005.
[RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax
Used to Form Encoding Rules in Various Routing Protocol
Specifications", RFC 5511, April 2009.
[RFC5786] Aggarwal, R. and K. Kompella, "Advertising a Router's
Local Addresses in OSPF Traffic Engineering (TE)
Extensions", RFC 5786, March 2010.
9.2. Informative References
[I-D.ietf-ccamp-rwa-info]
Bernstein, G., Lee, Y., Li, D., and W. Imajuku, "Routing
and Wavelength Assignment Information Model for Wavelength
Switched Optical Networks", draft-ietf-ccamp-rwa-info-11
(work in progress), March 2011.
[I-D.narten-iana-considerations-rfc2434bis]
Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs",
draft-narten-iana-considerations-rfc2434bis-09 (work in
progress), March 2008.
[RFC6163] Lee, Y., Bernstein, G., and W. Imajuku, "Framework for
GMPLS and Path Computation Element (PCE) Control of
Wavelength Switched Optical Networks (WSONs)", RFC 6163,
April 2011.
Appendix A. Solution(s) Evaluation
Within this section we try evaluate the amount of information that
needs to be exchanged through routing advertisements. For this
evaluation we consider some minimum optical node reference design to
make a OEO extension future proof.
This sections starts with summarizing the LSAs needed to depict a
node with both the solution depicted by this document and the
solution depicted by [I-D.ietf-ccamp-rwa-info]. Afterwards, the
hypothesis concerning the node features that will serve as a basis
for the solution evaluation will be presented, before the actual
results of the solutions evaluations (both the one of this document
Peloso, et al. Expires January 12, 2012 [Page 29]
Internet-Draft OSPF-TE extensions for WSON July 2011
and the one of [I-D.ietf-ccamp-rwa-info]).
A.1. RBNFs Comparison
In this section we try compare the how TLVs are composed according
two this draft proposal versus existing WSON solutions. The goal
here is to provide the all reference for and easy understanding where
two solutions are different. Numbers will be provided in the next
section.
The evaluation will be done on the Resource Pool top-level TLV since
the Node address and Link TLV are considered equivalent.
WSON Drafts. According to
[I-D.ietf-ccamp-wson-signal-compatibility-ospf] in section 2 defines
the Optical Node Property TLV which collect the WSON specific
information. This TLV is composed of the following:
<ResourcePool> ::= [<ResourceBlockInformation>]...
[<ResourceBlockAccessibility>]... [<ResourceBlockWvlConstraint>]...
[<ResourceBlockPoolState>...] [<SharedAccessWvls>...]
a) Resource Block Information. Defined as : ([<ResourceSet>]
<InputConstraints> <ProcessingCapabilities> <OutputConstraints>).
A resource block information defines here the number of devices
inside the block.
b) Resource Block Accessibility. Defined as (<PoolIngressMatrix>
<PoolEgressMatrix>) which is expanded in tuples like
(<INGRESS_LINK_SET><ResourceSet>)* and
(<EGRESS_LINK_SET><ResourceSet>)*. Note that INGRESS/
EGRESS_LINK_SET is a name defined here for the link set field
used in the [I-D.ietf-ccamp-rwa-info] document.
c) Resource Block Wavelength Constraints. Defined as
<IngressWaveConstraints><EgressWaveConstraints>. This is
expanded in <ResourceSet>INPUT_WAVELENGHT_SET
OUTPUT_WAVELENGTH_SET, for the static constraints of resource
blocks.
d) Shared Access Wavelengths. Defined as
<IngressWaveConstraints><EgressWaveConstraints>. This is
expanded in <ResourceSet>INPUT_WAVELENGHT_SET
OUTPUT_WAVELENGTH_SET, for the shared fibers between blocks.
Peloso, et al. Expires January 12, 2012 [Page 30]
Internet-Draft OSPF-TE extensions for WSON July 2011
e) Resource Block Pool State. <ResourceSet> <USAGE_STATE_BITMAP>
In current proposal there are two types of TLV.
First the Resource Pool TLV (with an instance per pool) is composed
of the following information:
<ResourcePool> ::= <ResourcePoolID> [<ResourceDescription>]...
[<ResourcePoolWvlConstraints>]... [<SharedAccessWvls>]...
[<ResourceBlockState>]...
a) Resource Description. Which is defined as: (<RBlockID>...)
<InputConstraints> <ProcessingCapabilities> <OutputConstraints>.
This is equivalent to the item a) above without the number of
devices inside the resource block, which allow this definition to
be usable by any block. The number of available resource of a
given type inside the pool being specified by the Resource Block
State below. When a Resource Description Container TLV is
defined by a Node, the Resource Pool TLV of this same node SHOULD
NOT contain any Resource Description sub-TLV.
b) Resource Block State. Where RBlockState is defined as <RBlockID>
[<NumResources>] <NumberOfAvailableResources>. This field
efficienty report how many of a given resource type is available
inside the pool or not.
c) Shared Access Available Wavelength. This is composed of a Label
Restriction field and SHOULD used to depict the dynamic
constraints of the pool.
d) Resource Pool Wavelength Constraints. This is composed of a
Label Restriction field and MAY be used to depict the static
constraints of the pool.
Second the Resource Descriptor Container TLV (with a single instance
per node) is used to gather all the Resource Descriptions of a given
node, as these are static information composed of the following
information:
<ResourceDescriptionContainer> ::= <ResourceDescription>...
a) Resource Description. Which is defined as: (<RBlockID>...)
<InputConstraints> <ProcessingCapabilities> <OutputConstraints>.
This is equivalent to the item a) above.
Peloso, et al. Expires January 12, 2012 [Page 31]
Internet-Draft OSPF-TE extensions for WSON July 2011
A.2. Depiction of the considered cases for evaluation
For the sake of the comparison we have considered the following
parameters and values characterizing the optical node design:
o Node Degree Connectivity: 4, 8 and 16.
o WDM capacity: 100 wavelengths.
o Switching capacity. Defines the total node switching capability
and is calculated as Node Degree Connectivity x 100 wavelengths.
o Regeneration Capability. We assume a value of 5% of the total
switching capacity.
o Add/Drop Capability. We assume a typical value of 25% of the
switching capability. So in the average up to 30 wavelengths per
incoming fiber can be added/dropped within the optical node.
o Resource pool setup and capabilities. A physical resource pool
contains a mix of Add/Drop and Regeneration capabilities. This
has the effect of increasing the number of resource pool
advertized. Resource pool can be fully flexible (connected to any
port), partial (only to some port) or Fixed (can only be connected
to one direction). This parameter influences the complexity of
the connectivity matrix.
o Number of Regenerator types. For a given node the number of OEO
capabilities is limited, it is typically decided by the type of
electrical equipment and optical modules (emitting laser and
optical receiver).
o Blocking Ratio. The Spatial/Spectral blocking ratio indicates how
much port-based/wavelength based blocking a node is experiencing.
For example considering the typical design it results in the
following static layout:
o 3 OEO pools each having 3 Resource Block inside.
o Connectivity Matrix: (8+30+30) 64x64 if considering one
connectivity matrix. Ingress=64x3, Egress=3x64 (considering the
OEO access with a multiple-wavelength link).
The following types of nodes and node designs were considered in this
evaluation:
Peloso, et al. Expires January 12, 2012 [Page 32]
Internet-Draft OSPF-TE extensions for WSON July 2011
Node Types and designs
Node Type Nodal Degree Pool Type Blocking
Small(S), Flexible 4 Partial None
Small(S), Fixed(port) 4 Fixed Port
Small(S), Fixed(label) 4 Partial Lambda
Middle(M), Flexible 8 Flexible None
Large(L), Flexible 16 Flexible None
For the small nodes, 5 different type of regenerators are considered,
for the Middle and Large ones 10 different type of regenerators are
considered. Based on those designs we derived the following
important figures:
o Number of resourcePool : depends on the pool type and
connectivity, which depend on the port blocking and number of Add/
Drop and Regenerator capacity.
o Number of resourceBlock. There is two numbers to be considered
here : the number of resourceBlock for a given resource pool (this
document) and total number of resourceBlock
([I-D.ietf-ccamp-rwa-info]). In this document the number of
resource block within a resource pool is, worst case, the number
of possible regenerator types, whereas in
[I-D.ietf-ccamp-rwa-info] the number of resource block depends on
the number of OEO types and on the connectivity.
o Number of connectivity matrix/number of pairs/link per pairs. The
number of sub-matrix increase depending on the port blocking
ratio, the number of pair in one connectivity matrix depends on
the wavelength restrictions. Those two criteria do not depend on
which information model is considered. The number of link per set
is increased by the number of resource pool in this draft.
Those numbers for each node are shown in the following table:
Peloso, et al. Expires January 12, 2012 [Page 33]
Internet-Draft OSPF-TE extensions for WSON July 2011
Details of information elements per node
Node Type # Pools Resource Blocks Matrix/Pair/Links
S, Flexible 6 5 (30) 1/1/10 (1/1/1)
S, Fixed(port) 12 5 (60) 4/4/4 (4/4/1)
S, Fixed(label) 6 5 (30) 4/1/10 (4/1/1)
M, Flexible 3 10 (30) 1/1/11 (1/1/1)
L, Flexible 5 10 (50) 1/1/21 (1/1/1)
Nota: Values for [I-D.ietf-ccamp-rwa-wson-encode] are between
brackets.
For further reading easiness the above table could be further
expanded as the following one:
Details of information elements per node
Node Type #Pools #Device #Blocks #ResProp Matrix/Pair/Links
Type TLV
S, Flexible 6 5 (30) 30 5 (25) 1/1/10 (1/1/1)
S, Fixed(port) 12 5 (60) 60 5 (45) 4/4/4 (4/4/1)
S,Fixed(label) 6 5 (30) 30 5 (25) 4/1/10 (4/1/1)
M, Flexible 3 10 (30) 30 10 (35) 1/1/11 (1/1/1)
L, Flexible 5 10 (50) 50 10 (40) 1/1/21 (1/1/1)
Nota: Values for [I-D.ietf-ccamp-rwa-wson-encode] are between
brackets.
A.3. Comparing evaluation of the solutions
Based on those key information model elements both the tables "LSA
size" indicate the size of the LSAs in this document and in
[I-D.ietf-ccamp-rwa-wson-encode]. Number of flooded LSAs of a given
type are indicated between brackets (when bigger than 1).
Solution of this document - Average size (and number) of LSAs per
node type (unit: bytes)
Node Type Node Attr LSA Resource Pool LSA Resource Desc LSA
S, Flexible 117 120 (6) 524
S, Fixed(port) 692 120 (12) 644
S, Fixed(label) 620 120 (6) 524
M, Flexible 127 120 (3) 904
L, Flexible 209 120 (5) 984
Peloso, et al. Expires January 12, 2012 [Page 34]
Internet-Draft OSPF-TE extensions for WSON July 2011
Solution of [I-D.ietf-ccamp-rwa-wson-encode] - Average size (and
number) of LSAs per node type (unit: bytes)
Node Type Node Attr LSA Optical Node LSA
S, Flexible 49 2801
S, Fixed(port) 340 2980
S, Fixed(label) 132 4118
M, Flexible 52 2980
L, Flexible 54 2809
The Resource Description Container LSA contains several resource
description TLVs. This LSA is smaller than the corresponding in
[I-D.ietf-ccamp-rwa-wson-encode] mainly because the resource
description do not depend on the port/lambda connectivity and number
of device per block, thus allowing a better sharing of the
information depicting the oeo capabilities.
The following summarizing table indicates the size of the sum of all
LSA and the average size per update. In this document all the
dynamic part is in the resource pool, allowing a more efficient
updating behavior. The evaluation for
[I-D.ietf-ccamp-rwa-wson-encode] are best case/worst case; the best
case being an update of the RBState TLV and SharedAccessPool TLV
only, which requires a multi-instance implementation of OSPF.
Summarizing Table (unit:bytes)
Node Type Total LSA size Total number of Avg size of an
LSA update
S, Flexible 1361 (2850) 8 (2) 120 (616/2801)
S, Fixed(port) 2776 (5411) 14 (2) 120 (1192/2980)
S, Fixed(label) 1864 (2941) 8 (2) 120 (616/4118)
M, Flexible 1391 (3032) 5 (2) 120 (448/2980)
L, Flexible 1793 (4172) 7 (2) 120 (720/2809)
Nota: Values for [I-D.ietf-ccamp-rwa-wson-encode] are between
brackets
The node design considered are typical case, a worst case can be a
node with high nodal degree, with lots of port and wavelength
constraints. With considering a nodal degree of 8, resulting in 28
resource pool and 140 resource blocks, the total size is 9816 (11820)
with 30 (2) LSAs.
Peloso, et al. Expires January 12, 2012 [Page 35]
Internet-Draft OSPF-TE extensions for WSON July 2011
Authors' Addresses
Pierre Peloso (editor)
Alcatel-Lucent
R.te de Villejust
Nozay, 91620
France
Phone: +33 130 702 662
Email: pierre.peloso@alcatel-lucent.com
Giovanni Martinelli
Cisco
Monza, 20900
Italy
Phone: +39 039 209 2044
Email: giomarti@cisco.com
Julien Meuric
France Telecom
2, av. Pierre Marzin
Lannion, 22307
France
Phone: +33 296 052 828
Email: julien.meuric@orange-ftgroup.com
Cyril Margaria
Nokia Siemens Networks
St-Martin str. 76
Munchen, 81541
Germany
Phone: +49-89-5159-16934
Email: cyril.margaria@nsn.com
Peloso, et al. Expires January 12, 2012 [Page 36]