LISP Map Server Reliable Transport

The communication channel between LISP ETRs and Map-Servers is based on unreliable UDP message exchange . Where required, reliability is pursued through periodic retransmissions that maintain soft state on the peer. Map-Register messages are retransmitted every minute by an ETR and the Map-Server times out its state if the state is not refreshed for three successive periods. When registering multiple EID-Prefixes, the ETR includes multiple mapping records in the Map-Register message. Packet size limitations provide an upper bound to the number of mapping records that can be placed in each Map-Register message. When the ETR has more EID-Prefixes to register than can be packed in a single Map-Register message, the mapping records for the EID-Prefixes are split across multiple Map-Register messages. The drawback of the periodic registration is the constant load that it introduces on both the ETR and the Map-Server. The ETR uses resources to periodically build and transmit the Map-Register messages, and to process the resulting Map-Notify messages issued by the Map-Server. The Map-Server uses resources to process the received Map-Register messages, update the corresponding registration state, and build and transmit the matching Map-Notify messages. When the number of EID-Prefixes to be registered by an ETR is small, the resulting load imposed by periodic registrations may not be significant. The ETR will only transmit a single Map-Register message each period that contains a small number of mapping records. In some LISP deployments, a large set of EID-Prefixes must be registered by each ETR (e.g. mobility, database redistribution). Use cases with a large set of EID-Prefixes behind an ETR will result in a much higher load. An example is LISP mobility deployments where EID-Prefixes are limited to host entries. ETRs may have thousands of hosts to register resulting in hundreds of Map-Register and Map-Notify messages per registration period. A transport is required for the ETR to Map-Server communication that provides reliability, flow-control and endpoint liveness notifications. This document describes the use of TCP or SCTP as a LISP reliable transport. The initial application for the LISP reliable transport session is the support of scalable EID prefix registration. The reliable session mechanism is defined to be extensible so that it can support additional LISP communication requirements as they arise using a single reliable transport session between an ETR and a Map-Server. The use of the reliable transport session for EID prefix registration is an alternative and does not replace the existing UDP based mechanism.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in .

A single LISP reliable transport session may carry information for multiple LISP applications. One such application is the registration of EID to RLOC mappings that operates over a session between an ETR and a Map-Server. Communication over a session is based on the exchange of messages. This document defines a base set of messages to support session establishment and management. It also defines the messages for the EID to RLOC mapping registration application. To support protocol extensibility when new applications, or extensions to existing applications are introduced, the messages are based on a TLV format.

Reliable transport message format Type: 16 bit type field identifying the message type. Length: 16 bit field that provides the total size of the message in octets including the length, type and end marker fields. The length allows the receiver to locate the next message in the TCP stream. The minimum value of the length field is 8. ID: A 32-bit value that identifies the message. May be used by the receiver to identify the message in replies or notification messages. Data: Type specific message contents. End Marker: A 32-bit message end marker that must be set to 0x9FACADE9. The End Marker is used by the receiver to validate that it has correctly parsed or skipped a message and provides a method to detect formatting errors. Note that message data may also contain this marker, and that the marker itself is not sufficient for parsing the message. The base message format does not indicate how the peer should deal with the message in cases where the message type is not supported/understood. This is best dealt with by the application. For example, in case an error notification is returned, or an expected acknowledgement message is not received, the application might choose various courses of action; from simply logging that the feature is not supported, all the way to tearing the relationship with the peer down for the feature, or for all LISP features.

To ensure backwards compatibility, the map server and ETR MUST communicate via unreliable UDP messages until a TCP session between the two is sucessfully established. The map server authenticates the ETR with the authentication data contained in the first UDP map-register message it receives from the ETR. Once the ETR is authenticated, the map server performs a passive open by listening on TCP port 4342, and does not qualify the remote port. As a security measure, the map server accepts TCP connections only from those ETRs that have been authenticated via UDP map-register messages. The ETR assumes the active role of the TCP session establishment by connecting to the map server once it has received a UDP map-notify message. When a TCP session goes down, UDP authentication must take place before a new TCP session is established. The map-server will not accept a connection from the ETR until a UDP map-register has been received. Similarly, the ETR will not attempt to establish a session with the map server until an UDP map-notify message has been received. A single reliable transport session is established between the map server and the ETR to cover all communication needs. For example, an ETR that has EID prefix registrations for multiple EID instances and EID address families will only establish a single session with the map server.

The error notification message is used to communicate base reliable transport session communication errors. LISP applications making use of the reliable transport session and having to communicate application specific errors must define their own messages to do so. An error notification is issued when the receiver of a message does not recognize the message type or cannot parse the message contents. The notification includes the offending message type and ID and as much of the offending message data as the notification sender wishes to.

