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

Versions: 00 01 02 03 04

CCAMP Working Group                               M. Vigoureux - Editor
Internet Draft                                                (Alcatel)
                                                   K. Shiomoto - Editor
Expiration Date: August 2003                                      (NTT)

                                                          February 2003

        Generalized MPLS Architecture for Multi-Region Networks


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

   The list of current Internet-Drafts can be accessed at

   The list of Internet-Draft Shadow Directories can be accessed at


   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
   Layer-2 Switching Capable Interfaces and combined LSR û OXC devices.
   The former intend to give a first overview of the trade-offs in
   using GMPLS-base control for Ethernet MAC-based networks. The latter
   covers opaque, service transparent and fully transparent (i.e.
   photonic) data planes. The intent of this memo is to demonstrate
   that these aspects may not be as straightforward as they may appear
   in first approach.

Vigoureux, Shiomoto et al. - Expires August 2003                     1

draft-vigoureux-shiomoto-ccamp-gmpls-mrn-01.txt          February 2003

Table of Contents

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


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

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

   1.1. Summary.......................................................2

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

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

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

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

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

   4. Routing over Forwarding Adjacencies.............................5

   4.1. Scalability...................................................6

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

   4.3. Robustness....................................................7

   4.4. TE Metric.....................................................8

   5. Cross-region considerations.....................................8

   5.1. Interface adaptation capability descriptor....................9

   5.2. Enhanced interface switching capability descriptor...........11

   5.3. Extended Scope of Switching Capabilities.....................11

   5.3.1. L2SC Switching.............................................12

   5.3.2. Waveband switching.........................................13

   5.4. LSP integrity................................................13

   5.4.1. Crossing regions...........................................13

   5.4.2. Dedicated traffic parameters...............................14

   6. Conclusions....................................................15

   7. Security considerations........................................15

   8. References.....................................................16

   9. Acknowledgments................................................17

   10. Authors addresses.............................................17

   11. Contributors..................................................18

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.

Vigoureux, Shiomoto et al. - Expires August 2003                     2

draft-vigoureux-shiomoto-ccamp-gmpls-mrn-01.txt          February 2003

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",
   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], [RFC-3471], and [GMPLS-RTG] as well as
   [MPLS-HIER] and [MPLS-BDL].

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

   Multi-Region Networks Positioning

   Vertical integration refers (see [TE-WG]) to the definition of
   collaborative mechanisms within a single control plane instance
   driving  multiple (but at least two) data planes (i.e. switching
   layers). Horizontal integration is defined when each entity
   constituting the network environment includes at least one  common
   (data plane) switching capability and the control plane topology
   extends over several partitions being either areas or autonomous
   systems. In this case thus, the integration is defined between nodes
   hosting the same switching capability. For instance, the control
   plane interconnection between lambda switching capable areas
   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

Vigoureux, Shiomoto et al. - Expires August 2003                     3

draft-vigoureux-shiomoto-ccamp-gmpls-mrn-01.txt          February 2003

   worked out over the past two years) by considering common multi-area
   traffic engineering techniques and protocol extensions whereas  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 (as defined in [MPLS-HIER]) 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). More generically, the TE link notion is now
   recursively defined and accepted implying that the link bundle term
   will be used only when referring to a set of component links or
   ports. 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. Last, the bundling of FA is
   also defined in [MPLS-BDL] allowing for additional flexibility in
   controlling large scale backbone networks.

   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 Multi-Region Networks

   The rationales for investigating vertical integration (and thus
   multi-region networks) in the GMPLS distributed control plane
   context can be summarized as follows:

   - 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
   - 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.

Vigoureux, Shiomoto et al. - Expires August 2003                     4

draft-vigoureux-shiomoto-ccamp-gmpls-mrn-01.txt          February 2003

   - 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
   - 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

   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 with "lambda" (photonic) encoding. 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 host  for instance 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, this assumption  may, in some circumstances, raise
   some issues with respect to the adaptation capabilities between
   switching layers of such devices (see also Section 4.2.1.).

4. Routing over 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 control of the several data plane layers (or switching
   layers) using the same protocol instance.

   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

Vigoureux, Shiomoto et al. - Expires August 2003                     5

draft-vigoureux-shiomoto-ccamp-gmpls-mrn-01.txt          February 2003

   scalability within a routing plane instance (i.e. define virtual TE
   links without increase the number of routing adjacencies). 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) from or to the same control plane instance.

4.1.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)).

4.1.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 specific
   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, for instance.

Vigoureux, Shiomoto et al. - Expires August 2003                     6

draft-vigoureux-shiomoto-ccamp-gmpls-mrn-01.txt          February 2003

   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), avoiding full meshes 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

   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.1.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.

   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

Vigoureux, Shiomoto et al. - Expires August 2003                     7

draft-vigoureux-shiomoto-ccamp-gmpls-mrn-01.txt          February 2003

   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

4.1.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.

5. 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

Vigoureux, Shiomoto et al. - Expires August 2003                     8

draft-vigoureux-shiomoto-ccamp-gmpls-mrn-01.txt          February 2003

   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.

