IETF MEXT Working Group                                       H. Soliman, Ed. Soliman
Internet-Draft                                      Elevate Technologies
Intended status: Standards Track                            N. Montavont                             G. Tsirtsis
Expires: August 17, October 30, 2009                                      GET/ENST-B                                       Qualcomm
                                                            N. Fikouras Montavont
                                                                   IT/TB
                                                             G. Giaretta
                                                                Qualcomm
                                                          K. Kuladinithi
                                                    University of Bremen
                                                       February 13,
                                                          April 28, 2009

          Flow Bindings in Mobile IPv6 and Nemo Basic Support
                  draft-ietf-mext-flow-binding-01.txt
                  draft-ietf-mext-flow-binding-02.txt

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and 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 August 17, October 30, 2009.

Copyright Notice

   Copyright (c) 2009 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document. document (http://trustee.ietf.org/license-info).
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.

Abstract

   This document introduces extensions to Mobile IPv6 and Nemo Basic
   Support 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 instruct their
   interfaces. peers to direct downlink
   flows to specific addresses.

Table of Contents

   1.  Introduction  Requirements notation  . . . . . . . . . . . . . . . . . . . .  4
   2.  Introduction . . . . .  4
   2.  Terminology . . . . . . . . . . . . . . . . . . . .  5
   3.  Terminology  . . . . .  6
   3.  Mobile IPv6 Extensions . . . . . . . . . . . . . . . . . . . .  7
     3.1.  Flow Identification option
   4.  Mobile IPv6 Extensions . . . . . . . . . . . . . . . .  7
     3.2.  The Binding Reference Sub-option . . . .  8
     4.1.  Definition Update for Binding Identifier Mobility
           Option . . . . . . . . . 10
     3.3.  Binding Cache and Binding Update list extensions . . . . . 11
   4.  Protocol operations . . . . . . . . . . . .  8
     4.2.  Flow Identification Mobility Option  . . . . . . . . . 12
     4.1.  Interaction with the Multiple CoA bindings mechanism . .  8
       4.2.1.  Binding Reference Sub-option . 12
     4.2.  Flow binding storage . . . . . . . . . . . . 11
       4.2.2.  Flow Description Sub-option  . . . . . . . 13
     4.3.  Preferred Care-of address . . . . . . 12
     4.3.  Flow Identification Summary Mobility Option  . . . . . . . 13
     4.4.  Flow Bindings entries list and its relationship to
           Binding Cache  . . . 13
     4.4.  Adding flow bindings . . . . . . . . . . . . . . . . . . . 13
     4.5.  Modifying flow bindings 14
   5.  Protocol operations  . . . . . . . . . . . . . . . . . 14
     4.6.  Removing flow bindings . . . . 17
     5.1.  General  . . . . . . . . . . . . . . 15
     4.7.  Refreshing Flow Bindings . . . . . . . . . . . 17
       5.1.1.  Preferred Care-of address  . . . . . . 15
     4.8.  Acknowledging flow identification options . . . . . . . . 15
   5.  Usage scenario 17
     5.2.  Mobile Node Considerations . . . . . . . . . . . . . . . . 17
       5.2.1.  Sending BU with BID Options  . . . . . . . . 16
   6.  Mobile Node operations . . . . . 18
       5.2.2.  Sending BU with Flow Identification Options  . . . . . 18
       5.2.3.  Sending BU with a Flow Summary Option  . . . . . . . . 20
       5.2.4.  Removing flow bindings . . 18
     6.1.  Default Bindings . . . . . . . . . . . . . . 21
       5.2.5.  Receiving Binding Acknowledgements . . . . . . . 18
       6.1.1.  Managing Flow Bindings with the Home Agent and MAP . . 18
       6.1.2.  Managing Flow Bindings in Correspondent nodes . 21
       5.2.6.  Return Routability Procedure . . . 19
       6.1.3.  Using Alternate Care-Of Address . . . . . . . . . . 21
     5.3.  HA, MAP, and CN Considerations . 20
       6.1.4.  Receiving Binding Acknowledgements . . . . . . . . . . 20
     6.2.  Movement . . . 22
       5.3.1.  Receiving BU with BID Options  . . . . . . . . . . . . 22
       5.3.2.  Receiving BU with Flow Identification Options  . . . . 23
       5.3.3.  Receiving BU with Flow Summary Option  . . . . . . 20
     6.3.  Return Routability Procedure . . 25
       5.3.4.  Handling flow binding Removals . . . . . . . . . . . . 26
       5.3.5.  Sending Binding Acknowledgements . 20
     6.4.  Returning Home . . . . . . . . . . 26
       5.3.6.  Packet Processing  . . . . . . . . . . . . 21
   7.  Applicability to Route Optimization . . . . . . 27
   6.  Security considerations  . . . . . . . 22
     7.1.  Receiving Binding Udpate . . . . . . . . . . . . 28
   7.  IANA Considerations  . . . . . 22
   8.  Home Agent operations  . . . . . . . . . . . . . . . . . . . . 24
     8.1.  Receiving Binding Update with the Flow Identification
           option . . . . . . . . . . . . . . . . . . . . 29
   8.  Contributors . . . . . . 24
     8.2.  Sending Binding Ackowledgement . . . . . . . . . . . . . . 25
     8.3.  Deleting an entry in the binding cache . . . . . . . . . . 25
       8.3.1.  Removing Flow Bindings 30
   9.  Acknowledgements . . . . . . . . . . . . . . . . 26
   9.  Applicability to Hierarchical Mobile IPv6 . . . . . . . 31
   10. References . . . 27
   10. Security considerations . . . . . . . . . . . . . . . . . . . 28
   11. Acknowledgements . . . . 32
     10.1. Normative References . . . . . . . . . . . . . . . . . . . 29
   12. 32
     10.2. Informative References . . . . . . . . . . . . . . . . . . . . 30 32
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31 33

1.  Requirements notation

   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 [RFC2119].

2.  Introduction

   Mobile IPv6 (RFC3775) [RFC3775] [RFC3775], DSMIPv6 [I-D.ietf-mext-nemo-v4traversal] and
   Nemo Basic Support (RFC3963) [RFC3963] 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 binding update can
   also be sent to correspondent node or to a mobility anchor point (see RFC4140
   [RFC4140]).
   [RFC5380]).  The semantics of the binding update are limited to
   care-of address changes.  That is, RFC3775 [RFC3775] [RFC3775],
   [I-D.ietf-mext-nemo-v4traversal], and RFC3963 [RFC3963] 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 [I-D.ietf-monami6-multiplecoa] 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 further
   extends Mobile IPv6 IPv6, DSMIPv6, 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. IPv4 or IPv6 flow,
   which is viewed as a group of packets matching a flow descriptor.
   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. point.

   In this document, a flow is defined as one or more connections that
   are identified by a set of IP packets matching a
   flow identifier. descriptor.  A single connection is
   typically identified by flow descriptor can identify the source and
   destination IP addresses, transport protocol number and number, the source and
   destination port
   numbers.  Alternatively a flow can be identified numbers and other fields in a simpler manner
   using the IP and higher layer
   headers.  This specification, however, does not define flow label field in the IPv6 header [RFC2460] or the
   Security Parameter Index (SPI) when IPsec
   descriptors and it is used.

   Flow bindings assumed that one or more ways of defining flow
   descriptors are useful going to be defined in cases where other specifications.  This
   specification, however, does define the sub-option extension format
   to be used for any defined flows descriptors.

   Using the flow identifier option introduced in this specification a
   mobile node / mobile router has more than can bind one address, probably due to being multihomed,
   and wants to direct certain flows to certain addresses.  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 or more flows to a care-of
   address while maintaining the reception of other 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 home
   agent, correspondent node (in the case of Mobile IPv6), home agent or mobility
   anchor point (in the case of Hierarchical Mobile IPv6).

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

