[Docs] [txt|pdf|xml|html] [Tracker] [WG] [Email] [Diff1] [Diff2] [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
Intended status: Standards Track                             G. Tsirtsis
Expires: September 2, 2010                                      Qualcomm
                                                            N. Montavont
                                                                   IT/TB
                                                             G. Giaretta
                                                                Qualcomm
                                                          K. Kuladinithi
                                                    University of Bremen
                                                           March 1, 2010


          Flow Bindings in Mobile IPv6 and NEMO Basic Support
                  draft-ietf-mext-flow-binding-06.txt

Abstract

   This document introduces extensions to Mobile IPv6 that allow nodes
   to bind one or more flows to a care-of address.  These extensions
   allow multihomed nodes to instruct home agents and other Mobile IPv6
   entities to direct inbound flows to specific addresses.

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 September 2, 2010.

Copyright Notice




Soliman, et al.         Expires September 2, 2010               [Page 1]

Internet-Draft                Flow binding                    March 2010


   Copyright (c) 2010 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.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the BSD License.







































Soliman, et al.         Expires September 2, 2010               [Page 2]

Internet-Draft                Flow binding                    March 2010


Table of Contents

   1.  Requirements notation  . . . . . . . . . . . . . . . . . . . .  4
   2.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  5
   3.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  7
   4.  Mobile IPv6 Extensions . . . . . . . . . . . . . . . . . . . .  8
     4.1.  Definition Update for Binding Identifier Mobility
           Option . . . . . . . . . . . . . . . . . . . . . . . . . .  8
     4.2.  Flow Identification Mobility Option  . . . . . . . . . . .  8
       4.2.1.  Flow Identification Sub-Options definition . . . . . . 11
       4.2.2.  Flow Summary Mobility Option . . . . . . . . . . . . . 15
     4.3.  Flow Bindings entries list and its relationship to
           Binding Cache  . . . . . . . . . . . . . . . . . . . . . . 16
   5.  Protocol operations  . . . . . . . . . . . . . . . . . . . . . 19
     5.1.  General  . . . . . . . . . . . . . . . . . . . . . . . . . 19
       5.1.1.  Preferred Care-of address  . . . . . . . . . . . . . . 19
     5.2.  Mobile Node Considerations . . . . . . . . . . . . . . . . 19
       5.2.1.  Sending BU with BID Options  . . . . . . . . . . . . . 20
       5.2.2.  Sending BU with Flow Identification Mobility
               Options  . . . . . . . . . . . . . . . . . . . . . . . 20
       5.2.3.  Sending BU with a Flow Summary Option  . . . . . . . . 22
       5.2.4.  Removing flow bindings . . . . . . . . . . . . . . . . 23
       5.2.5.  Returning Home . . . . . . . . . . . . . . . . . . . . 23
       5.2.6.  Receiving Binding Acknowledgements . . . . . . . . . . 23
       5.2.7.  Return Routability Procedure . . . . . . . . . . . . . 24
     5.3.  HA, MAP, and CN Considerations . . . . . . . . . . . . . . 24
       5.3.1.  Handling Binding Identifier Mobility Options . . . . . 24
       5.3.2.  Handling Flow Identification Mobility Options  . . . . 25
       5.3.3.  Handling Flow Summary Mobility Option  . . . . . . . . 28
       5.3.4.  Flow Binding Removals  . . . . . . . . . . . . . . . . 28
       5.3.5.  Sending Binding Acknowledgements . . . . . . . . . . . 28
       5.3.6.  Packet Processing  . . . . . . . . . . . . . . . . . . 29
   6.  MTU Considerations . . . . . . . . . . . . . . . . . . . . . . 31
   7.  Security considerations  . . . . . . . . . . . . . . . . . . . 32
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 33
   9.  Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 36
   10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 37
   11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 38
     11.1. Normative References . . . . . . . . . . . . . . . . . . . 38
     11.2. Informative References . . . . . . . . . . . . . . . . . . 38
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 39










Soliman, et al.         Expires September 2, 2010               [Page 3]

Internet-Draft                Flow binding                    March 2010


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














































Soliman, et al.         Expires September 2, 2010               [Page 4]

Internet-Draft                Flow binding                    March 2010


2.  Introduction

   Mobile IPv6 [RFC3775], DSMIPv6 [RFC5555] and NEMO Basic Support
   [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 and associated mobile networks.  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 [RFC5380]).  The semantics of the binding update are
   limited to care-of address changes.  That is, [RFC3775], [RFC5555],
   and [RFC3963] do not allow a mobile node / mobile router to bind more
   than one address to the home address.  In [RFC5648] 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, DSMIPv6, and NEMO Basic Support to allow it to
   specify policies associated with each binding.  A policy can contain
   a request for special treatment of a particular IPv4 or IPv6 flow,
   which is viewed as a group of packets matching a traffic selector.
   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, this specification
   allows to bind a particular flow to a particular care-of address
   directly with correspondent node and mobility agents (i.e., home
   agents [RFC3775] and mobility anchor points [RFC5380]).

   In this document, a flow is defined as a set of IP packets matching a
   traffic selector.  A traffic selector can identify the source and
   destination IP addresses, transport protocol number, the source and
   destination port numbers and other fields in IP and higher layer
   headers.  This specification, however, does not define traffic
   selectors and it is assumed that one or more ways of defining traffic
   selectors are going to be defined in other specifications.  This
   specification, however, does define the traffic selector sub-option
   format to be used for any defined traffic selectors.

   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 flows on another
   care-of address.  The mobile node / mobile router assembles the flow
   binding request based local policies, 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 mobility option can
   be associated with any binding update, whether it is sent to a
   mobility agent or a correspondent node.

   Note that per-packet load balancing may have negative impacts on TCP



Soliman, et al.         Expires September 2, 2010               [Page 5]

Internet-Draft                Flow binding                    March 2010


   congestion avoidance mechanisms as it is desirable to maintain order
   between packets belonging to the same TCP connection.  This behaviour
   is specified in [RFC2702].  Other negative impacts are also foreseen
   for other types of real time connections due to the potential
   variations in round trip time between packets.  Moreover, per-packet
   load-balancing will negatively affect traffic with anti-reply
   protection mechanisms.  Hence, per-packet load balancing is not
   envisioned in this specification.

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







































Soliman, et al.         Expires September 2, 2010               [Page 6]

Internet-Draft                Flow binding                    March 2010


3.  Terminology

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

      Flow: A flow is a sequence of packets for which the MN desires
      special handling either by the HA, the CN or the MAP.

      Traffic Selector: One or more parameters that can be matched
      against fields in the packet's headers for the purpose of
      classifying a packet.  Examples of such parameters include the
      source and destination IP addresses, transport protocol number,
      the source and destination port numbers and other fields in IP and
      higher layer headers.

      Flow binding: It consists of a traffic selector, and an action.
      IP packets from one or more flows that match the traffic selector
      associated with the flow binding, are processed according to the
      action associated with the same flow binding.

      Flow Identifier: A flow identifier uniquely identifies a flow
      binding associated with a mobile node.  It is generated by a
      mobile node and is cached in the table of flow binding entries
      maintained by the MN, HA, CN or MAP.



























Soliman, et al.         Expires September 2, 2010               [Page 7]

Internet-Draft                Flow binding                    March 2010


4.  Mobile IPv6 Extensions

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

4.1.  Definition Update for Binding Identifier Mobility Option

   This specification updates the definition of the Binding Identifier
   Mobility option defined in [RFC5648], 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
                                       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                       |   Type = 35   |     Length    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |       Binding ID (BID)        |     Status    |H|   BID-PRI   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------------------------+
       +                                                               +
       :                 IPv4 or IPv6 care-of address (CoA)            :
       +                                                               +
       +---------------------------------------------------------------+



             Figure 1: The Binding Identifier Mobility option



      BID-PRI

         This is a 7-bit unsigned integer placing each BID to a relative
         priority with other registered BIDs.  Value '0' is reserved and
         SHOULD NOT be used.  A lower number in this field indicates a
         higher priority, while BIDs with the same BID-PRI value have
         equal priority meaning that, the BID used is an implementation
         issue.  This is consistent with current practice in packet
         classifiers.

4.2.  Flow Identification Mobility Option

   The flow identification mobility option is a new mobility option
   [RFC3775] and it 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.  The
   alignment requirement for this option is 2n.




Soliman, et al.         Expires September 2, 2010               [Page 8]

Internet-Draft                Flow binding                    March 2010


        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         |     Status    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   Sub-options (optional) ...
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

             Figure 2: The Flow Identification Mobility Option



      Option Type

         To be assigned by IANA

      Option Len

         Length of the option in octets as per [RFC3775].

      FID

         The Flow Identifier field is a 16-bit unsigned integer that
         includes the unique identifier for the flow binding.  This
         field is used to refer to an existing flow binding or to create
         a new flow binding.  The value of this field is set by the
         mobile node.  FID = 0 is reserved and SHOULD NOT be used.

      FID-PRI

         This is an 8-bit unsigned 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.  Value '0' is reserved and SHOULD NOT be used.  FID-
         PRI MUST be unique to each of the flows pertaining to a given
         MN.

      Action

         This 8-bit unsigned integer field specifies the action that
         needs to be taken by the receiver of the binding update
         containing the flow identification option.  The details of
         these requests are discussed below.  The following values are
         reserved for the Action field in this option:



Soliman, et al.         Expires September 2, 2010               [Page 9]

Internet-Draft                Flow binding                    March 2010


            0 Reserved and SHOULD NOT be used

            1 'Discard'.  This value indicates a request to discard all
            packets in the flow described by the option.  No BIDs are
            associated with this Action.  Care should be taken when
            using this Action as it will lead to disrupting applications
            communication.  Implementations may consider notifying
            impacted applications in mobile nodes.

            2 'Forward'.  This value indicates a request to send the
            flow to one or more addresses indicated in the binding
            reference sub-option (see Section 4.2.1.3).  One or more
            BIDs MUST be associated with this Action.  If only one BID
            is associated with this action then it is essentially a
            request to forward packets to that CoA, otherwise matching
            packets are replicated and forwarded to all of the indicated
            CoAs.  Care should be taken when multiple BIDs are used in
            combination with the 'Forward' action as some transport
            layers may not be able to handle packet duplication and this
            can affect their performance.

            3-255 Reserved for future use

      Rsvd

         This field is unused.  It SHOULD be set to zero by the sender
         and ignored by the receiver.

      Status

         This 8-bit unsigned integer 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.  This field is only relevant when included in the
         Binding Acknowledgement message and must be ignored in the
         binding update message.  The following values are reserved for
         the status field within the flow identification mobility
         option:

            0 Flow binding successful

            128 Administratively prohibited

            129 Flow binding rejected, reason unspecified






Soliman, et al.         Expires September 2, 2010              [Page 10]

Internet-Draft                Flow binding                    March 2010


            130 Flow identification mobility option malformed

            131 BID not found

            132 FID not found

            133 Traffic selector format not supported

            134 Discard function not supported

            135 Forward function not supported

      Sub-options (optional)

         zero or more sub-options, defined in Section 4.2.1

4.2.1.  Flow Identification Sub-Options definition

   Flow identification sub-options are encoded within the remaining
   space of the flow identification mobility option, using a sub-option
   type-length-value (TLV) format as follows:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Sub-Opt Type  |Sub-Opt Length |   Sub-Option Data...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

              Figure 3: Flow Identification Sub-Option format



      Sub-opt Type

         8-bit unsigned integer indicating the sub-option Type.  When
         processing a flow identification mobility option containing an
         option for which the sub-option Type value is not recognized by
         the receiver, the receiver MUST quietly ignore and skip over
         the option, correctly handling any remaining sub-options in the
         same option.

      Sub-opt Len

         8-bit unsigned integer, representing the length in octets of
         the flow identification sub-option.  This field indicates the
         length of the sub-option not including the Sub-opt Type and
         Sub-opt Length fields.  Note that Sub-opt Type '0'
         (Section 4.2.1.1) is a special case that does not take a Sub-



Soliman, et al.         Expires September 2, 2010              [Page 11]

Internet-Draft                Flow binding                    March 2010


         opt Length field.

      Sub-Option Data

         A variable length field that contains data specific to the sub-
         option

   The following subsections specify the sub-option types which are
   currently defined for use in the flow identification option.
   Implementations MUST silently ignore any sub-options that they do not
   understand.

   These sub-options may have alignment requirements.  Following the
   convention in [RFC3775], regarding mobility options, these sub-
   options are aligned in a packet so that multi-octet values within the
   sub-option Data field of each sub-option fall on natural boundaries
   (i.e., fields of width n octets are placed at an integer multiple of
   n octets from the start of the header, for n = 1, 2, 4, or 8) .

4.2.1.1.  Pad1

   The Pad1 sub-option does not have any alignment requirements.  Its
   format is as follows:

          0
          0 1 2 3 4 5 6 7
         +-+-+-+-+-+-+-+-+
         | Sub-Opt Type  |
         +-+-+-+-+-+-+-+-+

   Sub-opt Type

      0

   NOTE! the format of the Pad1 sub-option is a special case - it has
   neither sub-option Length nor sub-option Data fields.

   The Pad1 sub-option is used to insert one octet of padding in the
   flow identification option.  If more than one octet of padding is
   required, the PadN sub-option, described next, should be used rather
   than multiple Pad1 sub-options.

4.2.1.2.  PadN

   The PadN sub-option does not have any alignment requirements.  Its
   format is as follows:





Soliman, et al.         Expires September 2, 2010              [Page 12]

Internet-Draft                Flow binding                    March 2010


          0                   1
          0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -
         | Sub-Opt Type  | Sub-Opt Len   | Option Data
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -

   Sub-opt Type

      1

   Sub-opt Len

      set to the length of the sub-option

   Sub-opt Data

      0 or more bytes set to 0 by the sender and ignored by the
      receiver.

   The PadN sub-option is used to insert two or more octets of padding
   in the flow identification mobility option.  For N octets of padding,
   the sub-option Length field contains the value N, and the sub-option
   data consists of N-2 zero-valued octets.  PadN sub-option data MUST
   be ignored by the receiver.

4.2.1.3.  Binding Reference Sub-option

   This section introduces the binding reference sub-option, which may
   be included in the flow identification mobility option.  A node MUST
   NOT include more than one binding reference sub-options in a given
   flow binding identification option.  The binding reference sub-option
   includes one or more BIDs defined in MCoA [RFC5648].  When this sub-
   option is included in the flow identification mobility option it
   associates the flow described with one or more registered BIDs.

   When binding a flow using this sub-option, the binding identifier
   mobility option, defined in [RFC5648], MUST be included in either the
   same or an earlier BU.  The binding reference sub-option is shown
   below.  The alignment requirement for this sub-option is 2n.

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




Soliman, et al.         Expires September 2, 2010              [Page 13]

Internet-Draft                Flow binding                    March 2010


                Figure 4: The Binding Reference sub-option



      Sub-opt Type

         2

      Sub-opt Len

         Variable

      BID

         A 16-bit unsigned integer indicating 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.
         Since each BID is 2 bytes long, the value of the Sub-opt Len
         field indicates the number of BIDs present.  Number of BIDs =
         Sub-opt Len/2.

4.2.1.4.  Traffic Selector sub-option

   The traffic selector sub-option includes the parameters used to match
   packets for a specific flow binding.  A node MUST NOT include more
   than one traffic selector sub-option in a given flow binding
   identification option.

        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  |   TS Format   |   Reserved    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |  Traffic Selector ...
       +-+-+-+-+-+-+-+-+-+-+-+


                 Figure 5: The Traffic Selector sub-option

   Sub-opt Type

      3

   Sub-opt Len

      variable





Soliman, et al.         Expires September 2, 2010              [Page 14]

Internet-Draft                Flow binding                    March 2010


   TS Format

      An 8-bit unsigned integer indicating the Traffic Selector Format.
      Value "0" is reserved and SHOULD NOT be used.

   Reserved

      An 8-bit reserved field.  It SHOULD be set to zero by the sender
      and ignored by the receiver.

   Traffic Selector

      A variable length field, the format and content of which is out of
      scope for this specification.

4.2.2.  Flow Summary Mobility Option

   The flow summary mobility option is a new mobility option [RFC3775],
   which includes one or more flow identifiers (FIDs) for the purpose of
   refreshing their state.  A node MUST NOT include more than one flow
   summary mobility option in a given binding update message.  The
   alignment requirement for this option is 2n.

        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 6: The Flow Summary Mobility Option



      Option Type

         To be assigned by IANA

      Option Length

         Length of the option in octets as per [RFC3775]

      FID

         A 16-bit unsigned integer indicating a registered FID.  One or
         more FID fields can be included in this option.  Number of FIDs
         = Option Len/2



Soliman, et al.         Expires September 2, 2010              [Page 15]

Internet-Draft                Flow binding                    March 2010


4.3.  Flow Bindings entries list and its relationship to Binding Cache

   The conceptual mobile IPv6 binding cache was defined in [RFC3775] to
   identify the mobile IP state maintained by the mobile node, mobility
   agent, and correspondent node.  The binding cache includes, between
   others, the mobile node's home address, the registered care-of
   address, and the lifetime of the binding.  The binding cache has been
   extended by [RFC5648] to include more than one care-of addresses and
   to associate each of them with a Binding Identifier (BID).

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

   Flow bindings can be thought of as a conceptual list of entries that
   is separate from the binding cache.  The flow bindings list contains
   an entry for each of the registered flow bindings.  Flow binding
   entries can point to an entry in the binding cache by means of the
   BID.  Each flow binding entry includes the following parameters :

   o  FID (Flow Identifier): For a given mobile node, identified by its
      primary home address, the FID MUST uniquely identify an entry,
      i.e. a unique flow binding.  Each mobile node can only have a
      single entry identified by a given FID at any one time.  A given
      FID number space is used for all the addresses associated to a
      given MN by the HA (e.g., via [RFC3963]).  Different mobile nodes
      use the same FID number space.

   o  A Traffic Selector: Included in a traffic selector sub-option.

   o  BID(s): The list of BIDs associated with the entry as defined by
      the binding reference sub-option included in the FID option that
      created it.

   o  Action: The action associated with a given entry as defined by the
      Action field of the FID option that created it

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

   o  FID-PRI: This field indicates the priority of the flow and is used
      to break the tie between overlapping flows.

   The flow bindings list is associated with a given mobile node, and
   the correspondent binding cache.  An entry in the flow bindings list,
   however, is identified by the FID and the list is ordered according
   to the FID-PRI field as defined in the FID option that created each
   entry.




Soliman, et al.         Expires September 2, 2010              [Page 16]

Internet-Draft                Flow binding                    March 2010


   For entries that take BIDs (i.e., entries that do not indicate a
   'Discard' action), a valid BID is required to make the entry
   'Active'.  If all of the BIDs pointed to by a given entry are
   deregistered [RFC5648], the flow binding entry becomes 'Inactive', in
   other words it does not affect data traffic.  Note that if the action
   parameter in an entry indicates 'Forward' then the entry becomes
   'Inactive' only if all of the BIDs are deregistered.  If only some of
   the BIDs are still valid, the invalid BIDs are simply ignored.

   Also note that the state described in this section is maintained by
   the mobile node as well as in mobility agents and correspondent
   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 mobile node in detail.

   As an example the following represents an ordered flow binding entry
   table for a mobile node that has registered multiple care-of
   addresses and flow bindings.

    FID-PRI     FID    Traffic Selector    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     Forward      Active


                       Ordered Flow Binding Entries

   According to the above list of flow binding entries, all TCP traffic
   will match the first entry, and according to the Action indicated it
   will be forwarded to BID2, corresponding to a given care-of address
   (IP3), as shown below.  Any traffic that is not TCP, but has as
   source address IPx will match the second entry, and according to the
   associated Action it will be discarded.  Note that any TCP traffic
   with source address IPx will match the 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 exist
   in the 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 of the earlier entries will
   match the forth rule and according to the Action indicated, it will
   be replicated and forwarded to BIDs 1 and 3, corresponding to care-of
   addresses IP1 and IP2 shown below.




Soliman, et al.         Expires September 2, 2010              [Page 17]

Internet-Draft                Flow binding                    March 2010


   Finally any remaining packets that do not match any of the entries
   above will be simply forwarded to the care-of address indicated by
   the highest order BID in the table below.  In the example, such
   packets will be forwarded to BID1 corresponding to care-of address
   IP1.

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

                            Ordered BID Entries

   Mobility agent and corresponding node implementations should take
   care to avoid flow binding rules affecting the fundamental operation
   of Mobile IPv6 and its extensions.  In particular, flow binding rules
   MUST NOT apply to Mobile IPv6 signaling generated by mobility agents
   and corresponding nodes communicating with a given mobile node, since
   that could adversely affect the operation of the protocol.  Other,
   non Mobile IPv6 traffic generated by these entities SHOULD be matched
   against the mobile node's flow binding rules as normal.





























Soliman, et al.         Expires September 2, 2010              [Page 18]

Internet-Draft                Flow binding                    March 2010


5.  Protocol operations

5.1.  General

   This specification introduces a flow bindings list of entries and an
   ordered list of flow binding identifiers, allowing mobile nodes to
   associate flow binding policies with the registered care-of
   addresses.

   The flow identification mobility option defines how the mobile node
   can control a set of flow binding entries maintained in a mobility
   agent, or correspondent node.  The fields of the flow identification
   mobility option are necessary for ordering flow identification
   mobility options, indicating the sort of action that should be
   undertaken to the recipient's flow binding list of entries or for
   carrying the results of such a petition.

   This specification allows mobile nodes to direct flows to a
   particular care-of address.  The granularity of what constitutes a
   flow depends on the traffic selector used.

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

5.1.1.  Preferred Care-of address

   Any node that supports this 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 BID-PRI field of the binding identifier mobility option
   (see Section 4.1).

   The ordered list of BIDs is used to determine how to forward a packet
   to a given mobile node when the packet does not match any of the flow
   binding entries defined in Section 4.3.  A packet that does not match
   any of the flow binding entries SHOULD be forwarded to the care-of
   address identified by the BID with the highest priority i.e., lowest
   BID-PRI value.

5.2.  Mobile Node Considerations

   This specification allows the mobile node to maintain several
   bindings with its mobility agent, and correspondent nodes and to
   direct packets to different care-of addresses according to flow
   bindings.  This section details the mobile node operations necessary



Soliman, et al.         Expires September 2, 2010              [Page 19]

Internet-Draft                Flow binding                    March 2010


   to implement this specification.

   The mobility agent and correspondent node list of flow bindings is
   manipulated by the mobile node, via flow identification and flow
   summary mobility options included in binding update messages.  Each
   flow binding update can add, modify, refresh, or delete a given
   binding.  More than one flow identification mobility options MAY be
   included in the same binding update but each of them MUST include a
   different FID.  In other words, two flow identification options in
   the same message can not be about the same flow binding.

   All flow binding state MUST be refreshed in every binding update the
   mobile node sends.  Any previously registered flow binding that is
   not included in a given binding update will be deleted.  So, any flow
   bindings that are not added or modified by a flow identification
   mobility option, but have previously registered and need to be
   maintained MUST be included in a flow summary mobility option.  Only
   one flow summary mobility option can be included in a given binding
   update.

5.2.1.  Sending BU with BID Options

   This specification (see Section 4.1) updates the definition of the
   binding identifier mobility option, originally defined in [RFC5648].
   According to this specification the BID 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 4.3.

   To ensure backwards compatibility with [RFC5648] for the purpose of
   this specification the field BID-PRI SHOULD NOT be set to zero.
   Receiver implementation of this specification will take a BID-PRI
   field of value zero as an indication that this is a BID option of the
   format defined in [RFC5648].

   Mobile nodes supporting this specification MUST use the BID option
   format defined in Section 4.1.  Mobile nodes MUST also register all
   care-of addresses using the updated BID option format, either in the
   same BU as any flow identification mobility options using them, or in
   earlier BUs.

5.2.2.  Sending BU with Flow Identification Mobility Options

5.2.2.1.  New Flow Bindings

   When adding a new flow binding, a mobile node sends the flow
   identification mobility option in the binding update, with the FID
   field set to a value that is not already present in the list of flow
   binding entries maintained by the receiver.  The care-of address(es)



Soliman, et al.         Expires September 2, 2010              [Page 20]

Internet-Draft                Flow binding                    March 2010


   associated with each flow identification mobility options in the
   binding update, must be logically registered by this binding update,
   or must have already been registered by the receiver of the binding
   update in an earlier binding update, as defined in Section 5.2.1.

   The flow identification mobility option MUST include a unique flow
   identifier in the FID field.  The FID needs only be unique for the
   receiver of the binding update and for the same sender, i.e. the same
   FID can be used across different receivers of the binding update, for
   the same sender.

      The FID-PRI field is set to the desired unique priority of the
      FID, defining the order of the flow binding to be added in the
      list of flow binding entries as defined in Section 4.3.

      The Action field is set to one of the defined action codes (see
      Section 4.2).

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

   Since this flow identification mobility option is requesting the
   addition of a new flow binding in the list of flow bindings
   maintained by the receiver, the mobile node MUST include exactly one
   Traffic Selector sub-option (see Section 4.2.1.4) describing the flow
   associated with the new flow binding.  The TS Format field of the
   Traffic Selector sub-option MUST be set to the non-zero value of the
   format used by the mobile node.

   The mobile node MAY also include up to one BID Reference sub-option
   (see Section 4.2.1.3) to associate the flow binding with a given set
   of BIDs and corresponding CoAs.  Depending on the Action field of the
   flow identification mobility option, the following rules MUST be
   followed with respect to the binding reference sub-option:

      - if the Action indicates 'Discard', the binding reference sub-
      option SHOULD NOT be included.  If it is included it will be
      ignored by the receiver.

      - if the Action indicates 'Forward', a single binding reference
      sub-option with one or more BIDs MUST be included.

5.2.2.2.  Updating Flow Bindings

   Flow binding modification is essentially a process where parameters
   associated with an existing flow binding in the list of flow binding
   entries is replaced by parameters included in the flow identification
   mobility option, and the same FID is maintained.  With this procedure
   the mobile node can change the action, the priority, the BID, and/or



Soliman, et al.         Expires September 2, 2010              [Page 21]

Internet-Draft                Flow binding                    March 2010


   the traffic selector associated with a flow binding.

   To modify an existing flow binding the mobile node MUST send a
   binding update with a flow identification option, with the FID field
   set to one of the FID values already in the list of flow binding
   entries.

      The FID-PRI and Action fields MUST be set to the priority value
      for the flow binding entry.

      The Status field is set to zero since this option is in a binding
      update.

   The mobile node MAY include exactly one traffic selector sub-option
   (see Section 4.2.1.4) describing the updated flow to be associated
   with the flow binding.  The mobile node MAY, however, omit the
   traffic selector sub-option if it wants the traffic selector
   currently associated with the flow binding entry identified by the
   FID field to be maintained.

   The mobile node MAY include exactly one binding reference sub-option
   (see Section 4.2.1.3) to associate the existing flow binding with a
   new set of CoAs.  If the mobile node includes a binding reference
   sub-option then it should follow the rules described in
   Section 5.2.2.1.  The mobile node MAY omit the binding reference sub-
   option if it wants the BIDs currently associated with the flow
   binding entry identified by the FID field to be maintained.

   Note that it is also possible for the mobile node to effectively
   modify the effect of a flow binding entry without actually changing
   the entry itself.  This can be done by changing the CoA associated
   with a given BID, which is a process defined in detail in [RFC5648].

5.2.3.  Sending BU with a Flow Summary Option

   When the mobile node sends a binding update it MUST refresh all flow
   bindings it wants to maintain even if it does not want to change any
   of their parameters.

   To refresh an existing flow binding the mobile node MUST 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.2.2.
   Each FID field included MUST be set to one of the FID values already
   in the list of flow binding entries.

   Any flow bindings (active or inactive) that are not included in a
   binding update will be removed from the list of flow binding entries.




Soliman, et al.         Expires September 2, 2010              [Page 22]

Internet-Draft                Flow binding                    March 2010


   Note that any inactive flow bindings, i.e., flow bindings without
   associated BIDs that are marked as Inactive in the list of flow
   binding entries (see Section 4.3), 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 binding 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
   includes flow identification and flow summary mobility options for
   all the FIDs that need to be refreshed, modified, or added, and
   simply omits any FIDs that need to be removed.

   Note that a mobile node can also render a flow binding inactive by
   removing the BIDs associated with it, without removing the flow
   binding itself.  The procedure for removing a BID is defined in
   detail in [RFC5648].

   When all the BIDs associated with a flow binding are removed, the
   flow binding MUST be marked as inactive in the list of flow binding
   entries as shown in Section 4.3.  In other words the state associated
   with the flow binding MUST be maintained but it does no longer affect
   the mobile node's traffic.  The MN can return an inactive flow
   binding to the 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.  Remember that flow bindings indicating a
   'Discard' action do not take BIDs and thus cannot be rendered
   inactive.  Instead these entries can only be removed by omitting
   their FID from a subsequent BU.

5.2.5.  Returning Home

   This specification is compatible to the home registration procedures
   defined in [RFC3775] and [RFC5648].  More specifically, if the mobile
   node performs an [RFC3775] style deregistration, all of its bindings,
   including flow bindings are deleted.  If the mobile node, however,
   performs an [RFC5648] style home registration, then the home link is
   associated with a specific BID and so, as far as this specification
   is concerned, it is treated as any other link associated with a given
   BID.

5.2.6.  Receiving Binding Acknowledgements

   According to [RFC3775] all nodes are required to silently ignore
   mobility options not understood while processing binding updates.  As



Soliman, et al.         Expires September 2, 2010              [Page 23]

Internet-Draft                Flow binding                    March 2010


   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 every flow identification mobility
   options included in the binding update.  A Binding Acknowledgement
   without flow identification option(s), in response to a Binding
   Update with flow identification mobility option, would indicate
   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 each flow
   identification mobility 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.

5.2.7.  Return Routability Procedure

   A mobile node may perform route optimization with 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.

5.3.  HA, MAP, and CN Considerations

   This specification allows the mobility agents (Home Agents and
   Mobility Anchor Points), and correspondent nodes to maintain several
   flow 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.  These operations are identical for MAPs and CNs
   unless otherwise stated.

   Note that route optimization is only defined for mobile nodes (MIPv6
   [RFC3775]), and not mobile routers (NEMOv6 [RFC3963]).  Thus, these
   sections only apply to correspondent nodes with respect to mobile
   nodes and not for mobile routers.

5.3.1.  Handling Binding Identifier Mobility Options

   This specification (see Section 4.1) updates the definition of the
   binding identifier mobility option, originally defined in [RFC5648].
   According to this specification the BID option includes a BID-PRI
   field assigning each registered care-of address a priority, and thus
   placing them in an ordered list (see Section 4.3).




Soliman, et al.         Expires September 2, 2010              [Page 24]

Internet-Draft                Flow binding                    March 2010


   Home agents receiving BUs including BID options and flow
   identification options MUST logically process BID options first.
   This is because BID Reference sub-options included in the flow
   identification mobility options might refer to BIDs defined in BID
   options included in the same message.

   The BID option is processed as defined in [RFC5648] but then the BID
   to care-of address mapping is placed in an ordered list according to
   the BID-PRI field of the BID option.

   Binding Identifier registrations and deregistrations indirectly
   affect the MN's flow binding entries.  The home agent MUST update the
   flow binding entries table accordingly as BIDs are added or removed (
   [RFC5648]).  For example, as discussed in Section 4.3, if all of the
   BIDs associated with a given flow binding entry are removed (i.e.,
   become invalid) the entry MUST be marked as inactive.  While if any
   of the invalid BIDs associated with an inactive flow binding entry
   are registered (i.e., become valid), the entry MUST be marked as
   active.

5.3.2.  Handling Flow Identification Mobility Options

   When the home agent receives a binding update which includes at least
   one flow identification mobility option, it first performs the
   operation described in section 10.3.1 of RFC3775, followed by the
   operations defined in Section 5.3.1 of this document.

   Home agents that do not support this specification will ignore the
   flow identification mobility options and all their sub-options,
   having no effect on the operation of the rest of the protocol.

   If the binding update is accepted, and the home agent is willing to
   support flow bindings for this MN, the home agent checks the flow
   identification mobility options.

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

   If all FID fields have different values the flow identification
   mobility options can be processed further and in any order, as
   defined by the following subsections.

5.3.2.1.  Handling new FIDs

   If the FID field of the flow identification mobility option is not
   already present in the list of flow binding entries for this mobile
   node, then this is a request for a new entry.



Soliman, et al.         Expires September 2, 2010              [Page 25]

Internet-Draft                Flow binding                    March 2010


   If the flow identification mobility option does not include a traffic
   selector sub-option, the home agent MUST reject this request by
   copying the flow identification mobility option in the BA, and
   setting the Status field to the value defined in Figure 2 for "Flow
   identification option malformed".

   If the flow identification option does include a traffic selector
   sub-option, but the format indicated in the TS Format field is not
   supported, the home agent MUST reject this request by copying the
   flow identification mobility option in the BA, and setting the Status
   field to the value defined in Figure 2 for "Traffic Selector format
   not supported".

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

   - if the Action indicates 'Discard',

      Any binding reference sub-options that might be present SHOULD be
      ignored.

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

   - if the Action indicates 'Forward",

      If the Binding reference sub-option is not included, the home
      agent MUST reject this request by copying the flow identification
      mobility option in the BA, and setting the Status field to the
      value defined for "Flow identification mobility option malformed"
      in Section 4.2.

      If the binding reference sub-option is present and includes one or
      more BIDs that are not present in the binding cache of the mobile
      node the home agent MUST reject this request by copying the flow
      identification option in the BA, and setting the Status field to
      the value defined for "BID not found" in Section 4.2.

      If the binding reference sub-option is present and includes one or
      more BIDs, and the BIDs exist in the mobile node's binding cache,
      the home agent SHOULD add a new entry in the mobile node's list of
      flow binding entries, as defined below.

   When the home agent decides to add an entry in the mobile node's list
   of flow binding entries, as discussed above, it MUST do it according
   to the following rules: The entry MUST be placed according to the
   order indicated by the FID-PRI field of the flow identification
   mobility option and it MUST include:



Soliman, et al.         Expires September 2, 2010              [Page 26]

Internet-Draft                Flow binding                    March 2010


      the FID as a key to the entry

      The traffic selector included in the corresponding sub-option

      the action indicated in the Action field

      the BIDs, depending on action field, indicated in the binding
      reference sub-option

      the entry MUST be marked as Active, as shown in Section 4.3

5.3.2.2.  Handling known FIDs

   If the FID field of the flow identification mobility option is
   already present in the list of flow binding entries for this mobile
   node, then this is a request to update the existing entry.

   The flow binding modification is essentially a process where
   parameters associated with an existing flow binding entry are
   replaced by the parameters included in a flow identification mobility
   option with the same FID as the existing entry.

   The home agent MUST:

      Change the priority of the entry according to the FID-PRI field of
      the flow identification mobility option.

      Change the action associated with the entry according to the
      Action field of the flow identification mobility option.

   Since this flow identification mobility option is designed to update
   an existing entry it may not include a traffic selector sub-option.

      If a traffic selector sub-option is not included in the flow
      identification mobility option, then the traffic selector already
      associated with entry MUST be maintained,

      otherwise the traffic selector in the entry MUST be replaced by
      the traffic selector in the sub-option.

   Like Section 5.3.2.1, if the Action field in the flow identification
   mobility option is set to 'Discard' if a binding reference sub-option
   is included in the option, it SHOULD be ignored; and any BIDs
   associated with the existing flow binding entry SHOULD be removed.

   Unlike Section 5.3.2.1, however, if the Action field in the flow
   identification mobility option is set to 'Forward', and since this
   flow identification mobility option is designed to update an existing



Soliman, et al.         Expires September 2, 2010              [Page 27]

Internet-Draft                Flow binding                    March 2010


   entry, it may not include a binding reference sub-option.

      If a binding reference sub-option is not included in the flow
      identification mobility option, then the BIDs already associated
      with entry MUST be maintained,

      otherwise the BIDs in the entry MUST be replaced by the BIDs in
      the sub-option.

5.3.3.  Handling Flow Summary Mobility Option

   When the home agent receives a binding update which includes a flow
   summary mobility option, it first performs the operation described in
   section 10.3.1 of RFC3775.  Binding update messages including more
   than one flow summary mobility option MUST be rejected.  A de-
   registration binding update (with a zero lifetime) would result in
   deleting all bindings, including all flow bindings regardless of the
   presence of the flow summary mobility option.

   If the value of any of the FID fields included in the flow summary
   mobility option is not present in the list of flow binding entries
   for this mobile node, the home agent MUST reject this flow binding
   refresh by including a flow identification mobility option in the BA
   for each FID that is not found, and by setting the FID field to the
   value of the FID that is not found and the Status field to the value
   defined for "FID not found" in Section 4.2.

   If the value of the FID field is present in the mobile nodes list of
   flow binding entries the, home agent SHOULD refresh the flow binding
   entry identified by the FID without changing any of the other
   parameters associated with it.

5.3.4.  Flow Binding Removals

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

   When a valid binding update is received, any registered FIDs that are
   not explicitly referred to in a flow identification mobility option
   or in a flow summary mobility option, in the same binding update,
   MUST be removed from the list of flow binding entries for the mobile
   node.

5.3.5.  Sending Binding Acknowledgements

   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 recommended in [RFC3775].  This status



Soliman, et al.         Expires September 2, 2010              [Page 28]

Internet-Draft                Flow binding                    March 2010


   code does not give information on the success or failure of flow
   bindings.

   In order to inform the mobile node about the status of the flow
   binding(s) requested by a mobile node, flow identification options
   SHOULD be included in the Binding Acknowledgement message.
   Specifically, the home agent SHOULD copy each flow identification
   mobility option received in the binding update and set its status
   code to an appropriate value.  If an operation requested in a flow
   identification option by a mobile node is performed successfully by
   the home agent, the status field on the copied flow identification
   mobility option in the BA, SHOULD be set to the value defined for
   "Flow binding successful" in Section 4.2, otherwise it SHOULD be set
   to one of the rejection codes also defined in Section 4.2.
   Section 5.3.2 identifies a 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 status field of any flow identification
   mobility options to the value defined for "Administratively
   prohibited" in Section 4.2, or by just ignoring all the flow binding
   options.

   Note that BID options and their Status field are handled as defined
   in [RFC5648].

5.3.6.  Packet Processing

   This section defines packet processing rules according to this
   specification.  This specification does not change any of the packet
   interception rules defined in [RFC3775], and [RFC5555].  These rules
   apply to HAs, MAPs, and CNs, as part of the routing process for any
   packet with destination address set to a valid home address of the
   mobile node.  For nodes other than CNs this also applies to packets
   with destination address set to an address under any of the
   registered prefixes.  These rules apply equally to IPv6 packets as
   well as to IPv4 packets as per [RFC5555].

   Before a packet is forwarded to the mobile node it MUST be matched
   against the ordered list of flow bindings stored in the list of flow
   binding entries for this mobile node (see Section 4.3).  A match is
   attempted with the traffic selector included in the first line
   (highest order) of the table.  If the packet matches the traffic
   selector, the action defined by the action parameter of the table
   SHOULD be performed.

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



Soliman, et al.         Expires September 2, 2010              [Page 29]

Internet-Draft                Flow binding                    March 2010


      - if the Action indicates 'Forward", a copy of the packet is
      forwarded to each of the care-of addresses associated with the
      BIDs indicated in the same line of the table.

   If the action indicated in one of the entries in the list of flow
   bindings is 'Discard' then, no BIDs need to be indicated in the same
   entry since the packet is not forwarded.  If, however, the action
   indicated in an entry of the list of flow bindings is 'Forward", the
   entry should indicate one or more valid BIDs.  For 'Forward' if any
   of the BIDs indicated does not correspond to a valid care-of address,
   e.g., the BID was deregistered then that BID has no effect on the
   traffic.  In other words, packets matching the flow binding are
   forwarded to the remaining BIDs, pointing to registered care-of
   addresses.  If none of the BIDs pointed to in a flow binding entry is
   valid then the entry is considered to be inactive (as defined in
   Section 4.3) and is skipped.  In other words packets should not be
   matched against that entry.

   If a packet does not match any of the active flow binding entries for
   the given MN, the packet SHOULD be forwarded to the care-of address
   associated with the BID with the highest BID-PRI.

   If a packet is fragmented, only the first fragment contains all IP
   and transport layer headers, while subsequent fragments only contain
   an IP header without transport layer headers.  For this reason it is
   possible that subsequent fragments do not match the same traffic
   selector as the initial fragment of such a packet.  Unless specific
   measures are taken the likely outcome is that the initial fragment is
   routed as the MN intended while subsequent fragments are routed
   differently, and probably based on the default flow binding.  HAs,
   MAPs, and CNs SHOULD take care to forward all fragments of a given
   packet the same way, and in accordance to the flow binding matching
   the first fragment of said packet.  This should be possible given the
   fact that fragment headers include enough information to identify a
   fragment as part of a specific packet, but the details of how this is
   ensured are implementation specific and are not defined in this
   specification.














Soliman, et al.         Expires September 2, 2010              [Page 30]

Internet-Draft                Flow binding                    March 2010


6.  MTU Considerations

   The options and sub-options defined in this specification add to
   those defined in [RFC3775] and other related specifications, all of
   which potentially adds to the size of binding update messages.
   Implementations SHOULD take care to minimize fragmentation by forming
   binding updates that are shorter than what the path MTU allows
   whenever possible.

   This specification offers a number of mechanisms for reducing the
   size of binding updates.  The operations defined in this
   specification that require the most verbose options are those
   registering new BIDs Section 4.1 and identifying new flows
   Section 4.2.1.4.  Implementations are encouradged to keep binding
   updates to sizes below than that of the path's MTU by making full use
   of BID Reference Section 4.2.1.3 and FID Summary Section 4.2.2 sub-
   options, which allows them to refer to already registered care-off
   addresses and flows, while registering new ones in subsequent binding
   update messages.
































Soliman, et al.         Expires September 2, 2010              [Page 31]

Internet-Draft                Flow binding                    March 2010


7.  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 one interface and other flows to another
   interface.  Since the flow identification mobility option is part of
   the mobility header, it uses the same security as the Binding Update,
   whether it is sent to a mobility agent, or to a correspondent node.











































Soliman, et al.         Expires September 2, 2010              [Page 32]

Internet-Draft                Flow binding                    March 2010


8.  IANA Considerations

   This specification requires the following IANA assignments on
   existing namespaces as well as the creation of some new namespaces.

      1) New Mobility Options [RFC3775]: This registry is available from
      http://www.iana.org under "Mobile IPv6 parameters".  The following
      type numbers need to be assigned for:

         Flow Identification Mobility Option, define in Section 4.2

         Flow Summary Mobility Option, defined in Section 4.2.2

      2) New "Flow Identification Mobility Option Action codes"
      namespace needs to be created.  The following 'Action' codes are
      defined in this specification, in Section 4.2:

         0 Reserved

         1 Discard

         2 Forward

         3-254 unassigned and available for allocation based on
         Standards Action or IESG Approval as per [RFC5226]

         255 reserved for experimental use.  A single value should be
         sufficient for experimenting with a different flow
         identifiction format.

      3) New "Flow Identification Mobility Option Status codes"
      namespace needs to be created.  The following 'Status' codes are
      defined in this specification, in Section 4.2:

         0 Flow binding successful

         1-127 unassigned and available for success codes to be
         allocated via STD action

         128 Administratively prohibited

         129 Flow binding rejected, reason unspecified

         130 Flow identification mobility option malformed

         131 BID not found





