idnits 2.17.1 draft-papadimitriou-ccamp-gmpls-mrn-extensions-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 20. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 755. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 766. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 773. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 779. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1, updated by RFC 4748 (on line 42), which is fine, but *also* found old RFC 3978, Section 5.4, paragraph 1 text on line 743. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 2007) is 6130 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC3945' is mentioned on line 61, but not defined == Missing Reference: 'RFC 3945' is mentioned on line 66, but not defined == Missing Reference: 'MLN-REQ' is mentioned on line 96, but not defined == Missing Reference: 'MLN-EVAL' is mentioned on line 185, but not defined == Missing Reference: 'GR-TELINK' is mentioned on line 128, but not defined == Missing Reference: 'RFC 3630' is mentioned on line 194, but not defined == Missing Reference: 'RFC 3784' is mentioned on line 241, but not defined ** Obsolete undefined reference: RFC 3784 (Obsoleted by RFC 5305) == Missing Reference: 'RFC3473' is mentioned on line 537, but not defined == Missing Reference: 'GMPLS-CALL' is mentioned on line 505, but not defined == Missing Reference: 'RFC4139' is mentioned on line 395, but not defined == Missing Reference: 'RFC2205' is mentioned on line 404, but not defined == Missing Reference: 'RFC3477' is mentioned on line 507, but not defined == Missing Reference: 'RFC 4206' is mentioned on line 518, but not defined == Unused Reference: 'L2SC-LSP' is defined on line 601, but no explicit reference was found in the text == Unused Reference: 'MRN-REQ' is defined on line 610, but no explicit reference was found in the text == Unused Reference: 'RFC2119' is defined on line 614, but no explicit reference was found in the text == Unused Reference: 'RFC2370' is defined on line 617, but no explicit reference was found in the text == Unused Reference: 'RFC3630' is defined on line 624, but no explicit reference was found in the text == Unused Reference: 'RFC3667' is defined on line 627, but no explicit reference was found in the text == Unused Reference: 'RFC3668' is defined on line 630, but no explicit reference was found in the text == Unused Reference: 'RFC4428' is defined on line 652, but no explicit reference was found in the text == Unused Reference: 'MAMLTE' is defined on line 663, but no explicit reference was found in the text -- Possible downref: Normative reference to a draft: ref. 'L2SC-LSP' == Outdated reference: A later version (-06) exists of draft-ietf-ccamp-gmpls-mln-eval-03 ** Downref: Normative reference to an Informational draft: draft-ietf-ccamp-gmpls-mln-eval (ref. 'MRN-EVAL') -- No information found for draft-ietf-ccamp-gmpls-mrn-reqs - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'MRN-REQ' ** Obsolete normative reference: RFC 2370 (Obsoleted by RFC 5250) ** Obsolete normative reference: RFC 3667 (Obsoleted by RFC 3978) ** Obsolete normative reference: RFC 3668 (Obsoleted by RFC 3979) ** Obsolete normative reference: RFC 4420 (Obsoleted by RFC 5420) ** Downref: Normative reference to an Informational RFC: RFC 4428 == Outdated reference: A later version (-06) exists of draft-ietf-ccamp-rsvp-te-exclude-route-05 -- No information found for draft-shiomoto-multiarea-te - is the name correct? Summary: 11 errors (**), 0 flaws (~~), 27 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Papadimitriou (Alcatel) 3 Internet Draft M. Vigoureux (Alcatel) 4 Expiration Date: December 2007 K. Shiomoto (NTT) 5 D. Brungard (ATT) 6 J.L. Le Roux (France Telecom) 8 July 2007 10 Generalized Multi-Protocol Label Switching (GMPLS) Protocol 11 Extensions for Multi-Layer and Multi-Region Networks (MLN/MRN) 13 draft-papadimitriou-ccamp-gmpls-mrn-extensions-04.txt 15 Status of this Memo 17 By submitting this Internet-Draft, each author represents that any 18 applicable patent or other IPR claims of which he or she is aware 19 have been or will be disclosed, and any of which he or she becomes 20 aware will be disclosed, in accordance with Section 6 of BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six 28 months and may be updated, replaced, or obsoleted by other documents 29 at any time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on December 31, 2007. 40 Copyright Notice 42 Copyright (C) The IETF Trust (2007). 44 Abstract 46 There are requirements for the support of networks ccomprising LSRs 47 with different data plane switching layers controlled by a single 48 Generalized Multi Protocol Label Switching (GMPLS) control plane 49 instance, referred to as GMPLS Multi-Layer Networks/Multi-Region 50 Networks (MLN/MRN). This document defines extensions to GMPLS routing 51 and signaling protocols so as to support the operation of GMPLS 52 Multi-Layer/Multi-Region Networks. 54 Conventions used in this document 56 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 57 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 58 document are to be interpreted as described in RFC-2119. 60 In addition the reader is assumed to be familiar with the concepts 61 developed in [RFC3945], [RFC3471], and [RFC4202] as well as 62 [RFC4206] and [RFC4201]. 64 1. Introduction 66 Generalized Multi-Protocol Label Switching (GMPLS) [RFC 3945] 67 extends MPLS to handle multiple switching technologies: packet 68 switching (PSC), layer-two switching (L2SC), TDM switching (TDM), 69 wavelength switching (LSC) and fiber switching (FSC). A GMPLS 70 switching type (PSC, TDM, etc.) describes the ability of a node to 71 forward data of a particular data plane technology, and uniquely 72 identifies a control plane region. LSP Regions are defined in 73 [RFC4206]. A network comprised of multiple switching types (e.g. PSC 74 and TDM) controlled by a single GMPLS control plane instance is 75 called a Multi-Region Network (MRN). 77 A data plane layer is a collection of network resources capable of 78 terminating and/or switching data traffic of a particular format. 79 For example, LSC, TDM VC-11 and TDM VC-4-64c represent three 80 different layers. A network comprising transport nodes with 81 different data plane switching layers controlled by a single GMPLS 82 control plane instance is called a Multi-Layer Network (MLN). 84 The applicability of GMPLS to multiple switching technologies 85 provides the unified control and operations for both LSP provisioning 86 and recovery. This document covers the elements of a single GMPLS 87 control plane instance controlling multiple layers within a given TE 88 domain. A CP instance can serve one, two or more layers. Other 89 possible approaches such as having multiple CP instances serving 90 disjoint sets of layers are outside the scope of this document. 92 The next sections provide the procedural aspects in terms of routing 93 and signaling for such environments as well as the extensions 94 required to instrument GMPLS to provide the capabilities for MLM/MRN 95 unified control. The rationales and requirements for Multi- 96 Layer/Region networks are set forth in [MLN-REQ]. These requirements 97 are evaluated against GMPLS protocols in [MLN-EVAL] and several 98 areas where GMPLS protocol extensions are required are identified. 99 This document defines GMPLS routing and signaling extensions so as 100 to cover GMPLS MLN/MRN requirements. 102 2. Summary of the Requirements and Evaluation 104 As identified in [MRN-EVAL] most of MLN/MRN requirements rely on 105 mechanisms and procedures that are outside the scope of the GMPLS 106 protocols, and thus do not require any GMPLS protocol extensions. 107 They rely on local procedures and policies, and on specific TE 108 mechanisms and algorithms, which are outside the scope of GMPLS 109 protocols. 111 Four areas for extensions of GMPLS protocols and procedures have been 112 identified: 114 - GMPLS routing extension for the advertisement of the 115 internal adaptation capability of hybrid nodes. 117 - GMPLS signaling extension for constrained multi-region 118 signaling (SC inclusion/exclusion). 120 - GMPLS signaling extension for the setup/deletion of 121 Virtual TE-links (as well as exact trigger for its actual 122 provisioning). 124 - GMPLS routing and signaling extension for graceful TE-link 125 deletion (covered in [GR-TELINK]). 127 The first three requirements are addressed in Sections 3, 4 and 5, 128 respectively, of this document. The fourth one is addressed in [GR- 129 TELINK]. 131 3. Interface adaptation capability descriptor (IACD) 133 In the MRN context, nodes supporting more than one switching 134 capability on at least one interface are called Hybrid nodes. Hybrid 135 nodes contain at least two distinct switching elements that are 136 interconnected by internal links to provide adaptation between the 137 supported switching capabilities. These internal links have finite 138 capacities and must be taken into account when computing the path of 139 a multi-region TE-LSP. 141 The advertisement of the internal adaptation capability is required 142 as it provides critical information when performing multi-region path 143 computation. 145 3.1 Overview 146 In an MRN environment, some LSRs could contain, under the control of 147 a single GMPLS instance, multiple switching capabilities such as PSC 148 and TDM or PSC and Lambda Switching Capability (LSC). 150 These nodes, hosting multiple Interface Switching Capabilities 151 (ISC), just like other nodes (hosting a single Interface Switching 152 Capability) are required to hold and advertise resource information 153 on link states and topology. They also may have to consider certain 154 portions of internal node resources to terminate hierarchical label 155 switched paths (LSPs), since circuit switch capable units such as 156 TDMs, LSCs, and FSCs require rigid resources. For example, a node 157 with PSC+LSC hierarchical switching capability can switch a Lambda 158 LSP but may not be able to can never terminate the Lambda LSP if 159 there is no unused adaptation capability between the LSC and the PSC 160 switching capabilities. 162 Another example occurs when L2SC (Ethernet) switching can be adapted 163 in LAPS X.86 and GFP for instance before reaching the TDM switching 164 matrix. Similar circumstances can occur, if a switching fabric that 165 supports both PSC and L2SC functionalities is assembled with LSC 166 interfaces enabling "lambda" encoding. In the switching fabric, some 167 interfaces can terminate Lambda LSPs and perform frame (or cell) 168 switching whilst other interfaces can terminate Lambda LSPs and 169 perform packet switching. 171 Therefore, within multi-region networks, the advertisement of the 172 so-called adaptation capability to terminate LSPs (not the interface 173 capability since the latter can be inferred from the bandwidth 174 available for each switching capability) provides critical 175 information to take into account when performing multi-region path 176 computation. This concept enables a node to discriminate the remote 177 nodes (and thus allows their selection during path computation) with 178 respect to their adaptation capability e.g. to terminate LSPs at the 179 PSC or LSC level. 181 Hence, we introduce the idea of discriminating the (internal) 182 adaptation capability from the (interface) switching capability by 183 considering an interface adaptation capability descriptor. 185 A more detailed problem statement can be found in [MLN-EVAL]. 187 3.2 Interface Adaptation Capability Descriptor (IACD) Format 189 The interface switching capability descriptor (IACD) provides the 190 information for the forwarding/switching) capability only. 192 3.2.1 OSPF-TE 193 In OSPF, the IACD sub-TLV is defined as a sub-TLV of the Link TLV 194 (see [RFC 3630]), with type TBD. The IACD sub-TLV format is defined 195 as follows: 197 0 1 2 3 198 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 199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 200 | Switching Cap | Encoding | Switching Cap | Encoding | 201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 202 | Max LSP Bandwidth at priority 0 | 203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 204 | Max LSP Bandwidth at priority 1 | 205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 206 | Max LSP Bandwidth at priority 2 | 207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 208 | Max LSP Bandwidth at priority 3 | 209 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 210 | Max LSP Bandwidth at priority 4 | 211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 212 | Max LSP Bandwidth at priority 5 | 213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 214 | Max LSP Bandwidth at priority 6 | 215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 216 | Max LSP Bandwidth at priority 7 | 217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 218 | Adaptation Capability-specific information | 219 | (variable) | 220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 222 Where: 224 - first Switching Capability (SC) field (byte 1): lower switching 225 capability (as defined for the existing ISC sub-TLV) 226 - first Encoding field (byte 2): as defined for the existing ISC 227 sub-TLV 228 - second SC value (byte 3): upper switching capability (new) 229 - second encoding value (byte 4): set to the encoding of the 230 available adaptation pool and to 0xFF when the corresponding SC 231 value has no access to the wire (i.e. there is no ISC sub-TLV for 232 this upper switching capability) 234 Multiple IACD sub-TLVs may be present within a given TE Link TLV 235 and the bandwidth simply provides an indication of resources still 236 available to perform insertion/ extraction for a given adaptation 237 (pool concept). 239 3.2.2 ISIS-TE 240 In IS-IS, the IACD sub-TLV is a sub-TLV of the Extended IS 241 Reachability TLV (see [RFC 3784]) with type TBD. The IACD sub-TLV 242 format is defined as follows: 244 0 1 2 3 245 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 246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 247 | Switching Cap | Encoding | Switching Cap | Encoding | 248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 249 | Max LSP Bandwidth at priority 0 | 250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 251 | Max LSP Bandwidth at priority 1 | 252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 253 | Max LSP Bandwidth at priority 2 | 254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 255 | Max LSP Bandwidth at priority 3 | 256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 257 | Max LSP Bandwidth at priority 4 | 258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 259 | Max LSP Bandwidth at priority 5 | 260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 261 | Max LSP Bandwidth at priority 6 | 262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 263 | Max LSP Bandwidth at priority 7 | 264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 265 | Adaptation Capability-specific information | 266 | (variable) | 267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 269 Where the fields have the same processing and interpretation rules as 270 for Section 3.2.1 272 Multiple IACD sub-TLVs may be present within a given extended IS 273 reachability TLV and the bandwidth simply provides an indication of 274 resources still available to perform insertion/ extraction for a 275 given adaptation (pool concept). 277 4. Multi-Region Signaling 279 Section 8.2 of [RFC4206] specifies that when a region boundary node 280 receives a Path message, the node determines whether it is at the 281 edge of an LSP region with respect to the ERO carried in the 282 message. If the node is at the edge of a region, it must then 283 determine the other edge of the region with respect to the ERO, 284 using the IGP database. The node then extracts from the ERO the 285 subsequence of hops from itself to the other end of the region. 287 The node then compares the subsequence of hops with all existing FA- 288 LSPs originated by the node: 289 - if a match is found, that FA-LSP has enough unreserved bandwidth 290 for the LSP being signaled, and the PID of the FA-LSP is 291 compatible with the PID of the LSP being signaled, the node uses 292 that FA-LSP as follows. The Path message for the original LSP is 293 sent to the egress of the FA-LSP. The PHOP in the message is the 294 address of the node at the head-end of the FA-LSP. Before sending 295 the Path message, the ERO in that message is adjusted by removing 296 the subsequence of the ERO that lies in the FA-LSP, and replacing 297 it with just the end point of the FA-LSP. 298 - if no existing FA-LSP is found, the node sets up a new FA-LSP. 299 That is, it initiates a new LSP setup just for the FA-LSP. 301 Applying this procedure, in a MRN environment MAY lead to setup one- 302 hop FA-LSPs between each node. Therefore, considering that the path 303 computation is able to take into account richness of information with 304 regard to the SC available on given nodes belonging to the path, it 305 is consistent to provide enough signaling information to indicate the 306 SC to be used and on over which link. Particularly, in case a TE 307 link has multiple SC advertised as part of its ISCD sub-TLVs, an ERO 308 does not allow selecting a particular SC. 310 Limiting modifications to existing RSVP-TE procedures [RFC3473] and 311 referenced, this document defines a new sub-object of the eXclude 312 Route Object [XRO], called Switching Capability sub-object. This sub- 313 object enables (when desired) the explicit identification of (at 314 least one) switching capability to be excluded from the resource 315 selection process described here above. 317 Including this sub-object as part of the XRO that explicitly 318 indicates which SCs have to be excluded (before initiating the 319 procedure described here above) over a specified TE link solves the 320 ambiguous choice among SCs that are potentially used along a given 321 path and give the possibility to optimize resource usage on a multi- 322 region basis. Note that implicit SC inclusion is easily supported by 323 explicitly excluding other SCs (e.g. to include LSC, it is required 324 to exclude PSC, L2SC, TDM and FSC). 326 Note: usage of the EXRS is under investigation. 328 4.1 SC Subobject Encoding 330 The contents of an EXCLUDE_ROUTE object defined in [XRO] are a 331 series of variable-length data items called subobjects. This 332 document defines the SC subobject of the XRO (Type TBD), its 333 encoding and processing. 335 Subobject Type TBD: Switching Capability 336 0 1 2 3 337 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 338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 339 |L| Type | Length | Attribute | Switching Cap | 340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 342 L 343 0 indicates that the attribute specified MUST be excluded 344 1 indicates that the attribute specified SHOULD be avoided 346 Attribute 348 0 reserved value 350 1 indicates that the specified SC should be excluded or 351 avoided with respect to the preceding numbered (Type 1 or 352 Type 2) or unnumbered interface (Type) subobject 354 Switching Cap (8-bits) 356 Switching Capability value to be excluded. 358 This sub-object must follow the set of numbered or unnumbered 359 interface sub-objects to which this sub-object refers. In case, of 360 loose hop ERO subobject, the XRO sub-object must precede the loose- 361 hop sub-object identifying the tail-end node/interface of the 362 traversed region(s). 364 Furthermore, it is expected, when label sub-object are following 365 numbered or unnumbered interface sub-objects, that the label value is 366 compliant with the SC capability to be explicitly excluded. 368 5. Virtual TE link 370 Two techniques can be used for the setup operation and maintenance of 371 Virtual TE links. The corresponding GMPLS protocols extensions are 372 described in this section. 374 5.1 Edge-to-edge Association 376 This approach that does not require state maintenance on transit LSRs 377 relies on extensions to the GMPLS RSVP-TE Call procedure ([GMPLS- 378 CALL]). 380 This technique consists of exchanging identification and TE 381 attributes information directly between TE link end points. These TE 382 link end-points correspond to the LSP head-end and tail-end points of 383 of the LSPs that will be established. The end-points MUST belong to 384 the same (LSP) region through the establishment of a call between 385 terminating LSRs. 387 Once the call is established the resulting association populates the 388 local TEDB and the resulting TE link is advertised as any other TE 389 link. The latter can then be used to attract traffic. Once an upper 390 layer/lower region LSP makes use of this TE link. A set of one or 391 more LSPs must be initially established before the FA LSP can be used 392 for nesting the incoming LSP. 394 In order to distinguish usage of such call from a classical call (as 395 defined e.g. in [RFC4139]), a CALL ATTRIBUTES object is introduced. 397 5.1.1 CALL_ATTRIBUTES Object 399 The CALL_ATTRIBUTES object is used to signal attributes required in 400 support of a call, or to indicate the nature or use of a call. It is 401 built on the LSP-ATTRIBUTES object defined in [RFC4420]. 403 The CALL_ATTRIBUTES object class is 201 (TBD by IANA) of the form 404 11bbbbbb. This C-Num value (see [RFC2205], Section 3.10) ensures that 405 LSRs that do not recognize the object pass it on transparently. 407 One C-Type is defined, C-Type = 1 for CALL Attributes. This object is 408 optional and may be placed on Notify messages to convey additional 409 information about the desired attributes of the call. 411 5.1.2 Processing 413 Specifically, if an egress (or intermediate) LSR does not support the 414 object, it forwards it unexamined and unchanged. This facilitates 415 the exchange of attributes across legacy networks that do not support 416 this new object. 418 The CALL_ATTRIBUTES object may be used to report call operational 419 state on a Notify message. 421 CALL_ATTRIBUTES class = 201, C-Type = 1 423 0 1 2 3 424 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 425 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 426 | | 427 // Attributes TLVs // 428 | | 429 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 431 The Attributes TLVs are encoded as described in Section 3. 433 5.1.3 Attributes TLVs 435 Attributes carried by the CALL_ATTRIBUTES object are encoded within 436 TLVs. One or more TLVs may be present in each object. 438 There are no ordering rules for TLVs, and no interpretation should be 439 placed on the order in which TLVs are received. 441 Each TLV is encoded as follows. 443 0 1 2 3 444 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 445 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 446 | Type | Length | 447 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 448 | | 449 // Value // 450 | | 451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 453 Type 455 The identifier of the TLV. 457 Length 459 The length of the Value field in bytes. Thus, if no Value 460 field is present the Length field contains the value zero. 461 Each Value field must be zero padded at the end to take it up 462 to a four byte boundary -- the padding is not included in the 463 length so that a one byte value would be encoded in an eight 464 byte TLV with Length field set to one. 466 Value 468 The data for the TLV padded as described above. 470 TLV Type 1 indicates the Attributes Flags TLV. Other TLV types may be 471 defined in the future with type values assigned by IANA (see Section 472 11.2). The Attributes Flags TLV may be present in a CALL_ATTRIBUTES 473 object. 475 The Attribute Flags TLV value field is an array of units of 32 flags 476 numbered from the most significant bit as bit zero. The Length field 477 for this TLV is therefore always a multiple of 4 bytes, regardless of 478 the number of bits carried and no padding is required. 480 Unassigned bits are considered as reserved and MUST be set to zero on 481 transmission by the originator of the object. Bits not contained in 482 the TLV MUST be assumed to be set to zero. If the TLV is absent 483 either because it is not contained in the CALL_ATTRIBUTES object or 484 because this object is itself absent, all processing MUST be 485 performed as though the bits were present and set to zero. That is to 486 say, assigned bits that are not present either because the TLV is 487 deliberately foreshortened or because the TLV is not included MUST be 488 treated as though they are present and are set to zero. 490 5.1.4 Call inheritance Flag 492 This document introduces a specific flag (MSB position bit 0) of the 493 Attributes Flags TLV, to indicate that the association initiated 494 between the end-points belonging to a call results into a (virtual) 495 TE link advertisement. 497 The Call inheritance flag MUST be set to 1 in order to indicate that 498 the established association is to be translated into a TE link 499 advertisement. The value of this flag is by default set to 1. Setting 500 this flag to 0 results in a hidden TE link or in deleting the 501 corresponding TE link advertisement (by setting the corresponding 502 Opaque LSA Age to MaxAge). 504 The notify message used for establishing the association is defined 505 as per [GMPLS-CALL]. Additionally, the notify message must carry an 506 LSP_TUNNEL_INTERFACE_ID Object, that allows identifying unnumbered 507 FA-LSPs ([RFC3477], [RFC4206], [RFC4206-bis]) and numbered FA-LSPs 508 ([RFC4206], [RFC4206-bis]). 510 5.2. Soft-FA approach 512 The Soft Forwarding Adjacency (Soft FA) approach consists of setting 513 up the FA LSP at the control plane level without actually committing 514 resources in the data plane. This means that the corresponding LSP 515 exists only in the control plane domain. 517 Once such FA is established the corresponding TE link can be 518 advertized following the procedures described in [RFC 4206]. 520 5.2.1 Pre-planned LSP Flag 522 The LSP ATTRIBUTES object and Attributes Flags TLV are defined in 523 [RFC4420]. The present document defines a new flag, the pre-planned 524 LSP Flag, in the existing Attributes Flags TLV (numbered as Type 1). 526 The position of this flag is TBD in accordance with IANA assignment. 527 This flag, part of the LSP_REQUIRED ATTRIBUTE object, follows 528 processing of [RFC4420] for that object. That is, LSRs that do not 529 recognize the object reject the LSP setup effectively saying that 530 they do not support the attributes requested. Indeed, the newly 531 defined attribute requires examination at all transit LSRs. 533 The pre-planned LSP Flag can take one of the following values: 535 o) When set to 0 this means that the LSP should be fully provisioned. 536 Absence of this flag (hence corresponding TLV) is therefore compliant 537 with the signaling message processing per [RFC3473]) 539 o) When set to 1 this means that the LSP should be provisioned in the 540 control plane only. 542 If an LSP is established with the pre-planned Flag set to 1, no 543 resources are committed at the data plane level. The operation of 544 committing data plane resources occurs by re-signaling the same LSP 545 with the pre-planned Flag set to 0. It is RECOMMENDED that no other 546 modifications are made to other RSVP objects during this operation. 547 That is each intermediate node, processing a Flag transiting from 1 548 to 0 shall only be concerned with the commitment of data plane 549 resources and no other modification of the LSP properties and/or 550 attributes. 552 If an LSP is established with the pre-planned Flag set to 0, it MAY 553 be re-signaled by setting the Flag to 1. 555 5.2.2 Path Provisioned LSPs 557 There is a difference in between an LSP that is established with 0 558 bandwidth (path provisioning) and an LSP that is established with a 559 certain bandwidth value not committed at the data plane level (i.e. 560 pre-planned LSP). 562 However, the former is currently not possible using the GMPLS 563 protocol suite (following technology specific SENDER_TSPEC/FLOWSPEC 564 definition). Indeed, Traffic Parameters such as those defined in [RFC 565 4606] do not support setup of 0 bandwidth LSPs. 567 Mechanisms for provisioning (pre-planned or not) LSP with 0 bandwidth 568 will be described in next release of this document. 570 6. Backward compatibility 572 New objects and procedures defined in this document are running 573 within a given TE domain. The latter is expected to run in the 574 context of a consistent TE policy. 576 In such TE domains, we distinguish between edge LSRs and intermediate 577 LSrs. Edge LSRs must be able to process Call Attribute as defined in 578 section 5.1 if this is method selected or creating edge-to-edge 579 associations. In that domain, intermediate LSRs are by definition 580 transparent to the Call processing. 582 In case the Soft FA method is used for the creation of Virtual TE 583 links, edge and intermediate LSRs must support processing of the LSP 584 ATTRIBUTE object per Section 5.2. 586 7. Security Considerations 588 In its current version, this memo does not introduce new security 589 consideration from the ones already detailed in the GMPLS protocol 590 suite. 592 8. References 594 8.1 Normative References 596 [GMPLS-CALL]D.Papadimitriou and A.Farrel, "Generalized MPLS (GMPLS) 597 RSVP-TE Signaling Extensions in support of Calls," Work 598 in progress, draft-ietf-ccamp-gmpls-rsvp-te-call-04.txt, 599 January 2007. 601 [L2SC-LSP] D.Papadimitriou, et al., "Generalized MPLS Signaling for 602 Layer-2 Label Switched Paths (LSP)", Work in Progress, 603 draft-papadimitriou-ccamp-gmpls-l2sc-lsp-03.txt. 605 [MRN-EVAL] J.-L. Leroux et al., "Evaluation of existing GMPLS 606 Protocols against Multi Region and Multi Layer Networks 607 (MRN/MLN)", Work in Progress, draft-ietf-ccamp-gmpls-mln- 608 eval-03.txt. 610 [MRN-REQ] K.Shiomoto et al., "Requirements for GMPLS-based multi- 611 region and multi-layer networks (MRN/MLN)", Work in 612 Progress, draft-ietf-ccamp-gmpls-mrn-reqs-03.txt. 614 [RFC2119] Bradner, S., 'Key words for use in RFCs to indicate 615 requirements levels', RFC 2119, March 1997. 617 [RFC2370] R.Coltun, "The OSPF Opaque LSA Option", RFC 2370, July 618 1998. 620 [RFC3471] L.Berger et al., "Generalized Multi-Protocol Label 621 Switching (GMPLS) - Signaling Functional Description", 622 RFC 3471, January 2003. 624 [RFC3630] D.Katz et al., "Traffic Engineering (TE) Extensions to 625 OSPF Version 2," RFC 3630, September 2003. 627 [RFC3667] Bradner, S., "IETF Rights in Contributions", BCP 78, 628 RFC 3667, February 2004. 630 [RFC3668] Bradner, S., Ed., 'Intellectual Property Rights in IETF 631 Technology', BCP 79, RFC 3668, February 2004. 633 [RFC4201] K.Kompella, et al., "Link Bundling in MPLS Traffic 634 Engineering", RFC 4201, October 2005. 636 [RFC4202] K.Kompella (Editor), Y. Rekhter (Editor) et al. "Routing 637 Extensions in Support of Generalized MPLS", RFC 4202, 638 October 2005. 640 [RFC4206] K.Kompella and Y.Rekhter, "LSP Hierarchy with Generalized 641 MPLS TE", RFC 4206, October 2005. 643 [RFC4206-bis] Shimoto et al. " Procedures for Dynamically Signaled 644 Hierarchical Label Switched Paths ", draft-ietf-ccamp- 645 lsp-hierarchy-bis, work in progress. 647 [RFC4420] A.Farrel et al., "Encoding of Attributes for 648 Multiprotocol Label Switching (MPLS) Label Switched Path 649 (LSP) Establishment Using Resource ReserVation Protocol- 650 Traffic Engineering (RSVP-TE)", RFC 4420, February 2006. 652 [RFC4428] D.Papadimitriou et al. "Analysis of Generalized Multi- 653 Protocol Label Switching (GMPLS)-based Recovery 654 Mechanisms (including Protection and Restoration)", RFC 655 4428, March 2006. 657 [XRO] C.Y.Lee et al. "Exclude Routes - Extension to RSVP-TE," 658 Work in progress, draft-ietf-ccamp-rsvp-te-exclude- 659 route-05.txt, August 2005. 661 8.2 Informative References 663 [MAMLTE] K.Shiomoto et al., "Multi-area multi-layer traffic 664 engineering using hierarchical LSPs in GMPLS networks", 665 Work in Progress, draft-shiomoto-multiarea-te-01.txt. 667 [MLRT] W.Imajuku et al., "Multilayer routing using multilayer 668 switch capable LSRs, Work in Progress, draft-imajuku-ml- 669 routing-02.txt. 671 Acknowledgments 673 The authors would like to thank Mr. Wataru Imajuku for the 674 discussions on adaptation between regions [MLRT]. 676 Author's Addresses 677 Dimitri Papadimitriou 678 Alcatel-Lucent Bell 679 Copernicuslaan 50 680 B-2018 Antwerpen, Belgium 681 Phone : +32 3 240 8491 682 E-mail: dimitri.papadimitriou@alcatel-lucent.be 684 Martin Vigoureux 685 Alcatel-Lucent France 686 Route de Villejust 687 91620 Nozay, France 688 Tel : +33 1 30 77 26 69 689 Email: martin.vigoureux@alcatel-lucent.fr 691 Kohei Shiomoto 692 NTT Network Service Systems Laboratories 693 3-9-11 Midori-cho 694 Musashino-shi, Tokyo 180-8585, Japan 695 Phone: +81 422 59 4402 696 E-mail: shiomoto.kohei@lab.ntt.co.jp 698 Deborah Brungard 699 AT&T 700 Rm. D1-3C22 - 200 S. Laurel Ave. 701 Middletown, NJ 07748, USA 702 Phone: +1 732 420 1573 703 E-mail: dbrungard@att.com 705 Jean-Louis Le Roux 706 FTRD/DAC/LAN 707 Avenue Pierre Marzin 708 22300 Lannion, France 709 Phone: +33 (0)2 96 05 30 20 710 E-mail:jean-louis.leroux@rd.francetelecom.com 712 Contributors 714 Eiji Oki 715 NTT Network Service Systems Laboratories 716 3-9-11 Midori-cho 717 Musashino-shi, Tokyo 180-8585, Japan 718 Phone : +81 422 59 3441 719 Email: oki.eiji@lab.ntt.co.jp 721 Ichiro Inoue 722 NTT Network Service Systems Laboratories 723 3-9-11 Midori-cho 724 Musashino-shi, Tokyo 180-8585, Japan 725 Phone : +81 422 59 6076 726 Email: ichiro.inoue@lab.ntt.co.jp 728 Emmanuel Dotaro 729 Alcatel-Lucent France 730 Route de Villejust 731 91620 Nozay, France 732 Phone : +33 1 6963 4723 733 Email: emmanuel.dotaro@alcatel-lucent.fr 735 Gert Grammel 736 Alcatel-Lucent SEL 737 Lorenzstrasse, 10 738 70435 Stuttgart, Germany 739 Email: gert.grammel@alcatel-lucent.de 741 Full Copyright Statement 743 Copyright (C) The Internet Society (2007). 745 This document is subject to the rights, licenses and restrictions 746 contained in BCP 78, and except as set forth therein, the authors 747 retain all their rights. 749 This document and the information contained herein are provided on an 750 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 751 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 752 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 753 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 754 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 755 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 757 Intellectual Property 759 The IETF takes no position regarding the validity or scope of any 760 Intellectual Property Rights or other rights that might be claimed to 761 pertain to the implementation or use of the technology described in 762 this document or the extent to which any license under such rights 763 might or might not be available; nor does it represent that it has 764 made any independent effort to identify any such rights. Information 765 on the procedures with respect to rights in RFC documents can be 766 found in BCP 78 and BCP 79. 768 Copies of IPR disclosures made to the IETF Secretariat and any 769 assurances of licenses to be made available, or the result of an 770 attempt made to obtain a general license or permission for the use 771 of such proprietary rights by implementers or users of this 772 specification can be obtained from the IETF on-line IPR repository at 773 http://www.ietf.org/ipr. 775 The IETF invites any interested party to bring to its attention any 776 copyrights, patents or patent applications, or other proprietary 777 rights that may cover technology that may be required to implement 778 this standard. Please address the information to the IETF at 779 ietf-ipr@ietf.org. 781 Acknowledgment 783 Funding for the RFC Editor function is provided by the IETF 784 Administrative Support Activity (IASA).