2.

3.  Terminology

   Terms used in this document are defined in [RFC3753] and
   [I-D.ietf-nemo-terminology]. [RFC4885].
   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 nodes and match a given flow description

      Flow Description: A set of instructions that describes a flow.

      Flow Identifier: Identifier of a flow binding.

      Flow binding: A mobility An entry in the list of flow binding extended associated with
      a flow identifier
      and flow description.

3. given mobile node.

4.  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.

4.1.  Definition Update for Binding Identifier Mobility Option

   This option contains information that
   allows specification updates the receiver definition 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 Binding Identifier
   Mobility option is
   called Flow Description defined in the remaining of this document.

       0 [I-D.ietf-monami6-multiplecoa], as
   follows:

                            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 = TBD  |  Option Len   |   PRI         |    FID     Length    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |        FID    |   Action       Binding ID (BID)        |     Status    |H|   BID-PRI   |  PRO  |  Res. |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Flow Description ...
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------------------------+
       +                                                               +
       :                 IPv4 or IPv6 care-of address (CoA)            :
       +                                                               +
       +---------------------------------------------------------------+

             Figure 1: The flow Binding Identifier Mobility option

      BID-PRI

         This is a 7-bit field placing each BID to a relative priority
         with other registered BIDs.  Value "0" is reserved for
         implementation of [I-D.ietf-monami6-multiplecoa] that do not
         support this specification.  A higher number in this field
         indicates lower priority, while BIDs with the same BID-PRI
         value have equal priority.

4.2.  Flow Identification Mobility Option

   The Flow identification mobility 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 care-of address.
   Multiple options may exist within the same binding update message.

       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   |              FID              |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   FID-PRI     |   Action      |  Rsvd |  PRO  |     Status    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

             Figure 2: The flow identification mobility option

      Option Type

         TBD

      Option Len

         Length of option option, including any sub-options, in 8-octet units

      PRI

      FID

         The Flow Identifier field is an 8-bit unsigned integer that
         includes the identifier for the flow binding.  This field is
         used to refer to an existing binding or to create a new
         binding.  The value of this field is set by the mobile node.

      FID-PRI

         This is an 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 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  The details of these requests are
         discussed below.

      Rsvd

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

      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.

      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 Modify 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 by indicated in the option. Binding Reference sub-option.  A
      single BID MUST be associated with this Action.

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

      2  No BIDs are associated with
      this Action.

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

   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 identification 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 FD-Type not supported.

      138 Discard function not supported.

      139 N-cast function not supported.

   It should be noted that per-packet load balancing has may have 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 [RFC2702].  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 currently supported in this extension.  However, the
   MN

   A number of sub-options can still request per-flow load balancing provided that the entire
   flow is moved to follow the new interface.

3.2.  The option defined in this
   section.  These are defined below.

4.2.1.  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 the MCoA document.
   [I-D.ietf-monami6-multiplecoa].  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 BIDs.

   The binding identifier option, defined in
   [I-D.ietf-monami6-multiplecoa], registering a given BID which is then
   indicated in the same BU, but Binding Reference sub-option, MUST be already known to either defined
   in the receiver of same or earlier BU from the one including the BU. binding
   reference sub-option.  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              |     ......
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |     BID  ........
       +-+-+-+-
       +-+-+-+-+-+-+-+-+-+-

                Figure 2: 3: 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 Sub-opt Type
         and
         length Sub-opt-Len 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  Since each BID is 2 byte long, the value
         of home agent,
   mobility anchor point and correspondent node, and in Binding Update
   List the Sub-opt Len field indicates the number of mobile node.  These logical structures need to be extended to BIDs present.
         Number of BIDs = (Sub-opt Len-2)/2.

4.2.2.  Flow Description Sub-option

   The Flow description sub-option(s) include the following parameters (in addition used to those described in
   RFC3775 [RFC3775]):

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

       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  |        Flow Description ...
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                 Figure 4: The Flow Description sub-option

      Sub-opt Type

         Indicates the same FID value.

      *  Each attribute that constitutes Sub-option type.  For the flow dsecription (and that
         are description sub-
         option, this field SHOULD be set to one of the FD types defined
         below.

      Sub-opt Len

         Indicates the sub-option length in a separate document).

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

4.  Protocol operations

   The flow identification option defines the controls on flow bindings.
   The fields entire length 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 sub-option including the results of such a petition. Sub-opt Type
         and Sub-opt-Len fields.

      Flow Description

         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 corresponding 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 type indicated by
   uniquely identifying a flow in the flow identification option.

   The remaining
         Sub-opt Type field.  Flow description is out 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 scope of bindings this
         document.

   The following values are all discussed
   below.

4.1.  Interaction with reserved for the Multiple CoA bindings mechanism sub-option Type values are
   defined for Flow binding presented in Description:

      17-32 reserved for Flow Description formats.

4.3.  Flow Identification Summary Mobility Option

   TBD

       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   |              FID              |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |     FID  ........
       +-+-+-+-+-+-+-+-+-+-

             Figure 5: The Flow Identification Summary Option

      Option Type

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

      Option Length

         Indicates the
   solution sub-option length in draft-ietf-monami6-multiplecoa.  The main reason why is
   to avoid octets.  This field includes
         the duplication entire length of the default binding to be used when none
   of sub-option including the Sub-opt Type
         and Sub-opt-Len fields.

      FID

         A registered rules FID.  One or more FID fields 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 be included in
         this specification with option.  Since each FID is 2 bytes long, the
   multiple CoA bindings allows for further aggregation value 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
         Option Len field indicates the two mechanisms allows for
   additional features (e.g., n-casting) to take place with minimal
   effort.  Hence, this specification makes use number of the BID option
   described in draft-ietf-monami6-multiplecoa.

4.2. FIDs present.  Number
         of FIDs = (Sub-opt Len-2)/2.