Soliman, et al.         Expires September 2, 2010              [Page 33]

Internet-Draft                Flow binding                    March 2010


         132 FID not found

         133 Traffic selector format not supported

         134 Discard function not supported

         135 Forward function not supported

         126-250 unassigned and available for reject codes to be
         allocated via Standards Action or IESG Approval as per
         [RFC5226]

         251-255 reserved for experimental use.  This small number of
         status codes should be sufficient for experiments with
         currently unforeseen error conditions.

      4) New "Flow Identification Sub-Options" namespace for the Flow
      Identification Mobility Option.  The sub-option space is defined
      in Figure 3.  The following Sub-option Type values are defined in
      this specification:

         0 Pad

         1 PadN

         2 BID Reference

         3 Traffic Selector

         4-250 unassigned and available for allocation based on
         Standards Action or IESG Approval as per [RFC5226]

         251-255 reserved for experimental use.  This small number of
         sub-option types should be sufficient for experiments with
         additional parameters associated with a flow.

      5) New "Traffic Selector Format" namespace for the Traffic
      Selector sub-option.  The traffic selector format space is defined
      by the TS Format field in Figure 5.  The following values are
      defined in this specification:

         0 Reserved

         1-250 unassigned and available for allocation based on
         Standards Action or IESG Approval as per [RFC5226]

         251-255 reserved for experimental use.  This small number of
         traffic selector format types should be sufficient for



