[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00 01 02 03 04

CCAMP Working Group                                    D. Papadimitriou
Internet Draft                                             M. Vigoureux
draft-vigoureux-shiomoto-ccamp-gmpls-mrn-00.txt               E. Dotaro
                                                              (Alcatel)
Expiration Date: April 2003
                                                            K. Shiomoto
                                                                 E. Oki
                                                            N. Matsuura
                                                                  (NTT)

                                                           October 2002



        Generalized MPLS Architecture for Multi-Region Networks

          - draft-vigoureux-shiomoto-ccamp-gmpls-mrn-00.txt -



Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups. Note that
   other groups may also distribute working documents as Internet-
   Drafts. Internet-Drafts are draft documents valid for a maximum of
   six months and may be updated, replaced, or obsoleted by other
   documents at any time. It is inappropriate to use Internet- Drafts
   as reference material or to cite them other than as "work in
   progress".

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html

Abstract

   Most of the efforts on Generalized MPLS were dedicated to
   environments including single switching capability devices, as such,
   the complexity raised by such control planes were equivalent to the
   one expected in classical IP/MPLS networks. The fundamental reason
   being that the definition of the control plane IP based protocol
   suite for Label Switch Routers (LSR) or Optical Cross-Connects (OXC)
   has exactly the same level complexity. The present document analyses
   the various GMPLS aspects when considering envinronments including
   combined LSR “ OXC devices. The latter covers opaque, service
   transparent and fully transparent (i.e. photonic) data planes. The
   intent of the first release of this memo is to demonstrate that


Vigoureux-Shiomoto et al      April 2003                             1

draft-vigoureux-shiomoto-ccamp-gmpls-mrn-00.txt              Oct. 2002


   these aspects may not be as straightforward as they may appear in
   first approach.

Table of Contents


   Status of this Memo................................................1

   Abstract...........................................................1

   Table of contents..................................................2

   1. Summary for Sub-IP Area.........................................3

   1.1. Summary.......................................................3

   1.2. Where does it fit in the Picture of the Sub-IP Work...........3

   1.3. Why is it Targeted at this WG.................................3

   1.4. Justification of Work.........................................3

   2. Conventions used in this document...............................3

   3. Introduction....................................................3

   4. Routing aspects.................................................5

   4.1. Forwarding Adjacencies........................................5

   4.2. Routing over FAs..............................................6

   4.2.1. Scalability.................................................6

   4.2.2. Emulating data plane overlays using FAs.....................6

   4.2.3. Robustness..................................................7

   4.2.4. TE Metric...................................................8

   4.3. Other cross-region considerations.............................8

   4.3.1. Interface adaptation capability descriptor..................9

   4.3.2. Enhanced interface capability..............................11

   4.4. Waveband switching...........................................11

   4.5. Physical constraints.........................................12

   5. Signaling aspects..............................................13

   5.1. LSP establishment schemes....................................13

   5.2. Label selection schemes......................................14

   5.2.1. First scheme...............................................14

   5.2.2. Second scheme..............................................15

   5.2.3. Third scheme...............................................16

   5.2.4. Schemes comparison.........................................16

   5.3. Label significance...........................................18

   5.3.1. Physical value.............................................19

   5.3.2. From statistical to deterministic..........................20

   5.4. LSP integrity................................................21

   5.4.1. Crossing regions...........................................21

   5.4.2 Dedicated traffic parameters................................21

   6. Summary........................................................22

   6.1. Signalling...................................................22

   6.2. Routing......................................................22

   7. Conclusions....................................................23

   8. Security considerations........................................23

   9. References.....................................................23

   10. Acknowledgments...............................................25


Vigoureux et al.              April 2003                             2

draft-vigoureux-shiomoto-ccamp-gmpls-mrn-00.txt              Oct. 2002



   11. AuthorsË addresses............................................25


1. Summary for Sub-IP Area

1.1. Summary

   See the Abstract above.

1.2. Where does it fit in the Picture of the Sub-IP Work

   This work fits the CCAMP box.

1.3. Why is it Targeted at this WG

   This draft is targeted at the CCAMP WG because it proposes a first
   input on common signaling and routing protocol considerations
   in multi-switching (a.k.a. multi-service) environments.

1.4. Justification of Work

   The CCAMP WG should consider this document as it provides an
   architectural framework for GMPLS-capable multi-switching capable
   devices as initiated in [GMPLS-RTG].

2. Conventions used in this document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC-2119.

   In addition the reader is assumed to be familiar with the concepts
   developed in [GMPLS-ARCH], [GMPLS-SIG], and [GMPLS-RTG] as well as
   [MPLS-HIER] and [MPLS-BUNDLE].

3. Introduction

   Generalized MultiProtocol Label Switching (GMPLS) facilitates the
   realization of seamless integration of IP/MPLS Networks with legacy
   SONET/SDH (see [T1.105]/[G.707]) or G.709 (see [G.709]) networks. In
   particular, integration of the packet/frame switching capability and
   circuit switching technologies under a unified GMPLS control plane
   would significantly enhance the forwarding capacity of the IP/MPLS
   network, while greatly reducing the total number of network elements
   to be managed.

   One of the other forces driving the construction of a unified GMPLS
   control plane is the desire to implement a multi-region routing
   capability. This would enable effective network resource utilization
   of both the Packet/Layer2 region and the Time Division Multiplexing
   (TDM) or Lambda (Optical Channels) regions in the high capacity
   networks.



Vigoureux et al.              April 2003                             3

draft-vigoureux-shiomoto-ccamp-gmpls-mrn-00.txt              Oct. 2002


   Vertical Vs. Horizontal integration
   -----------------------------------

   Vertical integration refers (see [TE-WG]) to the definition of
   collaborative mechanisms between multiple (but at least two) data
   planes (i.e. switching layers) using a single control plane
   instance. Horizontal integration is defined when each entity
   constituting the network environment includes only one single (data
   plane) switching capability. In this case the integration is defined
   between nodes hosting the same switching capability. For instance,
   the interconnection between packet and lambda switching capable
   networks defines an horizontal integration whilst an environment in
   which some devices (at least two and at most all) devices include
   packet and lambda switching capability involves a vertical
   integration within the GMPLS control plane. Note here that, the
   CCAMP Working Group is currently actively working on extensions to
   this horizontal integration (the initial iteration being the single
   area context worked out over the past two years) by considering
   multi-area traffic engineering while in a first phase vertical
   integration, as proposed in this memo, will focus on single area
   only environments. Such multi-switching level capable networks are
   referred to as Multi-Region Networks (MRN).

   From the control plane viewpoint a data plane layer is mapped to an
   LSP region. Following this approach, a Traffic Engineering link or
   simply TE Link (at the control plane level) maps exactly the
   definition proposed in the canonical layered model (see [G.805])
   where a link is defined as a link bundle (using the IETF
   terminology). Therefore, the TE Link concept opens the door for a
   clear separation between the routing adjacencies and the data plane
   bearer links (or channels). Furthermore, TE Links have been extended
   to non adjacent devices by introducing the Forwarding Adjacency (FA)
   concept enabling in turn to decrease the number of control plane
   instances to control N transport layers.

   Using the Forwarding Adjacency, a node may (under its local control
   policy configuration) advertise an LSP as a TE link into the same
   ISIS/OSPF instance as the one that induces this LSP. Such a link is
   referred to as a "Forwarding Adjacency" (FA) and the corresponding
   LSP to as a "Forwarding Adjacency LSP", or simply FA-LSP. Since the
   advertised entity appears as a TE link in ISIS/OSPF, both end-point
   nodes of the FA-LSP must belong to the same ISIS level/OSPF area
   (intra-area improvement of scalability). Afterwards, ISIS/OSPF
   floods the link-state information about FAs just as it floods the
   information about any other TE Link. This allows other nodes to use
   FAs as any other TE Links for path computation purposes.

   Rationales for Vertical Integration
   -----------------------------------

   The rationales for investigating vertical integration in the GMPLS
   distributed control plane context can be summarized as follows:


Vigoureux et al.              April 2003                             4

draft-vigoureux-shiomoto-ccamp-gmpls-mrn-00.txt              Oct. 2002


   - The maintenance of multiple instances of the control plane on
   devices hosting more than one switching capability not only (and
   obviously) increases the complexity of their interactions but also
   increases the total amount of processing individual instances would
   handle.
   - The merge of both data and control plane addressing spaces helps
   in avoiding multiple identification for the same object (a link for
   instance or more generally any network resource), on the other hand
   such aggregation does not impact the separation between the control
   and the data plane.
   - The collaboration between associated control planes (packet/framed
   data planes) and non-associated control planes (SONET/SDH, G.709,
   etc.) is facilitated due to the capability of hooking the associated
   in-band signalling to the IP terminating interfaces of the control
   plane.
   - Resource management and policies to be applied at the edges of
   such environment would be facilitated (less control to management
   interactions) and more scalable (through the use of aggregated
   information).

   In this context, Hybrid Photonic Networks (HPN) can be defined as a
   particular case of Multi-Region Networks (MRN). The main difference
   between nodes included in an HPN environment and nodes included in
   an MRN environment can be expressed as follows: the former MUST
   include at least for some (but at least two) of its interfaces an
   LSC switching capability. The latter MAY for some of its interfaces
   include LSC switching capability but MUST at least include two
   distinct switching capabilities taken from the following set {PSC,
   L2SC, TDM, LSC or FSC}. A MRN node MAY be for instance composed by
   L2SC + TDM switching capable interfaces or PSC + TDM switching
   capable interfaces. Moreover one assumes that the supported (LSP)
   encoding type is the same for all of its interfaces as specified in
   [GMPLS-RTG] and that any internal encoding conversion should be
   opaque at the network level. Nevertheless that latter may in some
   circumstances raise some issues with respect to the adaptation
   capabilities that may be used within such devices (see also Section
   4.3.1.).

   Specific aspects concerning HPN environments are further detailed in
   this memo, by considering opaque (client framing dependent), service
   transparent (client framing independence through network framing)
   and fully transparent environments.

4. Routing aspects

4.1. Forwarding Adjacencies

   In its successful attempt to extend MPLS for non-packet oriented TE-
   attributes within the scope of an integrated (routing) model
   encompassing several data planes, GMPLS has been rapidly confronted
   to the mapping of the several data planes within the control plane.



Vigoureux et al.              April 2003                             5

draft-vigoureux-shiomoto-ccamp-gmpls-mrn-00.txt              Oct. 2002


   Forwarding Adjacencies (FAs) as described in [MPLS-HIER] are a
   useful and powerful tool for improving the scalability of
   Generalized MPLS (GMPLS) Traffic Engineering (TE) capable networks.
   Through the aggregation of TE Label Switched Paths (LSPs) this
   concept enables the creation of a (nested) TE-LSP Hierarchy.
   Forwarding Adjacency LSPs (FA-LSP) may be advertised as TE link (or
   simply FA) into the same instance of ISIS/OSPF as the one that was
   used to create, initiate or trigger this LSP, allowing other LSRs to
   use FAs as TE links for their path computation. As such, forwarding
   adjacency LSPs have characteristics of both TE links and LSPs.

   While this definition is in perfect alignment for non-packet LSP
   regions and boundaries, the same concept(s) can also be re-used in
   the MPLS LSP context but with a major difference. The mapping goes
   in the opposite direction i.e. from the control to the IP/MPLS
   forwarding plane, since in the packet domain FA-LSPs are purely
   abstract objects that would, if well tailored, provide additional
   scalability within a routing plane instance (in particular, an
   area). Indeed, the use of FAs provides a mechanism for improving
   bandwidth (or more generally any resource) utilization when its
   dynamic allocation can be performed in discrete units; it also
   enables aggregating forwarding state, and in turn, reducing
   significantly the number of required labels. Therefore, FAs may
   significantly improve the scalability of GMPLS TE-capable control
   planes, and allow the creation of a TE-LSP hierarchy.

   From this, and when combining multi-region environments, the
   challenges that arise are related to the combination of both types
   of mappings (and in particular their control) for both super-classes
   of LSPs i.e. packet LSPs and circuit-oriented LSPs (a.k.a. non-
   packet LSPs) within the same control plane instance.

4.2. Routing over FAs

4.2.1. Scalability

   The Shortest Path First (SPF) computation complexity is, in
   classical cases, proportional to L Log(N) where L is the number of
   links (here, more precisely TE links) and N the number of address
   prefixes. When considering M regions, over the same control plane
   topology and without using any heuristics, one increases this
   complexity to M x L (Log (M x N)).

   Since TE Links can advertise multiple Interface Switching
   Capabilities (ISC), the number of links can be limited (by
   combination) by using specific topological maps referred to as VNT
   (Virtual Network Topologies). The introduction of virtual
   topological maps leads us to consider the concept of emulation of
   data plane overlays [MAMLTE].

   Therefore the expectation here is to reduce the overal computational
   complexity to L Log(M+1) Log (Log(M+1) x N) (note: with M = 1 it
   brings L Log(N)).

Vigoureux et al.              April 2003                             6

draft-vigoureux-shiomoto-ccamp-gmpls-mrn-00.txt              Oct. 2002



4.2.2. Emulating data plane overlays using FAs

   The main issue arising with FAs is related to the mapping
   directionality (from the data to the control plane). FAs allow
   avoiding the well-known O(N^2) at the control plane level by using
   the mechanisms defined in [MPLS-HIER] but requires a complex
   policing at the LSP region edges (or boundaries) in order to avoid
   full mesh at the data plane level.

   As such, the full mesh scalability issues can be solved in two ways
   either by improving the computational capabilities of the (C-)SPF
   algorithms or simply by keeping existing Log(N) complexity but then
   by improving collaboration between data planes. The former can be
   achieved for instance by using Fibonacci heaps with Log(Log(N))
   complexity for instance, which in turn, allows for a number of TE
   links greater than 1E6.

   Currently, and as specified in [MPLS-HIER], it is expected that FAs
   will not be used for establishing ISIS/OSPF peering relation between
   the routers at the ends of the adjacency thus clearly avoiding N
   square problem at the control plane level.

   On the other hand, at the data plane level (FAs only used in Traffic
   Engineering path computations), this can be accomplished by setting
   the default metric of the FA to max(1, (the TE metric of the FA-LSP
   path) - 1) so that it attracts traffic in preference to setting up a
   new LSP. Such policing clearly states that FA-LSPs are driven by a
   most fit approach: do not create new FA-LSPs as long as existing
   ones are not filled up. The main issue with this approach is
   definitely related to Ÿwhat to advertise and originate at LSP region
   boundaries÷. For instance, fully filled FA-LSPs should not be
   advertised (if preemption is not allowed) while attracting traffic
   should be provided in some coordinated manner in order to avoid sub-
   optimal FA-LSP setup. Moreover, nothing precludes the maintenance of
   several partially filled FA-LSPs that are kept unused indefinitely
   (even if their metric is set optimally) in particular when the
   bandwidth of the FA-LSP can not (due to its discrete bandwidths
   units) be exactly set to the incoming LSP request.

   Note: the latter suggests filtering of the corresponding LSAs at the
   regionsË boundaries. In OSPF this can be accomplished by not
   advertising the link as a regular LSA, but only as a TE opaque LSA
   (see [RFC-2370]).

4.2.3. Robustness

   According to [MPLS-HIER] ISC ordering, we can use the following
   terminology: FA-LSP(1) corresponds to TE Links for which the ISC is
   equal to PSC-1, FA-LSP(2) to PSC-2, FA-LSP(3) to PSC-3, FA-LSP(4) =
   PSC-4, FA-LSP(5) to TDM, FA-LSP(6) to LSC and FA-LSP(7) to FSC.



Vigoureux et al.              April 2003                             7

draft-vigoureux-shiomoto-ccamp-gmpls-mrn-00.txt              Oct. 2002


   FA-LSP(i) is routed over the FA-LSP(i+j) with j >= 1. In other words
   a set of FA-LSPs(i+j) with j fixed provides a virtual network
   topology (VNT) for routing FA-LSPs(i). The virtual network topology
   offered by a set of FA-LSPs(i) is denoted by VNT(i) in this
   document. The virtual network topology is changed by setting up
   and/or tearing down one (or more) FA-LSP(i). The change of the
   VNT(i) affects the routing of FA-LSPs(i-1). It is expected that
   boundary LSRs of VNT(i) will behave consistently with respect to any
   internal (LSP/link recovery) or external (LSP/link provisioning)
   triggering event.

   Routing is dependent on the network topology and associated link
   state. Routing stability may be impaired if the Virtual Network
   Topology frequently changes and/or if the status of links in the
   Virtual Network Topology frequently changes. In this context,
   robustness is defined as the capability to smooth changes that may
   occur and avoid their subsequent propagation. Changes of the Virtual
   Network Topology may be caused by the creation and/or deletion of
   several LSPs. Creation and deletion of LSPs may be triggered by
   adjacent regions or through operational actions to meet change of
   traffic demand. Routing robustness should be traded with
   adaptability with respect to the change of incoming traffic
   requests.

4.2.4. TE Metric

   Several FA-LSPs(i) between LSRs over LSP region(i+1) are already
   established, and several FA-LSPs(i-1) have been setup over this
   topology and are partially filled up. One of the latter LSR regions
   sees an incoming LSP request. It can be demonstrated that the TE
   metric (in addition to the Maximum LSP Bandwidth and Unreserved
   Bandwidth see [GMPLS-RTG]) alone is not a sufficient metric to
   compute the best path between these regions. This suggests that the
   inheritence process over which the TE-Metric of the FA is not as
   strightforward as proposed in [MPLS-HIER].

   The best example is a packet LSP (PSC-1) to be multiplexed into PSC-
   2 region that lies over an LSC region. The metric MUST not take only
   into account packet boundaries interface features, properties and
   traffic engineering attributes such as delay or bit-rate but also
   for instance the distance over the LSP region that this LSP will
   have to travel. As such, the TE Metric for the Lambda LSP (in this
   example, FA-LSP(i+1)) must be at least defined as a combination of
   the bit-rate and the distance, classically the bit-rate times the
   distance with some weighting factors. The main issue from this
   perspective is that joined Path TE Metric wouldnËt in such a case
   tackle simultaneously both packet and optical specifics.

   This suggests the definition of more flexible TE Metric, at least
   the definition of a TE Metric per ISC. Simply adjust the TE Metric
   to the (TE Metric of the FA-LSP path “ 1) is a valid approach
   between LSP over the same region class (PSC-1, PSC-2, ... , PSC-N,
   for instance) but not necessarily between PSC and LSC region.

Vigoureux et al.              April 2003                             8

draft-vigoureux-shiomoto-ccamp-gmpls-mrn-00.txt              Oct. 2002



4.3. Other cross-region considerations

   In an MRN, as described here above, each LSR would contain multiple-
   type switching capabilities such as PSC and Time-Division-
   Multiplexing (TDM) or PSC and Lambda Switching Capability (LSC) or
   LSC and Waveband Switching Capability under the control of a single
   GMPLS instance.

   These LSRs, with (integrated) multiple Interface Switching
   Capabilities (ISC), are required to hold and advertise resource
   information on link states and topology. They also may have to
   consider certain portions of internal LSR resources to terminate
   hierarchical label switched paths (LSPs), since circuit switch
   capable units such as TDMs, LSCs, and FSCs require rigid resources.

   For example, an LSR with the PSC+LSC integrated switching capability
   can forward a Lambda label switched path (or Lambda LSP) but can
   never terminate the Lambda LSP if there is no unused adaptation
   capability between the PSC and the LSC.

   Therefore, the concept of advertising adaptation capability (not
   capacity since can be inferred from the bandwidth available at each
   layer) to terminate LSPs, within such multi-region LSRs may be
   critical to perform multi-region route calculation of LSPs.

   This concept enables a local LSR to discriminate remote LSRs (and
   thus their selection during path computation) based on whether or
   not they have the needed adaptation capability to terminate Lambda
   LSPs at PSCs within the remote LSRs.

   Hence, here we introduce the idea of discriminating the adaptation
   capability from the switching capability in the LSR. Then, this
   draft proposes to add an interface adaptation capability descriptor
   (in the interface switching capability descriptor) and disseminate
   the LSP termination capability within multi-region LSRs.

4.3.1. Interface adaptation capability descriptor

   We propose an interface adaptation capability descriptor that can be
   interpreted either as the adaptation capability information from an
   incoming interface or as the adaptation capability to an outgoing
   interface for a given interface switching capability. By introducing
   such an additional descriptor (as a sub-object of the ISC sub-TLV
   for instance), the local GMPLS control plane can swiftly search
   which LSRs can terminate a certain encoding type of LSP and
   successfully establish an LSP tunnel between two PSCs.

   As an example, consider for instance a multiple switching region
   domain comprising simultaneously PSC LSRs, LSC LSRs, PSC+LSC LSRs
   and PSC+TDM+LSC LSRs. The LSRs discriminate the type of these links
   by the interface switching capability descriptor in LSAs [LSP-HIER].


Vigoureux et al.              April 2003                             9

draft-vigoureux-shiomoto-ccamp-gmpls-mrn-00.txt              Oct. 2002


   The interface switching capability at both ends of a TE-link shall
   be [LSC, LSC], [PSC, LSC], or [TDM, LSC] for fiber links carrying a
   "lambda" label. On the other hand, the interface switching
   capability at both ends of a TE link shall be [PSC, PSC] for LSPs
   that carry a "shim" header label, or shall be [TDM, TDM] or [PSC,
   TDM] for LSPs carrying "TDM time slot" labels. Based on the
   interface switching capability descriptor, the LSRs can impose
   proper constraints in order to compute the paths of the LSPs. For
   example, LSRs can understand that a remote TDM LSR with [TDM, LSC]
   link cannot forward LSPs, but can terminate LSPs and switch the "TDM
   timeslot".

   However, LSRs cannot infer the LSP switching capability of remote
   LSRs, especially if the LSRs have a multi-switching capability
   architecture such as a PSC+TDM+LSC LSR as shown below or more
   generally, more than two ISC capabilities. In the LSR, LSC may have
   a direct inner interface not only to TDM but also to PSC. The LSP
   can be interfaced at both TDM or PSC. This kind of multi-switching
   architecture may become very common in optical networks.

                           -------_
                    ------|       |------
                   |      |  PSC  |      |
                   |    --|       |--    |
                   |   |   -------   |   |
                   |  \|/           /|\  |
                   |   |   -------   |   |
                   |    --|       |--    |
                  \|/     |  TDM  |     /|\
                   |    --|       |--    |
                   |   |   -------   |   |
                   |  \|/           /|\  |
                   |   |   -------   |   |
                   |    --|       |--_   |
                   |      |       |      |
                    ------|       |------
                          |       |
                     /|   |       |   |\
                    | |---|       |---| |   Fiber #1
            ========| |---|  LSC  |---| |========
            ========| |---|       |---| |========
                     \|---|       |---|/    Fiber #N
                           -------

   Referring to this figure, the problem with the use of the interface
   switching capability descriptor at the PSC+TDM+LSC LSR, is the
   shortage of LSP termination capability information. The PSC+TDM+LSC
   LSRs provides only switching capability information by abstracting
   the internal node capabilities. Therefore, remote LSRs cannot
   accurately determine which switching capability can be terminated at
   the PSC+TDM+LSC LSR.



Vigoureux et al.              April 2003                            10

draft-vigoureux-shiomoto-ccamp-gmpls-mrn-00.txt              Oct. 2002


   Similar circumstances can occur, if a switching fabric that supports
   both PSC and L2SC functionalities is assembled with LSC with
   "lambda" (photonic) encoding. In the switching fabric, some
   interfaces terminate Lambda LSPs and perform frame (or cell)
   switching, other interfaces terminate Lambda LSPs and perform packet
   switching.

   Thus, the interface switching capability descriptor provides the
   information for the forwarding capability only. In order for remote
   LSRs to understand properly the termination capability of LSRs,
   additional information to the existing interface switching
   capability descriptor is essential in achieving seamless multi-
   region routing.

   This approach can deliver seamless routing such as the signalling of
   packet LSP set-up combined with an automatically triggering of new
   Lambda LSPs between the LSRs that do not yet have a preferred Lambda
   LSP to carry the Packet LSP. This even if multiple kinds of
   switching capabilities are assembled to form the LSCs using
   miscellaneous switching capabilities.

4.3.2. Enhanced interface capability

   In an HPN context, the lower LSP region provides for the upper LSP
   region, thanks to the presence of opto-electronic interfaces, a
   regeneration/conversion function. More precisely a regeneration
   function can deliver automatically conversion (within a given range
   pre-determined or not) while conversion may be delivered
   independently of the existence of any regeneration capability.

   The following classification applies from the definition of the
   regeneration function:

   1. If the regeneration function is defined as an Interface Switching
   Capability (or simply ISC see [GMPLS-RTG] and [GMPLS-HIER]), then if
   this ISC value is lower or equal to the incoming LSP switching type,
   the request may be processed by the network. Otherwise if the LSP
   Switching Type > ISC value of the region, the LSP request can not be
   processed and is simply rejected.

   2. If the regeneration function is not defined as an interface
   switching capability (pure regeneration without any connection
   function defined) then the following alternative applies depending
   on the encoding type defined at its entry points. If the
   regeneration depends on the encoding type of the incoming LSP
   request the latter must be the same as the one provided by the
   regeneration function. Otherwise the LSP request is simply rejected
   or tunneled toward the next hop (if feasible). Notice here that
   forwarding an LSP request to the next hop and expect the latter
   would provide enough regeneration capacity for this incoming LSP is
   a complex problem since can not with the currently available GMPLS
   tools guarantee that this request will not itself be forwarded to
   the next hop, and s.o.

Vigoureux et al.              April 2003                            11

draft-vigoureux-shiomoto-ccamp-gmpls-mrn-00.txt              Oct. 2002



   Moreover, by extending the knowlegde of the interface capability to
   terminate a given signal, it would be possible for instance to
   characterise more precisely the interfaces distance coverage. This
   may be achieved by considering information such as the transmission
   distance range (Short Haul, Long Haul, Ultra Long Haul, etc.) or
   even the modulation format. At the end, a more dynamic interface
   resource management than the one currently delivered by asynchronous
   Network Management techniques would be deliverable. In turn, one
   expects to decrease also the time needed for selecting resources
   during the path computation.

4.4. Waveband switching

   The GMPLS protocol suite, as currently defined, supports waveband
   switching through inverse multiplexing or switching of individual
   (contiguous) wavelength components. It may be thus appropriate to
   integrate wavebands in the switching hierarchy in order to reflect,
   at the control plane level, waveband physical components
   (multiplexer/demultiplexer) availability at the data plane [WBEXT].

   Also, depending on the (passive/active) components used in an
   optical network, wavelength spacing in the optical multiplex can
   vary. Some components like multiplexer/demultiplexer impose or
   depend on that spacing. Therefore, it may be appropriate to detail
   the component capability with respect to spacing, and/or to indicate
   the number of supported wavelengths per waveband. Moreover, one may
   also expect in case of (standardized) waveband nominal frequency
   values some simplification during the corresponding wavelength
   assignment.

   In the MRN context, the main issue with Waveband Switching can be
   viewed as follows. If the LSRs support in addition to waveband
   switching an ISC in the set {PSC, L2SC, TDM, FSC} then waveband
   switching can be assumed (from the control plane processing
   viewpoint) as being equivalent to Lambda Switching, if one considers
   labels as described here above. However if the additional switching
   capability within a single device, or even network, includes
   interfaces with LSC capability then either links should have a
   specific resource class assigned or dedicated values should be
   considered for the Encoding Type, Switching Type and G-PID (when
   bands are carried over fibers).

4.5. Physical constraints

   In most optical environments, due to the limited number of (shared)
   regeneration capability in HPNs, physical constraints have to be
   considered during both spatial and spectral routing.

   Since physical impairments (see for instance [IPO-IMP]) may be only
   relevant at the wavelength granularity, the latter requirement is
   confronted to a scalability problem if this information is to be
   flooded by a link state routing protocol. A solution would be to

Vigoureux et al.              April 2003                            12

draft-vigoureux-shiomoto-ccamp-gmpls-mrn-00.txt              Oct. 2002


   appropriately aggregate physical impairment information at the TE
   Link level. This would in turn provide an aggregated information on
   signal degradation enabling TE Link selection during the LSP path
   computation. On the other hand, summarized information can be either
   delivered using its absolute or abstracted semantic. The latter case
   simply refers to abstracted information (such a service levels for
   instance). Needless to precise here that both summarized and
   abstracted spectral information would translate in sub-optimal
   routing.

   Another class of solution would consist of passing physical
   constraint on a hop by hop basis and perform selection (filtering)
   depending on the constraints expressed by the sender. The issue
   being here that the blocking probability is directly proportional to
   the number of hops to take into account in the path but also on the
   occupancy level of each of the selected fiber spans.

   In any case, if the considered physical impairments are nearly
   static or have a long variation period they may either be flooded
   using the DoNotAge flag set (see [RFC-1793]) or may not be flooded
   at all. In the latter case, the corresponding information would be
   just made available for path selection by using another class of
   mechanism such as using the management plane. Otherwise, and as
   stated here above, some specific means to aggregate physical
   impairments information and to disseminate this information will be
   needed.

   Last, as stated in [IPO-IMP], a distance based approach (the
   physical distance of each span) is made available and usable by the
   routing protocol instance. The knowledge of this information would
   allow constructing maps (i.e. specific photonic virtual network
   topologies) through which domains of transparency would be feasible
   and physical impairments would only be used at their egress. Main
   issue here being to determine the best exit point knowing that
   subsequent decision are dependent on the impairments that have
   already affected the outgoing signal. Also this approach suggest
   some (spectral) constraint passing toward these edges in order to
   compute the (sub-)path for reaching the next edge node (seen as a
   loose hop). The latter lead us to consider some specific signalling
   aspects.

5. Signaling aspects

   MRN environments do not introduce specific problems as long as the
   LSRs are homogeneous and do not include an LSC or FSC capability.
   Therefore most the of issues related to signalling are related to
   hybrid photonic environments where constraints such as resource
   availability are of utmost importance in particular when
   regeneration / conversion functions are limited and shared.

   When considering HPN environments, resources are no longer
   symmetrical with respect to regeneration/conversion functions (see
   Section 4.3.2.). This property deeply impacts the complexity of the

Vigoureux et al.              April 2003                            13

draft-vigoureux-shiomoto-ccamp-gmpls-mrn-00.txt              Oct. 2002


   wavelength selection schemes (a.k.a. spectral path computation) as
   well as the wavelength continuity requirement when none of the
   devices provides any conversion capability. This, in addition to the
   selection of entities delivering regeneration capability, which is
   conditioned by resource availability and optical signal degradation.

   This section highlights the signalling issues raised by these
   emerging trends including transparency.

5.1. LSP establishment schemes

   The concept of hierarchical LSPs was introduced in [LSP-HIERARCHY].
   GMPLS signaling protocol of RSVP allows to set up nested LSPs.

   When a new LSP is set up, this LSP setup may trigger the
   establishment of an FA-LSP if the latter does not yet exist. Thus
   the incoming LSP can use the FA-LSP as a link along this lower LSP
   region. Here an FA-LSP is taken as a TE link of the lower LSP
   region. The bandwidth of the FA-LSP is equal to or larger than that
   of the FA (see [MPLS-HIER]).

   In the sequential scheme (as currently defined in [GMPLS-ARCH] and
   [MPLS-HIER]) the Path message of the lower LSP region is transmitted
   from a node to the downstream neighbor node, only after a higher-
   region LSP has been established. This can be considered as the
   safest and cleanest way to provide nested LSP setup.

   The concurrent scheme allows a Path message to be transmitted to the
   downstream neighbor node without waiting for the establishment of
   the higher-region LSP. The confirmation of the establishment of the
   higher-region LSP is performed at the source node of the higher LSP
   region before a Resv message of the lower LSP region is transmitted
   to the upstream neighbor node.

5.2. Label selection schemes

   Establishing a connection throughout an optical network involves the
   computation and selection of a path constrained by spatial and
   spectral routing information. This may be achieved using a two steps
   operation: determination of an explicit spatial route followed by a
   signaling phase selecting network resources (e.g. sequence of
   wavelengths) to be used by the LSP. In this document, these two
   phases are respectively referred to as spatial routing and spectral
   routing. It has emphasized that spatial routing constraints are
   external constraints conveyed during the LSP request while spatial
   routing constraints may be a combination of both external and
   internal (or intrinsic) constraints due to the physical transmission
   medium for instance. Notice that external spectral routing
   constraints are generally dictated by Bit Error Rate (BER) or
   inferred through Service Levels.

   The different schemes listed below (see also [ONM-1]) tend to
   address the issues arising from the introduction of transparency in

Vigoureux et al.              April 2003                            14

draft-vigoureux-shiomoto-ccamp-gmpls-mrn-00.txt              Oct. 2002


   optical networks (or equivalently the need to consider spectral
   traffic engineering attributes with the TE Link routing
   information). The impact of each scheme on the protocol architecture
   is detailed afterwards.

5.2.1. First scheme

   The ingress node performs spatial and spectral routing decision.
   This scheme assumes that both spatial and spectral Traffic
   Engineering routing information is made available (at least) at the
   edges of the optical network. Additional complexity arising from
   hybrid environments dictates that such information would be
   available at each hop.

   The main issue in this context is related to the need for making
   this information available per optical channel (or potential
   wavelength channel that can be established throughout the network).
   Thus precluding by definition the usage of wavelength bundles since
   their component links (or data links) are correlated on spatial
   traffic engineering information routing basis.

   Due to link-state scalability issues (and since one does not
   consider here feeding of the spectral routing related information
   through the backward or upstream signaling flow), this scheme is not
   considered in the context of this memo.

5.2.2. Second scheme

   The ingress node performs spatial routing, while the intermediate
   nodes perform spectral routing (hop-by-hop label selection is part
   of spectral routing).


   When using this scheme, two classes of mechanisms can be considered
   depending on the directionality of the LSP.

   1. Asymmetrical:

   At one hand of the spectrum and as currently specified, the GMPLS
   protocol suite definition reflects an asymmetrical scheme.

        1. Unidirectional LSP: (downstream) label set
        2. Bi-directional LSP: (downstream) label set and upstream
           label

   Per [GMPLS-SIG], the Label Set selection works according to an AND
   scheme. Each hop restricts the Label Set sent to the next hop from
   the one received from the previous hop by performing an AND
   operation between the wavelength referred by the labels the Label
   Set includes, with the one available on the ongoing interface. The
   constraint to perform this AND operation is up to the node local
   policy (even if one expects a consistent policy configuration
   throughout a given transparency domain).

Vigoureux et al.              April 2003                            15

draft-vigoureux-shiomoto-ccamp-gmpls-mrn-00.txt              Oct. 2002



   It must be emphasized that this scheme is compliant with RSVP
   receiver oriented approach (see [RFC 2205]): for bi-directional LSP
   the upstream node specifies the upstream label and lets the
   downstream node determine the downstream label given a label set
   into which the corresponding label must be selected. The major point
   to underline can be described as follows: if the nominal wavelength
   value has to be identical in both upstream and downstream direction,
   the downstream label is strictly constraint by the (local) upstream
   label value. Using this scheme and in case of blocking on the
   (corresponding) local value, an Acceptable Label Set is returned to
   the ingress node. As such this scheme may generate M-1 retries
   (going back and forth) before reaching an egress node separated by M
   links. Note also that blocking MUST never occur on the Label Set of
   values, as such this technique assumes that the largest set is used
   at each hop and the egress node makes a (downstream) label selection
   decision.

   2. Symmetrical:

   At the other end of the spectrum an improvement that may be provided
   is to extend the upstream label to an upstream label set, thus one
   would have the following symmetrical approach when using an AND
   label selection scheme:

        1. Unidirectional selection scheme: (downstream) label set
        2. Bi-directional selection scheme: (downstream) label set and
           upstream label set

   The Resv message will then either include the downstream label in
   addition to the upstream label, in case of bi-directional LSP.
   Notice that here both labels are selected at the egress. Detailed
   extensions concerning the upstream label set are described in [OKI-
   UPSTRM].

   When wavelength conversion is performed at an intermediate node, a
   new Label Set MUST be generated. The egress nodes selects one label
   in the Label Set received at the node. According to the selected
   label for the incoming link at the egress node, each label on the
   route is determined in a hop-by-hop manner.

5.2.3. Third scheme

   The ingress node performs spatial routing while the egress node
   performs spectral routing. Here, intermediate nodes may be allowed
   performing some local processing (as long as this processing is
   consistently defined for a given transparency domain).

   Spectral related information is fed through downstream signaling
   toward the egress node according to an ALL scheme (see also [OKI-
   IPO]). The ALL scheme when used for bi-directional path setup must
   take into account not only outgoing spectral routing information but
   also incoming spectral routing information and perform the selection

Vigoureux et al.              April 2003                            16

draft-vigoureux-shiomoto-ccamp-gmpls-mrn-00.txt              Oct. 2002


   at the destination based on a correlation operation between both
   upstream and downstream flows.

   For this purpose, at each hop, a Label Set object may be appended to
   the global Label Set (more precisely to the list of Label Set
   objects defining an end-to-end significant Label Set). Additional
   processing may be performed at intermediate nodes depending on local
   constraints in particular in order to decrease the amount of
   information to be carried towards the egress node.

   At the end of the process and according to the collected spectral
   information, the egress node determines all the labels on the route
   considering the (individual) local constraints.

5.2.4. Schemes comparison

   In case of the second scheme (see Section 5.2.), the Label Set
   reduction works according to an AND scheme. Each hop restricts the
   label set sent to the next hop from the one received from the
   previous hop by performing an AND operation between the wavelengths
   referred by the Labels it includes the one available on the ongoing
   interface.

   This method generates an important issue with respect to the
   probability of having the Label Set reduced to an empty set of
   labels before reaching the egress node (if each hop only proposes
   Labels referring to wavelengths that are neither converted nor
   regenerated).

   Note that using crank-back procedure can help reducing blocking
   probability. A node may initiate a crank-back procedure if all
   wavelengths referred in the Label Set coming from the upstream node
   are not usable on the outgoing links to the downstream node. It has
   to be clearly emphasized here that crank-back only applies when the
   Label Set initiated by the ingress (or reduced by intermediate
   nodes) follows policy rules other than the Ÿabsolute largest set÷
   i.e. crank-back may only be applied when Label Set policy restrict
   arbitrarily the number of labels included in the set. Otherwise when
   blocking on the Label Set occurs it means that the LSP is not
   feasible at all.

   If conversion capabilities are available at this node and accessible
   by the wavelengths referred in the Label Set coming from the
   upstream node, the node may propose a new Label Set including Labels
   accessible through conversion. As such conversion availability re-
   initialize the Label Set. An LSP being converted N times between the
   ingress and egress node defines N-1 sub-paths.

   If conversion functions are either not available in the node or/nor
   accessible by the wavelengths referred in the Label Set coming from
   the upstream node, the node may send a message (including an
   Acceptable Label Set) to the upstream nodes in order for the latter
   to propose new Labels (via conversion). The Acceptable Label Set

Vigoureux et al.              April 2003                            17

draft-vigoureux-shiomoto-ccamp-gmpls-mrn-00.txt              Oct. 2002


   included in this message is used as feedback by the ingress node (or
   more precisely by the node having performed the last conversion
   operation) to intelligently propose new Label values in the set.

   Crank-back may reduce blocking probability but generates an issue
   concerning signaling messages that may go back to the source and
   forth many times before spectral path is found. Consequently, an
   additional improvement should target intermediate Label Set
   initialization point as (intermediate) destination of such messages
   in order to avoid that the source (located behind the initialization
   point) takes a contradictory decision based on the Acceptable Label
   Set information. Moreover, it can be demonstrated that Label Set
   utilization according to the AND scheme with crank-back feature (in
   addition to the applicability rules described here above) is sub-
   optimal with respect to the minimization of the number of conversion
   / regeneration points along the path. Nevertheless, in the same
   context, only a global knowledge of spectral resources availability
   along the spatial path enables optimal spectral path computation.

   It may be thus proposed to feed this information through signaling
   using Label Set combined with an ALL scheme (i.e. also referred to
   as Ÿexhaustive scheme÷) and do spectral path computation at the
   egress node. This refers to third scheme. Note that the exhaustive
   property may be relaxed according to a local policy in order to
   reduce the amount of information exchange from the source to the
   destination (i.e. over the entire LSP).

   At each hop, the local Label Set object is appended to the Label Set
   (more precisely to the list of Label Let objects). Additional
   processing might be done at intermediate nodes depending on local
   constraints and policy. The egress node receives the spectral
   information collected along at least one spatial path. It can then
   compute, using this spectral information, the optimal combination or
   transparent sub-paths.

   The third scheme provides an added value compared to the second one.
   It enables ensuring (a better) wavelength continuity while jointly
   addressing regeneration needs along the path, though it requires
   having the knowledge (at egress) of the ability a node to access
   regeneration for a given wavelength.

   The issue here is to make a clear differentiation between a Path
   message with resource reservation and a so-called probing message,
   defined as a message only probing for the resource availability. For
   that purpose an additional status of the request can be defined in
   the signaling protocol. For instance, using a specific
   Administrative Status flag (see [GMPLS-SIG], other solutions may
   also be considered here for this purpose.

   Hence, the following method may be considered:
       - Path/Label Request message(s), along several but at least one
         spatial explicit routes computed at ingress
       - Computation at the egress of the best combination of

Vigoureux et al.              April 2003                            18

draft-vigoureux-shiomoto-ccamp-gmpls-mrn-00.txt              Oct. 2002


         transparent sub-paths. (Wavelength Labels containing the
         necessary information for this purposes)
       - Resv/Label Mapping message through the selected path
       - PathErr/Notification messages to the non-selected path (if one
         considers that releasing the reserved resources must be
         performed)

   Note: Downstream Wavelength Selection and Reservation can only be
   considered with Selective AND scheme. The ALL Scheme with forward
   (downstream) reservation is precluded since it would generate an
   overwhelming blocking probability, so this method can only be used
   with a backward (upstream) reservation. Nevertheless, Soft Selection
   (control plane only) can be considered either with a Selective AND
   and Exhaustive ALL scheme.

5.3. Label significance

   As specified in [GMPLS-SIG], the Wavelength label space may include
   either absolute values (channel identifiers (Channel ID) also
   referred to as wavelength identifiers) or relative values (channel
   spacing also referred to as inter-wavelength spacing). The latter is
   strictly confined to a per-port label space while the former could
   be defined as a local or a global (per node) label space.

   However, both wavelength selection schemes listed above require the
   knowledge of the mapping between collected Labels and the wavelength
   spectral-related information they locally refer. Therefore, in this
   context, it is proposed to define an association between the Label
   value and the wavelength spectral information.

   Using the second scheme, the upstream nodes receiving an Acceptable
   Label Set message, due to the crank-back procedure, must be able to
   understand to which wavelengths these Label values refer to. In
   third scheme, the egress node must also know which wavelengths the
   Labels refer to in order to achieve the expected wavelength
   continuity.

5.3.1. Physical value

  Two different scenarios can be envisaged for nodes to know the
  underlying wavelength nominal value behind a Label proposed by a
  distant node. Also consider here that jittering is assumed to be
  known and stable in this context.

  Hop-by-hop label translation, assumes that the label values are
  translated at each from their incoming as delivered by the upstream
  node to their outgoing value(s). As such this simply means that the
  spectralinformation related to the link local topology can be simply
  translated. Further this means that the corresponding spectral
  traffic engineering information should also be kept locally and as
  such does not allow for any decision made on network-wide scope
  basis. This is fundamentally an issue when links are not carrying
  channels that terminates over the same interfaces, or equivalently

Vigoureux et al.              April 2003                            19

draft-vigoureux-shiomoto-ccamp-gmpls-mrn-00.txt              Oct. 2002


  the link concept simply translates trunks through which optical
  channels will be routed but these channels will use sequence of such
  trunks over the optical network.

  Complexity is generated from the following issue, one can not ensure
  that the trunk will behave like a Ÿpassive component÷. This simply
  means that its current state MAY depends on the previous (in
  particular, the reactive behavior of these trunks is strongly
  dependent on the type of equipment it includes, gain clamped edfaËs,
  variable optical amplifiers, etc.). More than certainly, a confidence
  interval (a jitter measurement) such as the ones considered in ATM
  (Cell Delay Variation Time - CDVT) may help in adjusting the traffic
  engineering decisions over time. In brief, photonic networks do not
  only add per component spectral routing constraints but also make
  these dependencies variable over time.

   The second approach for defining the association between the Label
   value and the wavelength spectral information is achieved by
   specifying semanticfull and dedicated fields in the 32 bits Label.
   This specification simply corresponds to a Label value assignment
   rule and still ensures backward compatibility for nodes not able to
   understand the hereafter defined semantic.

   This Label may for instance include the following additional
   information reflecting the spectral capabilities and attributes of
   the selected Label:

   - Wavelength Index : Identifies the wavelength for a given
     Amplification Band by considering minimum channel spacing.

   - Wavelength Identifier : Used to differentiate Labels (proposed for
     example in a Label Set) that would have same values of the fields
     listed above.

   Other definitions not detailed here may also be used for the same
   purpose. It should be also emphasized that such label space
   definition does not raise (in an absolute sense) any backward
   compatibility issue with respect to [GMPLS-SIG] since the latter
   considers that any translation can be applied locally. In particular
   one assumes here that the node may still locally convert these
   values into a value which has an internal significance only.
   Therefore, no specific procedures should be defined to achieve
   backward compatibility.

5.3.2. From statistical to deterministic

   In order to decide where regeneration / conversion should be ideally
   performed because of signal degradation/blocking probabilities, the
   knowledge of the capability associated to a wavelength to be
   regenerated is also important.




Vigoureux et al.              April 2003                            20

draft-vigoureux-shiomoto-ccamp-gmpls-mrn-00.txt              Oct. 2002


   This Label may for instance include the following additional
   information reflecting the spectral capabilities and attributes of
   the selected Label:

   - Regeneration (R) : set by the node proposing the Label. Informs
     whether the corresponding wavelength can be regenerated or not
     note: this applies only if the regeneration function does not
     define a switching layer

   - Conversion (C) : set by the node proposing the Label. Informs
     whether the corresponding wavelength can be converted or not.

   This semantic may be related to the wavelength index and identifier,
   the underlying issue is related to the upstream label exchange, as
   such one expects the same issue as the one arising from the Label
   Set utilization here. More precisely the use of such semanticfull
   label suggests the definition of a symmetrical processing for both
   the upstream and downstream flow. Also notice here that since the
   label keeps a link local significance raising the question about
   whether an ALL scheme is suitable when such label structure is used.
   Detailed considerations on this particular are left for further
   study.

5.4. LSP integrity

5.4.1. Crossing regions

   Crossing regions may be performed for two main reasons: regeneration
   (when delivered by a switching capable layer) or grooming.

   1. Regeneration

   Knowing the constraints of optical transmission, the optical signal
   might have to be regenerated along the path. Some multi-region
   network architectures require to cross a region boundary in order to
   access the regeneration function. This rises the question of what
   could be called LSP integrity through crossing region boundaries.

   Consider for instance a Lambda LSP in a PSC+LSC multi-region
   network. For a given reason the LSP needs to be regenerated at an
   intermediate node. It will thus use the O/E/O interfaces present in
   the PSC region. From the control plane viewpoint either two Lambda
   LSPs are seen (ingress to intermediate and intermediate to egress)
   or a single one (ingress to egress).

   Keeping a single Lambda LSP would prevent from maintaining, at the
   control plane level, several entities for a single connection. It
   should be also noticed here that one assumes that regeneration is
   delivered between LSPs (from ingress to intermediate and
   intermediate to egress) defined within regions of the same switching
   capability. This would in turn facilitate the processing of both the
   regenerated entities and the (pool of) regeneration resources.


Vigoureux et al.              April 2003                            21

draft-vigoureux-shiomoto-ccamp-gmpls-mrn-00.txt              Oct. 2002


   2. Grooming

   Related to the previous issue, and directly linked to the
   optimization of network resource utilization is the need to perform
   LSP grooming. MRN environments are particularly well adapted for
   this feature as they may provide different switching granularities
   allowing for the tunnelling of several finer grained LSPs into a
   coarser grained LSP. Just as for the previous issues, it would be
   useful from the control plane viewpoint not to terminate an LSP in
   order to tunnel this LSP into a lower-region LSP.

   This raises the question of the representation of the newly
   established LSP at the control plane level. In particular,
   concerning the maintenance of the two LSPs (head-end and tail-end
   LSPs) that forms the newly spliced LSPs. Further consideration on
   grooming are left here for further study since the above
   considerations lead to the definition of multipoint-to-point LSPs.

5.4.2. Dedicated traffic parameters

   The remaining point is related to whether or not dedicated traffic
   parameters should be defined for LSPs established MRN or HPN
   environments. With respect to spatial routing the LSP Encoding Type,
   Switching Type and G-PID (see [GMPLS-SIG] for the corresponding
   definitions) provides the required information to pertinently setup
   such LSPs. It is nevertheless expected here to see some additional
   capability allowing for transient states. In particular when the
   regeneration function is defined as a switching layer.

   Now from the spectral routing viewpoint (and if we dissociate this
   discussion from the one concerning the label assignment scheme) the
   main issue raises from the passing of external physical constraints
   between conversion points. In addition to the Multiplier usage that
   may help in establshing/deleting parallel LSPs, additional
   information concerning the physical constraint each sub-path MUST
   fulfill should be considered in the present context. A parameter
   equivalent to the Transparency level may help in providing a hop-by-
   hop negotiation of the regeneration capability to be used. Last a
   maximum distance and BER per (sub-path) would also be conceivable.

   Additional consideration concerning the need for dedicated traffic
   parameters in optical environement are left for further study.

6. Summary

   The following tables summarize the GMPLS Signalling and Routing
   mechanisms considered in the previous sections:

6.1 Signalling

   --------------------------------------------------------------------
   Path setup                           Sequential versus Concurrent
                                        Scheme

Vigoureux et al.              April 2003                            22

draft-vigoureux-shiomoto-ccamp-gmpls-mrn-00.txt              Oct. 2002


   --------------------------------------------------------------------
   Generalized Label Request            (Photonic) Traffic Parameters
   --------------------------------------------------------------------
   Generalized Label                    Label semantic
                                        Distribution rules (AND vs ALL
                                        Scheme)
   --------------------------------------------------------------------
   Interface Identification             Sub-interface through Label
                                        semantic
   --------------------------------------------------------------------
   Waveband Switching                   Approach based on [WBEXT]
   --------------------------------------------------------------------
   Label Set and Bidirectional LSPs     Symmetrical: downstream and
                                        upstream label set [GMPLS-SIG]
                                        Asymmetrical: downstream label
                                        and upstream label
   --------------------------------------------------------------------
   Explicit Label Control               LSP Splicing (Cross-Region)
   --------------------------------------------------------------------

6.2. Routing

   --------------------------------------------------------------------
   ISC Descriptor                       Additional Interface Adaptation
                                        Capability
   --------------------------------------------------------------------
   TE Metric                            Considerations about Multi-
                                        Switching Capability
   --------------------------------------------------------------------
   Waveband Switching                   Approach based on [WBEXT]
   --------------------------------------------------------------------

   Note: in particular, additional routing consideration are to be
   expected in future releases of this memo.

7. Conclusions

   In this memo, we address the issues when using the GMPLS protocol
   suite as unified control plane for MSN environments and in
   particular HPN networks. Several alternatives have been proposed in
   enhancing the current GMPLS mechanisms and protocol details without
   putting under questioning its foundations (see [GMPLS-ARCH]). Also
   this memo by proposing an analysis of the suitability of the GMPLS
   protocol suite for such environment keeps a strict and full
   alignment with the current and preferred suite of signalling and
   routing protocols (in particular, OSPF, IS-IS, RSVP-TE and LMP).
   This said a detailed discussion concerning the suitability and
   optimality may be considered for some ccampËers as either not
   justified (we donËt spend too much efforts in optimization) or
   overkilled (Generalized MPLS, does not mean Universal MPLS). To
   these open questions the response may be as follows. By starting
   from a single area context, the expectations coming out from the
   first release of this memo, are clearly intended to open the field

Vigoureux et al.              April 2003                            23

draft-vigoureux-shiomoto-ccamp-gmpls-mrn-00.txt              Oct. 2002


   of more detailed description of the collaborative processes within
   the GMPLS protocol suite. Therefore, even if the context into which
   these considerations have been introduced may be perceived as too
   largely scoped, one can still consider this topic as challenging
   enough in its attempt to optimize its current well accepted
   mechanisms.

   But what do we have to expect from such effort, and how will it
   impact my current GMPLS implementation ? Well the first point to
   clearly underline here is, the main guideline is backward
   compatibility with the current GMPLS protocols suite. Then, the
   other issue that may arise (and that will more certainly arise in
   the very short future) is related to the delivery of strong
   guarantees and insurance that the current item scope will not
   generate unbounded (or not handled) complexity. This question may be
   asked equivalently as how far can such a topic go in defining new
   (even backward compatible) mechanisms. Since currently only
   alternatives have been proposed we invite the CCAMP community to
   collaborate on these challenging topics in order to make them as
   tiny as possible.

8. Security considerations

   In its current version, this memo does not introduce new security
   consideration from the ones already detailed in the GMPLS protocol
   suite.

9. References

   [GMPLS-ARCH] E.Mannie (Editor) et al.,
                "Generalized Multi-Protocol Label Switching (GMPLS)
                Architecture",
                Internet draft, Work in progress,
                draft-ietf-ccamp-gmpls-architecture-03.txt

   [GMPLS-ISIS] K. Kompella (Editor), Y. Rekhter (Editor) et al.,
                "IS-IS Extensions in Support of Generalized MPLS",
                Internet draft, Work in progress,
                draft-ietf-isis-gmpls-extensions-14.txt

   [GMPLS-OSPF] K. Kompella (Editor), Y. Rekhter (Editor) et al.,
                "OSPF Extensions in Support of Generalized MPLS",
                Internet draft, Work in progress,
                draft-ietf-ccamp-ospf-gmpls-extensions-08.txt

   [GMPLS-SIG]  P. Ashwood-Smith et al.,
                "Generalized MPLS-Signaling Functional Description",
                Internet draft, Work in progress,
                draft-ietf-mpls-generalized-signaling-09.txt

   [GMPLS-RTG]  K. Kompella (Editor), Y. Rekhter (Editor) et al.,
                "Routing Extensions in Support of Generalized MPLS",
                Internet draft, Work in progress,

Vigoureux et al.              April 2003                            24

draft-vigoureux-shiomoto-ccamp-gmpls-mrn-00.txt              Oct. 2002


                draft-ietf-ccamp-gmpls-routing-05.txt

   [WBEXT]      R. Douville et al.,
                "Extensions to Generalized MPLS for Waveband
                Switching",
                Internet draft, Work in progress,
                draft-douville-ccamp-gmpls-waveband-extensions-01.txt

   [IPO-IMP]    A. Chiu et al.,
                "Impairments And Other Constraints On Optical Layer
                Routing",
                Internet draft, Work in progress,
                draft-ietf-ipo-impairments-03.txt.

   [ISIS-TE]    H. Smit and T. Li,
                "IS-IS Extensions for Traffic Engineering", Work in
                progress,
                Internet draft, Work in progress,
                draft-ietf-isis-traffic-04.txt

   [OKI-IPO]    E. Oki et al.,
                "Requirements of optical link-state information for
                traffic engineering",
                Internet draft, Work in progress,
                draft-oki-ipo-optlink-req-00.txt

   [OKI-UPSTRM] E. Oki et al.,
                "Upstream Label Set Support in RSVP-TE extensions",
                Internet draft, Work in progress,
                draft-oki-ccamp-upstream-labelset-00.txt

   [OZU-FLAGS]  T. Ozugur et al.,
                "Label Set Priority and Flagging Operations",
                Internet draft, Work in progress,
                draft-ozugur-ccamp-gmpls-label-flag-00.txt

   [MAMLTE]     K. Shiomoto et al.,
                "Multi-area multi-layer traffic engineering using
                hierarchical LSPs in GMPLS networks",
                Internet draft, Work in progress,
                draft-shiomoto-multiarea-te-01.txt

   [MLRT]       W. Imajuku et al.,
                "Multilayer routing using multilayer switch capable
                LSRs",
                Internet draft, Work in progress,
                draft-imajuku-ml-routing-02.txt

   [ONM-1]      "A comparative study of distributed protocols for
                wavelength reservation in WDM Optical networks",
                Optical Network Magazine, January 2002.

   [OSPF-TE]    D. Katz, D. Yeung and K. Kompella,

Vigoureux et al.              April 2003                            25

draft-vigoureux-shiomoto-ccamp-gmpls-mrn-00.txt              Oct. 2002


                "Traffic Engineering Extensions to OSPF Version 2",
                Internet draft, Work in progress,
                draft-katz-yeung-ospf-traffic-08.txt

10. Acknowledgments

   We would like to thank here, Sven Van Den Bosch, Richard Douville,
   Olivier Audouin, Amaury Jourdan, Emmanuel Desmet and Bernard sales.

   The authors would like to thank Mr. Wataru Imajuku for the
   discussions on adaptation between regions [MLRT].

11. Author's addresses

   Dimitri Papadimitriou (Alcatel)
   Fr.Wellensplein 1, B-2018 Antwerpen, Belgium
   E-mail : dimitri.papadimitriou@alcatel.fr
   Phone  : +32 3 2408491

   Martin Vigoureux (Alcatel)
   Route de Nozay, 91461 Marcoussis cedex
   E-mail : martin.vigoureux@alcatel.fr
   Phone  : +33 1 69631852

   Emmanuel Dotaro (Alcatel)
   Route de Nozay, 91461 Marcoussis cedex
   E-mail : emmanuel.dotaro@alcatel.fr
   Phone  : +33 1 69634723

   Kohei Shiomoto
   NTT Network Innovation Laboratories
   3-9-11 Midori-cho
   Musashino-shi, Tokyo 180-8585, Japan
   Phone: +81 422 59 4402
   Fax: +81 422 59 6387
   E-mail: shiomoto.kohei@lab.ntt.co.jp

   Eiji Oki
   NTT Network Innovation Laboratories
   3-9-11 Midori-cho
   Musashino-shi, Tokyo 180-8585, Japan
   Phone: +81 422 59 3441
   Fax: +81 422 59 6387
   E-mail: oki.eiji@lab.ntt.co.jp

   Eiji Oki
   NTT Network Service Systems Laboratories
   3-9-11 Midori-cho
   Musashino-shi, Tokyo 180-8585, Japan
   Phone: +81 422 59 3758
   Fax: +81 422 59 6387
   E-mail: matsuura.nobuaki@lab.ntt.co.jp


Vigoureux et al.              April 2003                            26

draft-vigoureux-shiomoto-ccamp-gmpls-mrn-00.txt              Oct. 2002


Full Copyright Statement


   "Copyright (C) The Internet Society (date). All Rights Reserved.
   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph
   are included on all such copies and derivative works. However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."




























Vigoureux et al.              April 2003                            27


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/