Loc/ID Separation is different from Core-Edge Separation

Established 2010-01-12 Robin Whittle rw@firstpr.com.au
../ To the main Ivip page, with background on scalable routing..

Also of interest - the companion page ../namespace/ .

The following was written in a hurry - it is in need of editing when I have time.


Ivip and LISP ("Locator / Identifier Separation Protocol") are Core-Edge Separation (CES) architectures. So are APT, TRRP and TIDR.

They are not  Locator / Identifier Separation architectures.

HIP and ILNP are examples of Locator / Identifier Separation (LIS) architectures.

If you are happy with this, please move on to some other web page.  Any page will do - every page is less tortuous than what follows: my not very well written argument as to why the above is true.

With LIS, there are two separate kinds of thing: Locators and Identifiers.  A value which is a Locator is interpreted according to the rules of the Locator namespace.  A value which is an Identifier is interpreted according to the rules of the Identifier namespace.   A given value, such as 12345, means one thing if it is found in a variable which is a Locator and something else if it is found in a variable which is an Identifier.

True Locator / Identifier Separation architectures such as HIP and ILNP do exactly this.  They maintain two different types of address, with the value for each type interpreted in different ways - according to different namespaces.


With CES, there is a single namespace for global unicast IP addresses.  A subset of these are known as "edge" addresses and the remainder are known as "core" addresses.  If the subset 12.34.0.0/16 are known as "edge" addresses, then an address within this subset, such as 12.34.56.78 is an "edge" address.  This division of the global unicast address space into two disjoint sets "edge" and "core" is part of how any address is interpreted (at least by some devices) when the address is interpreted according to the global unicast namespace.

With CES, the separation involves separating one subset of addresses from the rest, calling the one "edge" and calling the remainder "core".   Most devices, including all host stacks and applications, and all ordinary routers make no distinction between the two classifications since they process packets addressed to "core" or "edge" addresses in exactly the same way.

The exception is the ITR device.  ITRs and their companion devices ETRs work with the rest of the system (unmodified hosts and routers) and with a new thing - the mapping system - to give the "edge" addresses special properties.  "Edge" addresses can be used for end-user networks, to provide portability, multihoming and inbound TE, on a highly scalable basis. Also, "edge" addresses can't be used for ETRs.

"Core" and "edge" are not separate namespaces.  Separate namespaces means that a given value could be interpreted according to one namespace or the other. 

CES cannot be correctly construed as "Locator / Identifier Separation" because "core" and "edge" cannot correctly be equated with "Locator" and "Identifier".

In LISP, "core" addresses are called "RLOCs" and "edge" addresses are called "EIDs".

Yet no matter whether an address is in the "core" subset of the global unicast address space or the "edge" subset, all devices still use it the same way.  The address identifies a particular host, and the routing system uses this same address to figure out how to get the packet closer to, and ultimately right to, the destination host.

All hosts treat the address the same way no matter which subset it is in.  So do all normal routers.  The only device which treats them differently is an ITR, which adopts a different method of getting the packet towards the destination host if the packet is in the "edge" subset.

If the packet's destination address is in the "edge" subset, then the ITR does something to the packet which causes it to be different and to have a form that will cause all ordinary routers to forward it towards a particular ETR, the address (always a "core" address) of which is chosen by the ITR.

Once the packet in its modified form arrives at the ETR, the ETR converts it back to normal and uses its local knowledge to figure out how to get it to the destination network.  The ETR may serve multiple destination networks, or just one.

