NEMO Working Group Jongkeun Na
Internet Draft Seongho Cho
Expires: November 2004 Chongkwon Kim
Seoul National University
Sungjin Lee
Hyunjeong Kang
Changhoi Koo
Samsung Electronics
April 2004
Route Optimization Scheme based on Path Control Header
draft-na-nemo-path-control-header-00
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
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 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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
In this memo, we propose a unified Route Optimization (RO) scheme
that can solve several types of RO problem by using Path Control
Header (PCH) Piggybacking. In our scheme, Home Agent (HA) does
piggyback the PCH on the packet which is reversely forwarded from
Mobile Router (MR). That enables any PCH-aware routing facility on
Na, et al. Expires - November 2004 [Page 1]
Internet Draft Path Control Header April 2004
the route to make a RO tunnel with MR using the Care-of address of
MR contained in the PCH. By applying to some already known NEMO RO
problems, we show that our scheme can incrementally optimize the
routes via default HA-MR tunnel through the simple PCH
interpretation.
Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in RFC-2119.
Na, et al. Expires - November 2004 [Page 2]
Internet Draft Path Control Header April 2004
Table of Contents
1. Introduction.................................................4
2. Terminology..................................................5
3. Basic Operations.............................................6
3.1 PCH Piggybacking by HA..................................6
3.2 Making a RO Tunnel......................................7
4. Route Optimization...........................................9
4.1 Route Optimization by CR................................9
4.2 Route Optimization over MR-to-MR.......................10
4.3 Nested Tunnels Optimization............................12
5. Extensions..................................................15
5.1 MIPv6 Extension........................................15
5.2 MR Extension...........................................18
5.3 HA Extension...........................................18
6. Security Considerations.....................................19
References......................................................20
Acknowledgments.................................................21
Authors' Addresses..............................................21
Na, et al. Expires - November 2004 [Page 3]
Internet Draft Path Control Header April 2004
1. Introduction
NEMO Basic Support Solution[15] would suppose to support
transparent mobility to mobile network nodes(MNNs) in mobile
networks by using MR-HA bi-directional tunneling. However,
inherently due to the use of the bi-directional tunnel, there are
some types of route optimization problem [14] that need our
attention. Until now, one solution is proposed to solve only one
type of route optimization problem such as nested tunnel
optimization.
In this memo, we propose a route optimization scheme based on
PCH(Path Control Header) piggybacking by HA. The scheme is a
unified solution that can solve a several types of route
optimization problem with applying the same principle to the
routing facilities such as HA, MR and Correspondent Router(CR).
In the proposed scheme, HA does piggyback PCH on the packet which
is reversely forwarded from MR through bi-directional MR-HA tunnel.
PCH is a hop-by-hop option header so that it can be processed by
all of the routing facilities on the path that is from HA to CN. HA
forwards the packet with PCH to CN for the route optimization. CR
on the path makes a RO(Route Optimization) tunnel between MR and
itself using the information which is the CoA of MR that is
contained in PCH.
This memo describes how we can apply PCH based scheme on two
problem spaces listed in [14]. One is to CR based route
optimization in routing infrastructure and the other is to the
nested tunnels optimization for which many of solutions in NEMO
have been proposed. The basic operation and signaling will be
detailed in section 3 and 4.
Our proposed RO scheme, PCH piggybacking by HA, is a simple but
effective one in solving the problems of route optimization in
network mobility support. By taking the functional extension of
routing facilities such as HA, MR and CR, we can dynamically
incrementally optimize the routes over CN-HA-MR without the loss of
transparency to CN.
We expect that the basic concept of this scheme can be used to
support other mobility-related route optimizations as a unified
solution, not limited to network mobility.
Na, et al. Expires - November 2004 [Page 4]
Internet Draft Path Control Header April 2004
2. Terminology
It is assumed that readers are familiar with NEMO terminology
described in [2][14], and the terms described in [4][5]. In
addition, we define a few of terms used in describing the operation
of our solution.
Path Control Header (PCH)
IPv6 hop-by-hop option header piggybacked on the reversely
forwarded packet by HA for the route optimization. This
header contains, as an option data, a form of array of IPv6
global addresses that are the addresses of Mobile Routers on
the nested path which means from TLMR to any nested MR in
nested mobile networks.
RO Tunnel (ROT)
Any tunnel that created by the scheme of route optimization
proposed by this document is referred to a "RO Tunnel.
Nested RO Tunnel (NROT)
Any RO tunnel that do require the source routing using IPv6
Routing Header Type 0 (RH0). This kind of RO tunnel is only
used in optimizing the nested tunnels to guarantee the
correct routing over nested MRs.
Correspondent Router (CR)
Any router in the Internet that can play a role of a
correspondent agent for a set of correspondent nodes. It
maybe an access router serving the routing service to a set
of subnets or a border router located in AS-level or ISP-
level.
Na, et al. Expires - November 2004 [Page 5]
Internet Draft Path Control Header April 2004
3. Basic Operations
3.1 PCH Piggybacking by HA
To route optimization, HA does piggyback PCH on the packet which is
reversely forwarded from MR through bi-directional MR-HA tunnel.
PCH is a hop-by-hop option header so that it can be processed by
all of the routing facilities on the path that is from HA to CN.
The mentioned routing facility means an entity which can play a
role of transparent correspondent agent. The router in the Internet
that implements such a function of transparent correspondent agent,
we call it a CR, provides the packet redirection service to the
nodes behind it by intercepting the packets sent from them and
redirecting to the RO tunnel. The RO tunnel between CR and MR can
be established when CR gets know the existence of HA by processing
the packet with PCH.
In fig.1, HA de-capsulates the encapsulated packet forwarded from
MR via MR-HA tunnel and then forwards the PCH piggybacked packet to
CN for the route optimization. Any existing CR on the path from HA
to CN can catch the path control information as examining PCH in
the packet. Therefore, the CR can initiate the procedure of making
RO tunnel between itself and MR using the CoA of MR which is
contained in PCH. After setting up RO tunnel, the packets of CN
will be redirected to RO tunnel at CR.
+----+ IP in IP
CN <--- Packet with PCH --- | HA |<==== Packet ==== MR
| +----+
=[1|CoA of MR]
Fig.1 PCH piggybacking by HA
This scheme is simple and effective in respects of RO. It only
requires a little effort of HA to provide the RO tunnel between CR
and MR. HA does PCH piggybacking on the packet which taking a non-
optimized path of MR-HA tunnel. In here, we can say that CR maybe
an access router that providing the routing service for a few of
subnets or a border router that runs BGP routing protocol in one AS.
Fig.2 shows the structure of PCH. PCH has address information as an
option data. In here, the address information represents the list
of IPv6 addresses. The address contained in PCH indicates the CoA
of MR in MR-HA relationship. Through PCH, CR gets know the CoA of
MR so that CR can initiate the signaling for RO tunnel.
Na, et al. Expires - November 2004 [Page 6]
Internet Draft Path Control Header April 2004
PCH(Path Control Header) : IPv6 Hop-by-Hop Options Header
Option Type : 00 0 XXXXX
00 - skip over this option and continue processing the header.
0 - Option Data does not change en-route
XXXXX = Path Control Option ID (to be assigned by IANA)
Option Data :
+-----------+------------+------------+---------+------------+
| Length(n) | Address(1) | Address(2) | . . . . | Address(n) |
+-----------+------------+------------+---------+------------+
Fig.2 Type and data format of PCH option
In fig.3 that shows the case of forming nested tunnels, PCH gets
contain two CoAs, each of MR1 and MR2. HA2 gets know the fact that
its MR2-HA2 tunnel is nested under outer MR1-HA1 tunnel after
taking a look at the packet with PCH1. The nested HA just adds the
CoA of its MR on the received PCH to make its PCH. In fig.3, HA2
does piggyback PCH which includes the CoA of MR1(the exit point of
the outer tunnel) and the CoA of MR2(the exit point of its tunnel).
In this case, one CR on the path between HA2 and CN will able to
make RO tunnel with MR2 by using the nested information carried in
PCH.
+---+ +---+ +---+ +---+
CN <----|HA2|=========|HA1|////////|MR1|========|MR2|<----LFN
\ +---+ \ +---+ +---+ +---+
\ PCH=[1|CoA of MR1]
PCH=[2|CoA of MR1, CoA of MR2]
Fig.3 Nested PCH piggybacking by HAs
3.2 Making a RO Tunnel
The CR can make a RO tunnel after getting the piggybacked PCH from
HA. The signaling to construct a RO tunnel between CR and MR is
done with 3-way handshake as in fig.4. The messages defined in here
are carried by Mobility Header(MIPv6). We define new message called
BR(Binding Request) to notify MR of the need of RO tunnel.
BU(Binding Update) and BA(Binding Acknowledgement) are same as
defined in MIPv6 and NEMO. Additionally, we define new mobility
option to carry a set of network prefixes. CR can use this option
to inform MR of the routing information of networks which are
reachable from RO tunnel. By referring those of routing information,
MR reversely forwards the packets to pre-established RO tunnel
Na, et al. Expires - November 2004 [Page 7]
Internet Draft Path Control Header April 2004
because they are destined to the network that is reachable from RO
tunnel.
CR does the same thing for the prefix of mobile network that is
bound through BU from MR. CR intercepts the packets destined to the
prefix and redirects them to pre-established RO tunnel.
CR MR
| |
|----- Binding Request(BR) -------->|
| |
|<---- Binding Update(BU)-----------|
| |
|----- Binding Ack.(BA)------------>|
| |
|<======== RO tunnel ==============>|
| |
Fig.4 The signaling procedure for RO Tunnel
Na, et al. Expires - November 2004 [Page 8]
Internet Draft Path Control Header April 2004
4. Route Optimization
4.1 Route Optimization by CR
HA1
|
===*====
|&
CR1(Border Router)
\
+---------------------+
| Internet |--CR2 ====|===
+---------------|-----+ CN1
/ AR(Access Router)
CN2 |
======*===========
MR1
|
LFN1
Fig.5 CR-based Route Optimization : Network Configuration
As in fig.5 and 6, CR1 and CR2 can simultaneously establish a RO
tunnel with MR through one PCH piggybacking by HA1. This is
possible because both are on the path that is from HA1 to CN1. In
that case, the packets sent from CNs in all of subnets attached to
CR2 are redirected to RO tunnel at CR2. CR1 can serve the packets
sent from any CNs(in here, CN2) that are scattered in the Internet.
The packets reached on CR1 indicate that there is no CR in the path
that is from CN2 to CR1, or CR but still not received PCH. The
packets from CN2 are redirected at CR1 and reversely the packets
from MR1 are forwarded via HA1. At next time, the CR on the CR1-CN2
path can make a RO tunnel by picking PCH up on the reversely
forwarded packets from HA1. As a result of PCH piggybacking by HA1,
we can serve the incremental route optimization to all of CNs.
Na, et al. Expires - November 2004 [Page 9]
Internet Draft Path Control Header April 2004
CN1 CN2 CR2 CR1 HA1 MR1 LFN1
| | | | | | |
| | | | | Tunnel | |
|----------Packet------------------>|========|------->|
|<+++Packet(PCH)++|<+++++++|<+++++++|========|<-------|
| | | |------- BR ----->| |
| | | |<------ BU ------| |
| | | |------- BA------>| |
| | | |<== RO tunnel ==>| |
| | | | | | |
| | |----------- BR ---------->| |
| | |<---------- BU -----------| |
| | |----------- BA ---------->| |
| | |<======= RO tunnel ======>| |
| | | | | | |
|---------------->|==========================|------->|
|<----------------|==========================|<-------|
| | | | | | |
| |---------------->|=================|------->|
| |<+++++++++++++++++++++++++|========|<-------|
| | | | | | |
Fig.6 CR-based Route Optimization : Message Flow
4.2 Route Optimization over MR-to-MR
As in fig.7 and fig.8, we can get the RO tunnel over MR-to-MR by
using PCH piggybacking. MR per se interprets PCH piggybacked from
the HA of the other MR and initiates the signaling for RO tunnel
with the other MR. As a result of that, the nodes behind one MR can
directly communicate with the nodes behind the other MR without any
routing overhead.
Na, et al. Expires - November 2004 [Page 10]
Internet Draft Path Control Header April 2004
LFN2
|
MR2
===*====
|
AR(Access Router)
\
+---------------------+
| Internet |--HA1
+---------------|-----+
/ AR(Access Router)
HA2 |
======*===========
MR1
|
LFN1
Fig.7 MR-to-MR Route Optimization : Network Configuration
LFN1 MR1 HA1 HA2 MR2 LFN2
| | | | | |
| | Tunnel | | Tunnel | |
|------->|========|+++++++>|========|+++++++>|
| | | | | |
| |<---------- BR -----------| |
| | | | | |
| |----------- BU ---------->| |
| | | | | |
| |<---------- BA -----------| |
| | | | | |
| |<======= RO Tunnel ======>| |
| | | | | |
|<-------|==========================|<-------|
| | | | | |
| | | | | |
Fig.8 MR-to-MR Route Optimization : Message Flow
Na, et al. Expires - November 2004 [Page 11]
Internet Draft Path Control Header April 2004
4.3 Nested Tunnels Optimization
Fig.9 and 10 show the network configuration and message flow for
the nested tunnels optimization using PCH piggybacking. In nested
mobile networks, RO tunnel is called Nested RO Tunnel(NROT)
because we introduces the source routing concept in handling the
nested tunnel optimization. To the correct routing in the nested
network configuration, we take advantage of IPv6 Routing Header
Type 0(RH0) in NROT.
HA1
|
===*====
|&
AR(Access Router)
\
+---------------------+
HA2--| Internet |--CR====|===
+---------------|-----+ CN
/ AR(Access Router)
HA3 |
======*===========
MR1(TLMR)
|
====*=============|=================*==========
MR2 LFN1 MR4
| |
=======*==== ================?====
MR3 VMN
|
====|=======|=====
LFN3 LMN
Fig.9 Nested Tunnels Optimization : Network Configuration
In fig.10, CR gets know the existence of nested tunnels through PCH
information (MR1s CoA and MR2s CoA, MR3s CoA) and then initiate
the signaling for NROT to MR3 via nested tunnels. At this time,
Binding Request(BR) message contains Nested Routing Path Option(NRP
Option). NRP Option is used to inform MR3 of the nested path
information. If MR3 receives BR message having NRP option, MR3 also
gets know that it is nested. Therefore, the tunnel between CR and
MR3 becomes a NROT.
In NROT, the entry point of tunnel adds RH0 at encapsulation.
Reversely, the exit point of tunnel deletes RH0 at decapsulation.
Na, et al. Expires - November 2004 [Page 12]
Internet Draft Path Control Header April 2004
For the packets tunneled from CR to MR3, the packet forwarding is
done with source routing of RH0 (MR1->MR2->MR3). For the packets
tunneled from MR3 to CR, the reverse source routing (MR2->MR1->CR)
occurs. Fig.11 and 12 shows the content of RH0 at the packet
delivery.
LFN3 MR3 MR2 MR1 HA1 HA2 HA3 CR CN
| | | | | | | | |
| | | |\\\\\\| | | | |
| | |//////|//////|//////| | | |
|----->|======|======|======|======|======|+++++>|++++>|
| | |//////|//////|//////| | | |
| | | |\\\\\\| | | | |
| | | | | | | | |
| |<----------------- BR -------------------| |
| |------------------ BU ------------------>| |
| |<----------------- BA -------------------| |
| | | | | | | | |
| |<========== Nested RO Tunnel ===========>| |
| | | | | | | | |
| |Source routing | | | | |
|<-----|<<====|<<====|<<=========================|<----|
| | | | | | | | |
|----->|====>>|====>>|=========================>>|---->|
| | | | | | | | |
Fig.10 Nested Tunnels Optimization : Message Flow
Na, et al. Expires - November 2004 [Page 13]
Internet Draft Path Control Header April 2004
<--------------- outer IPv6 header --------------->
+-------+-------++ -- ++----+---+--------+---------++--------
|oSRC |oDST |: :|oRH |LS |Addr[1] | Addr[2] ||
CR :| CR |MR1-CoA|:oEXT:|type| 2 |MR2-CoA | MR3-CoA || iPACKET
| | |: :| 0 | | | ||
+-------+-------++ -- ++----+---+--------+---------++--------
<--------------- outer IPv6 header --------------->
+-------+-------++ -- ++----+---+--------+---------++--------
|oSRC |oDST |: :|oRH |LS |Addr[1] | Addr[2] ||
MR1:| CR |MR2-CoA|:oEXT:|type| 1 |MR1 | MR3-CoA || iPACKET
| | |: :| 0 | | | ||
+-------+-------++ -- ++----+---+--------+---------++--------
<--------------- outer IPv6 header --------------->
+-------+-------++ -- ++----+---+--------+---------++--------
|oSRC |oDST |: :|oRH |LS |Addr[1] | Addr[2] ||
MR2:| CR |MR3-CoA|:oEXT:|type| 0 |MR1 | MR2 || iPACKET
| | |: :| 0 | | | ||
+-------+-------++ -- ++----+---+--------+---------++--------
Fig.11 Forward Packet Delivery (CR->MR3) via NROT
<--------------- outer IPv6 header --------------->
+-------+-------++ -- ++----+---+--------+---------++--------
|oSRC |oDST |: :|oRH |LS |Addr[1] | Addr[2] ||
MR3: |MR3-CoA| MR2 |:oEXT:|type| 2 |MR1 | CR || iPACKET
| | |: :| 0 | | | ||
+-------+-------++ -- ++----+---+--------+---------++--------
<--------------- outer IPv6 header --------------->
+-------+-------++ -- ++----+---+--------+---------++--------
|oSRC |oDST |: :|oRH |LS |Addr[1] | Addr[2] ||
MR2: |MR2-CoA| MR1 |:oEXT:|type| 1 |MR3-CoA | CR || iPACKET
| | |: :| 0 | | | ||
+-------+-------++ -- ++----+---+--------+---------++--------
<--------------- outer IPv6 header --------------->
+-------+-------++ -- ++----+---+--------+---------++--------
|oSRC |oDST |: :|oRH |LS |Addr[1] | Addr[2] ||
MR1: |MR1-CoA| CR |:oEXT:|type| 0 |MR3-CoA | MR2-CoA || iPACKET
| | |: :| 0 | | | ||
+-------+-------++ -- ++----+---+--------+---------++--------
Fig.12 Reverse Packet Delivery (MR3->CR) via NROT
Na, et al. Expires - November 2004 [Page 14]
Internet Draft Path Control Header April 2004
5. Extensions
The proposed scheme requires some extensions for existing MIPv6 and
NEMO Basic Support protocols.
5.1 MIPv6 Extension
The proposed scheme requires some extensions for existing MIPv6
protocol [1]. As you see in section 3.2, new mobility message, BR,
is required. And also, new two mobility options are needed. We
describe the purpose and usage of them in here.
Binding Request Message (BR Message): This message is used to
notify MR of the need of RO tunnel. If the sender of this
message detects the nested tunneling(i.e. PCH contains one more
addresses), it should put NRP(Nested Routing Path) Option into
this message to inform MR of its nested path information.
Otherwise, this message includes no special information except
for triggering the signaling of RO tunnel.
Nested Routing Path Option (NRP Option): The initiator of the
signaling of RO tunnel should add this mobility option in BR
message to set up the Nested RO Tunnel with nested MR. This
option contains the list of addresses that represents the tree
topology of nested MRs. That is used for MR to assign the source
routing path that is necessary to nested tunnels optimization.
Reachable Network Prefixes Option (RNP Option): This option is
used to let MR know about the network prefixes which are
reachable via RO tunnel. By using this information associated
with RO tunnel, MR can select the optimized path(i.e. RO tunnel)
for the out-going packets. This option should be contained in BA
message.
5.1.1 Binding Request Message (BR Message)
New BR Message is defined to notify MR of the need of RO tunnel. If
sender detects the nested mobility, it has to put NRP Option into
in this message to inform MR of its nested path information. The
format of this message is as follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # |
Na, et al. Expires - November 2004 [Page 15]
Internet Draft Path Control Header April 2004
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Mobility options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
TBD
5.1.2 Reachable Network Prefixes Option (RNP Option)
RNP Option is used to let MR know about the networks reachable via
the tunnel. By using this information associated with the tunnel
between CR and MR, MR can select the optimized path for the out-
going packets. This option should be contained either BR or BA
message for the route optimization in the reverse packet delivery.
The format of this option is as follows:
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 = TBA | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ a set of network prefixes +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
TBD
Na, et al. Expires - November 2004 [Page 16]
Internet Draft Path Control Header April 2004
5.1.3 Nested Routing Path Option (NRP Option)
CR adds new mobility option, NRP Option in BR message to set up the
Nested RO Tunnel with nested MR. The format of this option is as
follows:
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 = TBA | Length=16*n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NP_Length=n | Reserved | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Addr[1](=TLMR address) +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| o |
| o |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Addr[n] +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
NP_Length
8-bit unsigned integer that indicates the number of Addr[]
slots.
Addr[1..n]
Vector of IPv6 global addresses of MRs on the nested path,
numbered 1 to n.
NRP Option is only valid in a Binding Request message. The purpose
of this option is to inform MR that it can do optimize the nested
tunnels overhead. Using this information, MR can route packets to
Na, et al. Expires - November 2004 [Page 17]
Internet Draft Path Control Header April 2004
CR via the MRs on the nested path by using type 0 RH optional
header.
5.2 MR Extension
For route optimization, MR MUST understand BR message sent from
routing facilities such as CR. According to MIPv6 Spec.[1], MR MUST
maintain Binding Update List(BU List). In managing BU List, the
following information MUST be maintained additionally to use RO
tunnel defined in this proposed solution.
RO Tunnel (ROT) flag: When it is set, it indicates that the
associated BU entry is for ROT tunnel. All of ROT tunnel should
contain a set of network prefixes that is carried from RNP
Option.
Nested RO Tunnel (NROT) flag: When it is set, it indicates that
the associated BU entry is for NROT tunnel. In this case, the BU
entry should contain the nested path information carried from
NRP Option.
Nested Path Information (NPI) Vector: The address vector
information is transferred in NRP Option. This information is
only valid when NROT flag is set.
Network Prefixes (NP) Vector: The address vector information
transferred in RNP Option. This information is only valid when
either ROT flag or NROT flag is set.
The successful establishment of RO tunnel allows the ready of RO-
enabled tunnel interface that would be associated with the
correspondent entry of BU List. That tunnel interface should be
setup to add IPv6 RH0(Routing Header Type 0) optional header at the
encapsulation of tunneled packets if the NROT flag is set.
Lastly, MR should maintain the RO tunnels in its own context. In
other words, MR can tear down less necessary RO tunnels according
to its own criterion such as Least Recently Used(LRU) in case of
the resource shortage.
5.3 HA Extension
For route optimization, HA should maintain the state of PCH
piggybacking for per traffic flow. The traffic flow can be
classified by the destination address of the packets. HA does
piggyback PCH on one packet per the traffic flow. The piggybacking
state should be managed by soft-state. The piggybacking state of
Na, et al. Expires - November 2004 [Page 18]
Internet Draft Path Control Header April 2004
per traffic flow becomes set when the first packet is piggybacked
and reset when the state timer is expired. HA doesnt need to
piggyback PCH on the packets belong the traffic flow while the
correspondent state is set. The overhead of managing the
piggybacking state can be minimized by the careful implementation.
According to MIPv6 Spec.[1], HA MUST maintain Binding Cache(BC).
Like MR extension. Additionally, HA manages the following
information in associated BC entry for route optimization.
Route Optimization (RO) flag: When it is set, it indicates that
the associated BU entry is RO enabled. RO may be enabled or
disabled by administrative means.
Piggybacking State Table (PST): An entry of this table
represents a record that contains (flow-id = destination
address, time-info = UTC time). It indicates that the first
packet belong the traffic flow(=flow-id) was piggybacked with
PCH at time(=time-info).
For the packets forwarded via RO enabled tunnel from MR, HA
decapsulates them, and checks the need of PCH piggybacking. If an
entry that contains the destination address of the packet exists in
PST, PCH is not piggybacked to the packet at forwarding. Otherwise,
HA creates new entry in PST for that traffic flow and piggybacks
PCH on the packet at forwarding. We can use one global timer to
delete the records which were long sustained in PST.
6. Security Considerations
TBD
In particular, considering security concerns is very important in
applying the Internet protocol. At this moment, Public Key
Infrastructure (PKI) can be a solution to support the integrity and
the origin-authentication of PCH because the participants in our
scheme are limited to some of routing facilities. We know that the
potential security problem of our scheme must be deeply considered.
We leave the detailed security consideration into the future work
item with high priority.
Na, et al. Expires - November 2004 [Page 19]
Internet Draft Path Control Header April 2004
References
[1] Perkins, C., Johnson, D. and J. Arkko, "Mobility Support in
IPv6", draft-ietf-mobileip-ipv6-18 (work in progress), July
2002.
[2] Ernst, T. and H. Lach, "Network Mobility Support Terminology",
draft-ietf-nemo-terminology-00 (work in progress), May 2003.
[3] Ernst, T., Castelluccia, C., Bellier, L., Lach, H. and A.
Olivereau, "Mobile Networks Support in Mobile IPv6 (Prefix
Scope Binding Updates)", draft-ernst-mobileip-v6-network-03
(work in progress), March 2002.
[4] Thubert, P., and Molteni, M., "IPv6 Reverse Routing Header
and Its Application to Mobile Networks", Internet Draft:
draft-thubert-nemo-reverse-routing-header-01
(work in progress), Oct 2002.
[5] Chan-Wah Ng, and Takeshi Tanaka, "Securing Nested Tunnels
Optimization with Access Router Option", Internet Draft:draft
-ng-nemo-access-router-option-00(work in progress), Oct 2002.
[7] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
[8] Kent, S. and R. Atkinson, "IP Authentication Header",
RFC 2402, November 1998.
[9] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload
(ESP)", RFC 2406, November 1998.
[10] Deering, S. and R. Hinden, "Internet Protocol,
Version 6 (IPv6) Specification", RFC 2460, December 1998.
[11] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery
for IP Version 6 (IPv6)", RFC 2461, December 1998.
[12] Conta, A. and S. Deering, "Internet Control Message Protocol
(ICMPv6) for the Internet Protocol Version 6 (IPv6)
Specification", RFC 2463, December 1998.
[13] Reynolds, J., "Assigned Numbers: RFC 1700 is Replaced by
an On-line Database", RFC 3232, January 2002.
[14] Thubert, P., and Molteni, M., "Taxonomy of Route Optimization
Models in the NEMO Context", Internet Draft: draft-thubert-
nemo-ro-taxonomy-00(work in progress), Oct 2002.
Na, et al. Expires - November 2004 [Page 20]
Internet Draft Path Control Header April 2004
[15] vijay, D., Ryuji, W., Alexandru, P., Pascal, T., "NEMO Basic
Support Protocol", draft-ietf-nemo-basic-support-00(work in
process), June 2003.
[16] A. Conta, S. Deering, "Generic Packet Tunneling in IPv6
Specificiation", RFC2473, December 1998.
Acknowledgments
Authors' Addresses
Jongkeun Na
Information Networking & Computing Lab.
School of Computer Science and Engineering,
Seoul National University, Seoul Korea
EMail: jkna@popeye.snu.ac.kr
Sungho Cho
Information Networking & Computing Lab.
School of Computer Science and Engineering,
Seoul National University, Seoul Korea
EMail: shcho@popeye.snu.ac.kr
Chongkwon Kim
Information Networking & Computing Lab.
School of Computer Science and Engineering,
Seoul National University, Seoul Korea
EMail: ckim@popeye.snu.ac.kr
Sungjin Lee
Global Standards & Research Team
Telecommunication R&D Center,
Samsung Electronics, KOREA
Email : steve.lee@samsung.com
Hyunjeong Kang
Global Standards & Research Team
Telecommunication R&D Center,
Samsung Electronics, KOREA
Email : hyunjeong.kang@samsung.com
Changhoi Koo
Global Standards & Research Team
Telecommunication R&D Center,
Na, et al. Expires - November 2004 [Page 21]
Internet Draft Path Control Header April 2004
Samsung Electronics, KOREA
Email : chkoo@samsung.com
Na, et al. Expires - November 2004 [Page 22]