Tech-invite3GPPspaceIETFspace
96959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 6163

Framework for GMPLS and Path Computation Element (PCE) Control of Wavelength Switched Optical Networks (WSONs)

Pages: 51
Informational
Part 2 of 2 – Pages 26 to 51
First   Prev   None

Top   ToC   RFC6163 - Page 26   prevText

4. Routing and Wavelength Assignment and the Control Plane

From a control plane perspective, a wavelength-convertible network with full wavelength-conversion capability at each node can be controlled much like a packet MPLS-labeled network or a circuit- switched Time Division Multiplexing (TDM) network with full-time slot interchange capability is controlled. In this case, the path
Top   ToC   RFC6163 - Page 27
   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.

4.1. Architectural Approaches to RWA

Two general computational approaches are taken to performing RWA. Some algorithms utilize a two-step procedure of path selection followed by wavelength assignment, and others perform RWA in a combined fashion. In the following sections, three different ways of performing RWA in conjunction with the control plane are considered. The choice of one of these architectural approaches over another generally impacts the demands placed on the various control plane protocols. The approaches are provided for reference purposes only, and other approaches are possible.

4.1.1. Combined RWA (R&WA)

In this case, a unique entity is in charge of performing routing and wavelength assignment. This approach relies on a sufficient knowledge of network topology, of available network resources, and of
Top   ToC   RFC6163 - Page 28
   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

4.1.2. Separated R and WA (R+WA)

In this case, one entity performs routing while a second performs wavelength assignment. The first entity furnishes one or more paths to the second entity, which will perform wavelength assignment and final path selection. The separation of the entities computing the path and the wavelength assignment constrains the class of RWA algorithms that may be implemented. Although it may seem that algorithms optimizing a joint usage of the physical and wavelength paths are excluded from this solution, many practical optimization algorithms only consider a limited set of possible paths, e.g., as computed via a k-shortest path algorithm. Hence, while there is no guarantee that the selected final route and wavelength offer the optimal solution, reasonable optimization can be performed by allowing multiple routes to pass to the wavelength selection process. The entity performing the routing assignment needs the topology information of the network, whereas the entity performing the wavelength assignment needs information on the network's available resources and specific network node capabilities.

4.1.3. Routing and Distributed WA (R+DWA)

In this case, one entity performs routing, while wavelength assignment is performed on a hop-by-hop, distributed manner along the previously computed path. This mechanism relies on updating of a list of potential wavelengths used to ensure conformance with the wavelength continuity constraint. As currently specified, the GMPLS protocol suite signaling protocol can accommodate such an approach. GMPLS, per [RFC3471], includes support for the communication of the set of labels (wavelengths) that
Top   ToC   RFC6163 - Page 29
   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.

4.2. Conveying Information Needed by RWA

The previous sections have characterized WSONs and optical path requests. In particular, high-level models of the information used by RWA process were presented. This information can be viewed as either relatively static, i.e., changing with hardware changes (including possibly failures), or relatively dynamic, i.e., those that can change with optical path provisioning. The time requirement in which an entity involved in RWA process needs to be notified of such changes is fairly situational. For example, for network restoration purposes, learning of a hardware failure or of new hardware coming online to provide restoration capability can be critical. Currently, there are various methods for communicating RWA relevant information. These include, but are not limited to, the following: o Existing control plane protocols, i.e., GMPLS routing and signaling. Note that routing protocols can be used to convey both static and dynamic information. o Management protocols such as NetConf, SNMPv3, and CORBA.
Top   ToC   RFC6163 - Page 30
   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

5. Modeling Examples and Control Plane Use Cases

This section provides examples of the fixed and switched optical node and wavelength constraint models of Section 3 and use cases for WSON control plane path computation, establishment, rerouting, and optimization.

5.1. Network Modeling for GMPLS/PCE Control