4.4.  Flow binding storage

   Home agent, correspondent node Bindings entries list and mobility anchor point maintain its relationship to Binding Cache in order to record associations between home addresses
   and care-of addresses of

   The conceptual mobile nodes that are away from the home
   link.  Mobile nodes maintain binding update list to record IPv6 binding
   between home address and care-of address.  RFC 3775 cache was defined in [RFC3775] allows
   mobile nodes to register only one care-of address per home address.
   Thus a binding cache entry is uniquely identified
   identify the mobile IP state maintained by the mobile node, home
   address.

   This specification extends the
   agent, and corresponding node.  The binding cache and includes, between
   others, the binding update
   list structures, and allows mobile node to (1) register multiple
   care-of addresses for a given node's home address and (2) associate flow
   binding policies with address, 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 lifetime of the flow identification option MUST
   maintain a default binding per home address.  A default binding.  The binding
   indicates an association between a home address and a Care-of
   address.  In addition cache was then
   extended by [I-D.ietf-monami6-multiplecoa] to include more than one
   care-of addresses and to the default binding, several bindings may
   co-exist within a binding cache for the same home address, associate each of them indicating different with a Binding
   Identifier (BID).

   This specification does not change modify the mobile IPv6 binding
   cache any further.

   Flow bindings between flows and Care-of
   addresses.  When can be thought of as a data flow conceptual list of entries that
   is intercepted by a home agent or
   initiated by a correspondent node, if separate from the said data binding cache.  The flow does not
   match bindings list contains
   an existing flow identification option, entry for each of the care-of address
   indicated registered flow binding.  Flow binding
   entries can point to an entry in the default binding is used as destination address for cache by means of the mobile node.  The default
   BID.  Each flow binding is indicated by entry include the Priority
   field in following parameters :

      *  FID (Flow Identifier): For a given mobile node, identified by
         its primary home address, the BID option described in draft-ietf-monami6-multiplecoa.
   A FID MUST uniquely identify an
         entry, i.e. a unique flow binding.  Each mobile node is responsible for having can only
         have a preferred care-of address
   with single entry identified by a given FID at any one time.
         Different mobile nodes can use the receiver same FID number space.

      *  A Flow Descriptor: Included in a Flow Description sub-option.

      *  BID(s): The list of BIDs associated with the flow identification option.

