Mobile IP Working Group Koichi Ishibashi INTERNET-DRAFT Keiichi Shimizu Expires: April 2002 Shoichiro Seno Mitsubishi Electric Corporation October, 2001 Behavior of A Mobility Agent in Mobile IP in order to manage the flow 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 cite them other than as "work in progress". The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/lid-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This document is an individual submission to the IETF. Comments should be directed to the authors. Abstract Mobile IP [1] protocol allows a mobile node (MN) to move between different networks seamlessly. However, in certain cases, the latency involved in the handoff can be beyond the threshold required for the support of delay-sensitive or real-time services. In order to address the above problem, there have been many proposals related to extensions of Mobile IP handoffs in order to achieve efficient handoff procedures. Originally the Mobile IP should be considered a protocol that deals solely with terminal mobility. On the other hand, when the future mobile network supports QoS, mobility agents should support QoS treatment of tunneling and forwarding and distinguish individual flows. And the above support of the QoS treatment should be applied to a handoff procedure as well as the tunneling and forwarding procedure. Ishibashi, Shimizu, Seno Expires April 2002 [Page 1] INTERNET-DRAFT Behavior of a Mobility Agent October, 2001 This draft aims at bringing up a problem that a mobility agent should apply different handoff mechanisms to individual flows according to an implicit or explicit configuration. TABLE OF CONTENTS 1. Introduction 2. Terminology 3. Backgrounds 4. Example of a Behavior of a Mobility Agent Supporting Fast MIP and Buffer Management Simultaneously 5. Future Issues 6. IPv6 Consideration 7. References 8. Authors' Addresses 1. Introduction Mobile IP [1] protocol allows a mobile node (MN) to move between different networks seamlessly. That is, Mobile IP presents a solution for ensuring an IP-layer handoff as the MN changes its point of attachment with the Internet. However, in certain cases, the latency involved in the handoff can be beyond the threshold required for the support of delay-sensitive or real-time services. In order to address the above problem, Fast MIP [2] proposes methods to achieve low-latency Mobile IP handoffs when an MN moves between different networks served by each network's foreign agent (FA). And there are many proposals related to extensions of Mobile IP handoffs in order to achieve efficient handoff procedures. Originally the Mobile IP should be considered a protocol that deals solely with terminal mobility, so that we think Fast MIP and the other proposals are based on assumption of terminal mobility. On the other hand, in the future, we envision an MN that has multiple flows simultaneously and each flow may request its own distinctive QoS (Quality-of-Service) attribute, that is, low-latency, low-loss, best-effort, and so on. For example, whereas one flow may request the low-latency service as its QoS attribute, another flow may request the best-effort service as its QoS attribute. Ishibashi, Shimizu, Seno Expires April 2002 [Page 2] INTERNET-DRAFT Behavior of a Mobility Agent October, 2001 However, mobility agents of Mobile IP or Fast MIP are unable to distinguish individual flows and therefore apply the same procedure to all intercepted traffic for an MN. Consequently, if an MN requests for simultaneous bindings, the home agent (HA) will redirect, or bi-cast, all intercepted packets to the MN to all registered care-of addresses. However, a flow that requests the best-effort service may be tolerant of disruption involved in the handoff. So, applying the method for the low-latency service, such as bi-casting, to the flow requesting the best-effort service results in ineffective utilization of the resource in mobility agents and the bandwidth of a mobile network. In our opinion, a future network will support a QoS mechanism and a future mobile network will support a QoS mechanism also. When the future mobile network supports QoS, mobility agents should support QoS treatment of tunneling and forwarding and distinguish individual flows. And the above support of the QoS treatment should be applied to a handoff procedure as well as the tunneling and forwarding procedure. This draft aims at bringing up a problem that a mobility agent should apply different handoff mechanisms to individual flows according to an implicit or explicit configuration. The configuration for individual flows is outside the scope of this document. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. 3. Backgrounds In a future network, a mobile node may have multiple flows simultaneously. And each flow may request its own distinctive QoS (Quality-of-Service) attribute, that is, low-latency, low-loss, best-effort, and so on. Here, Fast MIP primarily proposes methods to achieve low-latency Mobile IP handoffs. That is, by introducing a new concept i.e, "anticipation", and implementing the mechanism of "bi-casting" or BET (bi-directional edge tunnel), a new foreign agent (nFA) can be allowed to receive IP packets to the mobile node before the MN has completed movement to the new network served by the nFA. And forwarding IP packets to the mobile node before the mobile node has completed registration of its location can realize reduction of the latency involved in the handoff. Ishibashi, Shimizu, Seno Expires April 2002 [Page 3] INTERNET-DRAFT Behavior of a Mobility Agent October, 2001 As an illustration, suppose that the mobile network supports the PRE-REGISTRATION handoff method presented by Fast MIP and an MN has two flows. One flow requests the low-latency service, another flow requests the best-effort service. When the HA receives IP packets to the MN during movement between an old foreign agent(oFA) and a new foreign agent (nFA), the HA must bi-cast the received packets to both the oFA and the nFA. That is, the IP packets belonging to the flow with the best-effort service may be forwarded to the nFA by the bi-casting mechanism. This forwarding procedure may be inefficient for the best-effort service, and result in increase of processing load on the HA and consumption of network resource. Note that the oFA's and n FA's decision on which action to be taken should depend on the type of traffic involved. - drop all packets to the MN or - buffer packets to the MN. However, it is not shown how the FA behaves to support the low-latency service and the loss-less service simultaneously. Although Fast MIP allows a protocol to minimize the amount of service disruption during movement between FAs, it is difficult to avoid packet loss completely. So we think that in order to support the low-loss service, it may be necessary to apply a specific mechanism, for example, such as the mechanism described in Buffer Management [3]. And the mobile network may need to support multiple mechanisms for the low-latency and the low-loss services since each mechanism can only satisfy a requirement related to a specific QoS attribute. When supporting the buffering method described in Buffer Management, a mobility agent should not buffer all IP packets destined to the MN, but the IP packets belonging to the flow requesting the low-loss service, to make efficient use of limited buffer capacity. Note that in order to support multiple handoff mechanisms, the mobility agent must distinguish IP packets belonging to individual flows, and apply the behavior according to the flow to the IP packets. And, the QoS treatment should be applied to the packet stream not only before and after the handoff, but also during the handoff. That is, the behavior or action of a mobility agent should be decided according to the QoS attributes of relayed packets. Here, in order to satisfy the requested QoS between end-to-end hosts, it may be necessary to specify the behavior of nodes along the path. Thus it is important to describe the behavior of a mobility agent that is a component of the end-to-end path. Ishibashi, Shimizu, Seno Expires April 2002 [Page 4] INTERNET-DRAFT Behavior of a Mobility Agent October, 2001 Because the future mobile network will support QoS, each component in the future mobile network must support a behavior or an action that realizes the requested QoS, so that a mobility agent can support a QoS mechanism. Under this environment, since the mobility agent may forward IP packets according to its requested QoS, excessive overhead may not occur if the mobility agent applies individual handoff mechanisms according to the requested QoS. 4. Example of a Behavior of a Mobility Agent Supporting Fast MIP and Buffer Management Simultaneously First, suppose that a mobile network implements both the PRE-REGISTRATION handoff method presented by Fast MIP and the method presented by Buffer Management. While the flow that requests the low-latency may be serviced by the PRE-REGISTRATION handoff method during movement between networks, the flow that requests the low-loss may be serviced by the method presented by Buffer Management. Note that the flow that requests the best-effort service may be serviced by the method presented by Mobile IP. In the 51th IETF meeting, there was the consensus that bi-casting mechanism should be moved to a separate document for Fast MIP draft. However, in this draft, we address the requirement that a mobility agent should apply an appropriate behavior for each requested QoS to individual flows according to an implicit or explicit configuration. And for the above purpose, we refer to the bi-casting mechanism as an example for supporting the low-latency handoffs, and Buffer Management as an example for supporting the low-loss handoffs. Note that the mechanisms to achieve the low-latency Mobile IP handoff or the low-loss Mobile IP handoff are outside the scope of this document. Therefore, for a mobility agent to apply an appropriate behavior for each requested QoS, it is necessary to distinguish individual flows and decide which QoS attribute each flow deserves. Ishibashi, Shimizu, Seno Expires April 2002 [Page 5] INTERNET-DRAFT Behavior of a Mobility Agent October, 2001 As an illustration, suppose that the MN requests the simultaneous bindings to the HA by the PRE-REGISTRATION handoff method. When the HA receives an IP packet to the MN, it must bi-cast the packet destined to the MN to multiple locations registered by the MN. After this process, IP packet transmission routine on the HA would discard IP packets destined to the MN corresponded with the flows that do not request the low-latency handoffs. In this point, the behavior for individual flows may be ruled by an implicit or explicit configuration. However, the HA must forward the IP packets destined to the MN to at least one location among multiple locations registered by the MN. Which location the HA selects may depend on its policy, that is, the MN may indicate the location that the HA should primarily forward the IP packets, or the HA may forward the IP packets to the oldest location among locations that the MN registered. On the other hand, when the FA receives an encapsulated IP packet, first it de-encapsulates the received IP packet. And the FA may: - drop the received packet, - buffer packet for the MN, or - buffer packet for the MN according to the mechanism presented by the Buffer Management. The choice of which action to be taken may depend on the type of the received packet. The following contains message timing diagram describing the above behavior. Ishibashi, Shimizu, Seno Expires April 2002 [Page 6] INTERNET-DRAFT Behavior of a Mobility Agent October, 2001 MN oFA nFA HA | | | | |<~~L2-Triffer | | | | | | | | RegReq(with Buffer Control Request extension) |------------->| | | | RegRep(with OPTIONAL Buffer Control | |<-------------| Response extension) | | | | | | ProxyRtSol | | | |------------->| | | | ProxyRtAdv | | | |<-------------| | | | | | | | RegReq | | | |--------------|------------->| | | | |---------->| | | | RegRep | | |<----------| |<-------------|--------------| | |<-------------|<-------------| | IP packet to MN | | | |<--- for low-latency | |<-------------------------|# |<-------------| *|<----------|# bi-casting | | Buffering or Discard | | | | | IP packet to MN | | | |<--- for loss-less | *|<-------------------------| | Buffering for Buffer Management | | | | | | | | | | RegReq(with two Buffer Control extensions | | and Previous FA Notification extension) |--------------|------------->| | | | |---------->| | | Binding Update(with Buffer Control | |<-------------| Request extension) | | [Forwarding] | | | |=============>| | | |<----------| |<-------------|--------------| | | RegRep(with OPTIONAL Buffer Control Response extension) | | | | RegReq : Registration Request RegRep : Registration Reply ProxyRtSol : Proxy Router Solicitation ProxtRtAdv : Proxy Router Advertisement Ishibashi, Shimizu, Seno Expires April 2002 [Page 7] INTERNET-DRAFT Behavior of a Mobility Agent October, 2001 Note that a traffic flow may be identified by using the DS codepoint of DiffSev or by combining the destination address, the source address, transport protocol number and port numbers. And, if we consider the POST-REGISTRATION handoff method presented by Fast MIP as an example for supporting the low-latency, we will encounter the same issues when an FA decides whether it should forward an IP packet by using BET or not. 5. Future Issues This section describes the requirements for realizing MA's behavior according to individual flows in brief. The following shows the list of the requirements. - capability to configure for individual flows on each mobility agent, - capability to distinguish between individual flows on each mobility agent, - capability to map handoff mechanisms to individual flows according to its configuration, - if possible, aggregation of signaling messages involved in each handoff mechanism. 6. IPv6 Consideration In this draft, we consider the problem and an example of behavior of Mobile IPv4 mobility agents when a mobile node has multiple flows simultaneously and each flow requests its own distinctive QoS attribute. There is the same problem when we consider the issues with the Mobile IPv6. That is, a home agent and access routers of Mobile IPv6 should apply different handoff mechanisms to individual flows that may request its own distinctive QoS attributes. Ishibashi, Shimizu, Seno Expires April 2002 [Page 8] INTERNET-DRAFT Behavior of a Mobility Agent October, 2001 7. References [1] C. Perkins, Editor, "IP Mobiity Support", RFC 2002, October 1996. [2] MIPv4 Handoffs Design Team, "Low Latency Handoffs in Mobile IPv4", draft-ietf-mobileip-lowlatency-handoffs-v4-01.txt, work in progress, May 2001. [3] M. Khalil et. al., "Buffer Management for Mobile IP", draft-mkhalil-mobileip-buffer-00.txt, October 1999. 8. Authors' Addresses Koichi Ishibashi Mitsubishi Electric Corporation 5-1-1 Ofuna, Kamakura, Kanagawa 247-8501, JAPAN Phone: +81 467-41-2430 Enail: ishi@isl.melco.co.jp Keiichi Shimizu Mitsubishi Electric Corporation 5-1-1 Ofuna, Kamakura, Kanagawa 247-8501, JAPAN Phone: +81 467-41-2869 Enail: kei1@csc.melco.co.jp Shoichiro Seno Mitsubishi Electric Corporation 5-1-1 Ofuna, Kamakura, Kanagawa 247-8501, JAPAN Phone: +81 467-41-2430 Enail: senos@isl.melco.co.jp Ishibashi, Shimizu, Seno Expires April 2002 [Page 9]