Skip to main content

5. Decent-Pull-Based Mapping System

The pull-based system does not require xTRs to join a multicast group. It uses a SHA-256 hash over an ASCII EID string and DNS A/AAAA records to identify which xTRs act as Map-Resolvers and Map-Servers.

Important hash strings and names are preserved:

[<iid>]<eid>/<ml>
[<iid>]<group>/<gml>-<source>/<sml>

eid = "[<iid>]<eid>/<ml>"
index = hash.sha_256(eid) MOD mv

sg-eid = "[<iid>]<group>/<gml>-<source>/<sml>"
index = hash.sha_256(sg-eid) MOD mv

starg-eid = "[<iid>]<group>/<gml>-0.0.0.0/0"
index = hash.sha_256(starg-eid) MOD mv

<index>.map-server.example.com

For multicast entries, the Hash Mask MUST include the string "[]" and not the string . For Map-Request messages, xTRs MAY round robin EID lookup requests among A and AAAA records.

Operators MAY configure ITRs to use specific lookup prefix lengths for EID allocation ranges. ITRs SHOULD support this configuration, SHOULD check for matching configured ranges, MUST use the configured lookup prefix length when a match is found, and MUST select the longest matching configured prefix when multiple ranges match. When constructing the hash string, the ITR MUST mask bits beyond the lookup-length.

The example EID range configuration is preserved:

Example configuration with multiple EID ranges:

   EID Range Configuration:
     Range: [0]240.11.0.0/16  -> lookup-length: 24
     Range: [0]240.12.0.0/16  -> lookup-length: 30
     Range: [0]240.13.0.0/16  -> lookup-length: 25

   Lookup Examples:
     EID [0]240.11.1.1/32     -> hash on [0]240.11.1.0/24
     EID [0]240.12.2.5/32     -> hash on [0]240.12.2.4/30
     EID [0]240.13.3.7/32     -> hash on [0]240.13.3.0/25
     EID [0]240.14.1.1/32     -> hash on [0]240.14.1.1/32
                                  (no match, use full EID)

The deployment example is preserved:

Here is an example deployment of a Decent-Pull-based model.  Let's
   say that 4 Map-Server sets are provisioned for the Mapping System.
   Therefore, 4 distinct DNS names are allocated and a Modulus Value 4
   is used.  Each DNS name is allocated Name Index 0 through 3:

       0.map-server.lispers.net
       1.map-server.lispers.net
       2.map-server.lispers.net
       3.map-server.lispers.net

   The A records for each name can be assigned as:

       0.map-server.lispers.net:
           A <rloc1-att>
           A <rloc2-verizon>
       1.map-server.lispers.net:
           A <rloc1-bt>
           A <rloc2-dt>
       2.map-server.lispers.net:
           A <rloc1-cn>
           A <rloc2-kr>
       3.map-server.lispers.net:
           A <rloc1-au>
           A <rloc2-nz>

   When an xTR wants to register "[1000]fd::2222/128", it hashes the EID
   string to produce, for example, hash value 0x67.  Using the modulus
   value 4 (0x67 & 0x3) produces index 0x3, so the DNS name 3.map-
   server.lispers.net is used and a Map-Register is sent to <rloc1-au>
   and <rloc2-nz>.

   Note that the Decent-Pull-based method can be used for a core seed-
   group for bootstrapping a Decent-Push-based Mapping System where
   multicast groups are registered.

An implementation SHOULD periodically perform DNS lookups to detect changed A records. All xTRs need the same Modulus Value, otherwise EIDs can be looked up in the wrong Map-Server set.

Last updated on