CCAMP Working Group D. Papadimitriou (Alcatel) Internet Draft M. Vigoureux (Alcatel) Expiration Date: August 2005 K. Shiomoto (NTT) D. Brungard (ATT) J.L. Le Roux (FT) February 2005 Generalized Multi-Protocol Label Switching (GMPLS) Protocol Extensions for Multi-Region Networks (MRN) draft-papadimitriou-ccamp-gmpls-mrn-extensions-01.txt Status of this Memo This document is an Internet-Draft and is subject to all provisions of section 3 of RFC 3667. 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 become aware will be disclosed, in accordance with RFC 3668. 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. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract Most of the initial efforts on Generalized Multi-Protocol Label Switching (GMPLS) have been related to environments hosting single switching capability devices as such, the complexity raised by the D.Papadimitriou et al. - Expires April 2005 [Page 1] draft-papadimitriou-ccamp-gmpls-mrn-extensions-01.txt Feb. 2005 control of such data planes is similar to the one expected in classical IP/MPLS networks. The present document analyses the various GMPLS signaling and routing aspects when considering network environments consisting of multiple switching capabilities as defined in RFC 3945. 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 [HIER] and [BUNDLE]. 1. Introduction Generalized Multi-Protocol Label Switching (GMPLS) facilitates the realization of seamless control integration of IP/MPLS networks with SONET/SDH (see ANSI T1.105]/ITU-T G.707]) or Optical Transport Networks (see ITU-T G.709). In particular, the applicability of GMPLS to both packet/frame and circuit switching technologies (i.e. unified control plane architecture) provides a unified control management approach for both provisioning resources and restoration techniques. One of the additional advantages driving the construction of a unified Generalized Multi-Protocol Label Switching (GMPLS) control plane is the desire to support multi LSP-region [HIER] routing and Traffic Engineering (TE) capability. This would enable effective network resource utilization of both the Packet/Layer2 LSP regions and the Time Division Multiplexing (TDM) or Lambda LSP regions in high capacity networks. Vertical integration refers to the collaborative mechanisms within a single control plane instance driving networks hosting multiple switching capabilities. Such multi-switching capable networks are referred to as Multi LSP-Region Networks or simply Multi-Region Networks (MRN). A MRN is thus a vertically integrated network that includes nodes hosting at least two different switching capabilities that are controlled by a single instance of the GMPLS control plane. The GMPLS protocol suite extensions proposed in this document follows the requirements detailed in [MRN-REQ]. These extensions are proposed in-line with the analysis of the GMPLS capabilities to accommodate multiple switching capable networks as evaluated in [MRN-EVAL]. D.Papadimitriou et al. - Expires April 2005 [Page 2] draft-papadimitriou-ccamp-gmpls-mrn-extensions-01.txt Feb. 2005 2. Motivations The rationales for investigating vertical integration (and thus multi-region networks) in the GMPLS distributed control plane context are detailed in [MRN-REQ]. This section determines the corresponding motivations in terms of the GMPLS protocol suite: - 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 signaling 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). - Multi-region traffic engineering is facilitated as TE-links from distinct regions are stored within the same TE Database The next sections provide the operational aspects in terms of routing and signaling for such environments as well as the extensions required to instrument GMPLS to control such environments. 3. Routing over Forwarding Adjacencies Forwarding Adjacencies (FAs) as described in [HIER] are a useful and powerful tool for improving the scalability of GMPLS capable networks. This concept enables the creation of a vertical (nested) LSP Hierarchy. 3.1 Overview A node may advertise an LSP as a TE link into the same OSPF/ISIS instance. Such a TE link is referred to as a "Forwarding Adjacency" (FA) link and the corresponding LSP to as a "Forwarding Adjacency LSP", or simply FA-LSP. Since the advertised entity appears as a TE link in OSPF/ISIS, both end-point nodes of the FA-LSP must belong to the same OSPF area/ISIS level (thus constitute an intra-area improvement of scalability). OSPF/ISIS floods the link-state information about FAs just as it floods the information about any D.Papadimitriou et al. - Expires April 2005 [Page 3] draft-papadimitriou-ccamp-gmpls-mrn-extensions-01.txt Feb. 2005 other TE Link. So, FA-LSPs may be advertised as TE links into the same instance of OSPF/ISIS. This allows other nodes to use FAs as any other TE Links for path computation purposes. As such, FA LSPs have characteristics of both TE links and LSPs. Following this approach, a TE Link provides a clear separation between the routing adjacencies and the data plane bearer links (or channels). Furthermore, as TE links have been extended to non- adjacent devices by introducing the FA concept. This, in turn, allows decreasing the number of control plane instances to control N LSP regions (as defined in [LSP-HIER]). Last, the bundling of FA is also defined in [BUNDLE] allowing for additional flexibility in controlling large scale backbone networks. FA-LSPs, if well tailored, provide additional scalability within a routing plane instance (i.e. define virtual TE links without increasing 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 as well as the number of signaling sessions. Therefore, FAs may significantly improve the scalability of GMPLS capable control planes, and allow the creation of a TE-LSP hierarchy. 3.2 Scalability of Multi- Region Networks (with Single Switching Capable Elements) FAs allow avoiding the well-known O(N^2) problem at the control plane level by using the mechanisms defined in [HIER] but requires a specific policing at the LSP region boundaries in order to avoid full meshes both at the data plane level and control plane level. As specified in [HIER], it is expected that FAs will not be used for establishing OSPF/ISIS peering relationship between the routers at the ends of the adjacency thus clearly avoiding N square problem at the control plane level. However, specific policies would be still required to avoid a full mesh of FAs. A full mesh of FAs would lead, at the control plane level, to a full mesh of signaling sessions while, at the data plane, it would lead to poor resource utilization. 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 D.Papadimitriou et al. - Expires April 2005 [Page 4] draft-papadimitriou-ccamp-gmpls-mrn-extensions-01.txt Feb. 2005 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 bandwidth 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 [RFC2370] and [RFC3630]). 3.3 Scalability of Multi-Region Networks (with Multi-Switching Capable Elements) The Shortest Path First (SPF) computation complexity is proportional to L Log(N) where L is the number of links (here, more precisely TE links) and N the number of address prefixes. 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 to O(L + N Log N) instead of O(L Log N) with binary heaps, and its improvement with O(L Log Log(N)) complexity, which in turn, allows for a number of TE links greater than 1E4 (versus ~1E3 with classical implementations). By 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)). However, 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 Virtual Network Topologies (VNT). 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 overall computational complexity to L Log(M+1) x Log (Log(M+1) x N) (note: with M = 1 it brings L Log(N)). 3.4 Emulating Virtual Topologies using FAs According to ISC ordering [HIER], the following terminology can be defined: FA-LSP(1) corresponds to FA link with PSC-1, FA-LSP(2) with PSC-2, FA-LSP(3) with PSC-3, FA-LSP(4) with PSC-4, FA-LSP(5) with L2SC, FA-LSP(6) with TDM, FA-LSP(7) with LSC and FA-LSP(8) with FSC. FA-LSP(i) is routed over the FA-LSP(i+j) with j >= 1. In other words D.Papadimitriou et al. - Expires April 2005 [Page 5] draft-papadimitriou-ccamp-gmpls-mrn-extensions-01.txt Feb. 2005 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-j). It is expected that boundary nodes of VNT(i) will behave consistently with respect to any internal (LSP/link recovery) or external (LSP/link provisioning) triggering event. Below figure shows how the VNT is reconfigured by creating and/or withdrawing FA-LSPs. P1, P2, and P3 are nodes in the PSC region while T1, T2, and T3 are nodes in the TDM region. -------------+ +--------------+ +---------- PSC | | TDM | | PSC | | | | ----- P1 ------------ T1 ----------- P2 --- | | | | | ------------+ | | | +---------- | T2 | +---------- | | | | PSC | | | | | T3 ----------- P3 --- | | | +--------------+ +---------- (a) Physical topology P1 ----- P2 P1 P2 | | | | | | | | | P3 ----- P3 (b) VNT 1 (c) VNT 2 By creating two FA-LSPs between P1 and P2, P2 and P3, the VNT 1 is created. When the traffic demand between P1 and P2 decreases and that between P1 and P3 increases, the FA-LSP between P1 and P2 is destroyed and that between P1 and P3 is created. The VNT 1 is reconfigured to the VNT 2. 3.5 FA Attributes Inheritance Several FA-LSPs(i) between nodes 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 node of the FA- LSP(i-1) region sees an incoming LSP request. It can be demonstrated that the TE metric (in addition to the Maximum LSP Bandwidth and D.Papadimitriou et al. - Expires April 2005 [Page 6] draft-papadimitriou-ccamp-gmpls-mrn-extensions-01.txt Feb. 2005 Unreserved Bandwidth see [GMPLS-RTG]) alone is not a sufficient metric to compute the best path between these regions. This suggests that the inheritance process over which the TE Metric of the FA is not as straightforward as proposed in [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. Other TE attributes that need a specific processing during inheritance are the Shared Risk Link Groups (SRLG), Resource Class/Color (i.e. Administrative Groups) and Protection. The next section will describe the specific TE attributes to be considered for devices hosting at least two switching capabilities, in particular the interface switching adaptation capabilities. 3.6 FA Abstraction for Recovery In multi switching environments the inheritance of protection and restoration related TE link attributes must also be considered. 1) Considering a 1:1 end-to-end LSP recovery scheme, two FA-LSPs may be set up to form a single FA. To enhance the availability of the FA, the primary and the secondary LSPs are set up. The primary LSP is used to carry the normal traffic (see [TERM] and [E2E-RECOVERY]). Once the failure occurs affecting the primary LSP, the normal traffic is carried over the secondary LSP. From the routing perspective, there is no topological change to carry the traffic. These two LSPs should, therefore, be advertised within the scope of a single FA TE link advertisement with link protection type of 1:1. This FA will be processed by an upper LSP region as a span protected link. 2) Considering now a single FA-LSP, span protected over each link (i.e. at the underlying LSP region). D.Papadimitriou et al. - Expires April 2005 [Page 7] draft-papadimitriou-ccamp-gmpls-mrn-extensions-01.txt Feb. 2005 The question that arises is how should this span protected FA-LSP be advertised in the IGP. A link protection type of 1:1 could also be used for this advertisement but then, an upper region would have no means to differentiate the two cases. However, these two recovery schemes (end-to-end and span) have major differences in terms of recovery delay and robustness [RECOVERY]. Therefore, abstraction and summarization must be performed when advertising FA-LSPs as TE links (to an upper region) but using the Link Protection Type flags and applying simple attribute inheritance might not be sufficient to distinguish different recovery schemes. 4. Interface adaptation capability descriptor (IACD) In an MRN environment, some LSR could contain, under the control of a single GMPLS instance, multiple switching capabilities such as PSC and TDM or PSC and Lambda Switching Capability (LSC). These nodes, hosting 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 node resources to terminate hierarchical label switched paths (LSPs), since circuit switch capable units such as TDMs, LSCs, and FSCs require rigid resources. For example, a node with PSC+LSC switching capability can switch a Lambda LSP but can never terminate the Lambda LSP if there is no unused adaptation capability between the LSC and the PSC switching capabilities. Therefore, within multi-region networks, the advertisement of the so- called adaptation capability to terminate LSPs (not the interface capability since the latter can be inferred from the bandwidth available for each switching capability) provides critical information to take into account when performing multi-region path computation. This concept enables a node to discriminate the remote nodes (and thus allows their selection during path computation) with respect to their adaptation capability e.g. to terminate LSPs at the PSC or LSC level. Hence, we introduce the idea of discriminating the (internal) adaptation capability from the (interface) switching capability by considering an interface adaptation capability descriptor. 4.1 Overview Some nodes may host, under the control of a single GMPLS instance, multiple Interface Switching Capabilities (ISC) such as PSC and Time-Division-Multiplexing (TDM) or PSC and Lambda Switching Capability (LSC) or Ethernet (L2SC) and TDM. D.Papadimitriou et al. - Expires April 2005 [Page 8] draft-papadimitriou-ccamp-gmpls-mrn-extensions-01.txt Feb. 2005 For example, a L2SC+TDM switching capable node can deliver connectivity for TDM LSPs but can never terminate the TDM LSP if there is no unused adaptation capability left between the L2SC and the TDM switching capabilities. Therefore, the advertisement of the so-called adaptation capability to terminate LSPs provides the critical information to take into account when performing multi- region path computation. This concept enables a local node to discriminate from remote nodes (and thus allows their selection during path computation) with respect to their adaptation capability e.g. to terminate TDM LSP at the L2SC level. Hence, the idea of discriminating the (internal) adaptation capability from the (interface) switching capability by considering an interface adaptation capability descriptor has been introduced. The interface adaptation capability descriptor (IACD) 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, by analogy to the existing Interface Switching Capability Descriptor (ISCD) sub-TLV, the local GMPLS control plane can swiftly determine which nodes can terminate a certain encoding type of LSP and successfully establish an LSP tunnel between endpoints terminating a particular SC. This allows integrated devices to avoid the duplication of the switching capacity at each SC by not requiring full capacity for interworking between the SC. The IACD is thus an enabler for GMPLS application in those integrated situations. 1) Number of Switching Capabilities: The problem with the use of the interface switching capability descriptor at the PSC+TDM+LSC node, is the shortage of LSP termination capability information. For instance, a PSC+TDM+LSC node provides only switching capability information by abstracting the internal node capabilities. Therefore, remote nodes cannot accurately determine which switching capability can be switched and/or terminated at the PSC+TDM+LSC node. For such a node supporting LSC, TDM and PSC switching capability, the determination of the resource made available to cross for instance the LSC to PSC region boundary (LSC -> PSC) may involve one of the following region cross- over: LSC -> PSC and LSC -> TDM -> PSC. Another example occurs when L2SC (Ethernet) switching can be adapted in LAPS X.86 and GFP for instance before reaching the TDM switching matrix. Similar circumstances can occur, if a switching fabric that supports both PSC and L2SC functionalities is assembled with LSC interfaces enabling "lambda" encoding. In the switching fabric, some interfaces can terminate Lambda LSPs and perform frame (or cell) D.Papadimitriou et al. - Expires April 2005 [Page 9] draft-papadimitriou-ccamp-gmpls-mrn-extensions-01.txt Feb. 2005 switching whilst other interfaces can terminate Lambda LSPs and perform packet switching. Thus, the interface switching capability descriptor provides the information for the forwarding/switching) capability only. In order for remote nodes to understand properly the termination capability of the other nodes, additional information to the existing interface switching capability descriptor is essential in achieving seamless multi-region routing. In turn, adequate processing of this additional information will allow the signaling of packet LSP set-up combined with an automated triggering of new Lambda LSPs between nodes that do not yet have a preferred Lambda LSP to carry the Packet LSP. 4.2 IACD Format The IACD sub-TLV format is as follows. In IS-IS, this is a sub-TLV of the Extended IS Reachability TLV (see [RFC 3784]) with type TBD. In OSPF, it is defined as a sub-TLV of the Link TLV (see [RFC 3630]), with type TBD. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Switching Cap | Encoding | Switching Cap | Encoding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max LSP Bandwidth at priority 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max LSP Bandwidth at priority 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max LSP Bandwidth at priority 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max LSP Bandwidth at priority 3 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max LSP Bandwidth at priority 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max LSP Bandwidth at priority 5 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max LSP Bandwidth at priority 6 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max LSP Bandwidth at priority 7 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Adaptation Capability-specific information | | (variable) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Where: - first Switching Capability (SC) field (byte 1): lower switching capability (as D.Papadimitriou et al. - Expires April 2005 [Page 10] draft-papadimitriou-ccamp-gmpls-mrn-extensions-01.txt Feb. 2005 defined for the existing ISC sub-TLV) - first Encoding field (byte 2): as defined for the existing ISC sub-TLV - second SC value (byte 3): upper switching capability (new) - second encoding value (byte 4): set to the encoding of the available adaptation pool and to 0xFF when the corresponding SC value has no access to the wire (i.e. there is no ISC sub-TLV for this upper switching capability) Multiple sub-TLVs may be present within a given TE Link TLV and the bandwidth simply provides an indication of resources still available to perform insertion/extraction for a given adaptation (pool concept). 5. Multi-Region Signaling Section 8.2 of [HIER] specifies that when an region boundary node receives a Path message, the node determines whether it is at the edge of an LSP region with respect to the ERO carried in the message. If the node is at the edge of a region, it must then determine the other edge of the region with respect to the ERO, using the IGP database. The node then extracts from the ERO the subsequence of hops from itself to the other end of the region. The node then compares the subsequence of hops with all existing FA- LSPs originated by the node: - if a match is found, that FA-LSP has enough unreserved bandwidth for the LSP being signaled, and the PID of the FA-LSP is compatible with the PID of the LSP being signaled, the node uses that FA-LSP as follows. The Path message for the original LSP is sent to the egress of the FA-LSP. The PHOP in the message is the address of the node at the head-end of the FA-LSP. Before sending the Path message, the ERO in that message is adjusted by removing the subsequence of the ERO that lies in the FA-LSP, and replacing it with just the end point of the FA-LSP. - if no existing FA-LSP is found, the node sets up a new FA-LSP. That is, it initiates a new LSP setup just for the FA-LSP. Applying this procedure, in a MRN environment MAY lead to setup one- hop FA-LSPs between each node. Therefore, considering that the path computation is able to take into account richness of information with regard to the SC available on given nodes belonging to the path, it is consistent to provide enough signaling information to indicate the SC to be used and on over which link. Particularly, in case a TE link has multiple SC advertised as part of its ISCD sub-TLVs, an ERO does not allow selecting a particular SC. Limiting modifications to existing the above RSVP-TE procedure is required for this purpose. It is expected to provide this strict D.Papadimitriou et al. - Expires April 2005 [Page 11] draft-papadimitriou-ccamp-gmpls-mrn-extensions-01.txt Feb. 2005 indication of SC through a new sub-object of the eXclude Route Object (XRO). Such information can be specified by explicitly indicating which SCs have to be excluded before initiating the procedure described here above. When a SC value has to be explicitly included (instead of excluding a specific list of SC values) for a link part of the route followed by the LSP, the same subobject with Type TBA, should be included as part of the EXPLICIT ROUTE object (ERO). This subobject must follow the numbered or unnumbered interface subobjects to which this subobject refers. It is expected, when label subobject are following numbered or unnumbered interface subobjects, that the label value is compliant with the SC capability to be explicitly included. This solves the ambiguous choice of SC that are potentially used along a given path and give the possibility to optimize resource usage on a multi-region basis. 5.1 SC Subobject Encoding The contents of an EXCLUDE_ROUTE object defined in [XRO] are a series of variable-length data items called subobjects. This document defines the SC subobject of the XRO (Type TBD), its encoding and processing. Subobject Type TBD: Switching Capability 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |L| Type | Length | Attribute | Switching Cap | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ L 0 indicates that the attribute specified MUST be excluded 1 indicates that the attribute specified SHOULD be avoided Attribute 0 reserved value 1 indicates that the specified SC should be excluded or avoided with respect to the preceding numbered (Type 1 or Type 2) or unnumbered interface (Type) subobject 6. Backward compatibility TBD D.Papadimitriou et al. - Expires April 2005 [Page 12] draft-papadimitriou-ccamp-gmpls-mrn-extensions-01.txt Feb. 2005 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 8.1 Normative References [BUNDLE] K.Kompella, et al., "Link Bundling in MPLS Traffic Engineering", Work in Progress, draft-ietf-mpls-bundle- 04.txt. [GMPLS-RTG] K.Kompella (Editor), Y. Rekhter (Editor) et al. "Routing Extensions in Support of Generalized MPLS", Work in Progress, draft-ietf-ccamp-gmpls-routing-09.txt. [HIER] K.Kompella and Y.Rekhter, "LSP Hierarchy with Generalized MPLS TE", Work in Progress, draft-ietf-mpls-lsp- hierarchy-08.txt. [RECOVERY] D.Papadimitriou et al. "Analysis of Generalized Multi- Protocol Label Switching (GMPLS)-based Recovery Mechanisms (including Protection and Restoration)," Work in Progress, draft-ietf-ccamp-gmpls-recovery-analysis- 04.txt. [INTER-AREA-AS] A.Ayyangar, et al., "Inter-area and Inter-AS MPLS Traffic Engineering", Work in Progress, draft-vasseur- ayyangar-ccamp-inter-area-AS-TE-00.txt [L2SC-LSP] D.Papadimitriou, et al., "Generalized MPLS Signaling for Layer-2 Label Switched Paths (LSP)", Work in Progress, draft-papadimitriou-ccamp-gmpls-l2sc-lsp-03.txt. [MRN-EVAL] J.-L. Leroux et al., "Evaluation of existing GMPLS Protocols against Multi Region Networks", Work in Progress, draft-leroux-ccamp-mrn-gmpls-analysis-01.txt. [MRN-REQ] K.Shiomoto et al., "Requirements for GMPLS-based Multi- Region Networks (MRN)", Work in Progress, draft- shiomoto-ccamp-gmpls-mrn-reqs-01.txt. [RFC2119] Bradner, S., 'Key words for use in RFCs to indicate requirements levels', RFC 2119, March 1997. [RFC2370] R.Coltun, "The OSPF Opaque LSA Option", RFC 2370, July 1998. D.Papadimitriou et al. - Expires April 2005 [Page 13] draft-papadimitriou-ccamp-gmpls-mrn-extensions-01.txt Feb. 2005 [RFC3471] L.Berger et al., "Generalized Multi-Protocol Label Switching (GMPLS) - Signaling Functional Description", RFC 3471, January 2003. [RFC3630] D.Katz et al., "Traffic Engineering (TE) Extensions to OSPF Version 2," RFC 3630, September 2003. [RFC3667] Bradner, S., 'IETF Rights in Contributions', BCP 78, RFC 3667, February 2004. [RFC3668] Bradner, S., Ed., 'Intellectual Property Rights in IETF Technology', BCP 79, RFC 3668, February 2004. [XRO] C.Y.Lee et al. "Exclude Routes - Extension to RSVP-TE," Work in progress, draft-ietf-ccamp-rsvp-te-exclude- route-02.txt, July 2004. 8.2 Informative References [MAMLTE] K.Shiomoto et al., "Multi-area multi-layer traffic engineering using hierarchical LSPs in GMPLS networks", Work in Progress, draft-shiomoto-multiarea-te-01.txt. [MLRT] W.Imajuku et al., "Multilayer routing using multilayer switch capable LSRs, Work in Progress, draft-imajuku-ml- routing-02.txt. Acknowledgments The authors would like to thank Mr. Wataru Imajuku for the discussions on adaptation between regions [MLRT]. Author's Addresses Dimitri Papadimitriou (Alcatel) Francis Wellensplein 1, B-2018 Antwerpen, Belgium Phone : +32 3 240 8491 E-mail: dimitri.papadimitriou@alcatel.be Martin Vigoureux (Alcatel) Route de Nozay, 91461 Marcoussis cedex, France Phone: +33 (0)1 69 63 18 52 E-mail: martin.vigoureux@alcatel.fr Kohei Shiomoto (NTT Network Service Systems Laboratories) 3-9-11 Midori-cho D.Papadimitriou et al. - Expires April 2005 [Page 14] draft-papadimitriou-ccamp-gmpls-mrn-extensions-01.txt Feb. 2005 Musashino-shi, Tokyo 180-8585, Japan Phone: +81 422 59 4402 E-mail: shiomoto.kohei@lab.ntt.co.jp Deborah Brungard (AT&T) Rm. D1-3C22 - 200 S. Laurel Ave. Middletown, NJ 07748, USA Phone: +1 732 420 1573 E-mail: dbrungard@att.com Jean-Louis Le Roux (FTRD/DAC/LAN) Avenue Pierre Marzin 22300 Lannion, France Phone: +33 (0)2 96 05 30 20 E-mail:jean-louis.leroux@rd.francetelecom.com Contributors Eiji Oki (NTT Network Service Systems Laboratories) 3-9-11 Midori-cho Musashino-shi, Tokyo 180-8585, Japan Phone : +81 422 59 3441 Email: oki.eiji@lab.ntt.co.jp Ichiro Inoue(NTT Network Service Systems Laboratories) 3-9-11 Midori-cho Musashino-shi, Tokyo 180-8585, Japan Phone : +81 422 59 6076 Email: ichiro.inoue@lab.ntt.co.jp Emmanuel Dotaro (Alcatel) Route de Nozay, 91461 Marcoussis cedex, France Phone : +33 1 6963 4723 Email: emmanuel.dotaro@alcatel.fr D.Papadimitriou et al. - Expires April 2005 [Page 15] draft-papadimitriou-ccamp-gmpls-mrn-extensions-01.txt Feb. 2005 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY 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 Internet Society (2004). 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. D.Papadimitriou et al. - Expires April 2005 [Page 16]