idnits 2.17.1 draft-hu-pce-auxiliary-connections-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 12 instances of too long lines in the document, the longest one being 16 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (December 12, 2016) is 2691 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) == Missing Reference: 'TBD' is mentioned on line 133, but not defined == Outdated reference: A later version (-11) exists of draft-ietf-pce-pce-initiated-lsp-07 == Outdated reference: A later version (-21) exists of draft-ietf-pce-stateful-pce-18 Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PCE WG Fangwei. Hu 3 Internet-Draft Ran. Chen 4 Intended status: Standards Track ZTE Corporation 5 Expires: June 15, 2017 December 12, 2016 7 PCE auxiliary connections 8 draft-hu-pce-auxiliary-connections-00.txt 10 Abstract 12 This document provides a method to establish auxiliary connections 13 between PCE and PCC to improve the reliability of the connection of 14 PCE and PCC. The real-time sample data and some state report flow 15 are suggestion to transport by take use of the auxiliary connection. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on June 15, 2017. 34 Copyright Notice 36 Copyright (c) 2016 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 2. Conventions Used in This Document . . . . . . . . . . . . . . 3 53 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 54 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 55 3. New Functions to Support auxiliary connections . . . . . . . 3 56 4. Overview of Protocol Extensions . . . . . . . . . . . . . . . 3 57 4.1. Auxiliary-Connections-Capability-TLV . . . . . . . . . . 3 58 4.2. Capability Advertisement . . . . . . . . . . . . . . . . 5 59 4.3. Initialization Phase . . . . . . . . . . . . . . . . . . 5 60 4.4. Termination of the Auxiliary Connections PCEP Session . . 7 61 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 62 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 63 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 64 8. Informative References . . . . . . . . . . . . . . . . . . . 8 65 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 67 1. Introduction 69 The Path Computation Element Protocol (PCEP) defined in [RFC5440] is 70 used between a Path Computation Element (PCE) and a Path Computation 71 Client (PCC) (or other PCE) to enable computation of Multi-protocol 72 Label Switching (MPLS) for Traffic Engineering Label Switched Path 73 (TE LSP). 75 PCEP is a recommendation south-bound interface protocol, and PCE acts 76 as a controller, and PCCs are the SDN switch being managed by PCE. 77 The PCC should report the link state and flow statistics in the SDN 78 environment. The data going through the PCEP channel may be very 79 huge. The PCEP session and the TCP connection may be occupied by the 80 flow sample and be congested for the PCEP packet. So it is important 81 to improve the reliability of the PCE and the connection between PCE 82 and PCC. 84 This document provides to establish auxiliary connections between PCE 85 and PCC to improve the reliability of the connection of PCE and PCC. 86 The real-time sample data and some state report flow are suggestion 87 to transport by take use of the auxiliary connection. And the 88 original connection (we name it main connection) are used to 89 transport the PCEP protocol message (such as PCE PCReq message, PCRep 90 message, PCRpt message, PCUpd mesage, PCInitiate message 91 ,etc.)([RFC5440], [I-D.ietf-pce-stateful-pce], 92 [I-D.ietf-pce-pce-initiated-lsp]). 94 2. Conventions Used in This Document 96 2.1. Requirements Language 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 2.2. Terminology 104 This document uses the following terms defined in ([RFC5440]:PCC, 105 PCE, PCEP Peer. 107 The following terms are defined in this document: 109 Main connection: The PCEP session between PCE and PCC peer. It is 110 defined in [RFC5440]. It is renamed as main connection in this 111 document. 113 Auxiliary connection: the addition connection session beyond the main 114 connection. It is used to improve the reliability of main 115 connection. 117 3. New Functions to Support auxiliary connections 119 A new function is required in PCEP to support auxiliary connections. 120 A function can be initiated either from a PCC towards a PCE (C-E) or 121 from a PCE towards a PCC (E-C). The new function is: 123 Capability advertisement (E-C, C-E): both the PCC and the PCE must 124 announce during PCEP session establishment that they support 125 auxiliary connection defined in this document. 127 4. Overview of Protocol Extensions 129 4.1. Auxiliary-Connections-Capability-TLV 130 0 1 2 3 131 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 132 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 133 | Type[TBD] | Length | 134 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 135 | Auxiliary Connections number | Res | 136 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ 137 | Auxiliary Connection1 ID | Length | | 138 +--------------------------------+------------------------------+ > Auxiliary 139 | transport protocol | port number | | Connetction 1 140 +--------------------------------+------------------------------+ | 141 | option | / 142 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ 143 | Auxiliary Connection2 ID | Length | | 144 +--------------------------------+------------------------------+ | 145 | transport protocol | port number | > Auxiliary 146 +--------------------------------+------------------------------+ | Connetction 2 147 | option | | 148 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / 149 Figure 1 Auxiliary-Connections-Capability-TLV 151 o Type: 153 o Length: the whole length of TLV 155 o Auxiliary Connections number: the record number of auxiliary 156 connections. 158 o Res: reserve for future use. 160 o Auxiliary Connection ID: the identifier of the auxiliary 161 connection. 163 o Length:the length for the auxiliary connection. 165 o transport protocol: the transport protocol for the auxiliary 166 connection. The value is as following: 168 o TCP 1; 170 o UDP 2; 172 o TLS 3; 174 o DTLS 4; 176 o port number: port number used for the transport protocol in the 177 auxiliary connection. 179 o Option: Optional data. The extra optional data is filled in the 180 filled. For example, if the transport protocol is TLS, the secret 181 key is filled in the field. 183 4.2. Capability Advertisement 185 During PCEP Initialization Phase, PCEP Speakers (PCE or PCC) 186 advertise their support auxiliary connections. A PCEP Speaker 187 includes the " Auxiliary-Connections-Capability" TLV, described in 188 Section 5.1, in the OPEN Object to advertise its support for 189 auxiliary connections. The Auxiliary Connections Capability TLV 190 includes the auxiliary connection parameters. 192 The presence of the auxiliary connection Capability TLV in PCC's OPEN 193 Object indicates that the PCC is willing to establish auxiliary 194 connection with PCE. 196 The presence of the auxiliary connection Capability TLV in PCE's OPEN 197 message indicates that the PCE is willing to establish auxiliary 198 connection with PCC. 200 4.3. Initialization Phase 202 The PCE peer must not initiate auxiliary connection before having 203 completed the connection setup overthe main connection; it must setup 204 and maintain auxiliary connections with the PCE peer only while the 205 corresponding main connection is alive. The connection setup for 206 auxiliary connections is the same as for the main connection. The 207 procedure of auxiliary connection is as following: 209 PCC sends OPEN message to initiate the main connection. The 210 auxiliary connections capability is filled in the OPEN object and 211 carried in the OPEN message. 213 PCE sends OPEN message to PCC carring the auxiliary connections 214 capability in the OPEN message too. 216 After receiving the OPEN message from PCE, PCC establishes PCEP 217 session, and sends the keepalive message to enable the keepalive 218 mechanism. The keepalive message is transported relying on the main 219 connection. If one end of the main connection session receives no 220 message before the DeadTimer expires, it declares the session dead. 222 Once the main connection session and the transport connection for the 223 auxiliary connection are established, the PCC and PCE initiatet the 224 auxiliary connections PCEP session establishment. 226 After receiving the OPEN message from the PCEP peer, the other PCEP 227 peer establishes PCEP session, and sends the keepalive message to 228 enable the keepalive mechanism. The keepalive message is transported 229 relying on the auxiliary connection. If one end of the auxiliary 230 connection session receives no message before the DeadTimer expires, 231 it declares the session dead and close the auxiliary connection. If 232 the PCEP peer notices that the main connection session is dead, the 233 auxiliary connection will be closed. 235 +-+-+ +-+-+ 236 |PCC| |PCE| 237 +-+-+ +-+-+ 238 | | 239 | Open msg(C->E, | 240 | Main Connection) | 241 |------------------------>| 242 | | 243 | | 244 | Open msg(E->C, | 245 | Main Connection) | 246 |<------------------------| 247 | | 248 | Keepalive | 249 | (Main Connection) | 250 |------------------------>| 251 | | 252 | Keepalive | 253 | (Main Connection) | 254 |<------------------------| 255 | | 256 | Open msg(C->E, | 257 | auxiliary Connection) | 258 |------------------------>| 259 | | 260 | Open msg(E->C, | 261 | Main Connection) | 262 |<------------------------| 263 | Keepalive | 264 | (auxiliary Connection) | 265 |------------------------>| 266 | | 267 | Keepalive | 268 | (auxiliary Connection) | 269 |<------------------------| 271 Figure 2 Initialization Phase 273 4.4. Termination of the Auxiliary Connections PCEP Session 275 The termination of the auxiliary connections PCEP session could be 276 triggered by the close of main connection or the auxiliary 277 connection's PCEP peer itself. 279 If PCC desires to close the main connection, PCC sends the close 280 message to PCE. When PCE receives the close message, it closes all 281 the auxiliary connections with the PCC firstly, then clears all the 282 states related to pending requests previously sent to the PCC and 283 closes the main connection. The procedure is described in figure 2. 285 Similarly, if the PCE desires to close the main connection, The PCC 286 close all the auxiliary connections with the PCE firstly, then clears 287 all the states related to pending requests previously sent to the PCE 288 and closes the main connection. 290 +-+-+ +-+-+ 291 |PCC| |PCE| 292 +-+-+ +-+-+ 293 | | 294 | Close msg(C->E, | 295 | Main Connection) | 296 |------------------------>| 297 | | 298 | | 1)Close message received 299 | | 300 | | 2)Close auxliary connection 301 | | 302 | | 3)Close main connection 304 Figure 3 Close Main Connection 306 When one of the PCEP peers desires to terminate an auxiliary 307 connection PCEP session, it first sends a PCEP Close message based on 308 the auxiliary connection and then closes the TCP connection. 310 If the PCEP session is terminated by the PCE, the PCC clears all the 311 states related to auxiliary connection pending requests previously 312 sent to the PCE. 314 Similarly, if the PCC terminates a PCEP session, the PCE clears all 315 auxiliary connection pending path computation requests sent by the 316 PCC in question as well as the related states. Figure 3 shows the 317 procedure. 319 +-+-+ +-+-+ 320 |PCC| |PCE| 321 +-+-+ +-+-+ 322 | | 323 | Close msg(C->E, | 324 | auxiliary Connection) | 325 |------------------------>| 326 | | 327 | | 328 | | 1)Close message received 329 | | 330 | | 2)Close auxliary connection 331 | | 332 | | 334 Figure 4 Close Auxliary Connection 336 5. Security Considerations 338 TBD 340 6. IANA Considerations 342 There is no need additional IANA allocation for this document. 344 7. Acknowledgements 346 TBD. 348 8. Informative References 350 [I-D.ietf-pce-pce-initiated-lsp] 351 Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "PCEP 352 Extensions for PCE-initiated LSP Setup in a Stateful PCE 353 Model", draft-ietf-pce-pce-initiated-lsp-07 (work in 354 progress), July 2016. 356 [I-D.ietf-pce-stateful-pce] 357 Crabbe, E., Minei, I., Medved, J., and R. Varga, "PCEP 358 Extensions for Stateful PCE", draft-ietf-pce-stateful- 359 pce-18 (work in progress), December 2016. 361 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 362 Requirement Levels", BCP 14, RFC 2119, 363 DOI 10.17487/RFC2119, March 1997, 364 . 366 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 367 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 368 DOI 10.17487/RFC5440, March 2009, 369 . 371 Authors' Addresses 373 Fangwei Hu 374 ZTE Corporation 375 No.889 Bibo Rd 376 Shanghai 201203 377 China 379 Phone: +86 21 68896273 380 Email: hu.fangwei@zte.com.cn 382 Ran Chen 383 ZTE Corporation 384 No.50 Software Avenue,Yuhuatai District 385 Nanjing, Jiangsu Province 210012 386 China 388 Phone: +86 025 88014636 389 Email: chen.ran@zte.com.cn