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. ::= ([]...) ([]...) ([]...) 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. ::= ... 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 ::= ( )... 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. ::= 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 ::= [] ------ 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. := ... with, ::= [] [] [] [] [] ::= [] [] Peloso, et al. Expires January 12, 2012 [Page 13] Internet-Draft OSPF-TE extensions for WSON July 2011 ::= [] [] [] 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: ::= []... []... []... [...] [...] a) Resource Block Information. Defined as : ([] ). A resource block information defines here the number of devices inside the block. b) Resource Block Accessibility. Defined as ( ) which is expanded in tuples like ()* and ()*. 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 . This is expanded in INPUT_WAVELENGHT_SET OUTPUT_WAVELENGTH_SET, for the static constraints of resource blocks. d) Shared Access Wavelengths. Defined as . This is expanded in 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. 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: ::= []... []... []... []... a) Resource Description. Which is defined as: (...) . 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 [] . 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: ::= ... a) Resource Description. Which is defined as: (...) . 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]