CCAMP Working Group M. Vigoureux - Editor Internet Draft (Alcatel) draft-vigoureux-shiomoto-ccamp-gmpls-mrn-01.txt K. Shiomoto - Editor Expiration Date: August 2003 (NTT) February 2003 Generalized MPLS Architecture for Multi-Region Networks draft-vigoureux-shiomoto-ccamp-gmpls-mrn-01.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 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 Abstract...........................................................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", "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], [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 networks. 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 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. 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 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 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 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.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 requests. 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 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 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 the PSC+TDM+LSC LSR. 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 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 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 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, OSPF, IS-IS, RSVP-TE and LMP). 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 suite. 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- 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. [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 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, Shiomoto et al. - Expires August 2003 19