idnits 2.17.1 draft-ietf-ccamp-gmpls-mln-extensions-12.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. 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: 'This I-D' is mentioned on line 928, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE' ** Obsolete normative reference: RFC 4306 (Obsoleted by RFC 5996) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET DRAFT Dimitri Papadimitriou 3 Martin Vigoureux 4 Intended Status: Standards Track Alcatel-Lucent 5 Updates: 4202, 4203, 4206, 4874, 4974, 5307 Kohei Shiomoto 6 Expiration Date: August 20 2010 NTT 7 Creation Date: February 21 2010 Deborah Brungard 8 ATT 9 Jean-Louis Le Roux 10 France Telecom 12 Generalized Multi-Protocol Label Switching (GMPLS) Protocol 13 Extensions for Multi-Layer and Multi-Region Networks (MLN/MRN) 15 draft-ietf-ccamp-gmpls-mln-extensions-12.txt 17 Status of this Memo 19 This Internet-Draft is submitted to IETF in full conformance 20 with the provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet 23 Engineering Task Force (IETF), its areas, and its working 24 groups. Note that other groups may also distribute working 25 documents as Internet-Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six 28 months and may be updated, replaced, or obsoleted by other 29 documents at any time. It is inappropriate to use Internet- 30 Drafts as reference material or to cite them other than as 31 "work in progress." 33 The list of current Internet-Drafts can be accessed 34 at http://www.ietf.org/ietf/1id-abstracts.txt 36 The list of Internet-Draft Shadow Directories can be accessed 37 at http://www.ietf.org/shadow.html 39 This Internet-Draft will expire on August 20, 2010. 41 Copyright Notice 43 Copyright (c) 2010 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) 49 in effect on the date of publication of this document. Please 50 review these documents carefully, as they describe your rights 51 and restrictions with respect to this document. Code Components 52 extracted from this document must include Simplified BSD 53 License text as described in Section 4.e of the Trust Legal 54 Provisions and are provided without warranty as described in 55 the Simplified BSD License. 57 This document may contain material from IETF Documents or IETF 58 Contributions published or made publicly available before 59 November 10, 2008. The person(s) controlling the copyright in 60 some of this material may not have granted the IETF Trust the 61 right to allow modifications of such material outside the IETF 62 Standards Process. Without obtaining an adequate license from 63 the person(s) controlling the copyright in such materials, this 64 document may not be modified outside the IETF Standards 65 Process, and derivative works of it may not be created outside 66 the IETF Standards Process, except to format it for publication 67 as an RFC or to translate it into languages other than English. 69 Abstract 71 There are specific requirements for the support of networks 72 comprising Label Switching Routers (LSR) participating in 73 different data plane switching layers controlled by a single 74 Generalized Multi Protocol Label Switching (GMPLS) control 75 plane instance, referred to as GMPLS Multi-Layer Networks/ 76 Multi-Region Networks (MLN/MRN). 78 This document defines extensions to GMPLS routing and signaling 79 protocols so as to support the operation of GMPLS Multi-Layer/ 80 Multi-Region Networks. It covers the elements of a single 81 GMPLS control plane instance controlling multiple LSP regions 82 or layers within a single TE domain. 84 Table of Contents 86 Abstract.....................................................2 87 Table of Contents............................................2 88 1. Introduction..............................................3 89 2. Summary of the Requirements and Evaluation................4 90 3. Interface adjustment capability descriptor (IACD).........5 91 3.1. Overview.............................................5 92 3.2. Interface Adjustment Capability Descriptor (IACD)....6 93 4. Multi-Region Signaling....................................9 94 4.1. XRO Subobjects......................................10 96 5. Virtual TE link..........................................13 97 5.1. Edge-to-edge Association............................13 98 5.2. Soft Forwarding Adjacency (Soft FA).................17 99 6. Backward Compatibility...................................19 100 7. Security Considerations..................................19 101 8. IANA Considerations......................................20 102 8.1 RSVP.................................................20 103 8.2 OSPF.................................................21 104 8.3 IS-IS................................................21 105 9. References...............................................21 106 9.1 Normative References.................................21 107 9.2 Informative References...............................23 108 Acknowledgments.............................................24 109 Author's Addresses..........................................24 111 Conventions used in this document 113 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 114 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 115 "OPTIONAL" in this document are to be interpreted as described 116 in [RFC2119]. 118 In addition the reader is assumed to be familiar with 119 [RFC3945], [RFC3471], [RFC4201], [RFC4202], [RFC4203], 120 [RFC4206], and [RFC5307]. 122 1. Introduction 124 Generalized Multi-Protocol Label Switching (GMPLS) [RFC3945] 125 extends MPLS to handle multiple switching technologies: packet 126 switching (PSC), layer-two switching (L2SC), TDM switching 127 (TDM), wavelength switching (LSC) and fiber switching (FSC). A 128 GMPLS switching type (PSC, TDM, etc.) describes the ability of 129 a node to forward data of a particular data plane technology, 130 and uniquely identifies a control plane Label Switched Path 131 (LSP) region. LSP Regions are defined in [RFC4206]. A network 132 comprised of multiple switching types (e.g. PSC and TDM) 133 controlled by a single GMPLS control plane instance is called a 134 Multi-Region Network (MRN). 136 A data plane layer is a collection of network resources capable 137 of terminating and/or switching data traffic of a particular 138 format. For example, LSC, TDM VC-11 and TDM VC-4-64c represent 139 three different layers. A network comprising transport nodes 140 participating in different data plane switching layers 141 controlled by a single GMPLS control plane instance is called 142 a Multi-Layer Network (MLN). 144 The applicability of GMPLS to multiple switching technologies 145 provides the unified control and operations for both LSP 146 provisioning and recovery. This document covers the elements 147 of a single GMPLS control plane instance controlling multiple 148 layers within a given TE domain. A TE domain is defined as 149 group of Label Switching Routers (LSR) that enforces a common 150 TE policy. A Control Plane (CP) instance can serve one, two or 151 more layers. Other possible approaches such as having multiple 152 CP instances serving disjoint sets of layers are outside the 153 scope of this document. 155 The next sections provide the procedural aspects in terms of 156 routing and signaling for such environments as well as the 157 extensions required to instrument GMPLS to provide the 158 capabilities for MLM/MRN unified control. The rationales and 159 requirements for Multi-Layer/Region networks are set forth in 160 [RFC5212]. These requirements are evaluated against GMPLS 161 protocols in [RFC5339] and several areas where GMPLS protocol 162 extensions are required are identified. 164 This document defines GMPLS routing and signaling extensions 165 so as to cover GMPLS MLN/MRN requirements. 167 2. Summary of the Requirements and Evaluation 169 As identified in [RFC5339], most MLN/MRN requirements rely on 170 mechanisms and procedures (such as local procedures and 171 policies, or specific TE mechanisms and algorithms) that are 172 outside the scope of the GMPLS protocols, and thus do not 173 require any GMPLS protocol extensions. 175 Four areas for extensions of GMPLS protocols and procedures 176 have been identified in [RFC5339]: 178 o GMPLS routing extensions for the advertisement of the 179 internal adjustment capability of hybrid nodes. See Section 180 3.2.2 of [RFC5339]. 182 o GMPLS signaling extensions for constrained multi-region 183 signaling (Switching Capability inclusion/exclusion). See 184 Section 3.2.1 of [RFC5339]. An additional eXclude Route 185 Object (XRO) Label subobject is also defined since absent 186 from [RFC4874]. 188 o GMPLS signaling extensions for the setup/deletion of Virtual 189 TE-links (as well as exact trigger for its actual 190 provisioning). See Section 3.1.1.2 of [RFC5339]. 192 o GMPLS routing and signaling extensions for graceful TE-link 193 deletion. See Section 3.1.1.3 of [RFC5339]. 195 The first three requirements are addressed in Sections 3, 4, 196 and 5 of this document, respectively. The fourth requirement is 197 addressed in [GMPLS-RR] with additional context provided by 198 [GR-TELINK]. 200 3. Interface adjustment capability descriptor (IACD) 202 In the MRN context, nodes that have at least one interface that 203 supports more than one switching capability are called Hybrid 204 nodes [RFC5212]. The logical composition of a hybrid node 205 contains at least two distinct switching elements that are 206 interconnected by "internal links" to provide adjustment 207 between the supported switching capabilities. These internal 208 links have finite capacities that MUST be taken into account 209 when computing the path of a multi-region TE-LSP. The 210 advertisement of the internal adjustment capability is required 211 as it provides critical information when performing multi- 212 region path computation. 214 3.1. Overview 216 In an MRN environment, some LSRs could contain multiple 217 switching capabilities such as PSC and TDM, or PSC and LSC, all 218 under the control of a single GMPLS instance, 220 These nodes, hosting multiple Interface Switching Capabilities 221 (ISC) [RFC4202], are required to hold and advertise resource 222 information on link states and topology, just like other nodes 223 (hosting a single ISC). They may also have to consider some 224 portions of internal node resources use to terminate 225 hierarchical LSPs, since in circuit-switching technologies 226 (such as TDM, LSC, and FSC) LSPs require the use of resources 227 allocated in a discrete manner (as pre-determined by the 228 switching type). For example, a node with PSC+LSC hierarchical 229 switching capability can switch a lambda LSP, but cannot 230 terminate the Lambda LSP if there is no available (i.e., not 231 already in use) adjustment capability between the LSC and the 232 PSC switching components. Another example occurs when L2SC 233 (Ethernet) switching can be adapted in LAPS X.86 and GFP for 234 instance before reaching the TDM switching matrix. Similar 235 circumstances can occur, if a switching fabric that supports 236 both PSC and L2SC functionalities is assembled with LSC 237 interfaces enabling "lambda" encoding. In the switching fabric, 238 some interfaces can terminate Lambda LSPs and perform frame (or 239 cell) switching whilst other interfaces can terminate Lambda 240 LSPs and perform packet switching. 242 Therefore, within multi-region networks, the advertisement of 243 the so-called adjustment capability to terminate LSPs (not the 244 interface capability since the latter can be inferred from the 245 bandwidth available for each switching capability) provides the 246 information to take into account when performing multi-region 247 path computation. This concept enables a node to discriminate 248 the remote nodes (and thus allows their selection during path 249 computation) with respect to their adjustment capability e.g. 250 to terminate LSPs at the PSC or LSC level. 252 Hence, we introduce the capability of discriminating the 253 (internal) adjustment capability from the (interface) switching 254 capability by defining an Interface Adjustment Capability 255 Descriptor (IACD). 257 A more detailed problem statement can be found in [RFC5339]. 259 3.2. Interface Adjustment Capability Descriptor (IACD) 261 The interface adjustment capability descriptor (IACD) provides 262 the information for the forwarding/switching capability. 264 Note that the addition of the IACD as a TE link attribute does 265 not modify the format of the Interface Switching Capability 266 Descriptor (ISCD) defined in [RFC4202], and does not change how 267 the ISCD sub-TLV is carried in the routing protocols or how it 268 is processed when it is received [RFC4201], [RFC4203]. 270 The receiving LSR uses its Link State Database to determine the 271 IACD(s) of the far-end of the link. Different Interface 272 Adjustment Capabilities at two ends of a TE link are allowed. 274 3.2.1 OSPF 276 In OSPF, the IACD sub-TLV is defined as an optional sub-TLV of 277 the TE Link TLV (Type 2, see [RFC3630]), with Type 24 (to be 278 assigned by IANA) and variable length. 280 The IACD sub-TLV format is defined as follows: 282 0 1 2 3 283 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 284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 285 | Lower SC | Lower Encoding| Upper SC | Upper Encoding| 286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 287 | Max LSP Bandwidth at priority 0 | 288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 289 | Max LSP Bandwidth at priority 1 | 290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 291 | Max LSP Bandwidth at priority 2 | 292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 293 | Max LSP Bandwidth at priority 3 | 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 | Max LSP Bandwidth at priority 4 | 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 | Max LSP Bandwidth at priority 5 | 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 299 | Max LSP Bandwidth at priority 6 | 300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 301 | Max LSP Bandwidth at priority 7 | 302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 303 | Adjustment Capability-specific information | 304 | (variable) | 305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 307 Lower Switching Capability (SC) field (byte 1) - 8 bits 309 Indicates the Lower Switching Capability associated to 310 the Lower Encoding field (byte 2). The value of the Lower 311 Switching Capability field MUST be set to the value of 312 Switching Capability of the ISCD sub-TLV advertized for 313 this TE Link. If multiple ISCD sub-TLVs are advertized 314 for that TE link, the Lower Switching Capability (SC) 315 value MUST be set to the value of SC to which the 316 adjustment capacity is associated. 318 Lower Encoding (byte 2) - 8 bits 320 Contains one of the LSP Encoding Type values specified in 321 Section 3.1.1 of [RFC3471] and updates. 323 Upper Switching Capability (SC) field (byte 3) - 8 bits 325 Indicates the Upper Switching capability. The Upper 326 Switching Capability field MUST be set to one of the 327 values defined in [RFC4202]. 329 Upper Encoding (byte 4) - 8 bits 331 Set to the encoding of the available adjustment capacity 332 and to 0xFF when the corresponding SC value has no access 333 to the wire, i.e., there is no ISC sub-TLV for this upper 334 switching capability. The adjustment capacity is the set 335 of resources associated to the upper switching 336 capability. 338 Max LSP Bandwidth 340 The Maximum LSP Bandwidth is encoded as a list of eight 341 4 octet fields in the IEEE floating point format [IEEE], 342 with priority 0 first and priority 7 last. The units are 343 bytes per second. Processing MUST follow the rules 344 specified in [RFC4202]. 346 The Adjustment Capability-specific information - variable 348 This field is defined so as to leave the possibility for 349 future addition of technology-specific information 350 associated to the adjustment capability. 352 Other fields MUST be processed as specified in [RFC4202] 353 and [RFC4203]. 355 The bandwidth values provide an indication of the resources 356 still available to perform insertion/extraction for a given 357 adjustment at a given priority (resource pool concept: set of 358 shareable available resources that can be assigned 359 dynamically). 361 Multiple IACD sub-TLVs MAY be present within a given TE Link 362 TLV. 364 The presence of the IACD sub-TLV as part of the TE Link TLV 365 does not modify the format/messaging and the processing 366 associated to the ISCD sub-TLV defined in [RFC4203]. 368 3.2.2 IS-IS 369 In IS-IS, the IACD sub-TLV is an optional sub-TLV of the 370 Extended IS Reachability TLV (see [RFC5305]) with Type 24 (to 371 be assigned by IANA). 373 The IACD sub-TLV format is identical to the OSPF sub-TLV format 374 defined in Section 3.2.1. The fields of the IACD sub-TLV have 375 the same processing and interpretation rules as defined in 376 Section 3.2.1. 378 Multiple IACD sub-TLVs MAY be present within a given extended 379 IS reachability TLV. 381 The presence of the IACD sub-TLV as part of the extended IS 382 reachability TLV does not modify format/messaging and 383 processing associated to the ISCD sub-TLV defined in [RFC5307]. 385 4. Multi-Region Signaling 387 Section 6.2 of [RFC4206] specifies that when a region boundary 388 node receives a Path message, the node determines whether or 389 not it is at the edge of an LSP region with respect to the ERO 390 carried in the message. If the node is at the edge of a region, 391 it must then determine the other edge of the region with 392 respect to the Explicit Route Object (ERO), using the IGP 393 database. The node then extracts from the ERO the sub-sequence 394 of hops from itself to the other end of the region. 396 The node then compares the sub-sequence of hops with all 397 existing FA-LSPs originated by the node: 399 o If a match is found, that FA-LSP has enough unreserved 400 bandwidth for the LSP being signaled, and the G-PID of the 401 FA-LSP is compatible with the G-PID of the LSP being 402 signaled, the node uses that FA-LSP as follows. The Path 403 message for the original LSP is sent to the egress of the FA- 404 LSP. The PHOP in the message is the address of the node at 405 the head-end of the FA-LSP. Before sending the Path message, 406 the ERO in that message is adjusted by removing the 407 subsequence of the ERO that lies in the FA-LSP, and replacing 408 it with just the end point of the FA-LSP. 410 o If no existing FA-LSP is found, the node sets up a new FA- 411 LSP. That is, it initiates a new LSP setup just for the FA- 412 LSP. 414 Note: compatible G-PID implies that traffic can be processed 415 by both ends of the FA-LSP without dropping traffic after its 416 establishment. 418 Applying the procedure of [RFC4206], in a MRN environment MAY 419 lead to setup single-hop FA-LSPs between each pair of nodes. 420 Therefore, considering that the path computation is able to 421 take into account richness of information with regard to the SC 422 available on given nodes belonging to the path, it is 423 consistent to provide enough signaling information to indicate 424 the SC to be used and over which link. Particularly, in case a 425 TE link has multiple SCs advertised as part of its ISCD sub- 426 TLVs, an ERO does not provide a mechanism to select a 427 particular SC. 429 In order to limit the modifications to existing RSVP-TE 430 procedures ([RFC3473] and referenced), this document defines a 431 new sub-object of the eXclude Route Object (XRO), see 432 [RFC4874], called the Switching Capability sub-object. This 433 sub-object enables (when desired) the explicit identification 434 of at least one switching capability to be excluded from the 435 resource selection process described above. 437 Including this sub-object as part of the XRO that explicitly 438 indicates which SCs have to be excluded (before initiating the 439 procedure described here above) over a specified TE link, 440 solves the ambiguous choice among SCs that are potentially used 441 along a given path and give the possibility to optimize 442 resource usage on a multi-region basis. Note that implicit SC 443 inclusion is easily supported by explicitly excluding other SCs 444 (e.g. to include LSC, it is required to exclude PSC, L2SC, TDM 445 and FSC). 447 The approach followed here is to concentrate exclusions in XRO 448 and inclusions in ERO. Indeed, the ERO specifies the 449 topological characteristics of the path to be signaled. Usage 450 of EXRS subobjects would also lead in the exclusion over 451 certain portions of the LSP during the FA-LSP setup. Thus, it 452 is more suited to extend generality of the elements excluded by 453 the XRO but also prevent complex consistency checks as well as 454 transpositions between EXRS and XRO at FA-LSP head-ends. 456 4.1. XRO Subobjects 458 The contents of an EXCLUDE_ROUTE object defined in [RFC4874] 459 are a series of variable-length data items called subobjects. 461 This document defines the Switching Capability (SC) subobject 462 of the XRO (Type 35), its encoding and processing. It also 463 complements the subobjects defined in [RFC4874] with a Label 464 subobject (Type 3). 466 4.1.1 SC Subobject 468 XRO subobject Type 35: Switching Capability 470 0 1 2 3 471 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 472 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 473 |L| Type=35 | Length | Attribute | Switching Cap | 474 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 476 L (1 bit) 478 0 indicates that the attribute specified MUST be excluded 480 1 indicates that the attribute specified SHOULD be 481 avoided 483 Type (7 bits) 485 The Type of the XRO SC subobject is 35. 487 Length (8 bits) 489 The total length of the subobject in bytes (including the 490 Type and Length fields). The Length of the XRO SC 491 subobject is 4. 493 Attribute (8 bits) 495 0 reserved value 497 1 indicates that the specified SC SHOULD be excluded or 498 avoided with respect to the preceding numbered (Type 1 499 or Type 2) or unnumbered interface (Type) subobject. 501 Switching Cap (8 bits) 503 Switching Capability value to be excluded. 505 The Switching Capability subobject MUST follow the set of one 506 or more numbered or unnumbered interface sub-objects to which 507 this sub-object refers. 509 In case, of loose hop ERO subobject, the XRO sub-object MUST 510 precede the loose-hop sub-object identifying the tail-end 511 node/interface of the traversed region(s). 513 4.1.2 Label Subobject 515 The encoding of the XRO Label subobject is identical to the 516 Label ERO subobject defined in [RFC3473] with the exception of 517 the L bit. The XRO Label subobject is defined as follows: 519 XRO Subobject Type 3: Label Subobject 521 0 1 2 3 522 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 523 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 524 |L| Type=3 | Length |U| Reserved | C-Type | 525 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 526 | Label | 527 | ... | 528 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 530 L (1 bit) 532 0 indicates that the attribute specified MUST be 533 excluded. 535 1 indicates that the attribute specified SHOULD be 536 avoided 538 Type (7 bits) 540 The Type of the XRO Label subobject is 3. 542 Length (8 bits) 544 The total length of the subobject in bytes (including the 545 Type and Length fields). The Length is always divisible 546 by 4. 548 U (1 bit) 550 See [RFC3471]. 552 C-Type (8 bits) 554 The C-Type of the included Label Object. Copied from the 555 Label Object (see [RFC3471]). 557 Label 559 See [RFC3471]. 561 XRO Label subobjects MUST follow the numbered or unnumbered 562 interface sub-objects to which they refer, and, when present, 563 MUST also follow the Switching Capability sub-object. 565 When XRO Label subobjects are following the Switching 566 Capability sub-object, the corresponding label values MUST be 567 compatible with the SC capability to be explicitly excluded. 569 5. Virtual TE link 571 A virtual TE link is defined as a TE link between two upper 572 layer nodes that is not associated with a fully provisioned FA- 573 LSP in a lower layer [RFC5212]. A virtual TE link is advertised 574 as any TE link, following the rules in [RFC4206] defined for 575 fully provisioned TE links. A virtual TE link represents thus 576 the potentiality to setup an FA-LSP in the lower layer to 577 support the TE link that has been advertised. In particular, 578 the flooding scope of a virtual TE link is within an IGP area, 579 as is the case for any TE link. 581 Two techniques can be used for the setup, operation, and 582 maintenance of virtual TE links. The corresponding GMPLS 583 protocols extensions are described in this section. The 584 procedures described in this section complement those defined 585 in [RFC4206] and [HIER-BIS]. 587 5.1. Edge-to-edge Association 589 This approach, that does not require state maintenance on 590 transit LSRs, relies on extensions to the GMPLS RSVP-TE Call 591 procedure (see [RFC4974]). This technique consists of 592 exchanging identification and TE attributes information 593 directly between TE link end points through the establishment 594 of a call between terminating LSRs. These TE link end-points 595 correspond to the LSP head-end and tail-end points of the LSPs 596 that will be established. The end-points MUST belong to the 597 same (LSP) region. 599 Once the call is established the resulting association 600 populates the local Traffic Engineering DataBase (TEDB) and the 601 resulting virtual TE link is advertised as any other TE link. 602 The latter can then be used to attract traffic. When an upper 603 layer/region LSP tries to make use of this virtual TE link, one 604 or more FA LSPs MUST be established using the procedures 605 defined in [RFC4206] to make the virtual TE link "real" and 606 allow it to carry traffic by nesting the upper layer/region 607 LSP. 609 In order to distinguish usage of such call from the call and 610 associated procedures defined in [RFC4974], a CALL ATTRIBUTES 611 object is introduced. 613 5.1.1 CALL_ATTRIBUTES Object 615 The CALL_ATTRIBUTES object is used to signal attributes 616 required in support of a call, or to indicate the nature or use 617 of a call. It is modeled on the LSP_ATTRIBUTES object defined 618 in [RFC5420]. The CALL_ATTRIBUTES object MAY also be used to 619 report call operational state on a Notify message. 621 The CALL_ATTRIBUTES object class is 201 (TBD by IANA) of the 622 form 11bbbbbb. This C-Num value (see [RFC2205], Section 3.10) 623 ensures that LSRs that do not recognize the object pass it on 624 transparently. 626 One C-Type is defined, C-Type = 1 for Call Attributes. This 627 object is OPTIONAL and MAY be placed on Notify messages to 628 convey additional information about the desired attributes of 629 the call. 631 CALL_ATTRIBUTES class = 201, C-Type = 1 633 0 1 2 3 634 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 635 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 636 | | 637 // Call Attributes TLVs // 638 | | 639 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 640 The Call Attributes TLVs are encoded as described in Section 641 5.1.3. 643 5.1.2 Processing 645 If an egress (or intermediate) LSR does not support the object, 646 it forwards it unexamined and unchanged. This facilitates the 647 exchange of attributes across legacy networks that do not 648 support this new object. 650 5.1.3 Call Attributes TLVs 652 Attributes carried by the CALL_ATTRIBUTES object are encoded 653 within TLVs names Call Attributes TLVs. One or more Call 654 Attributes TLVs MAY be present in each object. 656 There are no ordering rules for Call Attributes TLVs, and no 657 interpretation SHOULD be placed on the order in which these 658 TLVs are received. 660 Each Call Attributes TLV carried by the CALL_ATTRIBUTES object 661 is encoded as follows: 663 0 1 2 3 664 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 665 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 666 | Type | Length | 667 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 668 | | 669 // Value // 670 | | 671 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 673 Type 675 The identifier of the TLV. 677 Length 679 Indicates the total length of the TLV in octets. That 680 is, the combined length of the Type, Length, and Value 681 fields, i.e., four plus the length of the Value field in 682 octets. 684 The entire TLV MUST be padded with between zero and three 685 trailing zeros to make it four-octet aligned. The Length 686 field does not count any padding. 688 Value 690 The data field for the TLV padded as described above. 692 Assignment of Call Attributes TLV types MUST follow the rules 693 specified in Section 8 (IANA Considerations). 695 5.1.4 Call Attributes Flags TLV 697 The Call Attributes TLV of Type 1 defines the Call Attributes 698 Flags TLV. The Call Attributes Flags TLV MAY be present in a 699 CALL_ATTRIBUTES object. 701 The Call Attribute Flags TLV value field is an array of units 702 of 32 flags numbered from the most significant bit as bit zero. 703 The Length field for this TLV MUST therefore always be a 704 multiple of 4 bytes, regardless of the number of bits carried 705 and no padding is required. 707 Unassigned bits are considered as reserved and MUST be set to 708 zero on transmission by the originator of the object. Bits not 709 contained in the Call Attribute Flags TLV MUST be assumed to be 710 set to zero. If the Call Attribute Flags TLV is absent either 711 because it is not contained in the CALL_ATTRIBUTES object or 712 because this object is itself absent, all processing MUST be 713 performed as though the bits were present and set to zero. In 714 other terms, assigned bits that are not present either because 715 the Call Attribute Flags TLV is deliberately foreshortened or 716 because the TLV is not included MUST be treated as though they 717 are present and are set to zero. 719 5.1.5 Call Inheritance Flag 721 This document introduces a specific Call Inheritance Flag at 722 position bit 0 (most significant bit) in the Attributes Flags 723 TLV. This flag indicates that the association initiated between 724 the end-points belonging to a call results into a (virtual) TE 725 link advertisement. 727 The Call Inheritance Flag MUST be set to 1 in order to indicate 728 that the established association is to be translated into a TE 729 link advertisement. The value of this flag SHALL by default be 730 set to 1. Setting this flag to 0 results in a hidden TE link or 731 in deleting the corresponding TE link advertisement (by setting 732 the corresponding Opaque LSA Age to MaxAge) if the association 733 had been established with this flag set to 1. In the latter 734 case, the corresponding FA-LSP SHOULD also be torn down to 735 prevent unused resources. 737 The Notify message used for establishing the association is 738 defined as per [RFC4974]. Additionally, the Notify message MUST 739 carry an LSP_TUNNEL_INTERFACE_ID Object, that allows 740 identifying unnumbered FA-LSPs ([RFC3477], [RFC4206], [HIER- 741 BIS]) and numbered FA-LSPs ([RFC4206], [HIER-BIS]). 743 5.2. Soft Forwarding Adjacency (Soft FA) 745 The Soft Forwarding Adjacency (Soft FA) approach consists of 746 setting up the FA LSP at the control plane level without 747 actually committing resources in the data plane. This means 748 that the corresponding LSP exists only in the control plane 749 domain. Once such FA is established the corresponding TE link 750 can be advertised following the procedures described in 751 [RFC4206]. 753 There are two techniques to setup Soft FAs: 755 o The first one consists in setting up the FA LSP by precluding 756 resource commitment during its establishment. These are known 757 as pre-planned LSPs. 759 o The second technique consists in making use of path 760 provisioned LSPs only. In this case, there is no associated 761 resource demand during the LSP establishment. This can be 762 considered as the RSVP-TE equivalent of the Null service type 763 specified in [RFC2997]. 765 5.2.1 Pre-Planned LSP Flag 767 The LSP ATTRIBUTES object and Attributes Flags TLV are defined 768 in [RFC5420]. The present document defines a new flag, the Pre- 769 Planned LSP flag, in the existing Attributes Flags TLV 770 (numbered as Type 1). 772 The position of this flag is TBD in accordance with IANA 773 assignment. This flag, part of the Attributes Flags TLV, 774 follows general processing of [RFC5420] for 775 LSP_REQUIRED_ATTRIBUTE object. That is, LSRs that do not 776 recognize the object reject the LSP setup effectively saying 777 that they do not support the attributes requested. Indeed, the 778 newly defined attribute requires examination at all transit 779 LSRs along the LSP being established. 781 The Pre-Planned LSP flag can take one of the following values: 783 o When set to 0 this means that the LSP MUST be fully 784 provisioned. Absence of this flag (hence corresponding TLV) 785 is therefore compliant with the signaling message processing 786 per [RFC3473]). 788 o When set to 1 this means that the LSP MUST be provisioned in 789 the control plane only. 791 If an LSP is established with the Pre-Planned flag set to 1, no 792 resources are committed at the data plane level. 794 The operation of committing data plane resources occurs by re- 795 signaling the same LSP with the Pre-Planned flag set to 0. It 796 is RECOMMENDED that no other modifications are made to other 797 RSVP objects during this operation. That is each intermediate 798 node, processing a flag transiting from 1 to 0 shall only be 799 concerned with the commitment of data plane resources and no 800 other modification of the LSP properties and/or attributes. 802 If an LSP is established with the Pre-Planned flag set to 0, it 803 MAY be re-signaled by setting the flag to 1. 805 5.2.2 Path Provisioned LSPs 807 There is a difference in between an LSP that is established 808 with 0 bandwidth (path provisioning) and an LSP that is 809 established with a certain bandwidth value not committed at the 810 data plane level (i.e. pre-planned LSP). 812 Mechanisms for provisioning (pre-planned or not) LSP with 0 813 bandwidth is straightforward for PSC LSP: in the SENDER_TSPEC/ 814 FLOWSPEC object, the Peak Data Rate field of Int-Serv objects 815 (see [RFC2210]) MUST be set to 0. For L2SC LSP: the CIR, EIR, 816 CBS, and EBS values MUST be set to 0 in the Type 2 sub-TLV of 817 the Ethernet Bandwidth Profile TLV. In both cases, upon LSP 818 resource commitment, actual traffic parameter values are used 819 to perform corresponding resource reservation. 821 However, mechanisms for provisioning (pre-planned or not) TDM 822 or LSC LSP with 0 bandwidth is currently not possible because 823 the exchanged label value is tightly coupled with resource 824 allocation during LSP signaling (see e.g. [RFC4606] for 825 SDH/SONET LSP). For TDM and LSC LSP, a NULL Label value is used 826 to prevent resource allocation at the data plane level. In 827 these cases, upon LSP resource commitment, actual label value 828 exchange is performed to commit allocation of timeslots/ 829 wavelengths. 831 6. Backward Compatibility 833 New objects and procedures defined in this document are running 834 within a given TE domain, defined as group of LSRs that 835 enforces a common TE policy. Thus, the extensions defined in 836 this document are expected to run in the context of a 837 consistent TE policy. Specification of a consistent TE policy 838 is outside the scope of this document. 840 In such TE domains, we distinguish between edge LSRs and 841 intermediate LSRs. Edge LSRs MUST be able to process Call 842 Attribute as defined in Section 5.1 if this is the method 843 selected for creating edge-to-edge associations. In that 844 domain, intermediate LSRs are by definition transparent to the 845 Call processing. 847 In case the Soft FA method is used for the creation of virtual 848 TE links, edge and intermediate LSRs MUST support processing of 849 the LSP ATTRIBUTE object per Section 5.2. 851 7. Security Considerations 853 This document does not introduce any new security consideration 854 from the ones already detailed in [MPLS-SEC] that describes the 855 MPLS and GMPLS security threats, the related defensive 856 techniques, and the mechanisms for detection and reporting. 857 Indeed, the applicability of the proposed GMPLS extensions is 858 limited to single TE domain. Such a domain is under the 859 authority of a single administrative entity. In this context, 860 multiple switching layers comprised within such TE domain are 861 under the control of a single GMPLS control plane instance. 863 Nevertheless, Call initiation, as depicted in Section 5.1, MUST 864 strictly remain under control of the TE domain administrator. 865 To prevent any abuse of Call setup, edge nodes MUST ensure 866 isolation of their call controller (i.e. the latter is not 867 reachable via external TE domains). To further prevent man-in- 868 the-middle attack, security associations MUST be established 869 between edge nodes initiating and terminating calls. For this 870 purpose, IKE [RFC4306] MUST be used for performing mutual 871 authentication and establishing and maintaining these security 872 associations. 874 8. IANA Considerations 876 8.1 RSVP 878 IANA has made the following assignments in the "Class Names, 879 Class Numbers, and Class Types" section of the "RSVP 880 PARAMETERS" registry located at 881 http://www.iana.org/assignments/rsvp-parameters. 883 This document introduces a new class named CALL_ATTRIBUTES has 884 been created in the 11bbbbbb range (201) with the following 885 definition: 887 Class Number Class Name Reference 888 ------------ ----------------------- --------- 889 201 CALL ATTRIBUTES [This I-D] 891 Class Type (C-Type): 893 1 Call Attributes [This.I-D] 895 Upon approval of this document, IANA is requested to establish 896 a "Call attributes TLV" registry. The following types should be 897 defined: 899 TLV Value Name Reference 900 --------- ------------------------- --------- 901 0 Reserved [This I-D] 902 1 Call Attributes Flags TLV [This I-D] 904 The values should be allocated based on the following 905 allocation policy as defined in [RFC5226]. 907 Range Registration Procedures 908 ----- ------------------------ 909 0-32767 RFC 910 32768-65535 Private Use 912 Upon approval of this document, IANA is requested to establish 913 a "Call attributes flags" registry. The following flags should 914 be defined: 916 Bit Number 32-bit Value Name Reference 917 ---------- ------------ --------------------- --------- 918 0 0x80000000 Call Inheritance Flag [This I-D] 920 The values should be allocated based on the RFC allocation 921 policy as defined in [RFC5226]. 923 This document introduces a new Flag in the Attributes Flags 924 TLV defined in [RFC5420]: 926 Bit Number 32-bit Value Name Reference 927 ---------- ------------ --------------------- --------- 928 TBD TBD Pre-Planned LSP Flag [This I-D] 930 This document introduces two new subobjects for the 931 EXCLUDE_ROUTE object [RFC4874], C-Type 1. 933 Subobject Type Subobject Description 934 -------------- --------------------- 935 3 Label 936 35 Switching Capability (SC) 938 8.2 OSPF 940 IANA maintains Open Shortest Path First (OSPF) Traffic 941 Engineering TLVs Registries included below for Top level Types 942 in TE LSAs and Types for sub-TLVs of TE Link TLV (Value 2). 944 This document defines the following sub-TLV of TE Link TLV 945 (Value 2) 947 Value Sub-TLV 948 ----- ------------------------------------------------- 949 25 Interface Adjustment Capability Descriptor (IACD) 951 8.3 IS-IS 953 This document defines the following new sub-TLV type of top- 954 level TLV 22 that need to be reflected in the ISIS sub-TLV 955 registry for TLV 22: 957 Type Description Length 958 ---- ------------------------------------------------- ------ 959 25 Interface Adjustment Capability Descriptor (IACD) Var. 961 9. References 963 9.1 Normative References 965 [IEEE] IEEE, "IEEE Standard for Binary Floating-Point 966 Arithmetic", Standard 754-1985, 1985. 968 [RFC2205] Braden, R., et al., "Resource ReSerVation Protocol 969 (RSVP) -- Version 1 Functional Specification", 970 RFC 2205, September 1997. 972 [RFC2210] Wroclawski, J., "The Use of RSVP with IETF 973 Integrated Services", RFC 2210, September 1997. 975 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 976 Requirement Levels", BCP 14, RFC 2119, March 1997. 978 [RFC2997] Bernet, Y., Smith, A., and B. Davie, "Specification 979 of the Null Service Type", RFC2997, November 2000. 981 [RFC3471] Berger, L., et al., "Generalized Multi-Protocol 982 Label Switching (GMPLS) - Signaling Functional 983 Description", RFC 3471, January 2003. 985 [RFC3473] Berger, L., "Generalized Multi-Protocol Label 986 Switching (GMPLS) Signaling Resource ReserVation 987 Protocol-Traffic Engineering (RSVP-TE) Extensions", 988 RFC 3473, January 2003. 990 [RFC3477] Kompella, K., and Y. Rekhter, "Signalling Unnumbered 991 Links in Resource ReSerVation Protocol - Traffic 992 Engineering (RSVP-TE)", RFC 3477, January 2003. 994 [RFC3630] Katz, D., et al., "Traffic Engineering (TE) 995 Extensions to OSPF Version 2," RFC 3630, September 996 2003. 998 [RFC3945] Mannie, E. and al., "Generalized Multi-Protocol 999 Label Switching (GMPLS) Architecture", RFC 3945, 1000 October 2004. 1002 [RFC4201] Kompella, K., et al., "Link Bundling in MPLS Traffic 1003 Engineering", RFC 4201, October 2005. 1005 [RFC4202] Kompella, K., Ed., and Rekhter, Y. Ed., "Routing 1006 Extensions in Support of Generalized MPLS", RFC 1007 4202, October 2005. 1009 [RFC4203] Kompella, K., Ed., and Y. Rekhter, Ed., "OSPF 1010 Extensions in Support of Generalized Multi-Protocol 1011 Label Switching (GMPLS)", RFC 4203, October 2005. 1013 [RFC4206] Kompella, K., and Rekhter, Y., "LSP Hierarchy with 1014 Generalized MPLS TE", RFC4206, October 2005. 1016 [RFC4306] Kaufman, C., Ed., "Internet Key Exchange (IKEv2) 1017 Protocol", RFC 4306, December 2005. 1019 [RFC4606] Mannie, E., and D. Papadimitriou, D., "Generalized 1020 Multi-Protocol Label Switching (GMPLS) Extensions 1021 for Synchronous Optical Network (SONET) and 1022 Synchronous Digital Hierarchy (SDH) Control, 1023 RFC 4606, August 2006. 1025 [RFC5226] Narten, T., Alvestrand, H., "Guidelines for Writing 1026 an IANA Considerations Section in RFCs", BCP 26, RFC 1027 5226, May 2008. 1029 [RFC5305] Smit, H. and T. Li, "Intermediate System to 1030 Intermediate System (IS-IS) Extensions for Traffic 1031 Engineering (TE)", RFC 5305, October 2008. 1033 [RFC5307] Kompella, K., Ed., and Y. Rekhter, Ed., 1034 "Intermediate System to Intermediate System (IS-IS) 1035 Extensions in Support of Generalized Multi-Protocol 1036 Label Switching (GMPLS)", RFC 5307, October 2005. 1038 [RFC5420] Farrel, A., et al., "Encoding of Attributes for 1039 Multiprotocol Label Switching (MPLS) Label Switched 1040 Path (LSP) Establishment Using Resource ReserVation 1041 Protocol-Traffic Engineering (RSVP-TE)", RFC 5420, 1042 February 2009. 1044 [RFC4874] Lee, C.Y., et al. "Exclude Routes - Extension to 1045 RSVP-TE," RFC 4874, April 2007. 1047 [RFC4974] Papadimitriou, D., and Farrel, A., "Generalized MPLS 1048 (GMPLS) RSVP-TE Signaling Extensions in support of 1049 Calls," RFC 4974, August 2007. 1051 9.2 Informative References 1053 [GMPLS-RR] Berger, L., Papadimitriou, D., and JP. Vasseur, 1054 "PathErr Message Triggered MPLS and GMPLS LSP 1055 Reroute", RFC 5710, January 2010. 1057 [HIER-BIS] Shiomoto, K., and Farrel, A., "Procedures for 1058 Dynamically Signaled Hierarchical Label Switched 1059 Paths", draft-ietf-ccamp-lsp-hierarchy-bis, Work in 1060 progress. 1062 [GR-TELINK] Ali, Z., et al., "Graceful Shutdown in MPLS and 1063 Generalized MPLS Traffic Engineering Networks", 1064 draft-ietf-ccamp-mpls-graceful-shutdown, Work in 1065 progress. 1067 [MPLS-SEC] Fang, L. Ed., "Security Framework for MPLS and 1068 GMPLS Networks", draft-ietf-mpls-mpls-and-gmpls- 1069 security-framework, Work in progress. 1071 [RFC5212] Shiomoto, K., et al., "Requirements for GMPLS-based 1072 multi-region and multi-layer networks (MRN/MLN)", 1073 RFC 5212, July 2008. 1075 [RFC5339] Leroux, J.-L., et al., "Evaluation of existing 1076 GMPLS Protocols against Multi Region and Multi 1077 Layer Networks (MRN/MLN)", RFC 5339, September 1078 2008. 1080 Acknowledgments 1082 The authors would like to thank Mr. Wataru Imajuku for the 1083 discussions on adjustment between regions. 1085 Author's Addresses 1087 Dimitri Papadimitriou 1088 Alcatel-Lucent 1089 Copernicuslaan 50 1090 B-2018 Antwerpen, Belgium 1091 Phone: +32 3 2408491 1092 Email: dimitri.papadimitriou@alcatel-lucent.com 1094 Martin Vigoureux 1095 Alcatel-Lucent 1096 Route de Villejust 1097 91620 Nozay, France 1098 Phone: +33 1 30772669 1099 Email: martin.vigoureux@alcatel-lucent.fr 1101 Kohei Shiomoto 1102 NTT 1103 3-9-11 Midori-cho 1104 Musashino-shi, Tokyo 180-8585, Japan 1105 Phone: +81 422 594402 1106 Email: shiomoto.kohei@lab.ntt.co.jp 1108 Deborah Brungard 1109 ATT 1110 Rm. D1-3C22 - 200 S. Laurel Ave. 1111 Middletown, NJ 07748, USA 1112 Phone: +1 732 4201573 1113 Email: dbrungard@att.com 1115 Jean-Louis Le Roux 1116 France Telecom 1117 Avenue Pierre Marzin 1118 22300 Lannion, France 1119 Phone: +33 2 96053020 1120 Email: jean-louis.leroux@rd.francetelecom.com 1122 Contributors 1124 Eiji Oki 1125 University of Electro-Communications 1126 1-5-1 Chofugaoka 1127 Chofu, Tokyo 182-8585, Japan 1128 Email: oki@ice.uec.ac.jp 1130 Ichiro Inoue 1131 NTT Network Service Systems Laboratories 1132 3-9-11 Midori-cho 1133 Musashino-shi, Tokyo 180-8585, Japan 1134 Phone : +81 422 596076 1135 Email: ichiro.inoue@lab.ntt.co.jp 1137 Emmanuel Dotaro 1138 Alcatel-Lucent France 1139 Route de Villejust 1140 91620 Nozay, France 1141 Phone : +33 1 69634723 1142 Email: emmanuel.dotaro@alcatel-lucent.fr 1144 Gert Grammel 1145 Alcatel-Lucent SEL 1146 Lorenzstrasse, 10 1147 70435 Stuttgart, Germany 1148 Email: gert.grammel@alcatel-lucent.de