Internet DRAFT - draft-menzel-udlr-mipv6
draft-menzel-udlr-mipv6
Internet Draft O.Menzel, D.Wagner,
Expires: September 4, 2006 I. Miloucheva, SATCOM
April 2006
Support of mobile receivers with unidirectional links in MIPv6
draft-menzel-udlr-mipv6-00.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
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.
This Internet-Draft will expire on September 4, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This document discusses mechanisms for Mobile IPv6 allowing the
efficient establishment of bidirectional link layer connectivity of
mobile receivers moving to access networks with unidirectional links.
Scenarios are derived from the need to support seamless mobile
in heterogeneous networking environment including unidirectional
downstream link interfaces, such as DVB-H, DVB-T, DVB-S or satellites.
In order to establish quickly the upstream connectivity of a mobile
receiver, when moving to downstream unidirectional network in MIPv6
environment, the Link-Layer Tunneling Mechanisms defined in
RFC 3077 are used in interaction with Mobile IPv6 protocols.
Menzel Expires September 4, 2006 [Page 1]
INTERNET-DRAFT Mobile nodes with UDLs in Ipv6 April 2006
For the mobile receivers with interfaces to unidirectional downstream
links is required to have at least one additional interface, allowing
to provide the upstream connectivity over Internet.
The information for the upstream link, called also "feed" in the
framework of RFC 3077, is included in the route advertisement message
as an "unidirectional link tunneling" option.
This option contains the IPv6 tunnel address for the upstream
connectivity of a mobile node over the additional link.
The integration of the "unidirectional link tunneling" option is also
proposed for Fast Handovers and Candidate Access Router Discovery (CARD).
Table of Contents
1. Overview.................................................. 2
2. Terminology used in this document......................... 3
3. Scenarios using mobile receivers with unidirectional links 4
4. Requirements of mobile nodes with unidirectional links.... 5
5. Integration of unidirectional link tunneling information
in IPv6 mobility protocols................................ 9
6. Operational considerations................................ 10
6.1 Mobility support for Ipv6................................ 10
6.2 Fast Handovers for Ipv6.................................. 11
6.3 CARD protocol............................................ 12
7. IANA considerations......................................... 13
8. Further work................................................ 13
References..................................................... 13
Author's Addresses............................................. 15
1. Overview
Mobile IPv6 does not attempt to solve all general problems related
to mobile nodes, as for instance when they have interfaces atached to
links with unidirectional connectivity [4].
For the integration of technologies based on unidirectional links
(satellites, DVB-H, DVB-T [8]) into mobile IPv6 environment, there
is a need to define facilities for dynamic management of the
bidirectional connectivity of the mobile node, when the node
changes the access point to and/or moves to unidirectional access
network.
The Link-Layer Tunneling Mechanisms (LLTM) and the Dynamic
Tunneling Configuration Protocol (DTCP) described in RFC 3077
[1] are aimed to emulate bidirectional connectivity for
unidirectional links in Internet. LLTM was primary defined and used
based on scenarios mainly including IPv4 fixed multicast services
over unidirectional links, such as satellites [13].
In the European project DAIDALOS [22], LLTM is used to support mobile
Menzel Expires September 4, 2006 [Page 2]
INTERNET-DRAFT Mobile nodes with UDLs in Ipv6 April 2006
receivers based on DVB-technologies for IPv6 environment. This is
based on integration of IPv6 services and protocols, such as PIM-SM
routing [18], [19],and Multicast Listening Discovery (MLDv2) [17]),
in mobile Internet environment considering the specifics of
unidirectional links.
In order to support efficently bidirectional connectivity of mobile
nodes with unidirectional links in IPv6, this document proposes an
OPTIONAL facility extending IPv6 mobility protocol [4] and
its complementary protocols for Fast Handovers [15] and CARD [6]
considering interoperation with LLTM [1].
The proposed facility allows dynamically bidirectional connectivity
using LLTM and is RECOMMENDED for efficient support of IPv6 mobile
nodes with unidirectional links during their movement from one
access network to another.
This document discusses the usage of LLTM for MIPv6 and defines the
operational considerations for the integration of the option for
unidirectional link handling in MIPv6, Fast Handovers and CARD.
2. Terminology 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 [9].
Abbreviations used in the following text:
CoA Care-of Address
pCoA previous Care-of Address
pAR previous Access Router
pAP previous Access Point
nCoA next Care-of Address
nAR next Access Router
nAP next Access Point
AR Access Router
Mobility related terminology is defined in [10].
For nodes with unidirectional links, the terminology of [1]
is used enhanced with definitions for mobile environment as follows:
Access Router Feed
Access Router attached to an unidirectional link with
established tunnel end-points for bidirectional link (BDL)
emulation.
Access Router Feed information (FeedInfo)
Information describing tunnel end-points established at the
access router for bidirectional link emulation.
Menzel Expires September 4, 2006 [Page 3]
INTERNET-DRAFT Mobile nodes with UDLs in Ipv6 April 2006
Unidirectional link (UDL)
A layer 2 link with asymmetric reachability, defined in
[23] as non-reflexive reachability link, which means packets
from A reach B and packets from B do not reach A.
Unidirectional Link Access Point (UdlAP)
A layer 2 device connected to an IP subnet that offers
unidirectional multicast/unicast connectivity.
Unidirectional Link handling option (UdlOpt)
An option, which contains list of feed information about
unidirectional link access points.
Multihomed Mobile Node
A mobile node (either a host or a router) is multihomed when it has
at least multiple CoAs.
3. Scenarios using mobile receivers connected to unidirectional links
Unidirectional networks, based on satellites, DVB-T and DVB-H, could
be part of different scenarios for media content distribution to
multiple receivers and deploying of large scale multicast with saving
of bandwidth and administration costs.
In order to benefit from a better coverage area, costs and
the characteristics of the satellite and broadcast technology, the
unidirectional links are often used in heterogeneous wired and
wireless environment.
Such scenarios are typically based on asymmetric communication.
An example is described in [11], in which multicasting of cache
objects is performed on a high bandwidth downstream unidirectional
satellite links, while the acknowledgments and requests from the
receivers are transferred on an additional low bandwidth link over
Internet.
Satellites as unidirectional link could be efficiently used to
deliver multicast traffic to a large number of listeners located
in different geographic areas [16]. In this case, downstream
shortcuts from multicast sources to multicast listeners are created,
where upstream different wireless technologies could be used to
provide connectivity over Internet to the sending source.
In the heterogeneous mobile networking environment of Mobile IPv6
[4], the receivers with unidirectional downstream links are
connected upstream using additional wireless access technologies.
When the mobile receivers with unidirectional links move, there are
different kinds of handover related to the unidirectional links, which
should be seamlessly performed:
Menzel Expires September 4, 2006 [Page 4]
INTERNET-DRAFT Mobile nodes with UDLs in Ipv6 April 2006
- handover to another unidirectional access link for downstream
transfer, which requires establishment of new upstream tunnel over
the additional wireless access network and release of already
exiting tunnel;
- handover to a wireless access network with release of already
existing upstream tunnel;
- handover to a new upstream tunnel over the additional wireless
access network and establishment of new upstream channel and
release of already exiting;
Mobile IPv6 is designed to allow a mobile node to maintain
its IPv6 communications while moving between IPv6 subnets.
However, the current specification of Mobile IPv6 lacks support for
mobile nodes with unidirictional links using additional wireless
access network for upstream communication.
In case of unidirectional links, different IP addresses (CoAs) should
be assigned to the mobile node to the downstream (unidirectional) and
upstream link allowing the bidirectional connectivity.
For this purpose multihoming of the mobile node with unidirectional
link in MIPv6 is required, which is currently under standardisation
[7], [28], [29].
4. Requirements of mobile nodes with unidirectional links
Emulation of bidirectional connectivity for mobile nodes with
unidirectional links is required to support mobile IPv6 services.
Bidirectional connectivity is needed for address configuration in
MIPv6 based on Neighbor discovery [23], dynamic stateless [24] and
stateful [25] mechanisms. Multicast protocols, particularly used for
integration of DVB-T in IPv6 mobile environment, such as PIM-SM [18],
[19] and multicast listening based on MLDv2 [17], require
bidirectional links for their protocol messages.
For dynamically establishment of bidirectional connectivity based
on unidirectional links, dynamic LLTM protocol [1] was proposed,
which is adding a layer between the network interface and the routing
software to emulate the full bidirectional connectivity using Internet
tunnels. The focus of the UniDirectional Link Routing (UDLR) Working
group was to integrate LLTM to support Internet routing and multicast
services on UDLs such as satellites.
Application of LLTM in different scenarios was studied.
Experiments with IGMP protocol in Ipv4 environment using LLTM are
reported in [14]. Configuration issues of the multicast routing
protocol DVMRP for UDLs based on LLTM are addressed in [12].
Usage of LLTM to support Ipv4 multicast receivers connected over
UDLs to IPv6 infrastructures is described in [13].
Menzel Expires September 4, 2006 [Page 5]
INTERNET-DRAFT Mobile nodes with UDLs in Ipv6 April 2006
This document extends the current state-of-the art of LLTM usage
for mobile nodes with unidirectional links adapting the LLTM
mechanisms to the mobile IPv6 requirements. The usage of LLTM in
MIPv6 environment, when the mobile node moves, depends on the
possibility of establishment of Internet based connections for the
tunnels emulating the bidirectional links.
Figure 1 describes a scenario based on mobile nodes with UDLs
in IPv6 mobile environment using Access Routers acting as "feeds"
and mobile nodes as "receivers" considering the LLTM terminology.
+------+ +----------------------+ +--------+
+---->| pAR | --->| INTERNET | <--- | nAR |---+
| +------+ +----------------------+ +--------+ |
| | | |
| | | |
| pAR_Feed v v nAR_Feed |
| +-------------+ +-------------+ |
| | pAR_BDL | | nAR_BDL | |
| |-------------| |-------------| |
| | pAR_UDL | | nAR_UDL | |
| UDL_pAP--->+-------------+ +-------------+ <--UDL_nAP|
| | | |
| | | |
| v MN MN v |
| +-------------+ +--------------+ |
| |pCoA_UDL | handover|nCoA_UDL | |
| | ----------- | ------> |--------------| |
+<----------|pCoA_BDL | |nCoA_BDL |--------->+
+-------------+ +--------------+
Figure 1: UDL topology based on "receiver" mobile nodes and feed AR
An example for a mobile node with "receive only" capable
unidirectional link in MIPv6 is the mobile terminal with DVB-T
reception antenna supporting Digital Video Broadcasting.
In this scenario, mobile nodes with "receive-only" capable UDLs are
considered, which MUST be in addition equipped with other
wireless links providing bidirectional connectivity such as UMTS,
WLAN (IEEE 802.11x), or IEEE 802.16-2004 promoted by the WiMAX Forum.
The equipment of the mobile node with additional bidirectional wireless
links is required for emulation of bidirectional connectivity using LLTM.
Before the handover, the mobile node was attached to an access point with
unidirectional link (UDL_pAP) using the previous AR acting as Feed
(pAR_Feed). After the handover, the mobile node moves its attachment to
the next access point (UDL_nAP) using the nAR acting as Feed (nAR_Feed).
Menzel Expires September 4, 2006 [Page 6]
INTERNET-DRAFT Mobile nodes with UDLs in Ipv6 April 2006
During the movement, it is a need to establish the bidirectional
connectivity to the next AR Feed (nAR_Feed) using the additional
bidirectional wireless link of the mobile node.
The handover due to a new access point for the UDL is independent on the
handover to a nAR connected to the bidirectional wireless links.
The usage of LLTM requires a guarantee that the mobile node is connected
over the additional bidirectional wireless link to the Internet and there
is a route available to the AR Feed connecting the node with UDL.
The routing and management requirements for the additional BDL interface
are not focus of this document. The particular goal of this document is
to define mechanisms in Mobile IPv6, which allow to provide efficient
handover based on learning of the next Care-of address for the UDL
interface together with the feed information to provide BDL connectivity.
Currently in the mobile IPv6 [4], the configuration of a new Care-of
address for the mobile node is defined based on the Neighbor Discovery
[23], stateless [24] and stateful [25] configuration, but
the particular issues of configuration of care-of addresses for mobile
nodes with UDL is still not considered. It requires not only to obtain
information for the next Care-of Address of the UDL interface, but also
to get simultaneously the feed endpoints established at the next AR for
emulation of bidirectional connectivity.
Further requirements are to support the same tunneling protocol and link
layer addressing schemes at the mobile node and access router feed.
For this purpose the Generic Routing Encapsulation (GRE) [2] with
Ipv6 as delivery protocol could be used. Interoperable link layer
addressing for the BDL emulation should be also guaranteed.
As it is shown in figure 2, the LLTM packet using GRE for encapsulation
and IPv6 as delivery protocol has the following format:
+-------------------------------------------+
| Delivery Header (IPv6 header) |
| dest address = feed_IP_addr |
| next header = 47 (GRE) |
+-------------------------------------------+
| GRE Header ( |
| prototype=ETHER_TYPE(emulated link layer) |
| . . . . . . ) |
+-------------------------------------------|
| MAC header of emulated link layer |
| IPv6 Encapsulated packet |
+-------------------------------------------+
Figure 2: Packet encapsulation using Ipv6 and GRE
Menzel Expires September 4, 2006 [Page 7]
INTERNET-DRAFT Mobile nodes with UDLs in Ipv6 April 2006
The destination address of the Ipv6 header is the feed tunnel end
point at the AR. The "next header" field of the IPv6 header is 47,
pointing on the IP protocol number of the GRE protocol described by
the following header [0]. The prototype field of GRE header
shows the type of the emulated BDL [21], which SHOULD be supported
by the mobile nodes and feed ARs.
In mobile environment, there are always requirements to reduce the
overhead of the mobile nodes. Therefore, the sending intervals of
the "HELLO" messages for announcing tunnel end-points as defined in
Dynamic Tunneling Configuration Protocol (DTCP) should be adapted
for the mobile environment.
In order to establish bidirectional connectivity network between the
"feed" and "receivers", there is a need to advertise the "feed"
information of the new access router
(currently sent by "HELLO" message) during
the handover processing using IPv6 Mobility protocols.
This should accelerate the services concerning dynamic address
configuration of mobile nodes with UDLs during the handover.
In particular, this document proposes to learn the AR feeds more quickly
based on extensions of mobile IPv6 packets with a new option for handling
of UDLs, which contains information derived from the "HELLO" message.
The cause is that based on the "HELLO" messages the learning of the
"feeds" of the mobile node with unidirectional links during the
handover is delayed after its attachment on the new links and that is an
unacceptable delay for the configuration of mobile node's
Care-of address in IPv6.
In summary, the requirements for handling of mobile nodes with UDLs
using LLTM in MIPv6 are:
- Support of mobile nodes with unidirectional links during
handover for quickly care-of address configuration based on feed
information provided by the access routers.
- Adapting DTCP parameter for mobile environment based on reducing
the overhead to the mobile nodes.
- Supporting of interoperable tunneling protocol type (GRE with
IPv6 as delivery protocol is recommended) and link layer
addressing scheme for bidirectional link emulation.
- Management of mobile access router connectivity in order to
guarantee the connections using the additional bidirectional
wireless links to the feed ARs.
Further requirements for unidirectional link handling could arise
considering specific scenarios, as for instance multicast feedback
implosion problem, but they are out of scope.
Menzel Expires September 4, 2006 [Page 8]
INTERNET-DRAFT Mobile nodes with UDLs in Ipv6 April 2006
5. Integration of unidirectional link tunneling information in IPv6 mobility
protocols
This document proposes the Unidirectional Link tunneling information,
which is RECOMMENDED to enhance the Mobile IPv6 messages defined in
MIPv6 [4], Fast Handovers [15] and CARD protocol [6] in order to
establish dynamically the bidirectional connectivity of a mobile node with interfaces
to unidirectional links.
This option is used to get the IPv6 address for the "feeds" of the
a access router providing the upstream connectivity of the mobile node
with the unidirectional link.
There are different alternatives to include the option in IPv6 Mobility
protocols:
- Router Advertisement Message used in Mobile IPv6 [4]
- Proxy Router Advertisement Message defined in Fast Handovers
for MIPv6 [15]
- Reply message of the CARD [6].
The Unidirectional Link Handling option is described by:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Option Length | <Feed information ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ààààà.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- Option Type - To be defined by IANA.
- Option Length (8-bit unsigned integer) - representing the length
in octets of the Feed Information (FeedInfo).
The Feed Info includes for each Access Point Identifier the
established feed tunnel end-points at the access router.
It is defined by following descriptions:
o UdlAP (48 Bit) Access Point Identifier identifying the
IEEE MAC address of layer 2 device offering the
unidirectional connectivity
o FU_IP (128 bit) L3 (IPv6) address of the "feed" AR to the
unidirectional link
o FU_L2 (48 bit) L2 (MAC) address corresponding to FU_IP as
agreed for the bidirectional emulation of the particular
link.
Menzel Expires September 4, 2006 [Page 9]
INTERNET-DRAFT Mobile nodes with UDLs in Ipv6 April 2006
o Tunnel type (8 bit unsigned integer) defined by the
tunneling protocol type assigned by IANA [20].
Recommended is GRE [2]. Obtaining new values for
tunnelling protocols is documented in [3].
o F (1 bit) - Indicates the type of feed (send-only, receive-
only)
o NmbFeedInfo (4 bit unsigned integer) - Number of feed
information tuples.
o ListFeedInfo List of feed information tuples. Each tuple
includes:
- IPv6 address (128 bit) of feed tunnel end-point
- L2 (MAC) address (48 bit) of the feed tunnel end point
as agreed for the bidirectional emulation of
the particular link.
6. Operational considerations
The information for unidirectional link tunneling in Mobile IPv6
is used at the mobile receivers connected to the unidirectional links
to obtain dynamically the upstream tunneling information for
establishment of bidirectional connectivity.
The mobile receiver could get this information based on mechanisms
provided of Mobile IP6, Fast Handovers for MIPv6 or CARD protocol.
6.1 Mobility support for Ipv6
The unidirectional link handling option in the framework of MIPv6
[4] COULD be integrated in the "Options" Part of the Router
Advertisement Message [23] specified for MIPv6 [4].
This allows before the configuration of a new on-link care-of-
address of the mobile node based on the prefix included in the
Router Advertisement also to establish the tunnel endpoints to the
feed for bidirectional communication using the unidirectional links.
In Mobile IPv6 routers advertise their presence using Router
Advertisement Messages either periodically (unsolicited) or in
response to Router Solicitation message sent by the Mobile Node.
MIPv6 specifies the requirements for sending of unsolicited Router
Advertisement in Mobile IP [4].
When a mobile node attaches to a new "receive-only" unidirectional
link at the first time, it cannot send Router Solicitation messages
as proposed in [23] to locate default routers and learn
prefixes more quickly.
It SHOULD first receive an unsolicited Router Advertisement Message
with Option for unidirectional link Handling.
Menzel Expires September 4, 2006 [Page 10]
INTERNET-DRAFT Mobile nodes with UDLs in Ipv6 April 2006
In order to provide timely movement of mobile nodes with
UDLs, the "routers supporting mobility SHOULD be able to be configured
with a smaller MinRtrAdvInterval value and MaxRtrAdvInterval value to
allow sending of Unsolicited multicast Router Advertisements more often"
as this is generally required in [4].
After establishment of tunnel end-point for bidirectional connectivity,
the mobile node can configure its care-of address based on:
- Stateless Address Configuration [24], and/or
- Stateful Address Configuration using Dynamic Host Configuration
[25].
When the new connection is established, the mobile node can send Router
Solicitations for specific events described in [23], such as
temporary loss of connection.
Mobile Node Access Router
| |
| unsolicited RtAdv(UdlOpt) |
| <-------------------------|
| |
|*tunnel establ. [1] |
|*care-of address config. [24],[25] |
Figure 3: Unidirectional link handling in MIPv6
6.2 Fast Handovers for Ipv6
IPv6 Fast Handovers has been proposed in the Internet Draft [15]
in order to minimize the interruption in services experienced by a Mobile
IPv6 node as it changes its point of attachment to the Internet.
IPv6 Fast handover is complementary to IPv6, therefore the technique
to include Unidirectional Link Handling Option in Router Advertisement
will be also used in the Fast Handovers protocol.
IPv6 Fast Handovers protocol integrates two strategies for mobile node
movement called predictive and reactive handover. They are based on the
same procedures using the Proxy Router Advertisement Message to advertise
the next AR information for configuration of the new Care-of address for
the mobile node. It is sent from the previous AR to the mobile node to
supply next access router information (AR-Info) about new access points.
In the framework of IPv6 Fast Handovers, the UDL handling option COULD
be included in the "option" part of the Proxy Router Advertisement
Message (PrRtAdv). In case that the node moves to a next AR, the UDL
handling option will supply the feed information of the next AR for
bidirectional connectivity establishment.
Menzel Expires September 4, 2006 [Page 11]
INTERNET-DRAFT Mobile nodes with UDLs in Ipv6 April 2006
IPv6 Fast Handovers begins when a MN sends RtSolPr to its current
access router to resolve one or more Access Point Identifiers (AP-
IDs) to subnet-specific information.
In response, the access router sends a PrRtAdv message, which contains
one or more [AP-ID, AR-Info] tuples. The PrRtAdv message SHOULD include
the UDL handling option with AR-FeedInfo for requested Access Points
(AP-IDs), which are based on unidirectional connectivity.
The new AR-FeedInfo is used to update the mobile node information for
BDL emulation. With the AR-Info information included in the PrRTAdv
message, the mobile node formulates a prospective next Care-of address
establishing the tunnel end-points for its BDL emulation.
Performing this, it sends:
- Fast Binding Update message to the previous AR in the case of
"Predictive" Fast Handover.
- Fast Binding Update message to the next AR in the case of
"Reactive" Fast Handover.
In case that the mobile node does not receive AR-FeedInfo for BDL
emulation, it does not perform the binding update.
The specific steps for handling of movement of mobile nodes with
UDLs in Fast Handovers MIPv6 are shown in figure 4:
Mobile Node Prev-AR Next-AR
| | RtAdv (UdlOpt) |
| | <----------------|
|RtSolPr(UdlAP-Id) | |
|----------------> | |
| | |
| PrRtAdv (UdlOpt)| |
| <----------------| |
| | |
|* tunnel establ. [1] | |
|* nCoA config. [24],[25] | |
Figure 4: Unidirectional link handling in Fast Handovers MIPv6
6.3 UDL handling with CARD protocol
The Candidate Access Router Discovery (CARD) protocol was designed
to support the acquisition of information about the possible next ARs
that are candidates for the mobile node's handover [6].
This document proposes to use CARD to report UDL feed information,
when selecting a next router with UDLs.
Menzel Expires September 4, 2006 [Page 12]
INTERNET-DRAFT Mobile nodes with UDLs in Ipv6 April 2006
CARD protocol is used in EU project DAIDALOS [22] together
with the Context Transfer protocol [5] and IPv6 Fast Handovers
[15] for efficient handover aimed at optimization of service
re-establishment in case of MIPv6 node handover.
The UDL handling option is included as sub-option in the CARD
Reply Signalling message exchanged between access routers and mobile
nodes, in order to provide the feedback information to the mobile node,
arriving at the access network with unidirectional link.
The signalling messages using CARD protocol for reporting of unidirectional
link informations are shown in figure 5:
Mobile Node Prev-AR Next-AR
| | |
| |AR-AR CARD Request |
| |------------------> |
| | |
| | AR-AR CARD Reply(UdlOpt)|
| | <---------------------- |
|MN-AR CARD Request | |
|------------------ > | |
| | |
| MN-AR CARD Reply(UdlOpt)| |
| <------------------------| |
|*selection of optimal CAR | |
|*tunnel establ. | |
|*nCoA config. | |
Figure 6: Unidirectional link handling based on CARD
7. IANA considerations
IANA should record a value for Unidirectional Link Handling Option
(Mobile IPv6 Option).
8. Further work
The integration of unidirectional link handling in mobile IPv6
is important for efficient handover using technologies based on
DVB-T and satellites to connect mobile users.
Facilities for handling of unidirectional links in IPv6 based on
LLTM [1] with extensions for IPv6 mobility are proposed.
LLTM with GRE support [2] is implemented in DAIDALOS EU project
for mobile Ipv6 heterogeneous networking environment in
interaction with Mobile IPv6, Fast Handovers IPv6 and CARD Protocol.
Menzel Expires September 4, 2006 [Page 13]
INTERNET-DRAFT Mobile nodes with UDLs in Ipv6 April 2006
The scenarios for LLTM usage in DAIDALOS are based on DVB-T with
access routers acting as feeds and mobile nodes as receivers.
Other issues such as security and routing implications in case of
unidirectional links are topic of further work.
References
[1] Duros, E., Dabbous, W., Izumiyama, H., Fujii, N., and
Y.Zhang, 'A Link-Layer Tunneling Mechanism for Unidirectional
Links', RFC 3077, March 2001
[2] D. Farinacci, T. Li, S. Hanks, D. Meyer, and P.
Traina, "Generic Routing Encapsulation", RFC 2784 March 2000.
[3] Bradner, S. and V. Paxson, "IANA Allocation Guidelines For Values
In the Internet Protocol and Related Headers",
RFC 2780, March 2000.
[4] D. Johnson, C. Perkins, J. Arkko, Mobility Support in IPv6,
RFC 3775, 2004
[5] J. Loughney, M. Nakhjiri, C. Perkins, R. Koodli, Context Transfer
Protocol, RFC 4067, 2005
[6] M. Liebsch, A. Singh, H. Chaskar, D. Funato, E. Shim,
Candidate Access Router Discovery, RFC 4066, 2005
[7] Ng, C., "Analysis of Multihoming in Network Mobility Support",
draft-ietf-nemo-multihoming-issues-05 (work in progress),
February 2006.
[8] ETSI: "Digital Video Broadcasting (DVB); Framing structure, channel
coding and modulation for digital terrestrial television (DVB-T)",
European Standard EN 300 744
[9] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[10] J. Manner, M. Kojo, Ed., "Mobility Related Terminology",
Network Working Group, Request for Comments: 3753, Category:
Informational, March2004
[11] P. Basu, and K. Kanchanasut. "A Multicast Push Caching System over
a UDLR Satellite Link", in SAINT 2003 Satellite Internet Workshop,
IEEE Computer Society, Orlando, January 2003
Menzel Expires September 4, 2006 [Page 14]
INTERNET-DRAFT Mobile nodes with UDLs in Ipv6 April 2006
[12] C. Benassy-Foch, P. Charron, Y. Guinamand, Configuration
of DVMRP over a unidirectional link, UDLR Working Group, IETF
Draft, June2002, Work in Progress
[13] E. Duros et al., Experiments with RFC 3077, Internet-Draft,
<draft-ietf-udlr-experiments-00.txt>, October 2002, Work in Progress
[14] J.Takei, H.Izumiyama, Identifying Multicast Implications in a
Link-Layer Tunneling Mechanism for Unidirectional Links,
Internet-Draft, Network Working Group, February 2002,
<draft-ietf-udlr-multicast-issues-00.txt>, Work in Progress
[15] R. Koodli (ed.), Fast Handovers for Mobile Ipv6,
draft-ietf-mipshop-fast-mipv6-02.txt, November 2004, Internet
Draft, Work in Progress
[16] A.H. Thamrin, H. Izumiyama, H. Kusumoto, PIM-SM Configuartion
and Scalability on Satellite Unidirectional Links,
Proceedings of the 2003 Symposium on Applications and the Internet
Workshops (SAINT'03 Workshops), January, 2003
[17] R. Vida, and L. Costa, "Multicast Listener Discovery Version 2
(MLDv2) for IPv6", RFC 3810, March2004.
[18] D. Estrin, D. Farinacci, A. Helmy, D. Thaler, S. Deering, M.
Handley, V. Jacobson, C. Liu, P. Sharma, L. Wei, "Protocol
Independent Multicast-Sparse Mode (PIM-SM): Protocol Specification",
RFC 2362, Network Working Group, Experimental, June, 1998
[19] B. Fenner, M. Handley, H. Holbrook, and I. Kouvelas.
"Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol
Specification (Revised)," draft-ietf-pim-sm-v2-new-10.txt,
July 2004, Work in Progress
[20] IP Protocol Numbers, last updated 18 October 2004,
http://www.iana.org/assignments/protocol-numbers
[21] Ether Types, last updated 23 February 2006,
http://www.iana.org/assignments/ether-numbers
[22] Designing Advanced Interfaces for the Delivery and Administration
of Location independent Optimised personal Services,
EU IST project, www.ist-daidalos.org
[23] T. Narten, E. Nordmark, W. Simpson, Neighbor Discovery
for IP Version 6 (IPv6),RFC 2461, 1998
[24] S. Thomson, T. Narten, IPv6 Stateless Address Autoconfiguration,
Request for Comments: 2462, 1998
[25] R.Droms, J.Bound, B.Volz, T. Lemon, C.Perkins, and M.Carney,
"Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315,
July 2003
[26] N. Montavont, R. Wakikawa, T. Ernst, C. Ng, K. Kuladinithi,
Analysis of Multihoming in Mobile IPv6, IETF MONAMI6 Working Group,
Internet-Draft, draft-ietf-monami6-mipv6-analysis-00.txt
(work in progress), February 20, 2006
[27] Ernst, T., "Motivations and Scenarios for Using Multiple
Interfaces and Global Addresses",
draft-ietf-monami6-multihoming-motivations-scenarios-00 (work
in progress), February 2006
Author's Addresses
Olaf Menzel Phone: +49-2241-14-3494
Email: olaf.menzel@fokus.fraunhofer.de
David Wagner Phone: +49-2241-14-3491
Email: david.wagner@fokus.fraunhofer.de
Ilka Miloucheva Phone: +49-2241-14-3471
Email: ilka.miloucheva@fokus.fraunhofer.de
FOKUS - Fraunhofer Institute for Open Communication Systems
CC.SatCom,Schloss Birlinghoven
53757 Sankt Augustin, Germany
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Menzel Expires September 4, 2006 [Page 15]
INTERNET-DRAFT Mobile nodes with UDLs in Ipv6 April 2006
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Menzel Expires September 4, 2006 [Page 16]
