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


          Flow Bindings in Mobile IPv6 and Nemo Basic Support
                  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 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 in effect on the date of
   publication of this document (http://trustee.ietf.org/license-info).
   Please review these documents carefully, as they describe your rights



Soliman, et al.         Expires October 30, 2009                [Page 1]


Internet-Draft                Flow binding                    April 2009


   and restrictions with respect to this document.


















































Soliman, et al.         Expires October 30, 2009                [Page 2]


Internet-Draft                Flow binding                    April 2009


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 their peers to direct downlink
   flows to specific addresses.


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.  Binding Reference Sub-option . . . . . . . . . . . . . 11
       4.2.2.  Flow Description Sub-option  . . . . . . . . . . . . . 12
     4.3.  Flow Identification Summary Mobility Option  . . . . . . . 13
     4.4.  Flow Bindings entries list and its relationship to
           Binding Cache  . . . . . . . . . . . . . . . . . . . . . . 14
   5.  Protocol operations  . . . . . . . . . . . . . . . . . . . . . 17
     5.1.  General  . . . . . . . . . . . . . . . . . . . . . . . . . 17
       5.1.1.  Preferred Care-of address  . . . . . . . . . . . . . . 17
     5.2.  Mobile Node Considerations . . . . . . . . . . . . . . . . 17
       5.2.1.  Sending BU with BID Options  . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . 21
       5.2.5.  Receiving Binding Acknowledgements . . . . . . . . . . 21
       5.2.6.  Return Routability Procedure . . . . . . . . . . . . . 21
     5.3.  HA, MAP, and CN Considerations . . . . . . . . . . . . . . 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  . . . . . . . . 25
       5.3.4.  Handling flow binding Removals . . . . . . . . . . . . 26
       5.3.5.  Sending Binding Acknowledgements . . . . . . . . . . . 26
       5.3.6.  Packet Processing  . . . . . . . . . . . . . . . . . . 27
   6.  Security considerations  . . . . . . . . . . . . . . . . . . . 28
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 29
   8.  Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 30
   9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 31
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32
     10.1. Normative References . . . . . . . . . . . . . . . . . . . 32
     10.2. Informative References . . . . . . . . . . . . . . . . . . 32
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33




Soliman, et al.         Expires October 30, 2009                [Page 3]


Internet-Draft                Flow binding                    April 2009


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 October 30, 2009                [Page 4]


Internet-Draft                Flow binding                    April 2009


2.  Introduction

   Mobile IPv6 [RFC3775], DSMIPv6 [I-D.ietf-mext-nemo-v4traversal] 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.  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],
   [I-D.ietf-mext-nemo-v4traversal], and [RFC3963] do not allow a mobile
   node / mobile router to bind more than one address to the home
   address.  In [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, 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 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, this specification
   allows to bind a particular flow to a particular care-of address
   directly with correspondent node and mobility anchor point.

   In this document, a flow is defined as a set of IP packets matching a
   flow descriptor.  A flow descriptor 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 flow
   descriptors and it is assumed that one or more ways of defining flow
   descriptors are going to be defined in 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 can bind one 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), or mobility
   anchor point (in the case of Hierarchical Mobile IPv6).




Soliman, et al.         Expires October 30, 2009                [Page 5]


Internet-Draft                Flow binding                    April 2009


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
















































Soliman, et al.         Expires October 30, 2009                [Page 6]


Internet-Draft                Flow binding                    April 2009


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 identified as a set of data packets that are
      exchanged between two 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: An entry in the list of flow binding associated with
      a given mobile node.





































Soliman, et al.         Expires October 30, 2009                [Page 7]