Error notification message format Error Code: An 8 bit field identifying the type of error that occurred. Defined errors are: Unrecognized message type. Message format error. Reserved: Set to zero by the sender and ignored by the receiver. Offending Message Type: 16 bit type field identifying the message type of the offending message that triggered this error notification. This is copied from the Type field of the offending message. Offending Message Length: 16 bit field that provides the total size of the offending message in octets. This is copied from the Length field of the offending message. Offending Message ID: A 32-bit field that is set to the Message ID field of the offending message. Offending Message Data: The Data from the offending message that triggered this error notification. The sender of the notification may include as much of the original data as is deemed necessary. The length of the Offending Message Data field is not provided by the Offending Message Length field and is determined by subtracting the size of the other fields in the message from the Length field. It is valid to not include any of the offending message data when sending an error notification. End Marker: A 32-bit message end marker that must be set to 0x9FACADE9. The End Marker is used by the receiver to validate that it has correctly parsed or skipped a message and provides a method to detect formatting errors. Note that message data may also contain this marker, and that the marker itself is not sufficient for parsing the message. An error notification cannot be the offending message in another error notification and MUST NOT trigger such a message.

EID prefix registration uses the reliable transport session between an ETR and a Map-Server to communicate the ETR local EID database EID to RLOC mappings to the Map-Server. In contrast to the UDP based periodic registration, mapping information over the reliable transport session is only sent when there is new information available for the Map-Server. The Map-Server does not maintain a timer to expire registrations communicated over the reliable transport session. Instead an explicit de-registration (a registration carrying a zero TTL) is needed to delete the state maintained by the Map-Server. The key used to identify registration mapping records in the ETR to Map-Server communication is the EID prefix. The prefix may be specified using an LCAF encoding that includes an EID instance ID. When the reliable transport session goes down, registration mappings learned by the Map-Server are treated as periodic UDP registrations and a timer is used to expire them after 3 minutes. During this period UDP based registrations or the re-establishment of the reliable transport session and subsequent communication of a new mapping can update the EID prefix mapping state.

This section defines the LISP reliable transport session messages used to communicate local EID database registrations between the ETR and the Map-Server.

The reliable transport Registration message is used to communicate EID to RLOC mapping registrations from the ETR to the Map-Server. The Registration message uses exactly the same format as the UDP Map-Register message but instead of the IP/UDP header, the Map-Register is placed within the value section of the reliable transport TLV. A common message format is proposed to leverage the authentication features built into the UDP Map-Register message and increase code reuse.

Registration message format

The Acknowledgement message is sent from the Map-Server to the ETR to confirm successful registration of an EID prefix previously communicated by a reliable transport session Registration message. The Registration Acknowledgement message does not carry a mapping record (the map servers view of the mapping). This is accomplished by the LISP reliable transport Map Notification message.

Registration Acknowledgement message format EID-Prefix AFI: Address family identifier for the EID prefix in the following field. EID-Prefix: The EID prefix from the received Registration.

Negative acknowledgement sent from the Map-Server to the ETR to indicate that the registration of a specific EID prefix was rejected. The ETR must keep track of the fact that the registration of the EID prefix was rejected by the Map-Server and be prepared to re-register the mapping when requested through a failed Registration Refresh request.

Registration Rejected message format Rejection code: Code identifying the reason for which the Map-Server rejected the registration. Codes: 1 - Not a valid site EID prefix. 2 - Authentication failure. 3 - Locator set not allowed. EID-Prefix AFI: Address family identifier for the EID prefix in the following field. EID-Prefix: The EID prefix from the received Registration.

Sent by the Map-Server to the ETR to request the re-transmission of EID prefix database mapping Registration messages.

Registration Refresh message format R: Request from the ETR to only refresh registrations that have been previously rejected by the Map-Server. EID prefix, and its more specifics, to refresh. The prefix can be in LCAF format allowing specification of a complete refresh (unspecified prefix), refresh of all the prefixes under an EID instance or even of more specific registrations under a specific EID prefix.

Mapping Notification messages communicate the Map-Server view of the mapping for an EID prefix and no longer serve as a registration acknowledgement. Mapping Notifications do not need message level authentication as they are received over a reliable transport session to a known Map-Server. Note that reliable transport Mapping Notification messages do not reuse the UDP Map-Notify message format.

Mapping Notification message format

The ETR operates the following per EID prefix, per MS state machine that defines the reliable transport EID prefix registration behavior. There are five states: No state: The local EID database prefix does not exist. Periodic: The local EID database prefix is being periodically registered through UDP Map-Register messages as specified in []. Stable: From the ETR's perspective, no registrations are due to be sent to the peer. The session to the peer is up, and the peer has either acknowledged the registration, or is expected to request a refresh in the future. AckWait: A Registration message for the prefix has been transmitted to the Map-Server and the ETR is waiting for either a Registration Acknowledge or Registration Rejected reply from the Map-Server. Reject: The reliable transport registration for the local EID database prefix was rejected by the Map-Server. From the ETR's perspective, no registration is due to the peer AND the peer is known to have rejected the registration. The following events drive the state transitions: DB creation: The local EID database entry for the EID prefix is created. DB deletion: The local EID database entry for the EID prefix is deleted. DB change: The mapping contents or authentication information for the local EID database entry changes. Session up: The reliable transport session to the Map-Server is established. Session down: The reliable transport session the Map-Server goes down. Recv Refresh: A Registration refresh message is received from the Map-Server. Recv ACK: A Registration Acknowledge message is received from the Map-Server. Recv Rejected: A Registration Rejected message is received from the Map-Server. Periodic timer: The timer that drives generation of periodic UDP Map-Register messages fires. The state machine is:

