idnits 2.17.1 draft-kouvelas-lisp-reliable-transport-02.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 26, 2015) is 3318 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'RFC5925' is mentioned on line 668, but not defined == Missing Reference: 'RFC4895' is mentioned on line 669, but not defined == Unused Reference: 'I-D.ietf-lisp-lcaf' is defined on line 706, but no explicit reference was found in the text == Unused Reference: 'RFC6830' is defined on line 718, but no explicit reference was found in the text == Outdated reference: A later version (-22) exists of draft-ietf-lisp-lcaf-07 ** Obsolete normative reference: RFC 6830 (Obsoleted by RFC 9300, RFC 9301) ** Obsolete normative reference: RFC 6833 (Obsoleted by RFC 9301) Summary: 2 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 I. Kouvelas 4 Intended status: Experimental D. Lewis 5 Expires: September 27, 2015 Cisco Systems 6 March 26, 2015 8 LISP Reliable Transport 9 draft-kouvelas-lisp-reliable-transport-02.txt 11 Abstract 13 The communication between LISP ETRs and Map-Servers is based on 14 unreliable UDP message exchange coupled with periodic message 15 transmission in order to maintain soft state. The drawback of 16 periodic messaging is the constant load imposed on both the ETR and 17 the Map-Server. New use cases for LISP have increased the amount of 18 state that needs to be communicated with requirements that are not 19 satisfied by the current mechanism. This document introduces the use 20 of a reliable transport for ETR to Map-Server communication in order 21 to eliminate the periodic messaging overhead, while providing 22 reliability, flow-control and endpoint liveness detection. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on September 27, 2015. 41 Copyright Notice 43 Copyright (c) 2015 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 3 60 3. Message Format . . . . . . . . . . . . . . . . . . . . . . . 3 61 4. Session Establishment . . . . . . . . . . . . . . . . . . . . 5 62 5. Error Notifications . . . . . . . . . . . . . . . . . . . . . 5 63 6. EID Prefix Registration . . . . . . . . . . . . . . . . . . . 7 64 6.1. Reliable Mapping Registration Messages . . . . . . . . . 7 65 6.1.1. Registration Message . . . . . . . . . . . . . . . . 7 66 6.1.2. Registration Acknowledgement Message . . . . . . . . 8 67 6.1.3. Registration Rejected Message . . . . . . . . . . . . 9 68 6.1.4. Registration Refresh Message . . . . . . . . . . . . 9 69 6.1.5. Mapping Notification Message . . . . . . . . . . . . 10 70 6.2. ETR Behavior . . . . . . . . . . . . . . . . . . . . . . 11 71 6.3. Map-Server Behavior . . . . . . . . . . . . . . . . . . . 15 72 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 73 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 74 8.1. LISP Reliable Transport Message Types . . . . . . . . . . 16 75 8.2. Transport Protocol Port Numbers . . . . . . . . . . . . . 16 76 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 77 10. Normative References . . . . . . . . . . . . . . . . . . . . 17 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 80 1. Introduction 82 The communication channel between LISP ETRs and Map-Servers is based 83 on unreliable UDP message exchange [RFC6833]. Where required, 84 reliability is pursued through periodic retransmissions that maintain 85 soft state on the peer. Map-Register messages are retransmitted 86 every minute by an ETR and the Map-Server times out its state if the 87 state is not refreshed for three successive periods. When 88 registering multiple EID-Prefixes, the ETR includes multiple mapping 89 records in the Map-Register message. Packet size limitations provide 90 an upper bound to the number of mapping records that can be placed in 91 each Map-Register message. When the ETR has more EID-Prefixes to 92 register than can be packed in a single Map-Register message, the 93 mapping records for the EID-Prefixes are split across multiple Map- 94 Register messages. 96 The drawback of the periodic registration is the constant load that 97 it introduces on both the ETR and the Map-Server. The ETR uses 98 resources to periodically build and transmit the Map-Register 99 messages, and to process the resulting Map-Notify messages issued by 100 the Map-Server. The Map-Server uses resources to process the 101 received Map-Register messages, update the corresponding registration 102 state, and build and transmit the matching Map-Notify messages. When 103 the number of EID-Prefixes to be registered by an ETR is small, the 104 resulting load imposed by periodic registrations may not be 105 significant. The ETR will only transmit a single Map-Register 106 message each period that contains a small number of mapping records. 108 In some LISP deployments, a large set of EID-Prefixes must be 109 registered by each ETR (e.g. mobility, database redistribution). Use 110 cases with a large set of EID-Prefixes behind an ETR will result in a 111 much higher load. An example is LISP mobility deployments where EID- 112 Prefixes are limited to host entries. ETRs may have thousands of 113 hosts to register resulting in hundreds of Map-Register and Map- 114 Notify messages per registration period. 116 A transport is required for the ETR to Map-Server communication that 117 provides reliability, flow-control and endpoint liveness 118 notifications. This document describes the use of TCP or SCTP as a 119 LISP reliable transport. The initial application for the LISP 120 reliable transport session is the support of scalable EID prefix 121 registration. The reliable session mechanism is defined to be 122 extensible so that it can support additional LISP communication 123 requirements as they arise using a single reliable transport session 124 between an ETR and a Map-Server. The use of the reliable transport 125 session for EID prefix registration is an alternative and does not 126 replace the existing UDP based mechanism. 128 2. Requirements Notation 130 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 131 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 132 document are to be interpreted as described in [RFC2119]. 134 3. Message Format 136 A single LISP reliable transport session may carry information for 137 multiple LISP applications. One such application is the registration 138 of EID to RLOC mappings that operates over a session between an ETR 139 and a Map-Server. Communication over a session is based on the 140 exchange of messages. This document defines a base set of messages 141 to support session establishment and management. It also defines the 142 messages for the EID to RLOC mapping registration application. 144 To support protocol extensibility when new applications, or 145 extensions to existing applications are introduced, the messages are 146 based on a TLV format. 148 0 1 2 3 149 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 150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 151 | Type | Length | 152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 153 | Message ID | 154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 155 | Message Data ... 156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 157 | Message End Marker | 158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 160 Reliable transport message format 162 o Type: 16 bit type field identifying the message type. 164 o Length: 16 bit field that provides the total size of the message 165 in octets including the length, type and end marker fields. The 166 length allows the receiver to locate the next message in the TCP 167 stream. The minimum value of the length field is 8. 169 o ID: A 32-bit value that identifies the message. May be used by 170 the receiver to identify the message in replies or notification 171 messages. 173 o Data: Type specific message contents. 175 o End Marker: A 32-bit message end marker that must be set to 176 0x9FACADE9. The End Marker is used by the receiver to validate 177 that it has correctly parsed or skipped a message and provides a 178 method to detect formatting errors. Note that message data may 179 also contain this marker, and that the marker itself is not 180 sufficient for parsing the message. 182 The base message format does not indicate how the peer should deal 183 with the message in cases where the message type is not supported/ 184 understood. This is best dealt with by the application. For 185 example, in case an error notification is returned, or an expected 186 acknowledgement message is not received, the application might choose 187 various courses of action; from simply logging that the feature is 188 not supported, all the way to tearing the relationship with the peer 189 down for the feature, or for all LISP features. 191 4. Session Establishment 193 The LISP router that performs the active open initiates the 194 connection from a locally generated source transport port number to 195 the well-known destination transport port assigned to LISP. The LISP 196 router that performs the passive open listens on the well-known local 197 transport port and does not qualify the remote transport port number. 198 In the ETR to Map-Server reliable transport session, the ETR assumes 199 the active role and the Map-Server passively accepts connections. 201 A single reliable transport session can be established between a pair 202 of LISP peers to cover all communication needs. For example, an ETR 203 that has EID prefix registrations for multiple EID instances and EID 204 address families might only establish a single session with the Map- 205 Server. 207 When using TCP and symmetric connection establishment LISP must 208 perform collision detection and duplicate session elimination. To 209 accomplish that, LISP peer ID messages will be exchanged between the 210 peers once a session is established. If duplicate sessions are 211 detected then the one that was initiated by the router with the 212 higher ID is kept and the other session is torn down. TBD 214 5. Error Notifications 216 The error notification message is used to communicate base reliable 217 transport session communication errors. LISP applications making use 218 of the reliable transport session and having to communicate 219 application specific errors must define their own messages to do so. 220 An error notification is issued when the receiver of a message does 221 not recognize the message type or cannot parse the message contents. 222 The notification includes the offending message type and ID and as 223 much of the offending message data as the notification sender wishes 224 to. 226 0 1 2 3 227 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 228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 229 | Type = 16 | Length | 230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 231 | Message ID | 232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 233 | Error Code | Reserved | 234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 235 | Offending Message Type | Offending Message Length | 236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 237 | Offending Message ID | 238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 239 | Offending Message Data ... 240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 241 | Message End Marker | 242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 244 Error notification message format 246 o Error Code: An 8 bit field identifying the type of error that 247 occurred. Defined errors are: 249 * Unrecognized message type. 251 * Message format error. 253 o Reserved: Set to zero by the sender and ignored by the receiver. 255 o Offending Message Type: 16 bit type field identifying the message 256 type of the offending message that triggered this error 257 notification. This is copied from the Type field of the offending 258 message. 260 o Offending Message Length: 16 bit field that provides the total 261 size of the offending message in octets. This is copied from the 262 Length field of the offending message. 264 o Offending Message ID: A 32-bit field that is set to the Message ID 265 field of the offending message. 267 o Offending Message Data: The Data from the offending message that 268 triggered this error notification. The sender of the notification 269 may include as much of the original data as is deemed necessary. 270 The length of the Offending Message Data field is not provided by 271 the Offending Message Length field and is determined by 272 subtracting the size of the other fields in the message from the 273 Length field. It is valid to not include any of the offending 274 message data when sending an error notification. 276 o End Marker: A 32-bit message end marker that must be set to 277 0x9FACADE9. The End Marker is used by the receiver to validate 278 that it has correctly parsed or skipped a message and provides a 279 method to detect formatting errors. Note that message data may 280 also contain this marker, and that the marker itself is not 281 sufficient for parsing the message. 283 An error notification cannot be the offending message in another 284 error notification and MUST NOT trigger such a message. 286 6. EID Prefix Registration 288 EID prefix registration uses the reliable transport session between 289 an ETR and a Map-Server to communicate the ETR local EID database EID 290 to RLOC mappings to the Map-Server. In contrast to the UDP based 291 periodic registration, mapping information over the reliable 292 transport session is only sent when there is new information 293 available for the Map-Server. The Map-Server does not maintain a 294 timer to expire registrations communicated over the reliable 295 transport session. Instead an explicit de-registration (a 296 registration carrying a zero TTL) is needed to delete the state 297 maintained by the Map-Server. 299 The key used to identify registration mapping records in the ETR to 300 Map-Server communication is the EID prefix. The prefix may be 301 specified using an LCAF encoding that includes an EID instance ID. 303 When the reliable transport session goes down, registration mappings 304 learned by the Map-Server are treated as periodic UDP registrations 305 and a timer is used to expire them after 3 minutes. During this 306 period UDP based registrations or the re-establishment of the 307 reliable transport session and subsequent communication of a new 308 mapping can update the EID prefix mapping state. 310 6.1. Reliable Mapping Registration Messages 312 This section defines the LISP reliable transport session messages 313 used to communicate local EID database registrations between the ETR 314 and the Map-Server. 316 6.1.1. Registration Message 318 The reliable transport Registration message is used to communicate 319 EID to RLOC mapping registrations from the ETR to the Map-Server. 320 The Registration message uses exactly the same format as the UDP Map- 321 Register message but instead of the IP/UDP header, the Map-Register 322 is placed within the value section of the reliable transport TLV. A 323 common message format is proposed to leverage the authentication 324 features built into the UDP Map-Register message and increase code 325 reuse. 327 0 1 2 3 328 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 329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 330 | Type = 17 | Length | 331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 332 | Message ID | 333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 334 | Map-Register message ... 335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 336 ... Map-Register message | 337 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 338 | Message End Marker | 339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 341 Registration message format 343 6.1.2. Registration Acknowledgement Message 345 The Acknowledgement message is sent from the Map-Server to the ETR to 346 confirm successful registration of an EID prefix previously 347 communicated by a reliable transport session Registration message. 348 The Registration Acknowledgement message does not carry a mapping 349 record (the map servers view of the mapping). This is accomplished 350 by the LISP reliable transport Map Notification message. 352 0 1 2 3 353 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 354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 355 | Type = 18 | Length | 356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 357 | Message ID | 358 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 359 | EID-Prefix-AFI | EID-Prefix ... 360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 361 | Message End Marker | 362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 364 Registration Acknowledgement message format 366 o EID-Prefix AFI: Address family identifier for the EID prefix in 367 the following field. 369 o EID-Prefix: The EID prefix from the received Registration. 371 6.1.3. Registration Rejected Message 373 Negative acknowledgement sent from the Map-Server to the ETR to 374 indicate that the registration of a specific EID prefix was rejected. 375 The ETR must keep track of the fact that the registration of the EID 376 prefix was rejected by the Map-Server and be prepared to re-register 377 the mapping when requested through a failed Registration Refresh 378 request. 380 0 1 2 3 381 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 382 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 383 | Type = 19 | Length | 384 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 385 | Message ID | 386 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 387 | Rejection code | EID-Prefix-AFI | 388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 389 | EID-Prefix ... 390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 391 | Message End Marker | 392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 394 Registration Rejected message format 396 o Rejection code: Code identifying the reason for which the Map- 397 Server rejected the registration. Codes: 399 * 1 - Not a valid site EID prefix. 401 * 2 - Authentication failure. 403 * 3 - Locator set not allowed. 405 o EID-Prefix AFI: Address family identifier for the EID prefix in 406 the following field. 408 o EID-Prefix: The EID prefix from the received Registration. 410 6.1.4. Registration Refresh Message 412 Sent by the Map-Server to the ETR to request the re-transmission of 413 EID prefix database mapping Registration messages. 415 0 1 2 3 416 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 417 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 418 | Type = 20 | Length | 419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 420 | Message ID | 421 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 422 |R| Reserved | EID-Prefix-AFI | 423 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 424 | EID-Prefix ... 425 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 426 | Message End Marker | 427 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 429 Registration Refresh message format 431 o R: Request from the ETR to only refresh registrations that have 432 been previously rejected by the Map-Server. 434 o EID prefix, and its more specifics, to refresh. The prefix can be 435 in LCAF format allowing specification of a complete refresh 436 (unspecified prefix), refresh of all the prefixes under an EID 437 instance or even of more specific registrations under a specific 438 EID prefix. 440 6.1.5. Mapping Notification Message 442 Mapping Notification messages communicate the Map-Server view of the 443 mapping for an EID prefix and no longer serve as a registration 444 acknowledgement. Mapping Notifications do not need message level 445 authentication as they are received over a reliable transport session 446 to a known Map-Server. Note that reliable transport Mapping 447 Notification messages do not reuse the UDP Map-Notify message format. 449 0 1 2 3 450 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 451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 452 | Type = 21 | Length | 453 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 454 | Message ID | 455 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 456 | Mapping Record ... 457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 458 ... Mapping Record | 459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 460 | Message End Marker | 461 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 463 Registration message format 465 6.2. ETR Behavior 467 The ETR operates the following per EID prefix, per MS state machine 468 that defines the reliable transport EID prefix registration behavior. 470 There are five states: 472 o No state: The local EID database prefix does not exist. 474 o Periodic: The local EID database prefix is being periodically 475 registered through UDP Map-Register messages as specified in []. 477 o Stable: From the ETR's perspective, no registrations are due to be 478 sent to the peer. The session to the peer is up, and the peer has 479 either acknowledged the registration, or is expected to request a 480 refresh in the future. 482 o AckWait: A Registration message for the prefix has been 483 transmitted to the Map-Server and the ETR is waiting for either a 484 Registration Acknowledge or Registration Rejected reply from the 485 Map-Server. 487 o Reject: The reliable transport registration for the local EID 488 database prefix was rejected by the Map-Server. From the ETR's 489 perspective, no registration is due to the peer AND the peer is 490 known to have rejected the registration. 492 The following events drive the state transitions: 494 o DB creation: The local EID database entry for the EID prefix is 495 created. 497 o DB deletion: The local EID database entry for the EID prefix is 498 deleted. 500 o DB change: The mapping contents or authentication information for 501 the local EID database entry changes. 503 o Session up: The reliable transport session to the Map-Server is 504 established. 506 o Session down: The reliable transport session the Map-Server goes 507 down. 509 o Recv Refresh: A Registration refresh message is received from the 510 Map-Server. 512 o Recv ACK: A Registration Acknowledge message is received from the 513 Map-Server. 515 o Recv Rejected: A Registration Rejected message is received from 516 the Map-Server. 518 o Periodic timer: The timer that drives generation of periodic UDP 519 Map-Register messages fires. 521 The state machine is: 523 +--------------------+--------------------------------------+ 524 | | Prev State | 525 | Event +-------------------+------------------+ 526 | | No state | Periodic | 527 +--------------------+-------------------+------------------+ 528 | DB creation | -> Periodic | N/A | 529 | [session down] | A1 | | 530 +--------------------+-------------------+------------------+ 531 | DB creation | -> AckWait | N/A | 532 | [session up] | A2 | | 533 +--------------------+-------------------+------------------+ 534 | DB deletion | N/A | -> No state | 535 | | | A3 | 536 +--------------------+-------------------+------------------+ 537 | DB change | N/A | - | 538 | | | A1 | 539 +--------------------+-------------------+------------------+ 540 | Session up | - | -> Stable | 541 | | | A4 | 542 +--------------------+-------------------+------------------+ 543 | Session down | - | N/A | 544 | | | | 545 +--------------------+-------------------+------------------+ 546 | Recv Refresh | - | N/A | 547 | | | | 548 +--------------------+-------------------+------------------+ 549 | Recv Refresh | - | N/A | 550 | [rejected] | | | 551 +--------------------+-------------------+------------------+ 552 | Recv ACK | - | N/A | 553 | | | | 554 +--------------------+-------------------+------------------+ 555 | Recv Rejection | - | N/A | 556 | | | | 557 +--------------------+-------------------+------------------+ 558 | Timer | N/A | - | 559 | | | A5 | 560 +--------------------+-------------------+------------------+ 562 xTR per EID prefix per MS state machine 564 +-----------------+-----------------------------------------------+ 565 | | Prev State | 566 | Event +---------------+---------------+---------------+ 567 | | Stable | AckWait | Rejected | 568 +-----------------+---------------+---------------+---------------+ 569 | DB creation | N/A | N/A | N/A | 570 | | | | | 571 +-----------------+---------------+---------------+---------------+ 572 | DB deletion | -> No state | -> No state | -> No state | 573 | | A6 | A6 | | 574 +-----------------+---------------+---------------+---------------+ 575 | DB change | -> AckWait | - | -> AckWait | 576 | | A2 | A2 | A2 | 577 +-----------------+---------------+---------------+---------------+ 578 | Session up | N/A | N/A | N/A | 579 | | | | | 580 +-----------------+---------------+---------------+---------------+ 581 | Session down | -> Periodic | -> Periodic | -> Periodic | 582 | | A7 | A7 | A7 | 583 +-----------------+---------------+---------------+---------------+ 584 | Recv Refresh | -> AckWait | - | -> AckWait | 585 | | A2 | A2 | A2 | 586 +-----------------+---------------+---------------+---------------+ 587 | Recv Refresh | - | - | -> AckWait | 588 | [rejected] | | A2 | A2 | 589 +-----------------+---------------+---------------+---------------+ 590 | Recv ACK | - | -> Stable | -> AckWait | 591 | | | | A2 | 592 +-----------------+---------------+---------------+---------------+ 593 | Recv Rejection | -> Rejected | -> Rejected | - | 594 | | | | | 595 +-----------------+---------------+---------------+---------------+ 596 | Timer | N/A | N/A | N/A | 597 | | | | | 598 +-----------------+---------------+---------------+---------------+ 600 xTR per EID prefix per MS state machine 602 Action descriptions: 604 o A1: Start periodic registration timer with zero delay. 606 o A2: Send Registration over reliable transport session. 608 o A3: Send UDP registration with zero TTL. 610 o A4: Stop periodic registration timer. 612 o A7: Send UDP registration and start periodic registration timer 613 with registration period. 615 o A6: Send Registration with TTL zero over reliable transport 616 session. 618 o A7: Start periodic registration timer with registration period. 620 All timer start actions must be jittered. 622 When the reliable transport session is established the state machine 623 moves into the Stable state without first registering the EID prefix 624 over the reliable transport session. The subsequent refresh issued 625 by the Map-Server will trigger the registration message to be sent. 626 This model will allow future optimisations where the Map-Server may 627 retain registration state from a previous instantiation of the 628 reliable transport session with the ETR and only request the refresh 629 of EID prefix state beyond some negotiated session progress marker. 631 Aa Map-Server authentication key change is treated as a DB change 632 event and will result in triggering a new Registration message to be 633 transmitted. 635 6.3. Map-Server Behavior 637 Received registrations create/update or delete mapping state. 639 A refresh for an unspecified prefix is sent when a session is first 640 established to obtain the complete database contents from the ETR. 642 Refresh for rejected registrations sent (R bit set) when a new EID 643 prefix is configured on the Map-Server. 645 Rejection sent to the ETR when an EID prefix that is registered is 646 deconfigured. 648 Rejected Refresh (R bit set) sent when authentication for an EID 649 prefix changes followed by a Rejection for existing registrations 650 which fail authentication following change. 652 Mapping Notification message sent whenever the mapping for a 653 registered or more specific prefix for which notifications are 654 requested changes. ETR acknowledgement or rejection messaging for 655 Mapping Notification is not required because the ETR decides how to 656 process the message based on the registered mapping information. If 657 the mapping information changes the resulting registration will 658 trigger a new Mapping Notification message from the Map-Server. 660 7. Security Considerations 662 The LISP reliable transport session SHOULD be authenticated. On 663 controlled RLOC networks that can guarantee that the source RLOC 664 address of data packets cannot be spoofed, the authentication check 665 can be a source address validation on the reliable transport packets. 666 When the RLOC network does not provide such guarantees, reliable 667 transport authentication SHOULD be used. Implementations SHOULD 668 support the TCP Authentication Option (TCP-AO) [RFC5925] and SCTP 669 Authenticated Chunks [RFC4895]. 671 8. IANA Considerations 673 8.1. LISP Reliable Transport Message Types 675 Assignment of new LISP reliable transport message types is done 676 according to the "IETF Review" model defined in [RFC5266]. 678 The initial content of the registry should be as follows. 680 Type Name Reference 681 ----------- ---------------------------------------- -------------- 682 0-15 Reserved This document 683 16 Error Notification This document 684 17 Registration Message This document 685 18 Registration Acknowledgement Message This document 686 19 Registration Rejected Message This document 687 20 Registration Refresh Message This document 688 21 Mapping Notification Message This document 689 22-30 Reserved for EID membership distribution TBD 690 31-64999 Unassigned 691 65000-65535 Reserved for Experimental Use 693 8.2. Transport Protocol Port Numbers 695 TCP port 4342 already reserved for LISP CONS that is now obsolete. 696 Repurpose for reliable transport over TCP. Reserve an SCTP port. 698 9. Acknowledgments 700 The authors would like to thank Noel Chiappa, Dino Farinacci, Jesper 701 Skriver, Johnson Leong, Andre Pelletier and Les Ginsberg for their 702 contributions to this document. 704 10. Normative References 706 [I-D.ietf-lisp-lcaf] 707 Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical 708 Address Format (LCAF)", draft-ietf-lisp-lcaf-07 (work in 709 progress), December 2014. 711 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 712 Requirement Levels", BCP 14, RFC 2119, March 1997. 714 [RFC5266] Devarapalli, V. and P. Eronen, "Secure Connectivity and 715 Mobility Using Mobile IPv4 and IKEv2 Mobility and 716 Multihoming (MOBIKE)", BCP 136, RFC 5266, June 2008. 718 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The 719 Locator/ID Separation Protocol (LISP)", RFC 6830, January 720 2013. 722 [RFC6833] Fuller, V. and D. Farinacci, "Locator/ID Separation 723 Protocol (LISP) Map-Server Interface", RFC 6833, January 724 2013. 726 Authors' Addresses 728 Chris Cassar 729 Cisco Systems 730 10 New Square Park 731 Bedfont Lakes, Feltham TW14 8HA 732 United Kingdom 734 Email: ccassar@cisco.com 736 Isidor Kouvelas 737 Cisco Systems 738 Monumental Plaza, Building C 739 44 Kifissias Ave. 740 Maroussi, Athens 15125 741 Greece 743 Email: kouvelas@cisco.com 744 Darrel Lewis 745 Cisco Systems 746 Tasman Drive 747 San Jose, CA 95134 748 USA 750 Email: darlewis@cisco.com