Internet DRAFT - draft-choi-mobileip-ipv6-mpls
draft-choi-mobileip-ipv6-mpls
MPLS Working Group Jun Kyun Choi
Internet Draft ICU
Document: <draft-choi-mobileip-ipv6-mpls-02.txt> Myoung Hun Kim
Expires: June 2002 ICU
Yoon Ju Lee
ETRI
December 2001
Mobile IPv6 support in MPLS Network
<draft-choi-mobileip-ipv6-mpls-02.txt>
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026 except that the right to
produce derivative works is not granted.
This document is an Internet-Draft and is NOT offered in accordance
with Section 10 of RFC2026, and the author does not provide the IETF
with any rights other than to publish as 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
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
This document discusses how to build the large-scale mobile IPv6
network along with the MPLS network. It proposes that CR-LDP/RSVP-TE
can be applied to set up the QoS guaranteed Label switched path (LSP)
tunnels between an LER of mobile node and an LER of correspondent
node. It means that the IPv6-in-IPv6 tunnels can be replaced by one
or multiple LSPs on the MPLS network. This follows design principles
such as idle mobile node consideration and QoS guarantee, smooth
handoff, no change of Mobile IPv6 etc.
Conventions
Choi/Kim/Lee 1 Page
draft-choi-mobileip-ipv6-mpls-02.txt Expires June 2002
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.
Table of Contents
1. Introduction ................................................ 2
2. Benefits from MPLS ...........................................3
2.1. Independency from lower layer technologies .............. 3
2.2. IPv6 transition benefit ................................. 3
2.3. Connection-Oriented Switching Paradigm .................. 4
2.4. Well defined QoS support with DiffServ .................. 4
2.5. Secure VPN .............................................. 4
3. Features of Mobile IPv6 with MPLS ........................... 5
4. Description of Operation .................................... 6
4.1. When MN initiates data transmission ..................... 6
4.2. When CN initiates data transmission ..................... 7
4.3. Smooth Handoff .......................................... 8
4.4. QoS supported LSP ....................................... 8
5. Required Messages and TLVs ................................... 10
6. Conclusion .................................................. 10
7. Security considerations ..................................... 11
8. References .................................................. 11
9. Author's Addresses .......................................... 11
1. Introduction
Mobile IPv6 [1] allows a mobile node to be always addressable by its
home address, whether it is currently attached to its home link or is
away from home. While a mobile node is attached to some foreign link
away from home, it is also addressable by one or more care-of
addresses, in addition to its home address. A care-of address is an
IP address associated with a mobile node while visiting a
particular foreign link. The subnet prefix of a mobile node's care-
of address is the subnet prefix (or one of the subnet prefixes) on
the foreign link being visited by the mobile node; if the mobile node
is connected to this foreign link while using that care-of address,
packets addressed to this care-of-address will be routed to the
mobile node in its location away from home.
The MPLS network provides the backbone solution for high-speed IP
forwarding and large scalability. And also the MPLS network support
appropriate quality-of-service paths for differentiated mobile IP
services. The initial MPLS effort will be focused on IPv4. However,
the core technology will be extendible to new network layer protocols
(e.g., IPv6).
If IPv6 employs MPLS technology, variable benefit will be expected.
Because MPLS is not confined to certain specific link layer
technology, it can work with any media over which Network Layer
packets can be passed between network layer entities. This aspect
Choi/Kim/Lee 2 Page
draft-choi-mobileip-ipv6-mpls-02.txt Expires June 2002
will be applicable to guarantee user's required QoS and Traffic
Engineering because MPLS is well suited for DiffServ and sort of ATM
Traffic Engineering. In addition, secure VPN and IPv6 transition
benefit will be expected.
This document proposes the MPLS network architecture and tunneling
procedures to support the mobile IPv6 network. Similar concerns on
the integration of MPLS network and Mobile IP network are also
investigated in [2][3]. However those documents are lack of Mobile
IPv6 consideration.
In terms of control plane concern, both CR-LDP and RSVP-TE are
applicable to set up the QoS guaranteed Label Switched Path (LSP)
tunnel between a router of the mobile hosts and a router of the
correspondent node.
When the integration of wired and wireless network is designed, there
are thins to consider. For example, idle mobile node, smooth handoff,
QoS guarantee, etc. Next part describes those design principles.
2. Benefits from MPLS
2.1. Independency from lower layer technologies
The MPLS control component centers around IP functionality, which is
similar to proprietary multilayer switching solutions. However, MPLS
defines new standard-based IP signaling and label distribution
protocols, as well as extensions to existing protocols, to support
multivendor interoperability. In this way, MPLS brings significant
benefits to a packet-oriented Internet.
The MPLS forwarding component is based on the label-swapping
algorithm. If the Layer 2 technology supports a label field (such as
the ATM VPI/VCI or the Frame Relay DLCI fields), the native label
field encapsulates the MPLS label. However, if the Layer 2 technology
does not support a label field, the MPLS label is encapsulated in a
standardized MPLS header that is inserted between the Layer 2 and IP
headers. The MPLS header permits any link layer technology to carry
an MPLS label so it can benefit from label-swapping across an LSP.
2.2. IPv4 to IPv6 transition benefit
The ability of the underlying Internet infrastructure to accommodate
architectural improvements has proven to be a significant factor in
its overall success. Though IPv6 Transition still has lots of
scenarios and burdens simultaneously. MPLS, a forwarding and control
plane architecture, is a notable example of this.
Therefore given the wide-scale backbone adoption of MPLS, it is key
that IPv6 integrate with this technology. We believes that both are
highly complementary since integrating IPv6 transport services over
an MPLS topology requires much less backbone infrastructure upgrades
or reconfiguration while also supporting dynamic connectivity between
Choi/Kim/Lee 3 Page
draft-choi-mobileip-ipv6-mpls-02.txt Expires June 2002
peripheral IPv6 networks. This results from the fact that with MPLS
networks, forwarding is based upon labels rather than the IP header
itself. As such, the data plane dependency on being able to support
native IPv6 packet forwarding is removed, hence eliminating the need
for network core hardware and software upgrades, a likely reality for
native end-to-end IPv6 forwarding.
2.3. Connection-Oriented Switching Paradigm
As a packet of a connectionless network layer protocol travels from
one router to the next, each router makes an independent forwarding
decision for that packet. That is, each router analyzes the packet's
header, and each router runs a network layer routing algorithm. Each
router independently chooses a next hop for the packet, based on its
analysis of the packet's header and the results of running the
routing algorithm.
Unlike normal routers MPLS LSRs deliver connection-oriented network
service. Rather than determining the path of each packet
independently, the LSRs establish a path between the endpoints of a
connection in a network and send the packets across that path. That
LSP is still a virtual connection, sharing the bandwidth of the
physical circuit. In contrast to connectionless routing, the LSRs can
define the parameters of the virtual connection, including allowable
speed and priority. This is crucial to the LSR's ability to manage
bandwidth and QoS.
These distinct features give network managers the ability to tailor
network service to the specific needs of diverse applications with
varying classes of service. Demanded LSPs make use of LSR thus
deliver the variable features such as Fault tolerance, Prioritization,
QoS Classes.
2.4. Well defined QoS support with DiffServ
Though IPv6 has QoS consideration, it still has things to be solved
such as Flow ID issue. In addition, the MPLS shim header achieves the
original goals of the Flow ID field.
MPLS allows the precedence or class of service to be fully or
partially inferred from the label. In this case, one may say that
the label represents the combination of a FEC and a precedence or
class of service.
In a DiffServ domain all the IP packets crossing a link and requiring
the same DiffServ behavior are said to constitute a Behavior
Aggregate (BA). At the ingress node of the DiffServ domain the
packets are classified and marked with a DiffServ Code Point (DSCP),
which corresponds to their Behavior Aggregate. At each transit node,
the DSCP is used to select the Per Hop Behavior (PHB) that determines
the scheduling treatment and, in some cases, drop probability for
each packet.
Choi/Kim/Lee 4 Page
draft-choi-mobileip-ipv6-mpls-02.txt Expires June 2002
Recent work [4] allows the MPLS network administrator to select how
Diff-Serv Behavior Aggregates (BAs) are mapped onto Label Switched
Paths (LSPs) so that he/she can best match the Diff-Serv, Traffic
Engineering and protection objectives within his/her particular
network.
2.5. Secure VPN
The secure VPN, one of major applications of MPLS, is also applicable
to IPv6 network. The inherent VPN and Traffic Engineering services
available within an MPLS environment could enable IPv6 networks going
forward to be combined into virtual private networks or extranets
over an infrastructure also supporting IPv4 VPNs and MPLS-TE.
Additionally MPLS VPNs offer the same level of security as
connection-oriented VPNs. Packets from one VPN do not inadvertently
go to another VPN.
VPN traffic is kept separate. Malicious spoofing is nearly impossible
because the packets received from customers are IP packets. These IP
packets must be received on a particular interface or subinterface to
be uniquely identified with a VPN label.
3. Features of Mobile IPv6 with MPLS
3.1. QoS guaranteed LSP setup
It is required to program appropriate QoS support for the MN's
packets in the intermediate network domains, so that the performance
of QoS-sensitive applications running on the MN is maintained at
desired level. To achieve this, our model adopts QoS Object [5] to
interoperate with CR-LDP/RSVP-TE.
3.2. Idle mobile node consideration
We imagine that wireless IP communicators will be turned around the
clock, ready to receive or initiate services. In fact, the vast
majority of subscribers will not be actively communicating most of
the time. Rather, wireless IP communicators will be switched on,
ready for service, constantly reachable by the wireless Internet. In
essence, MN will be in an idle state but passively connected to the
network infrastructure. Thus design principle is that only active
data are supposed to traverse over QoS guaranteed LSP. This will
prevent LSP abusing that can be caused by lots of control packets.
Thus an LSP is established only between MN's router and CN's router
other than LSP via HA. This would be efficient scheme to save
bandwidth on network and to reduce end-to-end delay.
3.3. Smooth handoff support
There are two goals in term of handoff; the first, to reduce the
latency or interruption due to handoffs; and second, to reduce the
signaling load. Mobile IPv6 is considered as optimal solution for
those needs. Use of more than on care-of-address by a MN may be
useful to improve smooth handoff when the MN moves from on wireless
link to another. Our suggested model supports the smooth handoff
Choi/Kim/Lee 5 Page
draft-choi-mobileip-ipv6-mpls-02.txt Expires June 2002
scheme of Mobile IPv6 and gives solution to QoS consideration with
providing QoS guaranteed multiple LSP for the number of MN's care-of-
address.
3.4. Bi-directional LSP extensible
While traditional traffic engineered MPLS are unidirectional,
generalized MPLS [6] supports the establishment of bi-directional LSP.
Bi-directional LSP has the benefit of lower setup latency and lower
number of messages required during setup. It takes only one
initiator-eliminator round trip time. The suggested model is possible
to be expended to generalized MPLS.
3.5. No obligation of MPLS signaling on MN
Mobile IPv6 embedded MN and CN doesn't need to install CR-LDP/RSVP-TE
at all. CR-LDP/RSVP runs on a router or switch of MNs and CNs. This
will reduce memory cost and complexity of a MN device.
3.6. No additional messages on legacy MPLS signaling
There is no additional Message or TLV/Object on existing CR-LDP/RSVP-
TE to setup QoS guaranteed LSP between CN's LER and MN's LER. The
suggested model adopts data-driven LSP setup.
4. Description of Operation
4.1. When MN initiates data transmission
We assume a MN has already done new default router finding [7],
Address auto-configuration [8], Registration, and Biding
Acknowledgement reception as Mobile IPv6 procedures.
+----------+
| Foreign |
+------------------------------+ | Mobile IP|
| The MPLS Network +-+--+ | Network |
| with Mobility Support | | | +------+ |
+---------+ +----+ /|LER2|--+-|old MN| |
|Home | | HA | +------+ +------+ / +--+-+ | +------+ |
|Mobile IP+-+LER1|--| LSR1 +--+ LSR2 |--+ | +----------+
|Network | |----+ +------+ +------+ \ |
+---------+ | \ | \ | +----------+
| \ | \ | | Foreign |
| \ | \ | | Mobile IP|
| \ | +-++-+ | Network |
| +-+-+--+ | | | +------+ |
+----| LER3 |----------------|LER4|--+-|New MN| |
+---+--+ +----+ | +------+ |
| +----------+
+-+--+
| CN |
+----+
LER: Label Edge Router
Choi/Kim/Lee 6 Page
draft-choi-mobileip-ipv6-mpls-02.txt Expires June 2002
LSR: Label Switching Router
HA: Home Agent
MN: Mobile Node
FN: Correspondent Node
Figure 1. The MPLS Network with Mobile IPv6 Support
When the MN sends packets to any other correspondent node, it sends
packets directly to the destination. The MN sets the source address
of this packet to the care-of-address and includes a 'Home Address'
destination option. Then the correspondent node must process the
option in a manner consistent with exchanging the Home Address field
from the Home Address option into the IPv6 header. Since the home
address is static (in contrast to the care-of-address), this allows
every correspondent node the transparent use of the care-of-address
for layers above the Mobile IPv6 support. Higher layers including
applications do not recognize the care-of-address. They only notice
the home address. Then the packets from the correspondent node are
routed to the HA and tunneled to MN by IPv6-in-IPv6. This routing is
called Triangle Routing.
To avoid triangle routing a MN sends Binding Update that may be
together with QoS Object to correspondent node. The MN's LER
receiving the Binding Update message should determine whether to
initiate REQUEST/PATH message or not. If the Binding Update message
has zero H bit, the LER initiates REQUEST/PATH for a destination
address (FEC). Now the correspondent IPv6 node receiving the Binding
Update message is able to send packets to MN directly. Newly
established QoS guaranteed LSP provides tunnel for packets to
traverse.
MN MN's LER2 HA CN's LER3 CN
| | | | |
| | packet | |
|------------------------------------------------------------>|
| | | packet |
| IPv6-in-IPv6 tunneling |<----------------------------|
|<------------------------------| |
| | | | |
| Binding update with QoS Object | |
|-------------->|-------------------------------------------->|
| | REQUEST/PATH | |
| |------------------------------>| |
| | MAPPING/RESV | |
| |<------------------------------| |
| | | |
| | QoS guranteed LSP | |
|<------------->|<----------------------------->|<----------->|
| | | | |
Figure 2. MN initiates data transmission
Choi/Kim/Lee 7 Page
draft-choi-mobileip-ipv6-mpls-02.txt Expires June 2002
4.2. When CN initiates data transmission
We assume a MN has already done new default router finding, Address
auto-configuration, Registration, and Biding Acknowledgement
reception as Mobile IPv6 procedures.
Before a CN sends any packet to the MN, the CN should examine its
Binding Cache for an entry for an entry for the destination address
(Home address) to which the packet is being sent. If the CN has a
Binding Cache entry for this address, the CN should use a Routing
header to route the packet to the MN by way of the care-of-address in
the binding recorded in that Binding Cache entry. We assume that a CN
has no Binding Cache entry for the MN in this part. The packet sent
by the CN will be intercepted by the MN's HA and tunneled (using
IPv6-in-IPv6 encapsulation) to the MN's current primary care-of-
address.
To avoid triangle routing a MN sends Binding Update that may be
together with QoS Object to correspondent node. The MN's LER
receiving the Binding Update message should determine whether to
initiate REQUEST/PATH or not. If the Binding Update message has zero
H bit, the LER initiates REQUEST/PATH for a destination address (FEC).
Now the correspondent IPv6 node receiving the Binding Update message
is able to send packets to MN directly. Newly established QoS
guaranteed LSP provides tunnel for packets to traverse.
MN MN's LER2 HA CN's LER3 CN
| | | | |
| | | packet |
| IPv6-in-IPv6 tunneling |<----------------------------|
|<------------------------------| |
| | | | |
| Binding update with QoS Object | |
|-------------->|-------------------------------------------->|
| | REQUEST/PATH | |
| |------------------------------>| |
| | MAPPING/RESV | |
| |<------------------------------| |
| | | |
| | QoS guaranteed LSP | |
|<------------->|<----------------------------->|<----------->|
| | | | |
Figure 3. CN initiates data transmission
4.3. Smooth Handoff
Use of more than on care-of-address by a MN may be useful to improve
smooth handoff when the MN moves from on wireless link to another. If
each of these wireless links is connected to the Internet through a
separate base station, such that the wireless transmission range from
the two base stations overlap, the mobile node may be able to remain
Choi/Kim/Lee 8 Page
draft-choi-mobileip-ipv6-mpls-02.txt Expires June 2002
connected to both links while in the area of overlap. In this case,
the MN could acquire a new care-of-address on the new link before
moving out of transmission range and disconnecting from the old link.
The MN may thus still accept packets at its old care-of-address while
it works to update its HA and CNs, notifying them of its new CoA on
the new link.
When a MN acquires new CoA while communicating with CN over legacy
LSP, The MN sends Binding Update along with QoS Object to the CN for
Route Optimization. The MN's LER receiving the Binding Update message
will initiates REQUEST/PATH. Now the correspondent IPv6 node
receiving the Binding Update message is able to send packets to MN
directly while previous flow have been traversed over the legacy LSP.
Which supports smooth handoff scheme over both legacy LSP and newly
established QoS guaranteed LSP. The old LSP will be released
automatically as time goes by because no more data transmitted over
the LSP.
New CoA New LER4 Old LER2 CN's LER3 CN
| | | | |
| | | Legacy LSP | |
| | |<------------->|<----------->|
| Binding update with QoS Object | |
|-------------->|-------------------------------------------->|
| | REQUEST/PATH | |
| |------------------------------>| |
| | MAPPING/RESV | |
| |<------------------------------| |
| | | |
| | New QoS guaranteed LSP | |
|<------------->|<----------------------------->|<----------->|
| | | | |
Figure 4. Smooth handoff
There are still lots of discussion to adopt appropriate handoff
scheme[9][10]. Our document keeps an eye on those emerging handoff
algorithm and will adopt some of them to establish LSP between CN's
LSR and MN's one. Thus above handoff support LSP scheme may change.
For example, If a Handoff scheme use tunnel method between Old Access
Router (AR) and New AR, Our scheme may evolve to setup extended LSP
between Old AR and New AR. In this case MN can receive data through
old LSP and extended LSP as well as newly established LSP associated
new CoA.
4.4. QoS supported LSP
The composition of a QoS OBJECT is shown in Figure 5. A QoS OBJECT is
an extension of RSVP QoS and FILTER_SPEC objects. This is originally
from [5].
Choi/Kim/Lee 9 Page
draft-choi-mobileip-ipv6-mpls-02.txt Expires June 2002
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 | Reserved | Object Length |QoS Requirement|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2 | Max Delay | Delay Jitter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3 | Average Data Rate |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4 | Burstiness:Token Bucket Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5 | Peak Data Rate |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
6 | Minimum Policed Unit |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
7 | Maximum Packet Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
8 | |
| |
| Values of Packet Classification Parameters |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Composition of a QoS OBJECT
o QoS Requirement: This field describes the QoS requirement of the
MN's packet stream in terms of traffic class. An example is
specification in terms of DiffServ PHB classes such as EF or AF.
IntServ classes such as guaranteed service or controlled load service
and UMTS QoS class [11] such as delay sensitivity, interactive-delay
sensitive, non-interactive delay sensitive or delay insensitive are
also supported.
Some examples are,
00000xxx: DiffServ EF PHB
00001xxx: DiffServ AF PHB
After some sort of authentication, which is beyond the scope of this
document, MN's LSR can send Label REQUEST/PATH message with DiffServ
TLV/DiffServ Object to establish E-LSP or L-LSP.
5. Required messages and TLVs
There are no additional messages and TLVs to existing Mobile IPv6 [1],
CR-LDP/RSVP-TE, and Generalized MPLS [6] to operate the suggested
model. In order to support QoS guaranteed communication in Mobile
IPv6, QoS object described in [5] is required.
6. Conclusion
We have proposed a scheme to integrate Mobile IPv6 and MPLS. This
scheme eliminates usages of IP-in-IP tunneling in the data forwarding.
Choi/Kim/Lee 10 Page
draft-choi-mobileip-ipv6-mpls-02.txt Expires June 2002
Switching is much faster than hop-by-hop IP forwarding, so the
transmission delay and packet processing overhead is reduced. We have
designed principles such as No change to Mobile IPv6, Idle node
consideration, smooth handoff, bi-directional LSP, and QoS guaranteed
service. This document will be divided by RSVP-TE centered memo and
CR-LDP centered one.
7. Security Considerations
The Mobile IPv6 and MPLS scheme described in this document is
subject to the same security considerations that apply to draft-ietf-
mobileip-ipv6-13.txt[1], RFC3036[11], RFC3031[12].
8. References
[1] D. Johnson, Mobility Support in IPv6, draft-ietf-mobileip-ipv6-
14.txt, July, 2000.
[2] Choi, Extension of LDP for Mobile IP Service through the MPLS
Network, draft-choi-mobileip-ldpext-02.txt, August, 2001.
[3] R, Zhong, Integration of Mobile IP and MPLS, draft-zhong-mobile-
ip-mpls-01.txt July, 2000.
[4] F. Faucheur, MPLS Support of Differentiated Services, draft-ietf-
mpls-diff-ext-09.txt, April, 2001.
[5] H. Chaskar, Framework for QoS Support in Mobile IPv6, draft-
ietf-mobileip-qos-requirements-01.txt, August, 2001
[6] P. Ashwood, Generalized MPLS - Signaling Functional Description,
draft-ietf-mpls-generalized-signaling-06.txt, October, 2001.
[7] Thomas Narten, Erik Nordmark, Neighbor Discovery for IP Version 6
(IPv6). RFC 2461, December, 1998.
[8] S. Thomson and T. Narten, IPv6 Stateless Address
Autoconfiguration, RFC 2462, 1998.
[9] G. Tsirtsis, Fast Handovers for Mobile IPv6, draft-ietf-mobileip-
fast-mipv6-02.txt, July, 2001
[10] Karim El-Malki, Fast Handoffs in MIPv6, draft-elmalki-
handoffsv6-01.txt, November, 2000
[11] L. Andersson, LDP Specification, RFC3036, January, 2001.
[12] E. Rosen, Multiprotocol Label Switching Architecture, RFC3031,
January, 2001.
8. Author's Addresses
Jun Kyun Choi
Information and Communications University (ICU)
58-4 Hwa Ahm Dong, Yusong, Taejon
Korea 305-732
Phone: +82-42-866-6122
Email: jkchoi@icu.ac.kr
Myoung Hun Kim
Information and Communications University (ICU)
58-4 Hwa Ahm Dong, Yusong, Taejon
Korea 305-732
Phone: +82-42-866-6198
Choi/Kim/Lee 11 Page
draft-choi-mobileip-ipv6-mpls-02.txt Expires June 2002
Email: fiaa@icu.ac.kr
Yoon Ju Lee
Electronics and Telecommunication Research Institute (ETRI)
161 Kajung Dong Yusong, Taejon
Korea 305-305
Phone: +82-42-860-1130
Email: yjlee@etri.re.kr
Full Copyright Statement
"Copyright (C) The Internet Society (date). All Rights Reserved. This
document and translations of it may be copied and furnished to others,
and derivative works that comment on or otherwise explain it or
assist in its implmentation may be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be followed,
or as required to translate it into languages other than English. The
limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
Choi/Kim/Lee 12 Page
