idnits 2.17.1 draft-gu-nvo3-vntp-03.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 an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) 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 (October 19, 2015) is 3111 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: 'RFC2234' is defined on line 455, but no explicit reference was found in the text == Unused Reference: 'RFC2328' is defined on line 459, but no explicit reference was found in the text == Unused Reference: 'RFC5709' is defined on line 463, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-nvo3-arch' is defined on line 470, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-nvo3-hpvr2nve-cp-req' is defined on line 475, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-nvo3-nve-nva-cp-req' is defined on line 480, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2234 (Obsoleted by RFC 4234) == Outdated reference: A later version (-08) exists of draft-ietf-nvo3-arch-03 == Outdated reference: A later version (-17) exists of draft-ietf-nvo3-hpvr2nve-cp-req-03 == Outdated reference: A later version (-05) exists of draft-ietf-nvo3-nve-nva-cp-req-04 Summary: 2 errors (**), 0 flaws (~~), 11 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NVO3 Z. Gu 3 Internet-Draft Independent Reseacher 4 Intended status: Standards Track B. Khasnabish 5 Expires: April 21, 2016 ZTE (TX) Inc. 6 T. Ao 7 Fangwei. Hu 8 ZTE Corp 9 October 19, 2015 11 Virtual Network Transport Protocol (VNTP) 12 draft-gu-nvo3-vntp-03 14 Abstract 16 This document describes the overlay Virtual Network Transport 17 Protocol (VNTP), which defines the interactions between NVE and NVA/ 18 NVE and the relevant message to support virtual network 19 implementation. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on April 21, 2016. 38 Copyright Notice 40 Copyright (c) 2015 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Conventions Used in This Document . . . . . . . . . . . . . . 2 57 3. VNTP Overview . . . . . . . . . . . . . . . . . . . . . . . . 3 58 4. VNTP Message Format . . . . . . . . . . . . . . . . . . . . . 3 59 4.1. VNTP Header format . . . . . . . . . . . . . . . . . . . 4 60 4.2. VNTP Data Format . . . . . . . . . . . . . . . . . . . . 6 61 5. The Operations of NVE . . . . . . . . . . . . . . . . . . . . 9 62 6. The operations of NVA . . . . . . . . . . . . . . . . . . . . 9 63 7. Interaction with TS/Hypervisor-NVE protocol . . . . . . . . . 10 64 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 65 9. IANA/IEEE Considerations . . . . . . . . . . . . . . . . . . 10 66 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 67 10.1. Normative references . . . . . . . . . . . . . . . . . . 10 68 10.2. Informative References . . . . . . . . . . . . . . . . . 11 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 71 1. Introduction 73 [RFC7364] and [RFC7365] describe the need and some characteristics of 74 the interaction between NVE and NVA. [draft-ietf-nvo3-arch-03] has a 75 more detailed architectural description about NVE-NVA protocol. And 76 [draft-ietf-nvo3-nve-nva-cp-req-03] discusses the detail requirements 77 of NVE-NVA protocol. 79 This draft defines a NVE-NVA protocol, Virtual Network Transport 80 Protocol (VNTP). It belongs to the second model mentioned in [draft- 81 ietf-nvo3-arch-03], e.g. NVE interacts with NVA directly. It 82 defines the interactions between NVE and NVA/NVE and the relevant 83 message formats to support virtual network implementation and fulfill 84 the requirements described in the related documents mentioned above. 86 VNTP can be based on a broad transport mechanism such as TCP or UDP, 87 or even IP. A new TCP/UDP port or protocol number allocation is 88 needed if the transport mechanism is decided by NVO3 WG. 90 2. Conventions Used in This Document 92 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 93 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 94 document are to be interpreted as described in RFC 2119 [RFC2119]. 96 3. VNTP Overview 98 VNTP based on some basic assumptions and the main points include: 100 1), the first-hand mapping information provided by NVE, either 101 configured by administrator or automatically created. 102 Architecturally, VNTP also support other mapping resources such as 103 downloaded from NVA. 105 2), NVE registers to NVA per VN and NVA may store two lists of NVE, 106 the first one is all NVEs in a VN and another one is about all the 107 VNs NVE resides. 109 3), when mapping change occurs in NVE, the NVE send update message to 110 NVA to initiate the synchronization procedures and NVA then forward 111 the update message to all other NVEs in the same VN. Optionally, NVA 112 can store all the update information for latter use. 114 4), when a NVE register to a VN and some update messages received by 115 NVA, the NVA may use the messages stored or request the related NVEs 116 to send the update again to synchronize. 118 5), if NVA obtains the mapping information from other resources 119 different from NVE, for example configured by administrator or from 120 VM Orchestration, it sends the mapping/update information to all NVEs 121 in the same VN. 123 The VNTP procedures can be simplified to implement by point-to-point 124 communication between NVE and NVA. So the NVE-NVA interaction can be 125 based on a broad transport mechanism such as TCP, UDP or even IP. A 126 new TCP/UDP port or protocol number allocation is needed if the 127 transport mechanism is decided. 129 4. VNTP Message Format 131 Figure 1 shows the VNTP message format. VNTP message format 132 definition is based on some transport mechanism, such as TCP or UDP 133 transport protocol, or even based on IP, and further using its data/ 134 payload field. 136 1 2 3 137 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 138 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 139 | Ver | Type | Number | AuType | 140 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 141 | Checksum | Length | 142 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 143 | Authentication | 144 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 145 | Authentication | 146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 147 | | 148 | DATA | 149 | | 150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 151 Figure 1 VNTP message format 153 Figure 1 155 4.1. VNTP Header format 157 The following are the Header fields definition. 159 Ver (8bit): for VNTP version. 161 Type (8bit): for VNTP Type Command or result/response definition. 163 Number (8bit): item/entry number of data field. 165 AuType and Authentication(length TBD): for authentication type and 166 packet authentication.(Refer to RFC2328, especially section A and D; 167 and further to RFC5709 for authentication update discussion.) 169 Checksum (16bit): checksum of the whole VNTP packet except 170 authentication field. 172 Length (16bit): total packet octets including header. 174 Figure 2 shows detail Type definition. 176 0 1 2 3 4 5 6 7 177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 178 |E/A|C/R| CMD/RSP | AdrType | 179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 180 Figure 2 Type format 182 Figure 2 184 E/A (1bit): set to 1, NVE->NVA; 186 set to 0, NVA->NVE. 188 C/R (1bit): 1, CMD/RSP represents Command; 190 0, CMD/RSP represents Response/Result. 192 CMD/RSP: A command from NVE or NVA, or a response to the command 194 Detailed definition for the Command from NVE ( C/R = 1, E/A = 1 ) . 196 CMD Description 198 000 NVE registration: The NVE registers to VNs. 200 001 NVE deregistration: The NVE de-registers from VNs. 202 010 NVE Update: NVE's mapping information has been update. 204 011-111: Reserved for future use 206 Detailed definition for the Command from NVA ( C/R = 1, E/A = 0 ) 208 CMD Description 210 000 Request for NVE Mapping information 212 001 Nullify NVE Mapping information/NVE deregistration 214 010 (NVE registered) Update NVE mapping information 216 011-111: Reserved for future use 218 Detailed definition for NVA/NVE Response/Result (C/R = 0, E/A = 0/1 ) 220 RSP Description 222 000 command executed successfully 223 001-011 Reserved for future definition 225 100 command execution failed 227 101 command execution partially successful (Optional reasons ) 229 110-111 Reserved for future definition 231 AdrType (3bit): NVE address type. Detailed definition as following. 233 AdrType Description 235 000 IPv4 237 001 IPv6 239 010-111 Reserved 241 4.2. VNTP Data Format 243 VNTP Data field varies according to different command. 245 For Register/Deregister Command, the field contains the NVE's address 246 and a VN-ID set. In the VN-ID set, each entry for one VN-ID. See 247 Figure 3. 249 1 2 3 250 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 251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 252 | AT | NVE Address | 253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 254 | VN-ID set | 255 | | 256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 257 Figure 3 Data format for Register/Deregister command 259 Figure 3 261 The VN-ID set field would be Null, that means the NVE should be un- 262 reachable anymore. 264 For Request mapping info command, the field contains the Inner 265 address set, each entry for one inner address. See figure 4. 267 1 2 3 268 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 269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 270 | VN-ID | Reserve | 271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 272 | Mapping/Address set | 273 | | 274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 275 Figure 4 Data format for Request command 277 Figure 4 279 The mapping/Address set field would be Null, that means NVA is 280 requesting all the Inner address in this VN. 282 For Nullify Command, the field contains the NVE address. The command 283 is used by NVA to notify all the NVEs in the same VN that the NVE is 284 not reachable, all the mapping information relate to the NVE should 285 be removed. 287 1 2 3 288 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 289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 290 | AT | NVE Address | 291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 292 Figure 5 Data format for Nullify command 294 Figure 5 296 For Update Command, it also may include some entries, each entry has 297 the detailed definition refers to Figure 3. 299 1 2 3 300 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 301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 302 | AT | NVE Address | 303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 304 | VN-ID | 305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 306 | Op | R | AT | Mapping/Address set | 307 | | 308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 310 Figure 6 Data Format for Update command 312 Figure 6 314 The field means as following. 316 Op (3bit): for Operation Code. 318 Detailed definition for the Op field. 320 Op Description 322 000 Update add 324 001 Update delete 326 010 Update set to migration status 328 011 Update set to normal/non-migration status 330 100-111 Reserved for future use 332 AT (3bit): for Address Type. 334 Detailed definition for the AT field . 336 AT Description 338 000 IPv4 340 001 IPv6 342 010 MAC 344 011-111 Reserved 346 R (2bit): for Reserved. 348 NVE Address (length variable according AT): the outer address of 349 mapping. If the update command is from NVE, the field is the local 350 NVE address. If the update command is from NVA, the field is the 351 remote NVE. 353 NV-ID: The Virtual Network ID that relate to the mapping information. 355 Mapping/Address (length variable according AT): each/inner Address 356 needs updating. For the Update delete operation, if the field is 357 Null, that means all the mapping info in this VN should be deleted. 359 5. The Operations of NVE 361 In the context of VNTP, the NVE works include: 363 1), If a VNI is created, the NVE will send Register command to NVA to 364 register the VNI/NVE in the VN. 366 2), If a VNI is being deleted, the NVE will send update information 367 to NVA to inform all the NVE related VN entry will be invalid. Or 368 the NVA gets this information through the keep alive message, then 369 nullify the all entries from this NVE_s VN. 371 3), If entries in the NVE have changed, for example, a new entry 372 added or an existing entry deleted or become invalid, then the NVE 373 will send update information to the NVA. Individual or batch update 374 are supported. 376 4), And further, NVE also support tenant system migration. 378 5), The NVE accepts the updates from NVA and update the VRF table. 379 The commands may be individual update or updates resulted from NVE 380 failure. 382 6), Keep alive. Monitor the connection between NVE and NVA. 384 7), If the command not properly executed retransfer the command again 385 for pre-setting times. 387 8), When NVA is unavailable or the NVA connection lost, optionally 388 the NVE can connect other NVEs in the VN directly to keep the VN 389 synchronized. 391 9), Security functions. TBD. 393 6. The operations of NVA 395 1), VNI creation 397 2), Form list of NVEs in the VN based on NVE Registration. 399 3), Accept updates from NVE and forward these updates to all other 400 NVEs in the VN. Optionally, NVA store the update information for 401 late use. 403 4), If NVE not register but update accepted, NVA may register it and 404 forward the update to other NVEs. 406 5), if NVE registering after some updates then NVA will forward the 407 stored updates to this NVE. Or NVA send request message to all other 408 registered NVE for update if the previous updates not stored in NVA. 409 And the NVA controls the updates only to this NVE other than all 410 registered NVEs in the VN. 412 6), Keep alive. Monitor the connection between NVE and NVA. 414 7), if the command not properly executed NVA can retransfer the 415 command again for pre-setting times. 417 8), When NVE in the VN is unavailable or the NVE connection lost, 418 optionally the NVA can flood this NVE unreachable information to all 419 other NVEs in the VN to keep the VN synchronized. 421 9), VNI delete. If there are not any VM or NVE in the VN, or the 422 customer does not need the VN anymore then the NVA delete the VNI and 423 release all the resources occupied by this VN. 425 10), Security functions. TBD. 427 7. Interaction with TS/Hypervisor-NVE protocol 429 Generally, VNTP can run independent of TS/Hypervisor-NVE protocol, 430 but the interaction triggered by VRF changes because of the operation 431 of TS/Hypervisor-NVE protocol . If the direct interaction is needed 432 for further study. 434 8. Security Considerations 436 VNTP should support NVE and NVA mutual authentication and other 437 security functions. The authentication has been covered by this 438 draft, and the further security functions can be support through 439 VNTP's command reservations. 441 9. IANA/IEEE Considerations 443 VNTP needs a specific IP protocol value, or TCP/UDP port allocation 444 if the transport mechanism is chosen. 446 10. References 448 10.1. Normative references 450 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 451 Requirement Levels", BCP 14, RFC 2119, 452 DOI 10.17487/RFC2119, March 1997, 453 . 455 [RFC2234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 456 Specifications: ABNF", RFC 2234, DOI 10.17487/RFC2234, 457 November 1997, . 459 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, 460 DOI 10.17487/RFC2328, April 1998, 461 . 463 [RFC5709] Bhatia, M., Manral, V., Fanto, M., White, R., Barnes, M., 464 Li, T., and R. Atkinson, "OSPFv2 HMAC-SHA Cryptographic 465 Authentication", RFC 5709, DOI 10.17487/RFC5709, October 466 2009, . 468 10.2. Informative References 470 [I-D.ietf-nvo3-arch] 471 Black, D., Hudson, J., Kreeger, L., Lasserre, M., and T. 472 Narten, "An Architecture for Overlay Networks (NVO3)", 473 draft-ietf-nvo3-arch-03 (work in progress), March 2015. 475 [I-D.ietf-nvo3-hpvr2nve-cp-req] 476 Yizhou, L., Yong, L., Kreeger, L., Narten, T., and D. 477 Black, "Split-NVE Control Plane Requirements", draft-ietf- 478 nvo3-hpvr2nve-cp-req-03 (work in progress), August 2015. 480 [I-D.ietf-nvo3-nve-nva-cp-req] 481 Kreeger, L., Dutt, D., Narten, T., and D. Black, "Network 482 Virtualization NVE to NVA Control Protocol Requirements", 483 draft-ietf-nvo3-nve-nva-cp-req-04 (work in progress), July 484 2015. 486 [RFC7364] Narten, T., Ed., Gray, E., Ed., Black, D., Fang, L., 487 Kreeger, L., and M. Napierala, "Problem Statement: 488 Overlays for Network Virtualization", RFC 7364, 489 DOI 10.17487/RFC7364, October 2014, 490 . 492 [RFC7365] Lasserre, M., Balus, F., Morin, T., Bitar, N., and Y. 493 Rekhter, "Framework for Data Center (DC) Network 494 Virtualization", RFC 7365, DOI 10.17487/RFC7365, October 495 2014, . 497 Authors' Addresses 499 Zhongyu Gu 500 Independent Reseacher 502 Email: guzhongyu2015@sina.com 503 Bhumip Khasnabish 504 ZTE (TX) Inc. 505 55 Madison Ave, Suite 302 506 Morristown, New Jersey 07960 507 USA 509 Phone: +001-781-752-8003 510 Email: vumip1@gmail.com, bhumip.khasnabish@ztetx.com 511 URI: http://tinyurl.com/bhumip/ 513 Ting Ao 514 ZTE Corp 515 No.889 Bibo Rd 516 Shanghai 517 China 519 Phone: +86 21 68897642 520 Email: ao.ting@zte.com.cn 522 Fangwei Hu 523 ZTE Corp 524 No.889 Bibo Rd 525 Shanghai 201203 526 China 528 Phone: +86 21 68896273 529 Email: hu.fangwei@zte.com.cn