summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc7446.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc7446.txt')
-rw-r--r--doc/rfc/rfc7446.txt1291
1 files changed, 1291 insertions, 0 deletions
diff --git a/doc/rfc/rfc7446.txt b/doc/rfc/rfc7446.txt
new file mode 100644
index 0000000..ae90109
--- /dev/null
+++ b/doc/rfc/rfc7446.txt
@@ -0,0 +1,1291 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) Y. Lee, Ed.
+Request for Comments: 7446 Huawei
+Category: Informational G. Bernstein, Ed.
+ISSN: 2070-1721 Grotto Networking
+ D. Li
+ Huawei
+ W. Imajuku
+ NTT
+ February 2015
+
+
+ Routing and Wavelength Assignment Information Model
+ for Wavelength Switched Optical Networks
+
+Abstract
+
+ This document 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. Aspects of this
+ information that may be of use to other technologies utilizing a
+ GMPLS control plane are discussed.
+
+Status of This Memo
+
+ This document is not an Internet Standards Track specification; it is
+ published for informational purposes.
+
+ This document is a product of the Internet Engineering Task Force
+ (IETF). It represents the consensus of the IETF community. It has
+ received public review and has been approved for publication by the
+ Internet Engineering Steering Group (IESG). Not all documents
+ approved by the IESG are a candidate for any level of Internet
+ Standard; see Section 2 of RFC 5741.
+
+ Information about the current status of this document, any errata,
+ and how to provide feedback on it may be obtained at
+ http://www.rfc-editor.org/info/rfc7446.
+
+
+
+
+
+
+
+
+
+
+Lee, et al. Informational [Page 1]
+
+RFC 7446 WSON Information Model February 2015
+
+
+Copyright Notice
+
+ Copyright (c) 2015 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.
+
+Table of Contents
+
+ 1. Introduction ....................................................3
+ 2. Terminology .....................................................3
+ 3. Routing and Wavelength Assignment Information Model .............3
+ 3.1. Dynamic and Relatively Static Information ..................4
+ 4. Node Information (General) ......................................4
+ 4.1. Connectivity Matrix ........................................5
+ 5. Node Information (WSON Specific) ................................5
+ 5.1. Resource Accessibility/Availability ........................7
+ 5.2. Resource Signal Constraints and Processing Capabilities ...11
+ 5.3. Compatibility and Capability Details ......................12
+ 5.3.1. Shared Input or Output Indication ..................12
+ 5.3.2. Optical Interface Class List .......................12
+ 5.3.3. Acceptable Client Signal List ......................13
+ 5.3.4. Processing Capability List .........................13
+ 6. Link Information (General) .....................................13
+ 6.1. Administrative Group ......................................14
+ 6.2. Interface Switching Capability Descriptor .................14
+ 6.3. Link Protection Type (for This Link) ......................14
+ 6.4. Shared Risk Link Group Information ........................14
+ 6.5. Traffic Engineering Metric ................................15
+ 6.6. Port Label Restrictions ...................................15
+ 6.6.1. Port-Wavelength Exclusivity Example ................17
+ 7. Dynamic Components of the Information Model ....................18
+ 7.1. Dynamic Link Information (General) ........................19
+ 7.2. Dynamic Node Information (WSON Specific) ..................19
+ 8. Security Considerations ........................................19
+ 9. References .....................................................20
+ 9.1. Normative References ......................................20
+ 9.2. Informative References ....................................21
+ Contributors ......................................................22
+ Authors' Addresses ................................................23
+
+
+
+Lee, et al. Informational [Page 2]
+
+RFC 7446 WSON Information Model February 2015
+
+
+1. Introduction
+
+ The purpose of the WSON information model described in this document
+ is to facilitate constrained optical path computation, and as such it
+ is not a general-purpose network management information model. This
+ constraint is frequently referred to as the "wavelength continuity"
+ constraint, and the corresponding constrained optical path
+ computation is known as the Routing and Wavelength Assignment (RWA)
+ problem. Hence, the information model must provide sufficient
+ topology and wavelength restriction and availability information to
+ support this computation. More details on the RWA process and WSON
+ subsystems and their properties can be found in [RFC6163]. The model
+ defined here includes constraints between WSON signal attributes and
+ network elements but does not include optical impairments.
+
+ In addition to presenting an information model suitable for path
+ computation in WSON, this document also highlights model aspects that
+ may have general applicability to other technologies utilizing a
+ GMPLS control plane. The portion of the information model applicable
+ to technologies beyond WSON is referred to as "general" to
+ distinguish it from the "WSON-specific" portion that is applicable
+ only to WSON technology.
+
+2. Terminology
+
+ Refer to [RFC6163] for definitions of Reconfigurable Optical Add/Drop
+ Multiplexer (ROADM), RWA, Wavelength Conversion, Wavelength Division
+ Multiplexing (WDM), WSON, and other related terminology used in this
+ document.
+
+3. Routing and Wavelength Assignment Information Model
+
+ The WSON RWA information model in this document comprises four
+ categories of information. The categories are independent of whether
+ the information comes from a switching subsystem or from a line
+ subsystem -- a switching subsystem refers to WSON nodes such as a
+ ROADM or an Optical Add/Drop Multiplexer (OADM), and a line subsystem
+ refers to devices such as WDM or Optical Amplifier. The categories
+ are these:
+
+ o Node Information
+
+ o Link Information
+
+ o Dynamic Node Information
+
+ o Dynamic Link Information
+
+
+
+
+Lee, et al. Informational [Page 3]
+
+RFC 7446 WSON Information Model February 2015
+
+
+ Note that this is roughly the categorization used in Section 7 of
+ [G.7715].
+
+ In the following, where applicable, the Reduced Backus-Naur Form
+ (RBNF) syntax of [RBNF] is used to aid in defining the RWA
+ information model.
+
+3.1. Dynamic and Relatively Static Information
+
+ All the RWA information of concern in a WSON network is subject to
+ change over time. Equipment can be upgraded; links may be placed in
+ or out of service and the like. However, from the point of view of
+ RWA computations, there is a difference between information that can
+ change with each successive connection establishment in the network
+ and information that is relatively static and independent of
+ connection establishment. A key example of the former is link
+ wavelength usage since this can change with connection setup/teardown
+ and this information is a key input to the RWA process. Examples of
+ relatively static information are the potential port connectivity of
+ a WDM ROADM, and the channel spacing on a WDM link.
+
+ This document separates, where possible, dynamic and static
+ information so that these can be kept separate in possible encodings.
+ This allows for separate updates of these two types of information,
+ thereby reducing processing and traffic load caused by the timely
+ distribution of the more dynamic RWA WSON information.
+
+4. Node Information (General)
+
+ The node information described here contains the relatively static
+ information related to a WSON node. This includes connectivity
+ constraints amongst ports and wavelengths since WSON switches can
+ exhibit asymmetric switching properties. Additional information
+ could include properties of wavelength converters in the node, if any
+ are present. In [Switch] it was shown that the wavelength
+ connectivity constraints for a large class of practical WSON devices
+ can be modeled via switched and fixed connectivity matrices along
+ with corresponding switched and fixed port constraints. These
+ connectivity matrices are included with the node information, while
+ the switched and fixed port wavelength constraints are included with
+ the link information.
+
+ Formally,
+
+ <Node_Information> ::= <Node_ID> [<ConnectivityMatrix>...]
+
+ Where the Node_ID would be an appropriate identifier for the node
+ within the WSON RWA context.
+
+
+
+Lee, et al. Informational [Page 4]
+
+RFC 7446 WSON Information Model February 2015
+
+
+ Note that multiple connectivity matrices are allowed and hence can
+ fully support the most-general cases enumerated in [Switch].
+
+4.1. Connectivity Matrix
+
+ The connectivity matrix (ConnectivityMatrix) represents either the
+ potential connectivity matrix for asymmetric switches (e.g., ROADMs
+ and such) or fixed connectivity for an asymmetric device such as a
+ multiplexer. Note that this matrix does not represent any particular
+ internal blocking behavior but indicates which input ports and
+ wavelengths could possibly be connected to a particular output port.
+ For a switch or ROADM, representing blocking that is dependent on the
+ internal state is beyond the scope of this document. Due to its
+ highly implementation-dependent nature, it would most likely not be
+ subject to standardization in the future. The connectivity matrix is
+ a conceptual M by N matrix representing the potential switched or
+ fixed connectivity, where M represents the number of input ports and
+ N the number of output ports. This is a "conceptual" matrix since
+ the matrix tends to exhibit structure that allows for very compact
+ representations that are useful for both transmission and path
+ computation.
+
+ Note that the connectivity matrix information element can be useful
+ in any technology context where asymmetric switches are utilized.
+
+ <ConnectivityMatrix> ::= <MatrixID>
+
+ <ConnType>
+
+ <Matrix>
+
+ Where
+
+ <MatrixID> is a unique identifier for the matrix.
+
+ <ConnType> can be either 0 or 1 depending upon whether the
+ connectivity is either fixed or switched.
+
+ <Matrix> represents the fixed or switched connectivity in that
+ Matrix(i, j) = 0 or 1 depending on whether input port i can connect
+ to output port j for one or more wavelengths.
+
+5. Node Information (WSON Specific)
+
+ As discussed 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
+
+
+
+Lee, et al. Informational [Page 5]
+
+RFC 7446 WSON Information Model February 2015
+
+
+ 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.
+
+ In this document, the term "resource" is used to refer to a physical
+ component of a WSON node such as a regenerator or a wavelength
+ converter. Multiple instances of such components are often present
+ within a single WSON node. This term is not to be confused with the
+ concept of forwarding or switching resources such as bandwidth or
+ lambdas.
+
+ A WSON node may include regenerators or wavelength converters
+ arranged in a shared pool. As discussed in [RFC6163], a WSON node
+ can also include WDM switches that use optical-electronic-optical
+ (OEO) processing. There are a number of different approaches used in
+ the design of WDM switches containing regenerator or converter pools.
+ 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 a wavelength converter to
+ convert from a given input wavelength on a particular input port
+ to a desired output wavelength on a particular output port.
+
+ 3. Limitations on the types of signals that can be converted and the
+ conversions that can be performed.
+
+ Since resources tend to be packaged together in blocks of similar
+ devices, e.g., on line cards or other types of modules, the
+ fundamental unit of identifiable resource in this document is the
+ "resource block".
+
+ A resource block is a collection of resources from the same WSON node
+ that are grouped together for administrative reasons and for ease of
+ encoding in the protocols. All resources in the same resource block
+ behave in the same way and have similar characteristics relevant to
+ the optical system, e.g., processing properties, accessibility, etc.
+
+ A resource pool is a collection of resource blocks for the purpose of
+ representing throughput or cross-connect capabilities in a WSON node.
+ A resource pool associates input ports or links on the node with
+ output ports or links and is used to indicate how signals may be
+ passed from an input port or link to an output port or link by way of
+ a resource block (in other words, by way of a resource). A resource
+ pool may, therefore, be modeled as a matrix.
+
+
+
+
+Lee, et al. Informational [Page 6]
+
+RFC 7446 WSON Information Model February 2015
+
+
+ A resource block may be present in multiple resource pools.
+
+ This leads to the following formal high-level model:
+
+ <Node_Information> ::= <Node_ID>
+
+ [<ConnectivityMatrix>...]
+
+ [<ResourcePool>]
+
+ Where
+
+ <ResourcePool> ::= <ResourceBlockInfo>...
+
+ [<ResourceAccessibility>...]
+
+ [<ResourceWaveConstraints>...]
+
+ [<RBPoolState>]
+
+ First, the accessibility of resource blocks is addressed; then, their
+ properties are discussed.
+
+5.1. Resource Accessibility/Availability
+
+ A similar technique as used to model ROADMs, and optical switches can
+ be used to model regenerator/converter accessibility. This technique
+ was generally discussed in [RFC6163] and consisted of a matrix to
+ indicate possible connectivity along with wavelength constraints for
+ links/ports. Since regenerators or wavelength converters may be
+ considered a scarce resource, it is desirable that the model include,
+ if desired, the usage state (availability) of individual regenerators
+ or converters in the pool. Models that incorporate more state to
+ further reveal blocking conditions on input or output to particular
+ converters are for further study and not included here.
+
+ The three-stage model is shown schematically in Figures 1 and 2. The
+ difference between the two figures is that in Figure 1 it's assumed
+ that each signal that can get to a resource block may do so, while in
+ Figure 2 the access to sets of resource blocks is via a shared fiber
+ that imposes its own wavelength collision constraint. Figure 1 shows
+ that there can be more than one input to each resource block since
+ each input represents a single wavelength signal, while Figure 2
+ shows a single WDM input or output, e.g., a fiber, to/from each set
+ of blocks.
+
+
+
+
+
+
+Lee, et al. Informational [Page 7]
+
+RFC 7446 WSON Information Model February 2015
+
+
+ This model assumes N input ports (fibers), P resource blocks
+ containing one or more identical resources (e.g., wavelength
+ converters), and M output ports (fibers). Since not all input ports
+ can necessarily reach each resource block, the model starts with a
+ resource pool input matrix RI(i,p) = {0,1} depending on whether input
+ port i can potentially reach resource block p.
+
+ Since not all wavelengths can necessarily reach all the resources or
+ the resources may have limited input wavelength range, the model has
+ a set of relatively static input port constraints for each resource.
+ In addition, if the access to a set of resource blocks is via a
+ shared fiber (Figure 2), this would impose a dynamic wavelength
+ availability constraint on that shared fiber. The resource block
+ input port constraint is modeled via a static wavelength set
+ mechanism, and the case of shared access to a set of blocks is
+ modeled via a dynamic wavelength set mechanism.
+
+ Next, a state vector RA(j) = {0,...,k} is used to track the number of
+ resources in resource block j in use. This is the only state kept in
+ the resource pool model. This state is not necessary for modeling
+ "fixed" transponder system or full OEO switches with WDM interfaces,
+ i.e., systems where there is no sharing.
+
+ After that, a set of static resource output wavelength constraints
+ and possibly dynamic shared output fiber constraints maybe used. The
+ static constraints indicate what wavelengths a particular resource
+ block can generate or is restricted to generating, e.g., a fixed
+ regenerator would be limited to a single lambda. The dynamic
+ constraints would be used in the case where a single shared fiber is
+ used to output the resource block (Figure 2).
+
+ Finally, to complete the model, a resource pool output matrix RE(p,k)
+ = {0,1} depending on whether the output from resource block p can
+ reach output port k, may be used.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Lee, et al. Informational [Page 8]
+
+RFC 7446 WSON Information Model February 2015
+
+
+ I1 +-------------+ +-------------+ O1
+ ----->| | +--------+ | |----->
+ I2 | +------+ Rb #1 +-------+ | O2
+ ----->| | +--------+ | |----->
+ | | | |
+ | Resource | +--------+ | Resource |
+ | Pool +------+ +-------+ Pool |
+ | | + Rb #2 + | |
+ | Input +------+ +-------| Output |
+ | Connection | +--------+ | Connection |
+ | Matrix | . | Matrix |
+ | | . | |
+ | | . | |
+ IN | | +--------+ | | OM
+ ----->| +------+ Rb #P +-------+ |----->
+ | | +--------+ | |
+ +-------------+ ^ ^ +-------------+
+ | |
+ | |
+ | |
+ | |
+
+ Input wavelength Output wavelength
+ constraints for constraints for
+ each resource each resource
+
+ Note: Rb is a resource block.
+
+ Figure 1: Schematic Diagram of the Resource Pool Model
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Lee, et al. Informational [Page 9]
+
+RFC 7446 WSON Information Model February 2015
+
+
+ I1 +-------------+ +-------------+ O1
+ ----->| | +--------+ | |----->
+ I2 | +======+ Rb #1 +-+ | | O2
+ ----->| | +--------+ | | |----->
+ | | |=====| |
+ | Resource | +--------+ | | Resource |
+ | Pool | +-+ Rb #2 +-+ | Pool |
+ | | | +--------+ | |
+ | Input |====| | Output |
+ | Connection | | +--------+ | Connection |
+ | Matrix | +-| Rb #3 |=======| Matrix |
+ | | +--------+ | |
+ | | . | |
+ | | . | |
+ | | . | |
+ IN | | +--------+ | | OM
+ ----->| +======+ Rb #P +=======+ |----->
+ | | +--------+ | |
+ +-------------+ ^ ^ +-------------+
+ | |
+ | |
+ | |
+ Single (shared) fibers for block input and output
+
+ Input wavelength Output wavelength
+ availability for availability for
+ each block input fiber each block output fiber
+
+ Note: Rb is a resource block.
+
+ Figure 2: Schematic Diagram of the Resource Pool Model with
+ Shared Block Accessibility
+
+ Formally, the model can be specified as:
+
+ <ResourceAccessibility> ::= <PoolInputMatrix>
+
+ <PoolOutputMatrix>
+
+
+ <ResourceWaveConstraints> ::= <InputWaveConstraints>
+
+ <OutputWaveConstraints>
+
+
+ <RBSharedAccessWaveAvailability> ::= [<InAvailableWavelengths>]
+
+ [<OutAvailableWavelengths>]
+
+
+
+Lee, et al. Informational [Page 10]
+
+RFC 7446 WSON Information Model February 2015
+
+
+ <RBPoolState> ::= <ResourceBlockID>
+
+ <NumResourcesInUse>
+
+ [<RBSharedAccessWaveAvailability>]
+
+ [<RBPoolState>]
+
+ Note that, except for <RBPoolState>, all the components of
+ <ResourcePool> are relatively static. Also, the
+ <InAvailableWavelengths> and <OutAvailableWavelengths> are only used
+ in the cases of shared input or output access to the particular
+ block. See the resource block information in the next section for
+ how this is specified.
+
+5.2. Resource Signal Constraints and Processing Capabilities
+
+ The wavelength conversion abilities of a resource (e.g., regenerator,
+ wavelength converter) were modeled in the <OutputWaveConstraints>
+ previously discussed. As discussed in [RFC6163], the constraints on
+ an electro-optical resource can be modeled in terms of input
+ constraints, processing capabilities, and output constraints:
+
+ <ResourceBlockInfo> ::= <ResourceBlockSet>
+
+ [<InputConstraints>]
+
+ [<ProcessingCapabilities>]
+
+ [<OutputConstraints>]
+
+ Where <ResourceBlockSet> is a list of resource block identifiers
+ with the same characteristics. If this set is missing, the
+ constraints are applied to the entire network element.
+
+ The <InputConstraints> are constraints are based on signal
+ compatibility and/or shared access constraint indication. The
+ details of these constraints are defined in Section 5.3.
+
+ <InputConstraints> ::= <SharedInput>
+
+ [<OpticalInterfaceClassList>]
+
+ [<ClientSignalList>]
+
+ The <ProcessingCapabilities> are important operations that the
+ resource (or network element) can perform on the signal. The details
+ of these capabilities are defined in Section 5.3.
+
+
+
+Lee, et al. Informational [Page 11]
+
+RFC 7446 WSON Information Model February 2015
+
+
+ <ProcessingCapabilities> ::= [<NumResources>]
+
+ [<RegenerationCapabilities>]
+
+ [<FaultPerfMon>]
+
+ [<VendorSpecific>]
+
+ The <OutputConstraints> are either restrictions on the properties of
+ the signal leaving the block, options concerning the signal
+ properties when leaving the resource, or shared fiber output
+ constraint indication.
+
+ <OutputConstraints> := <SharedOutput>
+
+ [<OpticalInterfaceClassList>]
+
+ [<ClientSignalList>]
+
+5.3. Compatibility and Capability Details
+
+5.3.1. Shared Input or Output Indication
+
+ As discussed in Section 5.2 and shown in Figure 2, the input or
+ output access to a resource block may be via a shared fiber. The
+ <SharedInput> and <SharedOutput> elements are indicators for this
+ condition with respect to the block being described.
+
+5.3.2. Optical Interface Class List
+
+ <OpticalInterfaceClassList> ::= <OpticalInterfaceClass> ...
+
+ The Optical Interface Class is a unique number that identifies all
+ information related to optical characteristics of a physical
+ interface. The class may include other optical parameters related to
+ other interface properties. A class always includes signal
+ compatibility information.
+
+ The content of each class is out of the scope of this document and
+ can be defined by other entities (e.g., the ITU, optical equipment
+ vendors, etc.).
+
+ Since even current implementation of physical interfaces may support
+ different optical characteristics, a single interface may support
+ multiple interface classes. Which optical interface class is used
+ among all the ones available for an interface is out of the scope of
+ this document but is an output of the RWA process.
+
+
+
+
+Lee, et al. Informational [Page 12]
+
+RFC 7446 WSON Information Model February 2015
+
+
+5.3.3. Acceptable Client Signal List
+
+ The list is simply:
+
+ <ClientSignalList>::=[<G-PID>]...
+
+ Where the Generalized Protocol Identifiers (G-PID) object represents
+ one of the IETF-standardized G-PID values as defined in [RFC3471] and
+ [RFC4328].
+
+5.3.4. Processing Capability List
+
+ The ProcessingCapabilities are defined in Section 5.2.
+
+ The processing capability list sub-TLV is a list of processing
+ functions that the WSON network element (NE) can perform on the
+ signal including:
+
+ 1. number of resources within the block
+
+ 2. regeneration capability
+
+ 3. fault and performance monitoring
+
+ 4. vendor-specific capability
+
+ Note that the code points for fault and performance monitoring and
+ vendor-specific capability are subject to further study.
+
+6. Link Information (General)
+
+ MPLS-TE routing protocol extensions for OSPF [RFC3630] and IS-IS
+ [RFC5305], along with GMPLS routing protocol extensions for OSPF
+ [RFC4203] and IS-IS [RFC5307] provide the bulk of the relatively
+ static link information needed by the RWA process. However, WSONs
+ bring in additional link-related constraints. These stem from
+ characterizing WDM line systems, restricting laser transmitter
+ tuning, and switching subsystem port wavelength constraints, e.g.,
+ "colored" ROADM drop ports.
+
+ The following syntax summarizes both information from existing GMPLS
+ routing protocols and new information that may be needed by the RWA
+ process.
+
+
+
+
+
+
+
+
+Lee, et al. Informational [Page 13]
+
+RFC 7446 WSON Information Model February 2015
+
+
+ <LinkInfo> ::= <LinkID>
+
+ [<AdministrativeGroup>]
+
+ [<InterfaceCapDesc>]
+
+ [<Protection>]
+
+ [<SRLG>...]
+
+ [<TrafficEngineeringMetric>]
+
+ [<PortLabelRestriction>...]
+
+ Note that these additional link characteristics only apply to line-
+ side ports of a WDM system or add/drop ports pertaining to the
+ resource pool (e.g., regenerator or wavelength converter pool). The
+ advertisement of input/output tributary ports is not intended here.
+
+6.1. Administrative Group
+
+ Administrative Group: Defined in [RFC3630] and extended for MPLS-TE
+ [RFC7308]. Each set bit corresponds to one administrative group
+ assigned to the interface. A link may belong to multiple groups.
+ This is a configured quantity and can be used to influence routing
+ decisions.
+
+6.2. Interface Switching Capability Descriptor
+
+ InterfaceSwCapDesc: Defined in [RFC4202]; lets us know the different
+ switching capabilities on this GMPLS interface. In both [RFC4203]
+ and [RFC5307], this information gets combined with the maximum Link
+ State Protocol Data Unit (LSP) bandwidth that can be used on this
+ link at eight different priority levels.
+
+6.3. Link Protection Type (for This Link)
+
+ Protection: Defined in [RFC4202] and implemented in [RFC4203] and
+ [RFC5307]. Used to indicate what protection, if any, is guarding
+ this link.
+
+6.4. Shared Risk Link Group Information
+
+ SRLG: Defined in [RFC4202] and implemented in [RFC4203] and
+ [RFC5307]. This allows for the grouping of links into shared risk
+ groups, i.e., those links that are likely, for some reason, to fail
+ at the same time.
+
+
+
+
+Lee, et al. Informational [Page 14]
+
+RFC 7446 WSON Information Model February 2015
+
+
+6.5. Traffic Engineering Metric
+
+ TrafficEngineeringMetric: Defined in [RFC3630] and [RFC5305]. This
+ allows for the identification of a data-channel link metric value for
+ traffic engineering that is separate from the metric used for path
+ cost computation of the control plane.
+
+ Note that multiple "link metric values" could find use in optical
+ networks; however, it would be more useful to the RWA process to
+ assign these specific meanings such as "link mile" metric,
+ "probability of failure" metric, etc.
+
+6.6. Port Label Restrictions
+
+ Port label restrictions could be applied generally to any label types
+ in GMPLS by adding new kinds of restrictions. Wavelength is a type
+ of label.
+
+ Port label (wavelength) restrictions (PortLabelRestriction) model the
+ label (wavelength) restrictions that the link and various optical
+ devices, such as Optical Cross-Connects (OXCs), ROADMs, and waveband
+ multiplexers, may impose on a port. These restrictions tell us what
+ wavelength may or may not be used on a link and are relatively
+ static. This plays an important role in fully characterizing a WSON
+ switching device [Switch]. Port wavelength restrictions are
+ specified relative to the port in general or to a specific
+ connectivity matrix (Section 4.1). [Switch] gives an example where
+ both switch and fixed connectivity matrices are used and both types
+ of constraints occur on the same port.
+
+ <PortLabelRestriction> ::= <MatrixID>
+
+ <RestrictionType>
+
+ <Restriction parameters list>
+
+
+ <Restriction parameters list> ::=
+
+ <Simple label restriction parameters> |
+
+ <Channel count restriction parameters> |
+
+ <Label range restriction parameters> |
+
+ <Simple+channel restriction parameters> |
+
+ <Exclusive label restriction parameters>
+
+
+
+Lee, et al. Informational [Page 15]
+
+RFC 7446 WSON Information Model February 2015
+
+
+ <Simple label restriction parameters> ::= <LabelSet> ...
+
+
+ <Channel count restriction parameters> ::= <MaxNumChannels>
+
+
+ <Label range restriction parameters> ::= <MaxLabelRange>
+
+ (<LabelSet> ...)
+
+
+ <Simple+channel restriction parameters> ::= <MaxNumChannels>
+
+ (<LabelSet> ...)
+
+
+ <Exclusive label restriction parameters> ::= <LabelSet> ...
+
+ Where
+
+ MatrixID is the ID of the corresponding connectivity matrix (Section
+ 4.1).
+
+ The RestrictionType parameter is used to specify general port
+ restrictions and matrix-specific restrictions. It can take the
+ following values and meanings:
+
+ SIMPLE_LABEL: Simple label (wavelength) set restriction; the
+ LabelSet parameter is required.
+
+ CHANNEL_COUNT: The number of channels is restricted to be less
+ than or equal to the MaxNumChannels parameter (which is
+ required).
+
+ LABEL_RANGE: Used to indicate a restriction on a range of labels
+ that can be switched. For example, a waveband device with a
+ tunable center frequency and passband. This constraint is
+ characterized by the MaxLabelRange parameter, which indicates
+ the maximum range of the labels, e.g., which may represent a
+ waveband in terms of channels. Note that an additional
+ parameter can be used to indicate the overall tuning range.
+ Specific center frequency tuning information can be obtained
+ from information about the dynamic channel in use. It is
+ assumed that both center frequency and bandwidth (Q) tuning can
+ be done without causing faults in existing signals.
+
+
+
+
+
+
+Lee, et al. Informational [Page 16]
+
+RFC 7446 WSON Information Model February 2015
+
+
+ SIMPLE LABEL and CHANNEL COUNT: In this case, the accompanying
+ label set and MaxNumChannels indicate labels permitted on the
+ port and the maximum number of labels that can be
+ simultaneously used on the port.
+
+ LINK LABEL_EXCLUSIVITY: A label (wavelength) can be used at most
+ once among a given set of ports. The set of ports is specified
+ as a parameter to this constraint.
+
+ Restriction-specific parameters are used with one or more of the
+ previously listed restriction types. The currently defined
+ parameters are:
+
+ LabelSet is a conceptual set of labels (wavelengths).
+
+ MaxNumChannels is the maximum number of channels that can be
+ simultaneously used (relative to either a port or a matrix).
+
+ LinkSet is a conceptual set of ports.
+
+ MaxLabelRange indicates the maximum range of the labels. For
+ example, if the port is a "colored" drop port of a ROADM, then there
+ are two restrictions: (a) CHANNEL_COUNT, with MaxNumChannels = 1, and
+ (b) SIMPLE_WAVELENGTH, with the wavelength set consisting of a single
+ member corresponding to the frequency of the permitted wavelength.
+ See [Switch] for a complete waveband example.
+
+ This information model for port wavelength (label) restrictions is
+ fairly general in that it can be applied to ports that have label
+ restrictions only or to ports that are part of an asymmetric switch
+ and have label restrictions. In addition, the types of label
+ restrictions that can be supported are extensible.
+
+6.6.1. Port-Wavelength Exclusivity Example
+
+ Although there can be many different ROADM or switch architectures
+ that can lead to the constraint where a lambda (label) maybe used at
+ most once on a set of ports, Figure 3 shows a ROADM architecture
+ based on components known as Wavelength Selective Switches (WSSes)
+ [OFC08]. This ROADM is composed of splitters, combiners, and WSSes.
+ This ROADM has 11 output ports, which are numbered in the diagram.
+ Output ports 1-8 are known as drop ports and are intended to support
+ a single wavelength. Drop ports 1-4 output from WSS 2, which is fed
+ from WSS 1 via a single fiber. Due to this internal structure, a
+ constraint is placed on the output ports 1-4 that a lambda can be
+ used only once over the group of ports (assuming unicast and not
+ multicast operation). The output ports 5-8 have a similar constraint
+ due to the internal structure.
+
+
+
+Lee, et al. Informational [Page 17]
+
+RFC 7446 WSON Information Model February 2015
+
+
+ | A
+ v 10 |
+ +-------+ +-------+
+ | Split | |WSS 6 |
+ +-------+ +-------+
+ +----+ | | | | | | | |
+ | W | | | | | | | | +-------+ +----+
+ | S |--------------+ | | | +-----+ | +----+ | | S |
+ 9 | S |----------------|---|----|-------|------|----|---| p |
+ --| |----------------|---|----|-------|----+ | +---| l |<
+ | 5 |--------------+ | | | +-----+ | | +--| i |
+ +----+ | | | | | +------|-|-----|--| t |
+ +--------|-+ +----|-|---|------|----+ | +----+
+ +----+ | | | | | | | | |
+ | S |-----|--------|----------+ | | | | | | +----+
+ | p |-----|--------|------------|---|------|----|--|--| W |
+ ->| l |-----|-----+ | +----------+ | | | +--|--| S |11
+ | i |---+ | | | | +------------|------|-------|--| S |->
+ | t | | | | | | | | | | +---|--| |
+ +----+ | | +---|--|-|-|------------|------|-|-|---+ | 7 |
+ | | | +--|-|-|--------+ | | | | | +----+
+ | | | | | | | | | | | |
+ +------+ +------+ +------+ +------+
+ | WSS 1| | Split| | WSS 3| | Split|
+ +--+---+ +--+---+ +--+---+ +--+---+
+ | A | A
+ v | v |
+ +-------+ +--+----+ +-------+ +--+----+
+ | WSS 2 | | Comb. | | WSS 4 | | Comb. |
+ +-------+ +-------+ +-------+ +-------+
+ 1|2|3|4| A A A A 5|6|7|8| A A A A
+ v v v v | | | | v v v v | | | |
+
+ Figure 3: A ROADM Composed from Splitter, Combiners, and WSSes
+
+7. Dynamic Components of the Information Model
+
+ In the previously presented information model, there are a limited
+ number of information elements that are dynamic, i.e., subject to
+ change with subsequent establishment and teardown of connections.
+ Depending on the protocol used to convey this overall information
+ model, it may be possible to send this dynamic information separately
+ from the relatively larger amount of static information needed to
+ characterize WSONs and their network elements.
+
+
+
+
+
+
+
+Lee, et al. Informational [Page 18]
+
+RFC 7446 WSON Information Model February 2015
+
+
+7.1. Dynamic Link Information (General)
+
+ For WSON links, the wavelength availability and which wavelengths are
+ in use for shared backup purposes can be considered dynamic
+ information and hence are grouped with the dynamic information in the
+ following set:
+
+ <DynamicLinkInfo> ::= <LinkID>
+
+ <AvailableLabels>
+
+ [<SharedBackupLabels>]
+
+ AvailableLabels is a set of labels (wavelengths) currently available
+ on the link. Given this information and the port wavelength
+ restrictions, one can also determine which wavelengths are currently
+ in use. This parameter could potentially be used with other
+ technologies that GMPLS currently covers or may cover in the future.
+
+ SharedBackupLabels is a set of labels (wavelengths) currently used
+ for shared backup protection on the link. An example usage of this
+ information in a WSON setting is given in [Shared]. This parameter
+ could potentially be used with other technologies that GMPLS
+ currently covers or may cover in the future.
+
+ Note that the above does not dictate a particular encoding or
+ placement for available label information. In some routing
+ protocols, it may be advantageous or required to place this
+ information within another information element such as the Interface
+ Switching Capability Descriptor (ISCD). Consult the extensions that
+ are specific to each routing protocol for details of placement of
+ information elements.
+
+7.2. Dynamic Node Information (WSON Specific)
+
+ Currently the only node information that can be considered dynamic is
+ the resource pool state, and it can be isolated into a dynamic node
+ information element as follows:
+
+ <DynamicNodeInfo> ::= <NodeID> [<ResourcePool>]
+
+8. Security Considerations
+
+ This document discusses an information model for RWA computation in
+ WSONs. From a security standpoint, such a model is very similar to
+ the information that can be currently conveyed via GMPLS routing
+ protocols. Such information includes network topology, link state
+ and current utilization, as well as the capabilities of switches and
+
+
+
+Lee, et al. Informational [Page 19]
+
+RFC 7446 WSON Information Model February 2015
+
+
+ routers within the network. As such, this information should be
+ protected from disclosure to unintended recipients. In addition, the
+ intentional modification of this information can significantly affect
+ network operations, particularly due to the large capacity of the
+ optical infrastructure to be controlled. A general discussion on
+ security in GMPLS networks can be found in [RFC5920].
+
+9. References
+
+9.1. Normative References
+
+ [G.7715] ITU-T, "Architecture and requirements for routing in the
+ automatically switched optical networks", ITU-T
+ Recommendation G.7715, June 2002.
+
+ [RBNF] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax Used
+ to Form Encoding Rules in Various Routing Protocol
+ Specifications", RFC 5511, April 2009,
+ <http://www.rfc-editor.org/info/rfc5511>.
+
+ [RFC3471] Berger, L., Ed., "Generalized Multi-Protocol Label
+ Switching (GMPLS) Signaling Functional Description", RFC
+ 3471, January 2003,
+ <http://www.rfc-editor.org/info/rfc3471>.
+
+ [RFC3630] van der Meer, J., Mackie, D., Swaminathan, V., Singer, D.,
+ and P. Gentric, "RTP Payload Format for Transport of MPEG-4
+ Elementary Streams", RFC 3640, November 2003,
+ <http://www.rfc-editor.org/info/rfc3640>.
+
+ [RFC4202] Kompella, K., Ed., and Y. Rekhter, Ed., "Routing Extensions
+ in Support of Generalized Multi-Protocol Label Switching
+ (GMPLS)", RFC 4202, October 2005,
+ <http://www.rfc-editor.org/info/rfc4202>.
+
+ [RFC4203] Kompella, K., Ed., and Y. Rekhter, Ed., "OSPF Extensions in
+ Support of Generalized Multi-Protocol Label Switching
+ (GMPLS)", RFC 4203, October 2005,
+ <http://www.rfc-editor.org/info/rfc4203>.
+
+ [RFC4328] Papadimitriou, D., Ed., "Generalized Multi-Protocol Label
+ Switching (GMPLS) Signaling Extensions for G.709 Optical
+ Transport Networks Control", RFC 4328, January 2006,
+ <http://www.rfc-editor.org/info/rfc4328>.
+
+ [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic
+ Engineering", RFC 5305, October 2008,
+ <http://www.rfc-editor.org/info/rfc5305>.
+
+
+
+Lee, et al. Informational [Page 20]
+
+RFC 7446 WSON Information Model February 2015
+
+
+ [RFC5307] Kompella, K., Ed., and Y. Rekhter, Ed., "IS-IS Extensions
+ in Support of Generalized Multi-Protocol Label Switching
+ (GMPLS)", RFC 5307, October 2008,
+ <http://www.rfc-editor.org/info/rfc5307>.
+
+ [RFC6163] Lee, Y., Ed., Bernstein, G., Ed., and W. Imajuku,
+ "Framework for GMPLS and Path Computation Element (PCE)
+ Control of Wavelength Switched Optical Networks (WSONs)",
+ RFC 6163, April 2011,
+ <http://www.rfc-editor.org/info/rfc6163>.
+
+ [RFC7308] Osborne, E., "Extended Administrative Groups in MPLS
+ Traffic Engineering (MPLS-TE)", RFC 7308, July 2014,
+ <http://www.rfc-editor.org/info/rfc7308>.
+
+9.2. Informative References
+
+ [OFC08] Roorda, P., and B. Collings, "Evolution to Colorless and
+ Directionless ROADM Architectures", Optical Fiber
+ Communication / National Fiber Optic Engineers Conference
+ (OFC/NFOEC), 2008, pp. 1-3.
+
+ [RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS
+ Networks", RFC 5920, July 2010,
+ <http://www.rfc-editor.org/info/rfc5920>.
+
+ [Shared] Bernstein, G., and Y. Lee, "Shared Backup Mesh Protection
+ in PCE-based WSON Networks", iPOP 2008.
+
+ [Switch] Bernstein, G., Lee, Y., Gavler, A., and J. Martensson,
+ "Modeling WDM Wavelength Switching Systems for Use in GMPLS
+ and Automated Path Computation", Journal of Optical
+ Communications and Networking, vol. 1, June 2009, pp.
+ 187-195.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Lee, et al. Informational [Page 21]
+
+RFC 7446 WSON Information Model February 2015
+
+
+Contributors
+
+ Diego Caviglia
+ Ericsson
+ Via A. Negrone 1/A 16153
+ Genoa, Italy
+
+ Phone: +39 010 600 3736
+ EMail: diego.caviglia@(marconi.com, ericsson.com)
+
+
+ Anders Gavler
+ Acreo AB
+ Electrum 236
+ SE - 164 40 Kista
+ Sweden
+
+ EMail: Anders.Gavler@acreo.se
+
+
+ Jonas Martensson
+ Acreo AB
+ Electrum 236
+ SE - 164 40 Kista
+ Sweden
+
+ EMail: Jonas.Martensson@acreo.se
+
+
+ Itaru Nishioka
+ NEC Corp.
+ 1753 Simonumabe, Nakahara-ku, Kawasaki, Kanagawa 211-8666
+ Japan
+
+ Phone: +81 44 396 3287
+ EMail: i-nishioka@cb.jp.nec.com
+
+
+ Lyndon Ong
+ Ciena
+ EMail: lyong@ciena.com
+
+
+ Cyril Margaria
+ EMail: cyril.margaria@gmail.com
+
+
+
+
+
+
+Lee, et al. Informational [Page 22]
+
+RFC 7446 WSON Information Model February 2015
+
+
+Authors' Addresses
+
+ Young Lee (editor)
+ Huawei Technologies
+ 5369 Legacy Drive, Building 3
+ Plano, TX 75023
+ United States
+
+ Phone: (469) 277-5838
+ EMail: leeyoung@huawei.com
+
+
+ Greg M. Bernstein (editor)
+ Grotto Networking
+ Fremont, CA
+ United States
+
+ Phone: (510) 573-2237
+ EMail: gregb@grotto-networking.com
+
+
+ Dan Li
+ Huawei Technologies Co., Ltd.
+ F3-5-B R&D Center, Huawei Base,
+ Bantian, Longgang District
+ Shenzhen 518129
+ China
+
+ Phone: +86-755-28973237
+ EMail: danli@huawei.com
+
+
+ Wataru Imajuku
+ NTT Network Innovation Labs
+ 1-1 Hikari-no-oka, Yokosuka, Kanagawa
+ Japan
+
+ Phone: +81-(46) 859-4315
+ EMail: imajuku.wataru@lab.ntt.co.jp
+
+
+
+
+
+
+
+
+
+
+
+
+Lee, et al. Informational [Page 23]
+