draft-ietf-lisp-introduction-03.txt   draft-ietf-lisp-introduction-04.txt 
LISP Working Group J. N. Chiappa Network Working Group A. Cabellos-Aparicio (Ed.)
Internet-Draft Yorktown Museum of Asian Art Internet-Draft Technical University of Catalonia
Intended status: Informational October 21, 2013 Intended status: Informational D. Saucez (Ed.)
Expires: April 24, 2014 Expires: January 17, 2015 INRIA
July 16, 2014
An Architectural Introduction to the LISP An Architectural Introduction to the LISP Location-Identity
Location-Identity Separation System Separation System
draft-ietf-lisp-introduction-03 draft-ietf-lisp-introduction-04.txt
Abstract Abstract
LISP is an upgrade to the architecture of the IP internetworking This document is an introductory overview of the Locator/ID
system, one which separates location and identity properties Separation Protocol, it describes the major concepts and functional
(previously intermingled in IP addresses). This document is an sub-systems of LISP and the interactions between them.
introductory overview of the entire LISP system, and focuses on
describing the major concepts and functional sub-systems of LISP, and
the interactions between them.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. This document may not be modified, provisions of BCP 78 and BCP 79.
and derivative works of it may not be created, except to format it
for publication as an RFC or to translate it into languages other
than English.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 24, 2014. This Internet-Draft will expire on January 17, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Prefatory Note 1. Prefatory Note . . . . . . . . . . . . . . . . . . . . . . . 4
2. Part I 2. Part I . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Initial Glossary 3. Initial Glossary . . . . . . . . . . . . . . . . . . . . . . 5
4. Background 4. Background . . . . . . . . . . . . . . . . . . . . . . . . . 6
5. Deployment Philosophy 5. Deployment Philosophy . . . . . . . . . . . . . . . . . . . . 7
5.1. Economics 5.1. Economics . . . . . . . . . . . . . . . . . . . . . . . . 7
5.2. Maximize Re-use of Existing Mechanism 5.2. Maximize Re-use of Existing Mechanism . . . . . . . . . . 8
6. LISP Overview 6. LISP Overview . . . . . . . . . . . . . . . . . . . . . . . . 8
6.1. Basic Approach 6.1. Basic Approach . . . . . . . . . . . . . . . . . . . . . 9
6.2. Basic Functionality 6.2. Basic Functionality . . . . . . . . . . . . . . . . . . . 9
6.3. Mapping from EIDs to RLOCs 6.3. Mapping from EIDs to RLOCs . . . . . . . . . . . . . . . 11
6.4. Interworking With Non-LISP-Capable Endpoints 6.4. Interworking With Non-LISP-Capable Endpoints . . . . . . 11
6.5. Security in LISP 6.5. Security in LISP . . . . . . . . . . . . . . . . . . . . 12
7. Initial Applications 7. Initial Applications . . . . . . . . . . . . . . . . . . . . 13
7.1. Provider Independence 7.1. Provider Independence . . . . . . . . . . . . . . . . . . 13
7.2. Multi-Homing 7.2. Multi-Homing . . . . . . . . . . . . . . . . . . . . . . 13
7.3. Traffic Engineering 7.3. Traffic Engineering . . . . . . . . . . . . . . . . . . . 14
7.4. Routing 7.4. Routing . . . . . . . . . . . . . . . . . . . . . . . . . 15
7.5. Mobility 7.5. Mobility . . . . . . . . . . . . . . . . . . . . . . . . 15
7.6. Traversal Across Alternate IP Versions 7.6. Traversal Across Alternate IP Versions . . . . . . . . . 15
7.7. Virtual Private Networks 7.7. Virtual Private Networks . . . . . . . . . . . . . . . . 16
7.8. Local Uses 7.8. Local Uses . . . . . . . . . . . . . . . . . . . . . . . 16
8. Major Functional Subsystems 8. Major Functional Subsystems . . . . . . . . . . . . . . . . . 17
8.1. Data Plane - xTRs Overview 8.1. Data Plane - xTRs Overview . . . . . . . . . . . . . . . 17
8.1.1. Mapping Cache Performance 8.1.1. Mapping Cache Performance . . . . . . . . . . . . . . 18
8.2. Control Plane - Mapping System Overview 8.2. Control Plane - Mapping System Overview . . . . . . . . . 18
8.2.1. Mapping System Organization 8.2.1. Mapping System Organization . . . . . . . . . . . . . 19
8.2.2. Interface to the Mapping System 8.2.2. Interface to the Mapping System . . . . . . . . . . . 20
8.2.3. Indexing Sub-system 8.2.3. Indexing Sub-system . . . . . . . . . . . . . . . . . 20
9. Examples of Operation 9. Examples of operation . . . . . . . . . . . . . . . . . . . . 22
9.1. An Ordinary Packet's Processing 9.1. An Ordinary Packet's Processing . . . . . . . . . . . . . 22
9.2. A Mapping Cache Miss 9.2. A Mapping Cache Miss . . . . . . . . . . . . . . . . . . 23
10. Part II 10. Part II . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
11. Design Approach 11. Design Approach . . . . . . . . . . . . . . . . . . . . . . . 24
12. xTRs 12. xTRs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
12.1. When to Encapsulate 12.1. When to Encapsulate . . . . . . . . . . . . . . . . . . 25
12.2. UDP Encapsulation Details 12.2. UDP Encapsulation Details . . . . . . . . . . . . . . . 26
12.3. Header Control Channel 12.3. Header Control Channel . . . . . . . . . . . . . . . . . 26
12.3.1. Mapping Versioning 12.3.1. Mapping Versioning . . . . . . . . . . . . . . . . . 26
12.3.2. Echo Nonces 12.3.2. Echo Nonces . . . . . . . . . . . . . . . . . . . . 27
12.3.3. Instances 12.3.3. Instances . . . . . . . . . . . . . . . . . . . . . 27
12.4. Probing 12.4. Probing . . . . . . . . . . . . . . . . . . . . . . . . 28
12.5. Mapping Lifetimes and Timeouts 12.5. Mapping Lifetimes and Timeouts . . . . . . . . . . . . . 28
12.6. Mapping Gleaning in ETRs 12.6. Mapping Gleaning in ETRs . . . . . . . . . . . . . . . . 29
12.7. MTU Issues 12.7. MTU Issues . . . . . . . . . . . . . . . . . . . . . . . 29
12.8. Security of Mapping Lookups 12.8. Security of Mapping Lookups . . . . . . . . . . . . . . 29
12.9. xTR Mapping Cache Performance 12.9. ITR Mapping Cache Performance . . . . . . . . . . . . . 30
13. The Mapping System 13. The Mapping System . . . . . . . . . . . . . . . . . . . . . 31
13.1. The Mapping System Interface 13.1. The Mapping System Interface . . . . . . . . . . . . . . 32
13.1.1. Map-Request Messages 13.1.1. Map-Request Messages . . . . . . . . . . . . . . . . 32
13.1.2. Map-Reply Messages 13.1.2. Map-Reply Messages . . . . . . . . . . . . . . . . . 32
13.1.3. Map-Register and Map-Notify Messages 13.1.3. Map-Register and Map-Notify Messages . . . . . . . . 33
13.2. The DDT Indexing Sub-system 13.2. The DDT Indexing Sub-system . . . . . . . . . . . . . . 34
13.2.1. Map-Referral Messages 13.3. Reliability via Replication . . . . . . . . . . . . . . 35
13.3. Reliability via Replication 13.4. Security of the DDT Indexing Sub-system . . . . . . . . 35
13.4. Security of the DDT Indexing Sub-system 13.5. Extended Capabilities . . . . . . . . . . . . . . . . . 36
13.5. Extended Capabilities 13.6. Performance of the Mapping System . . . . . . . . . . . 36
13.6. Performance of the Mapping System 14. Multicast Support in LISP . . . . . . . . . . . . . . . . . . 37
14. Multicast Support in LISP 14.1. Basic Concepts of Multicast Support in LISP . . . . . . 37
14.1. Basic Concepts of Multicast Support in LISP 14.2. Initial Multicast Support in LISP . . . . . . . . . . . 38
14.2. Initial Multicast Support in LISP 15. Deployment Issues and Mechanisms . . . . . . . . . . . . . . 39
15. Deployment Issues and Mechanisms 15.1. LISP Deployment Needs . . . . . . . . . . . . . . . . . 39
15.1. LISP Deployment Needs 15.2. Interworking Mechanisms . . . . . . . . . . . . . . . . 40
15.2. Interworking Mechanisms 15.2.1. Proxy LISP Routers . . . . . . . . . . . . . . . . . 40
15.2.1. Proxy LISP Routers 15.2.2. LISP-NAT . . . . . . . . . . . . . . . . . . . . . . 42
15.2.2. LISP-NAT 15.3. Use Through NAT Devices . . . . . . . . . . . . . . . . 42
15.3. Use Through NAT Devices 15.4. LISP and Core Internet Routing . . . . . . . . . . . . . 43
15.4. LISP and Core Internet Routing 16. Fault Discovery/Handling . . . . . . . . . . . . . . . . . . 43
16. Fault Discovery/Handling 16.1. Handling Missing Mappings . . . . . . . . . . . . . . . 44
16.1. Handling Missing Mappings 16.2. Outdated Mappings . . . . . . . . . . . . . . . . . . . 44
16.2. Outdated Mappings 16.2.1. Outdated Mappings - Updated Mapping . . . . . . . . 44
16.2.1. Outdated Mappings - Updated Mapping 16.2.2. Outdated Mappings - Wrong ETR . . . . . . . . . . . 44
16.2.2. Outdated Mappings - Wrong ETR 16.2.3. Outdated Mappings - No Longer an ETR . . . . . . . . 45
16.2.3. Outdated Mappings - No Longer an ETR 16.3. Erroneous Mappings . . . . . . . . . . . . . . . . . . . 45
16.3. Erroneous Mappings 16.4. Verifying ETR Liveness . . . . . . . . . . . . . . . . . 45
16.4. Verifying ETR Liveness 16.5. Verifying ETR Reachability . . . . . . . . . . . . . . . 46
16.5. Verifying ETR Reachability 17. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 46
17. Acknowledgments 18. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 47
18. IANA Considerations 19. Security Considerations . . . . . . . . . . . . . . . . . . . 47
19. Security Considerations 20. References . . . . . . . . . . . . . . . . . . . . . . . . . 47
20. References 20.1. Normative References . . . . . . . . . . . . . . . . . . 47
20.1. Normative References 20.2. Informative References . . . . . . . . . . . . . . . . . 49
20.2. Informative References Appendix A. Glossary/Definition of Terms . . . . . . . . . . . . 52
Appendix A. Glossary/Definition of Terms Appendix B. Other Appendices . . . . . . . . . . . . . . . . . . 55
Appendix B. Other Appendices B.1. A Brief History of Location/Identity Separation . . . . 55
B.1. A Brief History of Location/Identity Separation B.2. A Brief History of the LISP Project . . . . . . . . . . . 56
B.2. A Brief History of the LISP Project B.3. Old LISP 'Models' . . . . . . . . . . . . . . . . . . . . 56
B.3. Old LISP 'Models' B.4. The ALT Mapping Indexing Sub-system . . . . . . . . . . . 57
B.4. The ALT Mapping Indexing Sub-system B.5. Early NAT Support . . . . . . . . . . . . . . . . . . . . 58
B.5. Early NAT Support Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 59
1. Prefatory Note 1. Prefatory Note
{{Suggestion by editors: Remove all the sections before "LISP
Overview" and write a straight-to-the-point introduction}}
{{Suggestion by editors: The draft should focus on describing the
LISP architecture and avoid comparing loc/id split architectures with
other approaches}}
This document is the first of a pair which, together, form what one This document is the first of a pair which, together, form what one
would think of as the 'architecture document' for LISP (the would think of as the 'architecture document' for LISP (the
'Location-Identity Separation Protocol'). Much of what would 'Location-Identity Separation Protocol'). Much of what would
normally be in an architecture document (e.g. the architectural normally be in an architecture document (e.g. the architectural
design principles used in LISP, and the design considerations behind design principles used in LISP, and the design considerations behind
various components and aspects of the LISP system) is in the second various components and aspects of the LISP system) is in the second
document, the 'Architectural Perspective on LISP' document. document, the 'Architectural Perspective on LISP' document.
[Perspective] [I-D.ietf-lisp-perspective]
This 'Architectural Introduction' document is primarily intended for This 'Architectural Introduction' document is primarily intended for
those who unfamiliar with LISP, and want to start learning about it. those who are unfamiliar with LISP, and want to start learning about
It is intended primarily for those working _on_ LISP, but those it. It is intended primarily for those working on LISP, but those
working _with_ LISP, and more generally anyone who wants to know more working with LISP, and more generally anyone who wants to know more
about LISP, may also find this document useful. about LISP, may also find this document useful.
This document is intended to both be easy to follow, and also to give This document is intended to both be easy to follow and it is
the reader a choice as to how much they wish to know about LISP. It structured as a series of phases, each covering the entire system,
is structured as a series of phases, each covering the entire system,
but with ever-increasing detail. Reading only the first part of the but with ever-increasing detail. Reading only the first part of the
document will give a good high-level view of the system; reading the document will give a good high-level view of the system; reading the
complete document should provide a fairly detailed understanding of complete document should provide a fairly detailed understanding of
the entire system. the entire system.
People who just want to get an idea of how LISP works might only read People who just want to get an idea of how LISP works might only read
the first part; they can stop reading either just before, or just the first part; they can stop reading either just before, or just
after, Section 9, "Examples of Operation". People who are going to after Section 9. People who are going to go on and read the protocol
go on and read the protocol specifications (perhaps to implement specifications (perhaps to implement LISP) should read the entire
LISP) should read the entire document. document.
Note: This document is a descriptive document, not a protocol This document is a descriptive document, not a protocol
specification. Should it differ in any detail from any of the LISP specification. Should it differ in any detail from any of the LISP
protocol specification documents, they take precedence for the actual protocol specification documents, they take precedence for the actual
operation of the protocol. operation of the protocol.
2. Part I 2. Part I
3. Initial Glossary 3. Initial Glossary
This initial glossary defines a few general terms which will be This initial glossary defines a few general terms which will be
useful to have in hand when commencing reading this document. A useful to have in hand when commencing reading this document. A
complete glossary is available in Appendix A. complete glossary is available in Appendix A.
A note about style: initial usage of a term defined in the glossary A note about style: initial usage of a term defined in the glossary
is denoted with double quotation marks ("). Other uses of quotations is denoted with double quotation marks ("). Other uses of quotations
(e.g. for quotations, euphemisms, etc) use single quotation marks (e.g. for quotations, euphemisms, etc) use single quotation marks
('). (').
skipping to change at line 197 skipping to change at page 5, line 15
This initial glossary defines a few general terms which will be This initial glossary defines a few general terms which will be
useful to have in hand when commencing reading this document. A useful to have in hand when commencing reading this document. A
complete glossary is available in Appendix A. complete glossary is available in Appendix A.
A note about style: initial usage of a term defined in the glossary A note about style: initial usage of a term defined in the glossary
is denoted with double quotation marks ("). Other uses of quotations is denoted with double quotation marks ("). Other uses of quotations
(e.g. for quotations, euphemisms, etc) use single quotation marks (e.g. for quotations, euphemisms, etc) use single quotation marks
('). (').
- Name: In this document, and in much of computer science, a 'name' o Name: a name refers to an identifier for an object or entity.
simply refers to an identifier for an object or entity. Names Names have both semantics (meaning) and syntax (form) [RFC1498].
have both semantics (meaning) and syntax (form). [RFC1498]
- Namespace: A group of "names" with matching semantics and syntax; o Namespace: A group of names with matching semantics and syntax;
they usually, but not always, refer to members of a class of they usually, but not always, refer to members of a class of
identical objects. identical objects.
- Mapping: In this document, a connection (or binding, to use the
computer science term) between two names, one in each of two o Mapping: a binding between two names, one in each of two
namespaces. namespaces.
- Delegation Hierarchy: an abstract rooted tree (in the graph theory
o Delegation Hierarchy: an abstract rooted tree (in the graph theory
sense of the term) which is a virtual representation of the sense of the term) which is a virtual representation of the
delegation of a "namespace" into smaller and smaller blocks, in a delegation of a namespace into smaller and smaller blocks, in a
recursive process. recursive process.
- Node: The general term used to describe any sort of communicating
o Node: The general term used to describe any sort of communicating
entity; it might be a physical or a virtual host, or a mobile entity; it might be a physical or a virtual host, or a mobile
device of some sort. It includes both entities which forward device of some sort. It includes both entities which forward
packets, and entities which create or consume packets. It was packets, and entities which create or consume packets.
deliberately chosen for use in this document precisely because its
definition is not fixed, and therefore unlikely to cause erroneous o Switch, Packet Switch: A packet switch, in the general meaning of
images in the minds of readers.
- Switch, Packet Switch: A packet switch, in the general meaning of
that term. A device which takes in packets from its interfaces that term. A device which takes in packets from its interfaces
and forwards them on, either to a next-hop switch, or to the final and forwards them on, either to a next-hop switch, or to the final
destination. They may operate at either the network layer (e.g. destination. They may operate at either the network layer (e.g.
ARPANET), or internetwork layer. [Baran][Heart][RFC1812] ARPANET), or internetwork layer. [Baran][Heart][RFC1812]
- Endpoint, end-end communication entity: The fate-sharing region at
o Endpoint, end-end communication entity: The fate-sharing region at
one end of an end-end communication; the collection of state one end of an end-end communication; the collection of state
related to both the reliable end-end communication channel, and related to both the reliable end-end communication channel, and
the applications running there. [Chiappa] the applications running there. [Chiappa]
- IPvN: IPv4 ([RFC791]) or IPv6 ([RFC2460]); the two are so similar,
in fundamental architecture, that in much discussion about their o Address: In this document, in current IP (IPv4 or IPv6) and
capabilities, limitations, etc statements about the apply equally similar networking suites, a "name" which has mixed semantics, in
to both, and to continually say 'IPv4 and IPv6' quickly becomes that it includes both identity ('who') and location ('where')
tedious. semantics. [Atkinson]
- Address: In this document, and in current "IPvN" and similar
networking suites, a "name" which has mixed semantics, in that it o Address Block, Block: A contiguous section of a namespace (e.g.,
includes both identity ('who') and location ('where') semantics. IP addresses that belong to the same prefix).
[Atkinson]
- Address Block, Block: A contiguous section of a namespace, usually o Identifier: a name which has identity semantics.
IPvN addresses; for the latter, it will normally be on a bit
boundary, using the standard 'prefix/length' selection indication. o Locator: name with only location semantics and not necessarily
- Identifier: Here, and in current networking discussions, a "name" carried in every packet [RFC1992].
which has purely identity semantics.
- Locator: Originally defined as a "name" with only location o Site: A collection of hosts, routers, and networks under a single
semantics, and one that was not necessarily carried in every
packet (as was widely assumed of "addresses") [RFC1992], it is now
generally taken, including here, to mean a "name" with purely
location semantics.
- Site: A collection of hosts, routers and networks under a single
administrative control. administrative control.
- LISP site: A single node, or a set of network elements in an edge
network under the administrative control of a single organization; o LISP site: a site separated from the rest of the network by LISP
they are separated from the rest of the network by "LISP routers". routers.
- LISP node: A IPvN "node" which has been enhanced with LISP
functionality; generally this means it can process some subset of o LISP node: A network element implementing LISP functionality; this
LISP control plane traffic. means it can process some subset of LISP control and planes
- LISP router: A IPvN "switch" which has been enhanced with LISP traffic.
functionality; a LISP node which can forward user traffic.
- LISP host: A IPvN host which is 'behind' (from the point of view o LISP router: A network element implementing LISP data-plane
of the rest of the network) a "LISP router". functionality, i.e., a LISP node which can forward user traffic.
o LISP host: A host which is behind (from the point of view of the
rest of the network) a LISP router.
4. Background 4. Background
It has gradually been realized in the networking community that It has gradually been realized in the networking community that
networks, especially large networks, should deal quite separately networks, especially large networks, should deal quite separately
with the 'identity' and 'location' of an "endpoint" - basically, with the identity and location of an endpoint - basically, who an
'who' an endpoint is, and 'where' it is. ([RFC1498]) (A more endpoint is, and where it is ([RFC1498] [RFC4984]).
detailed history of this evolution is in Appendix B.1, "A Brief
History of Location/Identity Separation".)
At the moment, in both IPv4 and IPv6, IP "addresses" indicate both
where the named "node" is, as well as identify it for purposes of
end-end communication; i.e. it has both location and identity
properties. However, the separation of those two properties is a
step which has recently been identified by the IRTF as a necessary
evolutionary architectural step for the Internet. [RFC6115]
The on-going LISP project is an attempt to provide a viable path At the moment of this writing, in both IPv4 and IPv6, IP addresses
towards this separation. (A brief history of the LISP project can be indicate both where the named node is, as well as identify it for
found in Appendix B.2, "A Brief History of the LISP Project".) purposes of end-end communication; i.e. it has both location and
identity properties. However, the separation of those two properties
is a step which has been identified by the IRTF as a necessary
evolutionary architectural step for the Internet [RFC6115] and the
on-going LISP project is an attempt to provide a viable path towards
this separation.
As an add-on to a large existing system, it has had to make certain As an add-on to a large existing system, it has had to make certain
compromises. (For a good example, see [Perspective], Section compromises. (For a good example, see [I-D.ietf-lisp-perspective],
"Residual Location Functionality in EIDs".) However, if it reaches Section "Residual Location Functionality in EIDs". However, if it
near-ubiquitous deployment, it will have two important consequences. reaches near-ubiquitous deployment, it will have two important
consequences.
First, in effectively providing separation of location and identity, First, in effectively providing separation of location and identity,
along with providing a distributed directory of the "mappings" along with providing a distributed directory of the mappings between
between them, 'Wheeler's Law' ('All problems in computer science can them, 'Wheeler's Law' ('All problems in computer science can be
be solved by another level of indirection') will come into play, and solved by another level of indirection') will come into play, and the
the Internet technical community will have a new, immensely powerful, Internet technical community will have a new, immensely powerful,
tool at its disposal. The fact that the namespaces on both sides of tool at its disposal. The fact that the namespaces on both sides of
the mapping are global ones maximizes the power of that tool. (See the mapping are global ones maximizes the power of that tool. (See
[Perspective], Section "Need for a Mapping System", for more on [I-D.ietf-lisp-perspective], Section "Need for a Mapping System", for
this.) more on this.)
Second, because of a combination of the flexible capability built Second, because of a combination of the flexible capability built
into LISP, and the breaking of the unification of location and into LISP, and the breaking of the unification of location and
identity names, further architectural evolution of the Internet identity names, further architectural evolution of the Internet
becomes easily available; for example, new namespaces for location becomes easily available; for example, new namespaces for location or
could be designed and deployed. In other words, LISP is not a point identity could be designed and deployed. In other words, LISP is not
solution to meet a particular need, but hopefully an 'escape hatch' a point solution to meet a particular need, but hopefully an 'escape
which will allow further significant enhancement to the Internet's hatch' which will allow further significant enhancement to the
overall architecture. (See [Future] for more on this.) Internet's overall architecture. (See [Future] for more on this.)
5. Deployment Philosophy 5. Deployment Philosophy
The deployment philosophy was a major driver for much of the design {{Suggestion by editors: Remove the entire section, it can be
of LISP: to some degree of the architecture, and to a very large summarized by the last paragraph. Furthermore the arguments used in
measure, the engineering. this sections are hard to follow since LISP has not been described
yet.}}
Experience over the last several decades has shown that having a The deployment philosophy was a major driver for the design of LISP
viable 'deployment model' for a new design is absolutely key to the (architecture and engineering).
success of that design. In general, it is comparatively easy to
conceive of new network designs, but much harder to devise approaches
which will actually get deployed throughout the global network. A
new design may be fantastic - but if it can not or will not be
successfully deployed (for whatever factors), it is useless.
This absolute primacy of what is hoped is a viable deployment model Experience over the last several decades has shown that having a
is what has lead to some painful compromises in the design; and the viable deployment model for a new design is a key to the adoption of
extreme focus on a viable deployment model (including economics) is the solution. In general, it is comparatively easy to conceive of
one of the key design guides of LISP. new network designs, but much harder to devise approaches which will
actually get deployed throughout the global network. A new design
may be fantastic but if it can not be successfully deployed (for
whatever factors), it is useless.
LISP aims to achieve the near-ubiquitous deployment necessary for LISP aims to achieve the near-ubiquitous deployment necessary for
maximum exploitation of an architectural upgrade by i) minimizing the maximum exploitation of an architectural upgrade by i) minimizing the
amount of change needed (most existing hosts and routers can operate amount of change needed (most existing hosts and routers can operate
unmodified); and ii) by providing significant benefits to early unmodified); and ii) by providing significant benefits to early
adopters. adopters.
5.1. Economics 5.1. Economics
{{Suggestion by editors: Remove this section, this has not been
discussed by the WG}}
A key factor in successful adoption is economics: does the new design A key factor in successful adoption is economics: does the new design
have benefits which outweigh its costs? have benefits which outweigh its costs?
More importantly, this balance needs to hold for early adopters - More importantly, this balance needs to hold for early adopters -
because if they do not receive benefits to their adoption, the sphere because if they do not receive benefits to their adoption, the sphere
of earliest adopters will not expand, and it will never get to of earliest adopters will not expand, and it will never get to
widespread deployment. widespread deployment.
This is particularly true of architectural enhancements, which are This is particularly true of architectural enhancements, which are
far less likely to be an addition which one can 'bolt onto the side' far less likely to be an addition which one can bolt onto the side of
of existing mechanisms, and often offer their greatest benefits only existing mechanisms, and often offer their greatest benefits only
when widely (or ubiquitously) deployed. when widely (or ubiquitously) deployed.
Maximizing the cost-benefit ratio obviously has two aspects. First, Maximizing the cost-benefit ratio obviously has two aspects. First,
on the cost side, by making the design as inexpensive as possible, on the cost side, by making the design as inexpensive as possible,
which means in part making the deployment as easy as possible. which means in part making the deployment as easy as possible.
Second, on the benefit side, by providing many new capabilities, Second, on the benefit side, by providing many new capabilities,
which is best done not by loading the design up with lots of features which is best done not by loading the design up with lots of features
or options (which adds complexity), but by making the addition or options (which adds complexity), but by making the addition
powerful through deeper flexibility. The LISP community believes powerful through deeper flexibility. The LISP community believes
LISP has met both of these goals. LISP has met both of these goals.
5.2. Maximize Re-use of Existing Mechanism 5.2. Maximize Re-use of Existing Mechanism
One key part of reducing the cost of a new design is to absolutely {{Suggestion by editors: Remove/Summarize the entire section, the
minimize the amount of change _required_ to existing, deployed, arguments used in this section are hard to follow since LISP has not
devices: the fewer devices need to be changed, and the smaller the been described yet.}}
change to those that do, the lower the pain (and thus the greater the
likelihood) of deployment.
Designs which absolutely require 'forklift upgrades' to large amounts One key part of reducing the cost of a new design is to minimize the
amount of change required to existing, deployed, devices: the fewer
devices need to be changed, and the smaller the change to those that
do, the greater the likelihood of deployment.
Designs which absolutely require forklift upgrades to large amounts
of existing gear are far less likely to succeed - because they have of existing gear are far less likely to succeed - because they have
to have extremely large benefits to make their very substantial costs to have extremely large benefits to make their very substantial costs
worthwhile. worthwhile.
It is for this reason that LISP, in most cases, initially requires no It is for this reason that LISP, in most cases, initially requires no
changes to almost all existing devices in the Internet (both hosts changes to almost all existing devices in the Internet (both hosts
and routers); LISP functionality needs to be added in only a few and routers); LISP functionality needs to be added in only a few
places (see Section 15.1, "LISP Deployment Needs", for more). places ( Section 15.1)
LISP also initially re-uses, where-ever possible, existing protocols.
The 'initially' must be stressed - careful attention has also long
been paid to the long-term future (see [Future]), and larger changes
become feasible as deployment increases.
6. LISP Overview 6. LISP Overview
LISP is an incrementally deployable architectural upgrade to the LISP is an incrementally deployable architectural upgrade to the
existing Internet infrastructure, one which provides separation of existing Internet infrastructure, one which provides separation of
location and identity. It thus starts to separate the names used for location and identity. It thus starts to separate the names used for
identity and location of nodes, which are currently unified in "IPvN" identity and location of nodes, which are currently unified in IP
"addresses". addresses.
The separation into names with purely location and purely identity
semantics is usually - but not necessarily - not perfect, for reasons
which are driven by the deployment philosophy (above), and explored
in more detail elsewhere (in [Perspective], Section "Namespaces-EIDs-
Residual").
6.1. Basic Approach 6.1. Basic Approach
In LISP, the first key concept is that nodes have both an {{Suggestion by editors: Merge this section with the previous one
'identifier' (a name which serves only to provide a persistent handle (LISP Overview)}}
for the node), called an "EID" (short for 'endpoint identifier'), and
an associated 'locator' (a name which says _where_ the node is, in
the network's connectivity structure), called an "RLOC" (short for
'routing locator').
A node may be associated with more than one RLOC, or the RLOC may In LISP, the first key concept is that nodes have both an identifier
change over time (e.g. if the node is mobile), but it would normally called an Endpoint IDentifier (EID) and an associated Routing Locator
always have the same EID. (RLOC). A node may be associated with more than one RLOC, or the
RLOC may change over time (e.g., if the node is mobile), but it would
normally always have the same EID.
The second key concept is that if one wants to be as forward-looking The second key concept is that if one wants to be as forward-looking
as possible, conceptually one should think of the two kinds of names as possible, conceptually one should think of the two kinds of names
(EIDs and RLOCs) as naming _different classes of entities_. (EIDs and RLOCs) as naming different classes of entities.
EIDs name nodes - or rather, their end-end communication entities On the one hand, EIDs are used to name nodes - or rather, their end-
(see [Chiappa] for more). RLOC(s), on the other hand, name end communication entities. RLOC(s), on the other hand, name
interfaces, i.e. places to which the system of routers sends packets. interfaces, i.e. places to which the system of routers sends packets.
(These will usually be on the "LISP routers", in the early stages of
LISP deployment; see below for more.)
This distinction, the formal recognition of _different_ kinds of This distinction, the formal recognition of different kinds of
entities ("endpoints" and interfaces), and their association with the entities ("endpoints" and interfaces), and their association with the
two different classes of names, is also important. Clearly two different classes of names, is also important. Clearly
recognizing interfaces and endpoints as distinctly separate classes recognizing interfaces and endpoints as distinctly separate classes
of objects is another improvement to the existing Internet of objects is another improvement to the existing Internet
architecture. architecture.
An important insight in LISP is that it initially uses existing IPvN An important insight in LISP is that it initially uses existing IP
addresses for both of these kinds of names, as opposed to some addresses for both of these kinds of names, as opposed to some
similar earlier deployment proposals for separation of location and similar earlier deployment proposals for separation of location and
identity (e.g. [RFC1992]), which proposed using a new namespace for identity (e.g. [RFC1992]), which proposed using a new namespace for
locators. This choice minimized LISP's deployment cost, as well as locators. This choice minimizes LISP's deployment cost, as well as
providing the ability to easily interact with un-modified hosts and providing the ability to easily interact with un-modified hosts and
routers. routers.
The capability to use namespaces other than IPvN addresses for both The capability to use namespaces other than IP addresses for both
kinds of names is already built in, which is expected to greatly kinds of names is already built in LISP, which is expected to greatly
increase the long-term benefits, flexibility, and power of the LISP increase the long-term benefits, flexibility, and power of LISP
"mapping" layer. [AFI][LCAF] ([AFI], [I-D.ietf-lisp-lcaf]).
6.2. Basic Functionality 6.2. Basic Functionality
{{Suggestion by editors: Rewrite this section: It is using non-
standard terminology to refer to standard LISP concepts ('enhance'
instead of encapsulate) It is using subjective terms (e.g., 'near'
the source) It is missing key LISP aspects such as that RLOC packets
are forwarded in the RLOC space }}
The basic operation of LISP, as it currently stands, is quite simple. The basic operation of LISP, as it currently stands, is quite simple.
LISP augmented packet switches, "LISP routers", near the source and LISP augmented packet switches, "LISP routers", near the source and
destination of packets intercept traffic, and 'enhance' the packets destination of packets intercept traffic, and 'enhance' the packets
for the trip between the LISP switches. for the trip between the LISP switches.
The LISP router near the original source (the Ingress Tunnel Router, The LISP router near the original source (the Ingress Tunnel Router,
or "ITR") looks up additional information about the destination of or ITR ) looks up additional information about the destination of the
the packet, and then wraps the packet in an outer header, one which packet, and then wraps the packet in an outer header, one which
contains some of that additional information. contains additional information related to LISP operation.
The LISP router near the destination, the (the Egress Tunnel Router, The LISP router near the destination, the (the Egress Tunnel Router,
or "ETR") removes that header, leaving the original, un-modified, or ETR) removes that header, leaving the original, un-modified,
packet to be sent on to the original destination node. packet to be sent on to the original destination node.
The overall processing is shown below, in Figure 1: The overall processing is shown below, in Figure 1:
(to be added) /-----------------\ ---
| Mapping | |
. System | | Control
-| |`, | Plane
,' \-----------------/ . |
/ \ ---
,.., - _,..--..,, `, ,.., |
/ ` ,' ,-` `', . / ` |
/ \ +-----+ ,' `, +--'--+ / \ |
| EID |-| xTR |---/ RLOC ,---| xTR |-| EID | | Data
| Space |-| |---| Space |---| |-| Space | | Plane
\ / +-----+ . / +-----+ \ / |
`. .' `. ,' `. .' |
`'-` `., ,.' `'-` ---
``''--''``
LISP Site (Edge) Core LISP Site (Edge)
Figure 1: Basic LISP Packet Flow Figure.- An schema of the LISP Architecture
Figure 1: Basic LISP Packet Flow
To retrieve that additional information, the ITR uses the information To retrieve that additional information, the ITR uses the information
in the original packet about the identity of its ultimate in the original packet about the identity of its ultimate
destination, i.e. the destination address; in LISP, this is the EID destination, i.e. the destination EID address. It uses the
of the ultimate destination. It uses the destination EID to look up destination EID to look up the current location (the RLOC) of that
the current location (the RLOC) of that EID. EID.
The lookup is performed through a "mapping system", which is the The lookup is performed through a mapping system, which is the heart
heart of LISP: it is a distributed directory of "mappings" from EIDs of LISP: it is a distributed directory of mappings from EIDs to
to RLOCs. The destination RLOC(s) will normally be the address(es) RLOCs. The destination RLOC(s) is (are) normally the address(es) of
of the ETR(s) near the ultimate destination. the ETR(s) near the ultimate destination.
The ITR then generates a new outer header for the original packet, The ITR then generates a new outer header for the original packet,
with that header containing the ETR's RLOC as the wrapped packet's with that header containing the ETR's RLOC as the wrapped packet's
destination, and the ITR's own address (i.e. the RLOC usually destination, and the ITR's own address (i.e. the RLOC usually
associated with the original source) as the wrapped packet's source, associated with the original source) as the wrapped packet's source,
and sends it off. and sends it off.
When the packet arrives at the ETR, that outer header is stripped When the packet arrives at the ETR, that outer header is stripped
off, and the original packet is forwarded to the original ultimate off, and the original packet is forwarded to the original ultimate
destination for normal processing. destination for normal processing.
Return traffic is handled similarly, often (depending on the Return traffic is handled similarly, often (depending on the
network's configuration) with the original ITR and ETR switching network's configuration) with the original ITR and ETR switching
roles. The ETR and ITR functionality is usually co-located in a roles. The ETR and ITR functionality is usually co-located in a
single LISP router; these are normally denominated as "xTRs". single LISP router; these are normally denominated as xTRs.
6.3. Mapping from EIDs to RLOCs 6.3. Mapping from EIDs to RLOCs
The "mappings" from EIDs to RLOCs are provided by a distributed, and The mappings from EIDs to RLOCs are provided by a distributed, and
potentially replicated, database, the "mapping database", which is potentially replicated, database, the "mapping database", which is
the heart of LISP. (Here, and in other places in LISP, the the heart of LISP. Here, and in other places in LISP, the
replication is not a deep architectural concept, simply an replication is not a deep architectural concept, simply an
engineering device to obtain reliability via potential redundancy.) engineering device to obtain reliability via potential redundancy.
Entities which need mappings get them from the "mapping system",
which is a collection of sub-systems through which clients can find
and obtain mappings. (The mapping system will be discussed in more
detail below, in Section 8.2, "Control Plane - Mapping System
Overview" and Section 13, "The Mapping System".)
Mappings are are normally distributed via a 'pull' mechanism; in Entities which need EID-to-RLOC mappings get them from the mapping
other words, they are generally not pre-loaded, but requested on system, which is a collection of sub-systems through which clients
demand. Once obtained by an ITR, they are cached by the ITR, for can find and obtain mappings as discussed in more details in
performance reasons. Section 8.2 and Section 13.
Extensive studies, including large-scale simulations driven by Mappings are normally distributed via a pull mechanism (i.e., not
lengthy recordings of actual traffic at several major sites, have pre-loaded, but requested on demand). Once obtained by an ITR, they
been performed to verify that this 'pull and cache' approach is are cached for performance reasons.
viable, in practical engineering terms. (This subject will be
discussed in more detail in Section 12.9, "xTR Mapping Cache
Performance", below, including references to the studies.)
6.4. Interworking With Non-LISP-Capable Endpoints 6.4. Interworking With Non-LISP-Capable Endpoints
It is clearly crucial to provide the capability for 'easy' It is clearly crucial to provide the capability for easy
interoperation between "LISP hosts" - i.e. they are behind xTRs, and interoperation between "LISP hosts" - i.e. they are behind xTRs, and
their EIDs are in the mapping database - and existing non-LISP-using their EIDs are in the mapping database - and existing non-LISP-using
hosts (often called 'legacy' hosts) or legacy "sites". hosts (often called 'legacy' hosts) or legacy "sites".
To allow such interoperation, a number of mechanisms have been To allow interoperation between devices hosted in a LISP site and
designed. One approach uses proxy LISP routers, called "PITRs" devices not belonging to a LISP site (non-LISP site), an interworking
(proxy ITRs) and "PETRs" (proxy ETRs), to provide LISP functionality mechanism based on proxies has been designed. Proxy ITRs (PITR)
during interaction with legacy hosts. Another approach uses a router encapsulate packets sent from non-LISP sites to LISP sites while
with combined LISP and NAT ([RFC1631]) functionality, named a LISP- Proxy ETRs (PETR) decapsulate packets sent from LISP sites to non-
NAT. LISP sites. More details are given in Section 15.2.1.
(See Section 15.2.1, "Proxy LISP Routers", and Section 15.2.2, "LISP-
NAT", respectively, for details of each, and their respective
advantages and disadvantages.)
6.5. Security in LISP 6.5. Security in LISP
{{Suggestion by editors: Rewrite this section: (first 3 paragraphs)
It contains a general discussion as well as strong statements that
are not supported by any WG document. (last 3 paragraphs) It
enumerates the security mechanisms specified in LISP but does not
describe them.}}
To provide a brief overview of security in LISP, it is definitely To provide a brief overview of security in LISP, it is definitely
understood that LISP needs to be highly _securable_, especially in understood that LISP needs to be highly _securable_, especially in
the long term; over time, the attacks mounted by 'bad guys' are the long term; over time, the attacks mounted by 'bad guys' are
becoming more and more sophisticated. So LISP, like DNS, needs to be becoming more and more sophisticated. So LISP, like DNS, needs to be
_capable_ of providing 'the very best' security there is. _capable_ of providing 'the very best' security there is.
At the same time, there is a conflicting goal: it must be deployable At the same time, there is a conflicting goal: it must be deployable
at a a viable cost. That means two things: First, as an experiment, at a a viable cost. That means two things: First, as an experiment,
we cannot expect to create the complete security apparatus which we we cannot expect to create the complete security apparatus which we
might see in the finished product, including both design and might see in the finished product, including both design and
implementation. Second, security needs to be flexible, so that we implementation. Second, security needs to be flexible, so that we
don't overload the users with more security than they need at any don't overload the users with more security than they need at any
point. point.
To accomplish these divergent goals, the approach taken is to first To accomplish these divergent goals, the approach taken is to first
analyze what LISP needs for security. [Threats]. Then, steps can be analyze what LISP needs for security. [I-D.ietf-lisp-threats].
taken to ensure that the appropriate 'hooks' (such as packet fields) Then, steps can be taken to ensure that the appropriate 'hooks' (such
are included at an early stage, when doing so is still easy. Over as packet fields) are included at an early stage, when doing so is
time, additional mechanisms will be fully specified, implemented, and still easy. Over time, additional mechanisms will be fully
deployed. specified, implemented, and deployed.
LISP does already include a number of security mechanisms; in LISP does already include a number of security mechanisms; in
particular, requesting mappings can be secured (see Section 12.8, particular, requesting mappings can be secured (see Section 12.8,
"Security of Mapping Lookups"), as can registering of xTRs (see "Security of Mapping Lookups"), as can registering of xTRs (see
Section 13.1.3, "Map-Register and Map-Notify Messages"); the key Section 13.1.3, "Map-Register and Map-Notify Messages"); the key
database of the mapping system is also secured (see Section 13.4, database of the mapping system is also secured (see Section 13.4,
"Security of the DDT Indexing Sub-system"). "Security of the DDT Indexing Sub-system").
The existing security mechanisms, and their configuration (which is The existing security mechanisms, and their configuration (which is
mostly manual at this point) currently in LISP are felt to be mostly manual at this point) currently in LISP are felt to be
adequate for the needs of the on-going early stages of deployment; adequate for the needs of the on-going early stages of deployment;
experience will indicate when improvements are required (within the experience will indicate when improvements are required (within the
constraints of the conflicting goal given above). constraints of the conflicting goal given above).
For more on LISP's security philosophy; see [Perspective], Section For more on LISP's security philosophy; see
"Security", where it is laid out in some detail. [I-D.ietf-lisp-perspective], Section 7 "Security", where it is laid
out in some detail.
7. Initial Applications 7. Initial Applications
{{Reorder the whole section in popularity order?}} {{Suggested by editors: Move this section after section 8, the
applications should not be described before LISP has been fully
described.
{{Suggested by Noel: Reorder the whole section in popularity order?}}
As previously mentioned, it is felt that LISP will provide even the As previously mentioned, it is felt that LISP will provide even the
earliest adopters with some useful capabilities, and that these earliest adopters with some useful capabilities, and that these
capabilities will drive early LISP deployment. capabilities will drive early LISP deployment.
It is very imporant to note that even when used only for It is very imporant to note that even when used only for
interoperation with existing un-modified hosts, use of LISP can still interoperation with existing un-modified hosts, use of LISP can still
provide benefits to the site which has deployed it - and, perhaps provide benefits to the site which has deployed it - and, perhaps
even more importantly, can do so _to both sides_. This even more importantly, can do so to both sides. This characteristic
characteristic acts to further enhance the utility for early adopters acts to further enhance the utility for early adopters of LISP.
of LISP. .
Note also that this section only lists some early applications and Note also that this section only lists some early applications and
benefits. See [Perspective], in the Section "Goals of LISP", for a benefits. See [I-D.ietf-lisp-perspective], in the Section "Goals of
more extensive discussion of some of what LISP might ultimately LISP", for a more extensive discussion of some of what LISP might
provide. ultimately provide.
7.1. Provider Independence 7.1. Provider Independence
Provider independence (i.e. the ability to easily change one's Provider independence (i.e. the ability to easily change one's
Internet Service Provider) is a good example of the utility of Internet Service Provider) is a good example of the utility of
separating location and identity. separating location and identity.
The problem is simple: for the global routing to scale, addresses To limit global routing table size addresses need to be aggregated.
need to be aggregated; i.e. things which are close in the overall To that aim networks can use provider aggregatable addresses
network's connectivity need to have closely related addresses (so- ([RFC4116]) which means that the IP prefixes of networks are sub-
called "provider aggregatable" addresses). [RFC4116] However, if prefixes of their provider. This solutions allows to reduce
this principle is followed, it means that when an entity switches scalability issues of the global routing table but it means that when
providers (i.e. it moves to a different 'place' in the network), it a network switches providers it has to re-number all its devices
has to re-number, a painful undertaking. [RFC5887] which is known to be complex in current networks [RFC5887].
Having separate namespaces for location and identity greatly reduces Having separate namespaces for location and identity greatly reduces
the problems involved with re-numbering; an organization which moves the problems involved with re-numbering; an organization which moves
retains its EIDs (which are how most other parties refer to its retains its EIDs (which are how most other parties refer to its
nodes), but is allocated new RLOCs, and the mapping system can nodes), but is allocated new RLOCs, and the mapping system can
quickly provide the updated mapping from the EIDs to the new RLOCs. quickly provide the updated mapping from the EIDs to the new RLOCs.
7.2. Multi-Homing 7.2. Multi-Homing
{{Suggested by editors: This section should be extended, it is
unclear the benefits that LISP brings to multihoming (.e.g, traffic
engineering, decoupled multihoming from the data-plane).
Multi-homing is another place where the value of separation of Multi-homing is another place where the value of separation of
location and identity became apparent. There are several different location and identity became apparent. There are several different
sub-flavours of the multi-homing problem - e.g. depending on whether sub-flavours of the multi-homing problem - e.g. depending on whether
one wants open TCP connections to keep working, etc - and other axes one wants open TCP connections to keep working, etc - and other axes
as well (e.g. site multi-homing versus host multi-homing). as well (e.g. site multi-homing versus host multi-homing).
In particular, for the 'keep open connections up' case, without In particular, for the 'keep open connections up' case, without
separation of location and identity, with most currently deployed separation of location and identity, with most currently deployed
implementations, the only currently feasible approach is to use implementations, the only currently feasible approach is to use
provider-independent addressses - which moves the problem into the provider-independent addressses - which moves the problem into the
global routing system, with attendant costs. This approach is also global routing system, with attendant costs. This approach is also
not really feasible for host multi-homing. not really feasible for host multi-homing.
7.3. Traffic Engineering 7.3. Traffic Engineering
{{Suggestion by editors: Merge this section with the previous one, TE
is not practical without multihoming}}
{{Needs a fix - not sure what.}} {{Needs a fix - not sure what.}}
Traffic engineering (TE) [RFC3272], desirable though this capability Traffic engineering (TE) [RFC3272], desirable though this capability
is in a global network, is currently somewhat problematic to provide is in a global network, is currently somewhat problematic to provide
in the Internet. The problem, fundamentally, is that this capability in the Internet. The problem, fundamentally, is that this capability
was not forseen when the Internet was designed, so the support for it was not forseen when the Internet was designed, so the support for it
via 'hacks' is neither clean, nor flexible. via hacks is neither clean, nor flexible.
TE is, fundamentally, a routing issue. However, the current Internet TE is, fundamentally, a routing issue. However, the current Internet
routing architecture, which is basically the Baran design of fifty routing architecture, which is basically the Baran design of fifty
years ago [Baran] (a single large, distributed computation), is ill- years ago [Baran] (a single large, distributed computation), is ill-
suited to provide TE. The Internet seems a long way from adopting a suited to provide TE. The Internet seems a long way from adopting a
more-advanced routing architecture, although the basic concepts for more-advanced routing architecture, although the basic concepts for
such have been known for some time. [RFC1992] such have been known for some time. [RFC1992]
Although the identity-location mapping layer is thus a poor place, Although the identity-location mapping layer is thus a poor place,
architecturally, to provide TE capabilities, it is still an architecturally, to provide TE capabilities, it is still an
skipping to change at line 648 skipping to change at page 14, line 52
table). table).
In addition, instead of the entire network incurring the costs In addition, instead of the entire network incurring the costs
(through the routing system overhead), when using a mapping layer to (through the routing system overhead), when using a mapping layer to
provide TE, the overhead is limited to those who are actually provide TE, the overhead is limited to those who are actually
communicating with that particular destination. communicating with that particular destination.
LISP includes a number of features in the mapping system to support LISP includes a number of features in the mapping system to support
TE. (described in Section 8.2, "Control Plane - Mapping System TE. (described in Section 8.2, "Control Plane - Mapping System
Overview", below); more details about using LISP for TE can be found Overview", below); more details about using LISP for TE can be found
in [LISP-TE]. in [I-D.farinacci-lisp-te].
Also, a number of academic papers have explored how LISP can be used Also, a number of academic papers have explored how LISP can be used
to do TE, and how effective it can be. See the online LISP to do TE, and how effective it can be. See the online LISP
Bibliography ([Bibliography]) for information about them. Bibliography ([Bibliography]) for information about them.
7.4. Routing 7.4. Routing
{{Suggestion by editors: Remove this section, LISP is not a routing
protocol.}}
Multi-homing and Traffic Engineering are both, in some sense, uses of Multi-homing and Traffic Engineering are both, in some sense, uses of
LISP for routing, but there are many other routing-related uses for LISP for routing, but there are many other routing-related uses for
LISP. LISP.
One of the major original motivations for the separation of location One of the major original motivations for the separation of location
and identity in general, and thus LISP, was to reduce the growth of and identity in general, and thus LISP, was to reduce the growth of
the routing tables in the "Internet core", the part where routes to the routing tables in the "Internet core", the part where routes to
_all_ ultimate destinations must be available. LISP is expected to _all_ ultimate destinations must be available. LISP is expected to
help with this; for more detail, see Section 15.4, "LISP and Core help with this; for more detail, see Section 15.4, "LISP and Core
Internet Routing", below. Internet Routing", below.
LISP may also have more local applications in which it can help with LISP may also have more local applications in which it can help with
routing; see, for instance, [CorasBGP]. routing; see, for instance, [CorasBGP].
7.5. Mobility 7.5. Mobility
{{Suggestion by editors: Remove this section, mobility is not in
charter.}}
Mobility is yet another place where separation of location and Mobility is yet another place where separation of location and
identity is obviously a key part of a clean, efficient and high- identity is a key part of a clean, efficient and high-functionality
functionality solution. Considerable experimentation has been solution. Considerable experimentation has been completed on doing
completed on doing mobility with LISP. mobility with LISP.
The mobility provided by LISP allows active sessions to survive moves The mobility provided by LISP allows active sessions to survive moves
(provided of course that there is not a period of inaccessability (provided of course that there is not a period of inaccessibility
which exceeds a timeout). LISP mobility also will typically have which exceeds a timeout). LISP mobility also will typically have
better packet 'stretch' (i.e. increase in path length) compared to better packet stretch (i.e. increase in path length) compared to
traditional mobility schemes, which use a 'home agent'. traditional mobility schemes, which use a home agent.
7.6. Traversal Across Alternate IP Versions 7.6. Traversal Across Alternate IP Versions
Note that LISP inherently supports intermixing of various IP versions Note that LISP inherently supports intermixing of various IP versions
for packet carriage; IPv4 packets might well be carried in IPv6, or for packet carriage; IPv4 packets might well be carried in IPv6, or
vice versa, depending on the network's configuration. vice versa, depending on the network's configuration.
This capability allows an 'island' of operation of one type to be This capability allows an island of operation of one type to be
automatically tunneled over a stretch of infrastucture which only automatically tunneled over a stretch of infrastucture which only
supports the other type. supports the other type.
While the machinery of LISP may seem too heavy-weight to be good for
such a mundane use, this is not intended as a 'sole use' case for
deployment of LISP. Rather, it is something which, if LISP is being
deployed anyway (for its other advantages), is an added benefit that
one gets 'for free'.
7.7. Virtual Private Networks 7.7. Virtual Private Networks
{{Suggestion by editors: Remove this section, not covered by any WG
document}}
L2 and L3 {{Need to add text here - This used to be part of 'Local' L2 and L3 {{Need to add text here - This used to be part of 'Local'
below, but we decided this was so important it deserved its own below, but we decided this was so important it deserved its own
section. Maybe move this up further, as it seems to be the most section. Maybe move this up further, as it seems to be the most
important 'early adopter' application?}} important 'early adopter' application?}}
This includes support of VPN's for segmentation and multi-tenancy The mapping-and-encapsulation nature of LISP makes it a perfect
(i.e. a spatially separated private VPN whose components are joined candidate for VPN solutions. In this case, private parts of the VPN
together using the public Internet as a backbone). form LISP sites and the IP addresses of devices in the private parts
are composing EID spaces. The interconnection between the LISP sites
is the public network and IP addresses in the interconnection compose
the RLOC space. A major advantage of using LISP to construct VPN
resides in the simplicity of the configurations: each xTR (i.e., VPN
end) is configured to query the mapping system to retrieve mappings
making the glue between the public (RLOC space) and the private (EID
space) of the VPN.
This includes support of multi-tenancy where several private networks
can be carried over the same underlayer network. Thanks to the
instance-id field, multi-tenant network can even use the exact same
addresses as the xTR distinguishes the tenant based on the value of
the instance-id. The multiple address family support in LISP
mappings also allows to build private networks using a different
addressing family than the carrier (e.g., IPv6 over IPv4).
7.8. Local Uses 7.8. Local Uses
{{Suggestion by editors: Remove this section. The section contains a
general discussion about the applicability of LISP in intra-domain
scenarios, however it does not describe any specific application.}}
LISP has a number of use cases which are within purely LISP has a number of use cases which are within purely
organizationally-local contexts, i.e. not in the larger Internet. organizationally-local contexts, i.e. not in the larger Internet.
These fall into two categories: uses seen on the Internet (above), These fall into two categories: uses seen on the Internet (above),
but here on a private (and usually small scale) setting; and but here on a private (and usually small scale) setting; and
applications which do not have a direct analog in the larger applications which do not have a direct analog in the larger
Internet, and which apply only to local deployments. Internet, and which apply only to local deployments.
Among the former are multi-homing and IP version traversal. {{This Among the former are multi-homing and IP version traversal. {{This
was marked to be deleted - why? The next part doesn't make sense was marked to be deleted - why? The next part doesn't make sense
without this first?}} without this first?}}
Among the latter class, non-Internet applications which have no Among the latter class, non-Internet applications which have no
analog on the Internet, are the following example applications: analog on the Internet, are the following example applications:
virtual machine mobility in data centers; other non-IP EID types such
as local network MAC addresses, or application specific data. virtual machine mobility in data centers; non-IP EID types such as L2
MAC addresses, or application specific data.
Several of the applications listed in this section are the ones which Several of the applications listed in this section are the ones which
have been most popular for LISP in practise; these include virtual have been most popular for LISP in practise; these include virtual
networks, and virtual machine mobility. networks, and virtual machine mobility.
These often show a synergistic tendency, in that a site which These often show a synergistic tendency, in that a site which
installs LISP to do one, often finds that then becomes a small matter installs LISP to do one, often finds that then becomes a small matter
to use it for the second. Given all the things which LISP can do, it to use it for the second. Given all the things which LISP can do, it
is hoped that this synergistic effect will continue to expand LISP's is hoped that this synergistic effect will continue to expand LISP's
uses. uses.
{{Preceeding paragraphs should probably get moved up into VPN {{Preceeding paragraphs should probably get moved up into VPN
section?}} section?}}
8. Major Functional Subsystems 8. Major Functional Subsystems
LISP has only two major functional sub-systems - the collection of {{Suggestion by editors: This section should appear before since it
LISP "packet switches" (the xTRs), which form the 'data plane' of describes key aspects of LISP (e.g., LISP decoupled control and data-
LISP; and the "mapping system", the most important part of the plane).}}
'control plane', which manages the "mapping database".
LISP has two major functional sub-systems: the xTRs which form the
data-plane of LISP; and the mapping system which forms the control
plane that maintains and distributes the mapping database.
The purpose and operation of each is described at a high level below, The purpose and operation of each is described at a high level below,
and then, later on, in a fair amount of detail, in separate sections and then, later on, in a fair amount of detail, in separate sections
on each (Sections Section 12, "xTRs", and Section 13, "The Mapping on each (Section 12 and Section 13).
System", respectively).
8.1. Data Plane - xTRs Overview 8.1. Data Plane - xTRs Overview
xTRs are packet switches which have been augmented with extra {{Suggestion by editors: Extend this section, it misses key LISP
functionality in both the data and control planes. The data plane data-plane aspects, such as the map-cache.}}
functions in ITRs include deciding which packets need to be given
LISP processing (since packets to non-LISP hosts may be sent as they
are); i.e. looking up the mapping; encapsulating (wrapping) the
packet; and sending it to the ETR.
This encapsulation is done using UDP [RFC768] (for reasons to be xTRs are routers that have been augmented with extra functionality in
explained below, in Section 12.2, "UDP Encapsulation Details"), along both the data and control planes. The data plane functions in ITRs
with an additional outer IPvN header (to hold the source and include deciding which packets need to be given LISP processing
destination RLOCs). To the extent that traffic engineering features (since packets to non-LISP hosts may be sent as they are); i.e.
are in use for a particular EID, the ITRs implement them as well. looking up the mapping; encapsulating (wrapping) the packet; and
sending it to the ETR.
This encapsulation is done using UDP [RFC0768], along with an
additional outer IP header (to hold the source and destination
RLOCs). To the extent that traffic engineering features are in use
for a particular EID, the ITRs implement them as well.
In the ETR, the data plane simply decapsulates (unwraps) the packets, In the ETR, the data plane simply decapsulates (unwraps) the packets,
and forwards the now-normal packets to the ultimate destination. and forwards the it to the destination.
Control plane functions in ITRs include: asking for {EID->RLOC} Control plane functions in ITRs include: asking for EID-to-RLOC
mappings via request control messages (Map-Request packets); handling mappings via Map-Request packets; handling the returning reply
the returning reply control messages (Map-Reply packets), which control messages (i.e., Map-Reply packets), which contain the EID-to-
contain the requested information; managing the local "mapping cache" RLOC mapping; managing the local mapping cache and checking for the
of "mappings"; checking for the "reachability" and "liveness" of reachability of destination ETR's RLOCs.
their neighbour ETRs; and checking for outdated mappings and
requesting updates.
In the ETR, control plane functions include participating in the In the ETR, control plane functions include participating in the
reachability and liveness function (see Section 16.4, "Verifying ETR reachability tests (see Section 16.4); interacting with the mapping
Liveness"); interacting with the mapping sub-system to let it know sub-system to let it know what mapping this ETR can provide (see
what mapping this ETR can provide (see Section 8.2.2, "Interface to Section 8.2.2); and answering Map-Request packets from ITRs for those
the Mapping System"); and answering requests from ITRs for those mappings.
mappings (ditto).
8.1.1. Mapping Cache Performance 8.1.1. Mapping Cache Performance
{{Suggestion by editors: Push this section further in the document,
the cache performance is not a "Major LISP subsystem"}}
As mentioned, studies have been performed to verify that caching As mentioned, studies have been performed to verify that caching
mappings in ITRs is viable, in practical engineering terms. These mappings in ITRs is viable, in practical engineering terms. These
studies not only verified that such caching is feasible, but also studies not only verified that such caching is feasible, but also
provided some insight for designing ITR "mapping caches". provided some insight for designing ITR "mapping caches".
Briefly, they took lengthy traces of all packets leaving a large Briefly, they took lengthy traces of all packets leaving a large
site, over a period of a week or so, and used those to drive site, over a period of a week or so, and used those to drive
simulations which showed how many mappings would be required. It simulations which showed how many mappings would be required. It
also allowed analysis of how much control traffic (for loading needed also allowed analysis of how much control traffic (for loading needed
mappings) would result, using various cache sizes and replacement mappings) would result, using various cache sizes and replacement
algorithms. algorithms. These studies provide an insight into how well LISP can
be expected to perform, and scale, over time.
A more extended look at the results us given below, in Section 12.9, A more extended look at the results us given below, in Section 12.9,
"xTR Mapping Cache Performance". "xTR Mapping Cache Performance".
Obviously, these studies are all snapshots of a particular point in
time, and as the Internet continues its life-cycle they will
increasingly become out-dated. However, they are useful because they
provide an insight into how well LISP can be expected to perform, and
scale, over time.
8.2. Control Plane - Mapping System Overview 8.2. Control Plane - Mapping System Overview
{{Suggestion by editors: Rewrite: Replace EID block terminology
(along with its description) with the very common term "prefix".
Describe Map-Request/Map-Reply LISP signaling messages.}}
The mapping system's entire purpose is to give ITRs on-demand access The mapping system's entire purpose is to give ITRs on-demand access
to the mapping database, which is a distributed, and potentially to the mapping database, which is a distributed, and potentially
replicated, database which holds mappings between EIDs (identity) and replicated, database which holds mappings between EIDs (identity) and
RLOCs (location), along with needed ancillary data (e.g. lifetimes). RLOCs (location), along with needed ancillary data (e.g. lifetimes).
To be exact, it contains mappings between EID "blocks" and RLOCs (the To be exact, it contains mappings between EID blocks and RLOCs (the
block size is given explicitly, as part of the syntax). Support for block size is given explicitly, as part of the syntax). Support for
blocks is both for minimizing the administrative configuration blocks is both for minimizing the administrative configuration
overhead, as well as for operational efficiency; e.g. when a group of overhead, as well as for operational efficiency; e.g. when a group of
EIDs are behind a single xTR. EIDs are behind a single xTR. In IP blocks are delimited by their IP
prefix.
However, the block may be, and sometimes is, as small as a single However, the block may be, and sometimes is, as small as a single
EID. However, since mappings are only loaded upon demand, if smaller EID. However, since mappings are only loaded upon demand, if smaller
blocks become predominant, then the increased size of the overall blocks become predominant, then the increased size of the overall
database is far less problematic than if the Internet's routing database is far less problematic than if the Internet's routing
tables came to be dominated by such small entries. tables came to be dominated by such small entries.
A particular EID (or EID block) may have more than one RLOC, or may A particular EID (or EID block) may be associated to than one RLOC,
change its RLOC(s), while keeping its basic identity. and may change the association with time.
Also, in general, throughout LISP, anyplace a name (EID, RLOC, etc) Also, in general, throughout LISP, the address family of EIDs and
appears in a control packet, the packet format also includes an RLOCs is explicitly mentioned in control packet.
Address Family Identifier (AFI) for that name. [AFI] The inclusion
of the AFI allows LISP (and in particular, the mapping system
interface, as embodied in those control packets) a great deal of
flexibility. (See [Perspective], Section "Namespaces" for more on
this.)
Finally, the mapping from an EID (or EID block) contains not just the Finally, the mapping from an EID (or EID block) contains not just the
RLOC(s), but also (for each RLOC for any given EID entry) priority RLOC(s), but also (for each RLOC for any given EID entry) priority
and weight fields (to allow allocation of load between several RLOCs and weight fields (to allow allocation of load between several RLOCs
at a given priority); this allows a certain amount of traffic at a given priority); this allows a certain amount of traffic
engineering to be accomplished with LISP. engineering to be accomplished with LISP.
8.2.1. Mapping System Organization 8.2.1. Mapping System Organization
The "mapping system" is actually split into what are effectively {{Suggestion by editors: Rewrite: Describe key Mapping System
three major functional sub-systems (although the latter two are components: Map-Server/Map-Resolver}}
closely integrated, and appear to most entities in the LISP system as
a single sub-system).
The first is the actual mappings themselves, collectively the The mapping system is split into three functional sub-systems.
"mapping database"; they are held by the ETRs, and an ITR which needs
a mapping gets it (effectively) directly from the ETR. This co- The first is the actual mappings themselves, collectively the mapping
location of the authoritative version of the mappings, and the database; they are held by the ETRs, and an ITR which needs a mapping
forwarding functionality which it describes, is an instance of fate- gets it (effectively) directly from the ETR. This co-location of the
sharing. [Clark] authoritative version of the mappings, and the forwarding
functionality which it describes, is an instance of fate-sharing.
[Clark]
To find the appropriate ETR(s) to query for the mapping, the second To find the appropriate ETR(s) to query for the mapping, the second
two sub-systems form an 'indexing system', itself also based on a two sub-systems form an indexing system, itself also based on a
distributed, potentially replicated database. It provides distributed, potentially replicated database. It provides
information on which ETR(s) are authoritative sources for the various information on which ETR(s) are authoritative sources for the various
{EID -> RLOC} mappings which are available. The two sub-systems EID-to-RLOC mappings which are available. The two sub-systems which
which form it are the client interface sub-system, and "indexing sub- form it are the client interface sub-system, and indexing sub-system
system" (which holds and provides the actual information). (which holds and provides the actual information).
8.2.2. Interface to the Mapping System 8.2.2. Interface to the Mapping System
{{Suggestion by editors: has been rewritten: This section should
appear earlier since it describes key LISP components (Map-Request/
Map-Reply/Map-Server/Map-Resolver}}
The client interface to the indexing system from an ITR's point of The client interface to the indexing system from an ITR's point of
view is not with the indexing sub-system directly; rather, it is view is not with the indexing sub-system directly; rather, it is
through the client-interface sub-system, which is provided by LISP through the Map-Resolvers (MRs) and Map-Servers (MSs).
nodes called Map-Resolvers (MRs) and Map-Servers (MSs).
ITRs send request control messages (Map-Request packets) to an MR.
(This interface is probably the most important standardized interface
in LISP - it is the key to the entire system.)
The MR then uses the indexing sub-system to allow it to forward the To obtain the mapping for an EID, the ITRs sends Map-Request packet
Map-Request to an appropriate Map-Server (MS), which in turn sends to an MR. The MR then uses the indexing sub-system to allow it to
the Map-Request on to the appropriate ETR. The latter is forward the Map-Request to an appropriate Map-Server (MS), which in
authoritative for the actual contents of all mappings for those EID turn sends the Map-Request on to the appropriate ETR. The latter is
namespace blocks which have been delegated to it. authoritative for the actual mappings for the EID.
The ETR then formulates reply control messages (Map-Reply packets), The ETR then sends the mappings for that EID in the form of aMap-
which are sent to the ITR. The details of the indexing sub-system Reply packets, which is sent directly to the ITR, without passing
are thus hidden from the ITRs. through the indexing sub-system and MR. The details of the indexing
sub-system are thus hidden from the ITRs.
(Note that in some cases, it is desirable for the MS to reply on Note that in proxy mode, the MS replies on behalf of the ETR. When
behalf of the ETR, in so-called 'proxy' mode. This behaviour can be this the case, the map-replies is tagged to indicate that the answer
selected when the ETR registers with the MR, described immediately is not delivered from the authoritative ETR but from the MS instead.
below.)
Similarly, the client interface to the indexing system from an ETR's The interface to the indexing system from an ETR's point of view is
point of view is through LISP nodes called Map-Servers (MSs). ETRs made through MSes. ETRs send Map-Register packets to their
send registration control messages (Map-Register packets) to an MS, designated MSes. The effect of a Map-Register is to inform the MS
which makes the information about the mappings which the ETR about the mappings maintained by ETRs such that the MS can transmit
indicates it is authoritative for available to the indexing sub- the Map-Requests is receives to the appropriate ETRs.
system.
The MS formulates a reply control message (the Map-Notify packet), The MS optionally replies Map-Register packets with a Map-Notify
which confirms the registration, and is returned to the ETR. The packet to confirm the registration. The details of the indexing sub-
details of the indexing sub-system are thus likewise hidden from the system are thus likewise hidden from ETRs.
'ordinary' ETRs.
The fact that the details of the indexing sub-system are entirely The fact that the details of the indexing sub-system are entirely
hidden from xTRs gives considerably flexibility to this aspect of hidden from xTRs gives considerably flexibility to this aspect of
LISP. As long as any potential indexing sub-system can track where LISP. As long as any potential indexing sub-system can track where
mappings are, it could potentially be used; this would allow the mappings are, it could potentially be used; this would allow the
actual indexing sub-system to be replaced without needing to modify actual indexing sub-system to be replaced without needing to modify
the clients - as has happened once already (see below). the xTRs.
8.2.3. Indexing Sub-system 8.2.3. Indexing Sub-system
{{suggestion by editor: rename the section to "DDT"}}
The current indexing sub-system is the Delegated Database Tree (DDT), The current indexing sub-system is the Delegated Database Tree (DDT),
which is very similar to DNS ([DDT], [RFC1034]). Unlike DNS, the which is conceptually similar to DNS ([I-D.ietf-lisp-ddt],
actual mappings are not handled by DDT; DDT, as the indexing sub-
system, merely identifies the ETRs which hold the actual mappings.
DDT replaces an earlier indexing sub-system, ALT (Appendix B.4, "The [RFC1034]). DDT replaces the earlier LISP+ALT indexing sub-system
ALT Mapping Indexing Sub-system"); this swap validated the concept of ([RFC6836]). The seamless migration to DDT while LISP+ALT was
having a client-interface sub-system between the indexing sub-system, previously used validated the concept of having a client-interface
and the clients. sub-system between the indexing sub-system, and the clients.
8.2.3.1. DDT Overview 8.2.3.1. DDT Overview
Conceptually, DDT is fairly simple: like DNS, in DDT the delegation Conceptually, DDT is similar to the DNS, in DDT the delegation of the
of the EID namespace ([Perspective], Section "Namespaces-XEIDs") is EID namespace is instantiated as a delegation hierarchy, a tree of
instantiated as a "delegation hierarchy", a tree of "DDT vertices", DDT nodes, starting with the root DDT node. Each vertex is
starting with the 'root' DDT vertex. Each vertex is responsible for responsible for a block of the EID namespace.
a "block" of the EID namespace.
The 'root' vertex is reponsible for the entire namespace; any DDT The root node is responsible for the entire EID space; any DDT node
vertex can 'delegate' part(s) of its block of the namespace to child can delegate part(s) of its EID block to child DDT node(s). The
DDT vertex(s). The child vertex(s) can in turn further delegate child node(s) can in turn further delegate (necessarily smaller)
(necessarily smaller) blocks of namespace to their children, through blocks of namespace to their children, through as many levels as are
as many levels as are needed (for operational, administrative, etc, needed (for operational, administrative, etc, needs).
needs).
Just as with DNS, any particular vertex in the DDT delegation tree Just as with DNS, any particular vertex in the DDT delegation tree
may be instantiated in one or more "DDT servers". Multiple may be instantiated in one or more DDT servers. Multiple (redundant)
(redundant) servers for a given vertex would be used for reasons of servers for a given node would be used for reasons of performance,
performance, reliability and robustness. Obviously, all the servers reliability, and robustness. Obviously, all the servers which
which instantiate a particular vertex in the tree have to have instantiate a particular nodes in the tree have to have identical
identical data about that vertex; if they do not, when a Map-Request data about that node.
is sent to one that does not have consistent information with its
other sibling(s), incorrect results will be returned.
Also, although the delegation hierarchy is a strict tree, a single
DDT server could be authoritative for more than one block of the EID
namespace (i.e. it could be a server for more than one vertex).
Eventually, leaf vertices in the delegation hierarchy statically
delegate EID namespace blocks to MS's, which are DDT terminal
servers; i.e. a leaf of the tree is reached when the delegation
points to an MS instead of to another DDT vertex. {{Straighten out.}}
The MS is in direct communication with the ETR(s) which both i) are
authoritative for the mappings for that block, and ii) handle traffic
to all nodes in that block of EID namespace.
8.2.3.2. Use of DDT by MRs 8.2.3.2. Use of DDT by MRs
An MR which wants to find a mapping for a particular EID first An MR which wants to find a mapping for a particular EID first
interacts with the "DDT servers" which instantiate the "vertices" of interacts with the DDT servers which instantiate the nodes of the
the LISP "delegation hierarchy" tree, discovering (by querying the LISP delegation hierarchy tree, discovering (by querying the servers
servers for information about DDT vertices) the chain of delegations for information about DDT nodes) the chain of delegations which cover
which cover that EID. Eventually it is directed to an MS, which is that EID. Eventually it is directed to an MS, which is servicing an
the 'door' to an ETR which is authoritative for that EID. ETR which is authoritative for that EID.
Also, again like DNS, MRs cache information they receive about the Also, again like DNS, MRs may cache information they receive about
delegations in the delegation tree. This means that once an MR has the delegations in the delegation tree. This means that once an MR
been in operation for while, it will usually have much of the has been in operation for a while, it will usually have much of the
delegation information cached locally (especially the top levels of delegation information cached locally (especially the top levels of
the delegation tree). This allows them, when passed a request for a the delegation tree). This allows them, when passed a request for a
mapping by an ITR, to usually forward the mapping request to the mapping by an ITR, to usually forward the mapping request to the
appropriate MS without having to interact with all the DDT servers on appropriate MS without having to interact with all the DDT servers on
the path down the delegation tree, in order to find any particular the path down the delegation tree, in order to find any particular
mappping. mapping.
Thus, a typical resolution cycle would usually involve looking at Thus, a typical resolution cycle would usually involve looking at
some locally cached delegation information, perhaps loading some some locally cached delegation information, perhaps loading some
missing delegation entries into their delegation cache, and finally missing delegation entries into their delegation cache, and finally
sending the Map-Request to the appropriate MS. sending the Map-Request to the appropriate MS.
It should also be noted that the delegation tree is fairly static, It should also be noted that the delegation tree is fairly static,
since it reflects namespace allocations, which are themselves fairly since it reflects EID block allocations, which are themselves fairly
static. This stability has several important consequences. First, static. This stability has several important consequences. First,
it increases the performance of the mapping system, since the sub- it increases the performance of the mapping system, since the sub-
system almost never needs to be re-queried for information about system almost never needs to be re-queried for information about
intermediate vertices. Second, it is not necessary to include a intermediate vertices. {{comment from editor: does not understand
the next sentence...}}Second, it is not necessary to include a
mechanism to find out-dated delegations. [LISP-TREE] mechanism to find out-dated delegations. [LISP-TREE]
This contrasts with the _mappings_, which may change at a high rate - This contrasts with the mappings, which may change at a high rate -
changes which have no impact on the indexing sub-system. LISP is changes which have no impact on the indexing sub-system. The
designed to make sure that changes in the mappings are detected and potentially high dynamics of mappings explains why mappings are
acted upon fairly quickly; this allows LISP to provide a number of delivered directly from ETRs (or MSes in proxy mode) to ITRs and
capabilities, such as mobility. hence not cached at the MR level. LISP is designed to make sure that
changes in the mappings are detected and acted upon fairly quickly;
this allows LISP to provide a number of capabilities, such as
mobility.
9. Examples of Operation 9. Examples of operation
To aid in comprehension, a few examples are given of user packets To aid in comprehension, a few examples are given of user packets
traversing the LISP system. The first shows the processing of a traversing the LISP system. The first shows the processing of a
typical user packet which is LISP forwarded, i.e. what the vast typical user packet which is LISP forwarded, i.e. what the vast
majority of user packets will see. The second shows what happens majority of user packets will see. The second shows what happens
when the first packet to a previously-unseen ultimate destination (at when the first packet to a previously-unseen ultimate destination (at
a particular ITR) is to be processed by LISP. a particular ITR) is to be processed by LISP.
9.1. An Ordinary Packet's Processing 9.1. An Ordinary Packet's Processing
This case follows the processing of a typical user packet (for {{Suggestion by editors: This section should be earlier in the
instance, a normal TCP data or acknowledgment packet associated with document structure, examples are important -particularly for
an already-open TCP connection) - i.e. not the first packet sent from engineers- to explain how systems work}}
a given source to a given destination - as it makes its way from the
original source host to the ultimate destination.
When the packet has made its way through the local site to an ITR, This case follows the processing of a typical , {{comment from
which in this case is a border router for the site, the border router editors: text missing}} when the packet has made its way through the
looks up the destination address - an EID - in its local "mapping local site to an ITR, which in this case is a border router for the
cache". For EIDs which are IPvN addresses, this lookup usually uses site, the border router looks up the destination address - an EID -
the usual IPvN 'longest prefix match' algorithm. in its local mapping cache. For EIDs which are IP addresses, this
lookup uses the IP longest prefix matching algorithm.
It finds a mapping, which instructs it to wrap the packet in an outer It finds a mapping, which instructs it to wrap the packet in an outer
header - an IP packet, containing a UDP packet which contains a LISP header - an IP packet, containing a UDP packet which contains a LISP
header - and then the user's original packet (see Section 12.2, "UDP header - and then the user's original packet (see Section 12.2 for
Encapsulation Details", for the reasons for this particular choice). the reasons for this particular choice). The destination address in
The destination address in the outer header is set by the ITR to the the outer header is set by the ITR to the RLOC of the destination
RLOC of the destination ETR. ETR.
The encapsulated packet is then sent off through the Internet, using The encapsulated packet is then sent off through the RLOC space
normal Internet routing. (e.g., Internet), using normal Internet routing.
On arrival at the destination ETR, the ETR will notice that it is On arrival at the destination ETR, the ETR will notice that it is
listed as the destination in the outer header. It will examine the listed as the destination in the outer header. It will examine the
packet, detect that it is a LISP packet, and unwrap it. It will then packet, detect that it is a LISP packet, and unwrap it. It will then
examine the header of the user's original packet, and forward it examine the header of the user's original packet, and forward it
internally, through the local site, to the ultimate destination. internally, through the local site, to the ultimate destination.
At the ultimate destination, the packet will be processed, and may At the ultimate destination, the packet will be processed, and may
produce a return packet, which follows the exact same process in produce a return packet, which follows the exact same process in
reverse - with the exception that the roles of the ITR and ETR are reverse - with the exception that the roles of the ITR and ETR are
swapped. swapped.
9.2. A Mapping Cache Miss 9.2. A Mapping Cache Miss
{{Suggestion by editors: (same as previous section)}}
If a host sends a packet, and it gets to the ITR, and the ITR If a host sends a packet, and it gets to the ITR, and the ITR
determines that it does not yet have a "mapping cache" entry which determines that it does not yet have a mapping cache entry which
covers that destination EID, then additional processing ensues; it covers that destination EID, then additional processing ensues; it
has to look up the mapping in the mapping system (as previously has to look up the mapping in the mapping system (as previously
described in Section 6.2, "Basic Functionality"). described in Section 6.2).
The overall processing is shown below, in Figure 2: The overall processing is shown below, in Figure 2:
Mapping System ----- -----
| | 3 | |
----- ----- Map Resolver | | -------> | | Map Server
| | 3 | | | | | |
Map Resolver | | -------> | | Map Server ----- -----
| | | | ^ |
----- ----- Key: | |
^ | | |
Key: | | -- = Control | |
| | == = Data | |
-- = Control | | 2 | 5 | 4
== = Data | | | --- |
2 | 5 | 4 Host A | / \ | Host B
| --- | | |_ \ V
Host A | / \ | Host B ----- ----- \ ----- -----
| |_ \ V | | 1 | | 6 | | 7 | |
----- ----- \ ----- ----- | | =====> | ITR | =======> | ETR | =====> | |
| | 1 | | 6 | | 7 | | | | | | | | | |
| | =====> | ITR | =======> | ETR | =====> | | ----- ----- ----- -----
| | | | | | | |
----- ----- ----- -----
Figure 2: Packet Flow With Missing Mapping Figure 2: Packet flow with missing mapping
1. Source-EID sends packet (to Dest-EID) to ITR 1. Source-EID sends packet (to Dest-EID) to ITR
2. ITR sends Map-Request to Map Resolver
2. ITR sends Map-Request to Map-Resolver
3. Map-Resolver delivers Map-Request to Map-Server 3. Map-Resolver delivers Map-Request to Map-Server
4. Map-Server delivers Map-Request to ETR 4. Map-Server delivers Map-Request to ETR
5. ETR returns Map-Reply to ITR; ITR caches EID-to-RLOC(s) mapping 5. ETR returns Map-Reply to ITR; ITR caches EID-to-RLOC(s) mapping
6. ITR uses mapping to encapsulate to ETR; sends user packet to ETR 6. ITR uses mapping to encapsulate to ETR; sends user packet to ETR
7. ETR decapsulates packet, delivers to Dest-EID 7. ETR decapsulates packet, delivers to Dest-EID
The ITR first sends a Map-Request packet, giving the destination EID The ITR first sends a Map-Request packet, giving the destination EID
it needs a mapping for, to its MR. The MR will look in its cache of it needs a mapping for, to its MR. The MR will look in its cache of
delegation information to find the vertex which is the most specific delegation information to find the vertex which is the most specific
in the delegation tree for that destination EID . If it does not in the delegation tree for that destination EID . If it does not
have the address of an appropriate MS, it will query the DDT system, have the address of an appropriate MS, it will query the DDT system,
recursively if need be, in order to eventually find the address of recursively if need be, in order to eventually find the address of
such an MS. such an MS.
skipping to change at line 1099 skipping to change at page 24, line 33
have the address of an appropriate MS, it will query the DDT system, have the address of an appropriate MS, it will query the DDT system,
recursively if need be, in order to eventually find the address of recursively if need be, in order to eventually find the address of
such an MS. such an MS.
When it has the MS's address, it will send the Map-Request on to the When it has the MS's address, it will send the Map-Request on to the
MS, which then usually sends it on to an appropriate ETR. The ETR MS, which then usually sends it on to an appropriate ETR. The ETR
sends a Map-Reply to the ITR which needs the mapping; from then on, sends a Map-Reply to the ITR which needs the mapping; from then on,
processing of user packets through that ITR to that ultimate processing of user packets through that ITR to that ultimate
destination proceeds as above. destination proceeds as above.
Often the original user packet will have been discarded, and not To the best of our knowledge, in all LISP implementations, the
queued waiting for the mapping to be returned. When the host original user packet will have been discarded, and not queued waiting
retransmits such a packet, the mapping will be there, and the packet for the mapping to be returned. When the host retransmits such a
will be forwarded. Alternatively, it might have been queued, or packet, the mapping will be there, and the packet will be forwarded.
perhaps it was forwarded using a PITR. (Section 6.4, "Interworking Alternatively, it might have been forwarded using a PITR to avoid
With Non-LISP-Capable Endpoints") being dropped (Section 6.4).
10. Part II 10. Part II
{{comment from editors: is that the role of an introductory document
to enter in such level of details and discuss (mostly) all fields of
the protocol? }}
11. Design Approach 11. Design Approach
{{Suggestion by editors: Remove this section, it does not describe/
discuss anything relevant, it is only providing a reference to
another non-WG document.}}
Before describing LISP's components in more detail below, it it worth Before describing LISP's components in more detail below, it it worth
pointing out that what may seem, in some cases, like odd (or poor) pointing out that what may seem, in some cases, like odd (or poor)
design approaches do in fact result from the application of a design approaches do in fact result from the application of a
thought-through, and consistent, design philosophy used in creating thought-through, and consistent, design philosophy used in creating
them. {{Subjective: maybe JMH, Dino can help with better words?}} them. {{Subjective: maybe JMH, Dino can help with better words?}}
This design philosophy is covered in detail in in [Perspective], This design philosophy is covered in detail in
Section "Design"), and readers who are interested in the 'why' of [I-D.ietf-lisp-perspective], Section "Design"), and readers who are
various mechanisms should consult that; reading it may make clearer interested in the 'why' of various mechanisms should consult that;
the reasons for some engineering choices in the mechanisms given reading it may make clearer the reasons for some engineering choices
here. in the mechanisms given here.
12. xTRs 12. xTRs
As mentioned above (in Section 8.1, "Data Plane - xTRs Overview"), As mentioned above (in Section 8.1), xTRs are the essential LISP data
xTRs are the basic data-handling nodes in LISP, and, as such, form plane elements. This section explores some advanced topics related
the LISP data plane - although of necessity they are also involved in to xTRs.
some control plane functions. This section explores some advanced
topics related to xTRs. {{Suggestion by editors: remove next paragraph, brings nothing)}}
Careful rules have been specified for both TTL and ECN [RFC3168] to Careful rules have been specified for both TTL and ECN [RFC3168] to
ensure that passage through xTRs does not interfere with the ensure that passage through xTRs does not interfere with the
operation of these mechanisms. In addition, care has been taken to operation of these mechanisms. In addition, care has been taken to
ensure that 'traceroute' works when xTRs are involved. ensure that traceroute works when xTRs are involved.
12.1. When to Encapsulate 12.1. When to Encapsulate
An ITR knows that an ultimate destination is 'running' LISP (remember An ITR knows that an ultimate destination is running LISP (remember
that the actual destination machine itself probably knows nothing that the actual destination machine itself probably knows nothing
about LISP), and thus that it should perform LISP processing on a about LISP), and thus that it should perform LISP processing on a
packet (including potential encapsulation) if it has an entry in its packet (including potential encapsulation) if it has an entry in its
local "mapping cache" that covers the destination EID. local mapping cache that covers the destination address (it is then
called an EID).
Conversely, if the cache contains a 'negative' entry (indicating that Conversely, if the cache contains a negative entry (indicating that
the ITR has previously attempted to find a mapping that covers this the ITR has previously attempted to find a mapping that covers this
EID, and it has been informed by the mapping system that no such EID, and it has been informed by the mapping system that no such
mapping exists), it knows the ultimate destination is not running mapping exists), it knows the ultimate destination is not running
LISP, and the packet can be forwarded natively (i.e. not LISP- LISP, and the packet can be forwarded natively (i.e. not LISP-
encapsulated). encapsulated).
Note that the ITR cannot simply depend on the appearance, or non- Note that the ITR cannot simply depend on the appearance, or non-
appearance, of the destination in the routing tables in the "Internet appearance, of the destination in the routing tables in the Internet
core", as a way to tell if an ultimate destination is a LISP node or core, as a way to tell if a destination is a LISP node or not. That
not. That is because mechanisms to allow interoperation of LISP is because mechanisms to allow interoperation of LISP sites and
sites and 'legacy' sites necessarily involve advertising LISP sites' legacy sites necessarily involve advertising LISP sites' EIDs into
EIDs into the Internet core; in other words, LISP sites which need to the Internet core; in other words, LISP sites which need to
interoperate with 'legacy' nodes will appear in the Internet core interoperate with legacy nodes will appear in the Internet core
routing tables, along with non-LISP sites. routing tables, along with non-LISP sites.
12.2. UDP Encapsulation Details 12.2. UDP Encapsulation Details
Use of UDP (instead of, say, a LISP-specific protocol number) was Use of UDP (instead of, say, a LISP-specific protocol number) was
driven by the fact that many routers filter out 'unknown' protocols, driven by the fact that many routers and middle boxes filter out
so adopting a non-UDP encapsulation would have made the initial unknown protocols, so adopting a non-UDP encapsulation would have
deployment of LISP harder. compromised the initial deployment of LISP.
The UDP source port in the encapsulated packet is a 5-way hash of the
original source and ultimate destination in the inner header, along
with the ports, and the protocol.
This is because many ISPs use multiple parallel paths (so-called The UDP source port used for encapsulating packet is computed with a
'Equal Cost Multi-Path'), and load-share across them. Using such a 5-way hash of the original source and destination in the inner
hash in the source-port in the outer header both allows LISP traffic header, along with the ports, and the protocol. This is because many
to be load-shared, and also ensures that packets from individual ISPs use multiple parallel paths (so-called Equal Cost Multi-Path),
connections are delivered in order (since most ISPs try to ensure and load-share across them. Using such a hash in the source-port in
that packets for a particular {source, source port, destination, the outer header both allows LISP traffic to be load-shared, and also
destination port} tuple flow along a single path, and do not become ensures that packets from individual connections are delivered in
disordered). order (since most ISPs try to ensure that packets for a particular
flow follow a single path, and hence do not become disordered).
The UDP checksum is zero because the inner packet usually already has The UDP checksum is zero because the inner packet usually already has
a end-end checksum, and the outer checksum adds no value. [Saltzer] a end-end checksum, and the outer checksum adds no value ([Saltzer]).
In most exising hardware, computing such a checksum (and checking it {{Suggestion by editors: not sure that next statement is correct}} In
at the other end) would also present a major load, for no benefit. most exising hardware, computing such a checksum (and checking it at
the other end) would also present a major load, for no benefit.
12.3. Header Control Channel 12.3. Header Control Channel
LISP provides a multiplexed channel in the encapsulation header. It {{Suggestion by editors: Rewrite this section to improve readability,
is mostly (but not entirely) used for control purposes. (See use standard terminology (e.g., Cache Coherence/Reachability instead
[Perspective], Section "Architecture-Piggyback" for a longer of "Header Control Channel"). Split the mechanisms depending on its
discussion of the architectural implications of performing control goal (cache coherence/reachability) and describe them under the same
functions with data traffic.) context.}}
The general concept is that the header starts with an 'flags' field, LISP provides a multiplexed channel in the encapsulation header. It
and it also includes two data fields, the contents and meaning of is mostly (but not entirely) used for control purposes. The general
which vary, depending on which flags are set. This allows these concept is that the header starts with a flags field, and it also
fields to be multiplexed among a number of different low-duty-cycle includes two data fields, the contents and meaning of which vary,
functions, while minimizing the space overhead of the LISP depending on which flags are set. This allows these fields to be
encapsulation header. multiplexed among a number of different low-duty-cycle functions,
while minimizing the space overhead of the LISP.
12.3.1. Mapping Versioning 12.3.1. Mapping Versioning
One important use of the multiplexed control channel is mapping One important use of the multiplexed control channel is mapping
versioning; i.e. the discovery of when the mapping cached in an ITR versioning; i.e. the discovery of when the mapping cached in an ITR
is outdated. To allow an ITR to discover this, identifying sequence is outdated. To allow an ITR to discover this, identifying sequence
numbers are applied to different versions of a mappping. [RFC6834] numbers are applied to different versions of a mappping [RFC6834].
This allows an ITR to easily discover when a cached mapping has been This allows an ITR to easily discover when a cached mapping has been
updated by a more recent variant. updated by a more recent variant.
Version numbers are available in control messages (Map-Replies), but Version numbers are available in control messages (Map-Replies), but
the initial concept is that to limit control message overhead, the the initial concept is that to limit control message overhead, the
versioning mechanism should primarily use the multiplexed user data versioning mechanism should primarily use the multiplexed user data
header control channel. header control channel.
Versioning can operate in both directions: an ITR can advise an ETR Versioning can operate in both directions: an ITR can advise an ETR
what version of a mapping it is currently using (so the ETR can what version of a mapping it is currently using (so the ETR can
notify it if there is a more recent version), and ETRs can let ITRs notify it if there is a more recent version), and ETRs can let ITRs
know what the current mapping version is (so the ITRs can request an know what the current mapping version is (so the ITRs can request an
update, if their copy is outdated). update, if their copy is outdated).
At the moment version numbers are manually assigned, and ordered.
12.3.2. Echo Nonces 12.3.2. Echo Nonces
Another important use of the header control channel is for a Another important use of the header control channel is for a
mechanism known as the Nonce Echo, which is used as an efficient mechanism known as the Nonce Echo, which is used as an efficient
method for ITRs to check the reachability of "neighbour ETRs". method for ITRs to check the reachability of neighbour ETRs.
Basically, an ITR which wishes to ensure that an ETR is up, and Basically, an ITR which has to determine that an ETR is up, and
"reachable", sends a nonce to that ETR, carried in the encapsulation reachable, sends a nonce to that ETR, carried in the encapsulation
header; when that ETR (acting as an ITR) sends some other user data header; when that ETR (also acting as an ITR) sends some other user
packet back to the ITR (acting in turn as an ETR), that nonce is data packet back to the ITR (acting in turn as an ETR), that nonce is
carried in the header of that packet, allowing the original ITR to carried in the header of that packet, allowing the original ITR to
confirm that its packets are reaching that ETR. confirm that its packets are reaching that ETR.
Note that a lack of a response is not necessarily _proof_ that Note that a lack of a response is not necessarily proof that
something has gone wrong - but it strongly suggests that something something has gone wrong - but it strongly suggests that something
has, so other actions (e.g. a switch to an alternative ETR, if one is has, so other actions (e.g. a switch to an alternative ETR, if one is
listed; a direct probe; etc) are advised. listed; a direct probe; etc) are advised. (See Section 16.5 for more
about Echo Nonces.)
(See Section 16.5, "Verifying ETR Reachability", for more about Echo
Nonces.)
12.3.3. Instances 12.3.3. Instances
Another use of these header fields is for 'Instances' - basically, {{Suggestion by editors: Move and extend this section: - Instance ID
support for VPN's across backbones. [RFC4026] Since there is only is not a cache-coherence/reachability algorithm. Describe where and
one destination UDP port used for carriage of user data packets, and what is the Instance ID field Explain its applications}}
the source port is used for multiplexing (above), there is no other
way to differentiate among different destination address namespaces The LISP data-plane header is also used to support VPN and multi-
(which are often overlapped in VPNs). tenant networks. Since there is only one destination UDP port used
for carriage of user data packets, and the source port is used for
multiplexing, there is no other way to differentiate among different
destination EID spaces (which are often overlapped in VPNs and multi-
tenant networks).
12.4. Probing 12.4. Probing
RLOC-Probing (see [RFC6830], Section 6.3.2. "RLOC-Probing Algorithm" RLOC-Probing is a mechanism method that an ITR can use to determine
for details) is a mechanism method that an ITR can use to determine with that an ETR is up and reachable from the ITR. As a side-
with certainty that an ETR is up and reachable from the ITR. As a benefit, it gives RTT estimates.
side-benfit, it gives a rough RTT estimates.
It is quite a simple mechanism - an ITR simply sends a specially To probe the reachability of an RLOC, an ITR sends a specially marked
marked Map-Request directly to the ETR it wishes information about; Map-Request directly to the ETR it wishes information about; that ETR
that ETR sends back a specially marked Map-Reply. A Map-Request and sends back a specially marked Map-Reply. A Map-Request message and a
Map-Reply are used, rather than a special probing control-message Map-Reply message are used, rather than a special probing control-
pair, because as a side-benefit the ITR can discover if the mapping message pair, because as a side-benefit the ITR can discover if the
has been updated since it cached it. mapping has been updated since it cached it.
The probing mechanism is rather heavy-weight and expensive (compared {{Suggestion from editors: remove the following sentence as it is not
to mechanisms like the Echo-Nonce), since it costs a control message motivated by strong arguments}} The probing mechanism is rather
from each side, so it should only be used sparingly. However, it has heavy-weight and expensive (compared to mechanisms like the Echo-
the advantages of providing information quickly (a single RTT), and Nonce), since it costs a control message from each side, so it should
being a simple, direct, robust way of doing so. only be used sparingly.
If the number of active neighbour ETRs of the ITR is large, use of If the number of active neighbour ETRs of the ITR is large, use of
RLOC-Probing to check on their reachability will result in RLOC-Probing to check on their reachability will result in
considerable control traffic; such control traffic has to be spread considerable control traffic; such control traffic has to be spread
out to prevent a load peak. out to prevent a load peak.
Obviously, if RLOC-Probing is the only mechanism being used to detect Obviously, if RLOC-Probing is the only mechanism being used to detect
unreachable neighbour ETRs, the rate at which RLOC-Probing is done unreachable neighbour ETRs, the rate at which RLOC-Probing is done
will control the timeliness of the detection of loss of reachability. will control the timeliness of the detection of loss of reachability.
There is thus a tradeoff between overhead and responsiveness, There is thus a tradeoff between overhead and responsiveness,
particular when an ITR has a large fanout of neighbour ETRs. particular when an ITR has a large fanout of neighbour ETRs.
A further observation is that unless what are likely unreasonable
amounts of RLOC Probing are being done, Echo Nonce will generally
provide faster notification of loss of reachability (unless there is
little or no bi-directional traffic between the ITR and ETR). {{ENs
help reduce the amount of probing when both are in use}}
12.5. Mapping Lifetimes and Timeouts 12.5. Mapping Lifetimes and Timeouts
{{Suggestion by editors: Remove this section, TTL is a simple well-
known concept, we suggest to include a sentence (and hence remove
this section) in the control-plane section stating that mappings
include a TTL.
Mappings come with a Time-To-Live, which indicate how long the Mappings come with a Time-To-Live, which indicate how long the
creator of the mapping expects them to be useful for. The TTL may creator of the mapping expects them to be useful for.
also indicate that the mapping should not be cached at all, or it can
indicate that it has no particular lifetime, and the recipient can
chose how long to store it.
Mappings might also be discarded before the TTL expires, depending on Mappings might also be discarded before the TTL expires, depending on
what strategies the ITR is using to maintain its cache; if the what strategies the ITR is using to maintain its cache; if the
maximum cache size is fixed, or the ITR needs to reclaim memory, maximum cache size is fixed, or the ITR needs to reclaim memory,
mappings which have not been used 'recently' may be discarded. mappings which have not been used recently may be discarded. (After
(After all, there is no harm in so doing; a future reference will all, there is no harm in so doing; a future reference will merely
merely cause that mapping to be reloaded.) cause that mapping to be reloaded.)
{{Contents may change before TTL expires?}} {{Contents may change before TTL expires?}}
12.6. Mapping Gleaning in ETRs 12.6. Mapping Gleaning in ETRs
{{Suggestion by editors: Remove this section, gleaning is discouraged
since it rises many security concerns.}}
As an optimization to the mapping acquisition process, ETRs are As an optimization to the mapping acquisition process, ETRs are
allowed to 'glean' mappings from incoming user data packets, and also allowed to glean mappings from incoming user data packets, and also
from incoming Map-Request control messages. This is not secure, and from incoming Map-Request control messages. This is not secure, and
so any such mapping must be 'verified' by sending a Map-Request to so any such mapping must be verified by sending a Map-Request to get
get an authoritative mapping. (See further discussion of the an authoritative mapping.
security implications of this in [Perspective], Section "Security-
xTRs".)
The value of gleaning is that most communications are two-way, and so The value of gleaning is that most communications are two-way, and so
if host A is sending packets to host B (therefore needing B's if host A is sending packets to host B (therefore needing B's
EID->RLOC mapping), very likely B will soon be sending packets back EID->RLOC mapping), very likely B will soon be sending packets back
to A (and thus needing A's EID->RLOC mapping). Without gleaning, to A (and thus needing A's EID->RLOC mapping). Without gleaning,
this would sometimes result in a delay, and the dropping of the first this would sometimes result in a delay, and the dropping of the first
return packet; this is felt to be very undesirable. return packet; this is felt to be very undesirable.
12.7. MTU Issues 12.7. MTU Issues
Several mechanisms have been proposed for dealing with packets which Several mechanisms have been proposed for dealing with packets which
are too large to transit the path from a particular ITR to a given are too large to transit the path from a particular ITR to a given
ETR. ETR.
In one, called the 'stateful' approach, the ITR keeps a per-ETR In one, called the stateful approach, the ITR keeps a per-ETR record
record of the maximum size allowed, and sends an ICMP Too Big message of the maximum size allowed, and sends an ICMP Too Big message to the
to the original source host when a packet which is too large is seen. original source host when a packet which is too large is seen.
In the other, referred to as the 'stateless' approach, for IPv4 In the other, referred to as the stateless approach, for IPv4 packets
packets without the 'DF' bit set, too-large packets are fragmented, without the DF bit set, too-large packets are fragmented, and then
and then the fragments are forwarded; all other packets are the fragments are forwarded; all other packets are discarded, and an
discarded, and an ICMP Too Big message returned. ICMP Too Big message returned.
12.8. Security of Mapping Lookups 12.8. Security of Mapping Lookups
{{Suggestion from editors: would remove all what is related to
security and instead put a small summary in the security section and
reference the threats document}}
LISP provides an optional mechanism to secure the obtaining of LISP provides an optional mechanism to secure the obtaining of
mappings by an ITR. [LISP-SEC] It provides protection against mappings by an ITR. [I-D.ietf-lisp-sec] It provides protection
attackers generating spurious Map-Reply messages (including replaying against attackers generating spurious Map-Reply messages (including
old Map-Replies), and also against 'over-claiming' attacks (where a replaying old Map-Replies), and also against over-claiming attacks
malicious ETR by claims EID-prefixes which are larger than what have (where a malicious ETR by claims EID-prefixes which are larger than
been actually delegated to it). what have been actually delegated to it).
In summary, the ITR provides a One-Time Key with its Map-Request; In summary, the ITR provides a One-Time Key with its Map-Request;
this key is used by both the MS (to sign an affirmation that it has this key is used by both the MS (to sign an affirmation that it has
delegated that EID block to that ETR), and indirectly by the ETR (to delegated that EID block to that ETR), and indirectly by the ETR (to
sign the mapping that it is returning to the ITR). sign the mapping that it is returning to the ITR).
The specification for LISP-SEC suggests that the ITR-MR stage be The specification for LISP-SEC suggests that the ITR-MR stage be
cryptographically protected, and indicates that the existing cryptographically protected, and indicates that the existing
mechanisms for securing the ETR-MS stage are used to protect Map- mechanisms for securing the ETR-MS stage are used to protect Map-
Rquests also. It does assume that the channel from the MR to the MS Rquests also. It does assume that the channel from the MR to the MS
is secure (otherwise an attacker could obtain the OTK from the Map- is secure.
Request and use it to forge a reply).
12.9. xTR Mapping Cache Performance
As mentioned previously (Section 8.1.1 "Mapping Cache Performance"), 12.9. ITR Mapping Cache Performance
a substantial amount of simulation work has been performed to
predict, and understand, the performance of the "mapping cache" in
xTRs.
For a comprehensive survey of this work, see [Perspective], Section As mentioned previously (Section 8.1.1, a substantial amount of
"Mapping Cache Performance", and the references; full details are too simulation work has been performed to predict, and understand, the
lengthy to include here. performance of the mapping cache in xTRs.
Briefly, however, the first, [Iannone], was performed in the very Briefly, however, the first, [Iannone], was performed in the very
early stages of the LISP effort, to verify that that caching approach early stages of the LISP effort, to verify that that caching approach
was feasible. was feasible.
Packet traces of all traffic over the external connection of a large Packet traces of all traffic over the external connection of a large
university over a week-long period were collected; simulations driven university over a week-long period were collected; simulations driven
by these recording were then performed. A variety of control by these recording were then performed. A variety of control
settings on the cache were used, to study the effects of varying the settings on the cache were used, to study the effects of varying the
settings. settings.
First, the simulation gave the cache sizes that would result from First, the simulation gave the cache sizes that would result from
such a cache design: it showed that the resulting cache sizes ranged such a cache design: it showed that the resulting cache sizes ranged
from 7,500 entries, up to about 100,000 (depending on factors such as from 7,500 entries, up to about 100,000 (depending on factors such as
traffic and entry retention time). Using some estimations as to how traffic and entry retention time). Using some estimations as to how
much memory mapping entries would use, this indicated cache sizes of much memory mapping entries would use, this indicated cache sizes of
between roughly 100 Kbytes and a few Mbytes. between roughly 100 Kbytes and a few Mbytes.
Of more interest, in a way, were the results regarding two important Of more interest, in a way, were the results regarding two important
measurements of the effectiveness of the cache: i) the hit ratio measurements of the effectiveness of the cache: i) the hit ratio
(i.e. the share of references which could be satisified by the (i.e. the share of references which could be satisfied by the cache),
cache), and ii) the miss _rate_ (since control traffic overhead is and ii) the miss rate (since control traffic overhead is one of the
one of the chief concerns when using a cache). These results were chief concerns when using a cache). These results were also
also encouraging: miss (and hence lookup) rates ranged from 30 per encouraging: miss (and hence lookup) rates ranged from 30 per minute,
minute, up to 3,000 per minute. up to 3,000 per minute.
Significantly, this was substantially lower than the amount of Significantly, this was substantially lower than the amount of
observed DNS traffic, which ranged from 1,800 packets per minute up observed DNS traffic, which ranged from 1,800 packets per minute up
to 15,000 per minute. The results overall showed that using a to 15,000 per minute. The results overall showed that using a
demand-loaded cache was an entirely plausible design approach: both demand-loaded cache was an entirely plausible design approach: both
cache size, and the control plane traffic load, were definitely cache size, and the control plane traffic load, were definitely
feasible. feasible.
The second, [Kim], was in general terms similar, except that it used The second, [Kim], was in general terms similar, except that it used
data from a large ISP, one with about three times as many users as data from a large ISP, one with about three times as many users as
skipping to change at line 1424 skipping to change at page 31, line 28
models of the performance of such a cache (using previous theoretical models of the performance of such a cache (using previous theoretical
work on caches) produced results that conformed with actual empirical work on caches) produced results that conformed with actual empirical
measurements. measurements.
It used yet another set of packet traces; using a cache size of It used yet another set of packet traces; using a cache size of
around 50,000 entries produced a miss rate of around 1x10-4; again, around 50,000 entries produced a miss rate of around 1x10-4; again,
definitely viable, and in line with the results of the other studies. definitely viable, and in line with the results of the other studies.
13. The Mapping System 13. The Mapping System
As discussed already in Section 8.2, "Control Plane - Mapping System {{Suggestion by editors: This section is somewhat redundant with
Overview", the LISP "mapping system" is an important part of LISP's respect to section 8.2, we suggest to move this section to Part I
control plane: it i) maintains the database of "mappings" between since it provides some missing details.}}
EIDs, and the RLOCs at which they are to be found, and ii) provides
those mappings to ITRs which request them, so that the ITRs can send
traffic for a given EID to the correct RLOC(s) for that EID.
RFC 1034 ("DNS Concepts and Facilities") has this to say about the As discussed already in Section 8.2, the LISP mapping system is an
DNS name to IP address database and mapping system: important part of LISP's control plane: it i) maintains the database
of mappings between EIDs, and the RLOCs at which they are to be
found, and ii) provides those mappings to ITRs which request them, so
that the ITRs can send traffic for a given EID to the correct RLOC(s)
for that EID.
"The sheer size of the database and frequency of updates suggest [RFC1034] has this to say about the DNS name to IP address database
that it must be maintained in a distributed manner, with local and mapping system:
caching to improve performance. Approaches that attempt to
collect a consistent copy of the entire database will become more "The sheer size of the database and frequency of updates suggest
and more expensive and difficult, and hence should be avoided." that it must be maintained in a distributed manner, with local
caching to improve performance. Approaches that attempt to
collect a consistent copy of the entire database will become more
and more expensive and difficult, and hence should be avoided."
and this observation applies equally to the LISP mapping database and and this observation applies equally to the LISP mapping database and
mapping system. mapping system.
To briefly recap, the mapping system is split into three parts: i) an To briefly recap, the mapping system is split into three parts: i) an
"indexing sub-system", which keeps track of where all the mappings indexing sub-system, which keeps track of where all the mappings are
are kept; ii) the interface to the indexing system (which remains the kept; ii) the interface to the indexing system (which remains the
same, even if the actual indexing system is changed); and iii) the same, even if the actual indexing system is changed); and iii) the
mappings themselves (collectively, the "mapping database"), the mappings themselves (collectively, the mapping database), the
authoritative copies of which are always held by ETRs. authoritative copies of which are always held by ETRs.
13.1. The Mapping System Interface 13.1. The Mapping System Interface
As mentioned in Section 8.2.2, "Interface to the Mapping System", As mentioned in Section 8.2.2, both of the interfaces to the mapping
both of the inferfaces to the mapping system (from ITRs, and ETRs) system (from ITRs, and ETRs) are standardized, so that the more
are standardized, so that the more numerous xTRs do not have to be numerous xTRs do not have to be modified when the mapping indexing
modified when the mapping indexing sub-system is changed. sub-system is changed.
(This precaution has already allowed the mapping system to be
upgraded during LISP's evolution, when ALT was replaced by DDT.)
This section describes the interfaces in a little more detail; for This section describes the interfaces in a little more detail; for
details, see [RFC6833]. details, see [RFC6833].
13.1.1. Map-Request Messages 13.1.1. Map-Request Messages
{{Suggestion from editors: should come much earlier as it is an
essential message in LISP}}
The Map-Request message contains a number of fields, the two most The Map-Request message contains a number of fields, the two most
important of which are the requested EID block identifier (remember important of which are the requested EID block identifier (remember
that individual mappings may cover a block of EIDs, not just a single that individual mappings may cover a block of EIDs, not just a single
EID), and the Address Family Identifier (AFI) for that EID block. EID), and the Address Family Identifier (AFI) for that EID block.
Other important fields are the source EID (and its AFI), and one or Other important fields are the source EID (and its AFI), and one or
more RLOCs for the source EID, along with their AFIs. {{Not quite more RLOCs for the source EID, along with their AFIs. The source EID
right, Dino will clarify. - Also two sets of RLOCs.}} Multiple RLOCs and RLOCs allow ETRs to customize their answer.
are included to ensure that at least one is in a form which will
allow the reply to be returned to the requesting ITR, and the source
EID is used for a variety of functions, including 'gleaning' (see
Section 12.6, " Mapping Gleaning in ETRs").
Finally, the message includes a long nonce, for simple, efficient Finally, the message includes a long nonce, for simple, efficient
protection against offpath attackers (see [Perspective], Section protection against offpath attackers and a variety of other fields
"Security-xTRs" for more), and a variety of other fields and control and control flag bits.
flag bits.
13.1.2. Map-Reply Messages 13.1.2. Map-Reply Messages
{{Suggestion from editors: should come much earlier as it is an
essential message in LISP}}
The Map-Reply message looks similar, except it includes the mapping The Map-Reply message looks similar, except it includes the mapping
entry for the requested EID(s), which contains one or more RLOCs and entry for the requested EID(s), which contains one or more RLOCs and
their associated data. (Note that the reply may cover a larger block their associated data. Note that the reply may cover a larger block
of the EID namespace than the request; most requests will be for a of the EID namespace than the request; most requests will be for a
single EID, the one which prompted the query.) single EID, the one which prompted the query.
If there are no mappings available at all for the EID(s) requested, a If there are no mappings available at all for the EID(s) requested, a
'Negative Map-Reply' message will be returned. This is a Map-Reply Negative Map-Reply message will be returned. This is a Map-Reply
message with flag bits set to indicate that fact. message with flag bits set to indicate that fact.
For each RLOC in the entry, there is the RLOC, its AFI, priority and For each RLOC in the entry, there is the RLOC, its AFI, priority and
weight fields (see Section 8.2, "Control Plane - Mapping System weight fields (see Section 8.2), and multicast priority and weight
Overview"), and multicast priority and weight fields (see Section 14, fields (see Section 14).
"Multicast Support in LISP" for more about multicast support in
LISP).
13.1.2.1. Solicit-Map-Request Messages 13.1.2.1. Solicit-Map-Request Messages
"Solicit-Map-Request" (SMR) messages are actually not another message Solicit-Map-Request (SMR) messages are actually not another message
type, but a variant of Map-Request messages. {{Look at how probe is type, but a variant of Map-Request messages. They include a special
handled, do similar here - take out 'not xxx', say what they are.}} flag which indicates to the recipient that it should send a new Map-
They include a special flag which indicates to the recipient that it Request message, to refresh its mapping, because the ETR has detected
_should_ send a new Map-Request message, to refresh its mapping, that the one it is using is out-dated.
because the ETR has detected that the one it is using is out-dated.
SMR's, like most other control traffic, is rate-limited. SMR's, like most other control traffic, should be rate-limited.
13.1.3. Map-Register and Map-Notify Messages 13.1.3. Map-Register and Map-Notify Messages
The Map-Register message contains authentication information, and a {{Suggestion by editors: As noted by the author add a paragraph
number of mapping records, each with an individual Time-To-Live describing how a xTR de-registers an EID-to-RLOC mapping.}}
(TTL). Each of the records contains an EID (potentially, a block of
EIDs) and its AFI, a version number for this mapping (see {{Suggestion by editors: add a small paragraph to explain what Map-
Section 12.3.1, "Mapping Versioning"), and a number of RLOCs and Registers are used for}}
The Map-Register message contains one or several mapping records,
each with an individual Time-To-Live (TTL). Each of the records
contains an EID (potentially, a block of EIDs) and its AFI, a version
number for this mapping (see Section 12.3.1 and a list of RLOCs and
their AFIs. their AFIs.
{{Suggestion by editors: do not understand the following paragraph}}
Each RLOC entry also includes the same data as in the Map-Replies Each RLOC entry also includes the same data as in the Map-Replies
(i.e. priority and weight); this is because in some circumstances it (i.e. priority and weight); this is because in some circumstances it
is advantageous to allow the MS to proxy reply on the ETR's behalf to is advantageous to allow the MS to proxy reply on the ETR's behalf to
Map-Request messages, and the MS needs this information when it does Map-Request messages, and the MS needs this information when it does
so (see [Mobility]). so.
Map-Notify messages have the exact same contents as Map-Register Map-Notify messages have the exact same contents as Map-Register
messages; they are purely acknowledgements (although planned LISP messages; they are purely acknowledgements.
functionality extensions may give them other functions as well).
The entire interaction can be authenticated by use of a shared key, The entire interaction is authenticated by use of a shared key,
configured in the MS and ETR. Although the protocol does already configured in the MS and ETR. Although the protocol does already
allow for replacement of the encryption algorithm, it does not allow for replacement of the encryption algorithm, it does not
support automated key management (although it appears to fall under support automated key management (although it appears to fall under
the exclusions in [RFC4107]). the exclusions in [RFC4107]).
{{Deregistering??}} LISP does not specify messages for de-registering an association with
a MS. The de-registration is hence ensured by the expiration of a
timer: if a MS does not receive Map-Register messages within given
timeout, it de-register the association.
13.2. The DDT Indexing Sub-system 13.2. The DDT Indexing Sub-system
As previously mentioned in Section 8.2.3, "Indexing Sub-system", the {{Suggestion from the editors: this section does not add any
"indexing sub-system" in LISP is currently the DDT system. fundamental value to the DDT overview section, propose to remove it
to only keep the overview; too much details that should not appear in
an intro document}}
As previously mentioned in Section 8.2.3, DDT is the current indexing
sub-system in LISP.
The overall functioning is conceptually fairly simple; an MR which The overall functioning is conceptually fairly simple; an MR which
needs a "mapping" starts at a server for the root "DDT vertex" (there needs a mapping starts at a server for the root DDT node (there will
will normally be more than one such server available, for both normally be more than one such server available, for both performance
performance and robustness reasons), and through a combination of and robustness reasons), and through a combination of cached
cached delegation information, and repetitive querying of a sequence delegation information, and repetitive querying of a sequence of DDT
of DDT servers, works its way down the delegation tree until it servers, works its way down the delegation tree until it arrives at
arrives at an MS which is authoritative (responsible?) for the block an MS which is authoritative for the block of EID which holds the
of EID namespace which holds the destination EID in question. destination EID in question.
The interaction between MRs and DDT servers is as follow. The MR The interaction between MRs and DDT servers is as follow. The MR
sends to the DDT server a Map-Request control message. The DDT sends to the DDT server a Map-Request control message. The DDT
server uses its data (which is configured, and static) to see whether server uses its data (which is configured, and static) to see whether
it is directly peered to an MS which can answer the request, or if it it is directly peered to an MS which can answer the request, or if it
has a child (or children, if replicated) which is responsible for has a child (or children, if replicated) which is responsible for
that portion of the EID namespace. that portion of the EID blocks.
If it has children configured which are responsible, it will reply to If it has children configured which are responsible, it will reply to
the MR with another kind of LISP control message, a Map-Referral the MR with another kind of LISP control message, a Map-Referral
message, which provides information about the delegation of the block message, which provides information about the delegation of the block
containing the requested EID. This step is secured; see containing the requested EID. This step is secured via
Section 13.4, "Security of the DDT Indexing Sub-system", for more. authentication.
The Map-Referral also gives the addresses of DDT servers for that The Map-Referral also gives the addresses of DDT servers for that
block. and the MR can then send Map-Requests to any one (or all) of block and the MR can then send Map-Requests to any one (or all) of
them. In addition, the Map-Referral includes keying material for the them. In addition, the Map-Referral includes keying material for the
children, which allows any information provided by them to be children, which allows any information provided by them to be
cryptographically verified. cryptographically verified.
Control flags in the Map-Referral indicate to the querying MR whether Control flags in the Map-Referral indicate to the querying MR whether
the referral is to another DDT server, an MS, or an ETR. {{All three? the referral is to another DDT server, an MS, or an ETR. {{All three?
Check}} If the former, the MR then sends the Map-Request to the child Check}} If the former, the MR then sends the Map-Request to the child
DDT server, repeating the process. DDT server, repeating the process.
If the second, the MR then interacts with that MS, and usually the If the second, the MR then interacts with that MS, and usually the
block's ETR(s) as well, to cause a mapping to be sent to the ITR block's ETR(s) as well, to cause a mapping to be sent to the ITR
which queried the MR for it. (Recall that some MS's provide Map- which queried the MR for it. Recall that some MS's provide Map-
Replies on behalf of an associated ETR, in so-called 'proxy mode', so Replies on behalf of an associated ETR, in so-called 'proxy mode', so
in such cases the Map-Reply will come from the MS, not the ETR. ) in such cases the Map-Reply will come from the MS, not the ETR.
Delegations are cached in the MRs, so that once an MR has received Delegations are cached in the MRs, so that once an MR has received
information about a delegation, it usually will not need to look that information about a delegation, it usually will not need to look that
up again. Once it has been in operation for a short while, there up again. Once it has been in operation for a short while, there
will usually only be a limited amount of delegation information which will usually only be a limited amount of delegation information which
is has not yet asked about - probably only the last stage in a is has not yet asked about - probably only the last stage in a
delegation to a 'leaf' MS. delegation to a leaf MS.
As describe below (Section 13.6, "Performance of the Mapping
System"), an extensive modeling and performance evaluation has
verified that DDT provides acceptable performance, as well as
scalability. [LISP-TREE]
13.2.1. Map-Referral Messages
Map-Referral messages look almost identical to Map-Reply messages,
except that the RLOCs potentially name either i) the DDT servers for
other DDT vertices (children in the delegation tree), or ii) terminal
MSs.
13.3. Reliability via Replication 13.3. Reliability via Replication
{{Suggestion by editors: Remove this section, describes operational
practices/policies of the DDT infrastructure, this is beyond the
scope of this document.}}
Everywhere throughout the mapping system, robustness to operational Everywhere throughout the mapping system, robustness to operational
failures is obtained by replicating data in multiple instances of any failures is obtained by replicating data in multiple instances of any
particular node (of whatever type). Map-Resolvers, Map-Servers, DDT particular node (of whatever type). Map-Resolvers, Map-Servers, DDT
nodes, ETRs - all of them can be replicated, and the protocol nodes, ETRs - all of them can be replicated, and the protocol
supports this replication. supports this replication.
{{About replication - we don't talk about how that rep occurs}}
{{Reliablity through rep is much sturdier - provide good ref}}
There are generally no mechanisms specified yet to ensure coherence There are generally no mechanisms specified yet to ensure coherence
between multiple copies of any particular data item (e.g. the copies between multiple copies of any particular data item (e.g. the copies
of delegation data for a particular block of namespace, in DDT of delegation data for a particular block of namespace, in DDT
sibling servers) - this is currently a manual responsibility. sibling servers) - this is currently a manual responsibility.
If and when LISP protocol adoption proceeds, an automated layer to If and when LISP protocol adoption proceeds, an automated layer to
perform this functionality can 'easily' be layered on top of the perform this functionality can easily be layered on top of the
existing mechanisms. existing mechanisms.
The deployed DDT system actually uses anycast [RFC4786], along with The deployed DDT system actually uses anycast [RFC4786], along with
replicated servers, to improve both performance and robustness. {{Not replicated servers, to improve both performance and robustness.
just DDT, other places as well.}}
13.4. Security of the DDT Indexing Sub-system 13.4. Security of the DDT Indexing Sub-system
{{Suggestion by editors: Remove this section, provides unnecessary
details of DDT.}}
In summary, securing the mapping indexing system is divided into two In summary, securing the mapping indexing system is divided into two
parts: the interface between the clients of the system (MR's) and the parts: the interface between the clients of the system (MR's) and the
mapping indexing system itself, and the interaction between the DDT mapping indexing system itself, and the interaction between the DDT
servers which make it up. servers which make it up.
The client interface provides only a single model, using the The client interface provides only a single model, using the
'canonical' public-private key system (starting from a trust anchor), canonical public-private key system (starting from a trust anchor),
in which the child's public key is provided by the parent, along with in which the child's public key is provided by the parent, along with
the delegation. When the child returns any data, it can sign the the delegation. When the child returns any data, it can sign the
data, and the requestor can use that signature to verify the data. data, and the requestor can use that signature to verify the data.
This requires very little configuration in the clients. This requires very little configuration in the clients.
The interface between the DDT servers allows for choices between a The interface between the DDT servers allows for choices between a
number of different options, allowing the operators to trade off number of different options, allowing the operators to trade off
among configuration complexity, security level, etc. This is based among configuration complexity, security level, etc. This is based
on experience with DNSSEC ([RFC4033]), where configuration complexity on experience with DNSSEC ([RFC4033]), where configuration complexity
has been a major stumbling block to deployment. has been a major stumbling block to deployment.
See [Perspective], Section "Security-Mappings" for more.
13.5. Extended Capabilities 13.5. Extended Capabilities
{{Suggestion by editors: Remove this section, not discussed in any WG
document.}}
In addition to the priority and weight data items in mappings, LISP In addition to the priority and weight data items in mappings, LISP
offers other tools to enhance functionality, particularly in the offers other tools to enhance functionality, particularly in the
traffic engineering area. traffic engineering area.
One is 'requestor-specific mappings', i.e. the ETR may return One is requestor-specific mappings, i.e. the ETR may return different
different mappings to the enquiring ITR, depending on the identity of mappings to the enquiring ITR, depending on the identity of the ITR.
the ITR. This allows very fine-tuned traffic engineering, far more This allows very fine-tuned traffic engineering, far more powerful
powerful than routing-based TE. {{Policy-based?}} than routing-based TE.
13.6. Performance of the Mapping System 13.6. Performance of the Mapping System
Prior to the creation of DDT, a large study of the performance of the Prior to the creation of DDT, a large study of the performance of the
previous mapping system, ALT ([ALT]), along with a proposed new previous mapping system, ALT ([RFC6836]), along with a proposed new
design called TREE (which used DNS to hold delegation information) design called TREE (which used DNS to hold delegation information)
provided considerable insight into the likely performance of the provided considerable insight into the likely performance of the
mapping systems at larger scale. (See [LISP-TREE], in particular mapping systems at larger scale (See [LISP-TREE]).
Section V, "Mapping System Comparison".)
The basic structure and concepts of DDT are identical to those of The basic structure and concepts of DDT are identical to those of
TREE, so the performance simulation work done for that design applies TREE, so the performance simulation work done for that design applies
equally to DDT. equally to DDT.
In that study, as with earlier LISP performance analyses, extensive {{Suggestion from editors: next sentence is redundant with previous
large-scale simulations were driven by lengthy recordings of actual parts of the doucment}} In that study, as with earlier LISP
traffic at several major sites; one was the site in the first study performance analyses, extensive large-scale simulations were driven
([Iannone]), and the other was an even large university, with roughly by lengthy recordings of actual traffic at several major sites; one
35,000 users. was the site in the first study ([Iannone]), and the other was an
even large university, with roughly 35,000 users.
The results showed that a system like DDT, which caches information The results showed that a system like DDT, which caches information
about delegations, and allows the MR to communicate directly with the about delegations, and allows the MR to communicate directly with the
servers for the lower vertices on the delegation hierarchy based on servers for the lower vertices on the delegation hierarchy based on
cached delegation information, would have good performance, with cached delegation information, would have good performance, with
average resolution times on the order of the MR to MS RTT. This average resolution times on the order of the MR to MS RTT. This
verified the effectiveness of this particular type of indexing verified the effectiveness of this particular type of indexing
system. system.
A more recent study, [Saucez], has measured actual resolution times A more recent study, [Saucez], has measured actual resolution times
in the deployed LISP network; it took measurements from a variety of in the deployed LISP network; it took measurements from a variety of
locations in the Internet, with respect to a number of different locations in the Internet, with respect to a number of different
target EIDs. Average measured resolution delays ranged from roughly target EIDs. Average measured resolution delays ranged from roughly
175 msec to 225 msec, depending on the location. 175 msec to 225 msec, depending on the location.
14. Multicast Support in LISP 14. Multicast Support in LISP
Multicast ([RFC3170], [RFC5110]) , since LISP is all about separating {{Suggestion by editors: Rewrite this section, it provides too many
identity from location, and although a multicast group in some sense details. Reduce it to a brief description of LISP Multicast}}
has an identity, it certainly does not have _a_ location.
LISP and its intrinsic separation of identity from location is well
suited for Multicast ([RFC3170], [RFC5110]), and the definition of
mappings in the current specifications already allows multicast
capability ([RFC6830]).
{{Say something about sources.}} {{Say something about sources.}}
Multicast is am important requirement, for a number of reasons: doing {{Suggestion by editors: remove the paragraph below, motivation for
multicast is out of the scope of this document}}
Multicast is an important requirement, for a number of reasons: doing
multiple unicast streams is inefficient, as it is easy to use up all multiple unicast streams is inefficient, as it is easy to use up all
the upstream bandwidth; without multicast a server can also be the upstream bandwidth; without multicast a server can also be
saturated fairly easily in doing the unicast replication; etc. saturated fairly easily in doing the unicast replication; etc.
Since it is important for LISP to work well with multicast; doing so Since it is important for LISP to work well with multicast; doing so
has been a significant focus in LISP throughout its entire has been a significant focus in LISP throughout its entire
development. development.
Further very significant improvements to multicast support in LISP Further very significant improvements to multicast support in LISP
are in progress; see [Improvements], Section "Multicast" for more on are in progress; see [Improvements], Section "Multicast" for more on
them. them.
14.1. Basic Concepts of Multicast Support in LISP 14.1. Basic Concepts of Multicast Support in LISP
This section introduces some of the basic principles of multicast This section introduces some of the basic principles of multicast
support in LISP. support in LISP.
Since group addresses name distributed collective entities, in Since group addresses name distributed collective entities, in
general they cannot have a single RLOC (although they may, after general they cannot have a single RLOC also. Since they usually
future improvements in multicast support in LISP, have multiple refer to collections of entities the notion of endpoint identity must
RLOCs); also, since they usually refer to collections of entities, be
they aren't really EIDs either.
A multicast source at a LISP site may not be able to become the root A multicast source at a LISP site may not be able to become the root
of a distribution tree in the core if it uses its EID as its identity of a distribution tree in the core if it uses its EID as its identity
for that distribution tree (i.e. a distribution tree (S-EID, G)); for that distribution tree (i.e. a distribution tree (S-EID, G));
that is because there may not be a route to its EID in the core that is because there may not be a route to its EID in the core
(assuming that its section of the core even supports multicast; not (assuming that its section of the core even supports multicast; not
all parts of the core do). all parts of the core do).
Therefore, outside the LISP site, multicast state for the Therefore, outside the LISP site, multicast state for the
distribution tree (S-RLOC, G) needs to be built instead, where S-RLOC distribution tree (S-RLOC, G) needs to be built instead, where S-RLOC
is the RLOC of the ITR that the multicast source inside the LISP site is the RLOC of the ITR that the multicast source inside the LISP site
will be sending its traffic through. will be sending its traffic through.
Multicast LISP requires no packet format changes to existing Multicast LISP requires no packet format changes to existing
multicast packets (both control, and user data). The initial multicast packets (both control, and user data). The initial
multicast support in LISP uses existing multicast control mechanisms multicast support in LISP uses existing multicast control mechanisms
exclusively; improvements currently being worked on provide LISP- exclusively; improvements currently being worked on provide LISP-
specific control mechanisms (see [Improvements], Section "Multicast", specific control mechanisms (see [Improvements]).
for more).
14.2. Initial Multicast Support in LISP 14.2. Initial Multicast Support in LISP
{{Suggestion by editors: remove this paragraph}}
Readers who wish to fully understand multicast support need to Readers who wish to fully understand multicast support need to
consult the appropriate specifications: LISP multicast issues are consult the appropriate specifications: LISP multicast issues are
discussed in [RFC6830], Section 11; and see [RFC6831] for the full discussed in [RFC6830], Section 11; and see [RFC6831] for the full
details of current multicast support in LISP. details of current multicast support in LISP.
In the current simple operating mode (covered in [RFC6831]), With the multicast operation defined in [RFC6831]), destination group
destination group addresses are not mapped; only the source address addresses are not mapped; only the source address (when the original
(when the original source is inside a LISP site) needs to be mapped, source is inside a LISP site) needs to be mapped, both during
both during distribution tree setup, as well as actual traffic distribution tree setup, as well as actual traffic delivery.
delivery.
In other words, while LISP's mapping capability is used, at this In other words, while LISP's mapping capability is used, at this
stage it is only applied to the source, not the destination (as with stage it is only applied to the source, not the destination (as with
most LISP activity). Thus, in LISP-encapsulated multicast packets in most LISP activity). Thus, in LISP-encapsulated multicast packets in
this mode, the inner source is the EID, and the outer source is the this mode, the inner source is the EID, and the outer source is the
ITR's RLOC; both inner and outer destinations are the group's ITR's RLOC; both inner and outer destinations are the group's
multicast address. multicast address.
Note that this does mean that if the group is using separate source- Note that this does mean that if the group is using separate source-
specific trees for distribution, there isn't a separate distribution specific trees for distribution, there isn't a separate distribution
tree outside the LISP site for each different source of traffic to tree outside the LISP site for each different source of traffic to
the group from inside the LISP site; they are all lumped together the group from inside the LISP site; they are all grouped together
under a single source, the RLOC. under a single source, the RLOC.
The issue of encapsulation is complex, because if the rest of the The issue of encapsulation is complex, because if the rest of the
group outside the LISP site includes some members which are at other group outside the LISP site includes some members which are at other
LISP sites (i.e. packets to them have to be encapsulated), and some LISP sites (i.e. packets to them have to be encapsulated), and some
members at legacy sites (i.e. encapsulated packets would not be members at legacy sites (i.e. encapsulated packets would not be
understood), there is no simple answer. (The situation becomes even understood), there is no simple answer. (The situation becomes even
more complex when one considers that as hosts leave and joint the more complex when one considers that as hosts leave and join the
group, it may switch back and forth between 'mixed' and group, it may switch back and forth between mixed and homogenous.)
'homogenous'.)
This issue is too complex to fully cover here; see Section 9.2., This issue is too complex to fully cover here; see Section 9.2.,
"LISP Sites with Mixed Address Families", in [RFC6831], for complete "LISP Sites with Mixed Address Families", in [RFC6831], for complete
coverage of this issue. coverage of this issue.
Basically, there are multicast equivalents of some of the legacy Basically, there are multicast equivalents of some of the legacy
interoperability mechanisms used for unicast; mPITRs and mPETRs interoperability mechanisms used for unicast; mPITRs and mPETRs
(multicast-capable PITRs and PETRs) etc. When 'mixed' groups are a (multicast-capable PITRs and PETRs). When mixed groups are a
possibility, two choices are available: i) send two copies (one possibility, two choices are available: i) send two copies (one
encapsulated, and one not) of all traffic, or ii) employ mPETRs to encapsulated, and one not) of all traffic, or ii) employ mPETRs to
distribute non-encapsulated copies to 'legacy' group members. distribute non-encapsulated copies to legacy group members.
15. Deployment Issues and Mechanisms 15. Deployment Issues and Mechanisms
{{Suggestion by editors: Remove this section, provides unnecessary
details. Add a reference to the deployment RFC.}}
This section discusses several deployment issues in more detail. This section discusses several deployment issues in more detail.
With LISP's heavy emphasis on practicality, much work has gone into With LISP's heavy emphasis on practicality, much work has gone into
making sure it works well in the real-world environments most people making sure it works well in the real-world environments most people
have to deal with. have to deal with.
15.1. LISP Deployment Needs 15.1. LISP Deployment Needs
As mentioned earlier (Section 5.2, "Maximize Re-use of Existing As mentioned earlier (Section 5.2), LISP requires no change to almost
Mechanism"), LISP requires no change to almost all existing hosts and all existing hosts and routers. Obviously, however, one must deploy
routers. Obviously, however, one must deploy _something_ to run something to run LISP. Exactly what that has to be will depend
LISP! Exactly what that has to be will depend greatly on the details greatly on the details of the site's existing networking gear, and
of the site's existing networking gear, and choices it makes for how choices it makes for how to achieve LISP deployment.
to achieve LISP deployment.
The primary requirement is for one or more xTRs. These may be The primary requirement is for one or more xTRs. These may be
existing routers, just with new software loads, or it may require the existing routers, just with new software loads, or it may require the
deployment of new devices. deployment of new devices.
{{Suggestion by editors: next paragraph is barely understandable}}
LISP also requires a certain amount of LISP-specific support LISP also requires a certain amount of LISP-specific support
infrastructure, such as MRs, MSs, the DDT hierarchy, etc. However, infrastructure, such as MRs, MSs, the DDT hierarchy, etc. However,
much of this will either i) {{for the case where you are adding a new much of this will either i) {{for the case where you are adding a new
site using existing LISP infrastructure}} already be deployed, and if site using existing LISP infrastructure}} already be deployed, and if
the new site can make arrangements to use it, it need do nothing the new site can make arrangements to use it, it need do nothing
else; or ii) those functions the site must provide may be co-located else; or ii) those functions the site must provide may be co-located
in other LISP devices (again, either new devices, or new software on in other LISP devices (again, either new devices, or new software on
existing ones). existing ones).
15.2. Interworking Mechanisms 15.2. Interworking Mechanisms
One aspect which has received a lot of attention are the mechanisms One aspect which has received a lot of attention are the mechanisms
previously referred to (in Section 6.4, "Interworking With Non-LISP- previously referred to (in Section 6.4) to allow interoperation of
Capable Endpoints") to allow interoperation of LISP sites with so- LISP sites with so-called legacy sites which are not running LISP
called 'legacy' sites which are not running LISP (yet). (yet).
{{Suggestion by editors: remove next paragraph as it talks about
features (NAT based transition) not covered by the WG}}
There are two main approaches to such interworking: proxy routers There are two main approaches to such interworking: proxy routers
(PITRs and PETRs), and an alternative mechanism using a router with (PITRs and PETRs), and an alternative mechanism using a router with
combined NAT and LISP functionality; these are described in more combined NAT and LISP functionality; these are described in more
detail here. detail here.
15.2.1. Proxy LISP Routers 15.2.1. Proxy LISP Routers
PITRs (proxy ITRs) serve as ITRs for traffic _from_ legacy hosts to {{Suggestion by editors: Move this section to Part I. PxTRs are an
important aspect of LISP and as such, should be described before.
Furthermore simplify it, it currently contains too many details plus
an additional discussion on the impact of PITR that is out of the
scope of the document.}}
PITRs (proxy ITRs) serve as ITRs for traffic from legacy hosts to
nodes in LISP sites. PETRs (proxy ETRs) serve as ETRs for LISP nodes in LISP sites. PETRs (proxy ETRs) serve as ETRs for LISP
traffic _to_ legacy hosts (for cases where a LISP node cannot send traffic to legacy host.
packets directly to such hosts, without encapsulation).
Note that return traffic _to_ a legacy host from a LISP-using node Note that return traffic to a legacy host from a LISP-using node does
does not necessarily have to pass through an ITR/PETR pair - the not necessarily have to pass through an ITR/PETR pair - the original
original packets can usually just be sent directly to the ultimate packets can usually just be sent directly to the ultimate
destination. However, for some kinds of LISP operation (e.g. mobile destination. However, for some kinds of LISP operation (e.g. mobile
nodes), this is not possible; in these situations, the PETR is nodes), this is not possible; in these situations, the PETR is
needed. needed.
15.2.1.1. PITRs 15.2.1.1. PITRs
To serve as ITRs for traffic _from_ legacy hosts to nodes in LISP To serve as ITRs for traffic from legacy hosts to nodes in LISP
sites, PITRs they have to advertise into the existing legacy backbone sites, PITRs they have to advertise into the existing legacy backbone
Internet routing the availability of whatever ranges of EIDs (i.e. of Internet routing the availability of whatever ranges of EIDs (i.e. of
nodes using LISP) they are proxying for, so that legacy hosts will nodes using LISP) they are proxying for, so that legacy hosts will
know where to send traffic to those LISP nodes. know where to send traffic to those LISP nodes. PITR implies that
EID prefixes are advertised in BGP.
This technique obviously has an impact on routing table in the This technique may have an impact on routing table in the Internet
"Internet core", but it is not clear yet exactly what that impact core, but it is not clear yet exactly what that impact will be; it is
will be; it is very dependent on the collected details of many very dependent on the collected details of many individual deployment
individual deployment decisions. {{Check on text elsewhere for decisions.
effects on routing table size, specifically advertizement of large
blocks.}}
A PITR may cover a group of EID blocks with a single EID A PITR may cover a group of EID blocks with a single EID
advertisement to the core, in order to reduce the number of routing advertisement to the core, in order to reduce the number of routing
table entries added. (In fact, at the moment, aggressive aggregation table entries added. In fact, at the moment, aggressive aggregation
of EID announcements is performed, precisely to to minimize the of EID announcements is performed, precisely to to minimize the
number of new announced routes added by this technique.) {{BGP tools number of new announced routes added by this technique.
can be used to restrict the direction and scope of these
advertisements.}}
At the same time, if a site does traffic engineering with LISP At the same time, if a site does traffic engineering with LISP
instead of fine-grained BGP announcement, that will help keep table instead of fine-grained BGP announcement, that will help keep table
sizes down (and this is true even in the early stages of LISP sizes down (and this is true even in the early stages of LISP
deployment). The same is true for multi-homing. {{Maybe mixing two deployment). The same is true for multi-homing. {{Maybe mixing two
concepts? LISP TE tools will still apply to traffic between PITR and concepts? LISP TE tools will still apply to traffic between PITR and
LISP site.}} LISP site.}}
{{Maybe reword, as we changed the target section.}} As mentioned As mentioned previously (Section 12.1), an ITR at another LISP site
previously (Section 12.1, "When to Encapsulate"), an ITR at another can avoid using a PITR (i.e. it can detect that a given ultimate
LISP site can avoid using a PITR (i.e. it can detect that a given destination is not a legacy host, if a PITR is advertising it into
ultimate destination is not a legacy host, if a PITR is advertising the Internet core) by checking to see if a LISP mapping exists for
it into the "Internet core") by checking to see if a LISP mapping that ultimate destination.
exists for that ultimate destination.
15.2.1.2. PETRs 15.2.1.2. PETRs
PETRs (proxy ETRs) serve as ETRs for LISP traffic _to_ legacy hosts, PETRs (proxy ETRs) serve as ETRs for LISP traffic to legacy hosts,
for cases where a LISP node cannot send packets to such hosts without for cases where a LISP node cannot send packets to such hosts without
encapsulation. That typically happens for one of two reasons. encapsulation. That typically happens for one of two reasons.
First, it will happen in places where some device is implementing First, it will happen in places where some device is implementing
Unicast Reverse Path Forwarding (uRPF), to prevent a variety of Unicast Reverse Path Forwarding (uRPF), to prevent a variety of
negative behaviour; originating packets with the original source's negative behaviour; originating packets with the original source's
EID in the source address field will result in them being filtered EID in the source address field will result in them being filtered
out and discarded. out and discarded.
{{Suggestion by editors: would adding and example be useful?}}
Second, it will happen when a LISP site wishes to send packets to a Second, it will happen when a LISP site wishes to send packets to a
non-LISP site, and the path in between does not support the non-LISP site, and the path in between does not support the
particular IP protocol version used by the original source along its particular IP protocol version used by the original source along its
entire length. Use of a PETR on the other side of the 'gap' will entire length. Use of a PETR on the other side of the gap will allow
allow the LISP site's packet to 'hop over' the gap, by utilizing the LISP site's packet to 'hop over' the gap, by utilizing LISP's
LISP's built-in support for mixed protocol encapsulation. built-in support for mixed protocol encapsulation.
PETRs are generally used by specific ITRs, which have the location of PETRs are generally used by specific ITRs, which have the location of
their PETRs configured into them. In other words, unlike normal their PETRs configured into them. In other words, unlike normal
ETRS, PETRs do not have to register themselves in the mapping ETRs, PETRs do not have to register themselves in the mapping
database, on behalf of any legacy sites they serve. database, on behalf of any legacy sites they serve.
Also, allowing an ITR to always send traffic leaving a site to a PETR Also, allowing an ITR to always send traffic leaving a site to a PETR
does avoid having to chose whether or not to encapsulate packets; it does avoid having to chose whether or not to encapsulate packets; it
can just always encapsulate packets, sending them to the PETR if it can just always encapsulate packets, sending them to the PETR if it
has no specific mapping for the ultimate destination. However, this has no specific mapping for the ultimate destination.
is not advised: as mentioned, it is easy to tell if something is a
legacy destination.
15.2.2. LISP-NAT 15.2.2. LISP-NAT
{{Suggestion by editors: Remove this section, LISP-NAT is not a WG
document neither an inter-networking mechanisms.}}
A LISP-NAT router, as previously mentioned, combines LISP and NAT A LISP-NAT router, as previously mentioned, combines LISP and NAT
functionality, in order to allow a LISP site which is internally functionality, in order to allow a LISP site which is internally
using addresses which cannot be globally routed to communicate with using addresses which cannot be globally routed to communicate with
non-LISP sites elsewhere in the Internet. (In other words, the non-LISP sites elsewhere in the Internet. (In other words, the
technique used by the PITR approach simply cannot be used in this technique used by the PITR approach simply cannot be used in this
case.) case.)
To do this, a LISP-NAT performs the usual NAT functionality, and To do this, a LISP-NAT performs the usual NAT functionality, and
translates a host's source address(es) in packets passing through it translates a host's source address(es) in packets passing through it
from an 'inner' value to an 'outer' value, and storing that from an inner value to an outer value, and storing that translation
translation in a table, which it can use to similarly process in a table, which it can use to similarly process subsequent packets
subsequent packets (both outgoing and incoming). [RFC6832] (both outgoing and incoming). [RFC6832]
{{Suggestion by editors: remove the following paragraph, does not
bring anything}}
There are two main cases where this might apply: There are two main cases where this might apply:
- Sites using non-routable global addresses
- Sites using private addresses [RFC1918] o Sites using non-routable global addresses
o Sites using private addresses [RFC1918]
15.3. Use Through NAT Devices 15.3. Use Through NAT Devices
{{Suggestion by editors: Remove this section, LISP-NAT is not a WG
document neither an inter-networking mechanisms.}}
NATs are both ubiquitous, and here to stay for a long time to come. NATs are both ubiquitous, and here to stay for a long time to come.
[RFC1631] Thus, in the actual Internet of today, having any new [RFC1631] Thus, in the actual Internet of today, having any new
mechanisms function well in the presence of NATs (i.e. with LISP xTRs mechanisms function well in the presence of NATs (i.e. with LISP xTRs
behind a NAT device) is absolutely necessary. behind a NAT device) is absolutely necessary.
LISP has produced a variety of mechanisms to do this. An LISP has produced a variety of mechanisms to do this. An
experimental mechanism to support them had major limitations; it, and experimental mechanism to support them had major limitations; it, and
its limitations, are described in Appendix B.5, "Early NAT Support". its limitations, are described in Appendix B.5.
A more recent proposed mechanism, which avoids those limitations, is
described in [Improvements], Section "Improved NAT Support".
15.4. LISP and Core Internet Routing 15.4. LISP and Core Internet Routing
One of LISP's original motivations was to try and control the growth {{Suggestion by editors: Remove this section, this is already
of the size of routing tables in the Internet core, the part where explained in lisp-deployment}}
routes to _all_ destinations must be available. As LISP becomes more
widely deployed, it can help with this issue, in a variety of ways.
{{Give ref for why large rout tables bad.}}
{{Does applications make forward ref to this section?}} One of LISP's original motivations was to control the growth of the
size of routing tables in the Internet core, the part where routes to
all destinations must be available. As LISP becomes more widely
deployed, it can help with this issue, in a variety of ways.
In covering this topic, one must recognize that conditions in various In covering this topic, one must recognize that conditions in various
stages of LISP deployment (in terms of ubiquity) will have a large stages of LISP deployment (in terms of ubiquity) will have a large
influence. [Deployment] introduced useful terminology for this influence. [RFC7215] introduced useful terminology for this
progression, in addition to some coverage of the topic (see Section progression, in addition to some coverage of the topic (see
5, "Migration to LISP"): Section 5, "Migration to LISP"):
The loosely defined terms of "early transition phase", "late The loosely defined terms of early transition phase, late transition
transition phase", and "LISP Internet phase" refer to time periods phase, and LISP Internet phase refer to time periods when LISP sites
when LISP sites are a minority, a majority, or represent all edge are a minority, a majority, or represent all edge networks
networks respectively. respectively.
In the early phases of deployment, two primary effects will allow In the early phases of deployment, two primary effects will allow
LISP to have a positive impact on the routing table growth: LISP to have a positive impact on the routing table growth:
- Using LISP for traffic engineering instead of BGP o Using LISP for traffic engineering instead of BGP
- Aggregation of smaller PI sites into a single PITR advertisement
The first is fairly obvious (doing TE with BGP requires injecting o Aggregation of smaller PI sites into a single PITR advertisement
more-specific routes into the "Internet core" routing tables,
something doing TE with LISP avoids); the second is not guaranteed to
happen (since it requires coordination among a number of different
parties), and only time will tell if it does happen.
{{Add xref to text moved to "Improvments" document.}} The first is fairly obvious (doing TE with BGP requires injecting
more-specific routes into the Internet core routing tables, something
doing TE with LISP avoids); the second is not guaranteed to happen
(since it requires coordination among a number of different parties),
and only time will tell if it does happen.
16. Fault Discovery/Handling 16. Fault Discovery/Handling
{{Suggestion by editors: Remove this section, although this section
helps understanding how many of the LISP mechanisms work
(particularly the ones described in section 12) it provides an
unnecessary level of (operational) detail. This level of
understanding should be achieved reading the main LISP spec. }}
The structure of LISP gives rise to a moderate number of of failure The structure of LISP gives rise to a moderate number of of failure
modes. modes.
16.1. Handling Missing Mappings 16.1. Handling Missing Mappings
To handling missing mappings, the ITR calls for the mapping, and in To handling missing mappings, the ITR calls for the mapping, and in
the meantime can either discard traffic to that ultimate destination the meantime can either discard traffic to that ultimate destination
(as many ARP implementations do) [RFC826], or, if dropping the (as many ARP implementations do) [RFC0826], or, if dropping the
traffic is deemed undesirable, it can forward them via a PITR. traffic is deemed undesirable, it can forward them via a PITR.
16.2. Outdated Mappings 16.2. Outdated Mappings
If a mapping changes once an ITR has retrieved it, that may result in If a mapping changes once an ITR has retrieved it, that may result in
traffic to the EIDs covered by that mapping failing. There are three traffic to the EIDs covered by that mapping failing. There are three
cases to consider: cases to consider:
- When the ETR to which traffic is being sent is still a valid ETR o When the ETR to which traffic is being sent is still a valid ETR
for that EID, but the mapping has been updated (e.g. to change the for that EID, but the mapping has been updated (e.g. to change the
priority of various ETRs) priority of various ETRs)
- When the ETR traffic is being sent to is still an ETR, but no
o When the ETR traffic is being sent to is still an ETR, but no
longer a valid ETR for that EID longer a valid ETR for that EID
- When the ETR traffic is being sent to is no longer an ETR
- {{No longer an ETR, but still a LISP node - another case to o When the ETR traffic is being sent to is no longer an ETR
consider.}}
16.2.1. Outdated Mappings - Updated Mapping 16.2.1. Outdated Mappings - Updated Mapping
A 'mapping versioning' system, whereby mappings have version numbers, A 'mapping versioning' system, whereby mappings have version numbers,
and ITRs are notified when their mapping is out of date, has been and ITRs are notified when their mapping is out of date, has been
added to detect this, and the ITR responds by refreshing the mapping. added to detect this, and the ITR responds by refreshing the mapping.
[RFC6834] [RFC6834]
16.2.2. Outdated Mappings - Wrong ETR 16.2.2. Outdated Mappings - Wrong ETR
If an ITR is holding an outdated cached mapping, it may send packets If an ITR is holding an outdated cached mapping, it may send packets
to an ETR which is no longer an ETR for that EID. to an ETR which is no longer an ETR for that EID.
It might be argued that if the ETR is properly managing the lifetimes It might be argued that if the ETR is properly managing the lifetimes
on its mapping entries, this 'cannot happen', but it is a wise design on its mapping entries, this cannot happen, but it is a wise design
methodology to assume that 'cannot happen' events will in fact happen methodology to assume that cannot happen events will in fact happen
(as they do, due to software errors, or, on rare occasions, hardware (as they do, due to software errors, or, on rare occasions, hardware
faults), and ensure that the system will handle them properly (if, faults), and ensure that the system will handle them properly.
perhaps not in the most expeditious, or 'clean' way - they are, after
all, very unlikely to happen). {{Make less run on, easier to
understand.}}
ETRs can easily detect cases where this happpens, after they have un- ETRs can easily detect cases where this happens, after they have un-
wrapped a user data packet; in response, they send a Solicit-Map- wrapped a user data packet; in response, they send a Solicit-Map-
Request to the source ITR to cause it to refresh its mapping. Request to the source ITR to cause it to refresh its mapping.
16.2.3. Outdated Mappings - No Longer an ETR 16.2.3. Outdated Mappings - No Longer an ETR
In another case for what can happen if an ITR uses an outdated In another case for what can happen if an ITR uses an outdated
mapping, the destination of traffic from an ITR might no longer be a mapping, the destination of traffic from an ITR might no longer be a
LISP node at all. In such cases, one might get an ICMP Destination LISP node at all. In such cases, one might get an ICMP Destination
Unreachable (Port Unreachble subtype) error message. However, one Unreachable (Port Unreachble subtype) error message. However, one
cannot depend on that - and in any event, that would provide an cannot depend on that - and in any event, that would provide an
attack vector, so it should be used with care. (See [RFC6830], attack vector, so it should be used with care. (See [RFC6830],
Section 6.3, "Routing Locator Reachability" for more about this.) Section 6.3 for more about this.)
The following mechanism will work, though. Since the destination is The following mechanism will work, though. Since the destination is
not an ETR, the echoing reachability detection mechanism (see not an ETR, the echoing reachability detection mechanism (see
Section 12.3.2, "Echo Nonces") will detect a problem. At that point, Section 12.3.2, "Echo Nonces") will detect a problem. At that point,
the backstop mechanism, Probing, will kick in. Since the destination the backstop mechanism, Probing, will kick in. Since the destination
is still not an ETR, that will fail, too. is still not an ETR, that will fail, too.
At that point, traffic will be switched to a different ETR, or, if At that point, traffic will be switched to a different ETR, or, if
none are available, a reload of the mapping may be initiated. none are available, a reload of the mapping may be initiated.
16.3. Erroneous Mappings 16.3. Erroneous Mappings
Again, this 'should not happen', but a good system should deal with {{Suggestion by editors: this section brings nothing, remove it}}
it. However, in practise, should this happen, it will produce one of
the prior two cases (the wrong ETR, or something that is not an ETR), Again, this should not happen, but a good system should deal with it.
and will be handled as described there. However, in practise, should this happen, it will produce one of the
prior two cases (the wrong ETR, or something that is not an ETR), and
will be handled as described there.
16.4. Verifying ETR Liveness 16.4. Verifying ETR Liveness
The ITR, like all packet switches, needs to detect, and react, when The ITR, like all packet switches, needs to detect, and react, when
its neighbour ceases operation. As LISP traffic is effectively its neighbour ceases operation. As LISP traffic is effectively
always uni-directional (from ITR to ETR), this could be somewhat always uni-directional (from ITR to ETR), this could be somewhat
problematic. problematic.
Solving a related problem, "neighbour ETR" "reachability" below) Solving a related problem, "neighbour ETR" "reachability" below)
subsumes handling this fault mode, however. subsumes handling this fault mode, however.
Note that the two terms - "liveness" and "reachability" - are _not_ {{Suggestion by editors: remove next paragraph }}
synonmous (although they are often confused). Liveness is a property
of a node - it is either up and functioning, or it is not. Note that the two terms - liveness and reachability - are not
Reachability is only a property of a particular _pair_ of nodes. synonymous (although they are often confused). Liveness is a
{{Really property of path - if only one path, property of pair, property of a node - it is either up and functioning, or it is not.
otherwise of path.}} Reachability is only a property of a particular pair of nodes.
If packets sent from a first node to a second are successfully If packets sent from a first node to a second are successfully
received at the second, it is 'reachable' from the first. However, received at the second, it is reachable from the first. However, the
the second node may at the very same time _not_ be reachable from second node may at the very same time not be reachable from some
some other node. Reachability is _always_ a ordered pairwise other node. Reachability is always a ordered pairwise property, and
property, and of a specified ordered pair. of a specified ordered pair.
16.5. Verifying ETR Reachability 16.5. Verifying ETR Reachability
A more significant issue than whether a particular ETR is up or not A more significant issue than whether a particular ETR is up or not
is, as mentioned above, that although the ETR may be up, attached to is, as mentioned above, that although the ETR may be up, attached to
the network, etc, an issue in the network, between a source ITR, and the network, etc, an issue in the network, between a source ITR, and
the ETR, may prevent traffic from the ITR from getting to the ETR. the ETR, may prevent traffic from the ITR from getting to the ETR.
(Perhaps a routing problem, or perhaps some sort of access control (Perhaps a routing problem, or perhaps some sort of access control
setting.) setting.)
The one-way nature of LISP traffic makes this situation hard to The one-way nature of LISP traffic makes this situation hard to
detect in a way which is economic, robust and fast. Two out of the detect with simple and non-intrusive techniques. In line with the
three are usually not to hard, but all three at the same time - as is LISP design philosophy this problem is then attacked not with a
highly desirable for this particular issue - are harder. single mechanism (which would be complex) but with a collection of
simple mechanisms.
In line with the LISP design philosophy ([Perspective], Section
"Design-Theoretical"), this problem is attacked not with a single
mechanism (which would have a hard time meeting all those three goals
simultaneously), but with a collection of simpler, cheaper
mechanisms, which collectively will usually meet all three.
They are reliance on the underlying routing system (which can of They are reliance on the underlying routing system (which can of
course only reliably provide a negative reachabilty indication, not a course only reliably provide a negative reachabilty indication, not a
positive one), the echo nonce (which depends on some return traffic positive one), the echo nonce (which depends on some return traffic
from the destination xTR back to the source xTR), and finally direct from the destination xTR back to the source xTR), and finally RLOC
'pinging', in the case where no positive echo is returned. probing, in the case where no positive echo is returned.
{{Suggestion by editors: remove next paragraph }}
(The last is not the first choice, as due to the large fan-out (The last is not the first choice, as due to the large fan-out
expected of LISP router, reliance on it as a sole mechanism would expected of LISP router, reliance on it as a sole mechanism would
produce a fair amount of overhead.) produce a fair amount of overhead.)
17. Acknowledgments 17. Acknowledgments
This document was initiated by Noel Chiappa, and much of the core
philosophy came from him. We acknowledge the important contributions
he has made to this work and thank him for his past efforts.
The author would like to start by thanking all the members of the The author would like to start by thanking all the members of the
core LISP group for their willingness to allow him to add himself to core LISP group for their willingness to allow him to add himself to
their effort, and for their enthusiasm for whatever assistance he has their effort, and for their enthusiasm for whatever assistance he has
been able to provide. been able to provide.
He would also like to thank (in alphabetical order) Michiel Blokzijl, He would also like to thank (in alphabetical order) Michiel Blokzijl,
Peter Chiappa, Vina Ermagan, Dino Farinacci, Vince Fuller and Peter Chiappa, Vina Ermagan, Dino Farinacci, Vince Fuller and
Vasileios Lakafosis for their review of, and helpful suggestions for, Vasileios Lakafosis for their review of, and helpful suggestions for,
this document. (If I have missed anyone in this list, I apologize this document. (If I have missed anyone in this list, I apologize
most profusely.) most profusely.)
skipping to change at line 2151 skipping to change at page 47, line 32
19. Security Considerations 19. Security Considerations
This memo does not define any protocol and therefore creates no new This memo does not define any protocol and therefore creates no new
security issues. security issues.
20. References 20. References
20.1. Normative References 20.1. Normative References
[AFI] IANA, "Address Family Indicators (AFIs)", Address [AFI] IANA, , "Address Family Indicators (AFIs)",
Family Numbers, January 2011, <http://www.iana.org/ http://www.iana.org/assignments/address-family-numbers ,
assignments/address-family-numbers>. January 2011.
[RFC768] J. Postel, "User Datagram Protocol", RFC 768,
August 1980.
[RFC791] J. Postel, "Internet Protocol", RFC 791, [I-D.ermagan-lisp-nat-traversal]
September 1981. Ermagan, V., Farinacci, D., Lewis, D., Skriver, J., Maino,
F., and C. White, "NAT traversal for LISP", draft-ermagan-
lisp-nat-traversal-05 (work in progress), February 2014.
[RFC2460] S. Deering and R. Hinden, "Internet Protocol, [I-D.farinacci-lisp-te]
Version 6 (IPv6) Specification", RFC 2460, Farinacci, D., Kowal, M., and P. Lahiri, "LISP Traffic
December 1998. Engineering Use-Cases", draft-farinacci-lisp-te-06 (work
in progress), March 2014.
[RFC6830] D. Farinacci, V. Fuller, D. Meyer, and D. Lewis, [I-D.ietf-lisp-ddt]
"The Locator/ID Separation Protocol (LISP)", Fuller, V., Lewis, D., Ermagan, V., and A. Jain, "LISP
RFC 6830, January 2013. Delegated Database Tree", draft-ietf-lisp-ddt-01 (work in
progress), March 2013.
[RFC6831] D. Farinacci, D. Meyer, J. Zwiebel, and S. Venaas, [I-D.ietf-lisp-lcaf]
"The Locator/ID Separation Protocol (LISP) for Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical
Multicast Environments", RFC 6831, January 2013. Address Format (LCAF)", draft-ietf-lisp-lcaf-05 (work in
progress), May 2014.
[RFC6832] D. Lewis, D. Meyer, D. Farinacci, and V. Fuller, [I-D.ietf-lisp-perspective]
"Interworking between Locator/ID Separation Protocol Chiappa, J., "An Architectural Perspective on the LISP
(LISP) and Non-LISP Sites", RFC 6832, January 2013. Location-Identity Separation System", draft-ietf-lisp-
perspective-00 (work in progress), February 2013.
[RFC6833] V. Fuller and D. Farinacci, "Locator/ID Separation [I-D.ietf-lisp-sec]
Protocol (LISP) Map-Server Interface", RFC 6833, Maino, F., Ermagan, V., Cabellos-Aparicio, A., and D.
January 2013. Saucez, "LISP-Security (LISP-SEC)", draft-ietf-lisp-sec-06
(work in progress), April 2014.
[RFC6834] L. Iannone, D. Saucez, and O. Bonaventure, [I-D.ietf-lisp-threats]
"Locator/ID Separation Protocol (LISP) Map- Saucez, D., Iannone, L., and O. Bonaventure, "LISP Threats
Versioning", RFC 6834, January 2013. Analysis", draft-ietf-lisp-threats-10 (work in progress),
July 2014.
[Perspective] J. N. Chiappa, "An Architectural Perspective on the [I-D.meyer-lisp-mn]
LISP Location-Identity Separation System", Farinacci, D., Lewis, D., Meyer, D., and C. White, "LISP
draft-ietf-lisp-perspective-00 (work in progress), Mobile Node", draft-meyer-lisp-mn-10 (work in progress),
February 2013. January 2014.
[Improvements] J. N. Chiappa, "An Overview of On-Going Improvements [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
to the LISP Location-Identity Separation System", August 1980.
draft-chiappa-lisp-improvements-00 (work in
progress), September 2013.
[DDT] V. Fuller, D. Lewis, and D. Farinacci, "LISP [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September
Delegated Database Tree", draft-ietf-lisp-ddt-01 1981.
(work in progress), March 2013.
[LISP-SEC] F. Maino, V. Ermagan, A. Cabellos-Aparicio, [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
D. Saucez, and O. Bonaventure, "LISP-Security (LISP- (IPv6) Specification", RFC 2460, December 1998.
SEC)", draft-ietf-lisp-sec-04 (work in progress),
October 2012.
[NAT-Traversal] V. Ermagan, D. Farinacci, D. Lewis, J. Skriver, [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The
F. Maino, and C. White, "NAT traversal for LISP", Locator/ID Separation Protocol (LISP)", RFC 6830, January
draft-ermagan-lisp-nat-traversal-03 (work in 2013.
progress), March 2013.
[Mobility] D. Farinacci, V. Fuller, D. Lewis, and D. Meyer, [RFC6831] Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas, "The
"LISP Mobility Architecture", draft-meyer-lisp-mn-08 Locator/ID Separation Protocol (LISP) for Multicast
(work in progress), April 2012. Environments", RFC 6831, January 2013.
[Deployment] L. Jakab, A. Cabellos-Aparicio, F. Coras, [RFC6832] Lewis, D., Meyer, D., Farinacci, D., and V. Fuller,
J. Domingo-Pascual, and D. Lewis, "LISP Network "Interworking between Locator/ID Separation Protocol
Element Deployment Considerations", (LISP) and Non-LISP Sites", RFC 6832, January 2013.
draft-ietf-lisp-deployment-09 (work in progress),
July 2013.
[Threats] D. Saucez, L. Iannone, and O. Bonaventure, "LISP [RFC6833] Fuller, V. and D. Farinacci, "Locator/ID Separation
Threats Analysis", draft-ietf-lisp-threats-08 (work Protocol (LISP) Map-Server Interface", RFC 6833, January
in progress), October 2013. 2013.
[LCAF] D. Farinacci, D. Meyer, and J. Snijders, "LISP [RFC6834] Iannone, L., Saucez, D., and O. Bonaventure, "Locator/ID
Canonical Address Format (LCAF)", Separation Protocol (LISP) Map-Versioning", RFC 6834,
draft-ietf-lisp-lcaf-03 (work in progress), January 2013.
September 2013.
[LISP-TE] D. Farinacci, P. Lahiri, and M. Kowal, "LISP Traffic [RFC7215] Jakab, L., Cabellos-Aparicio, A., Coras, F., Domingo-
Engineering Use-Cases", draft-farinacci-lisp-te-03 Pascual, J., and D. Lewis, "Locator/Identifier Separation
(work in progress), July 2013. Protocol (LISP) Network Element Deployment
Considerations", RFC 7215, April 2014.
20.2. Informative References 20.2. Informative References
[NIC8246] A. McKenzie and J. Postel, "Host-to-Host Protocol [Atkinson]
for the ARPANET", NIC 8246, Network Information R. Atkinson, , "Revised draft proposed definitions", RRG
Center, SRI International, Menlo Park, CA, list message, Message-Id: 808E6500-97B4-4107- 8A2F-
October 1977. 36BC913BE196@extremenetworks.com, 11 June 2007,
http://www.ietf.org/mail-archive/web/ram/current/
msg01470.html , .
[NSAP] International Organization for Standardization, [Baran] P. Baran, , "On Distributed Communications Networks", IEEE
"Information Processing Systems - Open Systems Transactions on Communications Systems Vol. CS-12 No. 1,
Interconnection - Basic Reference Model", ISO pp. 1-9 , March 1964.
Standard 7489.1984, 1984.
[IEN19] J. F. Shoch, "Inter-Network Naming, Addressing, and [Bibliography]
Routing", IEN (Internet Experiment Note) 19, J.N. Chiappa, , "LISP (Location/Identity Separation
January 1978. Protocol) Bibliography",
http://www.chiappa.net/~jnc/tech/lisp/LISPbiblio.html ,
July 2013.
[RFC826] D. Plummer, "Ethernet Address Resolution Protocol", [Chiappa] J.N. Chiappa, , "Endpoints and Endpoint Names: A Proposed
RFC 826, November 1982. Enhancement to the Internet Architecture", Personal draft
(work in progress), 1999,
http://www.chiappa.net/~jnc/tech/endpoints.txt , 1999.
[RFC1034] P. V. Mockapetris, "Domain Names - Concepts and [Clark] D. D. Clark, , "The Design Philosophy of the DARPA
Facilities", RFC 1034, November 1987. Internet Protocols", Proceedings of the Symposium on
Communications Architectures and Protocols SIGCOMM '88',
pp. 106-114 , 1988.
[RFC1498] J. H. Saltzer, "On the Naming and Binding of Network [CorasBGP]
Destinations", RFC 1498, (Originally published in: F. Coras, D. Saucez, L. Jakab, A. Cabellos-Aparicio, and
'Local Computer Networks', edited by P. Ravasio et J. Domingo-Pascual, , "Implementing a BGP-free ISP Core
al., North-Holland Publishing Company, Amsterdam, with LISP", Proceedings of the Global Communications
1982, pp. 311-317.), August 1993. Conference (GlobeCom), IEEE, pp. 2772-2778 , December
2012.
[RFC1631] K. Egevang and P. Francis, "The IP Network Address [CorasCache]
Translator (NAT)", RFC 1631, May 1994. J. Kim, L. Iannone, and A. Feldmann, , "On the Cost of
Caching Locator/ID Mappings", Proceedings of the 10th
International IFIP TC 6 Conference on Networking - Volume
Part I (NETWORKING '11)', IFIP, pp. 367-378 , May 2011.
[RFC1812] F. Baker, "Requirements for IP Version 4 Routers", [Future] J.N. Chiappa, , "Potential Long-Term Developments With the
RFC 1812, June 1995. LISP System", draft-chiappa-lisp-evolution-00 (work in
progress) (NOT EXISTING) , October 2012.
[RFC1918] Y. Rekhter, R. Moskowitz, D. Karrenberg, [Heart] F. E. Heart, R. E. Kahn, S. M. Ornstein, W. R. Crowther,
G. J. de Groot, and E. Lear, "Address Allocation for and D. C. Walden, , "The Interface Message Processor for
Private Internets", RFC 1918, February 1996. the ARPA Computer Network", Proceedings AFIPS SJCC, Vol.
36, pp. 551-567 , 1970.
[RFC1992] I. Castineyra, J. N. Chiappa, and M. Steenstrup, [I-D.farinacci-lisp]
"The Nimrod Routing Architecture", RFC 1992, Farinacci, D., "Locator/ID Separation Protocol (LISP)",
August 1996. draft-farinacci-lisp-00 (work in progress), January 2007.
[RFC3168] K. Ramakrishnan, S. Floyd, and D. Black, "The [IEN19] J. F. Shoch, , "Inter-Network Naming, Addressing, and
Addition of Explicit Congestion Notification (ECN) Routing", IEN (Internet Experiment Note) 19 , January
to IP", RFC 3168, September 2001. 1978.
[RFC3170] B. Quinn and K. Almeroth, "IP Multicast [Iannone] L. Iannone and O. Bonaventure, , "On the Cost of Caching
Applications: Challenges and Solutions", RFC 3170, Locator/ID Mappings", Proceedings of the 3rd International
September 2001. Conference on emerging Networking EXperiments and
Technologies (CoNEXT'07)', ACM, pp. 1-12 , December 2007.
[RFC3272] D. Awduche, A. Chiu, A. Elwalid, I. Widjaja, and [Improvements]
X. Xiao, "Overview and Principles of Internet J.N. Chiappa, , "An Overview of On-Going Improvements to
Traffic Engineering", RFC 3272, May 2002. the LISP Location-Identity Separation System", draft-
chiappa-lisp-improvements-00 (work in progress) (NOT
EXISTING) , September 2013.
[RFC4026] L. Andersson and T. Madsen, "Provider Provisioned [Kim] L. Iannone and O. Bonaventure, , "A Deep Dive Into the
Virtual Private Network (VPN) Terminology", LISP Cache and What ISPs Should Know About It",
RFC 4026, March 2005. Proceedings of the 3rd International Conference on
emerging Networking EXperiments and Technologies
(CoNEXT'07)', ACM, pp. 1-12 , December 2007.
[RFC4033] R. Arends, R. Austein, M. Larson, D. Massey, and [LISP-TREE]
S. Rose, "DNS Security Introduction and L. Jakab, A. Cabellos-Aparicio, F. Coras, D. Saucez, and
Requirements", RFC 4033, March 2005. O. Bonaventure, , "LISP-TREE: A DNS Hierarchy to Support
the LISP Mapping System", IEEE Journal on Selected Areas
in Communications', Vol. 28, No. 8, pp. 1332-1343 ,
October 2010.
[RFC4107] S. Bellovin and R. Housley, "Guidelines for [NIC8246] A. McKenzie and J. Postel, , "Host-to-Host Protocol for
Cryptographic Key Management", RFC 4107, June 2005. the ARPANET", NIC 8246, Network Information Center, SRI
International, Menlo Park, CA , October 1977.
[RFC4116] J. Abley, K. Lindqvist, E. Davies, B. Black, and [NSAP] International Organization for Standardization, ,
V. Gill, "IPv4 Multihoming Practices and "Information Processing Systems - Open Systems
Limitations", RFC 4116, July 2005. Interconnection - Basic Reference Model", ISO Standard
7489.1984 , 1984.
[RFC4786] J. Abley and K. Lindqvist, "Operation of Anycast [RFC0826] Plummer, D., "Ethernet Address Resolution Protocol: Or
Services", RFC 4786, December 2006. converting network protocol addresses to 48.bit Ethernet
address for transmission on Ethernet hardware", STD 37,
RFC 826, November 1982.
[RFC4984] D. Meyer, L. Zhang, and K. Fall, "Report from the [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
IAB Workshop on Routing and Addressing", RFC 4984, STD 13, RFC 1034, November 1987.
September 2007.
[RFC5110] P. Savola, "Overview of the Internet Multicast [RFC1498] Saltzer, J., "On the Naming and Binding of Network
Routing Architecture", RFC 5110, January 2008. Destinations", RFC 1498, August 1993.
[RFC5887] B. Carpenter, R. Atkinson, and H. Flinck, [RFC1631] Egevang, K. and P. Francis, "The IP Network Address
"Renumbering Still Needs Work", RFC 5887, May 2010. Translator (NAT)", RFC 1631, May 1994.
[RFC6115] T. Li, Ed., "Recommendation for a Routing [RFC1812] Baker, F., "Requirements for IP Version 4 Routers", RFC
Architecture", RFC 6115, February 2011. 1812, June 1995.
(Perhaps the most ill-named RFC of all time; it [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
contains nothing that could truly be called a E. Lear, "Address Allocation for Private Internets", BCP
'routing architecture'.) 5, RFC 1918, February 1996.
[ALT] V. Fuller, D. Farinacci, D. Meyer, and D. Lewis, [RFC1992] Castineyra, I., Chiappa, N., and M. Steenstrup, "The
"Locator/ID Separation Protocol Alternative Logical Nimrod Routing Architecture", RFC 1992, August 1996.
Topology (LISP+ALT)", RFC 6836, January 2013.
[LISP0] D. Farinacci, V. Fuller, and D. Oran, "Locator/ID [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
Separation Protocol (LISP)", draft-farinacci-lisp-00 of Explicit Congestion Notification (ECN) to IP", RFC
(work in progress), January 2007. 3168, September 2001.
[Future] J. N. Chiappa, "Potential Long-Term Developments [RFC3170] Quinn, B. and K. Almeroth, "IP Multicast Applications:
With the LISP System", Challenges and Solutions", RFC 3170, September 2001.
draft-chiappa-lisp-evolution-00 (work in progress),
October 2012.
[Baran] P. Baran, "On Distributed Communications Networks", [RFC3272] Awduche, D., Chiu, A., Elwalid, A., Widjaja, I., and X.
IEEE Transactions on Communications Systems Vol. Xiao, "Overview and Principles of Internet Traffic
CS-12 No. 1, pp. 1-9, March 1964. Engineering", RFC 3272, May 2002.
[Chiappa] J. N. Chiappa, "Endpoints and Endpoint Names: A [RFC4026] Andersson, L. and T. Madsen, "Provider Provisioned Virtual
Proposed Enhancement to the Internet Architecture", Private Network (VPN) Terminology", RFC 4026, March 2005.
Personal draft (work in progress), 1999,
<http://www.chiappa.net/~jnc/tech/endpoints.txt>.
[Clark] D. D. Clark, "The Design Philosophy of the DARPA [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Internet Protocols", in 'Proceedings of the Rose, "DNS Security Introduction and Requirements", RFC
Symposium on Communications Architectures and 4033, March 2005.
Protocols SIGCOMM '88', pp. 106-114, 1988.
[Saltzer] J. H. Saltzer, D. P. Reed, and D. D. Clark, "End-To- [RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic
End Arguments in System Design", ACM TOCS, Vol 2, Key Management", BCP 107, RFC 4107, June 2005.
No. 4, pp 277-288, November 1984.
[Heart] F. E. Heart, R. E. Kahn, S. M. Ornstein, [RFC4116] Abley, J., Lindqvist, K., Davies, E., Black, B., and V.
W. R. Crowther, and D. C. Walden, "The Interface Gill, "IPv4 Multihoming Practices and Limitations", RFC
Message Processor for the ARPA Computer Network", 4116, July 2005.
Proceedings AFIPS 1970 SJCC, Vol. 36, pp. 551-567.
[Iannone] L. Iannone and O. Bonaventure, "On the Cost of [RFC4786] Abley, J. and K. Lindqvist, "Operation of Anycast
Caching Locator/ID Mappings", in 'Proceedings of the Services", BCP 126, RFC 4786, December 2006.
3rd International Conference on emerging Networking
EXperiments and Technologies (CoNEXT'07)', ACM, pp.
1-12, December 2007.
[Kim] J. Kim, L. Iannone, and A. Feldmann, "A Deep Dive [RFC4984] Meyer, D., Zhang, L., and K. Fall, "Report from the IAB
Into the LISP Cache and What ISPs Should Know About Workshop on Routing and Addressing", RFC 4984, September
It", in 'Proceedings of the 10th International IFIP 2007.
TC 6 Conference on Networking - Volume Part I
(NETWORKING '11)', IFIP, pp. 367-378, May 2011.
[CorasCache] F. Coras, A. Cabellos-Aparicio, and J. Domingo- [RFC5110] Savola, P., "Overview of the Internet Multicast Routing
Pascual, "An Analytical Model for the LISP Cache Architecture", RFC 5110, January 2008.
Size", in 'Proceedings of the 11th International
IFIP TC 6 Networking Conference: Part I', IFIP, pp.
409-420, May 2012.
[LISP-TREE] L. Jakab, A. Cabellos-Aparicio, F. Coras, D. Saucez, [RFC5887] Carpenter, B., Atkinson, R., and H. Flinck, "Renumbering
and O. Bonaventure, "LISP-TREE: A DNS Hierarchy to Still Needs Work", RFC 5887, May 2010.
Support the LISP Mapping System", in 'IEEE Journal
on Selected Areas in Communications', Vol. 28, No.
8, pp. 1332-1343, October 2010.
[Saucez] D. Saucez, L. Iannone, and B. Donnet, "A First [RFC6115] Li, T., "Recommendation for a Routing Architecture", RFC
Measurement Look at the Deployment and Evolution of 6115, February 2011.
the Locator/ID Separation Protocol", in 'ACM SIGCOMM
Computer Communication Review', Vol. 43 No. 2, pp.
37-43, April 2013.
[CorasBGP] F. Coras, D. Saucez, L. Jakab, A. Cabellos-Aparicio, [RFC6836] Fuller, V., Farinacci, D., Meyer, D., and D. Lewis,
and J. Domingo-Pascual, "Implementing a BGP-free ISP "Locator/ID Separation Protocol Alternative Logical
Core with LISP", in 'Proceedings of the Global Topology (LISP+ALT)", RFC 6836, January 2013.
Communications Conference (GlobeCom)', IEEE, pp.
2772-2778, December 2012.
[Atkinson] R. Atkinson, "Revised draft proposed definitions", [Saltzer] J. H. Saltzer, D. P. Reed, and D. D. Clark, , "End-To-End
RRG list message, Message-Id: 808E6500-97B4-4107- Arguments in System Design", ACM TOCS, Vol 2, No. 4, pp
8A2F-36BC913BE196@extremenetworks.com, 11 June 2007, 277-288 , November 1984.
<http://www.ietf.org/mail-archive/web/ram/current/
msg01470.html>.
[Bibliography] J. N. Chiappa (editor), "LISP (Location/Identity [Saucez] D. Saucez, L. Iannone, and B. Donnet, , "A First
Separation Protocol) Bibliography", Personal Measurement Look at the Deployment and Evolution of the
site (work in progress), July 2013, <http:// Locator/ID Separation Protocol", ACM SIGCOMM Computer
www.chiappa.net/~jnc/tech/lisp/LISPbiblio.html>. Communication Review', Vol. 43 No. 2, pp. 37-43 , April
2013.
Appendix A. Glossary/Definition of Terms Appendix A. Glossary/Definition of Terms
- EID, Enpoint Identifier: Originally defined as a name for an {{Suggestion by editors: remove and use those from RFCs instead }}
"endpoint", one with purely identity semantics, and globally
unique, and with syntax of relatively short fixed length. o EID, Enpoint Identifier: Originally defined as a name for an
[Chiappa] It is used in the LISP work to mean the "identifier" of endpoint, one with purely identity semantics, and globally unique,
a "node"; it is the input to an EID->RLOC lookup in the "mapping and with syntax of relatively short fixed length. It is used in
system"; it is usually an "IPvN" "address". The source and the LISP work to mean the identifier of a node; it is the input to
destination addresses of the _innermost_ header in a LISP packet an EID->RLOC lookup in the mapping system; it is usually an IP
are usually EIDs. address. The source and destination addresses of the innermost
- RLOC, Routing Locator: a LISP-specific term meaning the "locator" header in a LISP packet are usually EIDs.
o RLOC, Routing Locator: a LISP-specific term meaning the locator
associated with an entity identified by an EID; as such, it is associated with an entity identified by an EID; as such, it is
often the output of an EID->RLOC lookup in the "mapping system"; often the output of an EID->RLOC lookup in the mapping system; it
it is usually an "IPvN" address, and of an "ETR". The source and is usually an IP address, and of an ETR. The source and
adestination addresses of the _outermost_ header in a LISP packet destination addresses of the outermost header in a LISP packet are
are usually RLOCs. usually RLOCs.
- ITR, Ingress Tunnel Router: a "LISP router" at the border of a
"LISP site" which takes user packets sent to it from inside the o ITR, Ingress Tunnel Router: a LISP router at the border of a LISP
LISP site, encapsulates in a LISP header, and then sends them site which takes user packets sent to it from inside the LISP
across the Internet to an "ETR"; in other words, the start of a site, encapsulates in a LISP header, and then sends them across
'tunnel' from the ITR to an ETR. the Internet to an ETR; in other words, the start of a tunnel from
- ETR: Egress Tunnel Router: a "LISP router" at the border of a the ITR to an ETR.
"LISP site" which decapsulates user packets which arrive at it
o ETR: Egress Tunnel Router: a LISP router at the border of a LISP
site which decapsulates user packets which arrive at it
encapsulated in a LISP header, and sends them on towards their encapsulated in a LISP header, and sends them on towards their
ultimate destination; in other words, the end of the 'tunnel' from ultimate destination; in other words, the end of the tunnel from
an "ITR" to the ETR. an ITR to the ETR.
- Neighbour ETR: Although an "ITR" and "ETR" may be separated by
many actual physical hops, _at the LISP level_, they are direct o Neighbour ETR: Although an ITR and ETR may be separated by many
actual physical hops, at the LISP level, they are direct
neighbours; so any ETR which an ITR sends traffic to is a neighbours; so any ETR which an ITR sends traffic to is a
'neighbour ETR' of that ITR. neighbour ETR of that ITR.
- xTR: An xTR refers to a "LISP router" which functions both as an
"ITR" and an "ETR" (which is typical), when the discussion o xTR: An xTR refers to a LISP router which functions both as an ITR
involves packet flows in both directions through the router, which and an ETR (which is typical), when the discussion involves packet
results in it alternately functioning as an ITR and then as an flows in both directions through the router, which results in it
ETR. alternately functioning as an ITR and then as an ETR.
- Reachable; Reachability; Neighbour ETR Reachability: The ability
of an "ITR" to be able to send packets to a "neighbour ETR", or o Reachable; Reachability; Neighbour ETR Reachability: The ability
the property of an ITR to be able to send such packets. of an ITR to be able to send packets to a neighbour ETR, or the
- Liveness: Whether a LISP "node" of any kind is 'up' and operating, property of an ITR to be able to send such packets.
or not; or the property of a LISP node to be in such a state.
- MR, Map Resolver: A LISP "node" to which "ITRs' send requests for o Liveness: Whether a LISP node of any kind is up and operating, or
"mappings". See Section 8.2.2, "Interface to the Mapping System", not; or the property of a LISP node to be in such a state.
for more.
- MS, Map Server: A LISP "node" with which "ETRs" register o MR, Map Resolver: A LISP node to which ITRs send requests for
"mappings", to indicate their availability to handle incoming mappings.
traffic to the "EIDs" covered in those mappings. See
Section 8.2.2, "Interface to the Mapping System" for more. o MS, Map Server: A LISP node with which ETRs register mappings, to
- Mapping System: The entire ensemble of data and mechanisms which indicate their availability to handle incoming traffic to the EIDs
allow clients - usually "ITRs" - to find "mappings" (from EIDs to covered in those mappings.
RLOCs). It includes both the "mapping database", and also
everything used to gain access to it - the MRs, the "indexing sub- o Mapping System: The entire ensemble of data and mechanisms which
system", etc. See Section 8.2.1, "Mapping System Organization" allow clients - usually ITRs - to find mappings (from EIDs to
for more. RLOCs). It includes both the mapping database, and also
- Mapping Database: The term 'mapping database' refers to the entire everything used to gain access to it - the MRs, the indexing sub-
collection of {EID->RLOC} "mappings" spread throughout the entire system, etc.
LISP system. It is a subset of the "mapping system". See
Section 8.2, "Control Plane - Mapping System Overview", for more. o Mapping Database: The term mapping database refers to the entire
- Mapping Cache: A collection of copies of {EID->RLOC} "mappings" collection of EID-to-RLOC mappings spread throughout the entire
retained in an ITR; not the entire "mapping database", but just LISP system. It is a subset of the mapping system.
the subset of it that an ITR needs in order to be able to properly
o Mapping Cache: A collection of copies of EID-to-RLOC mappings
retained in an ITR; not the entire mapping database, but just the
subset of it that an ITR needs in order to be able to properly
handle the user data traffic which is flowing through it. handle the user data traffic which is flowing through it.
- Indexing Sub-system: the entire ensemble of data and mechanisms
which allows "MRs" to find out which "ETR(s)" hold the mappping o Indexing Sub-system: the entire ensemble of data and mechanisms
for a given "EID" or "EID block". It includes both the data on which allows MRs to find out which ETR(s) hold the mapping for a
"namespace" delegations, as well as the nodes which hold that given EID or EID block. It includes both the data on namespace
data, and the protocols used to interact with those nodes. See delegations, as well as the nodes which hold that data, and the
Section 8.2.1, "Mapping System Organization" for more. protocols used to interact with those nodes.
- DDT Vertex; Vertex: a node (in the graph theory sense of the term)
in the (abstract) LISP namespace "delegation hierarchy". o DDT Vertex; Vertex: a node (in the graph theory sense of the term)
- DDT Server: an actual machine, which one can send packets to, in in the (abstract) LISP namespace delegation hierarchy.
o DDT Server: an actual machine, which one can send packets to, in
the DDT server hierarchy - which is, hopefully, a one-to-one the DDT server hierarchy - which is, hopefully, a one-to-one
projection of the LISP address "delegation hierarchy" (although of projection of the LISP address delegation hierarchy (although of
course a single "DDT vertex" may turn into several sibling course a single DDT vertex may turn into several sibling servers).
servers). Some documents refer to these as 'DDT nodes' but this Some documents refer to these as DDT nodes but this document does
document does not use that term, to prevent confusion with "DDT not use that term, to prevent confusion with DDT vertex.
vertex".
- PITR: Proxy ITR; an "ITR" which is used for interworking between a o PITR: Proxy ITR; an ITR which is used for interworking between a
LISP-speaking "node" or "site", and legacy nodes or sites; in LISP-speaking node or site, and legacy nodes or sites; in general,
general, it acts like a normal ITR, but does so on behalf of LISP it acts like a normal ITR, but does so on behalf of LISP nodes
nodes which are receiving packets from a legacy node. See which are receiving packets from a legacy node.
Section 15.2.1.1, "PITRs", for more.
- PETR: Proxy ETR; an "ETR" which is used for interworking between a o PETR: Proxy ETR; an ETR which is used for interworking between a
LISP-speaking "node" or "site", and legacy nodes or sites; in LISP-speaking node or site, and legacy nodes or sites; in general,
general, it acts like a normal ETR, but does so on behalf of LISP it acts like a normal ETR, but does so on behalf of LISP nodes
nodes which are sending packets to a legacy node. See which are sending packets to a legacy node.
Section 15.2.1.2, "PETRs" for more.
- RTR: Re-encapsulating Tunnel Router; a data plane 'anchor point' o RTR: Re-encapsulating Tunnel Router; a data plane 'anchor point'
used by a LISP-speaking node to perform functions that can only be used by a LISP-speaking node to perform functions that can only be
be performed in the core of the network. One use is for LISP- be performed in the core of the network. One use is for LISP-
speaking node behind a NAT device to send and receive traffic speaking node behind a NAT device to send and receive traffic
through the NAT device; see [Improvements], Section "Improved NAT through the NAT device; see
Support" for more.
- Internet core: That part of the Internet in which there are no o Internet core: That part of the Internet in which there are no
'default' entries in routing tables, but where the routing tables 'default' entries in routing tables, but where the routing tables
hold entries for every single reachable destination in the hold entries for every single reachable destination in the
Internet. (Sometimes referred to colloquially as the 'DFZ', or Internet. (Sometimes referred to colloquially as the DFZ, or
'Default Free Zone'.) 'Default Free Zone'.)
Appendix B. Other Appendices Appendix B. Other Appendices
B.1. A Brief History of Location/Identity Separation B.1. A Brief History of Location/Identity Separation
It was only gradually realized in the networking community that It was only gradually realized in the networking community that
networks (especially large networks) should deal quite separately networks (especially large networks) should deal quite separately
with the identity and location of a node; the distinction between the with the identity and location of a node; the distinction between the
two was more than a little hazy at first. two was more than a little hazy at first.
The ARPANET had no real acknowledgment of the difference between the The ARPANET had no real acknowledgment of the difference between the
two. [Heart] [NIC8246] The early Internet also co-mingled the two two. [Heart][NIC8246] The early Internet also co-mingled the two
([RFC791]), although there was recognition in the early Internet work ([RFC0791]), although there was recognition in the early Internet
that there were two different things going on. [IEN19] work that there were two different things going on. [IEN19]
This likely resulted not just from lack of insight, but also the fact This likely resulted not just from lack of insight, but also the fact
that extra mechanism is needed to support this separation (and in the that extra mechanism is needed to support this separation (and in the
early days there were no resources to spare), as well as the lack of early days there were no resources to spare), as well as the lack of
need for it in the smaller networks of the time. (It is a truism of need for it in the smaller networks of the time. (It is a truism of
system design that small systems can get away with doing two things system design that small systems can get away with doing two things
with one mechanism, in a way that usually will not work when the with one mechanism, in a way that usually will not work when the
system gets much larger.) system gets much larger.)
The ISO protocol architecture took steps in this direction [NSAP], The ISO protocol architecture took steps in this direction [NSAP],
skipping to change at line 2544 skipping to change at page 56, line 7
Internet engineering community at large, although it seems that this Internet engineering community at large, although it seems that this
may finally be happening. may finally be happening.
Unfortunately, although the development of IPv6 presented a golden Unfortunately, although the development of IPv6 presented a golden
opportunity to learn from this particular failing of IPv4, that opportunity to learn from this particular failing of IPv4, that
design failed to recognize the need for separation of location and design failed to recognize the need for separation of location and
identity. identity.
B.2. A Brief History of the LISP Project B.2. A Brief History of the LISP Project
{{Suggestion by editors: remove that makes no sense in this document
}}
The LISP system for separation of location and identity resulted from The LISP system for separation of location and identity resulted from
the discussions of this topic at the Amsterdam IAB Routing and the discussions of this topic at the Amsterdam IAB Routing and
Addressing Workshop, which took place in October 2006. [RFC4984] Addressing Workshop, which took place in October 2006. [RFC4984]
A small group of like-minded personnel from various scattered A small group of like-minded personnel from various scattered
locations within Cisco, spontaneously formed immediately after that locations within Cisco, spontaneously formed immediately after that
workshop, to work on an idea that came out of informal discussions at workshop, to work on an idea that came out of informal discussions at
the workshop. The first Internet-Draft on LISP appeared in January, the workshop. The first Internet-Draft on LISP appeared in January,
2007, along with a LISP mailing list at the IETF. [LISP0] 2007, along with a LISP mailing list at the IETF.
[I-D.farinacci-lisp]
Trial implementations started at that time, with initial trial Trial implementations started at that time, with initial trial
deployments underway since June 2007; the results of early experience deployments underway since June 2007; the results of early experience
have been fed back into the design in a continuous, ongoing process have been fed back into the design in a continuous, ongoing process
over several years. LISP at this point represents a moderately over several years. LISP at this point represents a moderately
mature system, having undergone a long organic series of changes and mature system, having undergone a long organic series of changes and
updates. updates.
LISP transitioned from an IRTF activity to an IETF WG in March 2009, LISP transitioned from an IRTF activity to an IETF WG in March 2009,
and after numerous revisions, the basic specifications moved to and after numerous revisions, the basic specifications moved to
skipping to change at line 2574 skipping to change at page 56, line 41
improve it, and find new uses for it, continues, and undoubtly will improve it, and find new uses for it, continues, and undoubtly will
for a long time to come). for a long time to come).
B.3. Old LISP 'Models' B.3. Old LISP 'Models'
LISP, as initilly conceived, had a number of potential operating LISP, as initilly conceived, had a number of potential operating
modes, named 'models'. Although they are now obsolete, one modes, named 'models'. Although they are now obsolete, one
occasionally sees mention of them, so they are briefly described occasionally sees mention of them, so they are briefly described
here. here.
- LISP 1: EIDs all appear in the normal routing and forwarding o LISP 1: EIDs all appear in the normal routing and forwarding
tables of the network (i.e. they are 'routable');this property is tables of the network (i.e. they are 'routable');this property is
used to 'bootstrap' operation, by using this to load EID->RLOC used to 'bootstrap' operation, by using this to load EID->RLOC
mappings. Packets were sent with the EID as the destination in mappings. Packets were sent with the EID as the destination in
the outer wrapper; when an ETR saw such a packet, it would send a the outer wrapper; when an ETR saw such a packet, it would send a
Map-Reply to the source ITR, giving the full mapping. Map-Reply to the source ITR, giving the full mapping.
- LISP 1.5: Similar to LISP 1, but the routability of EIDs happens
o LISP 1.5: Similar to LISP 1, but the routability of EIDs happens
on a separate network. on a separate network.
- LISP 2: EIDs are not routable; EID->RLOC mappings are available
o LISP 2: EIDs are not routable; EID->RLOC mappings are available
from the DNS. from the DNS.
- LISP 3: EIDs are not routable; and have to be looked up in in a
o LISP 3: EIDs are not routable; and have to be looked up in in a
new EID->RLOC mapping database (in the initial concept, a system new EID->RLOC mapping database (in the initial concept, a system
using Distributed Hash Tables). Two variants were possible: a using Distributed Hash Tables). Two variants were possible: a
'push' system, in which all mappings were distributed to all ITRs, 'push' system, in which all mappings were distributed to all ITRs,
and a 'pull' system in which ITRs load the mappings they need, as and a 'pull' system in which ITRs load the mappings they need, as
needed. needed.
B.4. The ALT Mapping Indexing Sub-system B.4. The ALT Mapping Indexing Sub-system
LISP initially used an indexing sub-system called ALT. [ALT] ALT re- LISP initially used an indexing sub-system called ALT. [RFC6836]ALT
purposed a number of existing mechanisms to provide an indexing re-purposed a number of existing mechanisms to provide an indexing
system, which allowed an experimental LISP initial deployment to system, which allowed an experimental LISP initial deployment to
become operational without having to write a lot of code, ALT was become operational without having to write a lot of code, ALT was
relatively easily constructed from basically unmodified existing relatively easily constructed from basically unmodified existing
mechanisms; it used BGP running over virtual tunnels using GRE. mechanisms; it used BGP running over virtual tunnels using GRE.
ALT proved to have a number of issues which made it unsuitable for ALT proved to have a number of issues which made it unsuitable for
large-scale use, and it has now been superseded by DDT. A complete large-scale use, and it has now been superseded by DDT. A complete
list of these is not possible here, but the issues mostly were of two list of these is not possible here, but the issues mostly were of two
kinds: technical issues which would have arisen at large scale, and kinds: technical issues which would have arisen at large scale, and
practical operational issues which appeared even in the experimental practical operational issues which appeared even in the experimental
skipping to change at line 2660 skipping to change at page 58, line 32
respect to a number of different target EIDs. The results indicate respect to a number of different target EIDs. The results indicate
that the performance was almost identical; there was more variance that the performance was almost identical; there was more variance
with DDT (perhaps due to the effects of caching), but the greatly with DDT (perhaps due to the effects of caching), but the greatly
improved scalability of DDT as compared to ALT made that effect improved scalability of DDT as compared to ALT made that effect
acceptable. acceptable.
B.5. Early NAT Support B.5. Early NAT Support
The first mechanism used by LISP to support operation through a NAT The first mechanism used by LISP to support operation through a NAT
device, described here, has now been superseded by the more general device, described here, has now been superseded by the more general
mechanism proposed in [NAT-Traversal]. That mechanism is, however, mechanism proposed in [I-D.ermagan-lisp-nat-traversal]. That
based heavily on this mechanism. The initial mechanism had some mechanism is, however, based heavily on this mechanism. The initial
serious limitations, which is why that particular form of it has been mechanism had some serious limitations, which is why that particular
dropped. form of it has been dropped.
First, it only worked with some NATs, those which were configurable First, it only worked with some NATs, those which were configurable
to allow inbound packet traffic to reach a configured host. The NAT to allow inbound packet traffic to reach a configured host. The NAT
had to be configured to know of the ETR. had to be configured to know of the ETR.
Second, since NATs share addresses by using ports, it was only Second, since NATs share addresses by using ports, it was only
possible to have a single LISP node behind any given NAT device. possible to have a single LISP node behind any given NAT device.
That is because LISP expects all incoming data traffic to be on a That is because LISP expects all incoming data traffic to be on a
specific port, so it was not possible to have multiple ETRs behind a specific port, so it was not possible to have multiple ETRs behind a
single NAT (which normally would have only one global IP address to single NAT (which normally would have only one global IP address to
skipping to change at line 2694 skipping to change at page 59, line 19
which included the source address from which the Echo Request was which included the source address from which the Echo Request was
received (i.e. the public global address assigned to the ETR by the received (i.e. the public global address assigned to the ETR by the
NAT). The ETR could then insert that address in any Map-Reply NAT). The ETR could then insert that address in any Map-Reply
control messages which it sent to correspondent ITRs. control messages which it sent to correspondent ITRs.
Echo-Request and Echo-Reply have been replaced by Info-Request and Echo-Request and Echo-Reply have been replaced by Info-Request and
Info-Reply in the replacement, [NAT-Traversal], where they perform Info-Reply in the replacement, [NAT-Traversal], where they perform
very similar functions; the main change is the addition of the {{xxx very similar functions; the main change is the addition of the {{xxx
- probably the port, etc to allow multiple XTRs behind a NAT}}. - probably the port, etc to allow multiple XTRs behind a NAT}}.
Author's Address Authors' Addresses
J. Noel Chiappa Albert Cabellos-Aparicio (Ed.)
Yorktown Museum of Asian Art Technical University of Catalonia
Yorktown, Virginia C/Jordi Girona, s/n
USA BARCELONA 08034
Spain
EMail: jnc@mit.edu Email: jacabello@ac.upc.edu
Damien Saucez (Ed.)
INRIA
2004 route des Lucioles BP 93
06902 Sophia Antipolis Cedex
France
Email: damien.saucez@inria.fr
 End of changes. 353 change blocks. 
1192 lines changed or deleted 1260 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/