LISP support for Multi-Tuple EIDs

4.1. LISP Tunnel Routers

LISP tunnel routers with enhanced operation for Multi-Tuple Extended-EIDs, or MT-TRs (MT-xTRs and MT-RTRs), behave as specified on and [I-D.ietf-lisp-rfc6833bis], with the particularity that MT-TRs perform mapping lookups based on Extended-EIDs (n-tuples).¶

Any MT-TR must keep an internal map-cache indexed by Extended-EIDs. When a MT-TR receives a packet to encapsulate, it extracts the fields required by the n-tuple lookup in use and stores them in an Extended-EID structure. In the case of a 5-tuple lookup, it will extract the source address, destination address, level 4 protocol, source port (if any) and destination port (if any) from the packet. The MT-TR uses the Extended-EID to perform a look-up into the map-cache. The lookup process must follow the procedure described in section Section 6. If there is an entry on the map-cache that matches the Extended-EID, the MT-TR retrieves the mapping information, selects a destination RLOC and encapsulates the packet, as defined in [I-D.ietf-lisp-rfc6833bis]¶

If the map-cache of the MT-TR contains no entry for the Extended-EID, the MT-TR sends a Map-Request to a MT-MR. The MT-TR MUST be provisioned with the RLOC of at least one MT-MR. The Map-Request sent carries the Extended-EID (encoded in the specific LCAF for that Extended-EID type) in the EID-prefix field of the Map-Request. This Map-Request will eventually trigger a Map-Reply to be sent back the requester MT-TR, see section Section 4.2. This Map-Reply carries an Extended-EID on the EID-prefix field. The MT-TR stores, as defined in [I-D.ietf-lisp-rfc6833bis], the mapping for the Extended-EID.¶

4.2. Mapping System

Mapping System elements (comprising Map Servers and Map Resolvers) behave as specified on [I-D.ietf-lisp-rfc6833bis] when implementing enhanced Multi-Tuple Extended-EIDs operation, with the particularity that MT-MRs resolve Map-Requests based on Extended-EIDs and MT-MSs store mappings indexed by Extended-EIDs.¶

MT-MRs must be capable of processing Map-Requests with an Extended-EID on the EID-prefix field, of finding the appropriate MT-MS for the Extended-EID and of forwarding the Map-Request to it. This is done according to the lookup rules described in section Section 6 and using the mapping database described in section Section 7 which differs depending on the specific Extended-EID.¶

LISP elements must perform the mapping update mechanisms defined in [I-D.ietf-lisp-rfc6833bis] (e.g, SMR) using as EID the Extended-EID.¶

5.1. 5-Tuple

The 5-tuple LCAF is a combination of Application Data Type 4 and Source/Dest Type 12 LCAFs. Experimental deployment may indicate that a specific 5-tuple type LCAF is necessary.¶

6.1. 5-Tuple (Coarse)

When using a coarse lookup for 5-tuple, the encoding described in Section 5.1 is used to carry the Extended-EID. Note that a coarse lookup also covers exact lookups. The lookup is (logically) done at steps, one per each element of the tuple. The lookup MUST follow this strict order:¶

(1)

Destination address¶

(2)

Source address¶

(3)

Protocol number¶

(4)

Destination port¶

(5)

Source port¶

This means that for a given 5-tuple, the lookup process will first select from the available 5-tuples present in the system, the ones that match the destination address. Among them, those that also match the source address. This is iterated for the rest of the elements in the tuple. If a 5-tuple matches several entries, then the one with the longest prefix match or shortest port-range has priority. To clarify the process an example is provided below.¶

Suppose that a MT-MS stores the mappings indexed by the tuples (A), (B), (C), (D) and (E), and that it receives Map-Request messages carrying the Extended-EIDs (T), (U), (V), (W), (X) and (Y).¶

      dst-add     src-add    pr   dst-prt    src-prt

(A) [1.1.1.0/24, 2.2.0.0/16, 17, 1000-3000, 1000-3000]
(B) [1.1.0.0/16, 2.2.2.0/24, 17, 1000-3000, 1000-3000]
(C) [3.3.3.0/24, 4.4.4.0/24,  6, 4000-4500, 7000-8000]
(D) [3.3.3.0/24, 4.4.4.0/24,  6, 4000-6000, 7000-8000]
(E) [5.5.5.0/24, 6.6.6.0/24, 17,   0-65535,   0-65535]

(T) [ 1.1.1.8,     2.2.2.9,  17,   2000,      2000   ]
(U) [ 1.1.8.8,     2.2.9.9,  17,   2000,      2000   ]
(V) [ 1.1.8.8,     2.2.2.9,  17,   2000,      2000   ]
(W) [ 3.3.3.3,     4.4.4.4,   6,   4300,      7500   ]
(X) [ 3.3.3.3,     4.4.4.4,   6,   5000,      7500   ]
(Y) [ 5.5.5.5,     6.6.6.6,  17,   6000,      6000   ]

(1)

When (T) is Map-Requested, the lookup could match both (A) and (B), however destination address has preference over source address and therefore (A) is returned.¶

(2)

When (U) is Map-Requested, the lookup will return that no entry exists for the 5-tuple.¶

(3)

When (V) is Map-Requested, the lookup will return (B).¶

(4)

When (W) is Map-Requested, the lookup will return (C) and not (D), although both could match the tuple, since the destination port range is shorter in (C).¶

(5)

When (X) is Map-Requested, the lookup will return (D).¶

(6)

When (Y) is Map-Requested, the lookup will return (E). A port range of 0-65535 means any port.¶

6.2. 5-Tuple (Exact)

In scenarios where 5-tuple coarse lookup is not required, the lookup can be optimized to only account for exact matchs. When using a exact lookup for 5-tuple, the encoding described in Section 6.1 is used to carry the Extended-EID. The exact match lookup is performed by serializing the elements of the 5-tuple as a single vector of bits. The order to serialize the elements is the same that is described in Section 5.1 This (unique) vector of bits is then used as the key to perform a exact match lookup over the available entries.¶

7.1. 5-Tuple (Coarse)

The mapping database to be used for a coarse lookup of 5-tuples can leverage on the LISP-DDT mapping database [RFC8111] since it supports multi-tuple lookups. Note that a LISP-DDT based database can support also a exact lookup.¶

7.2. 5-Tuple (Exact)

Although a LISP-DDT based mapping database supports both coarse and exact lookups, the particularities of the latter benefit of using a mapping database optimized for flat namespaces rather than one optimized for hierarchical data. In that sense, the exact match mechanism should be supported by a DHT-like mapping database, such [I-D.cheng-lisp-shdht] or [LISP-DHT].¶