idnits 2.17.1 draft-kouvelas-lisp-map-server-reliable-transport-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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([I-D.kouvelas-lisp-reliable-transport]), 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 (July 6, 2015) is 3218 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'RFC5925' is mentioned on line 685, but not defined == Missing Reference: 'RFC4895' is mentioned on line 686, but not defined == Unused Reference: 'I-D.ietf-lisp-lcaf' is defined on line 723, but no explicit reference was found in the text == Unused Reference: 'RFC6830' is defined on line 740, but no explicit reference was found in the text == Outdated reference: A later version (-22) exists of draft-ietf-lisp-lcaf-10 ** Obsolete normative reference: RFC 6830 (Obsoleted by RFC 9300, RFC 9301) ** Obsolete normative reference: RFC 6833 (Obsoleted by RFC 9301) Summary: 3 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Cassar 3 Internet-Draft Cisco Systems 4 Intended status: Experimental I. Kouvelas 5 Expires: January 7, 2016 Arista Networks Inc. 6 D. Lewis 7 J. Arango 8 J. Leong 9 Cisco Systems 10 July 6, 2015 12 LISP Map Server Reliable Transport 13 draft-kouvelas-lisp-map-server-reliable-transport-00.txt 15 Abstract 17 The communication between LISP ETRs and Map-Servers is based on 18 unreliable UDP message exchange coupled with periodic message 19 transmission in order to maintain soft state. The drawback of 20 periodic messaging is the constant load imposed on both the ETR and 21 the Map-Server. New use cases for LISP have increased the amount of 22 state that needs to be communicated with requirements that are not 23 satisfied by the current mechanism. This document introduces the use 24 of a reliable transport for ETR to Map-Server communication in order 25 to eliminate the periodic messaging overhead, while providing 26 reliability, flow-control and endpoint liveness detection. 28 This document has been renamed to avoid ambiguity. It is an update 29 to [I-D.kouvelas-lisp-reliable-transport]. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at http://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on January 7, 2016. 48 Copyright Notice 50 Copyright (c) 2015 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (http://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 66 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 3 67 3. Message Format . . . . . . . . . . . . . . . . . . . . . . . 4 68 4. Session Establishment . . . . . . . . . . . . . . . . . . . . 5 69 5. Error Notifications . . . . . . . . . . . . . . . . . . . . . 5 70 6. EID Prefix Registration . . . . . . . . . . . . . . . . . . . 7 71 6.1. Reliable Mapping Registration Messages . . . . . . . . . 7 72 6.1.1. Registration Message . . . . . . . . . . . . . . . . 8 73 6.1.2. Registration Acknowledgement Message . . . . . . . . 8 74 6.1.3. Registration Rejected Message . . . . . . . . . . . . 9 75 6.1.4. Registration Refresh Message . . . . . . . . . . . . 10 76 6.1.5. Mapping Notification Message . . . . . . . . . . . . 10 77 6.2. ETR Behavior . . . . . . . . . . . . . . . . . . . . . . 11 78 6.3. Map-Server Behavior . . . . . . . . . . . . . . . . . . . 15 79 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 80 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 81 8.1. LISP Reliable Transport Message Types . . . . . . . . . . 16 82 8.2. Transport Protocol Port Numbers . . . . . . . . . . . . . 16 83 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 84 10. Normative References . . . . . . . . . . . . . . . . . . . . 17 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 87 1. Introduction 89 The communication channel between LISP ETRs and Map-Servers is based 90 on unreliable UDP message exchange [RFC6833]. Where required, 91 reliability is pursued through periodic retransmissions that maintain 92 soft state on the peer. Map-Register messages are retransmitted 93 every minute by an ETR and the Map-Server times out its state if the 94 state is not refreshed for three successive periods. When 95 registering multiple EID-Prefixes, the ETR includes multiple mapping 96 records in the Map-Register message. Packet size limitations provide 97 an upper bound to the number of mapping records that can be placed in 98 each Map-Register message. When the ETR has more EID-Prefixes to 99 register than can be packed in a single Map-Register message, the 100 mapping records for the EID-Prefixes are split across multiple Map- 101 Register messages. 103 The drawback of the periodic registration is the constant load that 104 it introduces on both the ETR and the Map-Server. The ETR uses 105 resources to periodically build and transmit the Map-Register 106 messages, and to process the resulting Map-Notify messages issued by 107 the Map-Server. The Map-Server uses resources to process the 108 received Map-Register messages, update the corresponding registration 109 state, and build and transmit the matching Map-Notify messages. When 110 the number of EID-Prefixes to be registered by an ETR is small, the 111 resulting load imposed by periodic registrations may not be 112 significant. The ETR will only transmit a single Map-Register 113 message each period that contains a small number of mapping records. 115 In some LISP deployments, a large set of EID-Prefixes must be 116 registered by each ETR (e.g. mobility, database redistribution). Use 117 cases with a large set of EID-Prefixes behind an ETR will result in a 118 much higher load. An example is LISP mobility deployments where EID- 119 Prefixes are limited to host entries. ETRs may have thousands of 120 hosts to register resulting in hundreds of Map-Register and Map- 121 Notify messages per registration period. 123 A transport is required for the ETR to Map-Server communication that 124 provides reliability, flow-control and endpoint liveness 125 notifications. This document describes the use of TCP or SCTP as a 126 LISP reliable transport. The initial application for the LISP 127 reliable transport session is the support of scalable EID prefix 128 registration. The reliable session mechanism is defined to be 129 extensible so that it can support additional LISP communication 130 requirements as they arise using a single reliable transport session 131 between an ETR and a Map-Server. The use of the reliable transport 132 session for EID prefix registration is an alternative and does not 133 replace the existing UDP based mechanism. 135 2. Requirements Notation 137 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 138 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 139 document are to be interpreted as described in [RFC2119]. 141 3. Message Format 143 A single LISP reliable transport session may carry information for 144 multiple LISP applications. One such application is the registration 145 of EID to RLOC mappings that operates over a session between an ETR 146 and a Map-Server. Communication over a session is based on the 147 exchange of messages. This document defines a base set of messages 148 to support session establishment and management. It also defines the 149 messages for the EID to RLOC mapping registration application. 151 To support protocol extensibility when new applications, or 152 extensions to existing applications are introduced, the messages are 153 based on a TLV format. 155 0 1 2 3 156 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 157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 158 | Type | Length | 159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 160 | Message ID | 161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 162 | Message Data ... 163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 164 | Message End Marker | 165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 167 Reliable transport message format 169 o Type: 16 bit type field identifying the message type. 171 o Length: 16 bit field that provides the total size of the message 172 in octets including the length, type and end marker fields. The 173 length allows the receiver to locate the next message in the TCP 174 stream. The minimum value of the length field is 8. 176 o ID: A 32-bit value that identifies the message. May be used by 177 the receiver to identify the message in replies or notification 178 messages. 180 o Data: Type specific message contents. 182 o End Marker: A 32-bit message end marker that must be set to 183 0x9FACADE9. The End Marker is used by the receiver to validate 184 that it has correctly parsed or skipped a message and provides a 185 method to detect formatting errors. Note that message data may 186 also contain this marker, and that the marker itself is not 187 sufficient for parsing the message. 189 The base message format does not indicate how the peer should deal 190 with the message in cases where the message type is not supported/ 191 understood. This is best dealt with by the application. For 192 example, in case an error notification is returned, or an expected 193 acknowledgement message is not received, the application might choose 194 various courses of action; from simply logging that the feature is 195 not supported, all the way to tearing the relationship with the peer 196 down for the feature, or for all LISP features. 198 4. Session Establishment 200 To ensure backwards compatibility, the map server and ETR MUST 201 communicate via unreliable UDP messages until a TCP session between 202 the two is sucessfully established. 204 The map server authenticates the ETR with the authentication data 205 contained in the first UDP map-register message it receives from the 206 ETR. Once the ETR is authenticated, the map server performs a 207 passive open by listening on TCP port 4342, and does not qualify the 208 remote port. As a security measure, the map server accepts TCP 209 connections only from those ETRs that have been authenticated via UDP 210 map-register messages. 212 The ETR assumes the active role of the TCP session establishment by 213 connecting to the map server once it has received a UDP map-notify 214 message. 216 When a TCP session goes down, UDP authentication must take place 217 before a new TCP session is established. The map-server will not 218 accept a connection from the ETR until a UDP map-register has been 219 received. Similarly, the ETR will not attempt to establish a session 220 with the map server until an UDP map-notify message has been 221 received. 223 A single reliable transport session is established between the map 224 server and the ETR to cover all communication needs. For example, an 225 ETR that has EID prefix registrations for multiple EID instances and 226 EID address families will only establish a single session with the 227 map server. 229 5. Error Notifications 231 The error notification message is used to communicate base reliable 232 transport session communication errors. LISP applications making use 233 of the reliable transport session and having to communicate 234 application specific errors must define their own messages to do so. 235 An error notification is issued when the receiver of a message does 236 not recognize the message type or cannot parse the message contents. 238 The notification includes the offending message type and ID and as 239 much of the offending message data as the notification sender wishes 240 to. 242 0 1 2 3 243 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 244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 245 | Type = 16 | Length | 246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 247 | Message ID | 248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 249 | Error Code | Reserved | 250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 251 | Offending Message Type | Offending Message Length | 252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 253 | Offending Message ID | 254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 255 | Offending Message Data ... 256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 257 | Message End Marker | 258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 260 Error notification message format 262 o Error Code: An 8 bit field identifying the type of error that 263 occurred. Defined errors are: 265 * Unrecognized message type. 267 * Message format error. 269 o Reserved: Set to zero by the sender and ignored by the receiver. 271 o Offending Message Type: 16 bit type field identifying the message 272 type of the offending message that triggered this error 273 notification. This is copied from the Type field of the offending 274 message. 276 o Offending Message Length: 16 bit field that provides the total 277 size of the offending message in octets. This is copied from the 278 Length field of the offending message. 280 o Offending Message ID: A 32-bit field that is set to the Message ID 281 field of the offending message. 283 o Offending Message Data: The Data from the offending message that 284 triggered this error notification. The sender of the notification 285 may include as much of the original data as is deemed necessary. 287 The length of the Offending Message Data field is not provided by 288 the Offending Message Length field and is determined by 289 subtracting the size of the other fields in the message from the 290 Length field. It is valid to not include any of the offending 291 message data when sending an error notification. 293 o End Marker: A 32-bit message end marker that must be set to 294 0x9FACADE9. The End Marker is used by the receiver to validate 295 that it has correctly parsed or skipped a message and provides a 296 method to detect formatting errors. Note that message data may 297 also contain this marker, and that the marker itself is not 298 sufficient for parsing the message. 300 An error notification cannot be the offending message in another 301 error notification and MUST NOT trigger such a message. 303 6. EID Prefix Registration 305 EID prefix registration uses the reliable transport session between 306 an ETR and a Map-Server to communicate the ETR local EID database EID 307 to RLOC mappings to the Map-Server. In contrast to the UDP based 308 periodic registration, mapping information over the reliable 309 transport session is only sent when there is new information 310 available for the Map-Server. The Map-Server does not maintain a 311 timer to expire registrations communicated over the reliable 312 transport session. Instead an explicit de-registration (a 313 registration carrying a zero TTL) is needed to delete the state 314 maintained by the Map-Server. 316 The key used to identify registration mapping records in the ETR to 317 Map-Server communication is the EID prefix. The prefix may be 318 specified using an LCAF encoding that includes an EID instance ID. 320 When the reliable transport session goes down, registration mappings 321 learned by the Map-Server are treated as periodic UDP registrations 322 and a timer is used to expire them after 3 minutes. During this 323 period UDP based registrations or the re-establishment of the 324 reliable transport session and subsequent communication of a new 325 mapping can update the EID prefix mapping state. 327 6.1. Reliable Mapping Registration Messages 329 This section defines the LISP reliable transport session messages 330 used to communicate local EID database registrations between the ETR 331 and the Map-Server. 333 6.1.1. Registration Message 335 The reliable transport Registration message is used to communicate 336 EID to RLOC mapping registrations from the ETR to the Map-Server. 337 The Registration message uses exactly the same format as the UDP Map- 338 Register message but instead of the IP/UDP header, the Map-Register 339 is placed within the value section of the reliable transport TLV. A 340 common message format is proposed to leverage the authentication 341 features built into the UDP Map-Register message and increase code 342 reuse. 344 0 1 2 3 345 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 346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 347 | Type = 17 | Length | 348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 349 | Message ID | 350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 351 | Map-Register message ... 352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 353 ... Map-Register message | 354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 355 | Message End Marker | 356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 358 Registration message format 360 6.1.2. Registration Acknowledgement Message 362 The Acknowledgement message is sent from the Map-Server to the ETR to 363 confirm successful registration of an EID prefix previously 364 communicated by a reliable transport session Registration message. 365 The Registration Acknowledgement message does not carry a mapping 366 record (the map servers view of the mapping). This is accomplished 367 by the LISP reliable transport Map Notification message. 369 0 1 2 3 370 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 371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 372 | Type = 18 | Length | 373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 374 | Message ID | 375 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 376 | EID-Prefix-AFI | EID-Prefix ... 377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 378 | Message End Marker | 379 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 381 Registration Acknowledgement message format 383 o EID-Prefix AFI: Address family identifier for the EID prefix in 384 the following field. 386 o EID-Prefix: The EID prefix from the received Registration. 388 6.1.3. Registration Rejected Message 390 Negative acknowledgement sent from the Map-Server to the ETR to 391 indicate that the registration of a specific EID prefix was rejected. 392 The ETR must keep track of the fact that the registration of the EID 393 prefix was rejected by the Map-Server and be prepared to re-register 394 the mapping when requested through a failed Registration Refresh 395 request. 397 0 1 2 3 398 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 399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 400 | Type = 19 | Length | 401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 402 | Message ID | 403 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 404 | Rejection code | EID-Prefix-AFI | 405 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 406 | EID-Prefix ... 407 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 408 | Message End Marker | 409 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 411 Registration Rejected message format 413 o Rejection code: Code identifying the reason for which the Map- 414 Server rejected the registration. Codes: 416 * 1 - Not a valid site EID prefix. 418 * 2 - Authentication failure. 420 * 3 - Locator set not allowed. 422 o EID-Prefix AFI: Address family identifier for the EID prefix in 423 the following field. 425 o EID-Prefix: The EID prefix from the received Registration. 427 6.1.4. Registration Refresh Message 429 Sent by the Map-Server to the ETR to request the re-transmission of 430 EID prefix database mapping Registration messages. 432 0 1 2 3 433 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 434 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 435 | Type = 20 | Length | 436 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 437 | Message ID | 438 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 439 |R| Reserved | EID-Prefix-AFI | 440 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 441 | EID-Prefix ... 442 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 443 | Message End Marker | 444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 446 Registration Refresh message format 448 o R: Request from the ETR to only refresh registrations that have 449 been previously rejected by the Map-Server. 451 o EID prefix, and its more specifics, to refresh. The prefix can be 452 in LCAF format allowing specification of a complete refresh 453 (unspecified prefix), refresh of all the prefixes under an EID 454 instance or even of more specific registrations under a specific 455 EID prefix. 457 6.1.5. Mapping Notification Message 459 Mapping Notification messages communicate the Map-Server view of the 460 mapping for an EID prefix and no longer serve as a registration 461 acknowledgement. Mapping Notifications do not need message level 462 authentication as they are received over a reliable transport session 463 to a known Map-Server. Note that reliable transport Mapping 464 Notification messages do not reuse the UDP Map-Notify message format. 466 0 1 2 3 467 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 468 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 469 | Type = 21 | Length | 470 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 471 | Message ID | 472 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 473 | Mapping Record ... 474 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 475 ... Mapping Record | 476 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 477 | Message End Marker | 478 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 480 Mapping Notification message format 482 6.2. ETR Behavior 484 The ETR operates the following per EID prefix, per MS state machine 485 that defines the reliable transport EID prefix registration behavior. 487 There are five states: 489 o No state: The local EID database prefix does not exist. 491 o Periodic: The local EID database prefix is being periodically 492 registered through UDP Map-Register messages as specified in []. 494 o Stable: From the ETR's perspective, no registrations are due to be 495 sent to the peer. The session to the peer is up, and the peer has 496 either acknowledged the registration, or is expected to request a 497 refresh in the future. 499 o AckWait: A Registration message for the prefix has been 500 transmitted to the Map-Server and the ETR is waiting for either a 501 Registration Acknowledge or Registration Rejected reply from the 502 Map-Server. 504 o Reject: The reliable transport registration for the local EID 505 database prefix was rejected by the Map-Server. From the ETR's 506 perspective, no registration is due to the peer AND the peer is 507 known to have rejected the registration. 509 The following events drive the state transitions: 511 o DB creation: The local EID database entry for the EID prefix is 512 created. 514 o DB deletion: The local EID database entry for the EID prefix is 515 deleted. 517 o DB change: The mapping contents or authentication information for 518 the local EID database entry changes. 520 o Session up: The reliable transport session to the Map-Server is 521 established. 523 o Session down: The reliable transport session the Map-Server goes 524 down. 526 o Recv Refresh: A Registration refresh message is received from the 527 Map-Server. 529 o Recv ACK: A Registration Acknowledge message is received from the 530 Map-Server. 532 o Recv Rejected: A Registration Rejected message is received from 533 the Map-Server. 535 o Periodic timer: The timer that drives generation of periodic UDP 536 Map-Register messages fires. 538 The state machine is: 540 +--------------------+--------------------------------------+ 541 | | Prev State | 542 | Event +-------------------+------------------+ 543 | | No state | Periodic | 544 +--------------------+-------------------+------------------+ 545 | DB creation | -> Periodic | N/A | 546 | [session down] | A1 | | 547 +--------------------+-------------------+------------------+ 548 | DB creation | -> AckWait | N/A | 549 | [session up] | A2 | | 550 +--------------------+-------------------+------------------+ 551 | DB deletion | N/A | -> No state | 552 | | | A3 | 553 +--------------------+-------------------+------------------+ 554 | DB change | N/A | - | 555 | | | A1 | 556 +--------------------+-------------------+------------------+ 557 | Session up | - | -> Stable | 558 | | | A4 | 559 +--------------------+-------------------+------------------+ 560 | Session down | - | N/A | 561 | | | | 562 +--------------------+-------------------+------------------+ 563 | Recv Refresh | - | N/A | 564 | | | | 565 +--------------------+-------------------+------------------+ 566 | Recv Refresh | - | N/A | 567 | [rejected] | | | 568 +--------------------+-------------------+------------------+ 569 | Recv ACK | - | N/A | 570 | | | | 571 +--------------------+-------------------+------------------+ 572 | Recv Rejection | - | N/A | 573 | | | | 574 +--------------------+-------------------+------------------+ 575 | Timer | N/A | - | 576 | | | A5 | 577 +--------------------+-------------------+------------------+ 579 xTR per EID prefix per MS state machine 581 +-----------------+-----------------------------------------------+ 582 | | Prev State | 583 | Event +---------------+---------------+---------------+ 584 | | Stable | AckWait | Rejected | 585 +-----------------+---------------+---------------+---------------+ 586 | DB creation | N/A | N/A | N/A | 587 | | | | | 588 +-----------------+---------------+---------------+---------------+ 589 | DB deletion | -> No state | -> No state | -> No state | 590 | | A6 | A6 | | 591 +-----------------+---------------+---------------+---------------+ 592 | DB change | -> AckWait | - | -> AckWait | 593 | | A2 | A2 | A2 | 594 +-----------------+---------------+---------------+---------------+ 595 | Session up | N/A | N/A | N/A | 596 | | | | | 597 +-----------------+---------------+---------------+---------------+ 598 | Session down | -> Periodic | -> Periodic | -> Periodic | 599 | | A7 | A7 | A7 | 600 +-----------------+---------------+---------------+---------------+ 601 | Recv Refresh | -> AckWait | - | -> AckWait | 602 | | A2 | A2 | A2 | 603 +-----------------+---------------+---------------+---------------+ 604 | Recv Refresh | - | - | -> AckWait | 605 | [rejected] | | A2 | A2 | 606 +-----------------+---------------+---------------+---------------+ 607 | Recv ACK | - | -> Stable | -> AckWait | 608 | | | | A2 | 609 +-----------------+---------------+---------------+---------------+ 610 | Recv Rejection | -> Rejected | -> Rejected | - | 611 | | | | | 612 +-----------------+---------------+---------------+---------------+ 613 | Timer | N/A | N/A | N/A | 614 | | | | | 615 +-----------------+---------------+---------------+---------------+ 617 xTR per EID prefix per MS state machine 619 Action descriptions: 621 o A1: Start periodic registration timer with zero delay. 623 o A2: Send Registration over reliable transport session. 625 o A3: Send UDP registration with zero TTL. 627 o A4: Stop periodic registration timer. 629 o A7: Send UDP registration and start periodic registration timer 630 with registration period. 632 o A6: Send Registration with TTL zero over reliable transport 633 session. 635 o A7: Start periodic registration timer with registration period. 637 All timer start actions must be jittered. 639 When the reliable transport session is established the state machine 640 moves into the Stable state without first registering the EID prefix 641 over the reliable transport session. The subsequent refresh issued 642 by the Map-Server will trigger the registration message to be sent. 643 This model will allow future optimisations where the Map-Server may 644 retain registration state from a previous instantiation of the 645 reliable transport session with the ETR and only request the refresh 646 of EID prefix state beyond some negotiated session progress marker. 648 Aa Map-Server authentication key change is treated as a DB change 649 event and will result in triggering a new Registration message to be 650 transmitted. 652 6.3. Map-Server Behavior 654 Received registrations create/update or delete mapping state. 656 A refresh for an unspecified prefix is sent when a session is first 657 established to obtain the complete database contents from the ETR. 659 Refresh for rejected registrations sent (R bit set) when a new EID 660 prefix is configured on the Map-Server. 662 Rejection sent to the ETR when an EID prefix that is registered is 663 deconfigured. 665 Rejected Refresh (R bit set) sent when authentication for an EID 666 prefix changes followed by a Rejection for existing registrations 667 which fail authentication following change. 669 Mapping Notification message sent whenever the mapping for a 670 registered or more specific prefix for which notifications are 671 requested changes. ETR acknowledgement or rejection messaging for 672 Mapping Notification is not required because the ETR decides how to 673 process the message based on the registered mapping information. If 674 the mapping information changes the resulting registration will 675 trigger a new Mapping Notification message from the Map-Server. 677 7. Security Considerations 679 The LISP reliable transport session SHOULD be authenticated. On 680 controlled RLOC networks that can guarantee that the source RLOC 681 address of data packets cannot be spoofed, the authentication check 682 can be a source address validation on the reliable transport packets. 683 When the RLOC network does not provide such guarantees, reliable 684 transport authentication SHOULD be used. Implementations SHOULD 685 support the TCP Authentication Option (TCP-AO) [RFC5925] and SCTP 686 Authenticated Chunks [RFC4895]. 688 8. IANA Considerations 690 8.1. LISP Reliable Transport Message Types 692 Assignment of new LISP reliable transport message types is done 693 according to the "IETF Review" model defined in [RFC5266]. 695 The initial content of the registry should be as follows. 697 Type Name Reference 698 ----------- ---------------------------------------- -------------- 699 0-15 Reserved This document 700 16 Error Notification This document 701 17 Registration Message This document 702 18 Registration Acknowledgement Message This document 703 19 Registration Rejected Message This document 704 20 Registration Refresh Message This document 705 21 Mapping Notification Message This document 706 22-30 Reserved for EID membership distribution TBD 707 31-64999 Unassigned 708 65000-65535 Reserved for Experimental Use 710 8.2. Transport Protocol Port Numbers 712 TCP port 4342 already reserved for LISP CONS that is now obsolete. 713 Repurpose for reliable transport over TCP. Reserve an SCTP port. 715 9. Acknowledgments 717 The authors would like to thank Noel Chiappa, Dino Farinacci, Jesper 718 Skriver, Johnson Leong, Andre Pelletier and Les Ginsberg for their 719 contributions to this document. 721 10. Normative References 723 [I-D.ietf-lisp-lcaf] 724 Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical 725 Address Format (LCAF)", draft-ietf-lisp-lcaf-10 (work in 726 progress), June 2015. 728 [I-D.kouvelas-lisp-reliable-transport] 729 Cassar, C., Kouvelas, I., and D. Lewis, "LISP Reliable 730 Transport", draft-kouvelas-lisp-reliable-transport-02 731 (work in progress), March 2015. 733 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 734 Requirement Levels", BCP 14, RFC 2119, March 1997. 736 [RFC5266] Devarapalli, V. and P. Eronen, "Secure Connectivity and 737 Mobility Using Mobile IPv4 and IKEv2 Mobility and 738 Multihoming (MOBIKE)", BCP 136, RFC 5266, June 2008. 740 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The 741 Locator/ID Separation Protocol (LISP)", RFC 6830, January 742 2013. 744 [RFC6833] Fuller, V. and D. Farinacci, "Locator/ID Separation 745 Protocol (LISP) Map-Server Interface", RFC 6833, January 746 2013. 748 Authors' Addresses 750 Chris Cassar 751 Cisco Systems 752 10 New Square Park 753 Bedfont Lakes, Feltham TW14 8HA 754 United Kingdom 756 Email: ccassar@cisco.com 758 Isidor Kouvelas 759 Arista Networks Inc. 760 5453 Great America Parkway 761 Santa Clara, CA 95054 762 USA 764 Email: kouvelas@cisco.com 765 Darrel Lewis 766 Cisco Systems 767 Tasman Drive 768 San Jose, CA 95134 769 USA 771 Email: darlewis@cisco.com 773 Jesus Arango 774 Cisco Systems 775 Tasman Drive 776 San Jose, CA 95134 777 USA 779 Email: jearango@cisco.com 781 Johnson Leong 782 Cisco Systems 783 Tasman Drive 784 San Jose, CA 95134 785 USA 787 Email: joleong@cisco.com