selection process needs to identify the Traffic Engineered (TE) links to be used by an optical path, and wavelength assignment can be made on a hop-by-hop basis. However, in the case of an optical network without wavelength converters, an optical path needs to be routed from source to destination and must use a single wavelength that is available along that path without "colliding" with a wavelength used by any other optical path that may share an optical fiber. This is sometimes referred to as a "wavelength continuity constraint". In the general case of limited or no wavelength converters, the computation of both the links and wavelengths is known as RWA. The inputs to basic RWA are the requested optical path's source and destination, the network topology, the locations and capabilities of any wavelength converters, and the wavelengths available on each optical link. The output from an algorithm providing RWA is an explicit route through ROADMs, a wavelength for optical transmitter, and a set of locations (generally associated with ROADMs or switches) where wavelength conversion is to occur and the new wavelength to be used on each component link after that point in the route. It is to be noted that the choice of a specific RWA algorithm is out of the scope of this document. However, there are a number of different approaches to dealing with RWA algorithms that can affect the division of effort between path computation/routing and signaling.
network nodes' capabilities. This solution is compatible with most known RWA algorithms, particularly those concerned with network optimization. On the other hand, this solution requires up-to-date and detailed network information. Such a computational entity could reside in two different places: o In a PCE that maintains a complete and updated view of network state and provides path computation services to nodes o In an ingress node, in which case all nodes have the R&WA functionality and network state is obtained by a periodic flooding of information provided by the other nodes RFC3471], includes support for the communication of the set of labels (wavelengths) that
may be used between nodes via a Label Set. When conversion is not performed at an intermediate node, a hop generates the Label Set it sends to the next hop based on the intersection of the Label Set received from the previous hop and the wavelengths available on the node's switch and ongoing interface. The generation of the outgoing Label Set is up to the node local policy (even if one expects a consistent policy configuration throughout a given transparency domain). When wavelength conversion is performed at an intermediate node, a new Label Set is generated. The egress node selects one label in the Label Set that it received; additionally, the node can apply local policy during label selection. GMPLS also provides support for the signaling of bidirectional optical paths. Depending on these policies, a wavelength assignment may not be found, or one may be found that consumes too many conversion resources relative to what a dedicated wavelength assignment policy would have achieved. Hence, this approach may generate higher blocking probabilities in a heavily loaded network. This solution may be facilitated via signaling extensions that ease its functioning and possibly enhance its performance with respect to blocking probability. Note that this approach requires less information dissemination than the other techniques described. The first entity may be a PCE or the ingress node of the LSP.
o Methods to access configuration and status information such as a command line interface (CLI). o Directory services and accompanying protocols. These are typically used for the dissemination of relatively static information. Directory services are not suited to manage information in dynamic and fluid environments. o Other techniques for dynamic information, e.g., sending information directly from NEs to PCEs to avoid flooding. This would be useful if the number of PCEs is significantly less than the number of WSON NEs. There may be other ways to limit flooding to "interested" NEs. Possible mechanisms to improve scaling of dynamic information include: o Tailoring message content to WSON, e.g., the use of wavelength ranges or wavelength occupation bit maps o Utilizing incremental updates if feasible Section 3 and use cases for WSON control plane path computation, establishment, rerouting, and optimization. Figure 7.
+--+ +--+ +--+ +--------+ +-L3-+N2+-L5-+ +--------L12--+N6+--L15--+ N8 + | +--+ |N4+-L8---+ +--+ ++--+---++ | | +-L9--+| | | | +--+ +-+-+ ++-+ || | L17 L18 | ++-L1--+ | | ++++ +----L16---+ | | |R1| | N1| L7 |R2| | | | | ++-L2--+ | | ++-+ | ++---++ +--+ +-+-+ | | | + R3 | | +--+ ++-+ | | +-----+ +-L4-+N3+-L6-+N5+-L10-+ ++----+ +--+ | +--------L11--+ N7 + +--+ ++---++ | | L13 L14 | | ++-+ | |O1+-+ +--+ Figure 7. Routers and WSON Nodes in a GMPLS and PCE Environment Figure 7 have the following properties: o Nodes N1, N2, and N3 have FOADMs installed and can therefore only access a static and pre-defined set of wavelengths. o All other nodes contain ROADMs and can therefore access all wavelengths. o Nodes N4, N5, N7, and N8 are multi-degree nodes, allowing any wavelength to be optically switched between any of the links. Note, however, that this does not automatically apply to wavelengths that are being added or dropped at the particular node. o Node N4 is an exception to that: this node can switch any wavelength from its add/drop ports to any of its output links (L5, L7, and L12 in this case). o The links from the routers are only able to carry one wavelength, with the exception of links L8 and L9, which are capable to add/drop any wavelength.
o Node N7 contains an OEO transponder (O1) connected to the node via links L13 and L14. That transponder operates in 3R mode and does not change the wavelength of the signal. Assume that it can regenerate any of the client signals but only for a specific wavelength. Given the above restrictions, the node information for the eight nodes can be expressed as follows (where ID = identifier, SCM = switched connectivity matrix, and FCM = fixed connectivity matrix):
+ID+SCM +FCM + | | |L1 |L2 |L3 |L4 | | |L1 |L2 |L3 |L4 | | | |L1 |0 |0 |0 |0 | |L1 |0 |0 |1 |0 | | |N1|L2 |0 |0 |0 |0 | |L2 |0 |0 |0 |1 | | | |L3 |0 |0 |0 |0 | |L3 |1 |0 |0 |1 | | | |L4 |0 |0 |0 |0 | |L4 |0 |1 |1 |0 | | +--+---+---+---+---+---+---+---+---+---+---+---+---+ | | |L3 |L5 | | | | |L3 |L5 | | | | |N2|L3 |0 |0 | | | |L3 |0 |1 | | | | | |L5 |0 |0 | | | |L5 |1 |0 | | | | +--+---+---+---+---+---+---+---+---+---+---+---+---+ | | |L4 |L6 | | | | |L4 |L6 | | | | |N3|L4 |0 |0 | | | |L4 |0 |1 | | | | | |L6 |0 |0 | | | |L6 |1 |0 | | | | +--+---+---+---+---+---+---+---+---+---+---+---+---+ | | |L5 |L7 |L8 |L9 |L12| |L5 |L7 |L8 |L9 |L12| | |L5 |0 |1 |1 |1 |1 |L5 |0 |0 |0 |0 |0 | |N4|L7 |1 |0 |1 |1 |1 |L7 |0 |0 |0 |0 |0 | | |L8 |1 |1 |0 |1 |1 |L8 |0 |0 |0 |0 |0 | | |L9 |1 |1 |1 |0 |1 |L9 |0 |0 |0 |0 |0 | | |L12|1 |1 |1 |1 |0 |L12|0 |0 |0 |0 |0 | +--+---+---+---+---+---+---+---+---+---+---+---+---+ | | |L6 |L7 |L10|L11| | |L6 |L7 |L10|L11| | | |L6 |0 |1 |0 |1 | |L6 |0 |0 |1 |0 | | |N5|L7 |1 |0 |0 |1 | |L7 |0 |0 |0 |0 | | | |L10|0 |0 |0 |0 | |L10|1 |0 |0 |0 | | | |L11|1 |1 |0 |0 | |L11|0 |0 |0 |0 | | +--+---+---+---+---+---+---+---+---+---+---+---+---+ | | |L12|L15| | | | |L12|L15| | | | |N6|L12|0 |1 | | | |L12|0 |0 | | | | | |L15|1 |0 | | | |L15|0 |0 | | | | +--+---+---+---+---+---+---+---+---+---+---+---+---+ | | |L11|L13|L14|L16| | |L11|L13|L14|L16| | | |L11|0 |1 |0 |1 | |L11|0 |0 |0 |0 | | |N7|L13|1 |0 |0 |0 | |L13|0 |0 |1 |0 | | | |L14|0 |0 |0 |1 | |L14|0 |1 |0 |0 | | | |L16|1 |0 |1 |0 | |L16|0 |0 |1 |0 | | +--+---+---+---+---+---+---+---+---+---+---+---+---+ | | |L15|L16|L17|L18| | |L15|L16|L17|L18| | | |L15|0 |1 |0 |0 | |L15|0 |0 |0 |1 | | |N8|L16|1 |0 |0 |0 | |L16|0 |0 |1 |0 | | | |L17|0 |0 |0 |0 | |L17|0 |1 |0 |0 | | | |L18|0 |0 |0 |0 | |L18|1 |0 |1 |0 | | +--+---+---+---+---+---+---+---+---+---+---+---+---+
For the example use case shown here, assume the following feasible routes: +Endpoint 1+Endpoint 2+Feasible Route + | R1 | R2 | L1 L3 L5 L8 | | R1 | R2 | L1 L3 L5 L9 | | R1 | R2 | L2 L4 L6 L7 L8 | | R1 | R2 | L2 L4 L6 L7 L9 | | R1 | R2 | L2 L4 L6 L10 | | R1 | R3 | L1 L3 L5 L12 L15 L18 | | R1 | N7 | L2 L4 L6 L11 | | N7 | R3 | L16 L17 | | N7 | R2 | L16 L15 L12 L9 | | R2 | R3 | L8 L12 L15 L18 | | R2 | R3 | L8 L7 L11 L16 L17 | | R2 | R3 | L9 L12 L15 L18 | | R2 | R3 | L9 L7 L11 L16 L17 | Given a request to establish an LSP between R1 and R2, an RWA algorithm finds the following possible solutions: +WL + Path + | WL1| L1 L3 L5 L8 | | WL1| L1 L3 L5 L9 | | WL2| L2 L4 L6 L7 L8| | WL2| L2 L4 L6 L7 L9| | WL2| L2 L4 L6 L10 | Assume now that an RWA algorithm yields WL1 and the path L1 L3 L5 L8 for the requested LSP. Next, another LSP is signaled from R1 to R2. Given the established LSP using WL1, the following table shows the available paths: +WL + Path + | WL2| L2 L4 L6 L7 L9| | WL2| L2 L4 L6 L10 | Assume now that an RWA algorithm yields WL2 and the path L2 L4 L6 L7 L9 for the establishment of the new LSP. An LSP request -- this time from R2 to R3 -- cannot be fulfilled since the four possible paths (starting at L8 and L9) are already in use.
As in the previous scenarios, it is necessary to have information concerning regenerator properties for selection of compatible paths and for IA-RWA computations. In addition, during LSP setup, it is necessary to be able to configure regenerator options at a particular node along the path. Such a capability does not currently exist in GMPLS signaling. 5.5.1 and 5.5.2. Hence, they can be accommodated by the GMPLS extensions envisioned in this document.
RFC3471] or for G.709-compatible optical channels, the LSP encoding type (value = 13) "G.709 Optical Channel" from [RFC4328]. However, a number of practical issues arise in the identification of wavelengths and signals and in distributed wavelength assignment processes, which are discussed below. RFC6205] provides fixed mapping for communication between PCE and WSON PCCs. Section 3.3.2, a WSON signal at any point along its path can be characterized by the (a) modulation format, (b) FEC, (c) wavelength, (d) bitrate, and (e) G-PID. Currently, G-PID, wavelength (via labels), and bitrate (via bandwidth encoding) are supported in [RFC3471] and [RFC3473]. These RFCs can accommodate the wavelength changing at any node along the LSP and can thus provide explicit control of wavelength converters. In the fixed regeneration point scenario described in Section 5.5.1, no enhancements are required to signaling since there are no additional configuration options for the LSP at a node. In the case of shared regeneration pools described in Section 5.5.2, it is necessary to indicate to a node that it should perform regeneration on a particular signal. Viewed another way, for an LSP, it is desirable to specify that certain nodes along the path perform regeneration. Such a capability does not currently exist in GMPLS signaling. The case of reconfigurable regenerators described in Section 5.5.3 is very similar to the previous except that now there are potentially many more items that can be configured on a per-node basis for an LSP. Note that the techniques of [RFC5420] that allow for additional LSP attributes and their recording in a Record Route Object (RRO) could be extended to allow for additional LSP attributes in an Explicit Route Object (ERO). This could allow one to indicate where optional
3R regeneration should take place along a path, any modification of LSP attributes such as modulation format, or any enhance processing such as performance monitoring.
interpreted that the available Label Set is available in both directions. According to [RFC3471], Section 4.1, the setup of bidirectional LSPs is indicated by the presence of an upstream label in the path message. However, until the intersection of the available Label Sets is determined along the path and at the destination node, the upstream label information may not be correct. This case can be supported using current GMPLS mechanisms but may not be as efficient as an optimized bidirectional single-label allocation mechanism. RFC4202] currently defines an interface capability descriptor for "Lambda Switch Capable" (LSC) that can be used to describe the interfaces on a ROADM or other type of wavelength selective switch. In addition to the topology information typically conveyed via an Interior Gateway Protocol (IGP), it would be necessary to convey the following subsystem properties to minimally characterize a WSON: 1. WDM link properties (allowed wavelengths) 2. Optical transmitters (wavelength range) 3. ROADM/FOADM properties (connectivity matrix, port wavelength restrictions) 4. Wavelength converter properties (per network element, may change if a common limited shared pool is used) This information is modeled in detail in [WSON-Info], and a compact encoding is given in [WSON-Encode].
2. Acceptable FEC codes (configuration type) 3. Acceptable bitrate set: a list of specific bitrates or bitrate ranges that the device can accommodate. Coarse bitrate info is included with the optical tributary signal-class restrictions. 4. Acceptable G-PID list: a list of G-PIDs corresponding to the "client" digital streams that is compatible with this device Note that the bitrate of the signal does not change over the LSP. This can be communicated as an LSP parameter; therefore, this information would be available for any NE that needs to use it for configuration. Hence, it is not necessary to have "configuration type" for the NE with respect to bitrate. Output constraints: 1. Output modulation: (a) same as input, (b) list of available types 2. FEC options: (a) same as input, (b) list of available codes Processing capabilities: 1. Regeneration: (a) 1R, (b) 2R, (c) 3R, (d) list of selectable regeneration types 2. Fault and performance monitoring: (a) G-PID particular capabilities, (b) optical performance monitoring capabilities. Note that such parameters could be specified on (a) a network- element-wide basis, (b) a per-port basis, or (c) a per-regenerator basis. Typically, such information has been on a per-port basis; see the GMPLS interface switching capability descriptor [RFC4202]. 4.1.1 and 4.1.2. This is currently not possible with GMPLS routing. In the routing extensions for GMPLS [RFC4202], requirements for layer-specific TE attributes are discussed. RWA for optical networks without wavelength converters imposes an additional requirement for the lambda (or optical channel) layer: that of knowing which specific wavelengths are in use. Note that current DWDM systems range from 16 channels to 128 channels, with advanced laboratory systems with as many as 300 channels. Given these channel limitations, if the
approach of a global wavelength to label mapping or furnishing the local mappings to the PCEs is taken, representing the use of wavelengths via a simple bitmap is feasible [Gen-Encode].
Information Static/Dynamic Node/Link ------------------------------------------------------------------ Connectivity matrix Static Node Wavelength conversion capabilities Static(3) Node Information models and compact encodings for this information are provided in [WSON-Info], [Gen-Encode], and [WSON-Encode]. RFC4655]. The Path Computation Element Communication Protocol (PCEP) defines the procedures necessary to support both sequential [RFC5440] and Global Concurrent Optimization (GCO) path computations [RFC5557]. With some protocol enhancement, the PCEP is well positioned to support WSON-enabled RWA computation. Implications for PCE generally fall into two main categories: (a) optical path constraints and characteristics, (b) computation architectures.
Optical path constraints include: o Bidirectional assignment of wavelengths o Possible simultaneous assignment of wavelength to primary and backup paths o Tuning range constraint on optical transmitter RFC5088]. [RFC5088] indicates that a sub-TLV could be allocated for this purpose. Recent progress on objective functions in PCE [RFC5541] would allow operators to flexibly request differing objective functions per their need and applications. For instance, this would allow the operator to choose an objective function that minimizes the total network cost associated with setting up a set of paths concurrently. This would also allow operators to choose an objective function that results in the most evenly distributed link utilization.
This implies that PCEP would easily accommodate a wavelength selection algorithm in its objective function to be able to optimize the path computation from the perspective of wavelength assignment if chosen by the operators. RFC5920]. [RFC3471] Berger, L., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, January 2003. [RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. [RFC3945] Mannie, E., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Architecture", RFC 3945, October 2004.
[RFC4202] Kompella, K., Ed., and Y. Rekhter, Ed., "Routing Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4202, October 2005. [RFC4328] Papadimitriou, D., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Extensions for G.709 Optical Transport Networks Control", RFC 4328, January 2006. [RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, August 2006. [RFC5088] Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R. Zhang, "OSPF Protocol Extensions for Path Computation Element (PCE) Discovery", RFC 5088, January 2008. [RFC5212] Shiomoto, K., Papadimitriou, D., Le Roux, JL., Vigoureux, M., and D. Brungard, "Requirements for GMPLS-Based Multi-Region and Multi-Layer Networks (MRN/MLN)", RFC 5212, July 2008. [RFC5557] Lee, Y., Le Roux, JL., King, D., and E. Oki, "Path Computation Element Communication Protocol (PCEP) Requirements and Protocol Extensions in Support of Global Concurrent Optimization", RFC 5557, July 2009. [RFC5420] Farrel, A., Ed., Papadimitriou, D., Vasseur, JP., and A. Ayyangarps, "Encoding of Attributes for MPLS LSP Establishment Using Resource Reservation Protocol Traffic Engineering (RSVP-TE)", RFC 5420, February 2009. [RFC5440] Vasseur, JP., Ed., and JL. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, March 2009. [RFC5541] Le Roux, JL., Vasseur, JP., and Y. Lee, "Encoding of Objective Functions in the Path Computation Element Communication Protocol (PCEP)", RFC 5541, June 2009. [Gen-Encode] Bernstein, G., Lee, Y., Li, D., and W. Imajuku, "General Network Element Constraint Encoding for GMPLS Controlled Networks", Work in Progress, December 2010.
[G.652] ITU-T Recommendation G.652, "Characteristics of a single-mode optical fibre and cable", November 2009. [G.653] ITU-T Recommendation G.653, "Characteristics of a dispersion-shifted single-mode optical fibre and cable", July 2010. [G.654] ITU-T Recommendation G.654, "Characteristics of a cut- off shifted single-mode optical fibre and cable", July 2010. [G.655] ITU-T Recommendation G.655, "Characteristics of a non- zero dispersion-shifted single-mode optical fibre and cable", November 2009. [G.656] ITU-T Recommendation G.656, "Characteristics of a fibre and cable with non-zero dispersion for wideband optical transport", July 2010. [G.671] ITU-T Recommendation G.671, "Transmission characteristics of optical components and subsystems", January 2009. [G.694.1] ITU-T Recommendation G.694.1, "Spectral grids for WDM applications: DWDM frequency grid", June 2002. [G.694.2] ITU-T Recommendation G.694.2, "Spectral grids for WDM applications: CWDM wavelength grid", December 2003. [G.698.1] ITU-T Recommendation G.698.1, "Multichannel DWDM applications with single-channel optical interfaces", November 2009. [G.698.2] ITU-T Recommendation G.698.2, "Amplified multichannel dense wavelength division multiplexing applications with single channel optical interfaces ", November 2009. [G.707] ITU-T Recommendation G.707, "Network node interface for the synchronous digital hierarchy (SDH)", January 2007. [G.709] ITU-T Recommendation G.709, "Interfaces for the Optical Transport Network (OTN)", December 2009. [G.872] ITU-T Recommendation G.872, "Architecture of optical transport networks", November 2001.
[G.959.1] ITU-T Recommendation G.959.1, "Optical transport network physical layer interfaces", November 2009. [G.Sup39] ITU-T Series G Supplement 39, "Optical system design and engineering considerations", December 2008. [Imajuku] Imajuku, W., Sone, Y., Nishioka, I., and S. Seno, "Routing Extensions to Support Network Elements with Switching Constraint", Work in Progress, July 2007. [RFC6205] Otani, T., Ed. and D. Li, Ed., "Generalized Labels of Lambda-Switch Capable (LSC) Label Switching Routers", RFC 6205, March 2011. [RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS Networks", RFC 5920, July 2010. [WSON-Encode] Bernstein, G., Lee, Y., Li, D., and W. Imajuku, "Routing and Wavelength Assignment Information Encoding for Wavelength Switched Optical Networks", Work in Progress, March 2011. [WSON-Imp] Lee, Y., Bernstein, G., Li, D., and G. Martinelli, "A Framework for the Control of Wavelength Switched Optical Networks (WSON) with Impairments", Work in Progress, April 2011. [WSON-Info] Bernstein, G., Lee, Y., Li, D., and W. Imajuku, "Routing and Wavelength Assignment Information Model for Wavelength Switched Optical Networks", Work in Progress, July 2008.
Daniel King Old Dog Consulting UK EMail: firstname.lastname@example.org Itaru Nishioka NEC Corp. 1753 Simonumabe, Nakahara-ku Kawasaki, Kanagawa 211-8666 Japan Phone: +81 44 396 3287 EMail: email@example.com Lyndon Ong Ciena EMail: Lyong@Ciena.com Pierre Peloso Alcatel-Lucent Route de Villejust, 91620 Nozay France EMail: firstname.lastname@example.org Jonathan Sadler Tellabs EMail: Jonathan.Sadler@tellabs.com Dirk Schroetter Cisco EMail: email@example.com Jonas Martensson Acreo Electrum 236 16440 Kista Sweden EMail: Jonas.Martensson@acreo.se