[Docs] [txt|pdf] [Tracker] [WG] [Email] [Nits]

Versions: 00 01 02 03 04 05 06 07 08 09 10 11 RFC 6089

IETF MEXT Working Group                                       H. Soliman
Internet-Draft                                      Elevate Technologies
Expires: November 17, 2008                                  N. Montavont
                                                     IT/Telecom Bretagne
                                                             N. Fikouras
                                                          K. Kuladinithi
                                                    University of Bremen
                                                            May 16, 2008


          Flow Bindings in Mobile IPv6 and Nemo Basic Support
                  draft-ietf-mext-flow-binding-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 November 17, 2008.

Copyright Notice

   Copyright (C) The IETF Trust (2008).










Soliman, et al.         Expires November 17, 2008               [Page 1]

Internet-Draft                Flow binding                      May 2008


Abstract

   This document introduces extensions to Mobile IPv6 [1] and Nemo Basic
   Support [2] that allow nodes to bind one or more flows to a care-of
   address.  These extensions allow multihomed nodes to take full
   advantage of the different properties associated with each of their
   interfaces.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4

   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  6

   3.  Mobile IPv6 Extensions . . . . . . . . . . . . . . . . . . . .  7
     3.1.  Flow Identification option . . . . . . . . . . . . . . . .  7
     3.2.  The Binding Reference Sub-option . . . . . . . . . . . . . 10
     3.3.  Binding Cache and Binding Update list extensions . . . . . 10

   4.  Protocol operations  . . . . . . . . . . . . . . . . . . . . . 12
     4.1.  Interaction with the Multiple CoA bindings mechanism . . . 12
     4.2.  Flow binding storage . . . . . . . . . . . . . . . . . . . 12
     4.3.  Preferred Care-of address  . . . . . . . . . . . . . . . . 13
     4.4.  Adding flow bindings . . . . . . . . . . . . . . . . . . . 13
     4.5.  Modifying flow bindings  . . . . . . . . . . . . . . . . . 14
     4.6.  Removing flow bindings . . . . . . . . . . . . . . . . . . 14
     4.7.  Refreshing Flow Bindings . . . . . . . . . . . . . . . . . 15
     4.8.  Acknowledging flow identification options  . . . . . . . . 15

   5.  Usage scenario . . . . . . . . . . . . . . . . . . . . . . . . 16

   6.  Mobile Node operations . . . . . . . . . . . . . . . . . . . . 18
     6.1.  Default Bindings . . . . . . . . . . . . . . . . . . . . . 18
       6.1.1.  Managing Flow Bindings with the Home Agent and MAP . . 18
       6.1.2.  Managing Flow Bindings in Correspondent nodes  . . . . 19
       6.1.3.  Using Alternate Care-Of Address  . . . . . . . . . . . 19
       6.1.4.  Receiving Binding Acknowledgements . . . . . . . . . . 20
     6.2.  Movement . . . . . . . . . . . . . . . . . . . . . . . . . 20
     6.3.  Return Routability Procedure . . . . . . . . . . . . . . . 20
     6.4.  Returning Home . . . . . . . . . . . . . . . . . . . . . . 21

   7.  Applicability to Route Optimization  . . . . . . . . . . . . . 22
     7.1.  Receiving Binding Udpate . . . . . . . . . . . . . . . . . 22

   8.  Home Agent operations  . . . . . . . . . . . . . . . . . . . . 24
     8.1.  Receiving Binding Update with the Flow Identification
           option . . . . . . . . . . . . . . . . . . . . . . . . . . 24



Soliman, et al.         Expires November 17, 2008               [Page 2]

Internet-Draft                Flow binding                      May 2008


     8.2.  Sending Binding Ackowledgement . . . . . . . . . . . . . . 25
     8.3.  Deleting an entry in the binding cache . . . . . . . . . . 25
       8.3.1.  Removing Flow Bindings . . . . . . . . . . . . . . . . 25

   9.  Applicability to Hierarchical Mobile IPv6  . . . . . . . . . . 27

   10. Security considerations  . . . . . . . . . . . . . . . . . . . 28

   11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 29

   12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30

   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31
   Intellectual Property and Copyright Statements . . . . . . . . . . 32





































Soliman, et al.         Expires November 17, 2008               [Page 3]

Internet-Draft                Flow binding                      May 2008


1.  Introduction

   Mobile IPv6 (RFC3775) [1] and Nemo Basic Support (RFC3963) [2] allow
   a mobile node / mobile router to manage its mobility using the
   binding update message, which binds one care-of address to one home
   address.  The binding update message can be sent to the home agent.
   In Mobile IPv6, the Binding Update can also be sent to correspondent
   node or to a mobility anchor point (see RFC4140 [3]).  The semantics
   of the binding update are limited to address changes.  That is,
   RFC3775 [1] and RFC3963 [2] do not allow a mobile node / mobile
   router to bind more than one address to the home address.
   Furthermore, the binding granularity is limited to the address.
   Therefore, a mobile host cannot associate one of the connections
   using the home address with a different care-of address.  In
   draft-ietf-monami6-multiplecoa [4] Mobile IPv6 and Nemo Basic Support
   are extended to allow the binding of more than one care-of address to
   a home address.  This specification extends Mobile IPv6 and Nemo
   Basic Support to allow it to specify policies associated with each
   binding.  A policy can contain a request for a special treatment of a
   particular flow.  Hence, this specification allows a mobile node /
   mobile router to bind a particular flow to a care-of address without
   affecting other flows using the same home address.  In addition, we
   will see that this specification allows to bind a particular flow to
   a particular care-of address directly with correspondent node and
   mobility anchor point in the case of a single mobile node.

   In this document, a flow is defined as one or more connections that
   are identified by a flow identifier.  A single connection is
   typically identified by the source and destination IP addresses,
   transport protocol number and the source and destination port
   numbers.  Alternatively a flow can be identified in a simpler manner
   using the flow label field in the IPv6 header [5] or the Security
   Parameter Index (SPI) when IPsec is used.

   Flow bindings are useful in cases where the mobile node / mobile
   router has more than one address, probably due to being multihomed,
   and wants to direct certain flows to certain addresses [6], [7].
   This may be done because some flows are better suited to certain link
   layers or simply to load balance flows between different interfaces.
   This specification introduces the flow identifier option, which is
   included in the binding update message and used to distribute
   policies to the recipient of the binding update.  However, this
   document does not define the flow itself but only the action to take
   on this flow.  The flow description will be defined in another
   document.  This will allow to use the same flow description in
   several protocols.  Using the flow identifier option introduced in
   this specification a mobile node / mobile router can bind one or more
   flows to a care-of address while maintaining the reception of other