Consider a network containing three routers (R1 through R3), eight WSON nodes (N1 through N8), 18 links (L1 through L18), and one OEO converter (O1) in a topology shown in Figure 7.
Top   ToC   RFC6163 - Page 31
                       +--+    +--+             +--+       +--------+
                  +-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

5.1.1. Describing the WSON Nodes

The eight WSON nodes described in 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.
Top   ToC   RFC6163 - Page 32
   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):
Top   ToC   RFC6163 - Page 33
      +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  |   |
      +--+---+---+---+---+---+---+---+---+---+---+---+---+
Top   ToC   RFC6163 - Page 34

5.1.2. Describing the Links

For the following discussion, some simplifying assumptions are made: o It is assumed that the WSON node supports a total of four wavelengths, designated WL1 through WL4. o It is assumed that the impairment feasibility of a path or path segment is independent from the wavelength chosen. For the discussion of RWA operation, to build LSPs between two routers, the wavelength constraints on the links between the routers and the WSON nodes as well as the connectivity matrix of these links need to be specified: +Link+WLs supported +Possible output links+ | L1 | WL1 | L3 | +----+-----------------+---------------------+ | L2 | WL2 | L4 | +----+-----------------+---------------------+ | L8 | WL1 WL2 WL3 WL4 | L5 L7 L12 | +----+-----------------+---------------------+ | L9 | WL1 WL2 WL3 WL4 | L5 L7 L12 | +----+-----------------+---------------------+ | L10| WL2 | L6 | +----+-----------------+---------------------+ | L13| WL1 WL2 WL3 WL4 | L11 L14 | +----+-----------------+---------------------+ | L14| WL1 WL2 WL3 WL4 | L13 L16 | +----+-----------------+---------------------+ | L17| WL2 | L16 | +----+-----------------+---------------------+ | L18| WL1 | L15 | +----+-----------------+---------------------+ Note that the possible output links for the links connecting to the routers is inferred from the switched connectivity matrix and the fixed connectivity matrix of the Nodes N1 through N8 and is shown here for convenience; that is, this information does not need to be repeated.

5.2. RWA Path Computation and Establishment

The calculation of optical impairment feasible routes is outside the scope of this document. In general, optical impairment feasible routes serve as an input to an RWA algorithm.
Top   ToC   RFC6163 - Page 35
   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.
Top   ToC   RFC6163 - Page 36

5.3. Resource Optimization

The preceding example gives rise to another use case: the optimization of network resources. Optimization can be achieved on a number of layers (e.g., through electrical or optical multiplexing of client signals) or by re-optimizing the solutions found by an RWA algorithm. Given the above example again, assume that an RWA algorithm should identify a path between R2 and R3. The only possible path to reach R3 from R2 needs to use L9. L9, however, is blocked by one of the LSPs from R1.

5.4. Support for Rerouting

It is also envisioned that the extensions to GMPLS and PCE support rerouting of wavelengths in case of failures. For this discussion, assume that the only two LSPs in use in the system are: LSP1: WL1 L1 L3 L5 L8 LSP2: WL2 L2 L4 L6 L7 L9 Furthermore, assume that the L5 fails. An RWA algorithm can now compute and establish the following alternate path: R1 -> N7 -> R2 Level 3 regeneration will take place at N7, so that the complete path looks like this: R1 -> L2 L4 L6 L11 L13 -> O1 -> L14 L16 L15 L12 L9 -> R2

5.5. Electro-Optical Networking Scenarios

In the following subsections, various networking scenarios are considered involving regenerators, OEO switches, and wavelength converters. These scenarios can be grouped roughly by type and number of extensions to the GMPLS control plane that would be required.
Top   ToC   RFC6163 - Page 37

5.5.1. Fixed Regeneration Points