5.1. Interface adaptation capability descriptor

   In this section, an interface adaptation capability descriptor is
   considered. It 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].

   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

   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

Vigoureux, Shiomoto et al. - Expires August 2003                     9

draft-vigoureux-shiomoto-ccamp-gmpls-mrn-01.txt          February 2003

   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

   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

   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

Vigoureux, Shiomoto et al. - Expires August 2003                    10

draft-vigoureux-shiomoto-ccamp-gmpls-mrn-01.txt          February 2003

   switching capabilities are assembled to form the LSCs using
   miscellaneous switching capabilities.

5.2. Enhanced interface switching capability descriptor

   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 [MPLS-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 (see [MPLS-HIER] for a definition
   of the relationship between ISC values).

   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.

   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.

5.3. Extended Scope of Switching Capabilities

   When considering multi-region environments, main combinations can be
   classified as follows:
   - Packet(LSR)/Layer-2(Switch) with LSC (OXC)

Vigoureux, Shiomoto et al. - Expires August 2003                    11

draft-vigoureux-shiomoto-ccamp-gmpls-mrn-01.txt          February 2003

   - and Multi-Granularity OXC (including opaque and transparent
     switching capabilities at different granularity levels)

   The first implies some considerations with respect to Layer-2
   Switching Capable interfaces and L2SC environments. The latter
   implies further considerations on Waveband Switching aspects.

5.3.1. L2SC Switching

   Layer 2 Switching capable interfaces and Layer 2 LSPs were from the
   beginning under the scope of GMPLS (see [GMPLS-ARCH] and [RFC-
   3471]). Such interfaces are defined as capable to recognize
   frame/cell boundaries and can forward data based on the content of
   the frame/cell header. They include mainly interfaces on Ethernet
   bridges that forward data based on the content of the MAC header.

   In this context, the development of a GMPLS signalling profile for
   Ethernet networks, requires the definition of a label space. From
   there two questions arise: 1) what the label value space represents
   and is the corresponding label value space semanticfull or
   semanticless and 2) how is the label value space implemented (i.e.
   associated with data plane or non-associated and therefore exchanged
   over dedicated signalling channels or even a combination of both). A
   contiguous problem arises that the set of potential solutions must
   be backward compatible meaning that non-GMPLS controlled Ethernet
   interfaces should be capable to interwork with GMPLS controlled
   Ethernet interfaces.

   In addition to the label considerations, an additional problem
   raises from the type of environment in which these Ethernet
   interfaces are considered. These interfaces may be either so-called
   LAN PHY's (thus implying a broadcast capable environment) or WAN
   PHYÆs (thus implying point-to-point links). On the other side one
   has to consider MAC-based capable interfaces over Non-Broadcast
   Multiple Access (NBMA) technologies such as MPLS (Ethernet-over-
   MPLS) and over circuit-oriented technologies such as SDH and OTN
   (through different adaptation technologies such LAPS X.86 and GFP).
   This by taking into account that the MAC Address space is by
   definition non-hierarchical.

   The ideal situation would be to define a "one size fits all"
   solution. It is clear that inferring label value space from the
   barrier technology implies the development of so-called snooping
   approaches, while on the other side LAN PHY's would not scale such
   solution since implying the transformation of Broadcast Access (BA)
   environment into a NBMA one (using star, hub-and-spoke, or multi-
   tree approaches). Therefore a heuristic has to be proposed here in
   order to preclude such problems while avoiding to dredge past LAN
   Emulation (in particular, Broadcast Unknown Service - BUS) and other
   Next-Hop Resolution Protocol (NHRP) or Multi-Protocol Over ATM
   (MPOA) issues. The first question raising here is for which reasons
   broadcasts are mainly used in LAN environments and the response is
   clearly for address resolution (ARP) and bootstrapping (DHCP)

Vigoureux, Shiomoto et al. - Expires August 2003                    12

draft-vigoureux-shiomoto-ccamp-gmpls-mrn-01.txt          February 2003

   reasons. Thus a potential solution would be to let the network
   operate in a BA mode for such operations and bring it back to an
   NBMA mode for unicast/multicast operations. The same would apply for
   unknown unicasts frames.

   Therefore, if one can guarantee a dual mode for these environments
   the first backward compatible with the broadcast exchanges as
   defined by the IEEE (using IEEE 802.1d and related, thus using an
   associated control plane) and the second GMPLS compatible (thus
   using a non-associated IP-based distributed control plane) for the
   unicast operations a first step would be reached. The next issue
   relates to the realisation of resource reservation over Ethernet
   interfaces using GMPLS signaling techniques and its applicability.
   Considerations related to this are left for further study.

5.3.2. 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

   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 LSP Encoding Type, Switching Type and G-PID (when
   bands are carried over fibers).

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.

Vigoureux, Shiomoto et al. - Expires August 2003                    13