Soliman, et al.         Expires November 17, 2008               [Page 4]

Internet-Draft                Flow binding                      May 2008


   flows on another care-of address.  Requesting the flow binding can be
   decided based on local policies within the mobile node / mobile
   router and based on the link characteristics and the types of
   applications running at the time.  Such policies are outside the
   scope of this document.

   It should be noted that the flow identification option can be
   associated with any binding update, whether it is sent to a
   correspondent node (in the case of Mobile IPv6), home agent or
   mobility anchor point (in the case of Hierarchical Mobile IPv6).  A
   Similar mechanism for Mobile IPv4 is described in [8].

   In the rest of the document, the term "mobile node" is used to
   designate either a mobile node as defined in RFC3775 [1] or a mobile
   router as defined in RFC3963 [2] unless stated otherwise.




































Soliman, et al.         Expires November 17, 2008               [Page 5]

Internet-Draft                Flow binding                      May 2008


2.  Terminology

   Terms used in this document are defined in [9] and [10].  The
   following terms are also used in this document:

   Flow

      A flow is identified as a set of data packets that are exchanged
      between two distant hosts.

   Flow Description

      A set of instructions that describes a flow.

   Flow Identifier

      Identifier of a flow binding.

   Flow binding

      A mobility binding extended with a flow identifier and flow
      description.





























Soliman, et al.         Expires November 17, 2008               [Page 6]

Internet-Draft                Flow binding                      May 2008


3.  Mobile IPv6 Extensions

   This section introduces extensions to Mobile IPv6 that are necessary
   for supporting the flow binding mechanism described in this document.

3.1.  Flow Identification option

   The Flow identification option is included in the binding update and
   acknowledgement messages.  This option contains information that
   allows the receiver of a binding update to install policies on a
   traffic flow and route it to a given address.  Multiple options may
   exist within a binding update message.  The Flow identification
   option must come with another option (that will be defined in another
   document) that will describe the flow.  This additional option is
   called Flow Description in the remaining of this document.

       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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Option Type   |  Option Len   |   PRI         |    FID        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |        FID    |   Action      |  Status       |  PRO  |  Res. |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Flow Description ...


                 Figure 1: The flow identification option

   Option Type

      TBD

   Option Len

      Length of option in 8-octet units

   PRI

      This is a 8-bit priority field to indicate the priority of a
      particular option.  This field is needed in cases where two
      different flow descriptions in two different options overlap.  The
      priority field decides which policy should be in those cases.  A
      lower number in this field indicates a higher priority.

   FID

      The Flow Identifier field is an 8-bit unsigned integer that
      includes the identifier for the flow binding.  This field is used



Soliman, et al.         Expires November 17, 2008               [Page 7]

Internet-Draft                Flow binding                      May 2008


      to refer to an existing binding or to create a new binding.

   Action

      This field specifies the action that needs to be taken by the
      receiver of the binding update containing the flow identification
      option.

   Status

      This field indicates the success or failure of the flow binding
      operation for the particular flow in the option.  This field is
      not relevant to the binding update message as a whole or to other
      flow identification options.  Values from 0 to 127 indicate
      success.  Values of 128 and higher indicate failure.  This field
      is only relevant when included in the Binding Acknowledgement
      message and must be ignored in the binding update message.

   PRO

      This is a 4-bit field that describes the required processing for
      the option.  This field may indicate a request for adding,
      deleting, modifying or refreshing the option.  The details of
      these requests are discussed below.

   Res.

      This field is unused.  It MUST be initialized to zero by the
      sender and MUST be ignored by the receiver.

   The following values are reserved for the PRO field in this option:

   0 Add a flow binding

   1 Replace a flow binding

   2 Refresh the current binding

   15 Remove a flow binding

   The following values are reserved for the Action field in this
   option:

   1 Forward.  This value indicates a request to forward a flow to the
   address included or referred to by the option.

   2 Discard.  This value indicates a request to discard all packets in
   the flow described by this option.



Soliman, et al.         Expires November 17, 2008               [Page 8]

