idnits 2.17.00 (12 Aug 2021) /tmp/idnits30694/draft-zhang-ccamp-rsvp-te-mpls-tp-tcm-config-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 : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 4, 2010) is 4332 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: 'RFC3945' is defined on line 383, but no explicit reference was found in the text == Unused Reference: 'RFC3471' is defined on line 393, but no explicit reference was found in the text == Unused Reference: 'RFC3473' is defined on line 397, but no explicit reference was found in the text == Outdated reference: draft-ietf-mpls-tp-framework has been published as RFC 5921 ** Downref: Normative reference to an Informational draft: draft-ietf-mpls-tp-framework (ref. 'TP-FRWK') == Outdated reference: draft-ietf-mpls-tp-oam-framework has been published as RFC 6371 ** Downref: Normative reference to an Informational draft: draft-ietf-mpls-tp-oam-framework (ref. 'TP-OAM') == Outdated reference: draft-ietf-ccamp-mpls-tp-cp-framework has been published as RFC 6373 ** Downref: Normative reference to an Informational draft: draft-ietf-ccamp-mpls-tp-cp-framework (ref. 'TP-CP-FRWK') == Outdated reference: draft-ietf-ccamp-oam-configuration-fwk has been published as RFC 7260 Summary: 4 errors (**), 0 flaws (~~), 8 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Fatai Zhang 2 Internet Draft Yi Lin 3 Category: Standards Track Huawei 5 Expires: January 2011 July 4, 2010 7 RSVP-TE extensions for TCM configuration in MPLS-TP network 9 draft-zhang-ccamp-rsvp-te-mpls-tp-tcm-config-00.txt 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with 14 the provisions of BCP 78 and BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on January 4, 2011. 34 Abstract 36 This specification describes the requirements of Tandem Connection 37 Monitoring (TCM) configuration via GMPLS control plane in MPLS-TP 38 network and provides the procedure of creating TCM path segment 39 tunnel on a transport path to meet the requirements of TCM 40 configuration. 42 Conventions used in this document 44 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 45 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 46 document are to be interpreted as described in [RFC2119]. 48 Table of Contents 50 1. Introduction..................................................2 51 2. Terminology...................................................3 52 3. Requirements of TCM Configuration.............................3 53 3.1. Introduction of TCM Path Segment Tunnel..................3 54 3.2. Requirements of TCM Configuration Using RSVP-TE..........4 55 4. Procedure of TCM Configuration................................5 56 4.1. Path Segment Tunnel Creation.............................6 57 4.2. LSP Rerouting in control plane...........................7 58 4.3. OAM Configuration........................................7 59 5. RSVP-TE Extension.............................................7 60 5.1. TCM_CONFIGURATION object in PATH message.................8 61 5.2. TCM_CONFIGURATION object in RESV message.................9 62 6. Security Considerations.......................................9 63 7. IANA Considerations...........................................9 64 8. Acknowledgments...............................................9 65 9. References....................................................9 66 10. Authors' Addresses..........................................10 68 1. Introduction 70 The MPLS Transport Profile (MPLS-TP) is being developed by ITU-T and 71 IETF. The MPLS-TP data plane framework and requirements are described 72 in [TP-FRWK] and [RFC5654], and the [TP-CP-FRWK] provides the 73 framework to support dynamic provisioning of MPLS-TP transport paths 74 via control plane. 76 The MPLS-TP Operations, Administration and Maintenance (OAM), which 77 is defined in [TP-OAM], is one of the most important and fundamental 78 functionalities in MPLS-TP. The OAM functionality is not only applied 79 on a transport path granularity, but also applied on arbitrary parts 80 of the transport path, defined as Tandem Connections. For the latter 81 case, a Tandem Connection Monitoring (TCM) is implemented by creating 82 a path segment tunnel that has a 1:1 association with the path 83 segment of the transport path that is to be uniquely monitored. 84 Therefore, the LSP is nested into the TCM path segment tunnel. 86 In case of TCM configuration using GMPLS control plane, the TCM path 87 segment tunnel needs to be created on an in-service LSP, which is not 88 supported in the current GMPLS RSVP-TE signaling. 90 This document provides the procedure of creating such outer layer 91 path segment tunnel on a transport path via control plane to meet the 92 requirement of automatic TCM configuration. 94 2. Terminology 96 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 97 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 98 document are to be interpreted as described in [RFC2119]. 100 3. Requirements of TCM Configuration 102 3.1. Introduction of TCM Path Segment Tunnel 104 This sub-section is informational which introduces the TCM and LSP 105 Path Segment Tunnel Monitoring in the MPLS-TP data plane. 107 As described in [TP-OAM], TCM is implemented by LSP Path Segment 108 Tunnel Monitoring which can be deployed to monitor the behavior of a 109 part of an LSP. 111 |<---------------------- LSP ---------------------->| 112 | | 113 | |<-- Path Segment Tunnel -->| | 114 | | | | 115 +-----------+===========================+-----------+ 116 +-----------+===========================+-----------+ 117 +-----+ +-----+ +-----+ +-----+ +-----+ 118 | | | | | | | | | | 119 | A +------| B +------+ C +------+ D +------+ E | 120 | | | | | | | | | | 121 +-----+ +-----+ +-----+ +-----+ +-----+ 122 -------> -------> -------> -------> 123 +--+----+ +--+--+----+ +--+--+----+ +--+----+ 124 Data: |L1|Data| |L5|L3|Data| |L6|L3|Data| |L4|Data| 125 +--+----+ +--+--+----+ +--+--+----+ +--+----+ 126 +--+--+----+ +--+--+----+ 127 OAM packets: |L5|13|OAM | |L6|13|OAM | 128 +--+--+----+ +--+--+----+ 130 Figure 1 - Example of Path Segment Monitoring 132 Figure 1 shows an example of TCM. Assume that there is an LSP passing 133 through node A, B, C, D and E. A path segment tunnel between node B 134 and D will be created when the operator wants to configure a TCM to 135 monitor this path segment. The path segment tunnel has a 1:1 136 association with the LSP which is nested into this tunnel. In other 137 words, the label stacking is performed between B and D, where the 138 inner layer label is corresponded with the LSP and the outer layer 139 label is corresponded with the tunnel. 141 Since the data packets of the LSP and the OAM packets for path 142 segment monitoring are using the same outer layer labels (i.e., the 143 tunnel labels), the LSP and the OAM session can be associated. 145 3.2. Requirements of TCM Configuration Using RSVP-TE 147 In most cases, the path segment tunnel for TCM is created when the 148 LSP is in service. When the network operator wants to monitor a 149 certain part of the LSP, a path segment tunnel needs to be set up by 150 RSVP-TE if the GMPLS control plane is in use. 152 Figure 2 and 3 show the label forwarding tables on each node that the 153 LSP pass through before and after the creation of the tunnel. In the 154 example shown in Figure 3, in order to create the TCM tunnel, the TCM 155 source node B needs to create a new label forwarding entry with two 156 labels, in which the in-label at the TCM destination node D of the 157 LSP (i.e., the label "L3") is treated as the inner layer out-label. 158 The current RSVP-TE can not support creation of such label forwarding 159 entry and creation of TCM tunnel on an existing LSP, so RSVP-TE needs 160 to be extended. 162 |<---------------------- LSP ---------------------->| 163 | | 164 +---------------------------------------------------+ 165 +---------------------------------------------------+ 166 +-----+ +-----+ +-----+ +-----+ +-----+ 167 | | | | | | | | | | 168 | A +------| B +------+ C +------+ D +------+ E | 169 | | | | | | | | | | 170 +-----+ +-----+ +-----+ +-----+ +-----+ 172 +-----------+ +-----------+ +-----------+ +-----------+ +-----------+ 173 | Node A | | Node B | | Node C | | Node D | | Node E | 174 +-----+-----+ +-----+-----+ +-----+-----+ +-----+-----+ +-----+-----+ 175 | in | out | | in | out | | in | out | | in | out | | in | out | 176 |label|label| |label|label| |label|label| |label|label| |label|label| 177 +-----+-----+ +-----+-----+ +-----+-----+ +-----+-----+ +-----+-----+ 178 | -- | L1 | | L1 | L2 | | L2 | L3 | | L3 | L4 | | L4 | POP | 179 +-----+-----+ +-----+-----+ +-----+-----+ +-----+-----+ +-----+-----+ 181 Figure 2 - Label Forwarding Tables before Creation of Tunnel 182 |<---------------------- LSP ---------------------->| 183 | | 184 | |<-- Path Segment Tunnel -->| | 185 | | | | 186 +-----------+===========================+-----------+ 187 +-----------+===========================+-----------+ 188 +-----+ +-----+ +-----+ +-----+ +-----+ 189 | | | | | | | | | | 190 | A +------| B +------+ C +------+ D +------+ E | 191 | | | | | | | | | | 192 +-----+ +-----+ +-----+ +-----+ +-----+ 194 +-----------+ +-----------+ +-----------+ +-----------+ +-----------+ 195 | Node A | | Node B | | Node C | | Node D | | Node E | 196 +-----+-----+ +-----+-----+ +-----+-----+ +-----+-----+ +-----+-----+ 197 | in | out | | in | out | | in | out | | in | out | | in | out | 198 |label|label| |label|label| |label|label| |label|label| |label|label| 199 +-----+-----+ +-----+-----+ +-----+-----+ +-----+-----+ +-----+-----+ 200 | -- | L1 | | L1 |L3+L5| | L5 | L6 | | L6 | POP | | L4 | POP | 201 +-----+-----+ +-----+-----+ +-----+-----+ +-----+-----+ +-----+-----+ 202 | L3 | L4 | 203 +-----+-----+ 205 Figure 3 - Label Forwarding Tables after Creation of Tunnel 207 The basic requirements of setting up path segment tunnel on an LSP 208 for TCM by GMPLS RSVP-TE signaling include: 210 - No Disruption of User Traffic on the LSP. 212 - The path segment tunnel MUST pass through exactly the same 213 route as the LSP segment to be monitored. 215 - No extra bandwidth required. Since the tunnel and the LSP 216 segment have a 1:1 relationship, the bandwidth of the tunnel is 217 exactly the same as the LSP. Therefore, when setting up such 218 tunnel, no extra bandwidth is required to be reserved. 220 4. Procedure of TCM Configuration 222 When there is a need to monitor a part of an existing LSP between two 223 nodes (i.e., the TCM source node and the TCM destination node), the 224 network operator can instruct the TCM source node to perform the TCM 225 configuration. The GMPLS signaling is used to set up an RSVP-TE 226 session for the TCM tunnel between TCM source node and destination 227 node. 229 4.1. Path Segment Tunnel Creation 231 If the OAM MEP function can be supported, the TCM source node sends a 232 PATH message node by node along the LSP until the TCM destination 233 node. The ERO, which indicates the same route as the LSP segment to 234 be monitored, is necessary to be carried in this PATH message. The 235 tunnel sender address and the tunnel end point address in the PATH 236 message indicate the TCM source node and the TCM destination node. 238 Additionally, in order to perform bandwidth sharing between the TCM 239 tunnel and the LSP segment to be monitored, the PATH message for the 240 TCM tunnel should indicate using Share Explicit (SE) reservation 241 style and indicate which LSP to be monitored. Therefore, the 242 information of source and destination node IDs and the LSP ID of the 243 LSP to be monitored is needed to be carried in the PATH message. 245 A new TCM_CONFIGURATION object, as described in Session 5, is 246 introduced into the PATH message to carry this information. 248 If the OAM MEP function can be supported, the TCM destination node 249 responds a RESV message along the LSP until to the TCM source node. 250 Each node on the TCM tunnel performs a normal label distribution 251 procedure for the TCM tunnel and uses the SE style to share bandwidth 252 resources with the LSP. 254 Additionally, the TCM source node needs to use the in-label of the 255 LSP at the TCM destination node (i.e., L3 in figure 2 and 3) to 256 create the label forwarding entry for the TCM tunnel. But the TCM 257 source node may not have this label information because the Label 258 recording may not be performed in the LSP (i.e., the Label_Recording 259 flag in the SESSION_ATTRIBUTE object of the LSP is not set). 260 Therefore, the TCM destination node needs to include this in-label 261 in the RESV message. This label will be forwarded to the TCM source 262 node by the RESV messages sent by the intermediate nodes. This label 263 can be also carried in the TCM CONFIGUARION object. See Session 5 for 264 the detailed format of this object. 266 In Figure 3, for the TCM source node B, three labels are obtained: 268 - L3 from the downstream RESV message; 269 - The label of the TCM tunnel allocate by the downstream node (i.e., 270 L5 in figure 2 and 3) from the downstream RESV message; 272 - The in-label of the LSP on the TCM source node (i.e., L1 in figure 273 2 and 3) from the forwarding entry related to the LSP on itself. 275 Then the TCM source node can creates a new label forwarding entry 276 which indicates that for the received data packet with a label of L1, 277 the label is replaced to two layer label, where the inner layer label 278 is L3 and the outer label is L5. 280 At last, the TCM source node enables this new created label 281 forwarding entry and disables the old one for the LSP, so that the 282 TCM tunnel is created and is ready for use. 284 4.2. LSP Rerouting in control plane 286 After setting up the TCM tunnel, the TCM tunnel is treated to be one 287 hop in the viewpoint of the original LSP. In other words, the route 288 of the LSP is changed so that a rerouting procedure is necessary to 289 be performed in the control plane. A Notify message is sent from the 290 TCM source node to the source node of the LSP to inform the change of 291 the route, so that the source node of the LSP can refresh the LSP 292 along the new route in the next refreshing periods. 294 4.3. OAM Configuration 296 After setting up the TCM tunnel, the OAM function can be initiated. 297 [OAM-CFG] describes the procedure of OAM configuration using GMPLS 298 control plane. 300 5. RSVP-TE Extension 302 A new TCM_CONFIGURATION object is introduced to carry the TCM related 303 information. The object class is TBD. 305 5.1. TCM_CONFIGURATION object in PATH message 307 When the TCM_CONFIGURATION object is carried in the PATH message, the 308 object carries the information of the monitored LSP. 310 C_Type = 1: 312 0 1 2 3 313 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 314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 315 | LSP source node IPv4 address | 316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 317 | LSP destination node IPv4 address | 318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 319 | MUST be zero | LSP ID | 320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 322 C-Type = 2: 324 0 1 2 3 325 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 326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 327 | LSP source node IPv6 address | 328 | | 329 | | 330 | | 331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 332 | LSP destination node IPv6 address | 333 | | 334 | | 335 | | 336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 337 | MUST be zero | LSP ID | 338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 340 The LSP source and destination node and the LSP ID are used to 341 indicate which LSP to be monitored. 343 5.2. TCM_CONFIGURATION object in RESV message 345 When the TCM_CONFIGURATION object is carried in the RESV message, the 346 object carries the in-label of the LSP at the TCM destination node. 348 C-Type = 3: 350 0 1 2 3 351 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 352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 353 | in-label of LSP at TCM destination node | 354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 356 6. Security Considerations 358 TBD. 360 7. IANA Considerations 362 TBD. 364 8. Acknowledgments 366 TBD. 368 9. References 370 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 371 Requirement Levels", BCP 14, RFC 2119, March 1997. 373 [TP-FRWK] M. Bocci et al, "A Framework for MPLS in Transport 374 Networks", draft-ietf-mpls-tp-framework-06, October 16, 375 2009. 377 [RFC5654] B. Niven-Jenkins et al, "Requirements of an MPLS 378 Transport Profile", RFC 5654, September 2009. 380 [TP-OAM] I. Busi et al, "MPLS-TP OAM Framework", draft-ietf-mpls- 381 tp-oam-framework-06, April 21, 2010. 383 [RFC3945] Mannie, E., "Generalized Multi-Protocol Label Switching 384 (GMPLS) Architecture", RFC 3945, October 2004. 386 [TP-CP-FRWK] Loa Andersson et al, "MPLS-TP Control Plane Framework", 387 draft-ietf-ccamp-mpls-tp-cp-framework-02, June 18, 2010. 389 [OAM-CFG] A. Takacs et al, "OAM Configuration Framework and 390 Requirements for GMPLS RSVP-TE", draft-ietf-ccamp-oam- 391 configuration-fwk-03, January 28, 2010. 393 [RFC3471] Berger, L., Ed., "Generalized Multi-Protocol Label 394 Switching (GMPLS) Signaling Functional Description", RFC 395 3471, January 2003. 397 [RFC3473] L. Berger, Ed., "Generalized Multi-Protocol Label 398 Switching (GMPLS) Signaling Resource ReserVation 399 Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 400 3473, January 2003. 402 10. Authors' Addresses 404 Fatai Zhang 405 Huawei Technologies 406 F3-5-B R&D Center, Huawei Base 407 Bantian, Longgang District 408 Shenzhen 518129 P.R.China 410 Phone: +86-755-28972912 411 Email: zhangfatai@huawei.com 413 Yi Lin 414 Huawei Technologies Co., Ltd. 415 F3-5-B R&D Center, Huawei Base, 416 Bantian, Longgang District 417 Shenzhen 518129 P.R.China 419 Phone: +86-755-28972914 420 Email: linyi_hw@huawei.com 422 Intellectual Property 423 The IETF Trust takes no position regarding the validity or scope of 424 any Intellectual Property Rights or other rights that might be 425 claimed to pertain to the implementation or use of the technology 426 described in any IETF Document or the extent to which any license 427 under such rights might or might not be available; nor does it 428 represent that it has made any independent effort to identify any 429 such rights. 431 Copies of Intellectual Property disclosures made to the IETF 432 Secretariat and any assurances of licenses to be made available, or 433 the result of an attempt made to obtain a general license or 434 permission for the use of such proprietary rights by implementers or 435 users of this specification can be obtained from the IETF on-line IPR 436 repository at http://www.ietf.org/ipr 438 The IETF invites any interested party to bring to its attention any 439 copyrights, patents or patent applications, or other proprietary 440 rights that may cover technology that may be required to implement 441 any standard or specification contained in an IETF Document. Please 442 address the information to the IETF at ietf-ipr@ietf.org. 444 The definitive version of an IETF Document is that published by, or 445 under the auspices of, the IETF. Versions of IETF Documents that are 446 published by third parties, including those that are translated into 447 other languages, should not be considered to be definitive versions 448 of IETF Documents. The definitive version of these Legal Provisions 449 is that published by, or under the auspices of, the IETF. Versions of 450 these Legal Provisions that are published by third parties, including 451 those that are translated into other languages, should not be 452 considered to be definitive versions of these Legal Provisions. 454 For the avoidance of doubt, each Contributor to the IETF Standards 455 Process licenses each Contribution that he or she makes as part of 456 the IETF Standards Process to the IETF Trust pursuant to the 457 provisions of RFC 5378. No language to the contrary, or terms, 458 conditions or rights that differ from or are inconsistent with the 459 rights and licenses granted under RFC 5378, shall have any effect and 460 shall be null and void, whether published or posted by such 461 Contributor, or included with or in such Contribution. 463 Disclaimer of Validity 465 All IETF Documents and the information contained therein are provided 466 on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 467 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 468 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 469 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 470 WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE 471 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 472 FOR A PARTICULAR PURPOSE. 474 Copyright Notice 476 Copyright (c) 2010 IETF Trust and the persons identified as the 477 document authors. All rights reserved. 479 This document is subject to BCP 78 and the IETF Trust's Legal 480 Provisions Relating to IETF Documents 481 (http://trustee.ietf.org/license-info) in effect on the date of 482 publication of this document. Please review these documents 483 carefully, as they describe your rights and restrictions with respect 484 to this document. Code Components extracted from this document must 485 include Simplified BSD License text as described in Section 4.e of 486 the Trust Legal Provisions and are provided without warranty as 487 described in the Simplified BSD License.