Once the packet, again in its original form, is in the destination network, its destination address (an "edge" address" is used both to identify a particular host and to locate that host.

So it is wrong to equate "edge" with "identifier". 

Also, "core" addresses are just as much identifiers for their hosts as "edge" addresses.  So again, it is wrong to equate "edge" with "identifier".

"Core" addresses are no more locators than "edge" addresses.  They identify hosts just the same way as "edge" addresses.

The difference is that the main routing system (not counting ITRs and ETRs) can only transport a packet directly to its destination host if its destination address is in the "core" subset.  If the destination address is in the "edge" subset, the main routing system will forward the packet to the nearest (Ivip) DITR (Destination ITR in the DFZ, previously "OITRD").  In LISP, the same thing happens, but the packet is forwarded to the nearest "PTR" (Proxy Tunnel Router), which does the same thing as an Ivip DITR.

Packets addressed to "core" addresses are fully handled by the main routing system, and ITRs do nothing special to them.

Packets addressed to the subset of global unicast addresses known as "edge" are sent to the nearest ITR (DITR or PTR).  Then that ITR modifies the packet so the ordinary routing system forwards it to the correct ETR.  The ETR reconstitutes the packet and knows what to do with it.  The ETR is presumably close to the destination network.

"Core" has nothing to do with "Locator".

Destination addresses in the "core" subset can be used by the ordinary routers to take the packet all the way to the destination host without any ITR involvement - by using the most significant bits to identify which of multiple advertised prefixes the destination prefix matches, and by forwarding the packet to the neighbor router previously identified as being the best path towards the one or more routers which advertised that prefix.

Destination addresses in the "edge" subset cannot be used by the ordinary routers to take the packet all the way to the destination host without any ITR involvement.  There are multiple ITRs which advertise prefixes covering all "edge" addresses.  The ordinary routers still treat the packet exactly the same way: by using the most significant bits to identify which of multiple advertised prefixes the destination prefix matches, and by forwarding the packet to the neighbor router previously identified as being the best path towards the one or more routers which advertised that prefix.

Its just that there are multiple ITRs around the Net, some inside ISP and end-user networks - and some outside (DITRs AKA PTRs) in the DFZ - which advertise prefixes covering all the "edge" addresses.  These ITRs do get the packet to the destination network and host, but not by expecting the ordinary routers to forward it according to its destination address.  The ITR does something to modify the packet, so the ordinary routers will forward it to an ETR - and the ETR reconstitutes the packet and forwards it to the destination network without the packet being allowed to go to an ITR.

So a "core" destination address can be, and will be used, as a routing locator by ordinary routers, to get the packet to its destination host without any help from ITRs.  But the "core" address is also an identifier of the destination host, just as much as an "edge" address is.

An "edge" destination address cannot be used as a routing locator by the ordinary routing system to get the packet to the destination host because there are ITRs around the place advertising prefixes covering all such addresses.  The ordinary routers do not treat packets any differently according to whether their destination address is in the "core" subset or the "edge" subset.  The actions are the same - in blue text above.

The only device which does something different is the ITR.

If a packet enters an ITR and has a "core" destination address, the ITR forwards it like any other router.

If the packet had an "edge" address, the ITR would do something completely different with it.

TIDR, LISP, APT, Ivip and TRRP (chronological order) are all Core-Edge Separation schemes, as described above - but theres no valid way of construing "core" addresses to be "Locators" or "edge" addresses to be "Identifiers".  Both kinds of address are always host identifiers. 

"Core" addresses can be used as routing locators by ordinary routers - and the ITRs behave like ordinary routers to these packets.

"Edge" addresses are treated the same way by ordinary routers and because of the way one or typically many ITRs advertise all prefixes which cover "edge" addresses, the packet will soon be transformed and tunneled to an ETR.  The method of tunneling is usually encapsulation, by applying to the outer header a destination address of the ETR.  This address is arguably a routing locator, and it is always a "core" address.  But that doesn't mean there is cause to call "core" addresses "Locators" or "edge" addresses "Identifiers".


If that wasn't enough, read on for another attempt.  I was going to put this in the Ivip-arch-03 ID but it doesn't really belong there:



There is considerable terminological inexactitude regarding the use of "Loc/ID Separation" and the like.  True Locator - Identifier separation involves hosts handling packets using two addresses of different types, usually called Locator and Identifier, which therefore are in different namespaces.  If both types of address are numeric and a Locator and an Identifier were numerically identical they would refer to different things because this numeric value has different meanings in each namespace. 

HIP and ILNP <xref target="I-D.rja-ilnp-intro" />  are examples of Locator / Identifier Separation.  LISP (Locator/Identifier Separation Protocol) is not.

An architecture which uses FQDNs as Identifiers and IP addresses (always PI, to ensure scalability) as Locators is also an example of true Loc/ID separation - for instance Name-Based Sockets, from Christian Vogt. 

LISP, Ivip and other core-edge separation architectures do not present hosts with separate Locator and Identifier addresses.  The host sees only IP addresses, which perform both functions simultaneously - just as they do without core-edge separation.

In Ivip and other core-edge separation schemes, the destination IP address of all packets is still used by the routing system (that is all the devices which handle packets between two communicating hosts) to decide how the packet will be forwarded.  Packets addressed to a subset of the address space - SPI space in Ivip, EID space in LISP - are treated differently by the routing system.  Instead of being forwarded across the DFZ towards their destination network according to their destination address, they are processed by an ITR which by one means or another gets the packet to the ETR  specified in the mapping for the micronet which matches this destination address.

Core-edge separation architectures other than Ivip always use encapsulation - one-way tunneling - between the ITR and ETR.  (The historical roots of this can be found in the mid-1990s - Steve Deering's "Map & Encap" for IPv4 <xref target="Deering-1996" />, Robert Hinden's "New Scheme for Internet Routing and Addressing (ENCAPS) for IPNG" (RFC 1955) and the 1992 crocker-ip-encaps-01.txt.  Ivip can use encapsulation, but in the long-term is intended to avoid this and instead modify the IP header to contain bits which DFZ and any other routers between the ITR and ETR will use to control forwarding.

SPI address space is highly suited to the needs of end-user networks and provides portability, multihoming and inbound TE to very large numbers of such networks with minimal impact on the DFZ's BGP control plane.  SPI addresses are described as "edge" and the remaining space is described as "core".  There is a separation between these two types of address, but it is not into separate namespaces.  Both types of address are within the global unicast range of IP addresses and are always interpreted according to the one set of rules which governs the interpretation of all addresses in the global unicast namespace. 

The "core" and "edge" subsets of global unicast address space are known in Ivip as "conventional" and "SPI" and in LISP as "RLOC" and "EID".

The difference between the two is that "edge" (SPI or EID) addresses are treated differently by ITRs and are transformed into a different kind of packet which the existing routing system will forward towards the ETR, which is the gateway, or one of the gateways, to the destination network.

A "core" address and an "edge" address don't mean anything different.  They both identify a host and give the routing system the information it needs to get the packet to that host. 

Applications and host stacks make no distinction between "core" and "edge" addresses - and are unaware of which subset any IP address falls into. 

Its just that the routing system can handle packets addressed to "edge" address in a scalable manner, and that these "edge" addresses have certain restrictions on their use.  They can be used for end-user networks for portability, multihoming and TE in a scalable manner - and they cannot be used for ETRs.

When a traffic packet addressed to an "edge" address enters hosts or all routers except an ITR, it is treated no differently from a packet which is addressed to a "core" address.  When it enters an ITR, the ITR does treat it differently from a packet addressed to a "core" address.  The ITR does something to a traffic packet so it will be forwarded to the ETR the ITR decides it should be forwarded to.  This action on the packet is typically encapsulating it and tunneling it to the ETR.  In Ivip, the action could also be modifying its IP header so other routers will forward it to the ETR (EAF) or to the ISP network where the ETR is (PLF).  In either case, the resulting packet is different from the original traffic packet and is forwarded according to bits which are different from the traffic packet's destination address.  Those bits are arguably a "Locator" address of some kind, but they do not constitute a Locator for the destination host.  They simply constitute an address of some kind which the routing system can use to forward the packet to the ETR, which then forwards the reconstituted traffic packet to the destination network where the original destination address (an "edge" address) is used as a locator within the destination network to forward it to the destination host.  These bits are a Locator for the destination network, and one Locator value (one ETR address) might be used by many destination networks.  A multihomed destination network has two or more of these Locators.

With encapsulation, the bits used by the routing system (the DFZ and other routers between ITRs and ETRs, none of which require any upgrades) are the destination address of the outer header.  For the IPv4 MHF technique EAF (ETR Address Forwarding) the bits are 30 bits in the IPv4 header, which upgraded routers between the ITR and ETR use to decide the next-hop link, instead of the destination address.  ETRs in all cases have "core" addresses.  For the IPv6 MHF approach PLF (Prefix Label Forwarding), the 19 or 20 bits in what was previously the Flow Label of the IPv6 header are used to forward the packet to the correct ISP network.  If there is a single ETR there, then this is sufficient - but if there are multiple ETRs, then these 19 or 20 bits get the packet across the DFZ, not all the way to the ETR.

These bits are arguably routing "Locators".  Core-edge separation involves a separation of IP addresses, still all covered by the one global unicast namespace, into two subsets: core and edge.  Addresses in both subsets are used as today - to identify a host uniquely (though one host could have multiple IP addresses).  Packets addressed to these "edge" (SPI) addresses are transported to their destination network in a way suitable for end-user network portability, multihoming, TE, mobility etc. in a highly scalable way, which does use separate bits which are arguably "routing locators".  But the hosts never see these locators, unless they have an ITR function built in (ITFH).

Core-edge separation converts a subset of the existing range of global unicast addresses as "edge" addresses, and uses different routing techniques to transport them across the DFZ.  All other addresses remain unaltered in there functionality and how packets addressed to them are handled - and that set of global unicast address space which is not "edge" is then known as "core".

"Edge" could be construed as "identifier" and "core" as "locator" - but core addresses include many which are not used for ETRs, but are just plain IP addresses used by hosts.  These plain IP addresses are both Locators and Identifiers for the hosts which use them.  So it is not valid to construe all "core" (really non-"edge") addresses as Locators.

The proper term for LISP, APT, Ivip and any other system with ITRs, ETRs and a mapping system to determine ITR tunneling behavior is Core-Edge Separation.

True Locator Identifier separation involves separate namespaces for these two types of "address".  HIP, ILNP and some other architectures are true Locator / Identifier Separation schemes.



 

.