Internet-Draft                Flow binding                      May 2008


   3 n-cast.  This value indicates a request to replicate the flow to
   several addresses.  If this value is used, one or more Binding
   Reference sub-options MUST exist.  The Binding Reference sub-option
   is described later in this specification.

   The following values are reserved for the status field within the
   flow identification option:

   0 Flow binding successful.

   128 Flow binding rejected, reason unspecified.

   129 Flow binding option poorly formed.

   130 Administratively prohibited.

   131 Flow identification by IPv6 prefix is not supported.

   132 Flow identification by port numbers is not supported.

   133 Flow identification with Flow label is not supported.

   134 Flow identification with SPI is not supported.

   135 FID already in use

   136 FID not found

   137 Classifier language not supported.

   138 Discard function not supported.

   139 N-cast function not supported.


   It should be noted that per-packet load balancing has negative
   impacts on TCP congestion avoidance mechanisms as it is desirable to
   maintain order between packets belonging to the same TCP connection.
   This behaviour is specified in RFC2702 [11].  Other negative impacts
   are also foreseen for other types of real time connections due to the
   potential variations in RTT between packets.  Hence per-packet load
   balancing is not allowed in this extension.  However, the MN can
   still request per-flow load balancing provided that the entire flow
   is moved to the new interface.







Soliman, et al.         Expires November 17, 2008               [Page 9]

Internet-Draft                Flow binding                      May 2008


3.2.  The Binding Reference Sub-option

   This section introduces the Binding Reference sub-option, which may
   be included in the Flow identification option.  The Binding Reference
   sub-option includes one or more BIDs as defined in [4].  When this
   sub-option is included in the Flow identification option it
   associates the flow described with one or more BIDs that where
   already registered with the recipient of the BU.  A BID sub-option is
   not necessarily included in the same BU, but MUST be already known to
   the receiver of the BU.  The Binding Reference sub-option is shown
   below.


       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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |Sub-opt Type   |  Sub-Opt Len  |      BID      |     ......
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   ........
       +-+-+-+-



                Figure 2: The Binding Reference sub-option

   Sub-opt Type

      Indicates the Sub-option type.  For the Binding Reference sub-
      option, this field MUST be set to 1.

   Sub-opt Len

      Indicates the sub-option length in octets.  This field includes
      the entire length of the sub-option including the type and length
      fields.

   BID

      The BID that the mobile node wants to associate with the flow
      identification option.  One or more BID fields can be included in
      this sub-option.

3.3.  Binding Cache and Binding Update list extensions

   Flow bindings are conceptually stored in Binding Cache of home agent,
   mobility anchor point and correspondent node, and in Binding Update
   List of mobile node.  These logical structures need to be extended to
   include the following parameters (in addition to those described in



Soliman, et al.         Expires November 17, 2008              [Page 10]

Internet-Draft                Flow binding                      May 2008


   RFC3775 [1]):

   o  FID (Flow Identifier).  For a given home address, the FID MUST
      uniquely identify an entry, i.e. a unique flow binding.  An FID is
      only unique for a given home address.  Different mobile nodes can
      use the same FID value.

   o  Each attribute that constitutes the flow dsecription (and that are
      defined in a separate document).

   An entry in these structures is identified by the couple (home
   address, FID).







































Soliman, et al.         Expires November 17, 2008              [Page 11]

Internet-Draft                Flow binding                      May 2008


4.  Protocol operations

   The flow identification option defines the controls on flow bindings.
   The fields of the flow identification option are necessary for
   indexing flow identification options, indicating the sort of action
   that should be undertaken to the recipient's Binding Cache or for
   carrying the results of such a petition.  The flow description is
   transported in another option that will be defined in another
   document.  This separation is made to use the same flow description
   in various protocols.

   This specification allows mobile nodes to direct flows to a
   particular care-of address.  This can be done by aggregating many
   flows in the flow identification option (e.g. all TCP traffic), or by
   uniquely identifying a flow in the flow identification option.

   The remaining of this section discusses how mobile nodes can use the
   flow identification option when sending binding updates to the
   correspondent node, home agent or mobility anchor point.  In
   addition, deletion and modification of bindings are all discussed
   below.

4.1.  Interaction with the Multiple CoA bindings mechanism

   Flow binding presented in this specification MUST be used with the
   solution in [4].  The main reason why is to avoid the duplication of
   the default binding to be used when none of the registered rules can
   apply to a flow.  As the multiple CoA bindings document already
   defines a prority field which indicates which care-of address is
   preferred, flow binding uses this priority field in order to maintain
   a primary Care-of address (see below section Section 4.3).

   Moreover, combining the mechanism in this specification with the
   multiple CoA bindings allows for further aggregation of bindings.
   For example, if a mobile node has several flow identifiers bound to a
   single Care-of address identified by a unique BID, the mobile node
   can change the Care-of address for all these flows bindings just by
   changing the Care-of address associated with the given BID.

   Additionally, the combination of the two mechanisms allows for
   additional features (e.g., n-casting) to take place with minimal
   effort.  Hence, this specification makes use of the BID option
   described in [4].

4.2.  Flow binding storage

   Home agent, correspondent node and mobility anchor point maintain
   Binding Cache in order to record associations between home addresses



Soliman, et al.         Expires November 17, 2008              [Page 12]

Internet-Draft                Flow binding                      May 2008


   and care-of addresses of mobile nodes that are away from the home
   link.  Mobile nodes maintain binding update list to record binding
   between home address and care-of address.  RFC 3775 [1] allows mobile
   nodes to register only one care-of address per home address.  Thus a
   binding cache entry is uniquely identified by the home address.

   This specification extends the binding cache and the binding update
   list structures, and allows mobile node to (1) register multiple
   care-of addresses for a given home address and (2) associate flow
   binding policies with the registered care-of addresses.

   New parameters are added to these conceptual structures in order to
   list the particular rule associated with a standard binding.  On one
   hand, an entry is now identified by the pair (home address, FID)
   because several Care-of addresses may be bound to a single home
   address.  On the other hand, the Care-of address is selected
   according to the best match between the packets that need to be sent,
   and the existing flow bindings.  If no matching is found between the
   flow bindings and the data packet, a preferred entry is used (see
   next subsection).  If a flow matches two different flow bindings, the
   PRI field indicates which action is preferred by the mobile node.