draft-vigoureux-shiomoto-ccamp-gmpls-mrn-01.txt          February 2003

   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.

   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 in MRN
   environments such as the ones defined for Sonet/SDH (see [SONET-SDH]
   and G.709 (see [GMPLS-G709]).

   With respect to spatial routing the LSP Encoding Type, Switching
   Type and G-PID (see [RFC-3471] for the corresponding definitions)
   provides the required information to pertinently setup such LSPs. It
   is nevertheless expected here to see some additional capability

Vigoureux, Shiomoto et al. - Expires August 2003                    14

draft-vigoureux-shiomoto-ccamp-gmpls-mrn-01.txt          February 2003

   allowing for transient states. In particular when the regeneration
   function is defined as a switching layer.

   With respect to  spectral routing  (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.

6. Conclusions

   In this memo, we address the issues when using the GMPLS protocol
   suite as unified control plane for MRN environments. Several
   proposal for enhancing the current GMPLS mechanisms without putting
   under questioning its foundations (see [GMPLS-ARCH]). Also this memo
   analyzes 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,

   This said, a detailed discussion concerning the suitability and
   optimality of the proposed approach may be considered by 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 responses can  be
   formulated 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 to a more detailed description of
   the collaborative processes within the GMPLS protocol suite.
   Therefore, even if the context into which these considerations have
   been introduced might be perceived as too largely scoped, one can
   still consider this topic as challenging enough in its attempt to
   re-use its current well accepted mechanisms.

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

Vigoureux, Shiomoto et al. - Expires August 2003                    15

draft-vigoureux-shiomoto-ccamp-gmpls-mrn-01.txt          February 2003

7. Security considerations

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

8. References

   [RFC-1793]  J. Moy, "Extending OSPF to Support Demand Circuits",
               IETF RFC 1793, April 1995.

   [RFC-2370]  R. Coltun, "The OSPF Opaque LSA Option", IETF RFC 2370,
               July 1998.

   [RFC-3471]  L. Berger (Editor) et al., "Generalized Multi-Protocol
               Label Switching (GMPLS) Signaling Functional
               Description", IETF RFC 3471, January 2003.

   [GMPLS-RTG] K. Kompella (Editor), Y. Rekhter (Editor) et al.
               "Routing Extensions in Support of Generalized MPLS",
               Internet Draft, Work in Progress, draft-ietf-ccamp-
               gmpls-routing-05.txt, August 2002.

   [GMPLS-G709]D. Papadimitriou (Editor) et al. "Generalized MPLS
               Signalling Extensions for G.709 Optical Transport
               Networks Control", Internet Draft, Work in Progress,
               draft-ietf-ccamp-gmpls-g709-03.txt, November 2002.

   [SONET-SDH] E. Mannie and D. Papadimitriou (Editors) et al.
               "Generalized Multi-Protocol Label Switching Extensions
               for SONET and SDH Control", Internet Draft, Work in
               Progress, draft-ietf-ccamp-gmpls-sonet-sdh-08.txt,
               February 2003.

   [SURVEY]    L. Berger (Editor), Y. Rekhter (Editor) et al.
               "Generalized MPLS Signaling - Implementation Survey",
               Internet Draft, Work in Progress, draft-ietf-ccamp-
               gmpls-signaling-survey-03.txt, October 2002.

   [LSP-HIER]  K. Kompella and Y. Rekhter, "LSP Hierarchy with
               Generalized MPLS TE", Internet Draft, Work in Progress,
               draft-ietf-mpls-lsp-hierarchy-08.txt, September 2002.

   [MPLS-BDL]  K. Kompelle, Y. Rekhter and Lou Berger, "Link Bundling
               in MPLS Traffic Engineering", Internet Draft, Work in
               Progress, draft-ietf-mpls-bundle-04.txt, July 2002.

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

Vigoureux, Shiomoto et al. - Expires August 2003                    16

draft-vigoureux-shiomoto-ccamp-gmpls-mrn-01.txt          February 2003

   [MAMLTE]    K. Shiomoto et al., "Multi-area multi-layer traffic
               engineering using hierarchical LSPs in GMPLS networks",
               Internet Draft, Work in Progress, draft-shiomoto-

   [MLRT]      W. Imajuku et al., "Multilayer routing using multilayer
               switch capable LSRs, Internet Draft, Work in Progress,

   [G.707]     ITU-T, "Network node interface for the Synchronous
               Digital Hierarchy", Recommendation G.707, October 2000.

   [G.709]     ITU-T, "Interfaces for the Optical Transport Network"
               Recommendation G.709, October 2001.

   [G.805]     ITU-T, "Generic functional architecture of transport
               networks", Recommendation G.805, March 2000.

9. 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].

10. Author's addresses

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

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

11. Contributors

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

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

Vigoureux, Shiomoto et al. - Expires August 2003                    17

draft-vigoureux-shiomoto-ccamp-gmpls-mrn-01.txt          February 2003

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

   Dimitri Papadimitriou (Alcatel)
   Francis Wellensplein 1,
   B-2018 Antwerpen, Belgium
   Phone : +32 3 240 8491
   E-mail: dimitri.papadimitriou@alcatel.be

Vigoureux, Shiomoto et al. - Expires August 2003                    18

draft-vigoureux-shiomoto-ccamp-gmpls-mrn-01.txt          February 2003

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

   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

Vigoureux, Shiomoto et al. - Expires August 2003                    19

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