Soliman, et al.         Expires September 2, 2010              [Page 34]

Internet-Draft                Flow binding                    March 2010


         experiments with different ways of representing a traffic
         selector.

   Similar to the procedures specified for Mobile IPv6 [RFC3775] number
   spaces, future allocations from the new number spaces requires
   Standards Action or IESG Approval as per [RFC5226]













































Soliman, et al.         Expires September 2, 2010              [Page 35]

Internet-Draft                Flow binding                    March 2010


9.  Contributors

   We would like to explicitly acknowledge the following person who co-
   authored one of the documents used as source material for this
   document.

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












































Soliman, et al.         Expires September 2, 2010              [Page 36]

Internet-Draft                Flow binding                    March 2010


10.  Acknowledgements

   We would also like to acknowledge the following people in
   alphabetical order for their contributions to this specification: C.
   Castelluccia, D. Craig, K. ElMalki, K. Georgios, , C. Goerg, C. Kaas-
   Petersen, J. Laganier, T. Noel, F.-N.  Pavlidou, V. Park, P. Stupar.
   Also, Gabor Fekete for the analysis that led to the inclusion of the
   BIDRef sub-option, and Henrik Levkowetz for suggesting support for
   other ways of describing flows.










































Soliman, et al.         Expires September 2, 2010              [Page 37]

Internet-Draft                Flow binding                    March 2010


11.  References

11.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 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.

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

   [RFC5555]  Soliman, H., "Mobile IPv6 Support for Dual Stack Hosts and
              Routers", RFC 5555, June 2009.

   [RFC5648]  Wakikawa, R., Devarapalli, V., Tsirtsis, G., Ernst, T.,
              and K. Nagami, "Multiple Care-of Addresses Registration",
              RFC 5648, October 2009.

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

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











Soliman, et al.         Expires September 2, 2010              [Page 38]

Internet-Draft                Flow binding                    March 2010


Authors' Addresses

   Hesham Soliman
   Elevate Technologies

   Email: hesham@elevatemobile.com


   George Tsirtsis
   Qualcomm

   Email: tsirtsis@qualcomm.com


   Nicolas Montavont
   Institut Telecom / 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.enst-bretagne.fr/~nmontavo//


   Gerardo Giaretta
   Qualcomm

   Email: 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/









Soliman, et al.         Expires September 2, 2010              [Page 39]


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