Internet DRAFT - draft-ogashiwa-mip4-bid-extension

draft-ogashiwa-mip4-bid-extension









MIP4                                     Nobuo Ogashiwa(INTEC Netcore)
Internet-Draft                           Kenichi Nagami(INTEC Netcore)
Expires: January 1, 2006                  Ikuo Nakagawa(INTEC Netcore)
                                                   Satoshi Uda (JAIST)
                                            Ryuji Wakikawa(Keio Univ.)
                                            Hiroshi Esaki(Univ. Tokyo)
                                                 Hiroyuki Ohnishi(NTT)
                                                           Jul 1, 2005


              Binding Identifier Extension for Mobile IPv4
               <draft-ogashiwa-mip4-bid-extension-00.txt>

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on January 1, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2005).  All Rights Reserved.

Abstract

   This document specifies a new extension for Registration Request
   message and Registration Reply message in Mobile IPv4. This
   extension can be added by mobile mode and home agent to
   Registration Request and Registration Reply messages. This
   extension carries an identification of binding of a care-of
   address.







Ogashiwa, et al.         Expires January 1, 2006                [Page 1]

Internet-Draft           BID Extension for MIP4                 Jul 2005


1. Introduction

   According to the current MIP4 specification, mobile node can register
   multiple care-of addresses (CoA) to home agent. This can be done by
   setting simultaneous binding bit ('s' bit) of Registration Request
   message. This implies that the current MIP4 specification is
   applicable to multi-homing.

   The MIP4 specification document [RFC3344] also describes home
   agent's behavior as follows:

      "When the home agent allows simultaneous bindings, it will
      tunnel a separate copy of each arriving datagram to each care-of
      address, and the mobile node will receive multiple copies of
      datagrams destined to it."

   In multi-homing environment, mobile node and home agent can use
   multiple links efficiently by dividing or limiting flows or traffic
   for each tunnel using additional systems implemented on home agent
   and mobile node. However, home agent can not divide or limit flows
   to appropriate tunnels without binding information of CoA and
   network interface of mobile node.

   This document specifies a new extension for use in Mobile IPv4.
   This extension can be added by mobile node and home agent to
   Registration Request and Registration Reply messages. This
   extension carries an identification of binding of care-of address
   of the mobile node. By using this extension, mobile node can inform
   binding of coa and network interface of mobile node.

   Furthermore, by using this extension, mobile node can modify
   specific care-of address previously registered by single
   Registration Request even if the home agent has several care-of
   address registration for the mobile node.

   This specification does not require any changes to deployed MIP4
   implementations and the current MIP4 specification. Home Agent and
   Mobile Node that does not support this extension can silently
   discard messages which includes this extension.

2.  Terminology

   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.












Ogashiwa, et al.         Expires January 1, 2006                [Page 2]

Internet-Draft           BID Extension for MIP4                 Jul 2005


3. Motivation

3.1 Multihoming Using Multiple Physical Links

   As mentioned above, home agent and mobile node can use multiple
   links efficiently by using additional system since each links has
   different characteristics.  For example, a user requires to use
   low-latency link for latency-sensitive application such as VoIP and
   use other links for other applications. In such situation, home
   agent have to know bindings of care-of address and mobile node's
   network interface due to split downstream traffic to appropriate
   tunnels.

   The mobile node can inform own binding of care-of address and
   network interface by using Multiple Care-of Address Extension
   proposed in this document.  The discussion of the system to divide
   or limit user traffic to multiple tunnels is out of scope of this
   document.

   The figure 1 and following configurations are example of use of
   Multiple Care-of Address Extension.  The BID which is assigned to
   the binding carried in the Registration Request and Registration
   Reply. In a mobile node, each network interfaces have one or more
   BID.

                     i/f-1(BID1,low-latency, 32kbps)
                      +----------------+
                    +-++          +----+---+     +--+
                    |MN|          |Internet+-----+HA|
                    +-++          +----+---+     +--+
                      +----------------+
                     i/f-2(BID2, high-latency 54Mbps)

                         Fig.1 Example Network

    The MN and the HA's configuration is following:

    Home Agent's Configuration:
     MN, BID1, VoIP traffic
     MN, BID2, other traffic

    Mobile Node's Configuration:
     i/f-1, BID1
     i/f-2, BID2

    The MN acquires CoA1 and CoA2 for i/f-1 and i/f-2, then the MN
    send registration request messages to the HA, which include BIDs for
    each interfaces. After that, HA's registration database becomes as
    following:

    Home Agent's Registration Database:
     HoA, CoA1, BID1
     HoA, CoA2, BID2