4.4.  Adding flow bindings

   When adding a new flow binding, a mobile node sends entry as defined
         by the flow
   identification option Binding Reference sub-option included in the binding update. FID option
         that created it.

      *  Action: The care-of address
   concerned action associated with this binding update must already be registered a given entry as defined by
         the
   receiver PRO field of the binding update (i.e., must already be FID option that created it

      *  Active/Inactive flag: This flag indicates whether the entry is
         active or inactive.

   The flow bindings list is associated with a BID), or a BID sub-option MUST be present in given mobile node, and
   the corresponding binding update (as
   defined cache.  An entry in draft-ietf-multiplecoa").  The the flow identification option
   MUST include a unique FID.  The bindings list,
   however, is identified by the FID needs only be unique for and the
   receiver of list is ordered according
   to the binding update, i.e. FID-PRI field as defined in the same FID can be used across
   different receivers of the binding update. option that created each
   entry.

   The PRO field MUST
   indicate an Add operation.  Adding the flow binding implies
   associating BIDs included in a flow with given entry point to a particular care-of address corresponding entry in
   the binding cache for the mobile
   node.  The purpose of identifying a care-of address concerned with address.

   Depending on the Action parameter in a given entry a valid BID is
   required to make the entry "active".  If all of the BIDs pointed to
   by a given entry are not valid BIDs in the binding cache, the flow
   binding is present entry becomes "inactive", in other words it does not affect
   data traffic.  Note that if the source address action parameter in an entry
   indicates "n-cast" then the entry becomes inactive only if none of
   the packet or BIDs is valid.  If only some of the alternate care-of address
   option.  Alternatively, BIDs are valid, the care-of address may be indicated by invalid
   BIDs are simply ignored.

   Also note that the
   BID (which state described in this section is pointing to an existing care-of address) when maintained by
   the
   Binding Reference sub-option mobile node as well as in mobility agents and corresponding
   nodes.  As such the mobile node is fully aware of which are the valid
   BIDs at any time and which flow binding entries are active/inactive.
   Section 5 defines how these flow binding entries are manipulated by
   the Flow Identification option is
   present.

   The mobile node may need to define in detail.

   As an example the following represents an ordered flow partially or entirely
   based on the source and destination addresses in packets.  For
   instance, bindings
   entries table for a mobile node may choose that has registered three care-of
   addresses and three flow bindings.

    FID-PRI     FID    Flow Description    BIDs    Action       A/I
    -------     ---    ----------------    ----    -------     ------
       10        4           TCP            2      Forward     Active
       20        3       srcAddr=IPx       N/A     Discard     Active
       30        2       srcAddr=IPy        4      Forward     Inactive
       40        5           UDP           1,3     N-Cast      Active

                       Ordered Flow Binding Entries

   According to forward the above list of flow binding entries, all flows from address
   A TCP traffic
   will match the first entry, and according to address B the Action indicated it
   will be forwarded to BID2, corresponding to a particular given care-of address.  Alternatively, more
   granularity can be added by including port numbers address
   (IP3), as shown below.  Any traffic that is not TCP, but has as
   source address IPx will match the second entry, and protocol.
   These descriptions according to the
   associated Action it will be given in another document.

   An Add operation implies discarded.  Note that any TCP traffic
   with source address IPx will match the FID is new first entry and thus it will
   be forwarded as per that entry.

   The third entry is marked as Inactive since the BID 4 does not already used
   by exist
   in the mobile node for ordered list of BID entries below.  Inactive entries do not
   affect traffic, i.e., packets are not matched against them.

   Any UDP traffic that does not match any other flow binding.  If of the Flow
   identification option is sent without any flow description earlier entries will
   match the third rule and with according to the PRO field indicating an Add operation, this MUST Action indicated it will be seen as a
   wild card request by
   replicated and forwarded to BIDs 1 and 3, corresponding to care-of
   addresses IP1 and IP2 shown below.

   Finally any remaining packets that do not match any of the sender.  A wild card request implies that
   all flows should entries
   above will be directed simply forwarded to the particular care-of address indicated by
   the highest order BID in the
   packet.

4.5.  Modifying flow bindings

   When modifying a flow binding (either table below.  In the example, such
   packets will be forwarded to BID 1, corresponding to care-of address or other
   attributes of the flow), the mobile node sends the binding update
   with
   IP1.

                       BID-PRI          BID        CoA
                      ---------         ---        ---
                          20             1         IP1
                          30             3         IP2
                          30             2         IP3

                            Ordered BID Entries

5.  Protocol operations

5.1.  General

   This specification introduces a flow identification option.  The option includes the FID for
   the bindings list of entries and an
   ordered list of binding being modified, as well as the PRO field set to 1,
   indicating a request identifiers, allowing mobile nodes to modify the binding.  A
   associate flow description
   option may come binding policies with the registered care-of
   addresses.

   The flow identification option and contain the
   new attributes needed to classify defines how the flow.  Hence, flow modification
   is essentially a process where an existing flow definition is removed
   and mobile node can
   control a new set of flow (included binding entries maintained 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 home agent,
   correspondent node, or mobility anchor points, on its behalf.  The
   fields of the IP point of attachment), flow identification option are necessary for ordering
   flow identification options, indicating the mobile node
   may just need sort of action that
   should be undertaken to register the new care-of address for the given BID.

4.6.  Removing flow bindings

   When removing a recipient's flow binding, the mobile node sends a binding update
   message with list of entries
   or for carrying the flow identification option.  The PRO field MUST be
   set results of such a petition.

   This specification allows mobile nodes to direct flows to a value
   particular care-of address.  The granularity of 15, which indicates a request for removing what constitutes a
   flow
   binding.  This will provide enough information for the receiver to
   locate depends on the flow binding using descriptor used.  As indicated earlier the FID and remove it.

4.7.  Refreshing Flow Bindings

   A
   flow binding description itself is refreshed by simply including defined in another document.

   The remaining of this section discusses how mobile nodes can use the Flow
   identification option
   options and sub-options defined in this document when sending binding
   updates to the BU message. correspondent node, home agent or mobility anchor
   point.  In addition, refresh, deletion, and modification of bindings
   are all discussed below.

5.1.1.  Preferred Care-of address

   Any node that supports this case specification MUST maintain an ordered
   list of care-of addresses for each mobile node it maintains a list of
   flow bindings for.  The ordered list of care-of addresses is built
   based on the PRO BID-PRI field of the Binding Identifier option (see
   Section 4.1).

   The ordered list of BIDs is set used to indicate determine how to forward a refresh operation.

   The refresh operation is included in this specification due packet
   to a given mobile node when the
   nature packet does not match any of the BU message.  The BU message updates existing bindings
   with new information.  Hence, all information previously sent flow
   binding entries defined in Section 4.4.  A packet that does not match
   any of 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 binding entries SHOULD be forwarded to ackowledge the reception of Binding Update by sending Binding Acknowledgment.  A
   correspondent node SHOULD also acknowledge Binding Update.  The
   Binding Acknowledgement is extended care-of
   address identified by this the BID with the highest priority i.e., lowest
   BID-PRI value.

5.2.  Mobile Node Considerations

   This specification allows the mobile node to indicate maintain several
   bindings in its home agent and to direct packets to different care-of
   addresses according to flow bindings.  This section details the
   mobile node the success operations necessary to implement this specification.

   The home agent list of flow bindings is manipulated by the mobile
   node, via flow binding.  If a Binding
   Acknowledgement needs to be sent identification and flow summary options included in response to a Binding Update that
   contained
   binding update messages.  Each flow identification option(s), binding update can add, modify,
   refresh, or delete a copy of each given binding.  More than one flow
   identification MUST be included.  Only the Status field needs to options MAY be
   changed to included in the appropriate value.  The absence same binding update but
   each of them MUST include a different FID.  In other words, two flow
   identification
   option options in Binding Acknwoledgement indicates that the sender does same message can not
   support be about the extension descibed in this document and therefore same
   flow binding.

   All flow binding state MUST be
   interpreted as a negative acknowledgement.

5.  Usage scenario

   In this section, we highlight a use case of refreshed in every binding update 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 sends.  Any previously registered flow binding that an existing IPsec
   security association is set up betweeen the mobile node and its home
   agent.  We assume
   not included in a given binding update will be deleted.  So, any flow
   bindings 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 are not added or modified by a different care-of address,
   depending on the type of the communication.  For example, port
   numbers 22 (ssh) flow identification
   option, but have previously registered and 443 (https) may be tunneled need to CoA1 while other
   communications may be tunneled to CoA2.  In order to set up these maintained MUST
   be included in a flow bindings, the following messages are exchanged:

      *  The mobile node sends summary option.  Only one flow summary option
   can be included in a Binding Update through If2, given binding update.

5.2.1.  Sending BU with the
         source address set to CoA2.  The Binding Update includes a BID
         sub-option as described in draft-ietf-monami6-multiplecoa. Options

   This sub-option intends to set the highest preference on the
         given Care-of address.

      *  When the home agent receives the Binding Update, it first
         validates specification (see Section 4.1) updates the Binding Update as recommanded in section 10.3 definition of
         [RFC3775].  If the
   Binding Update is accepted, the home agent
         processes Identifier option, originally defined in
   [I-D.ietf-monami6-multiplecoa].  According to this specification the
   BID sub-option option includes a BID-PRI field assigning each registered care-of
   address a priority, and thus placing them in an ordered list as also
   described in section 6.2 of
         draft-ietf-monami6-multiplecoa.  It then registers the source
         address of the Binding Update as Section 4.4.

   Mobile nodes supporting this specification MUST use the preferred BID option
   format defined in Section 4.1.  Mobiles nodes MUST also register all
   care-of address
         for addresses using the given home address and sends back a Binding
         Acknowledgement.

      *  Later, updated BID option format, either in the mobile node sends additional Binding Update
   same BU as any flow identification options using them, or in earlier
   BUs.

5.2.2.  Sending BU with
         both Flow Identification options and BID sub-option.  The BID
         sub-option is used to indicate the priority of the Options

5.2.2.1.  Adding flow bindings

   When adding a 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 binding, a mobile node sends 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 option in the
         Binding Update.  These binding update.  The care-of address
   concerned with each 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.

      *  When in the home agent receives binding update,
   must be logically registered by this second Binding Update, it
         first checks binding update, or must have
   already been registered by the validity receiver of the Binding Update binding update in an
   earlier binding update , as recommanded defined in section 10.3 of [RFC3775] and section 6.2 of
         draft-ietf-monami6-multiplecoa.  If the Binding Update is
         accepted, the Flow Identification options are treated.  If
         these options are accepted by the home agent, it will return Section 5.2.1.

   The flow identification option MUST include a
         Binding Acknowledgement with unique Flow Identification options, each
         of them having the same first 8 bytes, and Identifier
   in the Status field set
         to 0 (success).

         Thereafter, if a data flow is destinated to FID field.  The FID needs only be unique for the home address receiver 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 binding update and for the data flow to CoA1.  If not, same sender, i.e. the data flow will same FID can be
         forwarded to CoA2.

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). across different receivers of the binding update, for the same
   sender.

      The default entry indicates which care-of
   address FID-PRI field is set to use for a data flow that does not match any the desired priority of the FID,
      defining the order of the binding to be added in the list of flow
   bindings.
      binding entries as defined in Section 4.4.

      The preferred care-of address Action field is determined through set to one of the
   BID option.

