NEMO Working Group Mazen TLAIS Internet Draft Houda LABIOD Expires: February 10, 2005 ENST - Paris August 11, 2004 Handoff and Resource Management for Multi-homed Networks Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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. Abstract Multi-homed networks based on IPv6 form an important architecture within the NEMO (NEtwork MObility) configurations. Mainly in these networks the Mobile Router (MR) can appear in the neighbourhood of several Access Routers (ARs). In this case, MR has several egress interfaces and can detect several ARs simultaneously. This draft introduces a protocol that achieves handoff and resource management in a NEMO network in the case of multi-homed MR. We called this protocol an HRMMN protocol (Handoff and Resource Management for Multi-homed Networks). We introduce into the NEMO architecture an intelligent control entity called Access Router Controller (ARC). Based on traffic information transmitted through several ARs under the control of specific ARC, this latter is responsible of taking decisions about handoff, resource management and maintain of multiple bidirectional tunnels. Tlais and Labiod Expires February, 2005 [Page 1] Internet-Draft Resource Management August 2004 TABLE OF CONTENTS 1. Introduction.................................................. 3 2. Terminology................................................... 4 3. Description of the HRMMN protocol............................. 5 3.1 AR-ARC communication...................................... 6 3.2 MR-ARC communication...................................... 7 3.3 Inter ARC communication................................... 8 4. Route optimization............................................ 9 5. Several bidirectional tunnels................................ 10 6. Message Formats.............................................. 11 6.1 HRMMN_ARC_Cache_Refresh_Request message.................. 11 6.2 HRMMN_ARC_Cache_Update message........................... 12 6.3 HRMMN_ARC_Cache_Acknowledgment message................... 13 6.4 HRMMN_RegReq message..................................... 14 6.5 HRMMN_RegRes message..................................... 14 6.6 ARC Address option....................................... 14 6.7 AR Preferences option.................................... 15 6.8 Alternate Care-of Address Option......................... 16 6.9 Traffic information Option............................... 16 7. Resource Reservation......................................... 17 7.1 Intra AR resource reservation............................ 18 7.2 Inter ARs resource reservation........................... 19 8. Security considerations...................................... 20 9. References................................................... 21 10. Authors' addresses........................................... 21 Tlais and Labiod Expires February, 2005 [Page 2] Internet-Draft Resource Management August 2004 1. Introduction The primary goal of the NEMO working group is to specify a solution to provide continuous Internet connectivity to nodes in a mobile network at all times while the mobile network changes its point of attachment [1]. This solution basically solves the problem by setting up a bidirectional tunnel between the mobile router (MR) and the home agent (HA) [2]. Mobile networks are typically connected to fixed networks by wireless links. In addition, there could be many nodes behind the MR. Since the wireless link is not always stable, mobile nodes need to use multiple links for improving the availability of network connectivity. Multi-homing architecture is one of solutions to improve the availability, it provides advantage of enhancing session continuity and load balancing to mobile networks [3]. The purpose of this draft is to investigate issues related to such a multi-homed mobile network, especially when there is more than one access router (AR) between the mobile router and the Internet. Figure 1 shows multi-homing mobile router architecture, in this architecture, a mobile router (MR) can detect simultaneously several ARs. Reference [3] lists and explains different multi-homed configurations for NEMO. It distinguishes two main cases: either the multi-homed mobile router has only one interface, or the mobile router has several interfaces. - One interface: It is multi-homed when several prefixes are advertised on its interface. The mobile router must therefore configure several IPv6 addresses. - Several interfaces: The mobile router must therefore configure several IPv6 addresses (one on each interface). The typical case of this scenario is to have a WLAN interface (e.g. IEEE 802.11b) and a 2G/3G interface (e.g. GPRS). In this case, the mobile router may use its two interfaces either alternatively or simultaneously. Our HRMMN protocol is based on the idea that each MR can detect simultaneously several ARs. If we assume the existence of an intelligent entity (called ARC) capable of controlling several ARs, and which can collect information on the traffic transmitted through the concerned ARs, then we can manage efficiently the handoff and the reservation of available resources. This information required by the ARC is mainly associated to the user flows and the quality of transmission on the wireless link between the MR and the AR. Furthermore, the introduction of the ARC entity into the NEMO architecture can also be used for route optimization if the ARC can play the role of a home agent (HA). Tlais and Labiod Expires February, 2005 [Page 3] Internet-Draft Resource Management August 2004 ________________________ | | | Internet | | | |________________________| __|__ __|__ | | | | | AR2 | | AR1 | |_____| |_____| foreign ______|_____ _____|______ foreign link 2 | ____ | link 1 | | | | |___| MR |___| |____| ______|_____ NEMO-link __|__ | | | MNN | |_____| Figure 1: MR has multiple egress interfaces 2. Terminology Figure 2 illustrates the architecture components involved in this section. The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [4]. Network Mobility related terminology is defined in [5] and [6]. In addition this draft defines the following terms. Active AR: An access router is called active AR, if the MR uses this AR to run out its traffic or a part of its traffic. A MR can have multiple active ARs. ARC (access router controller): An ARC is a special router responsible for managing several ARs. It can be integrated into one of its ARs or it can act independently. The ARC gathers the list of ARs'addresses. The ARC has one table called ARC_Cache; this table contains information about the traffic managed by each AR. Each entry of the ARC_Cache contains mainly: - MR's care of address (CoA), AR's address, traffic information, AR's type. This latter is a bit that indicates if the AR is active or inactive. MR (mobile router): Mobile router is in our case the root MR. Tlais and Labiod Expires February, 2005 [Page 4] Internet-Draft Resource Management August 2004 3. Description of the HRMMN protocol This section gives an overview of the HRMMN protocol, stating the model of the architecture and presenting the investigated details of exchanges between the main entities such as: - communication between AR and ARC (Access Router Controller). - communication between MR and ARC. - communication between ARC and ARC. We consider the architecture presented in figure 2. The access router controller is responsible to manage AR1 and AR2. The mobile router can detect both ARs: AR1 and AR2, but it uses only AR1 to transmit its traffic, what means that AR1 is active. _____ _____ | | | | | HA | | CN | |_____| |_____| ___|_________________|__ | | | | | Internet | | | |________________________| __|__ __|__ | | | |ARC_Cache: | AR2 | | ARC |- MR's CoA,AR1'address, AR's type=1 |_____| | | traffic information. foreign _____|_____ |_____|- MR's CoA,AR2'address, AR's type=0 link 2 | __|__ traffic information. | | | | | AR1 | | |_____| | __|______ foreign | | link 1 | ____ | | | | | |_____| MR |______| |____| ______|_____ NEMO-link __|__ | | | MNN | |_____| Figure 2: A basic configuration (ARC manages AR1 and AR2) Tlais and Labiod Expires February, 2005 [Page 5] Internet-Draft Resource Management August 2004 3.1 AR-ARC communication When MR registers with an AR, deregisters, or changes its traffic information, the AR MUST send to ARC an update message. This message MUST contain MR's CoA and traffic information. This message is called HRMMN_ARC_Cache_Update (see section 6.2). MR registration and AR-ARC communication are illustrated in figure 3. When the mobile router (MR) is active: - it obtains a local IP address and sends a registration request (HRMMN_RegReq) requesting allocation of a globally routable long-term IP address for the MR on the current foreign sub-network. This message must contain traffic characteristics desired by the mobile network. The DHCPv6 server allocates an IP address to the MR. - a registration response (HRMMN_RegRes) is sent to request the MR with the allocated IPv6 address. This message must contain the answer on the desired traffic characteristics demand. In the same time, the AR sends an HRMMN_ARC_Cache_Update message to notify the ARC of the presence of the new MR and its flow's characteristic. The M bit set to 0 (figure 3) means that the sender of this HRMMN_ ARC_Cache_Update message is an AR. Upon receiving the HRMMN_ARC_Cache_Update message: - the ARC must first check the M bit among reserved bits (see section 6.2). It will detect that the M bit si set to 0, what means that the sender is an access router. - ARC must refresh its ARC_Cache. It gets the Care of Address from traffic information option (section 6.9) in the HRMMN_ARC_Cache_ Update message. - It gets AR's Address from the source address of the HRMMN_ARC_ Cache_Update message. - It gets traffic information from traffic information option. - It sets the AR's type to 1. If the sender is an AR that means that the AR is active. - and it may send an acknowledgment message to the AR if needed. This message is called HRMMN_ARC_Cache_Acknowledgment. section 6.3. When MR changes its current AR, it will deregister from the old AR, and gets a new CoA from the new AR. Then both new and old ARs must send an HRMMN_ARC_Cache_Update message to the ARC. When the ARC receives the HRMMN_ARC_Cache_Update emitted by the: - old AR: it will detect the deregistration of the old CoA and it will remove the corresponding entry from the ARC_Cache. - new AR: it will detect the registration of new CoA and it will add the corresponding entry to the ARC_Cache. Tlais and Labiod Expires February, 2005 [Page 6] Internet-Draft Resource Management August 2004 A request message for traffic information may be sent by the ARC to AR if needed. This message is called HRMMN_ARC_Cache_Refresh_Request (section 6.1). This message is sent when the ARC looses or needs to refresh information for a specific MR. The ARC MUST put the care of address (CoA) of the concerned MR within the Alternate Care-of Address option (section 6.8). MR AR ARC | | | | HRMMN_RegReq | | |-------------->| | | | | | HRMMN_RegRes | HRMMN_ARC_Cache_Update (M=0) | |<--------------|--------------------------------->| | | HRMMN_ARC_Cache_Acknowledgment | | |<---------------------------------| | | | | | HRMMN_ARC_Cache_Refresh_Request | | |<---------------------------------| | | | | | | Figure 3: Refresh AR-ARC 3.2 MR-ARC communication To take into account the existence of ARC, we add to the Router Advertisement (RA) message defined in [7] a new option called ARC Address option (section 6.6). This option contains the address of the ARC. All ARs belonging to the same ARC domain MUST advertise the ARC's IP address. When MR is active in a given area, it can detect ARs in its neighbourhood through router advertisement (RA). MR chooses the most suitable AR and obtains a CoA. This AR is called an active AR. As illustrated in figure 4, the MR may send to the ARC an HRMMN_ARC_ Cache_Update message, this message must contain a list of inactive ARs which it can detect and the quality of reception of the flows emitted by these ARs. This message helps ARC to take intelligent decisions about handoff and resource management. This HRMMN_ARC_Cache_Update message must have the reserved bit M set to 1, so that ARC can distinguish this message from the update message emitted by the AR. The source address of this message MUST be the MR's CoA. Mobile router sends this message in two cases; when the MR can detect a new inactive AR, or cannot detect any more one of its inactive ARs. Tlais and Labiod Expires February, 2005 [Page 7] Internet-Draft Resource Management August 2004 Upon receiving an HRMMN_ARC_Cache_Update message: - ARC must first check the M bit among reserved bits. It will detect that the M bit is set to 1, what means that the sender is a mobile router. - ARC must refresh its ARC_Cache. It gets the care of address from the source address of the HRMMN_ARC_Cache_Update message. - It gets AR's address from the traffic information option in the HRMMN_ARC_Cache_Update message. - It gets traffic information from traffic information option. - It sets the AR's type to 0. If the sender is an AR that means that the AR is inactive. - and it may send an acknowledgment message to the MR if needed. This message is called HRMMN_ARC_Cache_Acknowledgment. Administrator can configure the ARC in such manner that it treats the update message emitted by MR as being a message of request for ARs preferences. In this case, ARC must answer by including in the HRMMN_ ARC_Cache_Acknowledgment message an option that contains preferences of each inactive AR, this option is called AR preferences option. The preferences values emitted by the ARC form an important product of the introduction of the intelligent element ARC. Receiving these preferences, the mobile router can make intelligent decision to change its active access router. MR AR ARC | | | | | | | HRMMN_ARC_Cache_Update (M=1) | |------------------------------------------->| | | | | HRMMN_ARC_Cache_Acknowledgment | |<-------------------------------------------| | | | | | | Figure 4: Refresh MR-ARC 3.3 Inter ARC communications On the border of two ARCs, MR will detect through the RA messages the existence of ARs which belong to various ARCs. Then the handoff operation is performed between these ARCs. In figure 5, the MR can detect two ARs: AR1 and AR2. Each access router belongs to a different ARC domain. AR1 belongs to ARC1 domain and AR2 belongs to ARC2 domain. - The mobile router (MR) will be registered with AR2 of the ARC2 domain, the registration message is called HRMMN_RegReq. Tlais and Labiod Expires February, 2005 [Page 8] Internet-Draft Resource Management August 2004 - Then, AR2 must response by an HRMMN_RegRes message, this message must contain the CoA of the MR. In the same time, AR2 must send an HRMMN_ARC_Cache_Update message to ARC2, so ARC2 can carry the new MR. - ARC2 must answer this update message by an Acknowledgment message (HRMMN_ARC_Cache_Acknowledgment). Let us note that we are finalizing simulation tool under NS2 named NEMO Simulator which enables us to implement the basic mechanism of this architecture. MR AR1 AR2 ARC1 ARC2 | | | | | | RA | | | | |<--------| | | | | | | | | | RA | | | |<------------------| | | | | | | | | HRMMN_RegReq | | | |------------------>| | | | | | | | | HRMMN_RegRes | HRMMN_ARC_Cache_Update (M=0) | |<------------------|-------------------------------------->| | | | HRMMN_ARC_Cache_Acknowledgment | | | |<--------------------------------------| | | | | | AR1: Access Router belongs to ARC1 domain. AR2: Access Router belongs to ARC2 domain Figure 5: ARC-ARC 4. Route optimization In this section, we propose a route optimization scheme. In fact, it can happen that the ARC could be closer to the mobile network than the Home Agent. In this case, it can be useful that the MR asks the ARC to play the role of its HA instead of its current HA (see Figure 6). If the ARC can play the role of a HA, then the delay and the tunnelling overhead on every transmitted packet could be significantly reduced. In this case, each time the MR changes the ARC domain, the mobile nodes initiate the Dynamic Home Agent Address Discovery Request message to get the address of the most appropriate home agent. In our case, the appropriate home agent is the ARC where the mobile nodes are in its domain. Tlais and Labiod Expires February, 2005 [Page 9] Internet-Draft Resource Management August 2004 ___________ | | _____ | HA | | | |___________| | CN | | |_____| ________|_____________|_ | | | | | Internet | | | |________________________| __|__ __|________ | | | | | AR2 | | ARC/HA | |_____| |___________| foreign ______|_____ __|__ link 2 | | | | | AR1 | | |_____| | ___|______ foreign | | link 1 | ____ | | | | | |_____| MR |______| |____| ______|_____ NEMO-link __|__ | | | MNN | |_____| Figure 6: ARC playing the role of HA 5. Several bidirectional tunnels Our HRMMN protocol can easily support the load balancing feature between different ARs. Mobile router can then be connected to the HA through several bidirectional tunnels. Indeed, when the mobile router receives the HRMMN_ARC_Cache_Acknowledgment message emitted by the ARC, this message must contain the preferences of inactive ARs, so the MR may decide to change its current AR or to be registered with an another AR in addition to current AR. If MR is registered with more than one AR, there will be several bidirectional tunnels between MR and HA. For instance, MR will obtain two CoAs in case of two actives ARs. Tlais and Labiod Expires February, 2005 [Page 10] Internet-Draft Resource Management August 2004 Let us note that the current Mobile IPv6 and the NEMO Basic Support protocol [2] does not allow to register more than one care of address in the home agent. A proposed solution to let the HA distinguish between multiple CoAs can be found in [8], then the HA balances the traffic directed towards this MR between different active ARs. In the case of several CoAs, MR must choose one of its active ARs to send the HRMMN_ARC_Cache_Update message. Moreover, it must add to this message the CoAs of other active ARs. So, the ARC can make the correspondence between various CoAs and the same MR. Thus, we use the defined option called Alternate Care-of Address [7]. The ARC must construct a table that contains correspondence between CoAs and the same MR. For doing so, each entry of the table must contain the CoA found in the Alternate Care-of Address option and the CoA found within the source address of the HRMMN_ARC_Cache_ Update message. It should be noted that the possibility of having several active bidirectional tunnels, allows handoff execution without connection interruption, even in the case of inter domain handoff. Indeed, if MR wants to change AR, it asks to be registered with the new AR. Then, during time when the new AR performs the registration, MR uses the old AR to run out its traffic. 6. Message Formats The mobile IPv6 messages are defined in [7]. This draft defines five new messages. It adds and modifies several options, some of which may appear multiple times in the same message. 6.1 HRMMN_ARC_Cache_Refresh_Request message This message is sent by an ARC to request an access router to update the ARC_Cache. The format is as follows: 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 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Mobility options . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Tlais and Labiod Expires February, 2005 [Page 11] Internet-Draft Resource Management August 2004 Reserved: This field is unused. It MUST be initialized to zero by the sender and MUST be ignored by the receiver. Mobility options: Variable-length field of such length that the complete mobility header is an integer multiple of 8 octets long. This field contains zero or more type-lengh-value TLV-encoded mobility options. The receiver MUST ignore and skip any options which it does not understand. Possible options Alternate Care-of Address option: When the ARC wants to refresh the traffic information belonging to a specific MR, it must specify the CoA of the concerned MR. 6.2 HRMMN_ARC_Cache_Update message The access router MUST send to ARC an update message that contains information about the traffic transmitted through it, the reserved bit M must be set to 0. Also, when MR sends to ARC an update message, this message must contain a list of inactive ARs which it can detect and the quality of reception of the flows emitted by these ARs. The reserved bit M must be set to 1. The format of the HRMMN_ARC_Cache_Update message is as follows: 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 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence # | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |A|M| Reserved | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Mobility options . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Acknowledge (A): The A bit is set by the sender to request an HRMMN_ARC_Cache_Acknowledgement message to be returned upon receiving the HRMMN_ARC_Cache_Update message. Tlais and Labiod Expires February, 2005 [Page 12] Internet-Draft Resource Management August 2004 Mobile router (M): The M bit is set by the sender, it must be put at 0 if the sender is an AR. Otherwise it is set to 1 if the sender is a MR. Sequence #: A 16-bit unsigned integer used by the receiving node to sequence HRMMN_ARC_Cache_Update and by the sending node to match a returned HRMMN_ARC_ Cache_Acknowledgement with this HRMMN_ARC_Cache_ Update. Lifetime: 16-bit unsigned integer. The number of time units remaining before the entry of this mobile router in the ARC_Cache MUST be considered expired. Possible options: Mobility options can have the following values: Alternate Care-of Address option: In the case of a MR that has multiple CoAs, the MR must send to ARC its other CoAs. So, the ARC can make the correspondence between various CoAs and the same MR. The MR puts each CoA in an Alternate Care-of Address option, except the CoA used in the source address of the update message. Traffic information option: When a mobile router or an access router sends an HRMMN_ARC_Cache_Update message, this message must contain traffic information to update the ARC_Cache. 6.3 HRMMN_ARC_Cache_Acknowledgment message This message is emitted by the ARC to acknowledge the reception of an HRMMN_ARC_Cache_Update message. The format is as follows: 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 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Status | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence # | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Mobility options . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Tlais and Labiod Expires February, 2005 [Page 13] Internet-Draft Resource Management August 2004 Status: 8-bit unsigned integer indicating the status of the HRMMN_ARC_Cache_Update message. Values of the Status field less than 128 indicate that the HRMMN_ARC_Cache_ Update was accepted by the receiving node. Values greater than or equal to 128 indicate that the HRMMN_ARC_Cache_ Update was rejected by the receiving node. 6.4 HRMMN_RegReq message This message is emitted by the mobile router to be registered with the AR. The format of this message is defined in [9]. We add to this message a traffic information field. 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 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Traffic Information . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6.5 HRMMN_RegRes message This message is an answer to the HRMMN_RegReq message. The format of this message is defined in [9]. We add to this message a traffic information status field. 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 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Traffic Information status | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6.6 ARC Address option The Router Advertisement message sent by the AR is modified to carry the address of the ARC. Indeed, MR requires information on the ARC's address so it can send to ARC the list of ARs it can detect. For that, we added a new option called ARC Address option. Tlais and Labiod Expires February, 2005 [Page 14] Internet-Draft Resource Management August 2004 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 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + ARC Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: ICMPv6 option type. Length: 8-bit unsigned integer. The length of the option (including the type and length fields) in units of 8 octets. ARC Address: The IP address of the ARC. 6.7 AR Preferences option The ARC must include the preferences of each inactive AR within the HRMMN_ARC_Cache_Acknowledgment message, so MR can make a suitable decision to change current AR. Each AR preferences option specifies preferences for a specific inactive AR. This option mainly consists of a 2-bits flag (low, medium, high or obligatory). 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 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length |Prf | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ But if the MR detects several ARs, how MR can distinguish which fields belongs to which AR? The solution is simple. Indeed, the ARC can transmit these preferences option according to the value of the AR's address. So if the MR and ARC have the same classification of ARs Addresses, then the MR can distinguish the concerned AR. Tlais and Labiod Expires February, 2005 [Page 15] Internet-Draft Resource Management August 2004 Prf (Preference): 2-bit signed integer. Indicates whether or not to prefer this router over other default routers. Preference values are encoded in two bits, as follows: 00 (Low), 01 (Medium), 10 (High), 11 (obligatory). 6.8 Alternate Care-of Address option The Alternate Care-of Address option is defined in [7], it has an alignment requirement of 8n+6. Its format is as follows: 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 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 3 | Length = 16 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Alternate Care-of Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Normally, an HRMMN_ARC_Cache_Update specifies the care-of address in the source address field of the IPv6 header. However, in the case of a MR that has multiple CoAs, the MR must send to ARC its other CoAs. So, the ARC can make the correspondence between various CoAs and the same MR. Moreover, when the ARC wants to refresh traffic information for a specific MR, it must specify to the AR, in the HRMMN_ARC_Cache_ Refresh_Request message, the concerned MR. Alternate Care-of Address: This option contains an address to use as the care-of address for the mobile router. 6.9 Traffic information Option When a mobile router or an access router sends a HRMMN_ARC_Cache_ Update message, this message must contain traffic information. This option is valid only in HRMMN_ARC_Cache_Update message. Tlais and Labiod Expires February, 2005 [Page 16] Internet-Draft Resource Management August 2004 The Traffic information option has an alignment requirement of 8n+6. Its format is as follows: 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 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + router Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Traffic Information . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ router Address: If the sender is a mobile router, this field must contain the address of inactive AR. If the sender is an access router, this field must contain the Care of Address of concerned mobile router. Traffic Information: This field must contain traffic information of a specific mobile router. 7. Resource Reservation The mobile networks must be able to manage the handoff. i.e. the switch of a communication from an AR to another while maintaining the connection to the Internet. Indeed, during these displacements, the connection to the Internet may be interrupted because of the delay of the MR registration, or because of non available resources. As Already proposed the use of several bidirectional tunnels is a solution to the handoff problem. But nothing prevent that when NEMO network is in a handoff state may not find necessary resources within the new AR. Also, when a new mobile node appears in a MR coverage, the MR may not find the necessary resources to accept it. Tlais and Labiod Expires February, 2005 [Page 17] Internet-Draft Resource Management August 2004 For that, our protocol handles resource reservation. Necessary resources are provided in the case of handoff, arrival of new mobile nodes, or variations in traffic within the environment. According to needs' for MRs, we can distinguish two levels of resource reservation. - Intra AR: When a mobile node appears in a MR coverage, MR must find necessary resources for its new mobile node. It sends to its current active AR, a message to change the characteristics of its flow to carry the new mobile node. - Inter ARs: When a mobile router performs handoff. It must contact the new AR to reserve the necessary resources to execute handoff with a minimum delay. Let us note that this resource reservation will be limited to the ARs level (MR-ARs). The end to end reservation (mobile network node - correspondent node) will be treated in another draft. 7.1 Intra AR resource reservation When a mobile node appears in a MR coverage, MR must find necessary resources for its new mobile node. We distinguish two types of resource reservation: Proactive and Reactive. - Proactive Reservation: MR can predict new mobile node's appearance. It tries to reserve the resources before mobile nodes' appearance. In this case, when mobile node appears, it can directly begin the transmission with a minimum delay. - Reactive Reservation: When MR detects appearance of a new mobile node, it executes the resource reservation mechanism. The new mobile node starts transmission after resource reservation mechanism takes end. In this case the MR may not find directly the necessary resources, so the new mobile node must wait until the release of resources. In the case of Intra AR resource reservation, when MR wants to change the characteristics of its flow, it must send to its active AR a Resource_Reservation_Request_Message (RRRM). This message MUST contain the desired flow and its characteristics (figure 7). When receiving RRRM message: - AR must check the desired flow characteristics in the RRRM message, - it MUST send an acknowledgment message called Resource_Reservation_ Acknowledgment_Message (RRAM) to the MR, this acknowledgment message must contain the response on the request demand. In the same time, the AR must send an HRMMN_ARC_Cache_Update message to the ARC to take into account the new flow characteristics. Tlais and Labiod Expires February, 2005 [Page 18] Internet-Draft Resource Management August 2004 MR AR ARC | | | | RRRM | | |------------>| | | | | | | | | | | | RRAM | HRMMN_ARC_Cache_Update (M=0) | |<------------|--------------------------------->| | | | Figure 7: Intra AR Reservation 7.2 Inter ARs resource reservation When a mobile router performs handoff, it must find necessary resources in the next AR. We distinguish, also, two types of resource reservation: Proactive and Reactive. - Proactive Reservation: Mobile Router can predict the handoff. It tries to reserve the resources before handoff's taking place. In this case, when a mobile router performs handoff, it will be sure to find reserved resources. - Reactive reservation: When MR detects handoff. It begins resource reservation mechanism. The mobile router starts the transmission after resource reservation mechanism takes end. In this case the MR may not find directly the necessary resources, so the mobile router must wait until the release of resources, and connections may be interrupted. In the case of Inter ARs resource reservation, when MR can detect the next AR, then the MR performs resource reservation in the same way as for intra AR reservation (figure 8). MR AR next AR ARC | | | | | RRRM | | |------------------>| | | | | | | | | | | RRAM | HRMMN_ARC_Cache_Update (M=0) | |<------------------|--------------------------------->| Figure 8: MR can see the new AR in Inter AR Reservation Tlais and Labiod Expires February, 2005 [Page 19] Internet-Draft Resource Management August 2004 In the case of inter ARs resource reservation, when MR can not see the next AR (figure 9). We suppose that ARC may have necessary information to decide the next AR, or the MR has the necessary information to decide the next AR. Indeed, the NEMO network route is generally fixed. The ways of transport such a train or a bus have a well-known route in advance. Consequently, we can pre-empt the movement of NEMO network and thus to predict which will be its next AR. Mechanism to predict the next AR in a NEMO context will be treated in another draft. So, when MR is already in communication by using an active AR: - It must send to its ARC a Resource_Reservation_Request_Message (RRRM). This message MUST contain the desired flow with its characteristics. - When receiving RRRM message, the ARC must ask the next AR to perform the resource reservation for the MR. This message is the same as RRRM. Then, as soon as MR enters the coverage of the next AR, it can start using reserved resources immediately. - After performing resource reservation, the next AR must send an acknowledgment message (RRAM) to the ARC. - Finally, ARC must send an acknowledgment message (RRAM) to the MR, this message must contain the status of the reservation and the address of the next AR. MR AR ARC next AR | | | | | RRRM | | |------------------------------------>| RRRM | | | |------------------------->| | | | | | | | RRAM | | | |<-------------------------| | RRAM | | |<------------------------------------| | | | | | | | | | Figure 9: MR can not see the next AR in Inter AR Reservation 8. Security considerations This draft introduces a new element to NEMO architecture, namely, an access router controller that acts as an intelligent element to control and manage handoff and resources. The security relationship between the mobile router (access router) and the ARC is very important and should be fixed. Tlais and Labiod Expires February, 2005 [Page 20] Internet-Draft Resource Management August 2004 9. References [1] T. Ernst. "Network Mobility Support Goals and Requirements". Internet Draft, IETF. draft-ietf-nemo-requirements-02.txt (work in progress). February 2004. [2] V. Devarapalli, "Nemo Basic Support Protocol", draft-ietf-nemo- basic-support-02.txt (work in progress). December 2003. [3] T. Ernst, N. Montavont, R. Wakikawa, E. Paik, C. Ng, K. Kuladinithi, T. Noel, "Goals and Benefits of Multihoming", draft-multihoming-generic-goals-and-benefits-00.txt (work in progress). February 2004. [4] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [5] J. Manner and M. Kojo. "Mobility Related Terminology". Internet Draft, IETF. draft-ietf-seamoby-mobility-terminology-05.txt (work in progress). November 2003. [6] T. Ernst, and H. Lach, "Network Mobility Support Terminology", draft-ietf-nemo-terminology-01.txt (work in progress). February 2004. [7] D. Johnson,C. Perkins, and J. Arkko, "Mobility Support in IPv6", draft-ietf-mobileip-ipv6-24.txt (work in progress), July 2003. [8] J. Charbon, C-W. Ng, K. Mitsuya, T. Ernst, "Evaluating Multi-homing Support in NEMO Basic Solution", draft-charbon- nemo-multihoming-evaluation-00.txt (work in progress). July 2003. [9] Chritian Huitema, "IPv6 The new Internet Protocol", second edition. 10. Authors' addresses Questions about this memo can be directed to: Mazen TLAIS Ecole Nationale Superieure des Telecommunications (ENST) GET/ENST/INFRES Department, LTCI-UMR 5141 CNRS 46 rue Barrault - 75634 Paris Cedex 13 - France E-mail: tlais@enst.fr Houda LABIOD Ecole Nationale Superieure des Telecommunications (ENST) GET/ENST/INFRES Department, 46 rue Barrault - 75634 Paris Cedex 13 - France Tel : +33 (0)1.45.81.74.36 Fax : +33 (0)1.45.81.31.19 E-mail: labiod@enst.fr Tlais and Labiod Expires February, 2005 [Page 21]