Periodic | N/A | | [session down] | A1 | | +--------------------+-------------------+------------------+ | DB creation | -> AckWait | N/A | | [session up] | A2 | | +--------------------+-------------------+------------------+ | DB deletion | N/A | -> No state | | | | A3 | +--------------------+-------------------+------------------+ | DB change | N/A | - | | | | A1 | +--------------------+-------------------+------------------+ | Session up | - | -> Stable | | | | A4 | +--------------------+-------------------+------------------+ | Session down | - | N/A | | | | | +--------------------+-------------------+------------------+ | Recv Refresh | - | N/A | | | | | +--------------------+-------------------+------------------+ | Recv Refresh | - | N/A | | [rejected] | | | +--------------------+-------------------+------------------+ | Recv ACK | - | N/A | | | | | +--------------------+-------------------+------------------+ | Recv Rejection | - | N/A | | | | | +--------------------+-------------------+------------------+ | Timer | N/A | - | | | | A5 | +--------------------+-------------------+------------------+ ]]> xTR per EID prefix per MS state machine

No state | -> No state | -> No state | | | A6 | A6 | | +-----------------+---------------+---------------+---------------+ | DB change | -> AckWait | - | -> AckWait | | | A2 | A2 | A2 | +-----------------+---------------+---------------+---------------+ | Session up | N/A | N/A | N/A | | | | | | +-----------------+---------------+---------------+---------------+ | Session down | -> Periodic | -> Periodic | -> Periodic | | | A7 | A7 | A7 | +-----------------+---------------+---------------+---------------+ | Recv Refresh | -> AckWait | - | -> AckWait | | | A2 | A2 | A2 | +-----------------+---------------+---------------+---------------+ | Recv Refresh | - | - | -> AckWait | | [rejected] | | A2 | A2 | +-----------------+---------------+---------------+---------------+ | Recv ACK | - | -> Stable | -> AckWait | | | | | A2 | +-----------------+---------------+---------------+---------------+ | Recv Rejection | -> Rejected | -> Rejected | - | | | | | | +-----------------+---------------+---------------+---------------+ | Timer | N/A | N/A | N/A | | | | | | +-----------------+---------------+---------------+---------------+ ]]> xTR per EID prefix per MS state machine Action descriptions: A1: Start periodic registration timer with zero delay. A2: Send Registration over reliable transport session. A3: Send UDP registration with zero TTL. A4: Stop periodic registration timer. A7: Send UDP registration and start periodic registration timer with registration period. A6: Send Registration with TTL zero over reliable transport session. A7: Start periodic registration timer with registration period. All timer start actions must be jittered. When the reliable transport session is established the state machine moves into the Stable state without first registering the EID prefix over the reliable transport session. The subsequent refresh issued by the Map-Server will trigger the registration message to be sent. This model will allow future optimisations where the Map-Server may retain registration state from a previous instantiation of the reliable transport session with the ETR and only request the refresh of EID prefix state beyond some negotiated session progress marker. Aa Map-Server authentication key change is treated as a DB change event and will result in triggering a new Registration message to be transmitted.

Received registrations create/update or delete mapping state. A refresh for an unspecified prefix is sent when a session is first established to obtain the complete database contents from the ETR. Refresh for rejected registrations sent (R bit set) when a new EID prefix is configured on the Map-Server. Rejection sent to the ETR when an EID prefix that is registered is deconfigured. Rejected Refresh (R bit set) sent when authentication for an EID prefix changes followed by a Rejection for existing registrations which fail authentication following change. Mapping Notification message sent whenever the mapping for a registered or more specific prefix for which notifications are requested changes. ETR acknowledgement or rejection messaging for Mapping Notification is not required because the ETR decides how to process the message based on the registered mapping information. If the mapping information changes the resulting registration will trigger a new Mapping Notification message from the Map-Server.

The LISP reliable transport session SHOULD be authenticated. On controlled RLOC networks that can guarantee that the source RLOC address of data packets cannot be spoofed, the authentication check can be a source address validation on the reliable transport packets. When the RLOC network does not provide such guarantees, reliable transport authentication SHOULD be used. Implementations SHOULD support the TCP Authentication Option (TCP-AO) [RFC5925] and SCTP Authenticated Chunks [RFC4895].

Assignment of new LISP reliable transport message types is done according to the "IETF Review" model defined in . The initial content of the registry should be as follows.

TCP port 4342 already reserved for LISP CONS that is now obsolete. Repurpose for reliable transport over TCP. Reserve an SCTP port.

The authors would like to thank Noel Chiappa, Dino Farinacci, Jesper Skriver, Johnson Leong, Andre Pelletier and Les Ginsberg for their contributions to this document.