4.3.  Preferred Care-of address

   Any distant node which supports the flow identification option MUST
   maintain a default binding per home address.  A default binding
   indicates an association between a home address and a Care-of
   address.  In addition to the default binding, several bindings may
   co-exist within a binding cache for the same home address, each of
   them indicating different bindings between flows and Care-of
   addresses.  When a data flow is intercepted by a home agent or
   initiated by a correspondent node, if the said data flow does not
   match an existing flow identification option, the care-of address
   indicated in the default binding is used as destination address for
   the mobile node.  The default binding is indicated by the Priority
   field in the BID option described in [4].  A mobile node is
   responsible for having a preferred care-of address with the receiver
   of the flow identification option.

4.4.  Adding flow bindings

   When adding a new flow binding, a mobile node sends the flow
   identification option in the binding update.  The care-of address
   concerned with this binding update must already be registered by the
   receiver of the binding update (i.e., must already be associated with
   a BID), or a BID sub-option MUST be present in the binding update (as
   defined in [4]).  The flow identification option MUST include a
   unique FID.  The FID needs only be unique for the receiver of the



Soliman, et al.         Expires November 17, 2008              [Page 13]

Internet-Draft                Flow binding                      May 2008


   binding update, i.e. the same FID can be used across different
   receivers of the binding update.  The PRO field MUST indicate an Add
   operation.  Adding the flow binding implies associating a flow with a
   particular care-of address for the mobile node.  The care-of address
   concerned with the flow binding is present in the source address of
   the packet or the alternate care-of address option.  Alternatively,
   the care-of address may be indicated by the BID (which is pointing to
   an existing care-of address) when the Binding Reference sub-option of
   the Flow Identification option is present.

   The mobile node may need to define the flow partially or entirely
   based on the source and destination addresses in packets.  For
   instance, a mobile node may choose to forward all flows from address
   A to address B to a particular care-of address.  Alternatively, more
   granularity can be added by including port numbers and protocol.
   These descriptions will be given in another document.

   An Add operation implies that the FID is new and is not already used
   by the mobile node for any other flow binding.  If the Flow
   identification option is sent without any flow description and with
   the PRO field indicating an Add operation, this MUST be seen as a
   wild card request by the sender.  A wild card request implies that
   all flows should be directed to the particular care-of address in the
   packet.

4.5.  Modifying flow bindings

   When modifying a flow binding (either the care-of address or other
   attributes of the flow), the mobile node sends the binding update
   with a flow identification option.  The option includes the FID for
   the binding being modified, as well as the PRO field set to 1,
   indicating a request to modify the binding.  A flow description
   option may come with the flow identification option and contain the
   new attributes needed to classify the flow.  Hence, flow modification
   is essentially a process where an existing flow definition is removed
   and a new flow (included in the option) is added and given the same
   FID as the flow that was removed.

   If one of the care-of addresses needs to be updated with a new one
   (e.g., after a change of the IP point of attachment), the mobile node
   may just need to register the new care-of address for the given BID.

4.6.  Removing flow bindings

   When removing a flow binding, the mobile node sends a binding update
   message with the flow identification option.  The PRO field MUST be
   set to a value of 15, which indicates a request for removing a flow
   binding.  This will provide enough information for the receiver to



Soliman, et al.         Expires November 17, 2008              [Page 14]

Internet-Draft                Flow binding                      May 2008


   locate the flow binding using the FID and remove it.

4.7.  Refreshing Flow Bindings

   A flow binding is refreshed by simply including the Flow
   identification option in the BU message.  In this case the PRO field
   is set to indicate a refresh operation.

   The refresh operation is included in this specification due to the
   nature of the BU message.  The BU message updates existing bindings
   with new information.  Hence, all information previously sent in the
   last BU message need to be resent in all new messages, otherwise such
   information will be lost.

4.8.  Acknowledging flow identification options

   The home agent and mobility anchor point are required to ackowledge
   the reception of Binding Update by sending Binding Acknowledgment.  A
   correspondent node SHOULD also acknowledge Binding Update.  The
   Binding Acknowledgement is extended by this specification to indicate
   to the mobile node the success of the flow binding.  If a Binding
   Acknowledgement needs to be sent in response to a Binding Update that
   contained flow identification option(s), a copy of each flow
   identification MUST be included.  Only the Status field needs to be
   changed to the appropriate value.  The absence of flow identification
   option in Binding Acknwoledgement indicates that the sender does not
   support the extension descibed in this document and therefore MUST be
   interpreted as a negative acknowledgement.























Soliman, et al.         Expires November 17, 2008              [Page 15]

Internet-Draft                Flow binding                      May 2008