In the simplest networking scenario involving regenerators, regeneration is associated with a WDM link or an entire node and is not optional; that is, all signals traversing the link or node will be regenerated. This includes OEO switches since they provide regeneration on every port. There may be input constraints and output constraints on the regenerators. Hence, the path selection process will need to know the regenerator constraints from routing or other means so that it can choose a compatible path. For impairment-aware routing and wavelength assignment (IA-RWA), the path selection process will also need to know which links/nodes provide regeneration. Even for "regular" RWA, this regeneration information is useful since wavelength converters typically perform regeneration, and the wavelength continuity constraint can be relaxed at such a point. Signaling does not need to be enhanced to include this scenario since there are no reconfigurable regenerator options on input, output, or processing.

5.5.2. Shared Regeneration Pools

In this scenario, there are nodes with shared regenerator pools within the network in addition to the fixed regenerators of the previous scenario. These regenerators are shared within a node and their application to a signal is optional. There are no reconfigurable options on either input or output. The only processing option is to "regenerate" a particular signal or not. In this case, regenerator information is used in path computation to select a path that ensures signal compatibility and IA-RWA criteria. To set up an LSP that utilizes a regenerator from a node with a shared regenerator pool, it is necessary to indicate that regeneration is to take place at that particular node along the signal path. Such a capability does not currently exist in GMPLS signaling.

5.5.3. Reconfigurable Regenerators

This scenario is concerned with regenerators that require configuration prior to use on an optical signal. As discussed previously, this could be due to a regenerator that must be configured to accept signals with different characteristics, for regenerators with a selection of output attributes, or for regenerators with additional optional processing capabilities.
Top   ToC   RFC6163 - Page 38
   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.4. Relation to Translucent Networks

Networks that contain both transparent network elements such as Reconfigurable Optical Add/Drop Multiplexers (ROADMs) and electro- optical network elements such as regenerators or OEO switches are frequently referred to as translucent optical networks. Three main types of translucent optical networks have been discussed: 1. Transparent "islands" surrounded by regenerators. This is frequently seen when transitioning from a metro optical subnetwork to a long-haul optical subnetwork. 2. Mostly transparent networks with a limited number of OEO ("opaque") nodes strategically placed. This takes advantage of the inherent regeneration capabilities of OEO switches. In the planning of such networks, one has to determine the optimal placement of the OEO switches. 3. Mostly transparent networks with a limited number of optical switching nodes with "shared regenerator pools" that can be optionally applied to signals passing through these switches. These switches are sometimes called translucent nodes. All three types of translucent networks fit within the networking scenarios of Sections 5.5.1 and 5.5.2. Hence, they can be accommodated by the GMPLS extensions envisioned in this document.

6. GMPLS and PCE Implications

The presence and amount of wavelength conversion available at a wavelength switching interface have an impact on the information that needs to be transferred by the control plane (GMPLS) and the PCE architecture. Current GMPLS and PCE standards address the full wavelength conversion case, so the following subsections will only address the limited and no wavelength conversion cases.
Top   ToC   RFC6163 - Page 39

6.1. Implications for GMPLS Signaling

