idnits 2.17.1 draft-zhang-ccamp-mpls-tp-rsvpte-ext-tunnel-num-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 : ---------------------------------------------------------------------------- ** There are 4 instances of lines with control characters in the document. ** The abstract seems to contain references ([I-D.ietf-mpls-tp-cc-cv-rdi], [RFC3473], [I-D.ietf-mpls-tp-identifiers]), 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 (September 16, 2011) is 4577 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: 2 errors (**), 0 flaws (~~), 1 warning (==), 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 September 16, 2011 5 Expires: March 19, 2012 7 RSVP-TE Extentions to Exchange MPLS-TP Tunnel Numbers 8 draft-zhang-ccamp-mpls-tp-rsvpte-ext-tunnel-num-00 10 Abstract 12 The MPLS Transport Profile (MPLS-TP) identifiers document 13 [I-D.ietf-mpls-tp-identifiers] introduce two tunnel numbers, A1- 14 Tunnel_Num and Z9-Tunnel_Num, which allow a compact format for 15 Maintenance Entity Point Identifier (MEP_ID). For some Operation, 16 Administration and Maintenance (OAM) functions, such as Connectivity 17 Verification (CV) [I-D.ietf-mpls-tp-cc-cv-rdi], source MEP_ID MUST be 18 inserted in the OAM packets, so that the peer endpoint can compare 19 the received and expected MEP_IDs to judge whether there is a 20 mismatch, which means that the two MEP nodes need to pre-store each 21 other's MEP_IDs. 23 The specification of setting up co-routed bidirectional LSP is 24 described in the document [RFC3473], which does not introduce the 25 locally configured tunnel number on the tunnel endpoint. This 26 document defines the Connection object to exchange the tunnel 27 numbers. 29 Status of this Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on March 19, 2012. 46 Copyright Notice 48 Copyright (c) 2011 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Conventions used in this document . . . . . . . . . . . . . . . 3 65 3. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 66 4. Connection Object . . . . . . . . . . . . . . . . . . . . . . . 4 67 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 68 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 69 7. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . . 5 70 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 71 8.1. Normative references . . . . . . . . . . . . . . . . . . . 6 72 8.2. Informative References . . . . . . . . . . . . . . . . . . 6 73 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 6 75 1. Introduction 77 The MPLS Transport Profile (MPLS-TP) identifiers document 78 [I-D.ietf-mpls-tp-identifiers] introduce two tunnel numbers, A1- 79 Tunnel_Num and Z9-Tunnel_Num, which are locally assigned and allow a 80 compact format for Maintenance Entity Point Identifier (MEP_ID). For 81 a co-routed bidirectional LSP, the format of A1-MEP_ID is A1- 82 Node_ID::A1-Tunnel_Num::LSP_Num, and the format of Z9-MEP_ID is Z9- 83 Node_ID::Z9-Tunnel_Num::LSP_Num. In order to realize some Operation, 84 Administration and Maintenance (OAM) functions, such as Connectivity 85 Verification (CV) [I-D.ietf-mpls-tp-cc-cv-rdi], source MEP-ID MUST be 86 inserted in the OAM packets, in this way the peer endpoint can 87 compare the received and expected MEP-IDs to judge whether there is a 88 mismatch. Hence, the two MEP nodes must pre-store each other's MEP- 89 IDs before sending the CV packets. 91 Although the exchange of MEP_IDs can be accomplished by Network 92 Management System (NMS) if it is deployed, it is still complex when 93 the LSPs cross different adiminstration domains, which needs the 94 cooperation of NMSs. So when the LSPs are set up by control plane, 95 Resource ReserVation Protocol Traffic Engnieering (RSVP-TE) signaling 96 will be more suitable to realize the exchange of MEP_IDs. 98 The specification of setting up co-routed bidirectional LSP is 99 described in the document [RFC3473], which does not introduce the 100 locally configured tunnel number on the tunnel endpoint. This 101 document defines the Connection object to exchange the tunnel 102 numbers. 104 2. Conventions used in this document 106 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 107 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 108 document are to be interpreted as described in [RFC2119]. 110 3. Operation 112 MPLS-TP co-routed bidirectional LSPs can be deloyed across one or 113 more administration domains, and NMS may exist in some administration 114 domains, which knows the tunnel spaces of every node in it's 115 responsible domain. Consider that LSP1 is initialized at A1 node 116 with Connection object inserted in LSP1's Path message , the 117 following modes may happend. 119 Modes 1: L bit is set, and the Z9-Tunnel_Num is designated in the 120 "Destination Tunnel Num" field. If the Z9 node finds that this 121 tunnel number is occupied, or it can not be used because of some 122 local policies, a PathErr message must be sent with "Unavailable 123 tunnel number" error. Otherwise, the designated tunnel number must 124 be adopted, and the Connection object may be inserted in the Resv 125 message without any change. 127 Modes 2: L bit is not set, and a recommended Z9-Tunnel_Num may be 128 filled in the "Destination Tunnel Num" field. If the Z9 node finds 129 that the recommended value can be used, the Connection object must be 130 inserted in the Resv message without any change; if the recommended 131 value can not be used or the "Destination Tunnel Num" field is empty, 132 a new tunnel number will be allocated and filled into the Connection 133 object that must be inserted in the Resv message. 135 Each mode has its own pros and cons and how to determine the right 136 mode for a specific network mainly depends on the operators' 137 preference. For example, for the operators who are used to operate 138 traditional transport network and familiar with the Transport-Centric 139 operational model may prefer mode 1. The second mode is more 140 suitable for the operators who are familiar with the operation and 141 maintenance of IP/MPLS network, or the MPLS-TP LSPs cross multiple 142 administration domains. 144 4. Connection Object 146 The format of Connection Object (Class-Num of the form 11bbbbbb with 147 value = TBA, C-Type = TBA) is as follow: 149 0 1 2 3 150 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 151 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 152 | Length | Class-Num(TBA)| C-Type (TBA) | 153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 154 |L| Reserverd | Destination Tunnel Num | 155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 157 Connection Object 159 L 161 The L bit is set if the initiating node enforces the peer 162 endpoint to configure the value carried in the field of 163 "Destination Tunnle Num". 165 If the bit is not set, the peer endpoint firstly tries to 166 use the recommended tunnel number; it can use any other 167 unoccupied tunnnel numbers when the recommended tunnel 168 number is unavailable. 170 Reserverd 172 Must be set to 0 on transmit and ignored on receive. 174 Destination Tunnel Num 176 If the L bit is set, it indicates that the peer endpoint 177 must configure the value carried in this field. 179 If the L bit is not set, this field can be empty or filled 180 by the recommended value. 182 The Connection object may appear in Path or Resv message, and a 183 midpoint that does not support this object is required to pass it on 184 unaltered, as indicated by the C-Num and the rules defined in 185 [RFC2205]. 187 5. IANA Considerations 189 TBD. 191 6. Security Considerations 193 TBD. 195 7. Acknowledgement 197 This document was prepared based on the discussion with George 198 Swallow, valuable comments and input was also received from 199 Venkatesan Mahalingam and Muliu Tao. 201 8. References 202 8.1. Normative references 204 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 205 Requirement Levels", BCP 14, RFC 2119, March 1997. 207 [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. 208 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 209 Functional Specification", RFC 2205, September 1997. 211 [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching 212 (GMPLS) Signaling Resource ReserVation Protocol-Traffic 213 Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. 215 8.2. Informative References 217 [I-D.ietf-mpls-tp-cc-cv-rdi] 218 Allan, D., Swallow, G., and J. Drake, "Proactive 219 Connectivity Verification, Continuity Check and Remote 220 Defect indication for MPLS Transport Profile", 221 draft-ietf-mpls-tp-cc-cv-rdi-06 (work in progress), 222 August 2011. 224 [I-D.ietf-mpls-tp-identifiers] 225 Bocci, M., Swallow, G., and E. Gray, "MPLS-TP 226 Identifiers", draft-ietf-mpls-tp-identifiers-07 (work in 227 progress), July 2011. 229 Author's Address 231 Fei Zhang 232 ZTE Corporation 234 Email: zhang.fei3@zte.com.cn 236 Xiao Bao 237 ZTE Corporation 239 Email: bao.xiao1@zte.com.cn