Internet Draft Guillermo Rigotti Expires: June 2010 UNICEN December 26, 2009 Decentralized Mobile Multicast .draft-rigotti-d-mobile-multicast-00 Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and 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 January 7, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Abstract The increasing deployment of both, IP multicast and mobility, rises the problem of delivering IPv6 multicast traffic to mobile nodes. This document proposes an approach to the problem, named Decentralized Mobile Multicast, that combines tunnelling and dynamic subscription to the multicast groups. The proposed solution aims to reduce handover time, and to diminish the overhead produced by multicast subscriptions. As a consequence of the decentralized selection of multicast routers, a single point of failure is eliminated. G. Rigotti Expires June 2010 [Page 1] Internet Draft Decentralized Mobile Multicast December 2009 Table of Contents 1. Introduction................................................2 2. Concepts and Operation Overview ...........................4 3. Roles of routers............................................5 4. Operation in the local network..............................8 4.1. Exchange of information about AMRs.....................8 4.2. Extended MLD Reports and Queries.......................8 4.3. Operation..............................................9 5. Tunnels.....................................................9 5.1. Establishment, reconfiguration and completion of tunnels.......................................... ....10 5.1.1. Tunnel establishment.............................10 5.1.2. Tunnel re-establishment..........................11 5.1.3. Tunnel completion................................11 5.2. Exchange of Information...............................11 6. State in routers and MNs...................................12 7. AMR selection algorithm (LMR)..............................14 8. AMR selection algorithm (MN)...............................14 9. Security considerations ...................................14 10. Conclusions ..............................................14 11. References................................................15 Author's Addresses............................................15 Intellectual Property Statement...............................16 Disclaimer of Validity........................................16 Copyright Statement...........................................16 1. Introduction In the last years, there has been an increasing deployment of multicast transmission in the Internet. Multicast protocols consolidated, and a diversity of multicast applications appeared, each with different requirements of quality of service. The advent of mobility, imposes the challenge to develop new solutions that enable to provide multicast service in mobile networks, maintaining QoS and scalability. These solutions have to be based on mobility support [2] and multicast protocols designed for stationary receivers and senders. Two basic approaches has been proposed in [2], MIP-BT and MIP-RS. MIP-BT is based on the creation of a bidirectional tunnel between the home agent and the MN. This approach does not generate overhead due to reconnections to the multicast tree, but have the problems of tunnel convergence and excessive size of the multicast path. G. Rigotti Expires June 2010 [Page 2] Internet Draft Decentralized Mobile Multicast December 2009 Additionally, the home agent becomes a single point of failure. MIP-RS proposes to join to the multicast tree each time a MN changes its L3 point of attachment. The multicast path is near to optimum, but the overhead due to multiple reconnections to the multicast tree can cause loss of packets; additionally, the signalling overhead in the multicast tree can be significant. Other attempts try to combine the characteristics of MIP-BT and MIP-RS to obtain better results, for example [3] [4] [5]. Most of these approaches are dedicated to multicast mobile receivers. The case of multicast mobile senders has been subject of less researching effort. In this document, a solution for the case of mobile receivers is proposed, which considers the following aspects: 1- Tradeoff between the size of the multicast tunnel (MIP-BT) and the overhead caused by frequent subscriptions to the multicast tree (MIP-RS). The protocol must allow to select suitable values considering the conditions of the network, load in routers, and the QoS required by the MNs. In this proposal, the decision process is carried out by the two routers that directly interact with the MN (AMR and LMR). No decision algorithm is proposed here 2- Allow a MN to receive multicast datagrams, still in networks that do not support multicast traffic. We propose the use of an IPv6 tunnel between an MN and its AMR to carry multicast data and control information. The configuration of that tunnel only requires that the MN has obtained its CoA in its current network. 3- Decreasing of handover latency. Handover is the process by which a MN changes its network point of attachment. It is composed by link layer handover (for example, change of AP);layer 3 handover, by which a MN obtains a new CoA, and registering handover (binding update process), that enables the MN to communicate with its home agent and with its correspondent nodes. Reduction of handover latency is critical in certain applications, and in most of the cases improves QoS and diminishes packet loss. Additionally to the above mentioned, exists a delay due to the multicast process, produced by either the subscription to the group (MIP-RS)or by the configuration of the bidirectional tunnel (MIP-BT). In this proposal, total handover latency is composed by L2 handover, plus L3 handover (obtention of a CoA) plus the reconfiguration time of the tunnel between MN and its AMR. 4- Negotiation of loss rate during handover process. According to the QoS negotiated between MN and its AMR, this one will store multicast datagrams addressed for G and send them immediately after tunnel reconfiguration. That negotiation will have to be done whenever a MN changes of AMR. This proposal does not address aspects such as packet identification, detection of network point of attachement, etc. 5- Elimination of points of failure. This is achieved with the dynamic selection of the routers that serve to the MN (AMR and LMR). In this way, points of failure such as Home Agents are eliminated. G. Rigotti Expires June 2010 [Page 3] Internet Draft Decentralized Mobile Multicast December 2009 6- Elimination of tunnel convergence. In this proposal, multiple tunnels for a group G, between MNs and its respective Home agents, are replaced by one tunnel between a selected AMR and the LMR of the network. 7- Diminishing of the overhead caused by frequent joins to the multicast tree (respect to MIP-RS). Depending on the negotiation among AMRs and LMRs, it is possible to configure parameters in such a way that wont produce joins each time that a MN changes of network. 2. Concepts and Operation Overview In our proposal we define two types of roles for the routers, active multicast router (AMR) and local multicast router (LMR). AMR: The AMR is the router that attaches to the multicast tree for a group G, based on the requirements of the MNs or the LMRs. The joining is carried out according to the normal procedures of the multicast protocol in use (for example PIM-SM [6]). A network (LMR) and the MNs attached to it, may be served by different AMRs. The AMR has the following functions: - To participate in the negotiation to select a new AMR for a network - To set up a tunnel with each LMR of the networks that he serves. Through this tunnel, the AMR sends multicast data that the LMR injects in its local network. - To set up a tunnel with each MNs that he serves. Through this tunnel, the AMR sends multicast data to the MN, while the MN does not receive such data from the LMR (or multicast router) situated in its current network. - To buffer multicast datagrams, to send them later to the MN after the handover process. The amount of buffered information depends on the negotiated QoS between the AMR and the MN. LMR: The LMR distributes multicast packets to the MNs located in its network. As explained above, the multicast datagrams can be received through a tunnel with the AMR or directly from the multicast tree (in this case, both roles, AMR and LMR, are performed by the router) The LMR has the following functions: - To distribute multicast data to the MNs located in his network. - To become in AMR or provide information about available AMRs to the MNs located in his network. - To participate in the negotiation to select a new AMR for the network. - To gather multicast control information (MLD) from its local network, to sum it up, and to send the result to the AMR. The following steps describe the actions of routers (acting as AMRs or LMRs) when a MN arrive in a network and joins a multicast group. G. Rigotti Expires June 2010 [Page 4] Internet Draft Decentralized Mobile Multicast December 2009 1- MN1, currently attached to network N1, decides to join group G. He sends a modified unsolicited report [7] (see sect 4.2), 1-to request reception of datagrams addressed to G, and, 2-to solicit the local router (R1) either to act as AMR or to provide an AMR (the resulting AMR is the LMR if it is acting as AMR, or the current AMR of the network). 2-a. If R1 does not recognize modified unsolicited reports, it just joins G (if he was not) and begins to distribute multicast datagrams for G in the local network. Because there is not support to our approach in the network, the process ends.Later, MN1 will repeat this process when he moves to another network. 2-b. If R1 recognizes modified unsolicited reports, in addition to begin to send multicast datagrams addressed to G in the local network, provides MN1 with a reference to an AMR (R1 itself or its current AMR -AMR1-) (this is done according to the state of R1 -see Table 1);. Continue with step 3. 3- When MN1 gets the reference to AMR1, he initiates a process by which AMR1 becomes the AMR of MN1. This enable AMR1 to recognize to MN1 when he changes of network and, after the handover process ,tries to communicate with AMR1 to get the multicast datagrams that have arrived during handover time. 4- MN1 moves to network N2 and gets a new CoA. Immediately, MN1 communicates with AMR1 to get multicast datagrams. AMR1 recognizes MN1 based on a unique identifier generated in step 3. 5- MN1 begins to receive multicast datagrams from AMR1. 6- As in step 1, MN1 sends a modified unsolicited report to the local router, R2. 7-a. If R2 does not recognize modified unsolicited, it just joins G (if he was not) and begins to distribute multicast datagrams for G in the local network. 7-b. If R2 recognizes modified unsolicited reports, because the report has a not null AMR identifier, R2 initiates a process to select an AMR for the network N2 (see Table 1). When this process ends, R2, acting as LMR for N2, will inform its local MNs about the selected AMR; each MN will decide either to change its AMR or not. 8- When MN1 begins to receive multicast datagrams from the LMR (R2), he asks its AMR for stop the sending of multicast datagrams through the tunnel. 9- The LMR (R2) announces the selected AMR to the MNs. Each MN will decide either to retain its current AMR or to request the new AMR to become its AMR. 3. Roles of routers Consider a router R1, and a network N1. R1 is either local (L) or remote (R) with respect to R1. Table 1 sums up the roles that the router R1 can assume based in the following events: 1- the arriving of a MN (MN1) in N1 and the result of the decision algorithm, and 2- the leaving of the G. Rigotti Expires June 2010 [Page 5] Internet Draft Decentralized Mobile Multicast December 2009 last MN joined to G in N1. When MN1 arrives in N1, a local router R1 can be performing the function of LMR, if it was selected previously as a consequence of a previous arriving. In addition, this router may be performing as AMR A router may have no state (NS) (no AMR neither LMR). This means that the router still was not chosen to be LMR or AMR. Exists a unique LMR for the network; this router have to be local to N1. He is chosen when a MN arrives in N1 and tries to join a group G, who is not been received in N1. This router maintains its state of LMR until the last MN joined to G leaves the network. The LMR must be capable to process MLD frames in the local network, to sum this up, and to send the result to the AMR of the network. Exists a unique AMR for the network N1; this router may be either local or remote with respect to N1.The AMR for a network may change. ------------------------------------------------------------------ | \ Router| LMR+AMR |AMR (Local,| LMR (Local) | NS (Local, | | \State | | Remote) | | will be selec-| |Event \ | | | | ted as LMR | |----------------------------------------------------------------| |MN1 arrives |LMR: |AMR: |LMR: |LMR: | |in N1 |1-Cancels|1-Stops be-|1-Cancel tunn|1-Establishes | | |tunnel |ing AMR for|el (internal)|tunnel with | |AMR of MN1 |with curr|N1 |with current |MN1 s AMR | |is selected |ent AMR |2-Leaves G |AMR |2-Informs MNs | |as AMR of N1|2-Establi|if it does |2-Establishes|about new AMR | | |shes tunn|not any cli|tunnel with |3-Becomes LMR | | |el with |ent (as |MN1 s AMR | | | |MN1 s AMR|AMR) |3-Informs MNs|New State = LMR| | |3-Informs| |about new AMR| | | |MNs about|New State =| | | | |new AMR |NS |New state = | | | | | |LMR | | | |AMR: | | | | | |1-Stops | | | | | |being AMR| | | | | |for N1 | | | | | |2-Leaves | | | | | |G if no | | | | | |more clie| | | | | |nts (as | | | | | |AMR) | | | | | | | | | | | |New State| | | | | |=LMR | | | | |----------------------------------------------------------------| Table 1 - States of a router G. Rigotti Expires June 2010 [Page 6] Internet Draft Decentralized Mobile Multicast December 2009 ------------------------------------------------------------------ | \ Router| LMR+AMR |AMR (Local,| LMR (Local) | NS (Local, | | \State | | Remote) | | will be selec-| |Event \ | | | | ted as LMR | |----------------------------------------------------------------| |MN1 arrives |LMR: |New State =|LMR: |LMR: | |in N1 |1-Informs|AMR |1-Informs MNs|1-Establishes | | |MNs that | |that he is |tunnel with | |This router |he is the| |the new AMR |MN1 s AMR | |(R1) is |new AMR | |2-Establishes|2-Informs MNs | |selected as | | |tunnel with |about the new | |AMR for |New State| |selected AMR |AMR | |Network N1 |= LMR+AMR| | |3-Becomes LMR | | | | |AMR: | | | | | |1-Join G |AMR: | | | | |2-Becomes AMR|1-Joins G | | | | | |2-Becomes AMR | | | | |New State= | | | | | |LMR+AMR |New State = | |----------------------------------------------------------------| |MN1 arrives |LMR: |New State =|LMR: |Not applicable | |in N1 |1-Informs|AMR |1-Informs MNs|(does not exist| | |MNs about| |about the new|AMR for N1 | |The current |the new | |AMR | | |AMR of N1 |AMR | | (MN1 s AMR) | | |remains as | | | | | |AMR |New State| |New State=LMR| | | |= LMR+AMR| | | | |----------------------------------------------------------------| |The last MN |LMR: |AMR: |LMR: |Not applicable | |joined to G |1-Cancels|1-Stops |1-Cancel | | |leaves N1 |tunnel |being AMR |tunnel with | | | |with AMR |for N1 |AMR | | | |2-Stops |2-Leaves G |2-Stops being| | | |being LMR|if no more |LMR | | | | |clients | | | | |AMR: | |New State=Ns | | | |1-Stops |New State= | | | | |Being AMR|NS | | | | |for N1 | | | | | |2-Leaves | | | | | |G if no | | | | | |more clie| | | | | |nts | | | | | | | | | | | |New State| | | | | |= NS | | | | |----------------------------------------------------------------| Table 1 (Continuation) - States of a router G. Rigotti Expires June 2010 [Page 7] Internet Draft Decentralized Mobile Multicast December 2009 The AMR must be capable to attach itself to the multicast tree. In Table 1, we show the change of state that routers do in function of the events that appear in the first column. The first row indicates the state of the router, previous to the event. Intersections event/state, show the actions performed by the router, either as LMR or AMR. The last line indicates the new state of the router. NS means no state, i.e. the router is not LMR neither AMR. 4. Operation in the local network 4.1 Exchange of information about AMRs. MNs and LMR exchange information about possibles AMRs. This enable MNs and LMRs to select the appropriated AMR to his requirements. The selection is based on the decision algorithm running in each node; the AMR finally selected depends on the availability of the AMRs. The exchange of information about AMRs is limited to each local network; possibles AMRs are the AMR of the network (if exists), the AMR of each MN and the LMR, if he is performing as AMR. The exchange of information about AMRs is limited to each local network; possibles AMRs are the AMR of the network (if exists), the AMR of each MN, and the LMR if he is acting as AMR. As stated, the information about AMRs is exchanged by means of modified reports issued by MNs and modified queries issued by the LMR (querier). These queries and reports contain information needed to contact the AMR, to negotiate the creation of a tunnel 4.2 Extended MLD Reports and Queries As stated in [7], in section 3.7, it is possible to send additional information in queries and reports. The receiver detects such information because of the size of the frame. Figure 1 shows the additional fields we propose to add to these frames. These fields are the following: -Reserved: this 16 bits are reserved to identify the proposed extension and to carry some information about the capability of the announced AMR (for example, QoS). This field would help MNs and LMRs to select the most appropriate AMR when they perform their decision process. -AMR port, AMR address: these two fields identify respectively the port and the address where the AMR receives requirements to create, or eliminate tunnels. G. Rigotti Expires June 2010 [Page 8] Internet Draft Decentralized Mobile Multicast December 2009 ------------------------------------ | Type | Code | Checksum | |----------------------------------| |Max. Resp. Delay | Reserved | |----------------------------------| | | | Multicast Address | | | | | |----------------------------------| | Reserved | AMR port | |----------------------------------| | | | | | AMR Address | | | ------------------------------------ Figure 1 - Extended MLD Queries and reports 4.3 Operation In the local network the LMR is in charge to distribute multicast datagrams to the MNs, and, as querier router, to exchange MLD frames with the MNs. The extended frames that are interchanged by LMR and MNs are interpreted correctly by stationary nodes receiving multicast datagrams and participating in MLD exchange. A MN who wishes to receive multicast data for a group G, emits an extended unsolicited report. If he is being served by an AMR, the additional fields of that report contains the address and port of his AMR; if the MN has not yet an AMR, these fields are zeroed. The querier router begins to assume his role of LMR when he receives for first time an extended unsolicited report, issued by an MN. The LMR, based on its decision algorithm and in the information contained in the unsolicited report, will either attach himself to the multicast tree (if not attached), or to contact the AMR to negotiate the establishment of a tunnel. In both cases, when the MN begins to receive multicast data emitted by the LMR, he asks his AMR for stop the sending of data through the tunnel. The AMR and the MNs periodically announce their AMR with the purpose that each of them can choose the best one for its requirements 5. Tunnels In order to interchange data and control information, bidirectional tunnels are established between each LMR and its AMR, and between each MN and its AMR. G. Rigotti Expires June 2010 [Page 9] Internet Draft Decentralized Mobile Multicast December 2009 For more information about the characteristics of these tunnels see [8]. A protocol is needed for communication between MN (LMR) and AMR through the tunnel. For simplicity, we define the same protocol for both kinds of tunnels; in the case AMR-LMR, the complete functionality is not used. For a brief, non-formal description of the protocol, see section 5.2. 5.1 Establishment, reconfiguration and termination of tunnels. These operations (with exception of termination, see below) are initiated by the node that solicits to be served (MN or LMR). He sends its requirement to the address (address and port published in extended reports and queries, as stated above) in which the AMR is listening, Interchanged PDUs between MN (LMR) and AMR can be encapsulated either in UDP or TCP. In the next sections, we will refer to the MN (LMR) as the tunnel client, and to the AMR as the tunnel server. 5.1.1 Tunnel Establishment This operation does not require security considerations.Any MN (LMR) that knows the address and port of an AMR, can require its services. Optionally, an AMR can be configured to accept only a set of clients In these cases, it is necessary to define the set of clients and to implement procedures to recognize its members. Immediately after the tunnel is established, security information is exchanged between the AMR and its client. This information will be used to identify the client when he changes its CoA and requires reestablishment of the tunnel. The establishment of the tunnel involves two PDUs, resulting in a two-way delay. The client sends its requirement, containing its HoA (this identifies univoquely the client), its CoA, and a list of its QoS requirements, if any. Each one is specified in TLV format, and includes the desired value and the minimum acceptable value. If the AMR cannot satisfy the minimum requirements, indicates this fact to the client, cancelling the request. In the case that the AMR have enough resources to satisfy the requirements, it sends a confirmation to the client, indicating, for each QoS parameter, the value granted (between the minimum and the desired). These values are specified in TLV format. Simultaneously with the sending of the confirmation, the AMR sets up the tunnel. The traffic of the tunnel is protected using IPSec. Once the tunnel is established, the AMR sends a cipher key,its index in the table of the AMR, and two strings randomly generated; these elements will serve the AMR to securely identify the client when G. Rigotti Expires June 2010 [Page 10] Internet Draft Decentralized Mobile Multicast December 2009 this solicit tunnel reestablishment using a new CoA. 5.1.2 Tunnel reestablishment This operation requires security measures to protect a client from impersonation on the part of a misbehaved host. He can impersonate the AMR or the client. In both cases, the client will not be able to communicate with the AMR, resulting in loss of data. The steps to re-establish the tunnel are the following. The client sends a requirement to re-establish the tunnel, to the address and port of the AMR. This message contains the HoA that identifies the client, the index associated with the cipher key, and the ciphered concatenation of HoA, CoA and the string1 provided by the AMR at tunnel establishment time. The AMR deciphers the information using the correspondent key, and checks its validity. If it is not valid, ignores the requirement. In the case it is valid, he sends a response that includes the ciphered string2 (provided at tunnel establishment), to avoid AMR impersonation. Immediately after these verifications, the tunnel is reconfigured and new security information is provided to the client for the next tunnel reestablishment. 5.1.3 Tunnel termination The completion of the tunnel happens by explicit requirement of one of the parts or by absence of activity in the channel (information, control or keep alives) during a time greater than the maximum configurated. Tunnel termination information travels through the tunnel, and therefore it does not require additional security considerations. 5.2 Exchange of information Information exchanged through tunnels consists of multicast data, data control information and tunnel Management information. The AMR send each datagram to the client immediately after it arrives, and, when required by the client, send buffered datagrams received previously. In order to conserve the order of the datagrams, each one is tagged with a sequence number. Data control information enables the client to stop (stop) or to start (start) the sending of data on the part of the AMR. It is also possible to request buffered datagrams (for example after reconnection of the MN) (continue); in this case, a number of tagged datagrams is sent, according to the negotiated QoS. Management information allows each endpoint to verify the state of the other. If an endpoint does not detect activity of the other for a period of time greater than the contents of keepalive variable, it cancels the tunnel. This is done to recover unnecessary resources wasted in maintaining non used tunnels. The value of the keepalive timer must be negotiated at the establishment of a tunnel. In the case that a client is a MN, the handover time must be considered. G. Rigotti Expires June 2010 [Page 11] Internet Draft Decentralized Mobile Multicast December 2009 An andpoint that is not sending data, must indicate its presence by sending keepalive at regular intervals. The PDUs exchanged are the following: - Data (AMR to LMR/MN): multicast datagrams for group G. Each Data has a sequence number that indicates the order in wich it was received by the AMR. - Start (MN/LM to AMR): The client asks for the AMR that initiates (or continue, if it was stopped) the transfer of multicast data. - Stop (MN/LMR to AMR): The client asks for the AMR that stops the data transfer through the tunnel. The MN asks for it to the AMR when it has begun to receive native multicast data through the network to which it is connected. The LMR asks for it to the AMR when in spite of not having more members of group G in its local network, it wishes to conserve the tunnel. - Continue (MN to AMR): The MN asks for the AMR to send buffered data. It indicates the sequence number of the first datagram it wishes to receive. Typically, this is used by the MN after a handover. - Alive (bidirectional): Periodically exchanged between client and server, when there is no activity in the channel. - Cancel (bidirectional): Used by either the client or the server to terminate the tunnel. The MN should send a cancel when it leaves group G. The AMR could send a cancel as a consequence of lack of resources. 6. State in routers and MNs Routers that plays roles of AMR or LMR, must have multicast capacity The AMR must be able to attach to a multicast tree, executing the multicast protocol of the domain. The LMR must be able to process MLD information. A router can act simultaneously like AMR and LMR for the same group. In this case the implementation of the tunnel is internal, and depends on the implementation. The state maintained by each node is the following: - AMR: For each tunnel: a- Multicast Group b- Local Endpoint (interface address) c- Remote Endpoint (MN CoA or LMR Address) d- Tunnel state (sending/stopped) e- Number of buffers assigned to store multicast datagrams f- Pointer to the older datagram stored in buffers g- Pointer to the last datagram stored in buffers (the last received) h- Cancel timer: It contains the remaining time after which the G. Rigotti Expires June 2010 [Page 12] Internet Draft Decentralized Mobile Multicast December 2009 tunnel will be cancelled due inactivity of the remote endpoint This timer is restarted each time activity of the remote endpoint is detected. i- Keepalive Timer: It contains the remaining time after wich this node must send a keepalive to indicate activity to the remote endpoint. This timer is restarted each time this node sends a message to the remote endpoint. If the remote endpoint is a MN, the AMR keeps variables associated with security. These are the following: j- Idx: Index of the key used to cipher information in the handshake for tunnel reestablishment. k- String1, string2: Random generated strings for authentication of both, client and server. l- HoA: MN s Home Address. It serves as a univoque identification of the MN. m- CoA: last MN s Care of Address known by the AMR. - LMR For each tunnel: a- Multicast Group b- Local Endpoint (interface address) c- Remote Endpoint (AMR Address) d- Tunnel state (sending/stopped) e- Local interface towards the MNs f- MLD information relative to the interface towards the MNs. - MN a- Multicast Group b- Local Endpoint (interface address) c- Remote Endpoint (AMR Address) d- Tunnel state (sending/stopped) e- Cancel timer: It contains the remaining time after which the tunnel will be cancelled due inactivity of the remote endpoint This timer is restarted each time activity of the remote endpoint is detected. f- Keepalive Timer: It contains the remaining time after wich this node must send a keepalive to indicate activity to the remote endpoint. This timer is restarted each time this node sends a message to the remote endpoint. g- Idx: Index of the key used to cipher information in the handshake for tunnel reestablishment. h- cipher key i- String1, string2: Random generated strings for authentication of both, client and server. j- HoA: MN s Home Address. k- CoA: last MN s Care of Address (current if it is attached to a network) l- pCoA: previous CoA. G. Rigotti Expires June 2010 [Page 13] Internet Draft Decentralized Mobile Multicast December 2009 7. AMR selection algorithm (LMR)` Each LMR decides either to become the client of one of the AMRs announced by the MNs attached to its network, or becomes itself AMR, attaching itself to the multicast tree. The decision is based mainly on the resulting overhead in the multicast tree. This algorithm is not considered in this document. 8.AMR selection algorithm (MN) Each MN select its AMR between its current AMR or one of the announced by its LMR. The selection is based on QoS (tunnel size, datagrams buffered, etc.). This algorithm is not considered in this document. 9. Security Considerations Security must be considered in the establishment, the reestablish ment and the termination of tunnels; it must involve mutual authentication, integrity protection, and protection against replay attacks. In addition, confidentiality is needed for the information that is sent through the tunnels, since it involves control and management information. - Tunnel establishment: It can be allowed to any MN to connect itself to an AMR; in this case security measures are not needed. If an AMR wishes to restrict its possible clients, it must use an authentication mechanism. - Tunnel re-establishment: Security must be implemented to avoid impersonation of both, MN and AMR. See section 5.1.2. - Tunnel termination: This operation only involves traffic sent through the tunnel. It is enough to assure the information that is sent through the tunnel. - Information sent through the tunnel: It is assured using security headers provided by IPv6. 10. Conclusions This document has presented an approach to deliver IPv6 multicast data to mobile nodes. The main characteristics of this proposal are the following: -Flexibility : A MN can decide which of the known AMRs satisfies better its requirements (delay, amount of buffered datagrams, etc.). A router can decide to join itself to the multicast tree or to attach itself to other router acting as AMR, in function of network resources and charge on the router. All these decisions depend on the MN s decision algorithm and the AMR s decision algorithm respectively. -Deployment: A MN is able to receive multicast data when visiting G. Rigotti Expires June 2010 [Page 14] Internet Draft Decentralized Mobile Multicast December 2009 areas that have not multicast support. -Elimination of single points of failure: a MN does not depend on a central point (for example the home agent) to receive multicast data; if it results disconnected of its AMR, it can reconnect with another router acting as LMR in its current network. -Efficiency: acting as LMR, a router eliminates the problem of tunnel convergence if several MNs joined to the same multicast group are attached to his network. With respect to the overhead due to joining to the multicast tree, routers can decide to do it or not, since they know the AMRs of the MNs attached to the network. -Reduction of handover latency: a MN can re-establish the tunnel with its AMR, immediately after obtaining a new CoA. 11. References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. [2] Johnson, D., Perkins C., and Arkko, J., "Mobility Support in IPv6", RFC 3775, June 2004. [3] Soliman, H., Castelluccia, C., El-Malki, K., Bellier, L. "Hierarchical Mobile IPv6 mobility management", RFC 4140, August 2005. [4] Hong-Ke Zhang, Bing-Yi Zhang, Bo Shen, "An efficient dynamic multicast agent approach for mobile IPv6 multicast", Academic Open Internet Journal, Volume 17, 2006, ISSN 1311-4360. [5] Harrison, T.,Williamson, C, Mackrell, W. and Bunt, R.,"Mobile Multicast (MoM) Protocol: Multicast support for mobile hosts", in: Proceedings of ACM/IEEE MOBICOM 97 (Sep. 1997). [6] B. Fenner, M. Handley, H. Holbrook, I. Kouvelas, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", RFC 4601, August 2006. [7] Deering, S., Fenner, W. and B. Haberman, "Multicast Listener Discovery (MLD) for IPv6", RFC 2710, October 1999. [8] Conta, A., Deering, S., "Generic Packet Tunneling in IPv6. Specification", RFC 2473, December 1998. Authors' Addresses Guillermo Rigotti ISISTAN. G. Rigotti Expires June 2010 [Page 15] Internet Draft Decentralized Mobile Multicast December 2009 UNICEN - Fac. Ciencias Exactas. Tandil - Bs. As. - Argentina Phone: +54 - 2293 - 440363 FAX: +54 - 2293 - 440362 Email: guillermo.rigotti@gmail.com G. Rigotti Expires June 2010 [Page 16]