--- 1/draft-ietf-ccamp-gmpls-mln-eval-05.txt 2008-07-14 23:12:21.000000000 +0200 +++ 2/draft-ietf-ccamp-gmpls-mln-eval-06.txt 2008-07-14 23:12:21.000000000 +0200 @@ -1,21 +1,20 @@ Network Working Group J.L. Le Roux (Ed.) Internet Draft France Telecom Category: Informational -Created: December 17, 2007 D. Papadimitriou (Ed.) -Expires: June 17, 2008 Alcatel-Lucent - - Evaluation of existing GMPLS Protocols against Multi Layer +Expires: January 2009 D. Papadimitriou (Ed.) + Alcatel-Lucent + Evaluation of Existing GMPLS Protocols Against Multi Layer and Multi Region Networks (MLN/MRN) - draft-ietf-ccamp-gmpls-mln-eval-05.txt + draft-ietf-ccamp-gmpls-mln-eval-06.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other @@ -44,42 +43,47 @@ 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. Table of Contents 1. Introduction................................................3 2. MLN/MRN Requirements Overview...............................4 - 3. Analysis....................................................4 - 3.1. Multi Layer Network Aspects.................................4 - 3.1.1. Support for Virtual Network Topology Reconfiguration........4 + 3. Analysis....................................................5 + 3.1. Multi Layer Network Aspects.................................5 + 3.1.1. Support for Virtual Network Topology Reconfiguration........5 3.1.1.1. Control of FA-LSPs Setup/Release..........................5 3.1.1.2. Virtual TE-Links..........................................6 3.1.1.3. Traffic Disruption Minimization During FA Release.........7 3.1.1.4. Stability.................................................8 3.1.2. Support for FA-LSP Attributes Inheritance...................8 3.1.3. FA-LSP Connectivity Verification............................8 - 3.2. Specific Aspects for Multi-Region Networks..................9 - 3.2.1. Support for Multi-Region Signaling..........................9 - 3.2.2. Advertisement of Adjustment Capacities......................9 - 4. Evaluation Conclusion......................................12 - 5. Security Considerations....................................13 - 6. IANA Considerations........................................13 - 7. Acknowledgments............................................13 - 8. References.................................................13 - 8.1. Normative References.......................................13 - 8.2. Informative References.....................................14 - 9. Editors' Addresses:........................................14 - 10. Contributors' Addresses:...................................15 - 11. Intellectual Property Statement............................15 + 3.1.4. Scalability.................................................9 + 3.1.5. Operations and Management of the MLN/MRN...................10 + 3.1.5.1. MIB Modules..............................................10 + 3.1.5.2. OAM......................................................10 + 3.2. Specific Aspects for Multi-Region Networks.................11 + 3.2.1. Support for Multi-Region Signaling.........................11 + 3.2.2. Advertisement of Adjustment Capacities.....................12 + 4. Evaluation Conclusion......................................15 + 4.1. Traceability of Requirements...............................15 + 5. Security Considerations....................................19 + 6. IANA Considerations........................................19 + 7. Acknowledgments............................................19 + 8. References.................................................19 + 8.1. Normative References.......................................19 + 8.2. Informative References.....................................20 + 9. Editors' Addresses.........................................21 + 10. Contributors' Addresses....................................22 + 11. Intellectual Property Statement............................22 1. Introduction Generalized MPLS (GMPLS) extends MPLS to handle multiple switching technologies: packet switching, layer-2 switching, TDM switching, wavelength switching, and fiber switching (see [RFC3945]). The Interface Switching Capability (ISC) concept is introduced for these switching technologies and is designated as follows: PSC (Packet Switch Capable), L2SC (Layer-2 Switch Capable), TDM (Time Division Multiplex capable), LSC (Lambda Switch Capable), and FSC @@ -88,21 +92,21 @@ [RFC4206]. A switching type describes the ability of a node to forward data of a particular data plane technology, and uniquely identifies a network region. A data plane switching layer describes a data plane switching granularity level. For example, LSC, TDM VC-11 and TDM VC-4-64c are three different layers. [MLN-REQ] defines a Multi Layer Network (MLN) to be a TE domain comprising multiple data plane switching layers either of the same ISC (e.g. TDM) or different ISC (e.g. TDM and PSC) and controlled by a single GMPLS control plane instance. - [MLN-REQ] further define a particular case of MLNs. A Multi Region + [MLN-REQ] further defines a particular case of MLNs. A Multi Region Network (MRN) is defined as a TE domain supporting at least two different switching types (e.g., PSC and TDM), either hosted on the same device or on different ones, and under the control of a single GMPLS control plane instance. The objectives of this document are to evaluate existing GMPLS mechanisms and protocols ([RFC3945], [RFC4202], [RFC3471], [RFC3473]) against the requirements for MLN and MRN, defined in [MLN-REQ]. From this evaluation, we identify several areas where additional protocol extensions and modifications are required to meet @@ -132,31 +136,38 @@ summarized below, and a mapping with sub-sections of [MLN-REQ] is provided. Here is the list of requirements that apply to MLN (and thus to MRN): - Support for robust Virtual Network Topology (VNT) reconfiguration. This implies the following requirements: - Optimal control of Forwarding Adjacency LSP (FA-LSP) setup and release (Section 5.8.1 of [MLN-REQ]); + - Support for virtual TE-links (Section 5.8.2 of [MLN-REQ]); + - Traffic Disruption minimization during FA-LSP release (Section 5.5 of [MLN-REQ]); + - Stability (Section 5.4 of [MLN-REQ]); - Support for FA-LSP attributes inheritance (Section 5.6 of [MLN-REQ]); - Support for FA-LSP data plane connectivity verification (Section 5.9 of [MLN-REQ]); + - MLN Scalability (section 5.3 of [MLN-REQ]); + + - MLN OAM (section 5.10 of [MLN-REQ]); + Here is the list of requirements that apply to MRN only: - Support for Multi-Region signaling (section 5.7 of [MLN-REQ]); - Advertisement of the adjustment capacity (section 5.2 of [MLN-REQ]); 3. Analysis 3.1. Multi Layer Network Aspects @@ -193,21 +204,21 @@ - Policing and scheduling of VNT resources with regard to traffic demands and usage (that is, decision to setup/release FA-LSPs). The functional component in charge of this function is called a VNT Manager (VNTM) [PCE-INTER]. - VNT Paths Computation according to TE topology, and potentially taking into account the old (existing) VNT to minimize changes. The Functional component in charge of VNT computation may be distributed on network elements or may be performed on an external - tool (such as a Path Computation Element (PCE), [RFC4655]). + element (such as a Path Computation Element (PCE), [RFC4655]). - FA-LSP setup/release. GMPLS routing protocols provide TE topology discovery. GMPLS signaling protocols allow setting up/releasing FA-LSPs. VNTM functions (resources policing/scheduling, decision to setup/release FA-LSPs, FA-LSP configuration) are out of the scope of GMPLS protocols. Such functionalities can be achieved directly on layer border LSRs, or through one or more external tools. When an @@ -215,45 +226,45 @@ the network elements so as to setup/release FA-LSPs. This could use standard management interfaces such as [RFC4802]. The set of traffic demands of the upper layer is required for the VNT Manager to take decisions to setup/release FA-LSPs. Such traffic demands include satisfied demands, for which one or more upper layer LSP have been successfully setup, as well as unsatisfied demands and future demands, for which no upper layer LSP has been setup yet. The collection of such information is beyond the scope of GMPLS protocols. Note that it may be partially inferred from - parameters carried in GMPLS signalling or advertised in GMPLS + parameters carried in GMPLS signaling or advertised in GMPLS routing. Finally, the computation of FA-LSPs that form the VNT can be - performed directly on layer border LSRs or on an external tool (such - as a Path Computation Element (PCE), [RFC4655]), and this is + performed directly on layer border LSRs or on an external element + (such as a Path Computation Element (PCE), [RFC4655]), and this is independent of the location of the VNTM. Hence, to summarize, no GMPLS protocol extensions are required to control FA-LSP setup/release. 3.1.1.2. Virtual TE-Links A Virtual TE-link is a TE-link between two upper layer nodes that is not actually associated with a fully provisioned FA-LSP in a lower layer. A Virtual TE-link represents the potentiality to setup an FA- LSP in the lower layer to support the TE-link that has been advertised. A Virtual TE-link is advertised as any TE-link, following the rules in [RFC4206] defined for fully provisioned TE-links. In particular, the flooding scope of a Virtual TE-link is within an IGP area, as is the case for any TE-link. - If an upper-layer LSP attempts (through a signalling message) to make + If an upper-layer LSP attempts (through a signaling message) to make use of a Virtual TE-link, the underlying FA-LSP is immediately - signalled and provisioned (provided there are available resources in + signaled and provisioned (provided there are available resources in the lower layer) in the process known as triggered signaling. The use of Virtual TE-links has two main advantages: - Flexibility: allows the computation of an LSP path using TE-links without needing to take into account the actual provisioning status of the corresponding FA-LSP in the lower layer; - Stability: allows stability of TE-links in the upper layer, while avoiding wastage of bandwidth in the lower layer, as data plane @@ -271,22 +282,22 @@ - A signaling mechanism for the dynamic setup and deletion of virtual TE-links. Setting up a virtual TE-link requires a signaling mechanism allowing an end-to-end association between Virtual TE-link end points so as to exchange link identifiers as well as some TE parameters. The TE mechanism responsible for triggering/policing dynamic modification of Virtual TE-links is out of the scope of GMPLS protocols. - Current GMPLS signalling does not allow setting up and releasing - Virtual TE-links. Hence GMPLS signalling must be extended to support + Current GMPLS signaling does not allow setting up and releasing + Virtual TE-links. Hence GMPLS signaling must be extended to support Virtual TE-links. We can distinguish two options for setting up Virtual TE-links: - The Soft FA approach that consists of setting up the FA-LSP in the control plane without actually activating cross connections in the data plane. On the one hand, this requires state maintenance on all transit LSRs (N square issue), but on the other hand this may allow for some admission control. Indeed, when a soft-FA is activated, the resources may be no longer available for use by other soft-FAs @@ -324,35 +335,36 @@ 3.1.1.4. Stability The stability of upper-layer LSP may be impaired if the VNT undergoes frequent changes. In this context robustness of the VNT is defined as the capability to smooth the impact of these changes and avoid their subsequent propagation. Guaranteeing VNT stability is out of the scope of GMPLS protocols and relies entirely on the capability of the TE and VNT management algorithms to minimize routing perturbations. This requires that the - algorithms takes into account the old VNT when computing a new VNT, + algorithms take into account the old VNT when computing a new VNT, and try to minimize the perturbation. Note that a full mesh of lower-layer LSPs may be created between every pair of border nodes between the upper and lower layers. The merit of a full mesh of lower-layer LSPs is that it provides stability to the upper layer routing. That is, forwarding table used in the upper layer is not impacted if the VNT undergoes changes. Further, there is always full reachability and immediate access to bandwidth to support LSPs in the upper layer. But it also has significant drawbacks, since it requires the maintenance of n^2 RSVP- - TE sessions, which may be quite CPU and memory consuming (scalability - impact). Also this may lead to significant bandwidth wastage. Note - that the use of virtual TE-links solves the bandwidth wastage issue, - and may reduce the control plane overload. + TE sessions, where n is the number of border nodes, which may be + quite CPU and memory consuming (scalability impact). Also this may + lead to significant bandwidth wastage. Note that the use of virtual + TE-links solves the bandwidth wastage issue, and may reduce the + control plane overload. 3.1.2. Support for FA-LSP Attributes Inheritance When a FA TE Link is advertised, its parameters are inherited from the parameters of the FA-LSP, and specific inheritance rules are applied. This relies on local procedures and policies and is out of the scope of GMPLS protocols. Note that this requires that both head-end and tail-end of the FA-LSP are driven by same policies. @@ -360,65 +372,202 @@ 3.1.3. FA-LSP Connectivity Verification Once fully provisioned, FA-LSP liveliness may be achieved by verifying its data plane connectivity. FA-LSP connectivity verification relies on technology specific mechanisms (e.g., for SDH using G.707 and G.783; for MPLS using BFD; etc.) as for any other LSP. Hence this requirement is out of the scope of GMPLS protocols. + The GMPLS protocols should provide mechanisms for the coordination + of data link verification in the upper layer network where data + links are lower layer LSPs. + o GMPLS signaling allows an LSP to be put into 'test' mode + [RFC3473]. + o The link Management Protocol [RFC4204] is a targeted protocol and + can be run end-to-end across lower-layer LSPs. + o Coordination of testing procedures in different layers is an + operational matter. + +3.1.4. Scalability + + As discussed in [MLN-REQ]), MRN/MLN routing mechanisms must be + designed to scale well with an increase of any of the following: + - Number of nodes + - Number of TE-links (including FA-LSPs) + - Number of LSPs + - Number of regions and layers + - Number of ISCDs per TE-link. + + GMPLS routing provides the necessary advertisement functions and is + based on IETF-designed IGPs. These are known to scale relatively well + with the number of nodes and links. Where there are multiple regions + or layers there are two possibilities. + 1. If a single routing instance distributes information about + multiple network layers, the effect is no more than to increase the + number of nodes and links in the network. + 2. If the MLN is fully integrated (i.e., constructed from hybrid + nodes), there is an increase in the number of nodes and links + as just mentioned, and also a potential increase in the amount + of ISCD information advertised per link. This is a relatively + small amount of information (e.g., 36 bytes in OSPF [RFC4203]) + per switching type, and each interface is unlikely to have more + than two or three switching types. + + The number of LSPs in a lower layer, advertised as TE-links may + impact the scaling of the routing protocol. A full mesh of FA-LSPs in + the lower layer would lead to n^2 TE-links where n is the number of + layer border LSRs. This must be taken into consideration in the VNT + management process. This is an operational matter beyond the scope of + GMPLS protocols. + + As regards the scalability of GMPLS signaling, a full mesh of LSPs in + the lower layer may impact the salability since it requires the + maintenance of n^2 RSVP-TE sessions, which may be quite CPU and + memory consuming. The use of virtual TE-links may reduce the control + plane overload (see section 3.1.1.2). + +3.1.5. Operations and Management of the MLN/MRN + + [MLN-REQ] identifies various requirements for effective management + and operation of the MLN. Some features already exist within the + GMPLS protocol set, some more are under development, and some + requirements are not currently addressed and will need new + development work in order to support them. + +3.1.5.1. MIB Modules + + MIB modules have been developed to model and control GMPLS switches + [RFC4803] and to control and report on the operation of the signaling + protocol [RFC4802]. These may be successfully used to manage the + operation of a single instance of the control plane protocols that + operate across multiple layers. + + [RFC4220] provides a MIB module for managing TE links, and this may + be particularly useful in the context of the MLN as LSPs in the lower + layers are made available as TE links in the higher layer. + + The traffic engineering database provides a repository for all + information about the existence and current status of TE links within + a network. This information is typically flooded by the routing + protocol operating within the network, and is used when LSP routes + are computed. [TED-MIB] provides a way to inspect the TED to view the + TE links at the different layers of the MLN. + + As observed in [MLN-REQ], although it would be possible to manage the + MLN using only the existing MIB modules, a further MIB module could + be produced to coordinate the management of separate network layers + in order to construct a single MLN entity. Such a MIB module would + effectively link together entries in the MIB modules already + referenced. + +3.1.5.2. OAM + + At the time of writing, the development of OAM tools for GMPLS + networks is at an early stage. GMPLS OAM requirements are addressed + in [GMPLS-OAM]. + + In general, the lower layer network technologies contain their own + technology-specific OAM processes (for example, SDH/SONET, Ethernet, + and MPLS). In these cases, it is not necessary to develop additional + OAM processes, but GMPLS procedures may be desirable to coordinate + the operation and configuration of these OAM processes. + [ETH-OAM] describes some early ideas for this function, but more work + is required to generalize the technique to be applicable to all + technologies and to MLN. In particular OAM function operating within + a server layer must be controllable from the client layer, and client + layer control plane mechanisms must map and enable OAM in the server + layer. + + Where a GMPLS-controlled technology does not contain its own OAM + procedures, this is usually because the technology cannot support + in-band OAM (for example, WDM networks). In these cases, there is + very little that a control plane can add to the OAM function since + the presence of a control plane cannot make any difference to the + physical characteristics of the data plane. However, the existing + GMPLS protocol suite does provide a set of tools that can help to + verify the data plane through control plane. These tools are equally + applicable to network technologies that do contain their own OAM. + + - Route recording is available through the GMPLS signaling protocol + [RFC3473] making it possible to check the route reported by the + control plane against the expected route. This mechanism also + includes the ability to record and report the interfaces and labels + used for the LSP at each hop of its path. + + - The status of TE links is flooded by the GMPLS routing protocols + [RFC4203] and [RFC4205] making it possible to detect changes in the + available resources in the network as an LSP is set up. + + - The GMPLS signaling protocol [RFC3473] provides a technique to + place an LSP into a "test" mode so that end-to-end characteristics + (such as power levels) may be sampled and modified. + + - The Link Management Protocol [RFC4204] provides a mechanism for + fault isolation on an LSP. + + - GMPLS signaling [RFC3473] provides a Notify message that can be + used to report faults and issues across the network. The message + includes scaling features to allow one message to report the + failure of multiple LSPs. + + - Extensions to GMPLS signaling [RFC4783] enable alarm information to + be collected and distributed along the path of an LSP for more easy + coordination and correlation. + 3.2. Specific Aspects for Multi-Region Networks 3.2.1. Support for Multi-Region Signaling There are actually several cases where a transit node could choose between multiple SCs to be used for a lower region FA-LSP: - - ERO expansion with loose hops: The transit node has to expand the - path, and may have to select among a set of lower region SCs. + - Explicit Route Object (ERO) expansion with loose hops: The transit + node has to expand the path, and may have to select among a set of + lower region SCs. - Multi-SC TE link: When the ERO of a FA LSP, included in the ERO of an upper region LSP, comprises a multi-SC TE-link, the region border node has to select among these SCs. - Existing GMPLS signalling procedures do not allow solving this + Existing GMPLS signaling procedures do not allow solving this ambiguous choice of SC that may be used along a given path. - Hence an extension to GMPLS signalling has to be defined to indicate + Hence an extension to GMPLS signaling has to be defined to indicate the SC(s) that can be used and the SC(s) that cannot be used along the path. 3.2.2. Advertisement of Adjustment Capacities In the MRN context, nodes supporting more than one switching capability on at least one interface are called Hybrid nodes ([MLN- REQ]). Conceptually, hybrid nodes can be viewed as containing at least two distinct switching elements interconnected by internal links which provide adjustment between the supported switching capabilities. These internal links have finite capacities and must be taken into account when computing the path of a multi-region TE-LSP. The advertisement of the adjustment capacities is required as it provides critical information when performing multi-region path computation. The term adjustment capacity refers to the property of a hybrid node - to interconnect different switching capabilities it provides though + to interconnect different switching capabilities it provides through its external interfaces [MLN-REQ]. This information allows path computation to select an end-to-end multi-region path that includes links of different switching capabilities that are joined by LSRs that can adapt the signal between the links. Figure 1a below shows an example of hybrid node. The hybrid node has two switching elements (matrices), which support here TDM and PSC switching respectively. The node has two PSC and TDM ports (port1 and - port2 respectively). It also has internal link connecting the two + port2 respectively). It also has an internal link connecting the two switching elements. The two switching elements are internally interconnected in such a way that it is possible to terminate some of the resources of the TDM port 2 and provide through them adjustment for PSC traffic, received/sent over the internal PSC interface (#b). Two ways are possible to set up PSC LSPs (port 1 or port 2). Available resources advertisement e.g. Unreserved and Min/Max LSP Bandwidth should cover both ways. @@ -533,35 +681,208 @@ Most of the required MLN/MRN functions will rely on mechanisms and procedures that are out of the scope of the GMPLS protocols, and thus do not require any GMPLS protocol extensions. They will rely on local procedures and policies, and on specific TE mechanisms and algorithms. As regards Virtual Network Topology (VNT) computation and reconfiguration, specific TE mechanisms need to be defined, but these mechanisms are out of the scope of GMPLS protocols. - Four areas for extensions of GMPLS protocols and procedures have been + Six areas for extensions of GMPLS protocols and procedures have been identified: - GMPLS signaling extension for the setup/deletion of the virtual TE-links; - - GMPLS routing and signaling extension for graceful TE-link - deletion; + - GMPLS signaling extension for graceful TE-link deletion; - - GMPLS signaling extension for constrained multi-region signalling + - GMPLS signaling extension for constrained multi-region signaling (SC inclusion/exclusion); - GMPLS routing extension for the advertisement of the adjustment capacities of hybrid nodes. + - A MIB module for coordination of other MIB modules being operated + in separate layers. + + - GMPLS signaling extensions for the control and configuration of + technology-specific OAM processes. + +4.1. Traceability of Requirements + + This section provides a brief cross-reference to the requirements set + out in [MLN-REQ] so that it is possible to verify that all of the + requirements listed in that document have been examined in this + document. + + - Path computation mechanism should be able to compute paths and + handle topologies consisting of any combination of (simplex) nodes + ([MLN-REQ], Section 5.1). + o Path computation mechanisms are beyond the scope of protocol + specifications, and out of scope for this document. + + - A hybrid node should maintain resources on its internal links + ([MLN-REQ], Section 5.2). + o This is an implementation requirement and is beyond the scope of + protocol specifications, and out of scope for this document. + + - Path computation mechanisms should be prepared to use the + availability of termination/adjustment resources as a constraint in + path computation ([MLN-REQ], Section 5.2). + o Path computation mechanisms are beyond the scope of protocol + specifications, and out of scope for this document. + + - The advertisement of a node's ability to terminate lower-region + LSPs and to forward traffic in the upper-region (adjustment + capability) is required ([MLN-REQ], Section 5.2). + o See Section 3.2.2 of this document. + + - The path computation mechanism should support the coexistence of + upper-layer links directly connected to upper-layer switching + elements, and upper-layer links connected through internal links + between upper-layer and lower-layer switching elements ([MLN-REQ], + Section 5.2). + o Path computation mechanisms are beyond the scope of protocol + specifications, and out of scope for this document. + + - MRN/MLN routing mechanisms must be designed to scale well with an + increase of any of the following: + - Number of nodes + - Number of TE-links (including FA-LSPs) + - Number of LSPs + - Number of regions and layers + - Number of ISCDs per TE-link. + ([MLN-REQ], Section 5.3). + o See Section 3.1.4 of this document. + + - Design of the routing protocols must not prevent TE information + filtering based on ISCDs, ([MLN-REQ], Section 5.3). + o All advertised information carries the ISCD and so a receiving + node may filter as required. + + - The path computation mechanism and the signaling protocol should be + able to operate on partial TE information, ([MLN-REQ], Section + 5.3). + o Path computation mechanisms are beyond the scope of protocol + specifications, and out of scope for this document. + + - Protocol mechanisms must be provided to enable creation, deletion, + and modification of LSPs triggered through operational actions, + ([MLN-REQ], Section 5.4). + o Such mechanisms are standard in GMPLS signaling [RFC3473]. + + - Protocol mechanisms should be provided to enable similar functions + triggered by adjacent layers, ([MLN-REQ], Section 5.4). + + o Such mechanisms are standard in GMPLS signaling [RFC3473]. + + - Protocol mechanisms may be provided to enable adaptation to changes + such as traffic demand, topology, and network failures. Routing + robustness should be traded with adaptability of those changes, + ([MLN-REQ], Section 5.4). + o See section 3.1.1 of this document. + + - Reconfiguration of the VNT must be as non-disruptive as possible + and must be under the control of policy configured by the operator, + ([MLN-REQ], Section 5.5). + o See Section 3.1.1.3 of this document + + - Parameters of a TE link in an upper should be inherited from the + parameters of the lower-layer LSP that provides the TE-link, based + on polices configured by the operator, ([MLN-REQ], Section 5.6). + o See Section 3.1.2 of this document. + + - The upper-layer signaling request may contain an ERO that includes + only hops in the upper layer, ([MLN-REQ], Section 5.7). + o Standard for GMPLS signaling [RFC3473]. See also Section 3.2.1. + + - The upper-layer signaling request may contain an ERO specifying the + lower layer FA-LSP route, ([MLN-REQ], Section 5.7). + o Standard for GMPLS signaling [RFC3473]. See also Section 3.2.1. + + - As part of the re-optimization of the MLN, it must be possible to + reroute a lower-layer FA-LSP while keeping interface identifiers of + the corresponding TE links unchanged and causing only minimal + disruption to higher-layer traffic, ([MLN-REQ], Section 5.8.1). + o See Section 3.1.1.3. + + - The solution must include measures to protect against network + destabilization caused by the rapid setup and teardown of lower- + layer LSPs as traffic demand varies near a threshold, ([MLN-REQ], + Sections 5.8.1 and 5.8.2). + o See Section 3.1.1.4. + + - Signaling of lower-layer LSPs should include a mechanism to rapidly + advertise the LSP as a TE link in the upper layer, and to + coordinate into which routing instances the TE link should be + advertised, ([MLN-REQ], Section 5.8.1). + o This is provided by [RFC4206] and enhanced by [HIER-BIS]. See + also Section 3.1.1.2. + + - If an upper-layer LSP is set up making use of a virtual TE-Link, + the underlying LSP must immediately be signaled in the lower layer, + ([MLN-REQ], Section 5.8.2). + o See Section 3.1.1.2. + + - The solution should provide operations to facilitate the build-up + of virtual TE-links, taking into account the forecast upper-layer + traffic demand and available resource in the lower-layer, + ([MLN-REQ], Section 5.8.2). + o See Section 3.1.1.2 of this document. + + - The GMPLS protocols should provide mechanisms for the coordination + of data link verification in the upper layer network where data + links are lower layer LSPs, ([MLN-REQ], Section 5.9). + o See Section 3.1.3 of this document. + + - Multi-layer protocol solutions should be manageable through MIB + modules, ([MLN-REQ], Section 5.10). + o See section 3.1.5.1. + + - Choices about how to coordinate errors and alarms, and how to + operate OAM across administrative and layer boundaries must be left + open for the operator, ([MLN-REQ], Section 5.10). + o This is an implementation matter, subject to operational + policies. + + - It must be possible to enable end-to-end OAM on an upper-layer LSP. + This function appears to the ingress LSP as normal LSP-based OAM + [GMPLS-OAM], but at layer boundaries, depending on the technique + used to span the lower layers, client-layer OAM operations may need + to be mapped to server-layer OAM operations ([MLN-REQ], Section + 5.10). + o See Section 3.1.5.2. + + - Client layer control plane mechanisms must map and enable OAM in + the server layer, ([MLN-REQ], Section 5.10). + o See Section 3.1.5.2. + + - OAM operation enabled for an LSP in a client layer must operate for + that LSP along its entire length, ([MLN-REQ], Section 5.10). + o See Section 3.1.5.2. + + - OAM function operating within a server layer must be controllable + from the client layer. Such control should be subject to policy at + the layer boundary, ([MLN-REQ], Section 5.10). + o This is an implementation matter. + + - The status of a server layer LSP must be available to the client + layer. This information should be configurable to be automatically + notified to the client layer at the layer boundary, and should be + subject to policy, ([MLN-REQ], Section 5.10). + o This is an implementation matter. + + - Implementations may use standardized techniques (such as MIB + modules) to convey status information between layers. + o This is an implementation matter. + 5. Security Considerations [MLN-REQ] sets out the security requirements for operating a MLN or MRN. These requirements are, in general, no different from the security requirements for operating any GMPLS network. As such, the GMPLS protocols already provide adequate security features. An evaluation of the security features for GMPLS networks may be found in [MPLS-SEC], and where issues or further work is identified by that document, new security features or procedures for the GMPLS protocols will need to be developed. @@ -576,95 +897,141 @@ Lastly, as noted in [MLN-REQ], it is expected that solution documents will include a full analysis of the security issues that any protocol extensions introduce. 6. IANA Considerations This informational document makes no requests for IANA action. 7. Acknowledgments - We would like to thank Julien Meuric, Igor Bryskin and Adrian Farrel + We would like to thank Julien Meuric, Igor Bryskin, and Adrian Farrel for their useful comments. Thanks also to Question 14 of Study Group 15 of the ITU-T for their thoughtful review. 8. References 8.1. Normative References [RFC3471] Berger, L., et. al. "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, January 2003. [RFC3945] Mannie, E., et. al. "Generalized Multi-Protocol Label Switching Architecture", RFC 3945, October 2004 [RFC4202] Kompella, K., Ed. and Y. Rekhter, Ed., "Routing Extensions in Support of Generalized Multi-Protocol Label Switching", RFC4202, October 2005. + [MLN-REQ] Shiomoto, K., Papadimitriou, D., Le Roux, J.L., + Vigoureux, M., Brungard, D., "Requirements for GMPLS- + based multi-region and multi-layer networks", draft- + ietf-ccamp-gmpls-mln-reqs, work in progess. + 8.2. Informative References - [RFC3473] Berger, L., et al. "GMPLS Singlaling RSVP-TE + [RFC3473] Berger, L., et al. "GMPLS Signaling RSVP-TE extensions", RFC3473, January 2003. + [RFC4203] K. Kompella, and Y. Rekhter, "OSPF Extensions in + Support of Generalized Multi-Protocol Label + Switching", RFC4203, Oct. 2005. + + [RFC4204] Lang, J., Ed., "The Link Management Protocol (LMP)", RFC + 4204, September 2005. + + [RFC4205] K. Kompella, and Y. Rekhter, "Intermediate System to + Intermediate System (IS-IS) Extensions in Support of + Multi-Protocol Label Switching (GMPLS)", RFC 4205, + October 2005. + [RFC4206] K. Kompella and Y. Rekhter, "LSP hierarchy with generalized MPLS TE", RFC4206, October 2005. + [RFC4220] Dubuc, M., Nadeau, T., and Lang, J., "Traffic + Engineering Link Management Information Base", RFC 4220, + November 2005. + [RFC4655] Farrel, A., Vasseur, J.-P., Ash,J., "A PCE based Architecture", RFC4655, August 2006. - [RFC4802] Nadeau, T., Farrel, A., "GMPLS TE MIB", RFC4802, + [RFC4802] Nadeau, T., Ed. and A. Farrel, Ed., "Generalized + Multiprotocol Label Switching (GMPLS) Traffic + Engineering Management Information Base", RFC 4802, February 2007. + [RFC4803] Nadeau, T., Ed. and A. Farrel, Ed., "Generalized + Multiprotocol Label Switching (GMPLS) Label Switching + Router (LSR) Management Information Base", RFC 4803, + February 2007. + + [RFC4783] L. Berger, Ed., "GMPLS - Communication of Alarm + Information", RFC 4783, December 2006. + [RFC4872] Lang, Rekhter, Papadimitriou, "RSVP-TE Extensions in support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS)-based Recovery", RFC4872, May 2007. [RFC4974] Papadimitriou, D., Farrel, A., et. al., "Generalized MPLS (GMPLS) RSVP-TE Signaling Extensions in support of Calls", RFC 4974, August 2007. + [ETH-OAM] Takacs, A., Gero, B., "GMPLS RSVP-TE Extensions to + Control Ethernet OAM", draft-takacs-ccamp-rsvp-te-eth- + oam-ext, work in progress. + + [GMPLS-OAM] Nadeau, T., Otani, T. Brungard, D., and Farrel, A., + "OAM Requirements for Generalized Multi-Protocol Label Switching + (GMPLS) Networks", draft-ietf-ccamp-gmpls-oam-requirements, work in + progress. + [GR-SHUT] Ali, Z., Zamfir, A., "Graceful Shutdown in MPLS Traffic Engineering Network", draft-ietf-ccamp-mpls-graceful- shutdown, work in progress. - [MLN-REQ] Shiomoto, K., Papadimitriou, D., Le Roux, J.L., - Vigoureux, M., Brungard, D., "Requirements for GMPLS- - based multi-region and multi-layer networks", draft- - ietf-ccamp-gmpls-mln-reqs, work in progess. + [HIER-BIS] Shiomoto, K., Rabbat, R., Ayyangar, A., Farrel, A., and + Ali, Z., "Procedures for Dynamically Signaled + Hierarchical Label Switched Paths", draft-ietf-ccamp- + lsp-hierarchy-bis, work in progress. [MPLS-SEC] Fang, et al. "Security Framework for MPLS and GMPLS Networks draft-fang-mpls-gmpls-security-framework, work in progress. [PCE-INTER] Oki, E., Le Roux , J-L., and Farrel, A., "Framework for PCE-Based Inter-Layer MPLS and GMPLS Traffic Engineering", draft-ietf-pce-inter-layer-frwk, work in progress. -9. Editors' Addresses: + [TED-MIB] Miyazawa, M., Otani, T., Kunaki, K. and Nadeau, T., + "Traffic Engineering Database Management Information + Base in support of GMPLS", draft-ietf-ccamp-gmpls-ted- + mib, work in progress. + +9. Editors' Addresses Jean-Louis Le Roux France Telecom 2, avenue Pierre-Marzin 22307 Lannion Cedex, France Email: jeanlouis.leroux@orange-ftgroup.com + Dimitri Papadimitriou Alcatel-Lucent Francis Wellensplein 1, B-2018 Antwerpen, Belgium Email: dimitri.papadimitriou@alcatel-lucent.be -10. Contributors' Addresses: +10. Contributors' Addresses Deborah Brungard AT&T Rm. D1-3C22 - 200 S. Laurel Ave. Middletown, NJ, 07748 USA E-mail: dbrungard@att.com Eiji Oki NTT 3-9-11 Midori-Cho @@ -714,13 +1081,13 @@ on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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. Copyright Statement - Copyright (C) The IETF Trust (2007). This document is subject to the + Copyright (C) The IETF Trust (2008). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.