Internet-Draft                Flow binding                    April 2009


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 [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
                                       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                       |   Type = TBD  |     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 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.






Soliman, et al.         Expires October 30, 2009                [Page 8]


Internet-Draft                Flow binding                    April 2009


       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, including any sub-options, in 8-octet units

      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.

      Action

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

      Rsvd

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




Soliman, et al.         Expires October 30, 2009                [Page 9]


Internet-Draft                Flow binding                    April 2009


      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.

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

      0 Add a flow binding

      1 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 indicated in the 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.  No BIDs are associated with
      this Action.

      3 n-cast.  This value indicates a request to replicate the flow to
      several addresses indicated in the Binding Reference sub-option.
      One or more BIDs MUST be associated with this 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 identification option poorly formed.




Soliman, et al.         Expires October 30, 2009               [Page 10]


Internet-Draft                Flow binding                    April 2009


      130 Administratively prohibited.

      135 FID already in use

      136 FID not found

      137 FD-Type not supported.

      138 Discard function not supported.

      139 N-cast function not supported.

   It should be noted that per-packet load balancing 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 currently supported in this extension.

   A number of sub-options can follow 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 defined in MCoA
   [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 registered BIDs.

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



Soliman, et al.         Expires October 30, 2009               [Page 11]


Internet-Draft                Flow binding                    April 2009




      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 Sub-opt Type
         and 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.  Since each BID is 2 byte long, the value
         of the Sub-opt Len field indicates the number of 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 parameters used to
   match packets for a specific flow binding.

       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 Sub-option type.  For the flow 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 octets.  This field includes
         the entire length of the sub-option including the Sub-opt Type
         and Sub-opt-Len fields.




Soliman, et al.         Expires October 30, 2009               [Page 12]


Internet-Draft                Flow binding                    April 2009


      Flow Description

         The flow description corresponding to the type indicated by the
         Sub-opt Type field.  Flow description is out of scope of this
         document.

   The following values are reserved for the sub-option Type values are
   defined for Flow 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 field MUST be set to 1.

      Option Length

         Indicates the sub-option length in octets.  This field includes
         the entire length of the sub-option including the Sub-opt Type
         and Sub-opt-Len fields.

      FID

         A registered FID.  One or more FID fields can be included in
         this option.  Since each FID is 2 bytes long, the value of the
         Option Len field indicates the number of FIDs present.  Number
         of FIDs = (Sub-opt Len-2)/2.







Soliman, et al.         Expires October 30, 2009               [Page 13]


Internet-Draft                Flow binding                    April 2009


4.4.  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, home
   agent, and corresponding 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 was then
   extended by [I-D.ietf-monami6-multiplecoa] to include more than one
   care-of addresses and to associate each of them with a Binding
   Identifier (BID).

   This specification does not change 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 binding.  Flow binding
   entries can point to an entry in the binding cache by means of the
   BID.  Each flow binding entry include the following parameters :



      *  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.
         Different mobile nodes can use the same FID number space.

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

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

      *  Action: The action associated with a given entry as defined by
         the PRO field of the 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 given mobile node, and
   the corresponding 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.

   The BIDs included in a given entry point to a corresponding entry in
   the binding cache for the purpose of identifying a care-of address.



Soliman, et al.         Expires October 30, 2009               [Page 14]


Internet-Draft                Flow binding                    April 2009


   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 entry becomes "inactive", in other words it does not affect
   data traffic.  Note that if the action parameter in an entry
   indicates "n-cast" then the entry becomes inactive only if none of
   the BIDs is valid.  If only some of the BIDs are 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 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 mobile node in detail.

   As an example the following represents an ordered flow bindings
   entries table for a mobile node 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 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 third 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 October 30, 2009               [Page 15]


Internet-Draft                Flow binding                    April 2009


   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 BID 1, corresponding to care-of address
   IP1.

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

                            Ordered BID Entries






































Soliman, et al.         Expires October 30, 2009               [Page 16]


Internet-Draft                Flow binding                    April 2009


5.  Protocol operations

5.1.  General

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

   The flow identification option defines how the mobile node can
   control a set of flow binding entries maintained in a home agent,
   correspondent node, or mobility anchor points, on its behalf.  The
   fields of the flow identification option are necessary for ordering
   flow identification 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 flow descriptor used.  As indicated earlier the
   flow description itself is defined in another document.

   The remaining 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 bindings
   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 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.4.  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 in its home agent and to direct packets to different care-of
   addresses according to flow bindings.  This section details the



Soliman, et al.         Expires October 30, 2009               [Page 17]


Internet-Draft                Flow binding                    April 2009


   mobile node operations necessary to implement this specification.

   The home agent list of flow bindings is manipulated by the mobile
   node, via flow identification and flow summary options included in
   binding update messages.  Each flow binding update can add, modify,
   refresh, or delete a given binding.  More than one flow
   identification 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
   option, but have previously registered and need to be maintained MUST
   be included in a flow summary option.  Only one flow summary 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 option, originally defined in
   [I-D.ietf-monami6-multiplecoa].  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.4.

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

5.2.2.  Sending BU with Flow Identification Options

5.2.2.1.  Adding flow bindings

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



Soliman, et al.         Expires October 30, 2009               [Page 18]


Internet-Draft                Flow binding                    April 2009


   used across different receivers of the binding update, for the same
   sender.

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

      The Action field is set to one of the 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 Description sub-option
   (see Section 4.2.2) describing the flow associated with the new
   binding.

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

      - if the Action indicates 'Forward', a 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 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 'n-cast', a single Binding Reference
      sub-option with one or more BIDs MUST be included.

5.2.2.2.  Modifying flow bindings

   Flow binding modification is essentially a process where an existing
   flow binding is removed from the list of flow binding entries and a
   new flow binding (included in the option) is added, and given the
   same FID as the flow that was removed.  With this procedure the
   mobile node can change the action, the priority, the BID, or the flow
   description 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.



Soliman, et al.         Expires October 30, 2009               [Page 19]


Internet-Draft                Flow binding                    April 2009


      The PRO field MUST be set to 1, indicating a request to modify the
      binding.

      The FID-PRI and Action fields MUST be set to the desired values to
      be implemented with this modification.

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

   The mobile node MAY include exactly one Flow Description sub-option
   (see Section 4.2.2) describing the modified flow to be associated
   with the binding.

   The mobile node MAY also include exactly one BID Reference sub-option
   (see Section 4.2.1) to associate the existing binding with a new set
   of CoAs.  The rules regarding the Binding Reference sub-option in
   this case are identical to those described from flow binding addition
   in Section 5.2.2.1 .

   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
   [I-D.ietf-monami6-multiplecoa].

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

   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.4, MUST also be refreshed, or
   modified, to be maintained.  If they are not included in a BU they
   will be removed.






Soliman, et al.         Expires October 30, 2009               [Page 20]


Internet-Draft                Flow binding                    April 2009


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
   includes flow identification and flow summary 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 remove the BIDs associated with a
   given Flow Binding, without removing the flow binding itself.  The
   procedure for removing a BID is defined in detail in
   [I-D.ietf-monami6-multiplecoa].

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

5.2.5.  Receiving Binding Acknowledgements

   According to [RFC3775] all nodes are required to silently ignore
   mobility options not understood while processing binding updates.  As
   such a mobile node receiving a Binding Acknowledgement in response to
   the transmission of a binding update MUST determine if the Binding
   Acknowledgement contains a copy of every flow identification options
   included in the binding update.  A Binding Acknowledgement without
   flow identification option(s), in response to a Binding Update with
   flow identification 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 of each flow
   identification option that was sent within the binding update, the
   status field of each flow identification option indicates the status
   of the flow binding on the distant node.

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



Soliman, et al.         Expires October 30, 2009               [Page 21]


Internet-Draft                Flow binding                    April 2009


   the mobile node.  Before sending a Binding Update to correspondent
   node, the Return Routability Procedure needs to be performed between
   the mobile node and the correspondent node.

   This procedure is not affected by the extensions defined in this
   document.  However, since a binding update message is secured with
   the key generated based on the home address and care-of address test,
   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.

5.3.  HA, MAP, and CN Considerations

   This specification allows the home agents, mobility anchor points,
   and corresponding nodes to maintain several bindings for a given home
   address and to direct packets to different care-of addresses
   according to flow bindings.  This section details the home agent
   operations necessary to implement this specification.  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.  Receiving BU with BID Options

   This specification (see Section 4.1) updates the definition of the
   Binding Identifier option, originally defined in
   [I-D.ietf-monami6-multiplecoa].  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.4).

   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 options might refer to BIDs defined in BID options
   included in the same message.

   The BID option is processed as defined in
   [I-D.ietf-monami6-multiplecoa] 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.





Soliman, et al.         Expires October 30, 2009               [Page 22]


Internet-Draft                Flow binding                    April 2009


5.3.2.  Receiving BU with Flow Identification Options

   When the home agent receives a binding update which includes at least
   one Flow Identification option, it first performs the operation
   described in section 10.3.1 of RFC3775.

   Home agents that do not support this specification will ignore the
   flow identification options and all their suboption, 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 options.

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

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

5.3.2.1.  Handling Flow Binding Add Requests

   If the PRO field of the flow identification option is set to 'Add',
   it indicates a flow binding add request.

   If the FID field of the flow identification option is already present
   in the list of flow binding entries for this mobile node, the home
   agent MUST reject this flow binding add request by copying the flow
   identification option in the BA, and setting the Status field to 135
   (FID already in use).

   If the flow identification option does not include a flow description
   sub-option, the home agent MUST again reject this request by copying
   the flow identification option in the BA, and setting the Status
   field to 129 (Flow identification option poorly formed).

   If the flow identification option does include a flow description
   sub-option, but the flow description type is not supported, the home
   agent MUST also reject this request by copying the flow
   identification option in the BA, and setting the Status field to 137
   (FD-Type not supported).

   If the FID value is new the home agent MUST check the Action field in
   combination with the Binding Reference sub-option if present.

   - if the Action indicates 'Forward'



Soliman, et al.         Expires October 30, 2009               [Page 23]


Internet-Draft                Flow binding                    April 2009


      If the Binding reference sub-option is not included or if it is
      included but it contains more than a single BID, the home agent
      MUST reject this flow binding add request by copying the flow
      identification option in the BA, and setting the Status field to
      129 (Flow identification option poorly formed).

      If the Binding Reference sub-option is present and includes a
      single BID, but the BID is not present in the binding cache of the
      mobile node the home agent MUST reject this flow binding add
      request by copying the flow identification option in the BA, and
      setting the Status field to TBD (BID not known).

      If the Binding Reference sub-option is present and includes a
      single BID, and the BID exists 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.

   - 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 '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 in the BA, and setting the Status field
      to 129 (Flow identification option poorly formed).

      If the Binding Reference sub-option is present and includes BIDs
      that are not present in the binding cache of the mobile node the
      home agent MUST reject this flow binding add request by copying
      the flow identification option in the BA, and setting the Status
      field to TBD (BID not known).

      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
   option and it MUST include:



Soliman, et al.         Expires October 30, 2009               [Page 24]


Internet-Draft                Flow binding                    April 2009


      the FID as a key to the 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 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 is set to
   'Modify', it indicates a flow binding modification request.

   Note that flow binding modification is essentially a process where an
   existing flow binding is removed from the list of flow binding
   entries and a new flow binding (included in the option) is added, and
   given the same FID as the flow that was removed.

   If the value of the FID field of the flow identification option is
   not present in the binding cache entries for this mobile node, the
   home agent MUST reject this flow binding modify request by copying
   the flow identification option in the BA, and setting the Status
   field to 135 (FID not found).

   If the value of the FID field is present in the mobile nodes list of
   flow binding entries, the home agent SHOULD first remove the flow
   binding entry identified by the FID.  The home agent then SHOULD
   processes this flow identification option as defined in
   Section 5.3.2.1.

5.3.3.  Receiving BU with Flow Summary Option

   When the home agent receives a binding update which includes a Flow
   Summary option, it first performs the operation described in section
   10.3.1 of RFC3775.  Binding update messages including more than one
   flow summary option MUST be rejected.

   Home agents that do not support this specification will ignore the
   flow summary option, having no effect on the operation of the rest of
   the protocol.

   If the value of any of the FID fields included in the flow summary
   option is not present in the list of flow binding entries for this
   mobile node, the home agent MUST reject this flow binding modify
   request by including a flow identification option in the BA, and
   setting the FID field in the value of the FID that is not found and



Soliman, et al.         Expires October 30, 2009               [Page 25]


Internet-Draft                Flow binding                    April 2009


   the Status field to 135 (FID not found).

   If the value of the FID field is present in the mobile nodes list of
   slow binding entries the, home agent SHOULD refresh the binding entry
   identified by the FID 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 from a binding update.

   When a valid binding update is received, any registered FIDs that are
   not explicitly referred to in a flow identification option or in a
   flow summary option, 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
   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
   MUST be included in the Binding Acknowledgement message.
   Specifically, the home agent MUST copy each flow identification
   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
   option in the BA, SHOULD be set to 0 (Flow binding successful),
   otherwise it SHOULD be set to one of the rejection codes defined.
   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
   options to 130 (Administratively prohibited), or by just ignoring all
   the flow binding options.

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






Soliman, et al.         Expires October 30, 2009               [Page 26]


Internet-Draft                Flow binding                    April 2009


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
   [I-D.ietf-mext-nemo-v4traversal].  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 when [I-D.ietf-mext-nemo-v4traversal].

   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.4).  A match is
   attempted with the flow description included in the first line
   (highest order) of the table.  If the packet matches the flow
   description, the action defined by the action parameter of the table
   SHOULD be performed.

      - if the Action indicates 'Forward' the packet is forwarded to the
      care-of address indicated by the BID parameter in the same line of
      the table.

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

      - if the Action indicates 'n-cast', 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 needs 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" or
   "n-cast", the entry must indicated a BID.  For "n-cast" 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 n-casted to the
   other 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.4) and is skipped.
   In other words packets should not be matched against that entry.







