Internet DRAFT - draft-miloucheva-udlr-mipv6
draft-miloucheva-udlr-mipv6
I. Miloucheva,
Internet Draft O. Menzel
Expires: December 4, 2005 SATCOM
June 2, 2005
Support of mobile nodes with unidirectional links in MIPv6
draft-miloucheva-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 December 4, 2005.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This document discusses mechanisms for dynamic establishment of
bidirectional link layer connectivity of mobile nodes with
unidirectional links in Mobile Ipv6 (MIPv6) environment.
Requirements are derived from the need to support services in
mobile Ipv6 based on unidirectional technologies, for instance
Digital Video Broadcasting, using multicast protocols, such as
Protocol Independent Multicast Routing û Sparse Mode (PIM-SM) and
Multicast Listener Discovery (MLDv2).
Miloucheva Expires December 4, 2005 [Page 1]
INTERNET-DRAFT Mobile nodes with UDLs in Ipv6 June 2005
Facilities aimed to reconfigure dynamically the bidirectional
connectivity of mobile nodes with unidirectional links, when the
mobile nodes move from one IPv6 access network to another, are
specified considering the usage of Link-Layer Tunneling Mechanisms
(LLTM) in MIPv6 environment.
A new option for unidirectional link handling containing feed
information for dynamic bidirectional link establishment is defined
to enhance messages of MIPv6 and its complementary protocols.
Scenarios for integration of the proposed unidirectional link
handling option are described based on MIPv6 and its enhancements
for Fast Handovers and Candidate Access Router Discovery (CARD).
Table of Contents
1. Overview.................................................. 2
2. Terminology used in this document......................... 3
3. Requirements of mobile nodes with unidirectional links.... 4
4. Definition of option for unidirectional link handling..... 7
5. Operational considerations................................ 9
5.1 Mobility support for Ipv6................................ 9
5.2 Fast Handovers for Ipv6.................................. 10
5.3 CARD protocol............................................ 11
6. IANA considerations......................................... 12
7. Further work................................................ 12
References..................................................... 12
Author's Addresses............................................. 14
1. Overview
Mobile IPv6 does not attempt to solve all general problems related
to the use of mobile nodes such as handling of links with
unidirectional connectivity [4].
For the integration of technologies based on unidirectional links
(DVB [7], DVB-T [8]) into mobile IPv6 environment, there
is a need to define facilities for dynamic management of the
bidirectional connectivity of mobile nodes, when the mobile node
with the unidirectional link changes the access point and/or moves
from one access network to another.
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], the usage of LLTM is
Miloucheva Expires December 4, 2005 [Page 2]
INTERNET-DRAFT Mobile nodes with UDLs in Ipv6 June 2005
extended for mobile IPv6 services using DVB-technologies based on
unidirectional links in heterogeneous wireless environment.
The goal is to allow efficient integration of IPv6 services and
protocols required for DVB, such as PIM-SM routing [18], [19],
and Multicast Listening Discovery (MLDv2) [17]) in IPv6
mobile network architectures including unidirectional links.
In order to support dynamical 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].
It is based on a definition of a new option for unidirectional link
handling of mobile nodes that COULD be integrated in MIPv6, Fast
Handovers and CARD protocol messages to provide efficient handover.
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].
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.
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)
Miloucheva Expires December 4, 2005 [Page 3]
INTERNET-DRAFT Mobile nodes with UDLs in Ipv6 June 2005
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.
Abbreviations used in the following text:
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
3. Requirements of mobile nodes with unidirectional links
Emulation of bidirectional connectivity for mobile nodes with
undirectional links is required to support mobile IPv6 services.
Bidirectional connectivity is needed for address configuration in
MIPv6 based on Neighbour 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]. PIM-SM based
routing over satellite using LLTM is discussed in [16].
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.
Miloucheva Expires December 4, 2005 [Page 4]
INTERNET-DRAFT Mobile nodes with UDLs in Ipv6 June 2005
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).
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
Miloucheva Expires December 4, 2005 [Page 5]
INTERNET-DRAFT Mobile nodes with UDLs in Ipv6 June 2005
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
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
Miloucheva Expires December 4, 2005 [Page 6]
INTERNET-DRAFT Mobile nodes with UDLs in Ipv6 June 2005
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 before arriving at
the new access network and to estabish BDL emulation at 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.
4. Definition of option for unidirectional link handling
This document proposes the Unidirectional Link Handling Option for
mobile nodes. This is a new optional data structure, which is
RECOMMENDED to enhance the Mobile IPv6 messages defined in MIPv6
[4], Fast Handovers [15] and CARD protocol [6].
This option is used to get information for the "feeds" established
at a new access router for the unidirectional link, to which the
mobile node will be attached as a result of the mobile handover.
The option for UDL handling of mobile Nodes COULD be included as:
Miloucheva Expires December 4, 2005 [Page 7]
INTERNET-DRAFT Mobile nodes with UDLs in Ipv6 June 2005
- Additional Option in Router Advertisement Message used in Mobile
IPv6 [4]
- Additional Option in Proxy Router Advertisement Message defined
in Fast Handovers for MIPv6 [15]
- New Sub-option for usage in the Reply message format in the CARD
protocol [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.
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.
Miloucheva Expires December 4, 2005 [Page 8]
INTERNET-DRAFT Mobile nodes with UDLs in Ipv6 June 2005
5. Operational considerations
The option for unidirectional link handling COULD be integrated in
the context of Mobile IPv6, Fast Handovers MIPv6 and CARD protocols.
It is used at the mobile node to get during the handover the
bidirectional connectivity information for the unidirectional links.
The integration of the option for unidirectional linkhandling in
different message formats is described.
5.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.
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.
Miloucheva Expires December 4, 2005 [Page 9]
INTERNET-DRAFT Mobile nodes with UDLs in Ipv6 June 2005
Mobile Node Access Router
| |
| unsolicited RtAdv(UdlOpt) |
| <-------------------------|
| |
|*tunnel establ. [1] |
|*care-of address config. [24],[25] |
Figure 3: Unidirectional link handling in MIPv6
5.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.
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
Miloucheva Expires December 4, 2005 [Page 10]
INTERNET-DRAFT Mobile nodes with UDLs in Ipv6 June 2005
- 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
5.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].
There are different issues in optimal candidate access router
discovery [11].
This document proposes to use CARD for the selection of a next
router, which supports feeds for UDLs, which are required to support
sevices of the mobile node.
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 could be included as sub-option in the CARD
Reply Signalling message exchanged between access routers and mobile
nodes. The option is used only, when access routers are attached to UDLs
in order to support the router selection by the mobile node.
The steps in usage of CARD for unidirectional link handling are
shown in figure 5:
Miloucheva Expires December 4, 2005 [Page 11]
INTERNET-DRAFT Mobile nodes with UDLs in Ipv6 June 2005
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 5: Unidirectional link handling based on CARD
6. IANA considerations
IANA should record a value for Unidirectional Link Handling Option
(Mobile IPv6 Option).
7. Further work
The discussed topic of integration of unidirectional link facility
for mobile IPv6 networking is important for efficient handover and
provision of services based on unidirectional links, such as DVB
over satellites in IPv6 context.
Facilities are proposed based on usage of LLTM with extensions
for IPv6 mobile protocols.
LLTM with GRE support [2] is implemented in DAIDALOS EU project
in Linux for mobile Ipv6 heterogeneous networking environment in
interaction with Mobile IPv6, Fast Handovers IPv6 and CARD Protocol.
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 for the
described unidirectional link handling 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.
Miloucheva Expires December 4, 2005 [Page 12]
INTERNET-DRAFT Mobile nodes with UDLs in Ipv6 June 2005
[3] Bradner, S. and V. Paxson, "IANA Allocation Guidelines For Values
In the Internet Protocol and Related Headers", BCP 37,
RFC 2780, March 2000.
[4] D. Johnson, C. Perkins, J. Arkko, Mobility Support in IPv6,
RFC 3775, June 2004
[5] J. Loughney, M. Nakhjiri, C. Perkins, R. Koodli, Context Transfer
Protocol, draft-ietf-seamoby-ctp-11.txt, August, 2004
[6] M. Liebsch, A. Singh, H. Chaskar, D. Funato, E. Shim,
Candidate Access Router Discovery, IETF Seamoby Working Group,
Internet Draft, draft-ietf-seamoby-card-protocol-08.txt,
September 2004
[7] ETSI: "Digital Video Broadcasting (DVB); DVB specification for data
broadcasting", European Standard EN 301 192
[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, June 2004
[11] D. Trossen, G. Krishanmurthi, H. Chaskar, J. Kempf,
"Issues in candidate access router discovery for seamless IP-level
handoffs", Internet Draft, 2002, Work in Progress
[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
Miloucheva Expires December 4, 2005 [Page 13]
INTERNET-DRAFT Mobile nodes with UDLs in Ipv6 June 2005
[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, June 2004.
[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 2005,
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),Request for Comments: 2461, December 1998
[24] S. Thomson, T. Narten, IPv6 Stateless Address Autoconfiguration,
Request for Comments: 2462, December 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
Author's Addresses
Ilka Miloucheva
Fraunhofer Institute
SATCOM FOKUS,Schloss Birlinghoven Phone: +49-2241-14-3471
53757 Sankt Augustin, Germany email: ilka@fokus.fraunhofer.de
Olaf Menzel
Fraunhofer Institute
SATCOM FOKUS,Schloss Birlinghoven Phone: +49-2241-14-3494
53754 Sankt Augustin, Germany Email: olaf.menzel@fokus.fhg.de
Miloucheva Expires December 4, 2005 [Page 14]
INTERNET-DRAFT Mobile nodes with UDLs in Ipv6 June 2005
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.
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 (2005). 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.
Miloucheva Expires December 4, 2005 [Page 15]
