Internet DRAFT - draft-saucez-lisp-iterable-mapping
draft-saucez-lisp-iterable-mapping
Network Working Group D. Saucez
Internet-Draft O. Bonaventure
Intended status: Informational Universite catholique de Louvain
Expires: October 23, 2011 April 21, 2011
LISP Iterable Mappings
draft-saucez-lisp-iterable-mapping-02
Abstract
The Mapping System is a key component of the Locator Identifier
Separation Protocol (LISP). In this document, we describe Iterable
Mappings allowing the mappings to point to Map-Server addresses
instead of ETR addresses. Iterable mappings open the possibility of
performing iterative queries that could be used to deploy mapping
systems without requiring overlays or to optimize current mapping
systems.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on October 23, 2011.
Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
Saucez & Bonaventure Expires October 23, 2011 [Page 1]
Internet-Draft LISP Iterable Mappings April 2011
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Additional LISP Packet Type Allocation . . . . . . . . . . . . 7
3. Extension to Map-Request Message Format . . . . . . . . . . . 7
4. Iterable-Mapping Message Format . . . . . . . . . . . . . . . 8
5. Message Processing . . . . . . . . . . . . . . . . . . . . . . 9
6. Map-Server Deployment and Adaptations . . . . . . . . . . . . 9
7. Security Considerations . . . . . . . . . . . . . . . . . . . 10
8. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 10
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10
10. Informative References . . . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
Saucez & Bonaventure Expires October 23, 2011 [Page 2]
Internet-Draft LISP Iterable Mappings April 2011
1. Introduction
LISP Mapping systems can be decomposed in three components: the
querier, the resolver and the server. First, the querier initiates a
request for a mapping resolution by querying a resolver. Second, the
resolver sends a Map-Request to a server. Third, the server returns
a Map-Reply containing the mapping to the resolver. The Map-Reply
gives the mapping for the identifier present in the Map-Request.
Finally, the resolver can return the mapping to the requester.
Depending on the mapping system, there can exist intermediate
elements between the resolver and the server. It is also possible to
have redundant resolvers or servers.
When the querier is not able to send the Map-Request directly to a
server that can provide a mapping for the identifier in the request,
the Map-Request must be transmitted to intermediate elements. Three
options can be followed to transmit Map-Request when going through
intermediate elements:
o Forwardable queries: when an intermediate element receives a Map-
Request, it transmits it as-is to another intermediate element
that, at its turn, transmits the Map-Request to another
intermediate element and so on until the Map-Request can be
transmitted to the server.
o Recursive queries: when an intermediate element receives a Map-
Request, it interprets the Map-Request and acts as a resolver. It
then generates a new Map-Request and sends it to another
intermediate element, and so on until the server is reached.
o Iterative queries: when an intermediate element receives a Map-
Request, it sends back the address of the next intermediate
element to the resolver. The resolver then sends the Map-Request
to this other intermediate element until a server is reached.
A mapping system working with forwardable queries can be seen as a
routing overlay. The intermediate elements are overlay routers that
forward Map-Request messages step by step on the overlay to reach a
server that can provide a mapping for the identifier in the Map-
Request. LISP+ALT [I-D.ietf-lisp-alt] is an example of such mapping
system.
The figure below presents an example of messages exchanged in LISP+
ALT. In LISP+ALT, the ITRs are at the same time the queriers and the
resolvers (an ITR is its own resolver). Labels postfixed by a ?
represent Map-Requests and those postfixed with a ! are the Map-
Replies. Intermediate elements are operated by ALT routers (depicted
as ALTx in the figure) and the server role is supported by the ETRs.
Saucez & Bonaventure Expires October 23, 2011 [Page 3]
Internet-Draft LISP Iterable Mappings April 2011
The figure shows that messages are sent step-by-step through the ALT
routers until an ETR that can return a mapping is reached. The ETR
directly returns the mapping to the ITR without traversing the ALT
routers. We can see that troubleshoot a problem occurring at an ALT
router is an issue for the ITR as it does not control the ALT routers
the Map-Request traverses. In addition, the ITRs do not even know
the ALT routers that are traversed.
e
+
1.(ITR, e)? 2.(ITR,e)? 3.(ITR,e)? +
ITR ---------------> ALT1 ----------------> ALT2 --------------->ETR --.
^ |
| 4.(R,e)! |
`<--------------------------------------------------------------------'
LEGEND: (x,e)?: Map-Request sent by x for EID e
(x,e)!: Map-Reply sent to x with the mapping for EID e
ALTx: ALT router
Figure 1: Example of message exchanged in a forwarding mode mapping
system: the LISP+ALT case
The operation of mapping systems working in recursive mode can be
abstracted as a directed graph of resolvers, each node being a
resolver for its predecessor. The figure below shows that when an
intermediate element receives a Map-Request, it originates a new Map-
Request for the same EID. When the server receives the request, it
replies to the intermediate element that, at its turn can return a
reply to the node that it receives a request from and so on until the
mapping arrives the resolver. In the figure, we omitted the
requester to start directly at the resolver (R).
e
+
1.(R,e)? 2.(I1,e)? 3.(I2,e)? +
R -------------> I1 --------------> I2 -------------> ETR --.
^ |^ |^ |
| 6.(R,e)! || 5.(I1,e)! || 4.(I2,e)! |
`<---------------'`<----------------'`<---------------------'
LEGEND: (x,e)?: Map-Request sent by x for EID e
(x,e)!: Map-Reply sent to x with the mapping for EID e
R: resolver
Ix: intermediate element x
Figure 2: Example of message exchanged in a recursive mapping system
Saucez & Bonaventure Expires October 23, 2011 [Page 4]
Internet-Draft LISP Iterable Mappings April 2011
In mapping systems operating in iterative mode, the intermediate
elements do not exchange requests among themselves. As presented in
the figure below, when an intermediate element receives a request, it
replies with the address of another intermediate element that can
potentially provide the mapping (labels postfixed with a @). When
the resolver receives this address, it sends it a Map-Request for the
identifier. This operation is repeated until a server is reached.
At a first glance, the iterative mode is the option that is likely to
present the longer delay. However, the resolver can cache the
intermediate elements and servers and for any subsequent Map-Request,
it can directly contact the server or intermediate element close to
the server.
.----. e
| | +
| \/ 1.(R,e)? +
| ,.R -------------> I1 I2 ETR-.
| |^|^ | ^| ^ |
| |||| 2(e,I2)@ | || | |
| |||`<--------------' 3.(R,e)? || | |
| ||`-----------------------------------'| | |
| || | | |
| || 4.(e,S)@ | | |
| |`<------------------------------------' 5.(R,e)? | |
| `------------------------------------------------------>' |
| |
| 6.(R,e)! |
`<-----------------------------------------------------------'
LEGEND: (x,e)?: Map-Request sent by x for EID e
(x,e)!: Map-Reply sent to x with the mapping for EID e
(e,x)@: the Map-Request for EID e has to be sent to x
R: resolver
Ix: intermediate element
Figure 3: Example of messages exchanged in an iterative mapping
system
An advantage of using the iterative mode is for the troubleshooting.
The figure below presents a case where the intermediate element I2 is
replicated with intermediate element I2'. The resolver first tries
to contact I2, but as no answer arrives within a given time frame, it
contacts the replicas I2' instead. Similar troubleshooting exists in
recursive mode but the recovery is done locally at the intermediate
element suppressing any control from the resolver. In forwarding
mode, and particularly in LISP+ALT, the troubleshooting is performed
locally but relies on the routing layer. Therefore, if an
Saucez & Bonaventure Expires October 23, 2011 [Page 5]
Internet-Draft LISP Iterable Mappings April 2011
intermediate element is overloaded but present on the network, i.e.,
the routing layer does not detect any failure, requests will continue
to be forwarded to the overloaded intermediate element.
.----. e
| | +
| \/ 1.(R,e)? +
| ,,.R ----------------> I1 I2 I2' ETR-.
| ||||^ | ^| | |
| ||||| 2(e,[I2,I2'])@ | X || | |
| ||||`<------------------' 3.(R,e)? | || | |
| |||`---------------------------------->' || | |
| ||| || | |
| ||| 4.(R,e)? || | |
| ||`---------------------------------------------->'| | |
| || | | |
| || 5.(e,S)@ | | |
| ||`<-----------------------------------------------' | |
| | | |
| | 6.(R,e)? | |
| `----------------------------------------------------->' |
| |
| 7.(R,e)! |
`<----------------------------------------------------------'
LEGEND: (x,e)?: Map-Request sent by x for EID e
(x,e)!: Map-Reply sent to x with the mapping for EID e
(e,[x,y])@: the Map-Request for EID e has to be sent to x or y
R: resolver
Ix: intermediate node
Figure 4: Intermediate node failure troubleshooting example with the
iterative mode
The analogy can be done with DNS that supports both iterative and
recursive modes. Experience with the DNS on the Internet showed that
using redundant servers coupled with iterative mode has been key in
handling various types of failures.
This memo presents the new Iterable-Mapping LISP message. We also
propose a one bit modification of the Map-Request for supporting the
iterative mode. Because of security and scalability issues, we do
not discuss the recursive mode even if it could be implemented by
using our solution.
Saucez & Bonaventure Expires October 23, 2011 [Page 6]
Internet-Draft LISP Iterable Mappings April 2011
2. Additional LISP Packet Type Allocation
Mappings, as defined in the LISP specifications [I-D.ietf-lisp],
associate locator lists to EID prefixes. To associate Map-Server
addresses to EID, we propose a new LISP control plane message: the
LISP Iterable-Mapping. We suggest the following type allocation:
LISP Iterable-Reply: 5 b'0101'
3. Extension to Map-Request Message Format
To support iterable mappings, we propose to add the I-bit flag in the
Map-Request message. When this bit is at 1, the ITR (or the Map-
Resolver) indicates that it accepts iterable mappings. If the I-bit
is at zero, the ITR (or the Map-Resolver) does not accept iterable
mappings meaning that the only acceptable answer to the request is a
Map-Reply.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Type=1 |A|M|P|S|I| Reserved | IRC | Record Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nonce . . . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . . . Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source-EID-AFI | Source EID Address ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ITR-RLOC-AFI 1 | ITR-RLOC Address 1 ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ITR-RLOC-AFI n | ITR-RLOC Address n ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ | Reserved | EID mask-len | EID-prefix-AFI |
Rec +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ | EID-prefix ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Map-Reply Record ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mapping Protocol Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Saucez & Bonaventure Expires October 23, 2011 [Page 7]
Internet-Draft LISP Iterable Mappings April 2011
4. Iterable-Mapping Message Format
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Type=5 | Reserved | Record Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nonce . . . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . . . Nonce |
+--> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Record TTL |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
R | Locator Count | EID mask-len | EID-AFI |
e +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
c | EID-prefix |
o +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
r L--| Unused Flags | Loc-AFI |
d o +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| c--| Locator |
+--> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5
Type: 5 (Iterable-Reply)
Reserved: Set to 0 on transmission and ignored on receipt.
Record Count: The number of records in this reply message. A
record is comprised of that portion of the packet labeled 'Record'
above and occurs the number of times equal to Record count.
Nonce: A 64-bit value from the Map-Request is echoed in this Nonce
field of the Map-Reply.
Record TTL: The time in minutes the recipient of the Iterable-
Mapping will store the mapping. If the TTL is 0, the entry SHOULD
be removed from the cache immediately. If the value is
0xffffffff, the recipient can decide locally how long to store the
mapping.
Locator Count: The number of Locator entries. A locator entry
comprises what is labeled above as 'Loc'. The locator count can
be 0 indicating there are no locators for the EID-prefix.
Locators are Map-Server addresses.
Saucez & Bonaventure Expires October 23, 2011 [Page 8]
Internet-Draft LISP Iterable Mappings April 2011
EID mask-len: Mask length for EID prefix.
EID-AFI: Address family of EID-prefix according to [RFC5226].
EID-prefix: 4 bytes if an IPv4 address-family, 16 bytes if an IPv6
address-family.
Loc-AFI: Address family of locator according to [RFC5226].
Locator: an IPv4 or IPv6 address (as encoded by the 'Loc-AFI'
field) assigned to a Map-Server.
5. Message Processing
When an ITR (or a Map-Resolver) needs to retrieve a Mapping for an
EID, it sends a Map-Request as specified in the LISP specifications
[I-D.ietf-lisp]. If the ITR (or Map-Resolver) desires to operate in
the iterable mode, it sends the Map-Request with the I-bit set to
one. When the Map-Request is processed, two possible replies are
possible, either a Map-Reply or an Iterable-Mapping. A Map-Reply is
returned if the node that processed the Map-Request has a mapping for
the EID in the Map-Request. If the node knows a list of Map-Servers
associated to the requested EID, an Iterable-Mapping is returned.
When an Iterable-Mapping arrives the ITR (or Map-Resolver), it
extracts one locator. The ITR (or Map-Resolver) then sends a Map-
Request to the selected Map-Server and follows the same procedure
until a Map-Reply is received. To speed-up further requests, the ITR
(or Map-Resolver) can cache the Iterable-Mappings. It is also
possible to imagine the ITR (or Map-Resolver) to send the Map-Request
to several Map-Server in parallel.
6. Map-Server Deployment and Adaptations
With the iterable mappings, it is no longer required to have an
overlay deployed to ensure the forwarding. Indeed, one could imagine
to have a hierarchy of Map-Server exclusively storing iterable
mappings that eventually point to ETRs. Such a general tree-based
deployment of EID is presented in LISP-TREE [lisptree]
Deploying a mapping system in iterative mode does not require to
maintain an overlay with its tunnels (e.g., GRE) and routing scheme
(e.g., BGP) making it more flexible, simple and cost effective than
LISP+ALT.
Saucez & Bonaventure Expires October 23, 2011 [Page 9]
Internet-Draft LISP Iterable Mappings April 2011
7. Security Considerations
An attacker controlling a Map-Server can provide an iterable mapping
pointing to a less specific EID that it should and thus control the
mapping to reply for EIDs it is not responsible for. This problem is
a variation of the same case for "normal" mappings. Globally, the
security issues are not different than those presented in
[I-D.saucez-lisp-security].
8. Conclusion
This draft presents the iterable mappings that, at the contrary of
"normal" mappings, do not point to ETR RLOCs but to Map-Server RLOCs.
The existence of such pointers to Map-Server permit to deploy mapping
system relying on iterative querying of Map-Requests. The iterative
way of querying the mapping system helps in troubleshooting mapping
system failures and can be used to optimize current mapping systems.
9. Acknowledgments
This work is partially funded by the European Commission funded ECODE
ICT- 223936 project.
10. Informative References
[I-D.ietf-lisp]
Farinacci, D., Fuller, V., Meyer, D., and D. Lewis,
"Locator/ID Separation Protocol (LISP)",
draft-ietf-lisp-08 (work in progress), August 2010.
[I-D.ietf-lisp-alt]
Fuller, V., Farinacci, D., Meyer, D., and D. Lewis, "LISP
Alternative Topology (LISP+ALT)", draft-ietf-lisp-alt-04
(work in progress), April 2010.
[I-D.ietf-lisp-ms]
Fuller, V. and D. Farinacci, "LISP Map Server",
draft-ietf-lisp-ms-05 (work in progress), April 2010.
[I-D.saucez-lisp-security]
Saucez, D., Iannone, L., and O. Bonaventure, "LISP
Security Threats", draft-saucez-lisp-security-02 (work in
progress), January 2011.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
Saucez & Bonaventure Expires October 23, 2011 [Page 10]
Internet-Draft LISP Iterable Mappings April 2011
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.
[lisptree]
Jakab, L., Cabellos-Aparicio, A., Coras, F., Saucez, D.,
and O. Bonaventure, "LISP-TREE: A DNS Hierarchy to Support
the LISP Mapping System.", JSAC 2010, October 2010.
Authors' Addresses
Damien Saucez
Universite catholique de Louvain
Place St. Barbe 2
Louvain-la-Neuve, B-1348
Belgium
Email: damien.saucez@uclouvain.be
URI: http://inl.info.ucl.ac.be
Olivier Bonaventure
Universite catholique de Louvain
Place St. Barbe 2
Louvain-la-Neuve, B-1348
Belgium
Email: olivier.bonaventure@uclouvain.be
URI: http://inl.info.ucl.ac.be
Saucez & Bonaventure Expires October 23, 2011 [Page 11]