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 03, 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 (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
• 2. new section
• 3. Terminology
• 4. LISP Extension Operation
• 4.1. EID-to-RLOC Mapping Update Operation
• 4.2. Map-Unregister Operation
• 5. LISP Extension Message
• 5.1. LISP Packet Type Allocations
• 5.2. Map-Update Message Format
• 5.3. Map-Unregister Message Format
• 6. Security Considerations
• 7. IANA Considerations
• 8. Acknowledgments
• 9. References
• 9.1. Normative References
• 9.2. Informative References
• Authors' Addresses

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.

• 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.
• 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:

• The LISP-MN extension design described in this document based on the Lisp, this document does not change any contents of the LISP.
• The LISP-MN extension design described in this document uses standard LISP functionality.
• This document only do some extension of the lisp and only introduces the contents the author think must be supplemented to the lisp .
• 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.

2. new section

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.

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 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.

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:

• LISP Map-Update: 5 b'0101'
• 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                     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Packet field descriptions:

Type: 5 (Map-Update)

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                     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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 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.

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.

7. IANA Considerations

This document creates no new requirements on IANA namespaces .[RFC5226]

8. Acknowledgments

TBD

9. References

9.1. Normative References

9.2. Informative References

Authors' Addresses