5.  Usage scenario

   In this section, we highlight a use case of the flow identification
   option.

   Assume a mobile node equipped with two interfaces namely If1 and If2,
   each connected to a different foreign network.  The mobile node
   configures one global IPv6 address on each interface, namely CoA1 and
   CoA2 respectively.  The mobile node runs Mobile IPv6 with a home
   agent located in its home network.  We assume that an existing IPsec
   security association is set up betweeen the mobile node and its home
   agent.  We assume that the mobile node wants to exchange secure data
   flows over CoA1 and insecure data flows over CoA2.  To do so, the
   mobile node may request its home agent to redirect packets intended
   to the mobile node's home address to a different care-of address,
   depending on the type of the communication.  For example, port
   numbers 22 (ssh) and 443 (https) may be tunneled to CoA1 while other
   communications may be tunneled to CoA2.  In order to set up these
   flow bindings, the following messages are exchanged:

   o  The mobile node sends a Binding Update through If2, with the
      source address set to CoA2.  The Binding Update includes a BID
      sub-option as described in [4].  This sub-option intends to set
      the highest preference on the given Care-of address.

   o  When the home agent receives the Binding Update, it first
      validates the Binding Update as recommanded in section 10.3 of
      [1].  If the Binding Update is accepted, the home agent processes
      the BID sub-option as described in section 6.2 of [4].  It then
      registers the source address of the Binding Update as the
      preferred care-of address for the given home address and sends
      back a Binding Acknowledgement.

   o  Later, the mobile node sends additional Binding Update with both
      Flow Identification options and BID sub-option of [4].  The BID
      sub-option is used to indicate the priority of the new Care-of
      address.  In this example, the priority must be lower than the
      priority of CoA2.  The flow identification options are used to
      indicate the Care-of address usage preferences.  In order to
      redirect source port numbers 22 and 443 to CoA1, two flow
      identification options need to be transported as well in the
      Binding Update.  These flow identification options are set as
      follows: PRI is set to 1, Action is set to 0 (forward), PRO is set
      to 0 (add), FID is set to 1 (and 2 for the second option), and the
      following flow description option should indicate port number 22
      and 443.





Soliman, et al.         Expires November 17, 2008              [Page 16]

Internet-Draft                Flow binding                      May 2008


   o  When the home agent receives this second Binding Update, it first
      checks the validity of the Binding Update as recommanded in
      section 10.3 of [1] and section 6.2 of [4].  If the Binding Update
      is accepted, the Flow Identification options are treated.  If
      these options are accepted by the home agent, it will return a
      Binding Acknowledgement with Flow Identification options, each of
      them having the same first 8 bytes, and the Status field set to 0
      (success).

      Thereafter, if a data flow is destinated to the home address of
      the mobile node, the home agent will determine if the source port
      number is equal to 22 or 443.  If yes, the home agent will tunnel
      the data flow to CoA1.  If not, the data flow will be forwarded to
      CoA2.





































Soliman, et al.         Expires November 17, 2008              [Page 17]

Internet-Draft                Flow binding                      May 2008


6.  Mobile Node operations

6.1.  Default Bindings

   A default binding is always maintained between a MN and its peers
   (home agent, correspondent node if RO is used and mobility anchor
   point if applicable).  The default entry indicates which care-of
   address to use for a data flow that does not match any of the flow
   bindings.  The preferred care-of address is determined through the
   BID option described in [4].

6.1.1.  Managing Flow Bindings with the Home Agent and MAP

   A mobile node may establish a Flow Binding by issuing a Binding
   Update containing a Flow Identifier (possibly associated with a Flow
   Description) in its mobility options.  The Flow Identification option
   MUST indicate valid FID, PRO, PRI (rule priority) and Action fields.

   The PRO field of the Flow Identification option indicates the
   processing that the targeted node has to perform to its Bindings
   Cache List.  A mobile node may request for any of the following
   requests:

   o  0: Add flow binding.  Create a new Flow Binding with the indicated
      FID and include the attached Flow.  A mobile node MUST NOT issue a
      Flow Identifier with the PRO field set to zero for an existing
      FID.

   o  1: Replace a flow binding.  This request enables the mobile node
      to replace attributes of the flow or the care-of address
      associated with the FID.  A mobile node MUST NOT issue a Flow
      Identifier with the PRO field set to one for a non existent FID.

   o  2: Refresh a flow binding.  This request allows the mobile node to
      inform the receiver of the BU message that the flow binding is
      still valid.  This request does not modify the flow option.  A
      flow identification option MUST NOT contain this value in the PRO
      field for a non-existent FID.

   o  15: Remove a flow binding.  This action enables a mobile node to
      remove the Flow Binding indicated by the FID on the targeted node.
      A mobile node MUST not issue a Flow Identifier with the PRO field
      set to 15 for a non existent FID.

   When adding a flow binding on the home agent or MAP, the mobile node
   MUST ensure the following:





Soliman, et al.         Expires November 17, 2008              [Page 18]

Internet-Draft                Flow binding                      May 2008


   o  The PRO field MUST be set to indicate an Add operation.

   o  The FID field includes a value that does not already exist in the
      mobile node's binding update list.

   o  The PRI field is set to indicate the priority of the rule in case
      of an overlap between rules.  An overlap can occur when one flow
      matches multiple flow description options.

   o  If the Action field is set to indicate N-cast, the Binding
      Reference sub-option must be present and it must contain one or
      more BIDs.  If the Binding Update sub-option includes only one
      BID, it must be pointing to a care-of address other than the one
      included in the binding update.

6.1.2.  Managing Flow Bindings in Correspondent nodes

   When route optimisation is used (see RFC3775 [1]), a mobile node
   sends the BU message to the correspondent node after the return
   routability test procedure.  When adding flow bindings in the BU sent
   to the correspondent node, the mobile node MUST ensure the following:

   o  The FID field includes a value that is not already stored in the
      binding update list with the correspondent node's address.

   o  The PRO field is set to indicate an Add operation.

   A mobile node can also modify or delete flow bindings in a similar
   manner to that described earlier with the home agent and MAP.  When
   Modifying a flow binding, the mobile node MUST ensure that the FID
   used already exists.  The rest of the rules for modifying flow
   bindings are the same as those listed above for adding a flow
   binding.

   Refreshing and deleting flow bindings are done in the same manner as
   that described for the home agent and MAP with one exception: the
   mobile node MUST NOT refresh or delete bindings associated with any
   care-of address other than the one included in the BU message.

6.1.3.  Using Alternate Care-Of Address

   If the Alternate Care-of Address option is used in the Binding
   Update, it shall indicate the care-of address to be associated with
   the Flow Identification options.  The Flow Identification options
   shall contain the FID to be allocated to the Flow Binding.






