idnits 2.17.1 draft-papadimitriou-ccamp-lmp-initiation-02.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == The page length should not exceed 58 lines per page, but there was 7 longer pages, the longest (page 2) being 59 lines 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([LMP]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (February 2003) is 7740 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) -- Looks like a reference, but probably isn't: '1' on line 17 -- Looks like a reference, but probably isn't: '2' on line 52 == Missing Reference: 'LMP-SONET-SDH' is mentioned on line 195, but not defined == Unused Reference: 'RFC-2026' is defined on line 300, but no explicit reference was found in the text == Unused Reference: 'RFC-2119' is defined on line 303, but no explicit reference was found in the text == Unused Reference: 'G.707' is defined on line 309, but no explicit reference was found in the text == Unused Reference: 'GMPLS-RTG' is defined on line 323, but no explicit reference was found in the text == Unused Reference: 'MPLS-BUND' is defined on line 341, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'G.707' == Outdated reference: A later version (-05) exists of draft-douville-ccamp-gmpls-waveband-extensions-03 -- Possible downref: Normative reference to a draft: ref. 'GMPLS-WB' == Outdated reference: A later version (-09) exists of draft-ietf-ccamp-gmpls-routing-05 == Outdated reference: A later version (-10) exists of draft-ietf-ccamp-lmp-07 -- Possible downref: Normative reference to a draft: ref. 'LMP-BOOT' == Outdated reference: A later version (-03) exists of draft-ietf-ccamp-lmp-wdm-01 == Outdated reference: A later version (-06) exists of draft-ietf-mpls-bundle-04 Summary: 6 errors (**), 0 flaws (~~), 12 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CCAMP Working Group Dimitri Papadimitriou 3 Internet Draft Jim Jones 4 Category: Standard Track Alcatel 6 Expiration Date: August 2003 February 2003 8 (FA-)LSP Initiation and Bundling 9 using Link Management Protocol (LMP) 11 draft-papadimitriou-ccamp-lmp-initiation-02.txt 13 Status of this Memo 15 This document is an Internet-Draft and is in full conformance with 16 all provisions of Section 10 of RFC2026 [1]. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. Internet-Drafts are draft documents valid for a maximum of 22 six months and may be updated, replaced, or obsoleted by other 23 documents at any time. It is inappropriate to use Internet- Drafts 24 as reference material or to cite them other than as "work in 25 progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 For potential updates to the above required-text see: 34 http://www.ietf.org/ietf/1id-guidelines.txt 36 1. Abstract 38 This memo is a companion document to Link Management Protocol (LMP), 39 for which it details the Forwarding Adjacency LSP (FA-LSP) 40 Initiation and Bundling process. [LMP] protocol is being developed 41 as part of the Generalized MPLS (GMPLS) protocol suite to control 42 and manage Traffic Engineering (TE) Links. The current document 43 extends the LMP capabilities to FA-LSPs enabling among other to 44 dynamically configure TE Links (in particular the LSP it can serve) 45 between non-adjacent LSRs. 47 2. Conventions used in this document 49 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 50 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 51 this document are to be interpreted as described in RFC-2119 [2]. 53 D.Papadimitriou Internet Draft - Expires August'03 1 54 3. Introduction 56 The Link Management Protocol [LMP] protocol has demonstrate its 57 value in automating Generalized MPLS (GMPLS) operations. This 58 protocol is being developed as part of the GMPLS protocol suite to 59 control and manage Traffic Engineering (TE) Links (aka link 60 bundles). LMP currently consists of four main functions, of which, 61 the first two are mandatory and the last two are optional (depending 62 on the capabilities provided by the transport plane): 64 1. Control channel management 65 2. Link property correlation 66 3. Link verification 67 4. Fault management 69 Control channel management is used to establish and maintain control 70 channel connectivity between adjacent nodes. As such, this function 71 enables the maintenance of the control plane adjacencies. This is 72 performed using a Config message exchange followed by a lightweight 73 keep-alive message exchange (a.k.a. Hello protocol). Link property 74 correlation is used to aggregate multiple data links into a single 75 TE Link and to synchronize their link properties. Link verification 76 is used to verify the physical connectivity of the data bearing 77 links and to exchange their identifiers (a.k.a discovery). Fault 78 management functions include alarm suppression and fault 79 localization in both opaque and transparent networks. 81 Note: control channel bootstrapping is described in [LMP-BOOT]. 83 4. FA-LSP Initiation and Bundling - Overview 85 In this document, we extend the LMP capabilities to enable 86 Forwarding Adjacency LSP (FA-LSP) initiation and bundling. The 87 usefulness of the proposed mechanism is illustrated by the following 88 multiple LSP Regions topology: 90 LSR(X) <--------------------- LMP ---------------------> LSR(Y) N+1 91 | | 92 | | 93 | | 94 LSR(X) <--LMP--> LSR(1) <--.. LMP ..--> LSR(M) <--LMP--> LSR(Y) N 96 Typically, LSR(1) to LSR(N) belongs to one LSP region (for instance, 97 LSC) and the LSPs established through these nodes crosses the LSP 98 region boundary at LSR(X) and LSR(Y) that belongs for instance to 99 the TDM region (see [MPLS-HIER]). When dealing with non-PSC layers 100 the LSP and TE Links are defined as the control plane mapping of the 101 transport plane paths and sections. Therefore, the LSP established 102 at region N appears as a TE link at region N+1 and are referred to 103 as a Forwarding Adjacency LSP (FA-LSP). 105 D.Papadimitriou - Internet Draft - Expires August'03 2 106 Note: such hierarchy is referred to as "hierarchical TE Link" when 107 the instance of the control plane having raised the LSP at layer N 108 is distinct from the one using this link to setup an LSP at layer 109 N+1. Corresponding considerations are outside out of the scope of 110 this document. 112 In this context, the main issues are on one hand related to the TE 113 Link identification and assignment performed at region N while only 114 its component links may be the object of an FA-LSP setup. Note also 115 that once these FA-LSPs are setup they appear at region N+1 with the 116 interface switching capability having raised these LSPs. For 117 instance, the triggering of an FA with TDM interface switching 118 capability is possible if both LSR(X) and LSR(Y) through the TE 119 Links they define with their neighboring nodes (i.e. LSR(1) and 120 LSR(M)) give access to an LSC switching capability region. Another 121 example is the initiation of FA's with LSC interface switching 122 capability through a Waveband LSP region as described in [GMPLS-WB]. 123 Moreover, when a FA-LSP is dynamically triggered the TE attributes 124 of its corresponding FA are inherited from the LSP, which induced 125 its creation. 127 On the other hand, the correlation of FAs having similar Traffic 128 Engineering (TE) attributes can induce the creation of an FA bundle 129 (here, in this example between LSR(X) and LSR(Y)) whose number of 130 components is at most as large as the number of components of the TE 131 Links defined between LSR(X) and LSR(1) and between LSR(M) and 132 LSR(Y), respectively. 134 Note: there is a similarity between this and the context where [LMP- 135 WDM] protocol is defined: LSR(X) and LSR(Y) corresponds to OXC and 136 LSR(1) to LSR(M) to Optical Line System (OLS); the only exception is 137 that in the latter case, one of the LMP neighbor is a non GMPLS- 138 capable node. 140 5. (FA-)LSP Initiation 142 (FA-)LSP initiation runs over an LMP adjacency and is invoked each 143 time an LSP is setup between a pair of ingress-egress LSRs belonging 144 to the same LSP region. To initiate an LMP adjacency between these 145 nodes at least one bi-directional control channel MUST be activated. 146 Once an LMP adjacency has been brought up, LMP session information 147 can start between the ingress-egress LSR pair. 149 The exact implementation of this control channel is not specified in 150 this document. It could be, for example, a dedicated wavelength, an 151 Ethernet link, or an IP tunnel defined between ingress LSR(1) and 152 egress LSR(M), or even the overhead bytes of a data-bearing link. 153 Rather, a node-wide unique 32-bit non-zero integer control channel 154 identifier (CCId) is assigned at each end of the control channel. 155 This identifier comes from the same space as the unnumbered 156 interface Id. 158 D.Papadimitriou - Internet Draft - Expires August'03 3 159 The control channel defined between LSR(X) and LSR(Y) is either 160 permanently maintained (in this case the control channel is 161 explicitly configured) or established on-demand (in this case the 162 control channel is dynamically configured and selected). As 163 described in [LMP] (see Section 3), once a control channel is 164 activated between two nodes, the LMP Hello protocol (see [LMP] 165 Section 3.2) can be used to maintain control channel connectivity 166 between the nodes and to detect control channel failures. This Hello 167 exchange is intended to be a lightweight keep-alive mechanism that 168 will react to control channel failures rapidly. Note that 169 subsequently this control channel can be used for signalling message 170 exchange between LSR(X) and LSR(Y) while routing channels are vy 171 definition kept separated. 173 Therefore, FA-LSP initiation can be invoked only after control 174 channel setup completion between LSR(X) and LSR(Y) but also between 175 LSR(X) and LSR(1) at the head-end (ingress) and between LSR(N) and 176 LSR(Y) at the tail-end (egress). Note that the LSR(X) to LSR(Y) LMP 177 session can use the same transport medium as the ingress and egress 178 LMP sessions (these sessions may be used as entry point). This 179 procedure consists of a sequence of LMP message exchanges between 180 the ingress LSR(X) and egress LSR(Y) prior to the LSP establishment 181 between these end-points. Consequently, when used, the FA-LSP 182 initiation MUST be performed before the corresponding LSP is 183 established. 185 Once the FA-LSP has been initiated, it can be established and the 186 created entity (i.e. the FA) used for path computation purposes by 187 the upper LSP region as any other TE Link belonging to this region 188 (see [MPLS-HIER]). 190 6. FA-LSP Verification 192 After the FA-LSP establishment (see [RFC-3471] and [MPLS-HIER]), 193 verification of the newly created Lambda LSP can be performed at any 194 time the FA-LSP is not in the property correlation process (see 195 Section 6). This verification can be performed either using [LMP- 196 SONET-SDH] in case of TDM FA-LSP and [LMP] in case of non TDM FA- 197 LSP. 199 Note that verification can only be performed on already initiated 200 and established FA-LSPs. 202 7. FA-LSP Bundling 204 The messages defined in [LMP] for Link Property Correlation are used 205 for FA-LSP bundling purposes: LinkSummary (MsgType = 14), 206 LinkSummaryAck (MsgType = 15) and LinkSummaryNack (MsgType = 16). 208 The contents of these messages are built using existing (see [LMP] 209 Section 13) and additional LMP sub-objects, which can be either 210 negotiable or non-negotiable. Here, negotiable objects are used to 211 let both sides agree on the acceptance of certain parameters for the 213 D.Papadimitriou - Internet Draft - Expires August'03 4 214 requested LSP. Non-negotiable objects are used for announcement of 215 specific values that do not need, or do not allow, negotiation. 217 These messages are exchanged between the ingress and the egress LSR 218 (through the control channel) and used as follows. When the ingress 219 LSR has established an FA-LSP and wants to add/remove this FA-LSP 220 from an existing bundle of FA-LSPs, it sends a LinkSummary message 221 to the egress LSR indicating its local TE Link and data bearing link 222 information (including status and availability) while requesting the 223 corresponding information from the remote side. Since the ingress 224 LSR can be aware of the remote node TE Link and data bearing link 225 information, this request MAY include the remote side information. 227 The LinkSummary message can also be used to aggregate simultaneously 228 multiple established FA-LSP into a bundle of FA-LSPs. In addition to 229 add/remove a FA-LSP from an existing bundle of FA-LSPs, it can also 230 change the FA-LSPs correlation parameters. 232 Remember here that each TE Link has an identifier (TE Link_Id) that 233 is assigned at each end of the TE Link (local and remote Link Id). 234 These identifiers MUST be the same type (i.e. IPv4, IPv6, 235 unnumbered) at both ends. Similarly, each component interface is 236 assigned an identifier (Interface_Id) at each end. These identifiers 237 MUST be of the same type at both ends. Interface Id values MUST be 238 taken from the space used for local LMP sessions. 240 If the LinkSummary message is received from a remote node and the 241 Interface Id mappings match those that are stored locally, then the 242 two nodes have agreement on Interface Id and TE Link Id if these are 243 known by the ingress. 245 The LinkSummaryAck message is used to signal an agreement (including 246 availability and status) on ALL the parameters both negotiable and 247 non-negotiable received in the LinkSummaryAck message. This 248 agreement includes the Interface Id mapping and data-bearing link 249 correlation properties in addition to the TE Link Id mapping if 250 known by the ingress LSR. Moreover, when sending such a message, the 251 receiver's data links support the capabilities listed in the 252 LinkSummary message. 254 Otherwise, a LinkSummaryNack message MUST be sent as response to 255 indicated which Interface Id mappings are not correct and/or which 256 data bearing link properties are not accepted. If a LinkSummaryNack 257 message indicates that the Interface Id mappings are not correct it 258 means that an error from a previous information has occurred (such 259 issues are outside of the scope of this document). If a 260 LinkSummaryNack message includes negotiable parameters, then 261 acceptable values for those parameters MUST be included. If a 262 LinkSummaryNack message is received and includes negotiable 263 parameters, then the initiator of the LinkSummary message MUST send 264 a new LinkSummary message that SHOULD include new values for the 265 negotiable parameters. These values SHOULD take into account the 266 acceptable values received in the LinkSummaryNack message. 268 D.Papadimitriou - Internet Draft - Expires August'03 5 269 Last, the following data structures are maintained at the ingress 270 (LSP initiator) and the egress (LSP receptor or destinator) LSR: 272 - Retransmission Timer, r: This configurable timer is set by a node 273 sending a LinkSummary message. The timer is reset if an 274 LinkSummaryAck or LinkSummaryNack message is received for this 275 message. The expiry of this timer results in the retransmission of 276 the LinkSummary message. The default value of this timer is 1 277 second. 279 - Number of Retransmissions, n: This configurable parameter 280 indicates the maximum number of allowed retransmissions of 281 LinkSummary messages. The default value of this number is 3. A 282 node considers the LSP Initiation procedure to have failed if a 283 response is not received from the peer after n retransmission 284 attempts. 286 Note: if the ingress LSR i.e. the LSP initiator, receives more than 287 one LinkSummaryAck/Nack after having issued a second (or subsequent) 288 LinkSummary message after retransmission timer expiration, only the 289 last LinkSummaryAck/Nack message is considered by the initiator. 291 8. Security Considerations 293 LMP provides authentication on a per IP Control Channel basis. The 294 packet authentication procedure is very similar to the one used in 295 OSPF, including multiple key support, key management, etc. The 296 details specific to LMP are defined in [LMP] Section 13.3. 298 9. References 300 [RFC-2026] Bradner, S., "The Internet Standards Process -- 301 Revision 3", BCP 9, RFC 2026, October 1996. 303 [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate 304 Requirement Levels", BCP 14, RFC 2119, March 1997. 306 [RFC-3471] Berger, L. et al, "Generalized MPLS - Signaling 307 functional description," IETF RFC 3471, February 2003. 309 [G.707] ITU-T G.707, "Network node interface for the 310 synchronous digital hierarchy (SDH)," March 1996. 312 [GR.253] GR-253-CORE, "Synchronous Optical Network (SONET) 313 Transport Systems: Common Generic Criteria," Telcordia 314 Technologies, Issue 3, September 2000. 316 [GMPLS-WB] Douville, R., et al. "Extensions to Generalized MPLS in 317 support of Waveband Switching", Internet Draft, Work in 318 Progress, draft-douville-ccamp-gmpls-waveband- 319 extensions-03.txt, February 2003. 321 D.Papadimitriou - Internet Draft - Expires August'03 6 323 [GMPLS-RTG] Kompella, K., et al, "Routing Extensions in Support of 324 Generalized MPLS," Internet Draft, Work in Progress, 325 draft-ietf-ccamp-gmpls-routing-05.txt, May 2002. 327 [LMP] Lang, J.P. (Editor), et al, "Link Management Protocol," 328 Internet Draft (work in progress), draft-ietf-ccamp- 329 lmp-07.txt, October 2002. 331 [LMP-BOOT] Lang, J.P., Drake, J. and Papadimitriou, D., "Control 332 Channel Bootstrap for LMP," Internet Draft (work in 333 progres), draft-lang-ccamp-lmp-bootstrap-03.txt, 334 February 2003. 336 [LMP-WDM] Fredette, A., Lang, J. P., (Editors), "Link Management 337 Protocol (LMP) for DWDM Optical Line Systems," Internet 338 Draft (work in progress), draft-ietf-ccamp-lmp-wdm- 339 01.txt, November 2002. 341 [MPLS-BUND] Kompella, K. et al., "Link Bundling in MPLS Traffic 342 Engineering," Internet Draft (work in progress), draft- 343 ietf-mpls-bundle-04.txt, August 2002. 345 [MPLS-HIER] Kompella, K. and Rekhter, Y., "LSP Hierarchy with 346 Generalized MPLS TE," Internet Draft (work in progress, 347 draft-ietf-mpls-lsp-hierarchy-08.txt, September 2002. 349 10. Acknowledgments 351 The authors would like to thank Bernard Sales, Emmanuel Desmet, Gert 352 Grammel, Mike Sexton and John Drake for their constructive comments 353 and inputs. 355 11. Author's Addresses 357 Dimitri Papadimitriou (Alcatel) 358 Francis Wellesplein, 1 359 B-2018 Antwerpen, Belgium 360 Phone: +32 3 240 8491 361 Email: dimitri.papadimitriou@alcatel.be 363 Jim Jones (Alcatel) 364 3400 W. Plano Parkway, 365 Plano, TX 75075, USA 366 Phone: +1 972 519-2744 367 Email: jim.d.jones1@usa.alcatel.com 369 D.Papadimitriou - Internet Draft - Expires August'03 7 370 12. Full Copyright Statement 372 "Copyright (C) The Internet Society (date). All Rights Reserved. 374 This document and translations of it may be copied and furnished to 375 others, and derivative works that comment on or otherwise explain it 376 or assist in its implementation may be prepared, copied, published 377 and distributed, in whole or in part, without restriction of any 378 kind, provided that the above copyright notice and this paragraph 379 are included on all such copies and derivative works. However, this 380 document itself may not be modified in any way, such as by removing 381 the copyright notice or references to the Internet Society or other 382 Internet organizations, except as needed for the purpose of 383 developing Internet standards in which case the procedures for 384 copyrights defined in the Internet Standards process must be 385 followed, or as required to translate it into languages other than 386 English. 388 The limited permissions granted above are perpetual and will not be 389 revoked by the Internet Society or its successors or assigns. 391 This document and the information contained herein is provided on an 392 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 393 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 394 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 395 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 396 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 398 D.Papadimitriou - Internet Draft - Expires August'03 8