Ogashiwa, et al.         Expires January 1, 2006                [Page 3]

Internet-Draft           BID Extension for MIP4                 Jul 2005


    The HA knows the bindings of BID and CoA of the MN as above
    database.  The HA also knows appropriate filter rules bound to
    each BIDs due to the HA's configuration so that the HA can apply
    filter rules to HA's tunnel interfaces.

3.2 CoA Modification by Single Registration Request

   The current MIP4 specification [RFC3344] doesn't define the
   operation to modify a CoA previously registered to home agent.  In
   case of that the 'S' bit doesn't set, the distinct definition of
   the modify operation is needless since the CoA registration will be
   overrided by new one. In case of the 'S' bit set and several CoAs
   are registered to the home agent, mobile node have to register a
   new CoA, and then deregister the old CoA since the modify operation
   is not defined.

   When the mobile node modify the CoA previously registered to the
   home agent by single operation, the home agent can keep
   communication between the mobile node and correspondent
   node. However, when the mobile node modify the CoA previously
   registered to the home agent by multiple operation such as
   deregister old one and register new one, the home agent cannot keep
   communication between the mobile node and correspondent node.

   When the number of CoA reach maximum limit, mobile node cannot
   register new CoA.  To avoid this, if the mobile node deregister old
   CoA before register new CoA, mobile node and correspondent node can
   not keep communication.

   If mobile node can change CoA registered to the home agent by
   single operation, home agent will be able to modify the mobile
   node's CoA entry in own CoA database keeping communication between
   mobile node and correspondent node.
























Ogashiwa, et al.         Expires January 1, 2006                [Page 4]

Internet-Draft           BID Extension for MIP4                 Jul 2005


4. Mobile IPv4 Multiple Care-of Address Extension

   The format of the Multiple Care-of Address Extension is simple
   extension structure defined in MIP4 specification [RFC3344].  This
   extension is not skippable.

     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 = TBD  |   Length = 2  |     Binding Unique ID (BID)   |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Type

             Type value for Binding Unique Identifier will be assigned
             later. An 8-bit identifier of the option.

      Length

             The value MUST be always 2.

      Binding Unique ID (BID)

             The BID which is assigned to the binding carried in the
             Registration Request and Registration Reply.  BID is
             16-bit unsigned integer. A value of zero is reserved.

5. Use of the Multiple Care-of Address Extension