Soliman, et al.         Expires November 17, 2008              [Page 19]

Internet-Draft                Flow binding                      May 2008


6.1.4.  Receiving Binding Acknowledgements

   According to [1] all nodes are required to silently ignore mobility
   options not understood while processing Binding Updates.  As such a
   mobile node receiving a Binding Acknowledgement in response to the
   transmission of a Binding Update MUST determine if the Binding
   Acknowledgement contains a copy of the 8 bytes of every Flow
   Identification options included in the Binding Update.  A Binding
   Acknowledgement without Flow Identification option(s) would indicate
   inabillity on behalf of the source node to support the extensions
   presented in this document.

   If a received Binding Acknowledgement contains a copy of the 8 bytes
   of each flow identification option that was sent within the Binding
   Update, the status field of each flow identification option indicates
   the status of the flow binding on the distant node.

6.2.  Movement

   When a MN changes its point of attachment to the Internet, its
   Care-of address(es) may become invalid and need to be updated.  All
   the flow bindings that are attached to such an old Care-of address
   need to be udpated with a new Care-of address.  This can be achieved
   by adding flow identification options in Binding Update.  One flow
   identification is needed per flow binding.  The flow description may
   not be needed if only the Care-of address is changed, and not the
   filter itself.  The FID must be set to the flow binding that needs to
   be udpated and the PRO field MUST be set to 1 (i.e., MODIFY).

   Another solution is to take advantage of the multiple care-of
   addresses bindings [4] to aggregate updates; the mobile node may only
   need to update the care-of address associated with the given BID.
   This would avoid to send a flow identification option per flow
   binding.

6.3.  Return Routability Procedure

   A mobile node may perform route optimization with correpondent nodes.
   Route optimization allows a mobile node to bind a care-of address to
   a home address in order to allow the correspondent node to direct the
   traffic to the current location of the mobile node.  Before sending a
   Binding Update to correspondent node, the Return Routability
   Procedure needs to be performed between the mobile node and the
   correspondent node.

   This procedure is not affected by the extensions defined in this
   document.  However, since a Binding Update message is secured with
   the key generated based on the home address and care-of address test,



Soliman, et al.         Expires November 17, 2008              [Page 20]

Internet-Draft                Flow binding                      May 2008


   a mobile node MUST NOT bind a flow to a care-of address whose keygen
   token (see RFC3775 [1]) was not used to generate the key for securing
   the Binding Update.  This limitation prohibits the sender from
   requesting the n-cast action before having registered each care-of
   address one by one.

6.4.  Returning Home

   Whenever a mobile node acquires a point of attachment to the home
   network and wishes to abolish all Flow Bindings associated with the
   respective home address, it is required to act as described in
   Section 11.5.4 of RFC3775 [1].  This will cause the home agent to
   remove all bindings that are linked to the home address, including
   the flow bindings.





































Soliman, et al.         Expires November 17, 2008              [Page 21]

Internet-Draft                Flow binding                      May 2008


7.  Applicability to Route Optimization

   The route optimization is only defined for mobile nodes (RFC3775
   [1]), and not mobile router (RFC3963 [2]).  Thus, this section does
   not apply to mobile routers.  This section describes the
   correspondent node operations.

   Every correspondent node is required to maintain a Binding Cache
   containing records of associations between mobile node home addresses
   and care-of addresses (bindings) as they roam away from the home
   network.  RFC3775 [1] allows mobile nodes to register only a single
   binding per home address with each correspondent node.

   This specification extends the binding cache structure, and enables
   correspondent nodes to (i) maintain multiple bindings for a given
   home address and (ii) to associate multiple Flow Identification /
   description options with every binding, termed as Flow Binding.  A
   flow matching a Flow Description should be directed to the Care-of
   address indicated by the Flow Binding.

7.1.  Receiving Binding Udpate

   When a correspondant node receives a Binding Update, it first
   performs the same operation as defined in RFC3775 [1].  If the
   Binding Update is valid and contains a Flow identification option,
   the correspondent node needs to check the content of the PRO field.
   If the PRO field contains a value indicating a request to add a new
   flow binding, the following checks are done:

   o  The FID field needs to contain a value that does not already
      exist.  If the FID contains a value that already exists, the
      correspondent node MUST reject the option by sending that option
      back in its Binding Acknowledgement with a Status field that
      contains an error value.

   o  If the Action field indicates a request to n-cast the flow, the
      correspondent node MUST reject the option by sending the option in
      its binding acknowledgement with an appropriate error code.

   o  If both the FID and Action fields are valid, the correspondent
      node checks the flow description that must follow the flow
      identification option.  If all of the checks above indicated a
      valid option, the correspondent node should add the flow binding
      to its binding cache.

   If the PRO field in the option indicates a request to modify the
   option, the following checks must be done by the correspondent node:




Soliman, et al.         Expires November 17, 2008              [Page 22]

Internet-Draft                Flow binding                      May 2008


   o  The FID MUST include a value that already exists.  If the FID
      cannot be found in the correspondent node's binding cache, the
      flow identification option MUST be rejected with an appropriate
      error code.

   o  If the Action field indicates a request to n-cast the flow, the
      correspondent node MUST reject the option by sending the option in
      its binding acknowledgement with an appropriate error code.

   o  If the Binding Reference sub-option is present, the correspondent
      node MUST ensure that the BID points to the care-of address in the
      packet, or to an already authrozied care-of address.  Otherwise
      the option MUST be rejected with an appropriate error code.

   o  If all of the above checks returned a valid result, the
      correspondent node should modify the binding as requested.

   If the PRO field in the option contains a request to refresh a
   binding, the correspondent node MUST ensure that the FID already
   exists.  If the FID does not exist, the correspondent node MUST
   reject the option by sending it back in its binding acknowledgement
   with an appropriate error code in the status field.  Otherwise, if
   the FID exists, the correspondent node must keep it in its binding
   cache.  No further checks need to be done in the option.

   The correspondent node should reply with a Binding Acknowledgement
   message.  This Binding Acknowlegement message must contain a copy of
   the 8 bytes of each flow identification option that was included in
   the Binding Udpate.  The Status field of each Flow Identification
   option MUST be set to an appropriate value.





















