idnits 2.17.1 draft-zhang-ccamp-mpls-tp-rsvpte-ext-tunnel-num-01.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 : ---------------------------------------------------------------------------- ** There are 5 instances of lines with control characters in the document. ** The abstract seems to contain references ([I-D.ietf-mpls-tp-cc-cv-rdi], [RFC6370], [RFC6371]), 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 (November 13, 2011) is 4548 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) == Outdated reference: A later version (-11) exists of draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-02 Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MPLS Working Group F. Zhang 3 Internet-Draft ZTE Corporation 4 Intended status: Standards Track November 13, 2011 5 Expires: May 16, 2012 7 RSVP-TE Extensions to Exchange MPLS-TP LSP Identifiers 8 draft-zhang-ccamp-mpls-tp-rsvpte-ext-tunnel-num-01 10 Abstract 12 The MPLS Transport Profile (MPLS-TP) identifiers document [RFC6370] 13 specifies a initial set of identifiers, such as local assigned tunnel 14 number and Global_ID, which can be used to form Maintenance Entity 15 Point Identifier (MEP_ID). As to some Operation, Administration and 16 Maintenance (OAM) functions, such as Connectivity Verification (CV) 17 [I-D.ietf-mpls-tp-cc-cv-rdi], source MEP_ID must be inserted in the 18 OAM packets, so that the peer endpoint can compare the received and 19 expected MEP_IDs to judge whether there is a mismatch [RFC6371], 20 which means that the two MEP nodes need to pre-store each other's 21 MEP_IDs. 23 This document defines the signaling extensions to exchange the Label 24 Switched Path (LSP) identifiers. 26 Status of this Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on May 16, 2012. 43 Copyright Notice 45 Copyright (c) 2011 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Conventions used in this document . . . . . . . . . . . . . . . 3 62 3. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 3.1. Co-routed Bidirectional LSP . . . . . . . . . . . . . . . . 3 64 3.2. Associated Bidirectional LSP . . . . . . . . . . . . . . . 4 65 4. RSVP-TE Extensions . . . . . . . . . . . . . . . . . . . . . . 5 66 4.1. LSP Attribute Flags . . . . . . . . . . . . . . . . . . . . 5 67 4.2. Connection TLV . . . . . . . . . . . . . . . . . . . . . . 5 68 4.3. Global_ID TLV . . . . . . . . . . . . . . . . . . . . . . . 6 69 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 70 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 71 7. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . . 7 72 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 73 8.1. Normative references . . . . . . . . . . . . . . . . . . . 7 74 8.2. Informative References . . . . . . . . . . . . . . . . . . 8 75 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8 77 1. Introduction 79 The MPLS Transport Profile (MPLS-TP) identifiers document [RFC6370] 80 specifies a initial set of identifiers, such as local assigned tunnel 81 number (Tunnel_Num) and Global_ID, which can be used to form 82 Maintenance Entity Point Identifier (MEP_ID). The MPLS-TP LSP_MEP_ID 83 is Node_ID::Tunnel_Num::LSP_Num, and in situations where global 84 uniqueness is required, this becomes: Global_ID::Node_ID:: 85 Tunnel_Num::LSP_Num. In order to realize some Operation, 86 Administration and Maintenance (OAM) functions, such as Connectivity 87 Verification (CV) [I-D.ietf-mpls-tp-cc-cv-rdi], source MEP-ID MUST be 88 inserted in the OAM packets, in this way the peer endpoint can 89 compare the received and expected MEP-IDs to judge whether there is a 90 mismatch [RFC6371]. Hence, the two MEP nodes must pre-store each 91 other's MEP-IDs before sending the CV packets. 93 Obviously, the exchange of MEP_IDs can be accomplished by the Network 94 Management System (NMS), but it is complex when the LSPs cross 95 different adiminstration domains, which involves the cooperation of 96 NMSs. When the LSPs are set up by control plane, Resource 97 ReserVation Protocol Traffic Engnieering (RSVP-TE) messages will be 98 more suitable to realize the exchange of MEP_IDs. 100 The specification of setting up co-routed bidirectional LSP is 101 described in the document [RFC3473], which does not specify the 102 Global_ID and locally configured Z9-Tunnel_Num. Similary, for 103 associated bidirectional LSP 104 [I-D.ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp], the Global_ID may 105 also be useful. This document defines the signaling extensions to 106 exchange the LSP identifiers. 108 2. Conventions used in this document 110 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 111 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 112 document are to be interpreted as described in [RFC2119]. 114 3. Operation 116 3.1. Co-routed Bidirectional LSP 118 MPLS-TP co-routed bidirectional LSPs can be deployed across one or 119 more administration domains, and NMS may exist in some administration 120 domains, which knows the tunnel spaces of every node in it's 121 responsible domain. Consider that LSP1 is initialized at A1 node, 122 and the "L" bit of the Attributes Flags TLV [RFC5420] may be set in 123 the outgoing Path message. If the "L" bit is set, the Connection TLV 124 MUST be carried and Global_ID TLV is optional in the LSP_ATTRIBUTES 125 object. 127 A "L" bit is defined in the Connection TLV. When it is set, the Z9- 128 Tunnel_Num is designated in the "Destination Tunnel Num" field. If 129 the Z9 node finds that this tunnel number is occupied, or it can not 130 be used because of some local policies, an error MUST be generated 131 "Notify error/ unavailable tunnel number". Otherwise, the designated 132 tunnel number must be adopted, and the Connection TLV may be inserted 133 in the Resv message without any change. In case the "L" bit is not 134 set, a recommended Z9-Tunnel_Num may be filled in the "Destination 135 Tunnel Num" field. If the Z9 node finds that the recommended value 136 can be used, the Connection TLV must be inserted in the Resv message 137 without any change; else the recommended value can not be used or the 138 "Destination Tunnel Num" field is empty, a new tunnel number will be 139 allocated and filled into the Connection TLV that must be inserted in 140 the Resv message. While, that the "L" bit is set or not depends on 141 the operators' preference. For example, for the operators who are 142 used to operate traditional transport network and familiar with the 143 Transport-Centric operational model may prefer "L" bit set. That the 144 "L" bit is not set is more suitable for the operators who are 145 familiar with the operation and maintenance of IP/MPLS network, or 146 the MPLS-TP LSPs cross multiple administration domains. 148 The Global_ID TLV is needed to be carried if the LSP is across 149 different administrative domains, which can be inserted in the 150 outgoing Path message at A1 node or added by the transit Autonomous 151 System Border Router (ASBR) node that is in the same domain as A1 152 node, and the value is A1's Global_ID. Z9's Global_ID should be 153 inserted in the Resv message at Z9 node or any other Label Swithed 154 Routers (LSRs) that in the same domain as Z9, and the value is Z9's 155 Global_ID. 157 3.2. Associated Bidirectional LSP 159 MPLS-TP associated bidirectional LSPs may also be deployed across one 160 or more administration domains, and the Global_ID is needed to keep 161 the MEP_ID globally unique. Consider that the forward LSP is 162 initialized at A1 node and the backward LSP is initialized at Z9 163 node, the "L" bit of the Attributes Flags TLV may be set in each 164 other's outgoing Path messages. When the "L" bit is set, the 165 Global_ID TLV with the value set to A1/Z9's Global_ID is optional in 166 the LSP_ATTRIBUTES object and can be inserted in the outgoing Path 167 message at A1/Z9 node or added by the transit Autonomous System 168 Border Router (ASBR) node that is in the same domain as A1/Z9 node. 169 If this TLV is present in Resv message, it can be ignored. 171 4. RSVP-TE Extensions 173 4.1. LSP Attribute Flags 175 The LSP Attribute Flags TLV is defined in [RFC5420], and this 176 document introduces a new flag: 178 One bit ("L", IANA to assign): "LSP identifier indication" is 179 allocated in the LSP Attributes Flags TLV to be used in the 180 LSP_ATTRIBUTES object. If the "L" bit is set, it is indicating that 181 A1/Z9 node needs to know each other's LSP identifer. 183 4.2. Connection TLV 185 The Connection TLV is carried in the LSP_ATTRIBUTES object with the 186 following format: 188 0 1 2 3 189 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 190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 191 | Type (TBD) | Length | 192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 193 |L| Reserved | Destination Tunnel Num | 194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 196 Connection TLV 198 L 200 The L bit is set if the initiating node enforces the peer 201 endpoint to configure the value carried in the field of 202 "Destination Tunnle Num". 204 If the bit is not set, the peer endpoint firstly tries to 205 use the recommended tunnel number; it can use any other 206 unoccupied tunnnel numbers when the recommended tunnel 207 number is unavailable. 209 Reserverd 211 Must be set to 0 on transmit and ignored on receive. 213 Destination Tunnel Num 215 If the L bit is set, it indicates that the peer endpoint 216 must configure the value carried in this field. 218 Else the L bit is not set, this field can be empty or filled 219 by the recommended value. 221 The Connection TLV may appear in Path or Resv message of co-routed 222 bidirectional LSP. 224 4.3. Global_ID TLV 226 The Global_ID TLV is carried in the LSP_ATTRIBUTES object with the 227 following format: 229 0 1 2 3 230 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 231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 232 | Type (TBD) | Length | 233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 234 | Global_ID | 235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 237 Global_ID TLV 239 This TLV can be used for co-routed or associated bidirectional LSP. 240 For co-routed bidirectional LSP, it can appear in Path or Resv 241 message. As to associated bidirectional LSP, it can only appear in 242 the Path message, and will be ignored in the Resv message. 244 5. IANA Considerations 246 One bit ("LSP identifier indication") needs to be allocated in the 247 LSP Attributes Flags Registry. 249 This document specifies two new TLVs to be carried in the 250 LSP_ATTRIBUTES objects in Path and Resv messages: the Connection TLV 251 and Global_ID TLV. 253 For the existing error code "Notify error" (value 25), one new Error 254 value: "Unavailable tunnel number" needs to be assigned. 256 6. Security Considerations 258 This document adds a new flag to the Attributes Flags TLV and 259 introduce two new TLVs in the LSP_ATTRIBUTES objects. It does not 260 introduce any new direct security issues, and the reader is referred 261 to the security considerations expressed in [RFC2205] and [RFC5420]. 263 For a more comprehensive discussion on GMPLS security please see the 264 Security Framework for MPLS and GMPLS Networks [RFC5920]. 266 7. Acknowledgement 268 This document was prepared based on the discussion with George 269 Swallow, valuable comments and input were also received from Berger 270 Lou, Venkatesan Mahalingam, Jaihari Kalijanakiraman and Muliu Tao. 272 8. References 274 8.1. Normative references 276 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 277 Requirement Levels", BCP 14, RFC 2119, March 1997. 279 [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. 280 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 281 Functional Specification", RFC 2205, September 1997. 283 [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching 284 (GMPLS) Signaling Resource ReserVation Protocol-Traffic 285 Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. 287 [RFC5420] Farrel, A., Papadimitriou, D., Vasseur, JP., and A. 288 Ayyangarps, "Encoding of Attributes for MPLS LSP 289 Establishment Using Resource Reservation Protocol Traffic 290 Engineering (RSVP-TE)", RFC 5420, February 2009. 292 8.2. Informative References 294 [I-D.ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp] 295 Zhang, F. and R. Jing, "RSVP-TE Extensions for Associated 296 Bidirectional LSPs", 297 draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-02 298 (work in progress), October 2011. 300 [I-D.ietf-mpls-tp-cc-cv-rdi] 301 Allan, D., Swallow, G., and J. Drake, "Proactive 302 Connectivity Verification, Continuity Check and Remote 303 Defect indication for MPLS Transport Profile", 304 draft-ietf-mpls-tp-cc-cv-rdi-06 (work in progress), 305 August 2011. 307 [RFC5920] Fang, L., "Security Framework for MPLS and GMPLS 308 Networks", RFC 5920, July 2010. 310 [RFC6370] Bocci, M., Swallow, G., and E. Gray, "MPLS Transport 311 Profile (MPLS-TP) Identifiers", RFC 6370, September 2011. 313 [RFC6371] Busi, I. and D. Allan, "Operations, Administration, and 314 Maintenance Framework for MPLS-Based Transport Networks", 315 RFC 6371, September 2011. 317 Author's Address 319 Fei Zhang 320 ZTE Corporation 322 Email: zhang.fei3@zte.com.cn 324 Xiao Bao 325 ZTE Corporation 327 Email: bao.xiao1@zte.com.cn