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 | | | | | | | 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, , 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, , 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]