Soliman, et al.         Expires November 17, 2008              [Page 23]

Internet-Draft                Flow binding                      May 2008


8.  Home Agent operations

   This specification allows the home agent to maintain several bindings
   for a given home address and to direct packets to different care-of
   addresses according to flow bindings.  This section details the home
   agent operations necessary to implement this specification.

8.1.  Receiving Binding Update with the Flow Identification option

   When the home agent receives a Binding Update which includes at least
   one Flow Identification option, it first performs the operation
   described in section 10.3.1 of RFC3775.  If the Binding Update is
   accepted, the home agent then checks the flow identification option.
   If the PRO field in the option indicates an Add operation, the
   following checks must be done:

   o  The FID field needs to contain a value that does not already
      exist.  If the FID contains a value that already exists, the home
      agent MUST reject the option by sending that option back in its
      Binding acknowledgement with a Status field that contains an
      appropriate error value.

   o  If the FID field is valid, the home agent then checks the Action
      field.  If the Action field contains a request for n-cast and the
      Binding Reference sub-option is not included in the option, the
      flow binding MUST be rejected in the binding acknowledgement
      containing an error code in the Status field.

   o  If both of the checks above indicate valid FID and Action fields,
      the home agent checks the flow description following the flow
      identification option, and identifies the filter that needs to be
      set up.

   o  If the flow option includes an action field that requests
      n-casting, the home agent MUST check for the presence of the BID
      sub-option(s).  If the sub-options are not present, the flow
      identification option MUST be rejected as a poorly formatted
      option.  If one or more BIDs are present in the BID Reference sub-
      option, the home agent needs to create multiple logical entries in
      its binding cache.  All flows matching the one in the option would
      be n-cast to the care-of addresses pointed to by the BIDs or the
      set of registered care-of addresses.  If only one BID were
      included in the Binding Reference sub-option and it pointed to a
      different care-of address from the one included in the packet,
      then packets matching the flow would be bicast to those two
      addresses.  However, if only one BID is present and points to the
      same address in the BU, the n-cast is essentially pointing to one
      address and therefore cannot be performed.  Such option MAY be



Soliman, et al.         Expires November 17, 2008              [Page 24]

Internet-Draft                Flow binding                      May 2008


      rejected as a poorly formatted option.

   o  If all of the checks above indicated a valid option, the home
      agent should add the flow binding to its binding cache.

   If the PRO field in the option contains a value indicating a request
   to modify an existing binding, the following actions must be taken:

   o  The FID MUST include a value that already exists.  If the FID
      cannot be found in the home agent's binding cache, the flow
      identification option MUST be rejected as a poorly formed option.

   o  If the FID is valid, the home agent MUST perform the same steps
      described above for the Add operation.

   If the PRO field indicates a refresh operation, the home agent MUST
   ensure that the FID in the option already exists.  If the FID field
   did not exist, the option MUST be rejected as a poorly formed option.
   If the FID existed, the home agent MUST keep the current flow binding
   in its binding cache.

8.2.  Sending Binding Ackowledgement

   Upon the reception of a Binding Update, the home agent is required to
   send back a Binding Acknowledgment.  The status code in the Binding
   Acknowledgement must be set as recommanded in [1] and is not modified
   by the extension defined in this specification.  This status code
   does not give information on the success or failure of the flow
   binding.

   In order to inform about the status of the flow binding that was
   requested by a mobile node, a flow identification option MUST be set
   in the Binding Acknowledgement message.  The home agent must copy the
   8 octets of each Flow Identification option received in the Binding
   Update and set the status code to an approriate value.  Each option
   must be included in the Binding Acknowledgement message.

8.3.  Deleting an entry in the binding cache

   A home agent might delete an entry in its binding cache for two
   reasons: either an entry expires, or the MN explicitly requests the
   home agent to remove a specific entry.  If an entry is going to
   expire, the home agent SHOULD send a Binding Refresh Advice.

8.3.1.  Removing Flow Bindings

   If the home agent receives a valid Binding Update with a flow
   Identification option where the PRO field is set to 15 (Remove), the



Soliman, et al.         Expires November 17, 2008              [Page 25]

