Internet DRAFT - draft-zhao-lisp-mn-extension
draft-zhao-lisp-mn-extension
PPSP Working Group Ningxia. Zhao
Internet-Draft Jiong. Shen
Intended status: Informational Mo. Sun
Expires: May 2, 2012 ZTE Corporation
October 30, 2011
LISP Mobile Node extension
draft-zhao-lisp-mn-extension-02
Abstract
LISP describes a network-based protocol that enables separation of IP
addresses into two new numbering spaces: Endpoint Identifiers (EIDs)
and Routing Locators (RLOCs). No changes are required to either host
protocol stacks or to the "core" of the Internet infrastructure. The
LISP Mobile Node extension design described in this document uses
standard LISP functionality to provide scalable mobility for LISP
mobile nodes.
This document extends the lisp, it introduces some contents that lisp
does not include but the author think it is important and
recommendation them to be considered in the lisp.
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 May 2, 2012.
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
Zhao, et al. Expires May 2, 2012 [Page 1]
Internet-Draft LISP Mobile Node extension October 2011
(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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. new section . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. LISP Extension Operation . . . . . . . . . . . . . . . . . . . 7
4.1. EID-to-RLOC Mapping Update Operation . . . . . . . . . . . 7
4.2. Map-Unregister Operation . . . . . . . . . . . . . . . . . 7
5. LISP Extension Message . . . . . . . . . . . . . . . . . . . . 9
5.1. LISP Packet Type Allocations . . . . . . . . . . . . . . . 9
5.2. Map-Update Message Format . . . . . . . . . . . . . . . . 9
5.3. Map-Unregister Message Format . . . . . . . . . . . . . . 10
6. Security Considerations . . . . . . . . . . . . . . . . . . . 12
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
9.1. Normative References . . . . . . . . . . . . . . . . . . . 15
9.2. Informative References . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
Zhao, et al. Expires May 2, 2012 [Page 2]
Internet-Draft LISP Mobile Node extension October 2011
1. Introduction
LISP defines protocol mechanisms for mapping from EIDs to RLOCs, the
lisp-MN specifies the behavior of the LISP Mobile Node, it has
introduced some aspects of lisp-MN, but there are some other
important areas have not considered.
The LISP Mobile Node extension design described in this document uses
standard LISP functionality to provide scalable mobility for the
mobile node in the LISP site.
o The EID-to-RLOC mapping update operation has not be considered.
When a MN in the LISP site roams onto a new network, it receives a
new RLOC, the lisp-MN Map-Registers it's new RLOC to its
configured Map-Server, then the lisp-MN sends packet to its peer
side by the new RLOC. But before the peer side receives the
packet the lisp-MN sent, the peer side will send packet to lisp-MN
by the old RLOC or the peer side must query the MS to obtain the
lisp-MN's RLOC and then the peer side updates its cache of the
EID-to-RLOC mapping and send packet by the new RLOC, this will
cause a problem, the packet the lisp-MN to receive from its peer
side will be missed or delayed when the LISP-MN roams onto a new
network. So how to update the previous EID-to-RLOC mapping cached
in the lisp-MN's peer side must be considered.
o The deregister has not be considered. When a MN in the lisp site
is shutdown or the user initiates to interrupt the network
connection or the contract is limited, the lisp-MN needn't
continue attach to the network, the lisp-MN or the network will
initiate the process of the Map-Unregister.
This document specifies the LISP-MN extension operation, which
includes two aspects, the EID-to-RLOC Mapping Update Operation and
the Map-Unregister Operation.
Design goals for the LISP-MN extension design include:
o The LISP-MN extension design described in this document based on
the Lisp, this document does not change any contents of the LISP.
o The LISP-MN extension design described in this document uses
standard LISP functionality.
o This document only do some extension of the lisp and only
introduces the contents the author think must be supplemented to
the lisp .
Zhao, et al. Expires May 2, 2012 [Page 3]
Internet-Draft LISP Mobile Node extension October 2011
o The LISP-MN extension design is built from the existing LISP
components: the MN in lisp site, its corresponding side in
communication , the existing Map-Server [LISP-MS] and the
Interworking [LISP-INTERWORK] infrastructures.
Zhao, et al. Expires May 2, 2012 [Page 4]
Internet-Draft LISP Mobile Node extension October 2011
2. new section
Zhao, et al. Expires May 2, 2012 [Page 5]
Internet-Draft LISP Mobile Node extension October 2011
3. Terminology
This section defines the terms used in this document.
LISP Mobile Node (LISP-MN): A LISP capable fast roaming mobile hand-
set.
Endpoint ID (EID): This is the traditional LISP EID [LISP], and is
the address that a LISP mobile node uses as its address for transport
connections. A LISP mobile node never changes its EID, which is
typically a /32 or /128 prefix and is assigned to a loopback
interface. Note that the mobile node can have multiple EIDs, and
these EIDs can be from different address families.
Routing Locator (RLOC): This is the traditional LISP RLOC, and is in
general a routable address that can be used to reach a mobile node.
Note that there are cases in which an mobile node may receive an
address that it thinks is an RLOC (perhaps via DHCP) which is either
an EID or an RFC 1918 address [RFC1918][RFC1918]. This could happen
if, for example, if the mobile node roams into a LISP domain or a
domain behind a Network Address Translator (NAT).
Map-cache: A data structure which contains an EID-prefix, its
associated RLOCs, and the associated policy. Map-caches are
typically found in ITRs and PITRs.
Map Update: A Map update is the lisp-MN notifies the correspondent to
change the EID-to-RLOC mapping when the lisp-MN move to another
location in the communication process.
Map Unregister: A Map Unregister is the lisp-MN notifies the
MS[LISP-Map-Server] to unbind the EID-to-RLOC mapping when the
lisp-MN needn't to attached to the network.
Zhao, et al. Expires May 2, 2012 [Page 6]
Internet-Draft LISP Mobile Node extension October 2011
4. LISP Extension Operation
The LISP Extension Operation described in this document uses the ETR/
ITR or theLISP-MN to provide scalable fast mobility and the Map-
Unregister operation.
4.1. EID-to-RLOC Mapping Update Operation
This section provides the EID-to-RLOC mapping update operation.
After a roaming event, a LISP-MN must immediately register its new
EID-to-RLOC mapping with its configured Map-Server(s). In addition,
the Lisp-MN sends the EID-to-RLOC mapping update request to its peer
side to inform the peer side the LISP-MN which is ongoing
communication has moved to a new location and the Lisp-MN has
received a new RLOC, the EID-to-RLOC mapping update request message
carries the EID and the new RLOC of the Lisp-MN. After received the
EID-to-RLOC mapping update request, the peer side updates the EID-to-
RLOC mapping cached in its local, that is in the local cache use the
new RLOC instead of the old RLOC in the EID-to-RLOC mapping, then the
peer side returns he EID-to-RLOC mapping update response (Update
Response) message to the lisp-MN. The EID-to-RLOC mapping update
operation improves the efficiency of data transmission and decreases
the occurrence of packet latency and packet loss when a roaming event
occurs in communication .
4.2. Map-Unregister Operation
When the MN in a lisp site is shutdown or the user initiates to
interrupt the network connection, the MN needn't continue register to
the network, the lisp-MN will initiate the process of the Map-
Unregister.
The lisp-MN sends a map-unregister to its configured Map-Server(s) to
delete the EID-to-RLOC mapping stored in this MS.
After received the Map-Unregister Request, the MS removes the EID-to-
RLOC mapping stored in it and sends the Map-Unregister response to
the lisp-MN, the message in this process carries the instructions
indicates the success or failure of the Map-Unregister operation.
The Map-Unregister process is completed.
The Map-Unregister Operation also inclueds another scenario, when the
lisp network detects the contact of the host is limited (how does the
network detect the contact of the host is limited is out of this
scope), the network will initiate the process of the Map-Unregister.
When the lisp network detects the contact of the host is limited, the
Zhao, et al. Expires May 2, 2012 [Page 7]
Internet-Draft LISP Mobile Node extension October 2011
network side informs the MS the host be listed in the black. Then
the MS removes the EID-to-RLOC mapping stored in it and sends a map-
unregister to the ETR and the ITR which communications with the
host， The MS can inform the ITR based on which has queried the
MS for the EID-to-RLOC mapping of the host and TTL has not expired.
After received the Map-Unregister Request, the ITR removes the EID-
to-RLOC mapping stored in its cache and sends the Map-Unregister
response to the MS, the ETR sets rules to prevent the flow to and
from the black host according to EID of the black host and sends the
Map-Unregister response to the MS.The Map-Unregister process is
completed.
Zhao, et al. Expires May 2, 2012 [Page 8]
Internet-Draft LISP Mobile Node extension October 2011
5. LISP Extension Message
5.1. LISP Packet Type Allocations
This section will be the authoritative source for allocating LISP
Type values. Current allocations are:
o LISP Map-Update: 5 b'0101'
o LISP Map-Unregister: 6 b'0110'
5.2. Map-Update Message Format
The Map-Update message format is:
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 |P| Reserved | Record Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nonce . . . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . . . Nonce |
+-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Record TTL |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
R | Locator Count | EID mask-len | ACT |A| Reserved |
e +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
c | Rsvd | Map-Version Number | EID-prefix-AFI |
o +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
r | EID-prefix |
d +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| /| Priority | Weight | M Priority | M Weight |
| L +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| o | Unused Flags |L|p|R| Loc-AFI |
| c +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| \| Locator |
+-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mapping Protocol Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Map-Update Message Format
Packet field descriptions:
Type: 5 (Map-Update)
Zhao, et al. Expires May 2, 2012 [Page 9]
Internet-Draft LISP Mobile Node extension October 2011
The Map-Update message has the same contents as a Map-Register
message. See Map-Register section in LISP [LISP]for field
descriptions.
5.3. Map-Unregister Message Format
The Map-Unregister message format is:
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=6 |P| Reserved | Record Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nonce . . . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . . . Nonce |
+-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Record TTL |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
R | Locator Count | EID mask-len | ACT |A| Reserved |
e +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
c | Rsvd | Map-Version Number | EID-prefix-AFI |
o +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
r | EID-prefix |
d +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| /| Priority | Weight | M Priority | M Weight |
| L +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| o | Unused Flags |L|p|R| Loc-AFI |
| c +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| \| Locator |
+-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mapping Protocol Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Packet field descriptions:
Type: 6 (Map-Unregister)
The EID-prefix in this message including the length is zero and the
length in non-zero, when the length is zero, the EID-prefix just
equal to the EID.
Because one EID maybe mapping to multiple RLOCs, so the Map-
Unregister operation including two cases. One case is to remove all
the RLOC mapping to the EID when the Map-Unregister occurs, this time
the Map-Unregister Message Format does not contain the field of the
Zhao, et al. Expires May 2, 2012 [Page 10]
Internet-Draft LISP Mobile Node extension October 2011
Locator. The second case is only remove one specific RLOC mapping to
the EID when the Map-Unregister occurs, this time the Map-Unregister
Message Format just contains the field of the Locator which must be
canceled.
The other field of the Map-Unregister message just has the same
contents as a Map-Register message. See Map-Register section in LISP
[LISP] for field descriptions.
Zhao, et al. Expires May 2, 2012 [Page 11]
Internet-Draft LISP Mobile Node extension October 2011
6. Security Considerations
Security for the LISP-MN design builds upon the security fundamentals
found in LISP [LISP] for data-plane security and the LISP Map Server
[LISP-MS] registration security. Security issues unique to the
LISP-MN design are considered below.
Zhao, et al. Expires May 2, 2012 [Page 12]
Internet-Draft LISP Mobile Node extension October 2011
7. IANA Considerations
This document creates no new requirements on IANA namespaces
.[RFC5226]
Zhao, et al. Expires May 2, 2012 [Page 13]
Internet-Draft LISP Mobile Node extension October 2011
8. Acknowledgments
TBD
Zhao, et al. Expires May 2, 2012 [Page 14]
Internet-Draft LISP Mobile Node extension October 2011
9. References
9.1. Normative References
[RFC1918] Rekhter, Y. and R. Moskowitz, "Address Allocation for
Private Internets", 1996.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", May 2008.
9.2. Informative References
[LISP] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis,
"Locator/ID Separation Protocol (LISP)", April 2011.
[LISP-INTERWORK]
Lewis, D., Meyer, D., Farinacci, D., and V. Fuller,
"Interworking LISP with IPv4 and IPv6", March 2011.
[LISP-Map-Server]
Farinacci, D. and V. Fuller, "LISP Map Server",
draft-ietf-lisp-ms-08 work in progress, June 2011.
Zhao, et al. Expires May 2, 2012 [Page 15]
Internet-Draft LISP Mobile Node extension October 2011
Authors' Addresses
Ningxia Zhao
ZTE Corporation
4F,RD Building 2,Zijinghua Road No.68
Yuhuatai District,Nanjing 210012
P.R.China
Phone: +86-025-5287-7612
Email: zhao.ningxia@zte.com.cn
Jiong Shen
ZTE Corporation
4F,RD Building 2,Zijinghua Road No.68
Yuhuatai District,Nanjing 210012
P.R.China
Phone: +86-025-5287-7612
Email: wang.jun17@zte.com.cn
Mo Sun
ZTE Corporation
C1-04,RD Building 1,Zijinghua Road No.68
Yuhuatai District,Nanjing 210012
P.R.China
Phone: +86-025-5287-2045
Email: meng.yu@zte.com.cn
Zhao, et al. Expires May 2, 2012 [Page 16]
