[5] Erik Guttman « Service Location Protocol Modifications for IPv6 » IETF, draft-ietf- srvloc-ipv6-12.txt, February 2001. [6] Erik Guttman, Charles Perkins and al.
IPv6 Unicast Protocol for Small Group Communication Mouhamadou Lamine Diagne, Thomas Noel LSIIT - Pôle API - Boulevard Sébastien Brant - 67400 Illkirch-Graffenstaden Tel: (33) 03 90 24 45 92 – Fax: (33) 03 90 24 44 55 {diagne, noel}@dpt-info.u-strasbg.fr Abstract: This article aims to extend the IPv6 Communication Redirection protocol (IPCR) that we defined. This protocol was used to make nomadic existing IPv6 communications by using existing mechanisms such as Service Location Protocol (SLP) and the improvements of the Internet Protocol in its version 6 (IPv6). In this paper we will include a transformation of a communication between two stations to a group communication. As a result, IPCR allows one or more stations to take part in an existing unicast communication by only using mechanisms of unicast communication. KEYWORDS: Hierarchical mobility, communication redirection, group communication, unicast communication.
INTRODUCTION IPv6 Communication Redirection (IPCR) [2] is a new protocol that we defined. With this protocol we are able to put a communication through to another person as it already exists in telecommunication networks. Indeed, IPCR protocol allows to redirect an IPv6 communication from a host to another one. In this article, we will extend IPCR by introducing a new function which is the conference between three or more members. This service allows us to transform a communication between two members to a communication between three or more members by letting one or more other persons to take part in the initial communication. We notice that we only use the mechanisms of unicast communication. For instance, we assume that there is a videoconference between two stations using a unicast communication. If a third station and possibly others would like to participate in this videoconference, then one has to interrupt it and to initiate another videoconference using a multicast group in which these stations will be members by joining it. With IPCR, there will not be this interruption during the videoconference because we are able to allow other stations to take part in the videoconference without changing the technique of communication i.e. the passage from a unicast communication to multicast one will not exist since only the mechanisms of unicast communication will be used. In order to share a communication among several other ones, we have to identify the communication which we need, then to transfer the information about this communication to the initiator and finally to demand that the concerned node shares the communication. For the identification of the communication and the transfer of information which are completed in the application layer, we propose the use of mechanisms already existing in the Service Location Protocol (SLP) [5,6]. The share of the communication, which we are interested in, in this article, will be undertaken by the mechanisms of Hierarchical Mobile IPv6, which is an extension of the standard Mobile IPv6.
In the following section, we will give an overview of Communication Redirection. An overview of Hierarchical Mobile IPv6 will be shown in section 2. In section 3 we will present our proposition about the group communication before concluding in section 4.
1. OVERVIEW OF COMMUNICATION REDIRECTION The IPv6 Communication Redirection protocol (IPCR) introduces new functions. Indeed, with this protocol we will be able to redirect a communication from a host to another one (Fig. 1). Corr1 and Corr2 represent the initial correspondents, Corr3 the station replacing Corr2 in the redirected communication. We call Initiator the initiator of the redirection. It can be either Corr2 or Corr3 or even a third station not involved in the communication. Corr1
Old Communication
Corr2
New Communication
Corr3
Figure 1 - Redirection of a communication We identify a communication as a flow of information between two applications. To redirect a communication, there are several steps: ▪ The identification of the existing communications among which we want to redirect one or more of them. To do this, we must have information on all the current communications. ▪ The transfer of the information about the communications to the host, which initiates the redirection. ▪ The last step is the redirection of the selected communication. For the identification of the communication and the transfer of information both of which are completed in the application layer we propose the use of mechanisms already existing in the Service Location Protocol (SLP). The last step, which is the redirection of the selected communication, will be undertaken by the mechanisms introduced in MIPv6. In IPCR, once the communication, which we want to redirect, has been identified, Corr3 will request that Corr1 redirects it. With Mobile IPv6, when a mobile node is in its home network, it receives the packets sent to it like any host, which is stationary. When it moves in another network with IPv6 mobility, its packets are sent to it directly as long as the correspondent node has an entry in its binding cache for this mobile (or the packets are sent to it via its home agent which is its representative in its home network when the correspondent node has no entry in its binding cache for this mobile).
To put it briefly, when a mobile node moves from a network to another, all its communications move with it. For this to function, we have extended the binding cache table of Mobile IPv6 (Table 1) to include identification of a communication (Table 2). In other words, we avoid the redirection of all communications of Corr2 towards Corr3. Home address Home address1 Home address2 Home address3 … …
Care-of address Care-of address1 Care-of address2 Care-of address3 … …
Lifetime
Comm . id Comm. id1 …
Lifetime 1 Lifetime 2 Lifetime 3 … …
Comm. id3 … …
Table 1 - Binding cache of MIPv6
Home address Home address1 Home address2 Home address3 … …
Care-of address Care-of address1 Care-of address2 Care-of address3 … …
Lifetime Redirec tion Lifetime Redirec 1 tion1 Lifetime … 2 Lifetime Redirec 3 tion3 … … … …
Table 2 - Extended Binding cache of MIPv6 for IPCR
In the extended binding cache (Table 2), in addition to the home address, care-of-address and lifetime fields, we have the comm. id (Communication identification) and the redirection fields. In the comm. id field, we have the identification of a communication redirected by the local station or received by it after a redirection. It is possible that this field is not set; in this case, the line specifies an entry for a mobile node. Note, that to identify the IPv6 packets, which belong to the communication, a node could use only the source address and the flow label, which is unique for each source. Then, we will have only the flow label in this table. However, some members of the IETF suggest, guarantying the unity of the flow label only on a link; the router has a correspondence table and depending of the input link and the flow label value this table allows to determine the output link and the new flow label value. If this proposition is accepted then it’ll be very difficult to identify the packets with only the source address and flow label. In this case we will use source and destination addresses and ports, and the protocol. The redirection field specifies whether the communication is redirected by the local host or if it receives the redirected communication. It is set only when the comm. id is set too. After identifying the needed communication, we can effect the request of its redirection. This demand must be done by Corr3 and addressed to Corr1. To achieve this aim, we have defined a new Binding Update Sub-Option, which we have called “redirect option”. In this BU sub-option (Fig. 2) we’ve inserted the identification of the chosen communication. So far, we only use the flow id and the source address to identify a communication. Sub-Option type
Sub-Option length Flow Id
Reserved
Figure 2 - Redirect option Corr3 inserts this option in a BU and sends it to Corr1 which has to update its extended binding cache, so, that when sending a packet belonging to the redirected communication, Corr1 will set the destination address of the IPv6 header with Corr3’s address and use a routing header containing Corr2’s address as described above. When Corr3 receives this
packet, it processes like any other IPv6 packet. It exchanges the addresses contained in the routing header and the destination address field. Note, that to continue the regular process of the packet, Corr3 has, first, to set Corr2’s address on one of its own interfaces. Corr3 acts like a mobile node with its own address as a care-of-address and Corr2’s address as its home address. The group communication is included in order to extend IPCR and the mechanisms defined in Hierarchical Mobile IPv6 will be used and will be presented in the following section.
2. OVERVIEW OF HIERARCHICAL MOBILE IPv6 In this section, we will talk about Hierarchical Mobile IPv6 (HMIPv6), which is a mobility part of IPv6 protocol. Hierarchical Mobile IPv6 (HMIPv6) is simply an extension to the Mobile IPv6 (MIPv6). It introduces a new function, the Mobility Anchor Point (MAP), which is a Mobile IPv6 node located at any level in a hierarchical mobile IPv6 network, and minor extensions to the mobile node (MN) and Home Agent (HA) operations. A MAP domain’s boundaries are defined by the Access Routers (ARs) advertising the information to the attached MNs. When changing its IP layer access point within the MAP domain, the MN only needs to perform one local Binding Update (BU) to the MAP. There are two different MAP modes: ▪ An extended mode where a MN may use a MAP’s address as an alternate-care-ofaddress (COA) ▪ A basic mode where a MN may form a Regional COA (RCOA) on the MAP’s subnet With the basic mode, which interests us for the purposes of this article, the MN uses a RCOA and the MAP acts essentially as a local Home Agent (HA) for the MN. As a result, the MN would have two addresses, a RCOA on the MAP’s subnet and an on-link COA (LCOA). When a MN moves to a new MAP domain, it needs to obtain these two addresses. After that, it sends a binding update (BU) to the MAP specifying its RCOA in the home address field. This BU will bind the MN’s RCOA to its LCOA. If this operation succeeds, the MN must register its new RCOA with its HA by sending a BU that specifies the binding RCOA-Home address as in MIPv6. In this case, the home address field of the BU is set to the Home Address and an alternate-COA sub-option is used and set to the RCOA. The MN can also send a similar BU to its current correspondent nodes. These mechanisms are similar to those, which we will use to perform the conference between three or more members.
3. CONFERENCE BETWEEN THREE OR MORE MEMBERS The conference between three or more members is a service allowing one or more stations to take part in an existing unicast communication by only using mechanisms of unicast communication. With this service we are able to transform a unicast communication between two members to a communication (the communication remains unicast) between three or more members. It should be underlined that this service is limited to a communication for a small group of members. Our objective is not to find a technique replacing the multicast communication but it is only to avoid the interruption of the initial communication between the correspondents and the passage from a unicast communication to a multicast one. 3.1 Overview of the conference between three or more members Like the MAP with HMIPv6, in IPCR we have IPCR routers covering a particular domain. IPCR routers can’t only regularly advertise hosts in their domain by emitting multicast
messages but they can also be discovered by hosts with multicast or anycast messages. These routers support HMIPv6 and some extensions that we will detail below (Fig. 3). If needed, IPCR routers will allow sharing a communication for the establishment of a conference between three or more hosts. Corr1
Old Communication New communication
IPCR Router
Corr2
Corr3
Figure 3 - Transformation of a unicast communication to a conference between three members Like in the communication redirection, to share a communication for performing a conference between three, there are several steps to consider: ! ! !
The identification of the existing communications amongst one of which we want to share. To do this, we must have information on all the current communications. The transfer of the information about the communications towards the host, which initiates the mechanism. The last step is the share of the selected communication.
The identification of the communication and the transfer of information are completed in the application layer as in the communication redirection and we proposed the use the extensions of mechanisms already existing in the Service Location Protocol (SLP) [6]. We presume that we have a unicast communication between Corr1 and Corr2. We want to allow to Corr3 to take part in this communication. We presume again that we have contacted Corr2 to obtain information about its current communications. The aim is to receive all the packets of the chosen communication on a defined point. After that, the IPCR router will intercept these packets and will forward them towards all the participants apart from the sender. In IPCR, once the communication to share has been identified, Corr3 must send a commchoice message to inform Corr2 about the chosen communication. Then, Corr2 must form a Regional care-of-address (RCOA) on the subnet of its local IPCR router. The method of forming a RCOA on the IPCR router is the same with HMIPv6 when the MN forms a RCOA on the MAP’s subnet. The IPCR router will act as a HA which intercepts packets arriving at the RCOA formed by Corr2. After that, Corr2 sends a BU to Corr1 by using a home address option set to Corr2's address and an alternate-COA sub-option set to RCOA. Corr2 also sends to Corr3 a comm-choice acknowledgement message including the RCOA and the IPCR router's address. As a result,
Corr1 and Corr3 can register its addresses to the IPCR router by sending a BU with a home address option set to RCOA. At this moment the IPCR router has the correspondence of RCOA and the addresses of Corr1, Corr2 and Corr3. When one of the correspondents (Corr1, Corr2 or Corr3) has to send a packet belonging to the communication, it sends it to the RCOA. The IPCR router intercepts it, duplicates it and forwards it to all the addresses registered with the RCOA apart of the sender. Note that the IPCR router doesn't need the description of the communication, since only the packets of the chosen communication will be sent to RCOA. We can observe that in the above case we presumed that the local IPCR router of Corr2 is also local to Corr3. If it is not the case, Corr3 forms a new RCOA, which we call RCOA2 on the subnet of its local IPCR router, and registers its address to this router for RCOA2. It is this router, which will perform the registering of RCOA2 to the local IPCR router of Corr2 (Fig. 4). Corr1
(1’) BU
(2’) BA
IPCR Router2
IPCR Router1 RCOA: Corr1, Corr2, RCOA2
(2”) BU
RCOA2 : Corr3, RCOA
(3”) BA (1) BU
Corr2
(2) BA
(4”) BA
(1”) BU(RCOA2 in home address option) +@IPCR router1+RCOA
Corr3
Figure 4 - Registration of the members We assume that Corr3 has IPCR router2 as its local router, which is different to the local IPCR router of Corr2. Corr4, a station having IPCR router2 as local IPCR router, it is possible that Corr4 wants to take part in the communication. Therefore, it can form a new RCOA (RCOA3) and register itself, to IPCR router2. This router would have to register RCOA3 to the local IPCR router of Corr2 but on noticing that a first address RCOA2 has been created for this communication, sends a message to demand to Corr4 to use RCOA2 as RCOA. As a result, the packets arriving at the address RCOA2 will be intercepted by IPCR router2, duplicated and sent to all members apart from the sender. 3.2 The mechanisms used For this, on each station we will use the extended binding cache of MIPv6 defined in the communication redirection. We will insert in this table only the redirected communication and the shared ones. As a result, the redirection field of the extended binding cache specifies whether the communication is redirected by the local host, whether it receives the redirected communication or if it is about a shared communication. This field is set only when the comm. id field is set too. For a shared communication, in the Care-of address field of the table, we will have the RCOA used by the local host to receive or to send packets and the home address field will be set to the address of the correspondent in the application layer. For example in the application layer:
– Corr1 has as correspondent Corr2 – Corr2 has as correspondent Corr1 – Corr3 has as correspondent Corr2 (if Corr3 have inserted the communication by contacting Corr2. It would be Corr1 if Corr3 had contacted it). Note, that the identification in the table is not the received packets but the identification of the packets, which are emitted. 1. A station (i.e. Corr1) sends a packet belonging to a shared communication ▪ ▪ ▪ ▪
Set the source address field of the IPv6 header to the local address (i.e. Corr1's address). Set the destination address field of the IPv6 header to RCOA (i.e. address contained in the care-of-address field of the extended binding cache. Set a routing header with the address contained in the home address field of the extended binding cache. Send the packet.
2. Processing of the packet arriving to a RCOA by the IPCR router ▪ ▪ ▪ ▪ ▪
Intercept the packet like the home agent (HA) of IPv6 Mobility Exchange the addresses contained in the routing header and in the destination address field of the IPv6 header. Duplicate the packet to have a number of packets equal to the number (minus 1) of the recorded addresses (corresponding to the RCOA) in the IPCR table. Encapsulate the packets having IPCR router's address as source address and respectively all the recorded addresses, apart the sender of the packet, as destination address. Send the packets.
3. Reception of a packet by a member (i.e. Corr3) of the communication ▪ ▪
Decapsulate the packet (Note that the resulting packet has as destination address one of the initial correspondents: Corr1 or Corr2's address). Process the packet normally (the normal process of the packet is possible because at the beginning of the shared communication Corr1 must set Corr2's address on an interface, Corr2 must set Corr1's address an interface and the inserted host (i.e. Corr3, …) must set the addresses of Corr1 and Corr2 on their interfaces like a mobile node sets a Care-of-address when it moves on a foreign network).
Figure 5 - Some examples of algorithms of the conference between three or more members As a result, when a host emits a packet belonging to a communication, its checks in this table if there is an entry for this communication: ▪ If not: it processes the packet as standardized in the IPv6 routing. In others words, it checks if there is an entry for the addressee of the packet. ▪
If there is, there are three options: – The local host is the receiver (i.e. Corr3) of the redirected communication [2]. – The redirection is completed by the local host (i.e. Corr1) [2]. – The communication is a shared one. The source address field of the IPv6 header of the packet will be set to the address of the local host, the destination address field set to the “local” RCOA used by the local host. In this packet, we will place a
routing header with the address contained in home address field of the extended binding cache. The reception of packets is done exactly like standardized in IPv6 routing. To allow a correct processing of communication's packets as we said it in the figure 5, Corr1 must set Corr2's address on an interface, Corr2 must set Corr1's address on an interface and the inserted host must set the addresses of Corr1 and Corr2 on their interfaces. Also, each IPCR router maintains a table doing the correspondence between the formed RCOA and the recorded addresses. Note that an address may represent a station participating in the communication or another RCOA situated on the subnet of another IPCR router. As a result, when a packet arrives to a RCOA, the IPCR router acting as HA intercepts this packet, duplicates it and forwards it to all addresses recorded and corresponding to this RCOA apart from the sender (Fig. 5).
4. CONCLUSION In this article we have define a new function to extend the IPCR protocol. Indeed, with this protocol we will not be just able to effect the redirection of a communication but it will also be possible to allow one or more stations to take part in an existing unicast communication by using only the mechanisms of unicast communication. To do this, we have used the mechanisms introduced in Hierarchical Mobility IPv6 (HMIPv6), which is an extension of MIPv6. As we said above, our goal is not to find a technique replacing the multicast communication but only to avoid the interruption of the initial communication between the correspondents and the passage from a unicast communication to a multicast one. Also, this service is limited to a communication for a small group of members.
REFERENCES [1] S. Deering and R. Hinden. « Internet Protocol », Version 6 (IPv6) Specification IETF Mobile IP Working Group, RFC 2460, December 1998. [2] Mouhamadou L. Diagne and Thomas Noel. «A protocol for IPv6 Nomadic Communications», 5th IEEE MICC'01 proceedings, October 2001, Kuala Lumpur, Malaysia. [3] Mouhamadou L. Diagne, Thomas Noel and Jean-Jacques Pansiot. « Extension of Service Location Protocol for IPv6 Communication Mobility », IEEE PACRIM'2001 proceedings, August 2001, Victoria, Canada. [4] Mouhamadou L. Diagne, Thomas Noel and Jean-Jacques Pansiot. « Active Networks for IPv6 Redirection », MATA'2000 proceedings, September 2000, Paris, France. [5] Erik Guttman « Service Location Protocol Modifications for IPv6 » IETF, draft-ietfsrvloc-ipv6-12.txt, February 2001. [6] Erik Guttman, Charles Perkins and al. « Service Location Protocol, version 2 » RFC 2608, June 1999. [7] David B. Johnson and Charles Perkins. « Mobility Support in IPv6 » IETF Mobile IP Working Group, draft-ietf-mobileip-ipv6-13.txt, November 2000. [8] Hesham Soliman, Claude Castelluccia, Karim El-Malki, Ludovic Bellier. «Hierarchical MIPv6 mobility management» IETF Mobile IP Working Group, draft-ietf-mobileip-hmipv603.txt, February 2001. [9] John Veizades, Erik Guttman, Charles Perkins and S. Kaplan. « Service Location Protocol » Network Working Group, RFC 2165, June 1997.