5.1 Changes to current MIP4 specification

   No changes is requiered for deployed implementations and current
   MIP4 basic specification. Home Agent and Mobile Node that doesn't
   support the Multiple Care-of Address Extension MAY silently discard
   messages which include the Multiple Care-of Address Extension or
   alternatively, Home Agent MAY return error code 128 ("reason
   unspecified") defined in MIP4 specification [RFC3344].




















Ogashiwa, et al.         Expires January 1, 2006                [Page 5]

Internet-Draft           BID Extension for MIP4                 Jul 2005


5.2 Home Agent and Mobile Node's behavior

   Following is mobile node's and home agent's behavior when they send
   or receive Registration Request and Registration Reply.

   mobile node:

   o statically or dinamically decide binding unique indentifier per
     mobile node's network interfaces or bindings.

   o when send registration request, attach BID to the message using
     Multiple Care-of Address Extension.

   o when change specific CoA previously registered, send registration
     request which include new CoA and appropriate BID.

   home agent:

   o when receive registration request which includes Multiple Care-of
     Address Extension, if the home agent doesn't support the
     extension, then return error code or, alternatively silently
     discard the message.

   o if home agent already know the BID then override old CoA by new
     CoA.  And then, home agent send registration reply message which
     include Multiple Care-of Address Extension.

   o if home agent doesn't know the BID then store the CoA and BID
     into own database.  And then, home agent send registration reply
     message which include Multiple Care-of Address Extension.

   When the Multiple Care-of Address Extension is added, the
   simulutaneous binding bit should be set. If the simulutaneous
   binding bit is not set, home agent and mobile node should ignore
   the Multiple Care-of Address Extension and should act as
   traditional home agent and mobile node described in the MIP4
   specification [RFC3344].

6. Security considerations

    This draft does not raise specific security issues beyond those of
    existing Mobile IP protocols.

7. IANA Considerations

   This specification reserves one number for the Multiple Care-of
   Address Extension Section 3 from the space of numbers for
   non-skippable mobility extensions defined for Mobile IPv4 [MIP4] at
   http://www.iana.org/assignments/mobileip-numbers. The value 50 is
   recommended for this extension.

References

    [MIP4] C. Perkins, Ed. "IP Mobility Support for IPv4",



Ogashiwa, et al.         Expires January 1, 2006                [Page 6]

Internet-Draft           BID Extension for MIP4                 Jul 2005


           RFC 3344, August 2002.


Author's Addresses

    Nobuo Ogashiwa
    INTEC NetCore Inc.
    1-3-3, Shin-suna, Koto-ku, Tokyo, 135-0075, Japan
    Email: ogashiwa@inetcore.com

    Kenichi Nagami
    INTEC NetCore Inc.
    1-3-3, Shin-suna, Koto-ku, Tokyo, 135-0075, Japan
    Email: nagami@inetcore.com

    Ikuo Nakagawa
    INTEC NetCore Inc.
    1-3-3, Shin-suna, Koto-ku, Tokyo, 135-0075, Japan
    Email: ikuo@inetcore.com

    Satoshi Uda
    School of Information Science Japan Advanced Institute of
    Science and Technology
    1-1 Asahidai, Tatsunokuchi, Ishikawa, 923-1292, Japan
    Email: zin@jaist.ac.jp

    Hiroshi Esaki
    Graduate School of Information Science and Technology,
    The university of Tokyo
    7-3-1 Hongo, Bunkyo-ku, Tokyo, 113-8656, Japan
    Email: hiroshi@wide.ad.jp

    Ryuji Wakikawa
    Keio University and WIDE
    5322 Endo Fujisawa Kanagawa, 252-8520, Japan
    Email:  ryuji@sfc.wide.ad.jp

    Hiroyuki Ohnishi
    NTT Network Service Systems Laboratories, NTT Corporation
    9-11, Midori-Cho, 3-Chome
    Musashino-Shi, Tokyo 180-8585, Japan
    Email: ohnishi.hiroyuki@lab.ntt.co.jp

Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed
   to pertain to the implementation or use of the technology described
   in this document or the extent to which any license under such
   rights might or might not be available; nor does it represent that
   it has made any independent effort to identify any such rights.
   Information on the procedures with respect to rights in RFC
   documents can be found in BCP 78 and BCP 79.




Ogashiwa, et al.         Expires January 1, 2006                [Page 7]

Internet-Draft           BID Extension for MIP4                 Jul 2005


   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use
   of such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository
   at http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Disclaimer of Validity

   THIS DOCUMENT AND THE INFORMATION CONTAINED HEREIN ARE PROVIDED ON
   AN "AS IS" BASIS AND THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
   REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES,
   EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT
   THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR
   ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
   PARTICULAR PURPOSE.


Copyright Statement

   Copyright (C) The Internet Society (2005).  This document is
   subject to the rights, licenses and restrictions contained in BCP
   78, and except as set forth therein, the authors retain all their
   rights.


Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.



















Ogashiwa, et al.         Expires January 1, 2006                [Page 8]