idnits 2.17.1 draft-chen-mpls-tp-bidir-lsp-association-00.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 date (July 5, 2010) is 5037 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) == Unused Reference: 'RFC5226' is defined on line 407, but no explicit reference was found in the text ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) == Outdated reference: A later version (-07) exists of draft-ietf-mpls-tp-identifiers-01 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network working group M. Chen 2 Internet Draft J. Dong 3 Intended status: Standards Track X. Guo 4 Expires: January 2011 Huawei Technologies 5 July 5, 2010 7 GACH Based Bidirectional LSP Association 9 draft-chen-mpls-tp-bidir-lsp-association-00.txt 11 Abstract 13 This document defines a mechanism to bind two unidirectional LSPs 14 into an associated bidirectional LSP and perform related operations, 15 including update, withdrawal and verification of the association 16 without a control plane. This is achieved using Generic Associated 17 Channel. 19 Status of this Memo 21 This Internet-Draft is submitted to IETF in full conformance with 22 the provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as Internet- 27 Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six 30 months and may be updated, replaced, or obsoleted by other documents 31 at any time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt. 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html. 40 This Internet-Draft will expire on January 5, 2011. 42 Copyright Notice 44 Copyright (c) 2010 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with 52 respect to this document. Code Components extracted from this 53 document must include Simplified BSD License text as described in 54 Section 4.e of the Trust Legal Provisions and are provided without 55 warranty as described in the Simplified BSD License. 57 Conventions used in this document 59 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 60 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 61 document are to be interpreted as described in RFC-2119 [RFC2119]. 63 Table of Contents 65 1. Introduction.................................................2 66 2. GACH based Path Association..................................3 67 3. Operation....................................................6 68 3.1. Binding of Two Unidirectional LSPs......................6 69 3.2. Binding Relationship Verification.......................7 70 3.3. Binding Update/Withdrawal...............................8 71 3.4. Association on Intermediate Nodes.......................8 72 4. Security Considerations......................................9 73 5. IANA Considerations..........................................9 74 6. Contributors................................................10 75 7. Acknowledgments.............................................10 76 8. References..................................................10 77 8.1. Normative References...................................10 78 8.2. Informative References.................................10 79 Authors' Addresses.............................................11 81 1. Introduction 83 Based on the definition of associated bidirectional path in MPLS-TP 84 Requirement [RFC5654], an associated bidirectional path comprises a 85 pair of unidirectional paths which are setup, monitored, and 86 protected independently and are associated with one another at the 87 path's ingress/egress points. 89 [RFC5654] specifies the requirements about associated bidirectional 90 paths in requirement 7, 11, 12: MPLS-TP MUST support associated 91 bidirectional point-to-point transport paths, the end points of an 92 associated bidirectional path MUST be aware of the pairing 93 relationship of the forward and reverse paths, and intermediate 94 nodes on the path which are transited by both the forward and 95 backward directions SHOULD be aware of the pairing relationship of 96 the forward and the backward directions of the associated 97 bidirectional path. 99 GMPLS based signaling [RFC4974] [RFC4872] [HIERACHY-BIS] may be used 100 (directly or with some extensions) to achieve the association of two 101 unidirectional LSPs. 103 Since MPLS-TP MUST support the capability for network operation 104 without the use of control plane, a method to bind the forward and 105 backward unidirectional paths into an associated bidirectional path 106 in the absence of control plane may be desired. 108 Normally the binding of two unidirectional paths occurs when there 109 are established unidirectional paths in each direction and an 110 associated bidirectional path is needed to provide some kind of 111 service. After the binding of the two unidirectional paths, there 112 MAY be requirement to verify the binding relationship during the 113 lifetime of the associated bidirectional path. In addition, the 114 operator MAY need to update or withdraw the previous binding of the 115 two unidirectional LSPs. 117 2. GACH based Path Association 119 This document provides a GACH [RFC5586] based method to achieve the 120 binding of two unidirectional LSPs. A new channel type (TBA) called 121 Path Binding is defined for this purpose. Format of the Path Binding 122 message is as below: 124 0 1 2 3 125 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 126 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 127 |0 0 0 1|Version| Reserved | Channel Type (TBA) | 128 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 129 | ACH TLV Header | 130 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 131 | | 132 ~ ACH TLVs ~ 133 | | 134 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 135 | Message Type |U|V| Flags | Return Code | 136 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 137 | Sequence Number | 138 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 139 ~ TLVs ~ 140 | | 141 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 143 The Message Type is one of the following: 145 Value Meaning 147 ----- ------- 149 1 Request 151 2 Response 153 The Flags field is an 8-bit vector. 155 The U (Update) flag indicates this message is used to update or 156 withdraw previous binding relationship. 158 The V (Verification) flag indicates this message is used to verify 159 the binding relationship. 161 The other undefined flags are set to zero on transmission and 162 ignored on reception. 164 The Return Code is only applicable in Response message, and is set 165 to zero in Request message. The receiver of the Request message uses 166 this field to carry information about the binding result back to the 167 initiator. This document defines some return codes as follows. 168 Additional return codes can be defined if needed. 170 Value Meaning 172 ----- ------- 174 0 Operation success 176 1 Malformed message received 178 2 Binding not accepted 180 3 Binding inconsistency 182 4 Update/Withdrawal not accepted 184 The Sequence Number is assigned by the sender of the Request message 185 and returned unchanged by the receiver in the Response message. It 186 can be used to matching up requests with responses. 188 This document defines IPv4/IPv6 Bidirectional LSP ID TLVs. The 189 proposed format is as follows: 191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 192 | IPv4 Bi-dir. LSP ID TLV | Length | 193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 194 | Source Global ID | 195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 196 | Source Node ID | 197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 198 | Source Tunnel Number | Source LSP Number | 199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 200 | Destination Global ID | 201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 202 | Destination Node ID | 203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 204 | Destination Tunnel Number | Destination LSP Number | 205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 207 | IPv6 Bi-dir. LSP ID TLV | Length | 208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 209 | Source Global ID | 210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 211 ~ Source Node ID ~ 212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 213 | Source Tunnel Number | Source LSP Number | 214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 215 | Destination Global ID | 216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 217 ~ Destination Node ID ~ 218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 219 | Destination Tunnel Number | Destination LSP Number | 220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 222 The definition of Global ID, Node ID, Tunnel Number and LSP Number 223 are specified in [TP-IDENTIFIER]. They are used to identify the 224 unidirectional LSP in each direction and in combination to identify 225 the associated bidirectional LSP. In order to identify the 226 unidirectional LSP in the reverse direction, a Destination LSP 227 Number field is also needed. 229 The source ID fields, i.e. the Source Global ID, Source Node ID, 230 Source Tunnel Number and Source LSP Number MUST be filled in by the 231 local LER with information of the forward LSP. 233 According to different situations, the destination IDs MAY be 234 explicitly specified by the initiating LER, or be set to zero when 235 do not know which reverse LSP to be bound. Detailed procedures are 236 specified in next section. 238 3. Operation 240 3.1. Binding of Two Unidirectional LSPs 242 One of the LERs initiates the request for the path association by 243 sending a Path Binding Request to the remote LER with flag U and V 244 cleared. The initiating LER SHOULD fill the Bidirectional LSP ID TLV 245 with the IDs of the two unidirectional LSPs to be bound The request 246 message is sent along the forward LSP with the GACH encapsulation. 248 On receipt of a Path Binding Request message, the receiving LER 249 SHOULD check the IDs of the two LSPs to determine if the binding 250 request is acceptable based on local policy and other information. 252 If the binding is accepted, it SHOULD send a Path Binding Response 253 message to the initiating LER with flag U and V cleared and the 254 return code set to 0 (Operation success). If the specified reverse 255 LSP does not exist, or the binding is not acceptable based on its 256 local policy, the receiving LER SHOULD send a Response message with 257 return code 2 (Binding not accepted). The Bidirectional LSP ID TLV 258 MAY be copied from the Request message to the Response message. 260 In some scenarios both LERs MAY send Path Binding Request messages 261 to each other independently, flag U and V MUST be cleared. On 262 receipt of the Path Binding Request message, both LERs SHOULD check 263 the Bidirectional LSP ID TLV of the message. If the binding 264 information in both requests are the same, then the binding is 265 successfully finished, and Response messages SHOULD be sent to 266 remote LER with flag U and V cleared and the return code set to 0 267 (Operation success). If the binding information in one Request 268 message differs from the information in the other Request message, 269 the LER with greater Node ID SHOULD discard the received Request 270 message and MAY send a Response with return code set to 2 (Binding 271 not accepted). Based on local policy and other information, The LER 272 with smaller Node ID SHOULD determine to accept or reject the 273 binding request. If the binding is accepted, the receiving LER 274 SHOULD send a Path Binding Response message with flag U and V 275 cleared and the return code set to 0 (Operation success). Otherwise, 276 the receiving LER SHOULD send a Response message with return code 2 277 (Binding not accepted). The Bidirectional LSP ID TLV MAY be copied 278 from the Request message to the Response message. 280 3.2. Binding Relationship Verification 282 After binding the two unidirectional LSP into an associated 283 bidirectional LSP, there MAY be requirement to check the binding 284 relationship, since some configuration errors may change the binding 285 relationship on some nodes. This is achieved using the path binding 286 message. One of the LER SHOULD send a path binding message with 287 message type set to "Request" and the V flag set. The Bidirectional 288 LSP ID TLV specifies the associated bidirectional LSP to be verified. 290 On receipt of the binding Request message with V flag set, the 291 remote LER SHOULD check if the binding relationship in the message 292 is consistent with the local binding relationship. If the binding 293 relationship is consistent, the remote LER SHOULD sent a Response 294 message with V flag set, and the return code set to 0. If there is 295 any inconsistency between the local binding information and the 296 information in the received message, it SHOULD sent a Response 297 message with V flag set, and the return code set to 3 (Binding 298 inconsistency). The Bidirectional LSP ID TLV MAY be copied from the 299 Request message to the Response message. 301 3.3. Binding Update/Withdrawal 303 When the operator needs to update or withdraw the binding of two 304 unidirectional LSPs, one of the LERs SHOULD send a path binding 305 message with the message type set to "Request", and the U flag MUST 306 be set. If it is to update the binding of forward LSP with another 307 backward LSP, then the Destination ID fields SHOULD be filled with 308 IDs of the new reverse LSP to be bound. If it is to withdraw the 309 current binding, the destination ID fields SHOULD be set to zero. 311 On receipt of the update/withdraw Request message, if the new 312 binding or the withdrawal is accepted, the remote LER SHOULD update 313 local binding relationship, and send a Response message with the U 314 flag set and the return code set to 0. Otherwise it SHOULD send a 315 response message with the U flag set and the return code set to 4 316 (Update/Withdrawal not accepted). The Bidirectional LSP ID TLV MAY 317 be copied from the Request message to the Response message. 319 3.4. Association on Intermediate Nodes 321 [RFC5654] specifies that the intermediate nodes traversed by both 322 the forward and backward directions of the associated bidirectional 323 LSP SHOULD be aware of the pairing relationship. 325 In some scenarios the edge nodes may have knowledge of the 326 intermediate nodes traversed by both directions of the associated 327 bidirectional LSP. In this case, after the successful LSP binding on 328 the two edge nodes, the LER with greater Node ID SHOULD send Path 329 Binding Request messages with flag U and V cleared to each 330 intermediate node traversed by both directions. This is achieved by 331 setting the TTL of the topmost label to hop value to the specific 332 intermediate node. The Bidirectional LSP ID TLV MUST be filled with 333 IDs of the forward and backward LSP. 335 On receipt of this message, the intermediate nodes SHOULD interpret 336 this as a path binding notification, since it is not the edge node 337 of the LSPs identified in the Bidirectional LSP ID TLV. Then it 338 SHOULD check if it is on both directions of the associated LSP, if 339 so it SHOULD create the association relationship of the two 340 unidirectional LSPs, if not it SHOULD silently discard the received 341 message. No response is needed from the intermediate node to the 342 initiating node. 344 In scenarios where the edge nodes do not know the intermediate nodes 345 traversed by both directions of the associated bidirectional LSP, 346 the LER with greater Node ID SHOULD form a Path Binding Request 347 message with the flag U and V cleared. The Bidirectional LSP ID TLV 348 MUST be filled with IDs of the forward and backward LSP. Then the 349 Route Alert Label (label value 1) SHOULD be encapsulated as the 350 topmost label. In this way, each intermediate node will process the 351 message locally and send it further along the path. According to the 352 Bidirectional LSP ID TLV in the message, intermediate nodes which 353 are traversed by both directions will create the association 354 relationship, and nodes not on both directions will not perform the 355 association. 357 4. Security Considerations 359 This document does not change the security properties of MPLS-TP. 361 Spurious path binding messages may be used to perform attacks. 362 However, since these messages are carried in a control channel, one 363 would have to gain access to the nodes providing the service to 364 initiate such attack, which makes the threats less likely. To 365 protect against such attack the Authentication TLV MAY be carried in 366 the ACH TLV field. 368 5. IANA Considerations 370 IANA is requested to make the following allocations from registries 371 under its control. 373 A new ACH Channel Type is defined in this document. 375 Channel Type Description 377 ------------ -------------------- 379 TBA Path Binding message 381 Two TLVs are defined for Path Binding message: 383 Type Description 385 ---- ------------------- 387 1 IPv4 Bi-dir. LSP ID TLV 388 2 Ipv6 Bi-dir. LSP ID TLV 390 6. Contributors 392 Li Xue 394 xueli@huawei.com 396 7. Acknowledgments 398 The authors would like to thank ... for their valuable comments. 400 8. References 402 8.1. Normative References 404 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 405 Requirement Levels", BCP 14, RFC 2119, March 1997. 407 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 408 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 409 May 2008. 411 [RFC5586] Bocci, M., Vigoureux, M. and Bryant, S., "MPLS Generic 412 Associated Channel", RFC 5586, June 2009. 414 [RFC5654] Niven-Jenkins, B., Brungard, D., Betts, M. et al., 415 "Requirements of an MPLS Transport Profile", RFC 5654, 416 September 2009. 418 [TP-IDENTIFIER] Bocci, M., Swallow, G., "MPLS-TP Identifiers", 419 draft-ietf-mpls-tp-identifiers-01 (work in progress), 420 March 2010. 422 8.2. Informative References 424 [RFC4872] Lang, J., Rekhter, Y., and Papadimitriou, D., "RSVP-TE 425 Extensions in Support of End-to-End Generalized Multi- 426 Protocol Label Switching (GMPLS) Recovery", RFC 4872, May 427 2007. 429 [RFC4974] Papadimitriou, D., Farrel, A., "Generalized MPLS (GMPLS) 430 RSVP-TE Signaling Extensions in Support of Calls", RFC 431 4974, August 2007. 433 [HIERACHY-BIS] Shiomoto, K, Ed., Farrel, A, Ed., "Procedures for 434 Dynamically Signaled Hierarchical Label Switched Paths", 435 work in progress, draft-ietf-ccamp-lsp-hierarchy-bis. 437 Authors' Addresses 439 Mach(Guoyi) Chen 440 Huawei Technologies Co.,Ltd. 441 Huawei Building, No.3 Xinxi Rd., 442 Hai-Dian District 443 Beijing, 100085 444 P.R. China 446 EMail: mach@huawei.com 448 Jie Dong 449 Huawei Technologies Co.,Ltd. 450 Huawei Building, No.3 Xinxi Rd., 451 Hai-Dian District 452 Beijing, 100085 453 P.R. China 455 EMail: dongjie_dj@huawei.com 457 Xinchun Guo 458 Huawei Technologies Co.,Ltd. 459 Huawei Building, No.3 Xinxi Rd., 460 Hai-Dian District 461 Beijing, 100085 462 P.R. China 464 Email: guoxinchun@huawei.com