6.1.1.  Managing defined action codes (see
      Section 4.2).

      The PRO field MUST indicate an Add operation.

      The Status filed is set to zero in all binding update messages.

   The mobile node MUST include exactly one Flow Bindings Description sub-option
   (see Section 4.2.2) describing the flow associated with the Home Agent and MAP

   A new
   binding.

   The mobile node may establish a Flow Binding by issuing a Binding
   Update containing a Flow Identifier (possibly associated MAY also include exactly one BID Reference sub-option
   (see Section 4.2.1) to associate the flow binding with a Flow
   Description) in its mobility options.  The Flow Identification option
   MUST indicate valid FID, PRO, PRI (rule priority) given set of
   BIDs and corresponding CoAs.  Depending on the Action fields.

   The PRO field of the
   Flow Identification option indicates the
   processing that Binding Identifier option, the targeted node has to perform following rules MUST be followed
   with respect to its Bindings
   Cache List.  A mobile node may request for any of the following
   requests:

      *  0: Add flow binding.  Create Binding Reference sub-option:

      - if the Action indicates 'Forward', a new Flow single Binding Reference
      sub-option with a single BID MUST be included.  This BID MUST be
      associated with a single care-of address.

      - if the
         indicated FID and include Action indicates 'Discard', the attached Flow.  A mobile node
         MUST Binding Reference sub-
      option SHOULD NOT issue be included.  If it is included it will be
      ignored by the receiver.

      - if the Action indicates 'n-cast', a single Binding Reference
      sub-option with one or more BIDs MUST be included.

5.2.2.2.  Modifying flow bindings

   Flow Identifier with the PRO field set to zero
         for binding modification is essentially a process where an existing FID.

      *  1: Replace a
   flow binding.  This request enables binding is removed from the mobile
         node to replace attributes list of the flow or binding entries and a
   new flow binding (included in the care-of address
         associated with option) is added, and given the FID.  A mobile node MUST NOT issue a Flow
         Identifier with
   same FID as the PRO field set to one for a non existent
         FID.

      *  2: Refresh a flow binding.  This request allows that was removed.  With this procedure the
   mobile node
         to inform can change the receiver of action, the BU message that priority, the flow binding
         is still valid.  This request does not modify BID, or the flow option.
         A flow identification option MUST NOT contain this value in the
         PRO field for a non-existent FID.

      *  15: Remove
   description associated with a flow binding.  This action enables a mobile node
         to remove the Flow Binding indicated by the FID on

   To modify an existing flow binding the targeted
         node.  A mobile node MUST not issue send a Flow Identifier
   binding update with a flow identification option, with the
         PRO FID field
   set to 15 for a non existent FID.

   When adding a flow binding on the home agent or MAP, one of the mobile node
   MUST ensure FID values already in the following:

      * list of flow binding
   entries.

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

      *  The FID field includes 1, indicating a value that does not already exist in request to modify the mobile node's binding update list.

      *
      binding.

      The PRI field is FID-PRI and Action fields MUST be 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.

      *  If the Action desired values to
      be implemented with this modification.

      The Status field is set to indicate N-cast, the Binding
         Reference zero since this option is in a binding
      update.

   The mobile node MAY include exactly one Flow Description sub-option must
   (see Section 4.2.2) describing the modified flow to be present and it must contain one or
         more BIDs.  If associated
   with the Binding Update sub-option includes only binding.

   The mobile node MAY also include exactly one
         BID, it must be pointing BID Reference sub-option
   (see Section 4.2.1) to associate the existing binding with a care-of address other than new set
   of CoAs.  The rules regarding the
         one included Binding Reference sub-option in the
   this case are identical to those described from flow binding update.

6.1.2.  Managing Flow Bindings addition
   in Correspondent nodes

   When route optimisation Section 5.2.2.1 .

   Note that it is used (see RFC3775 [RFC3775]), a also possible for the mobile node sends the BU message to effectively
   modify the correspondent node after the return
   routability test procedure.  When adding effect of a flow bindings in the BU sent
   to the correspondent node, binding entry without actually changing
   the mobile node MUST ensure entry itself.  This can be done by changing the following:

      *  The FID field includes CoA associated
   with a value that given BID, which is not already stored a process defined in
         the binding update list detail in
   [I-D.ietf-monami6-multiplecoa].

