Internet DRAFT - draft-ietf-mobileip-vip
draft-ietf-mobileip-vip
Internet Engineering Task Force Fumio Teraoka
INTERNET-DRAFT SonyCSL
Keisuke Uehara
University of Electro-Comm.
July 1993
The Virtual Network Protocol for Host Mobility
Status of this Memo
This document is an Internet Draft. Internet Drafts are working
documents of the Internet Engineering Task Force (IETF), its Areas,
and its Working Groups. Note that other groups may also distribute
working documents as Internet Drafts.
Internet Drafts are draft documents valid for a maximum of six
months. Internet Drafts may be updated, replaced, or obsoleted by
other documents at any time. It is not appropriate to use Internet
Drafts as reference material or to cite them other than as a
``working draft'' or ``work in progress.''
This document has been presented to, and is being evaluated by,
the "Mobile IP" working group of the IETF. This document is being
published as an Internet Draft in order to allow the general IETF
community the opportunity to gain a wider understanding of the issues
involved in mobile IP routing, as well as to understand the specific
solution proposed in this document. This document has not received
any formal endorsement from the Mobile IP working group.
Abstract
This memo describes the general virtual network protocol that
provides the transport layer with host migration transparency. This
protocol is based on the concept of a `virtual network' and the
`propagating cache method'[1]. Basically, this protocol can be
applied to any connectionless network layer protocol. This memo also
describes two virtual network protocols: `VIP' (Virtual Internet
Protocol) and `ISO-VIP'. The former is derived from IP, the network
layer protocol of Internet, while the latter is derived from CLNP,
the connectionless-mode network layer protocol of ISO.
1. Overview of the Protocol
Host migration transparency can be defined as an environment in
Expires: January 1994 [Page 1]
INTERNET-DRAFT VIP July 1993
which a user is unaware of physical migration of hosts, or an
application program is unaware of physical migration of its peers.
According to the protocol layering based on the OSI reference model,
the network layer should provide host migration transparency. There
are two key services in the network layer for host migration
transparency: `migration transparent host addressing' and `migration
transparent connectionless-mode communication'[1]. The `concept of a
virtual network' was introduced to provide the former, while the
`propagating cache method' was proposed to achieve the latter.
According to the virtual network concept, each host is logically
connected to the same virtual network called the `home network' even
if it physically moves. Therefore, each host has an immutable
network address, which can be thought of as a `host identifier'.
Such addresses are called `virtual network addresses' or `VN-
addresses'. Since the network layer provides the transport layer
with VN-addresses, host migration becomes transparent to transport
and higher layers.
To deliver packets, a host must have another network address
which indicates physical location of the host. Such addresses are
called `physical network addresses' or `PN-addresses'. Since the
transport layer specifies hosts by their VN-addresses, the network
layer must resolve VN-addresses into corresponding PN-addresses. To
incorporate the function for such address resolution in the OSI
reference model, the network layer is divided into two sublayers: the
`virtual network sublayer' (VN-sublayer) and the `physical network
sublayer' (PN-sublayer). The VN-sublayer resolves VN-addresses into
PN-addresses, and then the PN-sublayer delivers packets by using PN-
addresses.
The VN-sublayer employs the `propagating cache method' for
efficient address resolution. In this method, each host/router has a
cache called the `Address Mapping Table (AMT)' to store the relation
between VN-addresses and PN-addresses. When a host/router receives a
packet, it caches the relation between the VN/PN-addresses into its
AMT. Upon transmission, the source host specifies the VN-address of
the destination host as the destination PN-address if it has no AMT
entry for the destination host. Such a packet heads for the home
network of the destination host and address resolution is executed by
either an intermediate router or a router in the home network of the
destination host. Once this source host receives a reply packet from
the destination host, it creates the AMT entry for the destination
host and it can execute address resolution at the next transmission
time.
Expires: January 1994 [Page 2]
INTERNET-DRAFT VIP July 1993
2. Terminology
In this memo, the following terms are used.
o virtual network addresses (VN-addresses): migration independent
host identifiers in the network layer. Each host has a VN-
address. Transport and higher layers use VN-addresses to
specify hosts. Since VN-addresses are immutable, transport and
higher layers can indicate mobile hosts no matter where they
are connected.
o physical network addresses (PN-addresses): migration dependent
host identifiers indicating host location. The PN-address of a
mobile host may change in compliance with host's location. In
other words, when a host moves, it must be assigned a temporary
PN-address by a certain mechanism such as DHCP[2] in IP
networks and the extended ES-IS protocol[3] in CLNP networks.
o home network: the subnetwork indicated by the VN-address of a
mobile host.
o address mapping table (AMT): a table held at each host or
router in the network. An AMT consists of entries, each of
which holds the relation between a VN-address and a PN-address
of a mobile host. There are two types of AMT entries:
- home AMT entries: AMT entries that are created in the home
network of a mobile host.
- cache AMT entries: AMT entries that are created in the
subnetworks other than the home network of a mobile host.
o address resolution: processing in which a VN-address is
resolved into the corresponding PN-address with the assistance
of an AMT.
o address resolver: a router that executes address resolution.
Address resolvers are classified into three types:
- primary address resolver (for a mobile host): an address
resolver that is connected to the home network of the mobile
host. A primary resolver advertises the reachability to the
mobile hosts. All primary resolvers for the mobile host
always hold its most recent AMT entry unless errors such as
network partitioning occur in the network.
- secondary address resolver (for a mobile host): an address
resolver that is connected to a subnetwork other than the
Expires: January 1994 [Page 3]
INTERNET-DRAFT VIP July 1993
home network of the mobile host. Secondary resolvers may
hold the most recent AMT entry for the host.
- temporary proxy (for a mobile host): secondary address
resolvers in the subnetwork to which the mobile host was
previously connected. A temporary proxy holds the most
recent AMT entry for the mobile host until the entry times
out unless errors occur in the network.
o family hosts (for an address resolver): hosts for which an
address resolver is a primary address resolver.
o foreign hosts (for an address resolver): hosts for which an
address resolver is not a primary address resolver.
3. The General Virtual Network Protocol
This section defines the general `virtual network protocol (VN-
protocol)' to support host mobility, which is basically applicable to
any connectionless-mode network protocol.
3.1. Packet Headers
There are two types of packet header formats, the data packet
and the control packet. The header of the data packet consists of
ten fields as follows:
o flags:
- control/data = data
- authentication: if this flag is on, this packet has
authentication data.
- address resolution only at primary: if this flag is on, only
primary resolvers for the destination host execute address
resolution.
- AMT update only at primary: if this flag is on, only primary
resolvers for the source host create or update its AMT
entry.
o source VN-address, PN-address, and address pair version number
o destination VN-address, PN-address, and address pair version
number
o holding time: the initial value of the holding time field of an
Expires: January 1994 [Page 4]
INTERNET-DRAFT VIP July 1993
AMT entry when it is created or updated by this packet.
o resolver PN-address: the PN-address of the address resolver
that executed address resolution.
o (option) authentication data
The header of the control packet consists of ten fields as
follows:
o flags:
- control/data = control
- authentication: if this flag is on, this packet has
authentication data.
- AMT update only at primary: if this flag is on, only primary
resolvers for the target system update the AMT entry.
- AMT entry creation/invalidation (CAmt/InvAmt): this flag
specifies the type of AMT entry manipulation, i.e.
creation/update (CAmt) or invalidation (InvAmt).
- broadcast InvAmt: if this flag is on, when a router has an
obsolete AMT entry, it broadcast an `InvAmt' packet to all
the subnetworks to which it is connected.
o source VN-address, PN-address, and address version number
o destination PN-address
o target system VN-address, PN-address, address version number,
and holding time
o (option) authentication data
3.2. AMT Entry
A general AMT entry consists of five fields as follows:
o VN-address: the key of this entry.
o PN-address: the requested value.
o address version number: the version number of the VN-
address/PN-address pair of this entry.
Expires: January 1994 [Page 5]
INTERNET-DRAFT VIP July 1993
o flags:
- use/free: the entry is in use or free.
- valid/invalid: the entry holds valid information or invalid
information.
- home/cache: the entry is a home AMT entry or a cache AMT
entry.
- local/not-local: the mobile host indicated by this entry is
connected to the same segment or not.
o holding time: the value of this field is decremented by one for
a certain time interval. When the value becomes zero, this
entry is deleted.
An AMT entry has one of three states: `free', `valid', or
`invalid'. In the `free' state, an AMT entry is not allocated to any
mobile host. In the `valid' state, when a router relays a packet
having older destination address information than this AMT entry, it
executes address resolution for the destination host. In the
`invalid' state, when a system receives a packet having older
destination address information than this AMT entry, it transmits an
`InvAmt' packet to the host specified by the resolver PN-address
field or the target system PN-address field of the packet. Figure 1
shows the state transition diagram of an AMT entry.
Expires: January 1994 [Page 6]
INTERNET-DRAFT VIP July 1993
receive CAmt +---------+
or data packet| |
+----------| Free |
| +------->| |<--------+
| | +---------+ |
| | | time out
| | time out |
| | | receive old data packet
V | receive new CAmt or | -----------------------
+---------+ new data packet +---------+ send InvAmt
| |<--------------------| |<--+
| Valid | | Invalid | |
| |-------------------->| |---+
+---------+ receive new InvAmt +---------+
| ^ | ^
| | | |
+-----+ +-----+
receive CAmt or receive old CAmt or
data packet InvAmt
Figure 1: AMT entry state transition diagram
+--------------+ <PR> primary
| home network | resolver
CAmt | | CAmt
(3)+--------|---- <PR> <---|-------+ <SR> secondary
| +--------------+ | resolver
InvAmt| InvAmt InvAmt | InvAmt
<-----<SR>----->(4) (2)<----<SR>----> <TP> temporary
| | proxy
| |(1) (secondary
+---------V--------+ move +--------|--------+ resolver)
| <TP> - -|- - - - - - -|- - > <MH> |
| | | | <MH> mobile
| previous network | | current network | host
+------------------+ +-----------------+
Figure 2: Host connection
3.3. Host Migration
Figure 2 depicts a packet flow when a mobile host is connected
to a subnetwork.
1. The mobile host transmits a `CAmt' packet to its home network.
On the transmission path of this `CAmt' packet, intermediate
routers create or update the AMT entry for the mobile host
Expires: January 1994 [Page 7]
INTERNET-DRAFT VIP July 1993
unless the flags field of the `CAmt' packet prohibits caching,
i.e. such intermediate routers become secondary address
resolver for the mobile host. During connecting to a
subnetwork, the mobile host continues to transmit a `CAmt'
packet for a certain time interval.
2. If an intermediate router holds an obsolete AMT entry for the
mobile host and the flags field of the `CAmt' packet indicates
`broadcast InvAmt', it broadcasts an `InvAmt' packet to all
the subnetworks to which the router is connected in order to
invalidate obsolete entries which might remain on other
routers. When a router receives such an `InvAmt' packet, if
it holds an obsolete AMT entry, it invalidates the entry and
also broadcasts the `InvAmt' packet. If it holds a newer AMT
entry or does not have the corresponding entry, it discards
the `InvAmt' packet.
3. When a primary address resolver for the mobile host receives
this `CAmt' packet, it also creates or updates the AMT entry
for the mobile host. If it holds an obsolete AMT entry for
the mobile host, it transmits another `CAmt' packet to the
network specified by the obsolete AMT entry. After routers in
the previous network receive this `CAmt' packet, they hold the
most recent AMT entry for the mobile host until it times out,
i.e. each router in the previous subnetwork becomes a
`temporary proxy' for the mobile host.
4. On the path of the `CAmt' packet transmitted by a primary
address resolver, intermediate routers create or update the
AMT entry for the mobile host unless the flags field of the
`CAmt' packet prohibits caching, i.e. they become secondary
address resolvers for the mobile host. If a router holds an
obsolete AMT entry for the mobile host and the flags field of
the `CAmt' packet indicates `broadcast InvAmt', the router
broadcasts an `InvAmt' packet to all the subnetworks to which
the router is connected in order to invalidate obsolete AMT
entries which might remain on other routers.
Figure 3 depicts a packet flow when a mobile host disconnects
from a subnetwork or is powered off.
1. The mobile host may transmit an `InvAmt' packet to its home
network.
2. On the path of the `InvAmt' packet, if an intermediate router
has an obsolete AMT entry for the mobile host and the flags
field of the `InvAmt' packet indicates `broadcast InvAmt', the
Expires: January 1994 [Page 8]
INTERNET-DRAFT VIP July 1993
router broadcasts another `InvAmt' packet to all the
subnetworks to which it is connected.
3. When a primary address resolver for the mobile host receives
the `InvAmt' packet, if it has an obsolete AMT entry for the
host and the flags field of the `InvAmt' packet indicates
`broadcast InvAmt', the primary address resolver broadcasts
another `InvAmt' packet to all the subnetworks to which it is
connected.
^ ^ ^ <PR> primary
(1)|disconnect or | | resolver
power off |InvAmt (3)|InvAmt
+--------|--------+ | +------|-------+ <SR> secondary
| <MH> -----|-----<SR>-----|---> <PR> --->| resolver
| InvAmt| |Inv | |InvAmt |
| | (2)| Amt | V | <MH> mobile
| current network | V | home network | host
+-----------------+ +--------------+
Figure 3: Host disconnection or power off
+--------------+ <PR> primary
| home network | resolver
| |
+----------|-----<PR> | <SR> secondary
| +------^-------+ resolver
| |
| +--<SR> | <TP> temporary
+---|-----+ | | | +----------+ proxy
| v | V | | | |
| <MH> <--|---+----------------|----+ | <OR> obsolete
| | ^ | | | | | AMT entry
| current | | | | <OR>--|-> <TP> |
| network | | | | | | | <S> source
+---------+ <S> <S> <S> <S> | previous | host
(a) (b) (c) (d) | network |
+----------+
Figure 4: Data communication
3.4. Data Communication
Figure 4 depicts four types of packet flows for data
communication.
Expires: January 1994 [Page 9]
INTERNET-DRAFT VIP July 1993
(a) If the source host has the AMT entry for the destination host,
it executes address resolution at transmission time. The
packet will traverse the optimal route.
(b) If the source host does not have the AMT entry for the
destination host, it sets the VN-address of the destination
host to the destination PN-address field. The packet heads
for the home network of the destination host. If an
intermediate router holds an AMT entry for the destination
host, it executes address resolution and forwards the packet.
(c) A primary address resolver ultimately receives the packet
heading for the home network of the destination host. When it
receives the packet, it executes address resolution and
forwards the packet.
(d) A router which holds an obsolete AMT entry for the destination
host executes address resolution for the packet heading for
the home network of the destination host. The packet is
forwarded to the previous network of the destination host. A
temporary proxy of the destination host in the previous
network executes address resolution and forwards the packet to
the correct location. Since the packet holds the PN-address
of the address resolver that executed incorrect address
resolution, the temporary proxy transmits an `InvAmt' packet
to it in order to invalidate the obsolete AMT entry.
When the source host receives a reply packet from the
destination host, it creates or updates the AMT entry for the
destination host. Therefore, the source host can hereafter execute
address resolution at transmission time.
3.5. Packet Conversion
If a host does not have the functions for the VN-protocol, it
transmits conventional network layer packets. When a router relays
such a packet, if it has the AMT entry for the destination host of
the packet, it converts the packet into a VN-protocol packet and
forwards it. In the worst case, such a packet reaches a primary
address resolver for the destination host and is converted into a
VN-protocol packet. When such a host receives a VN-protocol packet,
although it will ignore the header of the VN-sublayer, it correctly
recognizes the VN-address of the source host.
4. VIP: Virtual Internet Protocol
VIP (Virtual Internet Protocol) is derived from IP by applying
Expires: January 1994 [Page 10]
INTERNET-DRAFT VIP July 1993
the general VN-protocol defined in Section 3. `VIP addresses' are
introduced as VN-addresses in the VN-protocol, while IP addresses are
thought of as PN-addresses. The IP option fields of the IP header is
used for the VIP header. The size of the VIP header is 28 octets if
authentication data is not included. Table 1 shows the
correspondence of the VN-protocol to VIP. Figures 5-(a), 5-(b), and
6 depict the packet formats of VIP and the format of an AMT entry for
VIP respectively. In Figure 5-(a) and 5-(b), the beginning 20 octets
indicate the IP header and the remaining octets are the VIP header as
an IP option. Note that the IP header includes the source `VIP'
address and the VIP header includes the source `IP' address.
Table 1:Correspondence of the VN-protocol to VIP
VN-protocol | VIP
------------------|--------------------------------------------------
VN-address | VIP address
|
PN-address | IP address
|
home network | the subnetwork indicated by the network number
| of the VIP address
|
primary address | routers connected to the home network of a mobile
resolvers | host
|
secondary address | routers connected to the subnetworks other than
resolvers | the home network of a mobile host
|
temporary proxy | routers connected to the previous network of a
| mobile host
Expires: January 1994 [Page 11]
INTERNET-DRAFT VIP July 1993
0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ver. | IHL | TOS | Total Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identification |Flags| Fragment Offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TTL | Protocol | Header Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source VIP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Option Length | Ver. |unused | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination VIP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Address Version |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Address Version |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Holding Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Resolving System IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authentication Data |
= =
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5-(a): Data packet
Expires: January 1994 [Page 12]
INTERNET-DRAFT VIP July 1993
0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ver. | IHL | TOS | Total Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identification |Flags| Fragment Offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TTL | Protocol | Header Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source VIP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Option Length | Ver. |unused | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Address Version |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Target System VIP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Target System IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Target System Address Version |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Target System Holding Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authentication Data |
= =
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5-(b): Control packet header
Expires: January 1994 [Page 13]
INTERNET-DRAFT VIP July 1993
0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VIP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Version |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| | | +-- use(1)/free(0)
| | +---- valid(1)/invalid(0)
| +------ home(1)/not-home(0)
+-------- local(1)/not-local(0)
Figure 6: AMT entry for VIP
Figure 7 shows a packet flow when a host is connected to a
subnetwork. The differences between the packet flow in the VN-
protocol and VIP are:
o when a primary address resolver receives a `CAmt' packet from a
family host, it broadcasts another `CAmt' packet in the home
network in order to update the AMT entry on the other primary
address resolvers in the home network.
o when a router receives a `CAmt' from a foreign host that was
previously connected to the same subnetwork, it broadcasts the
`CAmt' in the subnetwork in order to update the AMT entry on
the other routers in the subnetwork.
Expires: January 1994 [Page 14]
INTERNET-DRAFT VIP July 1993
+-----------------+ <HR> home
|<HR> ^ <HR>| router
| (3)|CAmt |
(4) | | | <R> router
+--------|----- <HR> <-----|-------+
(5) | +-----------------+ (2) | <MH> mobile
<----<R>----> home network <----<R>----> host
InvAmt| InvAmt|
|CAmt (1)|CAmt
+-------|--------+ +-------|-------+
| <--<R>--> | | <R> |
| CAmt|(6) | move | | |
| V - -|- - - - - - - - -|- - > <MH> |
|<R> <R>| |<R> <R>|
+----------------+ +---------------+
previous network current network
Figure 7: Packet flow upon host migration in VIP
5. ISO-VIP: Extended CLNP for Mobile Host
ISO-VIP is derived from CLNP (Connectionless-mode Network
Protocol)[4] by applying the VN-protocol defined in Section 3. It is
assumed that ES-IS[5] and IS-IS[6] are used as routing information
exchange protocols. In IS-IS, an NSAP address consists of three
portions: area address, ID, and SEL. An area address is unique in a
routing domain, an ID is unique in an area, and a SEL indicates the
entity which is to receive the PDU. Although NSAP addresses remain
unchanged when an ES moves within an area according to the IS-IS
model, a temporary PN-address is assigned to an ES when it migrates
to another subnetwork even within an area in ISO-VIP. Table 2 shows
the correspondence of the VN-protocol to ISO-VIP. Figures 8 and 9
show the header formats of PDU and the AMT entry formats for ISO-VIP
respectively.
Expires: January 1994 [Page 15]
INTERNET-DRAFT VIP July 1993
Table 2: Correspondence of the VN-protocol to ISO-VIP
VN-protocol | ISO-VIP
------------------|-------------------------------------------------
VN-address | V-NSAP address (virtual NSAP address) or
| V-NET (virtual network entity title)
|
PN-address | NSAP address of NET
|
home network | the subnetwork to which the designated level1-IS
| that advertises the connectivity to the ES
| is connected
|
primary address | the level1-IS that advertises the connectivity
resolver | to the ES
|
secondary address | ISs other than primary address resolver
resolver |
|
temporary proxy | the designated level1-IS in the previous
| subnetwork of an ES
octets
+--------------------------------------+
| Destination Address Length Indicator | 1
+--------------------------------------+
| Destination Address | dst addr len
+--------------------------------------+
| Source Address Length Indicator | 1
+--------------------------------------+
| Source Virtual Address | src addr len
+--------------------------------------+
(a) Address Part
Figure 8-(a): ISO-VIP packet header: Address Part
Expires: January 1994 [Page 16]
INTERNET-DRAFT VIP July 1993
octets
+--------------------------------------+
| Param Code = ISO-VIP | 1
+--------------------------------------+
| Param Len = variable | 1
+--------------------------------------+
| Flags | 1
+--------------------------------------+
| Destination Virtual Address | dst addr len
+--------------------------------------+
| Destination Address Version | 4
+--------------------------------------+
| Source Address | src addr len
+--------------------------------------+
| Source Address Version | 4
+--------------------------------------+
| Holding Time | 4
+--------------------------------------+
| Resolver Address Length | 1
+--------------------------------------+
| Resolver Address | addr len
+--------------------------------------+
| Authentication | n
+--------------------------------------+
(b) Option part: ISO-VIP Data
Figure 8-(b): ISO-VIP packet header: Option Part: ISO-VIP Data
Expires: January 1994 [Page 17]
INTERNET-DRAFT VIP July 1993
octets
+--------------------------------------+
| Param Code = ISO-VIP | 1
+--------------------------------------+
| Param Len = variable | 1
+--------------------------------------+
| Flags | 1
+--------------------------------------+
| Source Address | src addr len
+--------------------------------------+
| Source Address Version | 4
+--------------------------------------+
| Target System Address Length | 1
+--------------------------------------+
| Target System Virtual Address | addr len
+--------------------------------------+
| Target System Address | addr len
+--------------------------------------+
| Target System Address Version | 4
+--------------------------------------+
| Target System Holding Time | 4
+--------------------------------------+
| Authentication | n
+--------------------------------------+
(c) Option part: ISO-VIP Control
Figure 8-(c): ISO-VIP packet header: Option Part: ISO-VIP Control
Expires: January 1994 [Page 18]
INTERNET-DRAFT VIP July 1993
octets
+--------------------------+
| Flags | 1
+--------------------------+
| Holding Time | 4
+--------------------------+
| Address Version Number | 4
+--------------------------+
| ID Length Indicator | 1
+--------------------------+
| ID | id len
+--------------------------+
| Address Length Indicator | 1
+--------------------------+
| Address | addr len
+--------------------------+
(a) AMT entry
+-+-+-+-+-+-+-+-+
| Flags |
+-+-+-+-+-+-+-+-+
| | |
| | +- use(1)/free(0)
| +--- valid(1)/invalid(0)
+----- home(1)/not-home(0)
(b) Flags
Figure 9: AMT entry for ISO-VIP
Author's Address:
o Fumio Teraoka
Sony Computer Science Laboratory Inc.
3-14-13 Higashigotanda, Shinagawa-ku, Tokyo 141, Japan.
Phone: +81-3-5448-4380
Email: tera@csl.sony.co.jp
o Keisuke Uehara
University of Electro-Communications.
1-5-1 Chofugaoka, Chofu, Tokyo 182, Japan.
Phone: +81-424-83-2161, ext. 4122
Email: kei@cs.uec.ac.jp
References
[1] F. Teraoka, Y. Yokote, and M. Tokoro. "A Network Architecture
Providing Host Migration Transparency," in Proc. of SIGCOMM'91,
Sep. 1991.
Expires: January 1994 [Page 19]
INTERNET-DRAFT VIP July 1993
[2] R. Droms. "Dynamic Host Configuration Protocol," Internet Draft,
Dec. 1992.
[3] ISO. "Information processing systems - Telecommunications and
information exchange between systems - End system to Intermediate
system routeing exchange protocol for use in conjunction with the
Protocol for providing the connectionless-mode network service
(ISO 8473) - Amendment 1: Dynamic discovery of OSI NSAP Addresses
by End System," ISO 9542, 1988.
[4] ISO. "Information processing systems - Data communications -
Protocol for providing the connectionless-mode network service,"
ISO 8473, 1988.
[5] ISO. "Information processing systems - Telecommunications and
information exchange between systems - End system to Intermediate
system routeing exchange protocol for use in conjunction with the
Protocol for providing the connectionless-mode network service
(ISO 8473)," ISO 9542, 1988.
[6] ISO. "Information processing systems - Telecommunications and
information exchange between systems - Intermediate system to
Intermediate system intra-domain routeing exchange protocol for
use in conjunction with the Protocol for providing the
connectionless-mode network service (ISO 8473)," ISO 10589, 1992.
Expires: January 1994 [Page 20]
