One document matched: draft-zhao-lisp-mn-extension-02.xml
<?xml version="1.0" encoding="US-ASCII"?>
<?xml-stylesheet type="text/xsl" href="D:\draft\rfc2629xslt\rfc2629xslt\rfc2629.xslt"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<rfc category="info" docName="draft-zhao-lisp-mn-extension-02"
ipr="trust200902" obsoletes="" submissionType="independent" updates=""
xml:lang="en">
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<front>
<title abbrev="LISP Mobile Node extension">LISP Mobile Node
extension</title>
<author fullname="Ningxia Zhao" initials="Ningxia" surname="Zhao">
<organization>ZTE Corporation</organization>
<address>
<postal>
<street>4F,RD Building 2,Zijinghua Road No.68</street>
<region>Yuhuatai District,Nanjing 210012</region>
<country>P.R.China</country>
</postal>
<phone>+86-025-5287-7612</phone>
<email>zhao.ningxia@zte.com.cn</email>
</address>
</author>
<author fullname="Jiong Shen" initials="Jiong" surname="Shen">
<organization>ZTE Corporation</organization>
<address>
<postal>
<street>4F,RD Building 2,Zijinghua Road No.68</street>
<region>Yuhuatai District,Nanjing 210012</region>
<country>P.R.China</country>
</postal>
<phone>+86-025-5287-7612</phone>
<email>wang.jun17@zte.com.cn</email>
</address>
</author>
<author fullname="Mo Sun" initials="Mo" surname="Sun">
<organization>ZTE Corporation</organization>
<address>
<postal>
<street>C1-04,RD Building 1,Zijinghua Road No.68</street>
<region>Yuhuatai District,Nanjing 210012</region>
<country>P.R.China</country>
</postal>
<phone>+86-025-5287-2045</phone>
<email>meng.yu@zte.com.cn</email>
</address>
</author>
<date day="30" month="October" year="2011" />
<area>Standard</area>
<workgroup>PPSP Working Group</workgroup>
<keyword>Internet Draft</keyword>
<keyword>I-D</keyword>
<abstract>
<t>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.</t>
<t>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.</t>
</abstract>
</front>
<middle>
<section title="Introduction" toc="default">
<t>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.</t>
<t>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.</t>
<t><list style="symbols">
<t>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.</t>
<t>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.</t>
</list></t>
<t>This document specifies the LISP-MN extension operation, which
includes two aspects, the EID-to-RLOC Mapping Update Operation and the
Map-Unregister Operation.</t>
<t>Design goals for the LISP-MN extension design include:</t>
<t><list style="symbols">
<t>The LISP-MN extension design described in this document based on
the Lisp, this document does not change any contents of the
LISP.</t>
<t>The LISP-MN extension design described in this document uses
standard LISP functionality.</t>
<t>This document only do some extension of the lisp and only
introduces the contents the author think must be supplemented to the
lisp .</t>
<t>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 <xref target="LISP-INTERWORK"></xref>
infrastructures.</t>
</list></t>
</section>
<section title="new section">
<t></t>
</section>
<section title="Terminology" toc="default">
<t>This section defines the terms used in this document.</t>
<t>LISP Mobile Node (LISP-MN): A LISP capable fast roaming mobile
hand-set.</t>
<t>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.</t>
<t>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 <xref target="RFC1918"></xref>[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).</t>
<t>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.</t>
<t>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.</t>
<t>Map Unregister: A Map Unregister is the lisp-MN notifies the MS<xref
target="LISP-Map-Server"></xref> to unbind the EID-to-RLOC mapping when
the lisp-MN needn’t to attached to the network.</t>
</section>
<section title="LISP Extension Operation" toc="default">
<t>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.</t>
<section title=" EID-to-RLOC Mapping Update Operation">
<t>This section provides the EID-to-RLOC mapping update operation.</t>
<t>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 .</t>
</section>
<section title="Map-Unregister Operation">
<t>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.</t>
<t>The lisp-MN sends a map-unregister to its configured Map-Server(s)
to delete the EID-to-RLOC mapping stored in this MS.</t>
<t>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.</t>
<t>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.</t>
<t>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.</t>
<t>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.</t>
</section>
</section>
<section title="LISP Extension Message" toc="default">
<t></t>
<section title="LISP Packet Type Allocations">
<t>This section will be the authoritative source for allocating LISP
Type values. Current allocations are:</t>
<t><list style="symbols">
<t>LISP Map-Update: 5 b'0101'</t>
<t>LISP Map-Unregister: 6 b'0110'</t>
</list></t>
</section>
<section title="Map-Update Message Format">
<t>The Map-Update message format is:</t>
<figure anchor="service-discovery" title="Map-Update Message Format">
<artwork align="left"><![CDATA[
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>Packet field descriptions:</t>
<t>Type: 5 (Map-Update)</t>
<t>The Map-Update message has the same contents as a Map-Register
message. See Map-Register section in LISP <xref
target="LISP"></xref>for field descriptions.</t>
</section>
<section title="Map-Unregister Message Format">
<t>The Map-Unregister message format is:</t>
<t><figure align="center">
<artwork align="left" xml:space="preserve"><![CDATA[
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure> Packet field descriptions:</t>
<t>Type: 6 (Map-Unregister)</t>
<t>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.</t>
<t>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.</t>
<t>The other field of the Map-Unregister message just has the same
contents as a Map-Register message. See Map-Register section in LISP
<xref target="LISP"></xref> for field descriptions.</t>
</section>
</section>
<section title="Security Considerations" toc="default">
<t>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.</t>
</section>
<section title="IANA Considerations" toc="default">
<t>This document creates no new requirements on IANA namespaces .<xref
target="RFC5226"></xref></t>
</section>
<section title="Acknowledgments" toc="default">
<t>TBD</t>
<t></t>
</section>
</middle>
<back>
<references title="Normative References">
<reference anchor="RFC1918">
<front>
<title>Address Allocation for Private Internets</title>
<author initials="Y." surname="Rekhter">
<organization></organization>
</author>
<author initials="R." surname="Moskowitz">
<organization></organization>
<address>
<postal>
<street></street>
<city></city>
<region></region>
<code></code>
<country></country>
</postal>
<phone></phone>
<facsimile></facsimile>
<email></email>
<uri></uri>
</address>
</author>
<date year="1996" />
</front>
</reference>
<reference anchor="RFC5226">
<front>
<title>Guidelines for Writing an IANA Considerations Section in
RFCs</title>
<author initials="T." surname="Narten">
<organization></organization>
</author>
<author initials="H." surname="Alvestrand">
<organization></organization>
<address>
<postal>
<street></street>
<city></city>
<region></region>
<code></code>
<country></country>
</postal>
<phone></phone>
<facsimile></facsimile>
<email></email>
<uri></uri>
</address>
</author>
<date month="May" year="2008" />
</front>
</reference>
</references>
<references title="Informative References">
<reference anchor="LISP-Map-Server">
<front>
<title>LISP Map Server</title>
<author initials="D." surname="Farinacci"></author>
<author initials="V." surname="Fuller"></author>
<date month="June" year="2011" />
</front>
<seriesInfo name="draft-ietf-lisp-ms-08" value="work in progress" />
</reference>
<reference anchor="LISP-INTERWORK">
<front>
<title>Interworking LISP with IPv4 and IPv6</title>
<author initials="D." surname="Lewis">
<organization></organization>
</author>
<author initials="D." surname="Meyer">
<organization></organization>
<address>
<postal>
<street></street>
<city></city>
<region></region>
<code></code>
<country></country>
</postal>
<phone></phone>
<facsimile></facsimile>
<email></email>
<uri></uri>
</address>
</author>
<author initials="D." surname="Farinacci">
<organization></organization>
<address>
<postal>
<street></street>
<city></city>
<region></region>
<code></code>
<country></country>
</postal>
<phone></phone>
<facsimile></facsimile>
<email></email>
<uri></uri>
</address>
</author>
<author initials="V." surname="Fuller">
<organization></organization>
<address>
<postal>
<street></street>
<city></city>
<region></region>
<code></code>
<country></country>
</postal>
<phone></phone>
<facsimile></facsimile>
<email></email>
<uri></uri>
</address>
</author>
<date month="March" year="2011" />
</front>
</reference>
<reference anchor="LISP">
<front>
<title>Locator/ID Separation Protocol (LISP)</title>
<author initials="D." surname="Farinacci">
<organization></organization>
</author>
<author initials="V." surname="Fuller">
<organization></organization>
<address>
<postal>
<street></street>
<city></city>
<region></region>
<code></code>
<country></country>
</postal>
<phone></phone>
<facsimile></facsimile>
<email></email>
<uri></uri>
</address>
</author>
<author initials="D." surname="Meyer">
<organization></organization>
<address>
<postal>
<street></street>
<city></city>
<region></region>
<code></code>
<country></country>
</postal>
<phone></phone>
<facsimile></facsimile>
<email></email>
<uri></uri>
</address>
</author>
<author initials="D." surname="Lewis">
<organization></organization>
<address>
<postal>
<street></street>
<city></city>
<region></region>
<code></code>
<country></country>
</postal>
<phone></phone>
<facsimile></facsimile>
<email></email>
<uri></uri>
</address>
</author>
<date month="April" year="2011" />
</front>
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 08:48:37 |