5.2.3.  Sending BU with a Flow Summary Option

   When the correspondent node's address.

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

   A mobile node can also modify or delete sends a binding update it MUST refresh all flow
   bindings in a similar
   manner it wants to that described earlier with the home agent and MAP.  When
   Modifying a maintain even if it does not want to change any
   of their parameters.

   To refresh an existing flow binding, binding the mobile node MUST ensure that send a
   binding update with a flow summary option.  The flow summary option
   MUST include one or more FID fields as indicated in Section 4.3.
   Each FID field included MUST be set to one of the FID
   used values already exists.  The rest of
   in the rules for modifying list of flow binding entries.

   Any flow bindings (active or inactive) that are the same as those listed above for adding not included in a
   binding update will be removed from the list of flow
   binding.

   Refreshing and deleting binding entries.

   Note that any inactive flow bindings, i.e., flow bindings without
   associated BIDs that are done marked as Inactive in the same manner as list of flow
   binding entries (see Section 4.4, MUST also be refreshed, or
   modified, to be maintained.  If they are not included in a BU they
   will be removed.

5.2.4.  Removing flow bindings

   Removal of flow binging entries is performed implicitly by omission
   of a given FID from a binding update.

   To remove a flow binding the MN simply sends a binding update that described
   includes flow identification and flow summary options for all the home agent
   FIDs that need to be refreshed, modified, or added, and MAP with one exception: the simply omits
   any FIDs that need to be removed.

   Note that a mobile node MUST NOT refresh or delete bindings can also remove the BIDs associated with any
   care-of address other than a
   given Flow Binding, without removing the one included flow binding itself.  The
   procedure for removing a BID is defined in detail in
   [I-D.ietf-monami6-multiplecoa].

   When all the BU message.

6.1.3.  Using Alternate Care-Of Address

   If BIDs associated with a flow binding are removed, the Alternate Care-of Address option is used
   flow binding MUST be marked as inactive in the Binding
   Update, it shall indicate list of flow binding
   entries as shown in Section 4.4.  In other words the care-of address to be state associated
   with the Flow Identification options.  The Flow Identification options
   shall contain the FID to flow binding MUST be allocated maintained but it does no longer affect
   the mobile node's traffic.  The MN can return an inactive flow
   binding to the Flow Binding.

6.1.4. active state by using the flow binding modification
   process described in Section 5.2.2.2, to associate it again with one
   or more valid BIDs.

5.2.5.  Receiving Binding Acknowledgements

   According to [RFC3775] all nodes are required to silently ignore
   mobility options not understood while processing Binding Updates. binding updates.  As
   such a mobile node receiving a Binding Acknowledgement in response to
   the transmission of a Binding Update binding update MUST determine if the Binding
   Acknowledgement contains a copy of the 8 bytes of every Flow
   Identification flow identification options
   included in the Binding Update. binding update.  A Binding Acknowledgement without Flow Identification option(s)
   flow identification option(s), in response to a Binding Update with
   flow identification option, would indicate
   inabillity inability (or
   unwillingness) 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, 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 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.

5.2.6.  Return Routability Procedure

   A mobile node may perform route optimization with correpondent nodes. correspondent nodes
   as defined in [RFC3775].  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 binding update message is secured with
   the key generated based on the home address and care-of address test,
   a mobile node MUST NOT bind a flow to a care-of address whose keygen
   token (see RFC3775 [RFC3775]) 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

5.3.  HA, MAP, and CN Considerations

   This specification allows the home
   network agents, mobility anchor points,
   and wishes corresponding nodes to abolish all Flow Bindings associated with the
   respective maintain several bindings for a given home address, it is required
   address and to act as described in
   Section 11.5.4 of RFC3775 [RFC3775]. direct packets to different care-of addresses
   according to flow bindings.  This will cause section details the home agent
   operations necessary to remove all bindings that implement this specification.  These
   operations are linked to the home address, including
   the flow bindings.

7.  Applicability to Route Optimization

   The identical for MAPs and CNs unless otherwise stated.

   Note that route optimization is only defined for mobile nodes (RFC3775 (MIPv6
   [RFC3775]), and not mobile router (RFC3963 routers (NEMOv6 [RFC3963]).  Thus, this
   section does not these
   sections only apply to mobile routers.  This section describes the
   correspondent node operations.

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

5.3.1.  Receiving BU with each correspondent node. BID Options

   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 (see Section 4.1) updates the Care-of
   address indicated by definition of the Flow Binding.

7.1.  Receiving Binding Udpate

   When a correspondant node receives a
   Binding Update, it first
   performs the same operation as Identifier option, originally defined in RFC3775 [RFC3775].  If the
   Binding Update is valid and contains a Flow identification option,
   the correspondent node needs
   [I-D.ietf-monami6-multiplecoa].  According to check the content of the PRO field.
   If this specification the PRO field contains a value indicating a request to add
   BID option includes a new
   flow binding, the following checks are done:

      *  The FID BID-PRI field includes assigning each registered care-of
   address a value that priority, and thus placing them in an ordered list (see
   Section 4.4).

   Home agents receiving BUs including BID options and flow
   identification options MUST logically process BID options first.
   This is not already stored because BID Reference sub-options included in the flow
   identification options might refer to BIDs defined in BID options
   included in the binding update list with the correspondent node's address.

      * same message.

   The PRO field BID option is set processed as defined in
   [I-D.ietf-monami6-multiplecoa] but then the BID to indicate care-of address
   mapping is placed in an Add operation.

         +  The FID field needs ordered list according to contain a value that does not already
            exist.  If the FID contains a value that already exists, the
            correspondent node MUST reject BID-PRI field
   of the option by sending that
            option back in its Binding Acknowledgement BID option.

5.3.2.  Receiving BU with a Status
            field that contains an error value.

         +  If Flow Identification Options

   When the Action field indicates home agent receives a request to n-cast binding update which includes at least
   one Flow Identification option, it first performs the flow, operation
   described in section 10.3.1 of RFC3775.

   Home agents that do not support this specification will ignore the correspondent node MUST reject
   flow identification options and all their suboption, having no effect
   on the option by sending operation of the
            option in its binding acknowledgement with an appropriate
            error code.

         + rest of the protocol.

   If both the FID binding update is accepted, and Action fields are valid, the
            correspondent node home agent is willing to
   support flow bindings for this MN, the home agent checks the flow description that must
            follow
   identification options.

   If more than one flow identification option in the same BU, has the
   same value in the FID field, all the flow identification option. options MUST
   be rejected.

   If all of FID fields have different values the checks
            above indicated a valid option, flow identification
   options can be processed further and in any order, as defined by the correspondent node
            should add
   following subsections.

5.3.2.1.  Handling Flow Binding Add Requests

   If the PRO field of the flow binding to its binding cache.

         +  The FID MUST include identification option is set to 'Add',
   it indicates a value that already exists. flow binding add request.

   If the FID cannot be found field of the flow identification option is already present
   in the correspondent node's list of flow binding
            cache, entries for this mobile node, the home
   agent MUST reject this flow binding add request by copying the flow
   identification option MUST be rejected with
            an appropriate error code.

         +  If in the Action BA, and setting the Status field indicates a request to n-cast 135
   (FID already in use).

   If the flow, flow identification option does not include a flow description
   sub-option, the correspondent node home agent MUST again reject the option this request by sending copying
   the flow identification option in its binding acknowledgement with an appropriate
            error code.

         +  If the Binding Reference sub-option is present, the
            correspondent node MUST ensure that the BID points to the
            care-of address in BA, and setting the packet, or Status
   field to an already authrozied
            care-of address.  Otherwise the 129 (Flow identification option MUST be rejected with
            an appropriate error code.

         + poorly formed).

   If all of the above checks returned flow identification option does include a valid result, flow description
   sub-option, but the
            correspondent node should modify flow description type is not supported, the binding as requested.

   If home
   agent MUST also reject this request by copying the PRO field flow
   identification option in the option indicates a request to modify BA, and setting the
   option, Status field to 137
   (FD-Type not supported).

   If the following checks must be done by FID value is new the correspondent node:

   If home agent MUST check the PRO Action field in
   combination with the option Binding Reference sub-option if present.

   - if the Action indicates 'Forward'
      If the Binding reference sub-option is not included or if it is
      included but it contains more than a request to refresh a
   binding, single BID, the correspondent node home agent
      MUST ensure that reject this flow binding add request by copying the flow
      identification option in the FID already
   exists. BA, and setting the Status field to
      129 (Flow identification option poorly formed).

      If the FID does Binding Reference sub-option is present and includes a
      single BID, but the BID is not exist, present in the correspondent binding cache of the
      mobile node the home agent MUST reject this flow binding add
      request by copying the flow identification option by sending it back in its binding acknowledgement
   with an appropriate error code in the status field.  Otherwise, if BA, and
      setting the FID exists, Status field to TBD (BID not known).

      If the correspondent node must keep it Binding Reference sub-option is present and includes a
      single BID, and the BID exists in its the mobile node's binding
   cache.  No further checks need to be done in cache,
      the option.

   The correspondent node should reply with home agent SHOULD add a new entry in the mobile node's list of
      flow binding entries, as defined below.

   - if the Action indicates 'Discard',

      Any Binding Acknowledgement
   message.  This Binding Acknowlegement message must contain Reference sub-options that might be present SHOULD be
      ignored.

      The home agent SHOULD add a copy of new entry in the 8 bytes mobile node's list of each
      flow binding entries, as defined below.

   - if the Action indicates 'n-cast',

      If the Binding reference sub-option is not included, the home
      agent MUST reject this flow binding add request by copying the
      flow identification option that was included in the Binding Udpate.  The BA, and setting the Status field of each Flow Identification
   option MUST be set
      to an appropriate value.

8.  Home Agent operations

   This specification allows 129 (Flow identification option poorly formed).

      If the home agent to maintain several bindings
   for a given home address Binding Reference sub-option is present and to direct packets to different care-of
   addresses according to flow bindings.  This section details includes BIDs
      that are not present in the binding cache of the mobile node the
      home agent operations necessary to implement MUST reject this specification.

8.1.  Receiving Binding Update with flow binding add request by copying
      the Flow Identification flow identification option

   When in the BA, and setting the Status
      field to TBD (BID not known).

      If the home agent receives a Binding Update which Reference sub-option is present and includes at least one Flow Identification option, it first performs or
      more BIDs, and the operation
   described BIDs exist in section 10.3.1 of RFC3775.  If the Binding Update is
   accepted, mobile node's binding cache,
      the home agent then checks SHOULD add a new entry in the mobile node's list of
      flow identification option.
   If binding entries, as defined below.

   When the PRO field home agent decides to add an entry in the option indicates an Add operation, mobile node's list
   of flow binding entries, as discussed above, it MUST do it according
   to the following checks must be done:

      * rules: The FID field needs entry MUST be placed according to contain a value that does not already
         exist.  If the
   order indicated by the FID-PRI field of the flow identification
   option and it MUST include:

      the FID contains as a value that already exists, key to the
         home agent entry

      The flow description included in the corresponding sub-option

      the action indicated in the Action field

      the BIDs indicated in the binding reference sub-option

      the entry MUST reject be marked as Active, as shown in Section 4.4

5.3.2.2.  Handling flow binding Modification Requests

   If the PRO field of the flow identification option by sending that option back
         in its Binding acknowledgement with is set to
   'Modify', it indicates a Status field flow binding modification request.

   Note that
         contains flow binding modification is essentially a process where an appropriate error value.

      *  If
   existing flow binding is removed from the list of flow binding
   entries and a new flow binding (included in the FID field option) is valid, added, and
   given the home agent then checks same FID as the
         Action field. flow that was removed.

   If the Action value of the FID field contains a request for
         n-cast and of the Binding Reference sub-option flow identification option is
   not included in
         the option, the flow binding MUST be rejected present in the binding
         acknowledgement containing an error code in the Status field.

      *  If both of the checks above indicate valid FID and Action
         fields, cache entries for this mobile node, the
   home agent checks the MUST reject this flow description following binding modify request by copying
   the flow identification option, option in the BA, and identifies setting the filter that
         needs Status
   field to be set up.

      * 135 (FID not found).

   If the flow option includes an action field that requests
         n-casting, value of the home agent MUST check for FID field is present in the presence mobile nodes list of
   flow binding entries, the
         BID sub-option(s).  If home agent SHOULD first remove the sub-options are not present, flow
   binding entry identified by the FID.  The home agent then SHOULD
   processes this flow identification option MUST be rejected as a poorly
         formatted option.  If one or more BIDs are present defined in the BID
         Reference sub-option,
   Section 5.3.2.1.

5.3.3.  Receiving BU with Flow Summary Option

   When the home agent needs to create multiple
         logical entries in its receives a binding cache.  All flows matching update which includes a Flow
   Summary option, it first performs the
         one operation described in the section
   10.3.1 of RFC3775.  Binding update messages including more than one
   flow summary option would MUST be n-cast to the care-of addresses
         pointed to by rejected.

   Home agents that do not support this specification will ignore the BIDs or
   flow summary option, having no effect on the set operation of the rest 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 protocol.

   If the one value of any of the FID fields included in the packet, then packets
         matching the flow would be bicast to those two addresses.

         However, if only one BID summary
   option is not 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
         rejected as a poorly formatted option.

      *  If all list of the checks above indicated a valid option, flow binding entries for this
   mobile node, the home agent should add the MUST reject this flow binding to its binding cache.

   If modify
   request by including a flow identification option in the PRO BA, and
   setting the FID field in the option contains a value indicating a request
   to modify an existing binding, of the following actions must be taken:

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

      * Status field to 135 (FID not found).

   If the value of the FID field is valid, present in the mobile nodes list of
   slow binding entries the, home agent MUST perform the same steps
         described above for the Add operation.

   If the PRO field indicates a SHOULD refresh operation, the home agent MUST
   ensure that binding entry
   identified by the FID in the option already exists.  If without changing any of the other parameters
   associated with it.

5.3.4.  Handling flow binding Removals

   Removal of flow bindings is performed implicitly by omission of a
   given FID field
   did from a binding update.

   When a valid binding update is received, any registered FIDs that are
   not exist, the explicitly referred to in a flow identification option MUST be rejected as or in a poorly formed option.
   If the FID existed, the home agent
   flow summary option, MUST keep be removed from the current list of flow binding
   in its binding cache.

8.2.
   entries for the mobile node.

5.3.5.  Sending Binding Ackowledgement Acknowledgements

   Upon the reception of a Binding Update, 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 [RFC3775] and is not
   modified by the extension defined recommended in this specification. [RFC3775].  This status
   code does not give information on the success or failure of the flow
   binding.
   bindings.

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

8.3.  Deleting  If an entry operation requested in a flow
   identification option by a mobile node is performed successfully by
   the binding cache

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

8.3.1.  Removing Flow Bindings

   If be set to 0 (Flow binding successful),
   otherwise it SHOULD be set to one of the home agent receives a valid Binding Update with rejection codes defined.
   Section 5.3.2 identifies a flow
   Identification option number of cases where specific error codes
   should be used.

   Home agents that support this specification MAY refuse to maintain
   flow bindings by setting the PRO status field is set of any flow identification
   options to 15 (Remove), the
   home agent MUST remove 130 (Administratively prohibited), or by just ignoring all
   the corresponding entry.  The home agent looks
   up flow binding options.

   Note that BID options and their Status field are handled as defined
   in [I-D.ietf-monami6-multiplecoa].

5.3.6.  Packet Processing

   This section defines packet processing rules according to this
   specification.  This specification does not change any of the entry corresponding packet
   interception rules defined in [RFC3775], and
   [I-D.ietf-mext-nemo-v4traversal].  These rules apply to HAs, MAPs,
   and CNs, as part of the FID routing process for any packet with
   destination address set to a valid home address of the Binding Update.  If mobile node.
   For nodes other than CNs this also applies to packets with
   destination address set to an
   entry is found, the entry is removed from address under any of the Binding cache and registered
   prefixes.  These rules apply equally to IPv6 packets as well as to
   IPv4 packets when [I-D.ietf-mext-nemo-v4traversal].

   Before a
   Binding Acknowledgement packet is sent back forwarded to the mobile node with a
   success value for it MUST be matched
   against the status ordered list 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 bindings stored in the list of flow
   binding cache entry entries for the corresponding home
   address, the home agent MUST send back to the this mobile node a Binding
   Acknowledgement (see Section 4.4).  A match is
   attempted with error code 137 (FID not found) in the flow
   identification option.

9.  Applicability to Hierarchical Mobile IPv6

   This section describes description included in the Mobility Anchor Point (MAP) operations.
   The MAP operation is first line
   (highest order) of the same as table.  If the home agent operation.  Flow
   bindings sent to packet matches the MAP are associated with flow
   description, the regional care-of
   address.

   When a MAP receives a Binding Update that includes action defined by the flow
   Identification option, it checks action parameter of the table
   SHOULD be performed.

      - if such option the Action indicates 'Forward' the packet is valid according forwarded to the requirements
      care-of address indicated by the BID parameter in Section 8.1.  If the option same line of
      the table.

      - if the Action indicates 'Discard', the packet is valid, silently
      discarded

      - if the MAP
   installs Action indicates 'n-cast', a copy of the flow binding packet is
      forwarded to each of the care-of addresses associated with the flow identified by
      BIDs indicated in the
   flow description.  The lifetime same line of the binding is table.

   If the lifetime action indicated in one of the
   Binding Update.  Once entries in the binding list of flow
   bindings is successfully installed, "Discard" then, no BIDs needs to be indicated in the MAP
   sends same
   entry since the binding acknowledgement and includes packet is not forwarded.  If, however, the action
   indicated in an entry of the list of flow
   Identification option.  The MAP sets bindings is "forward" or
   "n-cast", the status field entry must indicated a BID.  For "n-cast" if any of the
   BIDs indicated does not correspond to a value
   indicating success. valid care-of address, e.g.,
   the BID was deregistered then that BID has no effect on the traffic.
   In all cases, a other words, packets matching the flow identification option SHOULD be included in binding are n-casted to the
   Binding Acknowledgement
   other BIDs, pointing to indicate success or failure registered care-of addresses.  If none of the
   BIDs pointed to in a flow binding installation.

10. entry is valid then the entry is
   considered to be inactive (as defined in Section 4.4) and is skipped.
   In other words packets should not be matched against that entry.

6.  Security considerations

   This draft introduces a new option that adds more granularity to the
   Binding Update
   binding update message.  The new option allows the mobile node to
   associate some flows to an one interface and other flows to another
   interface.  Since the flow 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.

7.  IANA Considerations

   A Type number (TBD) for Flow Identification Mobility Option and
   another Type number (TBD) for Flow Summary Mobility Option has been
   registered from the space of numbers for mobility options, defined
   for Mobile IPv6 [RFC3775].  This registry is available from
   http://www.iana.org under "Mobile IPv6 parameters".

   A new sub-type space for the type number of the Flow Identification
   Mobility Option has been created: "Flow Identification Mobility
   Option Sub-Options".  The suboption values 1, and 2, are defined in
   this specification, and the values 16-32 are reserved for flow
   description sub-options to defined in separate documents.  The rest
   of the sub-options are reserved and available for allocation based on
   Expert Review.

   Finally, a new space for the status field of the Flow Identification option is part
   Mobility Option has been created: "Flow Identification Mobility
   Option Status codes".  Values 0, 128-130 and 135-139 are defined in
   this specification.  The rest of the
   mobility header, it uses values below 128 are reserved
   for accept codes, and values from 128 and above are reserved for
   reject codes.

   Similar to the same security as procedures specified for Mobile IPv6 [RFC3775] number
   spaces, future allocations from the Binding Update,
   whether it is sent two number spaces require Expert
   Review [RFC5226].

8.  Contributors

   We would like to explicitly acknowledge the home agent, correspondent node, or MAP.

11. following person who co-
   authored one of the documents used as source material for this
   document.

      Nikolaus A. Fikouras, niko@comnets.uni-bremen.de

9.  Acknowledgements

   We would also like to thank all authors of initial I-Ds that were merged
   together to create this document; acknowledge the following people 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.  Pavlidou, V. Park.  Gabor Fekete for the
   analysis that led to the inclusion of the BID support. BIDRef sub-option.  Henrik
   Levkowetz for suggesting the equivalent of the CLS field to allow support for other ways of describing flows.

12.  Informative

10.  References

   [I-D.ietf-nemo-terminology]
              Ernst, T. and H. Lach, "Network Mobility

10.1.  Normative References

   [I-D.ietf-mext-nemo-v4traversal]
              Soliman, H., "Mobile IPv6 Support
              Terminology", draft-ietf-nemo-terminology-06 for Dual Stack Hosts and
              Routers", draft-ietf-mext-nemo-v4traversal-10 (work in
              progress), November 2006.

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

   [RFC2702]  "", 2005.

   [RFC3753]  Manner, J. April 2009.

   [I-D.ietf-monami6-multiplecoa]
              Wakikawa, R., Devarapalli, V., Tsirtsis, G., Ernst, T.,
              and M. Kojo, "Mobility Related Terminology", K. Nagami, "Multiple Care-of Addresses Registration",
              draft-ietf-monami6-multiplecoa-13 (work in progress),
              April 2009.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 3753, June 2004. 2119, March 1997.

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

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

   [RFC4140]  "RF", 2005.

   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
              May 2008.

   [RFC5380]  Soliman, H., Castelluccia, C., ElMalki, K., and L.
              Bellier, "Hierarchical Mobile IPv6 (HMIPv6) Mobility
              Management", RFC 5380, October 2008.

10.2.  Informative References

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

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

   [RFC4885]  Ernst, T. and H-Y. Lach, "Network Mobility Support
              Terminology", RFC 4885, July 2007.

Authors' Addresses

   Hesham Soliman (editor)
   Elevate Technologies

   Email: hesham@elevatemobile.com

   George
   Qualcomm

   Email: tsirtsis@gmail.com

   Nicolas Montavont
   Ecole Nationale Superieure des telecommunications de
   Institut Telecom / Telecom Bretagne
   2, rue de la chataigneraie
   Cesson Sevigne  35576
   France

   Phone: (+33) 2 99 12 70 23
   Email: nicolas.montavont@enst-bretagne.fr nicolas.montavont@telecom-bretagne.eu
   URI:   http://www-r2.u-strasbg.fr/~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   http://www.rennes.enst-bretagne.fr/~nmontavo//

   Gerardo
   Qualcomm

   Email: niko@comnets.uni-bremen.de
   URI:   http://www.comnets.uni-bremen.de gerardog@qualcomm.com

   Koojana Kuladinithi
   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: koo@comnets.uni-bremen.de
   URI:   http://www.comnets.uni-bremen.de/~koo/