Basic support for WSON signaling already exists in GMPLS with the lambda (value 9) LSP encoding type [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.

6.1.1. Identifying Wavelengths and Signals

As previously stated, a global-fixed mapping between wavelengths and labels simplifies the characterization of WDM links and WSON devices. Furthermore, a mapping like the one described in [RFC6205] provides fixed mapping for communication between PCE and WSON PCCs.

6.1.2. WSON Signals and Network Element Processing

As discussed in 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
Top   ToC   RFC6163 - Page 40
   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.

6.1.3. Combined RWA/Separate Routing WA support

In either the combined RWA case or the separate routing WA case, the node initiating the signaling will have a route from the source to destination along with the wavelengths (generalized labels) to be used along portions of the path. Current GMPLS signaling supports an Explicit Route Object (ERO), and within an ERO, an ERO Label subobject can be used to indicate the wavelength to be used at a particular node. In case the local label map approach is used, the label subobject entry in the ERO has to be interpreted appropriately.

6.1.4. Distributed Wavelength Assignment: Unidirectional, No Converters

GMPLS signaling for a unidirectional optical path LSP allows for the use of a Label Set object in the Resource Reservation Protocol - Traffic Engineering (RSVP-TE) path message. Processing of the Label Set object to take the intersection of available lambdas along a path can be performed, resulting in the set of available lambdas being known to the destination, which can then use a wavelength selection algorithm to choose a lambda.

6.1.5. Distributed Wavelength Assignment: Unidirectional, Limited Converters

In the case of wavelength converters, nodes with wavelength converters would need to make the decision as to whether to perform conversion. One indicator for this would be that the set of available wavelengths that is obtained via the intersection of the incoming Label Set and the output links available wavelengths is either null or deemed too small to permit successful completion. At this point, the node would need to remember that it will apply wavelength conversion and will be responsible for assigning the wavelength on the previous lambda-contiguous segment when the RSVP-TE RESV message is processed. The node will pass on an enlarged label set reflecting only the limitations of the wavelength converter and the output link. The record route option in RSVP-TE signaling can be used to show where wavelength conversion has taken place.

6.1.6. Distributed Wavelength Assignment: Bidirectional, No Converters

There are cases of a bidirectional optical path that require the use of the same lambda in both directions. The above procedure can be used to determine the available bidirectional lambda set if it is
Top   ToC   RFC6163 - Page 41
   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.

6.2. Implications for GMPLS Routing

GMPLS routing [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].

6.2.1. Electro-Optical Element Signal Compatibility

In network scenarios where signal compatibility is a concern, it is necessary to add parameters to our existing node and link models to take into account electro-optical input constraints, output constraints, and the signal-processing capabilities of an NE in path computations. Input constraints: 1. Permitted optical tributary signal classes: A list of optical tributary signal classes that can be processed by this network element or carried over this link (configuration type)
Top   ToC   RFC6163 - Page 42
   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].

6.2.2. Wavelength-Specific Availability Information

For wavelength assignment, it is necessary to know which specific wavelengths are available and which are occupied if a combined RWA process or separate WA process is run as discussed in Sections 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
Top   ToC   RFC6163 - Page 43
   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].

6.2.3. WSON Routing Information Summary

The following table summarizes the WSON information that could be conveyed via GMPLS routing and attempts to classify that information according to its static or dynamic nature and its association with either a link or a node. Information Static/Dynamic Node/Link ------------------------------------------------------------------ Connectivity matrix Static Node Per-port wavelength restrictions Static Node(1) WDM link (fiber) lambda ranges Static Link WDM link channel spacing Static Link Optical transmitter range Static Link(2) Wavelength conversion capabilities Static(3) Node Maximum bandwidth per wavelength Static Link Wavelength availability Dynamic(4) Link Signal compatibility and processing Static/Dynamic Node Notes: 1. These are the per-port wavelength restrictions of an optical device such as a ROADM and are independent of any optical constraints imposed by a fiber link. 2. This could also be viewed as a node capability. 3. This could be dynamic in the case of a limited pool of converters where the number available can change with connection establishment. Note that it may be desirable to include regeneration capabilities here since OEO converters are also regenerators. 4. This is not necessarily needed in the case of distributed wavelength assignment via signaling. While the full complement of the information from the previous table is needed in the Combined RWA and the separate Routing and WA architectures, in the case of Routing + Distributed WA via Signaling, only the following information is needed:
Top   ToC   RFC6163 - Page 44
     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].

6.3. Optical Path Computation and Implications for PCE

