idnits 2.17.1 draft-zhang-ccamp-mpls-tp-rsvpte-ext-tunnel-num-05.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 abstract seems to contain references ([RFC3473], [RFC6370], [RFC3209]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 12, 2012) is 4206 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) No issues found here. Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CCAMP Working Group F. Zhang 3 Internet-Draft ZTE Corporation 4 Intended status: Standards Track M. Venkatesan 5 Expires: April 15, 2013 Dell Inc. 6 Y. Xu 7 CATR 8 R. Gandhi 9 Cisco Systems 10 October 12, 2012 12 RSVP-TE Identification of MPLS-TP Co-Routed Bidirectional LSP 13 draft-zhang-ccamp-mpls-tp-rsvpte-ext-tunnel-num-05 15 Abstract 17 The MPLS Transport Profile (MPLS-TP) identifiers document [RFC6370] 18 specifies an initial set of identifiers, including the local assigned 19 Z9-Tunnel_Num for co-routed bidirectional LSP, which is not covered 20 by the current specifications, like [RFC3209], [RFC3473]. This 21 document defines Resource ReserVation Protocol Traffic Engnieering 22 (RSVP-TE) identification of MPLS-TP co-routed bidirectional LSP. 24 Status of this Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on April 15, 2013. 41 Copyright Notice 43 Copyright (c) 2012 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) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Conventions used in this document . . . . . . . . . . . . . . . 3 60 3. MPLS-TP Co-Routed Bidirectional LSP Identification . . . . . . 3 61 3.1. Signaling Procedures . . . . . . . . . . . . . . . . . . . 3 62 3.2. Association Object . . . . . . . . . . . . . . . . . . . . 4 63 3.3. Compatibility . . . . . . . . . . . . . . . . . . . . . . . 5 64 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 65 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 66 6. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . . 6 67 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 68 7.1. Normative references . . . . . . . . . . . . . . . . . . . 6 69 7.2. Informative References . . . . . . . . . . . . . . . . . . 7 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 72 1. Introduction 74 The MPLS Transport Profile (MPLS-TP) identifiers document [RFC6370] 75 specifies a initial set of identifiers, such as the LSP_ID of of the 76 MPLS-TP co-routed bidirectional LSP, which is A1- 77 {Node_ID::Tunnel_Num}::Z9-{Node_ID::Tunnel_Num}::LSP_Num. The mapping 78 from an MPLS-TP LSP_ID to Resource ReserVation Protocol Traffic 79 Engnieering (RSVP-TE) is also descirbed in [RFC6370], except the 80 local assigned Z9-Tunnel_Num, which is not covered by the current 81 specifications, like [RFC3209], [RFC3473]. However, the Z9- 82 Tunnel_Num is a part of the Maintenance Entity Point Identifier 83 (MEP_ID), and the two MEP nodes must pre-store each other's MEP-IDs 84 before sending some Operation, Administration and Maintenance (OAM) 85 packets, such as Connectivity Verification (CV) [RFC6428]. In this 86 way the peer endpoint can compare the received and expected MEP-IDs 87 to judge whether there is a mis-connectivity defect [RFC6371]. In 88 other words, A1/Z9 nodes need to know each other's Tunnel_Num. 90 This document defines Resource ReserVation Protocol Traffic 91 Engnieering (RSVP-TE) identification of MPLS-TP co-routed 92 bidirectional LSP. Since the LSP identifiers can be carried in an 93 ASSOCIATION object [I-D.ietf-ccamp-assoc-ext], it is naturally to 94 define the signaling extensions based on the ASSOCIATION object. 96 2. Conventions used in this document 98 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 99 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 100 document are to be interpreted as described in [RFC2119]. 102 3. MPLS-TP Co-Routed Bidirectional LSP Identification 104 3.1. Signaling Procedures 106 Consider that LSP1 is initialized at A1 node with an ASSOCIATION 107 object inserted in Path message. Association Type is set to "LSP 108 Identifiers", Association ID set to A1-Tunnel_Num, Association Source 109 set to A1-Node_ID. Upon receipt of the Association Object, the 110 egress node Z9 checks the Association Type field. If it is "LSP 111 Identifiers", the ASSOCIATION object MUST be carried in the Resv 112 message also. Similarly, Association Type is set to "LSP 113 Identifiers", Association ID set to Z9-Tunnel_Num, Association Source 114 set to Z9-Node_ID. In this way, the ingress LSR can get the Z9- 115 Tunnel_Num, which MAY be used for identifying a mis-connectivity 116 defect of the proactive CV OAM function. 118 If LSP1 is across different domains, A1 and Z9 nodes MAY need to know 119 each other's Global_ID also. When an Extended ASSOCIATION object 120 with Association Type "LSP Identifiers" in inserted in the 121 initialized LSP Path message, Global Association Source is set to A1- 122 Global_ID. Similarly, this field will be set to Z9-Global_ID in the 123 Resv message. 125 3.2. Association Object 127 Within the current document, a new Association Type is defined in the 128 ASSOCIATION object, which MAY be used with any ASSOCIATION object 129 type. For example, the Extended ASSOCIATION object defined in 130 [I-D.ietf-ccamp-assoc-ext] can be used when Global_ID based 131 identification is desired. 133 Value Type 134 ----- ----- 135 6 (TBD) LSP Identifiers (L) 137 Association ID: 16 bits 139 For Path message, Association ID is the Tunnel_Num of the node 140 sending out the Path message, and can be ignored by the receiver. 142 For Resv message, Association ID is the Tunnel_Num of the node 143 sending out the Resv message. 145 Association Source: 4 or 16 bytes 147 Same as for IPv4 and IPv6 ASSOCIATION objects, see [RFC4872]. 149 For Path message, Association Source is the IP address of the node 150 sending out the Path message, and can be ignored by the receiver. 152 For Resv message, Association Source is the IP address of the node 153 sending out the Resv message, and can be ignored by the receiver. 155 Global Association Source: 4 bytes 157 Same as defined in [I-D.ietf-ccamp-assoc-ext] if Extended 158 ASSOCIATION object is used. 160 For Path message, Global Association Source is filled with the 161 Global_ID of the node sending out the Path message. 163 For Resv message, Global Association Source is the Global_ID of 164 the node sending out the Resv message. 166 Extended Association ID: 168 Extended Association ID is not added in the Extended ASSOCIATION 169 object when association type signaled is "LSP Identifiers". 171 The rules associated with the processing of the Extended ASSOCIATION 172 objects in RSVP message are discussed in [I-D.ietf-ccamp-assoc-ext]. 173 It said that in the absence of Association Type-specific rules for 174 identifying association, the included ASSOCIATION objects MUST be 175 identical. Since the Association Type "LSP Identifiers" used here is 176 to carry LSP identifier, there is no need to associate Path state to 177 Path state or Resv state to Resv state, one specific rule is added: 178 when the Association Type is "LSP Identifiers", the ASSOCIATION 179 object can appear in Path or Resv message across sessions or in a 180 single session, and the values can be different. 182 3.3. Compatibility 184 Per [RFC4872], the ASSOCIATION object uses an object class number of 185 the form 11bbbbbb to ensure compatibility with non-supporting nodes. 186 Per [RFC2205], such nodes will ignore the object but forward it 187 without modification. This is also described in 188 [I-D.ietf-ccamp-assoc-ext]. 190 Per [RFC4872], transit nodes that support the ASSOCIATION object, but 191 not the Extended Association C-Types, will "transmit, without 192 modification, any received ASSOCIATION object in the corresponding 193 outgoing Path message." Per [RFC2205], an egress node that supports 194 the ASSOCIATION object, but not the Extended Association C-Types may 195 generate an "Unknown object C-Type" error. This error will propagate 196 to the ingress node for standard error processing. 198 Operators wishing to use a function supported by the association type 199 "LSP Identifiers" should ensure that the type is supported on any 200 node which is expected to act on the association. 202 4. IANA Considerations 204 IANA is requested to administer assignment of new values for 205 namespace defined in this document and summarized in this section. 207 One value ("LSP Identifiers") needs to be allocated in the 208 Association Type Registry. 210 5. Security Considerations 212 A new Association Type is defined in this document, and except this, 213 there are no security issues about the ASSOCIATION object and 214 Extended ASSOCIATION object are introduced here. For Association 215 object related security issues, see the documents [RFC4872], 216 [RFC4873], and [I-D.ietf-ccamp-assoc-ext]. 218 For a more comprehensive discussion on GMPLS security please see the 219 Security Framework for MPLS and GMPLS Networks [RFC5920]. 221 6. Acknowledgement 223 This document was prepared based on the discussion with George 224 Swallow, valuable comments and input were also received from Lou 225 Berger, John E Drake, Jaihari Kalijanakiraman, Muliu Tao and Wenjuan 226 He. 228 7. References 230 7.1. Normative references 232 [I-D.ietf-ccamp-assoc-ext] 233 Berger, L., Faucheur, F., and A. Narayanan, "RSVP 234 Association Object Extensions", 235 draft-ietf-ccamp-assoc-ext-06 (work in progress), 236 September 2012. 238 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 239 Requirement Levels", BCP 14, RFC 2119, March 1997. 241 [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. 242 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 243 Functional Specification", RFC 2205, September 1997. 245 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 246 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 247 Tunnels", RFC 3209, December 2001. 249 [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching 250 (GMPLS) Signaling Resource ReserVation Protocol-Traffic 251 Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. 253 7.2. Informative References 255 [RFC4872] Lang, J., Rekhter, Y., and D. Papadimitriou, "RSVP-TE 256 Extensions in Support of End-to-End Generalized Multi- 257 Protocol Label Switching (GMPLS) Recovery", RFC 4872, 258 May 2007. 260 [RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., and A. Farrel, 261 "GMPLS Segment Recovery", RFC 4873, May 2007. 263 [RFC5920] Fang, L., "Security Framework for MPLS and GMPLS 264 Networks", RFC 5920, July 2010. 266 [RFC6370] Bocci, M., Swallow, G., and E. Gray, "MPLS Transport 267 Profile (MPLS-TP) Identifiers", RFC 6370, September 2011. 269 [RFC6371] Busi, I. and D. Allan, "Operations, Administration, and 270 Maintenance Framework for MPLS-Based Transport Networks", 271 RFC 6371, September 2011. 273 [RFC6428] Allan, D., Swallow Ed. , G., and J. Drake Ed. , "Proactive 274 Connectivity Verification, Continuity Check, and Remote 275 Defect Indication for the MPLS Transport Profile", 276 RFC 6428, November 2011. 278 Authors' Addresses 280 Fei Zhang 281 ZTE Corporation 283 Email: zhang.fei3@zte.com.cn 285 Venkatesan Mahalingam 286 Dell Inc. 288 Email: venkat.mahalingams@gmail.com 290 Yunbin Xu 291 CATR 293 Email: xuyunbin@mail.ritt.com.cn 294 Rakesh Gandhi 295 Cisco Systems 297 Email: rgandhi@cisco.com 299 Xiao Bao 300 ZTE Corporation 302 Email: bao.xiao1@zte.com.cn