Soliman, et al.         Expires October 30, 2009               [Page 27]


Internet-Draft                Flow binding                    April 2009


6.  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 option is part of the
   mobility header, it uses the same security as the Binding Update,
   whether it is sent to the home agent, correspondent node, or MAP.











































Soliman, et al.         Expires October 30, 2009               [Page 28]


Internet-Draft                Flow binding                    April 2009


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
   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 values below 128 are reserved
   for accept codes, and values from 128 and above are reserved for
   reject codes.

   Similar to the procedures specified for Mobile IPv6 [RFC3775] number
   spaces, future allocations from the two number spaces require Expert
   Review [RFC5226].

























Soliman, et al.         Expires October 30, 2009               [Page 29]


Internet-Draft                Flow binding                    April 2009


8.  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 October 30, 2009               [Page 30]


Internet-Draft                Flow binding                    April 2009


9.  Acknowledgements

   We would also like to acknowledge the following people in
   alphabetical order: C. Castelluccia, K. ElMalki, K. Georgios, , C.
   Goerg, T. Noel, F.-N.  Pavlidou, V. Park.  Gabor Fekete for the
   analysis that led to the inclusion of the BIDRef sub-option.  Henrik
   Levkowetz for suggesting support for other ways of describing flows.












































Soliman, et al.         Expires October 30, 2009               [Page 31]


Internet-Draft                Flow binding                    April 2009


10.  References

10.1.  Normative References

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

   [I-D.ietf-monami6-multiplecoa]
              Wakikawa, R., Devarapalli, V., Tsirtsis, G., Ernst, T.,
              and 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 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.

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







Soliman, et al.         Expires October 30, 2009               [Page 32]


Internet-Draft                Flow binding                    April 2009


Authors' Addresses

   Hesham Soliman
   Elevate Technologies

   Email: hesham@elevatemobile.com


   George
   Qualcomm

   Email: tsirtsis@gmail.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
   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 October 30, 2009               [Page 33]