As previously noted, RWA can be computationally intensive. Such computationally intensive path computations and optimizations were part of the impetus for the PCE architecture [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.

6.3.1. Optical Path Constraints and Characteristics

For the varying degrees of optimization that may be encountered in a network, the following models of bulk and sequential optical path requests are encountered: o Batch optimization, multiple optical paths requested at one time (PCE-GCO) o Optical path(s) and backup optical path(s) requested at one time (PCEP) o Single optical path requested at a time (PCEP) PCEP and PCE-GCO can be readily enhanced to support all of the potential models of RWA computation.
Top   ToC   RFC6163 - Page 45
   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

6.3.2. Electro-Optical Element Signal Compatibility

When requesting a path computation to PCE, the PCC should be able to indicate the following: o The G-PID type of an LSP o The signal attributes at the transmitter (at the source): (i) modulation type, (ii) FEC type o The signal attributes at the receiver (at the sink): (i) modulation type, (ii) FEC type The PCE should be able to respond to the PCC with the following: o The conformity of the requested optical characteristics associated with the resulting LSP with the source, sink, and NE along the LSP o Additional LSP attributes modified along the path (e.g., modulation format change)

6.3.3. Discovery of RWA-Capable PCEs

The algorithms and network information needed for RWA are somewhat specialized and computationally intensive; hence, not all PCEs within a domain would necessarily need or want this capability. Therefore, it would be useful to indicate that a PCE has the ability to deal with RWA via the mechanisms being established for PCE discovery [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.
Top   ToC   RFC6163 - Page 46
   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.

7. Security Considerations

This document does not require changes to the security models within GMPLS and associated protocols. That is, the OSPF-TE, RSVP-TE, and PCEP security models could be operated unchanged. However, satisfying the requirements for RWA using the existing protocols may significantly affect the loading of those protocols. This may make the operation of the network more vulnerable to denial- of-service attacks. Therefore, additional care maybe required to ensure that the protocols are secure in the WSON environment. Furthermore, the additional information distributed in order to address RWA represents a disclosure of network capabilities that an operator may wish to keep private. Consideration should be given to securing this information. For a general discussion on MPLS- and GMPLS-related security issues, see the MPLS/GMPLS security framework [RFC5920].

8. Acknowledgments

The authors would like to thank Adrian Farrel for many helpful comments that greatly improved the contents of this document.

9. References

9.1. Normative References

[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.
Top   ToC   RFC6163 - Page 47
   [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.

9.2. Informative References

[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.
Top   ToC   RFC6163 - Page 48
   [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.
Top   ToC   RFC6163 - Page 49
   [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.

Contributors

Snigdho Bardalai Fujitsu EMail: Snigdho.Bardalai@us.fujitsu.com Diego Caviglia Ericsson Via A. Negrone 1/A 16153 Genoa Italy Phone: +39 010 600 3736 EMail: diego.caviglia@marconi.com, diego.caviglia@ericsson.com
Top   ToC   RFC6163 - Page 50
   Daniel King
   Old Dog Consulting
   UK
   EMail: daniel@olddog.co.uk

   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

   Pierre Peloso
   Alcatel-Lucent
   Route de Villejust, 91620 Nozay
   France
   EMail: pierre.peloso@alcatel-lucent.fr

   Jonathan Sadler
   Tellabs
   EMail: Jonathan.Sadler@tellabs.com

   Dirk Schroetter
   Cisco
   EMail: dschroet@cisco.com

   Jonas Martensson
   Acreo
   Electrum 236
   16440 Kista
   Sweden
   EMail: Jonas.Martensson@acreo.se
Top   ToC   RFC6163 - Page 51

Authors' Addresses

Young Lee (editor) Huawei Technologies 1700 Alma Drive, Suite 100 Plano, TX 75075 USA Phone: (972) 509-5599 (x2240) EMail: ylee@huawei.com Greg M. Bernstein (editor) Grotto Networking Fremont, CA USA Phone: (510) 573-2237 EMail: gregb@grotto-networking.com Wataru Imajuku NTT Network Innovation Labs 1-1 Hikari-no-oka, Yokosuka, Kanagawa Japan Phone: +81-(46) 859-4315 EMail: wataru.imajuku@ieee.org