Internet-Draft                Flow binding                      May 2008


   home agent MUST remove the corresponding entry.  The home agent looks
   up the entry corresponding to the FID of the Binding Update.  If an
   entry is found, the entry is removed from the Binding cache and a
   Binding Acknowledgement is sent back to the mobile node with a
   success value for the status of the flow Identification option (see
   section Section 8.2.  This operation does not modify any other
   binding that may appear with the same home address.  If the FID is
   not present in the binding cache entry for the corresponding home
   address, the home agent MUST send back to the mobile node a Binding
   Acknowledgement with error code 137 (FID not found) in the flow
   identification option.








































Soliman, et al.         Expires November 17, 2008              [Page 26]

Internet-Draft                Flow binding                      May 2008


9.  Applicability to Hierarchical Mobile IPv6

   This section describes the Mobility Anchor Point (MAP) operations.
   The MAP operation is the same as the home agent operation.  Flow
   bindings sent to the MAP are associated with the regional care-of
   address.

   When a MAP receives a Binding Update that includes the flow
   Identification option, it checks if such option is valid according to
   the requirements in Section 8.1.  If the option is valid, the MAP
   installs the flow binding associated with the flow identified by the
   flow description.  The lifetime of the binding is the lifetime of the
   Binding Update.  Once the binding is successfully installed, the MAP
   sends the binding acknowledgement and includes the flow
   Identification option.  The MAP sets the status field to a value
   indicating success.

   In all cases, a flow identification option SHOULD be included in the
   Binding Acknowledgement to indicate success or failure of the flow
   binding installation.































Soliman, et al.         Expires November 17, 2008              [Page 27]

Internet-Draft                Flow binding                      May 2008


10.  Security considerations

   This draft introduces a new option that adds more granularity to the
   Binding Update message.  The new option allows the mobile node to
   associate some flows to an interface and other flows to another
   interface.  Since the flow Identification option is part of the
   mobility header, it uses the same security as the Binding Update,
   whether it is sent to the home agent, correspondent node, or MAP.











































Soliman, et al.         Expires November 17, 2008              [Page 28]

Internet-Draft                Flow binding                      May 2008


11.  Acknowledgements

   We would like to thank all authors of initial I-Ds that were merged
   together to create this document; in alphabetical order: C.
   Castelluccia, K. ElMalki, K. Georgios, , C. Goerg, T. Noel, F.-N.
   Pavlidou.  Thanks to George Tsirtsis and Vince Park for their
   thorough review and input to the draft.  Gabor Fekete for the
   analysis that led to the inclusion of the BID support.  Henrik
   Levkowetz for suggesting the equivalent of the CLS field to allow
   other ways of describing flows.









































Soliman, et al.         Expires November 17, 2008              [Page 29]

Internet-Draft                Flow binding                      May 2008


12.  References

   [1]   Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in
         IPv6", RFC 3775, June 2004.

   [2]   Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert,
         "Network Mobility (NEMO) Basic Support Protocol", RFC 3963,
         January 2005.

   [3]   Soliman, H., Castellucia, C., ElMalki, K., and L. Bellier,
         "Hierarchical MIPv6 mobility management", RFC 4140,
         August 2005.

   [4]   Wakikawa, R., Ernst, T., and K. Nagami, "Multiple Care-of
         Addresses Registration", draft-ietf-monami6-multiplecoa-00
         (work in progress), June 2006.

   [5]   Deering, S. and R. Hinden, "Internet Protocol Version 6
         (IPv6)", IETF RFC 2460, December 1998.

   [6]   Montavont, N., Wakikawa, R., Ernst, T., Ng, C., and K.
         Kuladinithi, "Analysis of Multihoming in Mobile IPv6",
         draft-ietf-monami6-mipv6-analysis-01 (work in progress),
         June 2006.

   [7]   Ng, C., Paik, E., Ernst, T., and M. Bagnulo, "Analysis of
         Multihoming in Network Mobility Support",
         draft-ietf-nemo-multihoming-issues-06 (work in progress),
         June 2006.

   [8]   Zhao, X., Castelluccia, C., and M. Baker, "Flexible Network
         Support for Mobile Hosts", Journal ACM MONET, April 2001.

   [9]   Manner, J. and M. Kojo, "Mobility Related Terminology",
         RFC 3753, June 2004.

   [10]  Ernst, T. and H. Lach, "Network Mobility Support Terminology",
         draft-ietf-nemo-terminology-05 (work in progress), March 2006.

   [11]  Awduche, D., Malcolm, J., Agogbua, J., O Dell, M., and J.
         McManus, "Requirements for Traffic Engineering Over MPLS",
         RFC 2702, September 1999.

   [12]  Ernst, T., Montavont, N., Wakikawa, R., Ng, C., and K.
         Kuladinithi, "Motivations and Scenarios for Using Multiple
         Interfaces and Global Addresses",
         draft-ietf-monami6-multihoming-motivations-scenarios (work in
         progress), February 2006.



Soliman, et al.         Expires November 17, 2008              [Page 30]

Internet-Draft                Flow binding                      May 2008


Authors' Addresses

   Hesham Soliman
   Elevate Technologies


   Phone:
   Email: Hesham@elevatemobile.com
   URI:


   Nicolas Montavont
   IT / Telecom Bretagne
   2, rue de la chataigneraie
   Cesson Sevigne  35576
   France

   Phone: (+33) 2 99 12 70 23
   Email: nicolas.montavont@telecom-bretagne.eu
   URI:   http://www.rennes.telecom-bretagne.eu/~montavont/


   Nikolaus A. Fikouras
   University of Bremen
   ComNets-ikom,University of Bremen.
   Otto-Hahn-Allee NW 1
   Bremen, Bremen  28359
   Germany

   Phone: +49-421-218-8264
   Fax:   +49-421-218-3601
   Email: niko@comnets.uni-bremen.de
   URI:   http://www.comnets.uni-bremen.de


   Koojana Kuladinithi
   University of Bremen
   ComNets-ikom,University of Bremen.
   Otto-Hahn-Allee NW 1
   Bremen, Bremen  28359
   Germany

   Phone: +49-421-218-8251
   Fax:   +49-421-218-3601
   Email: koo@comnets.uni-bremen.de
   URI:   http://www.comnets.uni-bremen.de/~koo/





Soliman, et al.         Expires November 17, 2008              [Page 31]

Internet-Draft                Flow binding                      May 2008


Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   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.

   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, THE IETF TRUST 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.


Intellectual Property

   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.

   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.


Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).





Soliman, et al.         Expires November 17, 2008              [Page 32]


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/