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 EOXC 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 boundariesE 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 wouldnt 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 E1) 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 setE 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 schemeE 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 componentE 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 edfas, 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 ccampers as either not justified (we dont 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