Subject: Re: [netlmm] Proposed text for multihoming

From: Behcet Sarikaya <[email-masked]>
Date: Mon, 8 Oct 2007 14:58:02 -0700 (PDT)

Hi Jonne,
  What happened to the consensus call? It seems like we only have the text below to choose from. Are we voting on this text?
  Regards,

Behcet

----- Original Message ----
From: Basavaraj Patil <[email-masked]>
To: [email-masked]
Sent: Saturday, October 6, 2007 11:33:10 PM
Subject: [netlmm] Proposed text for multihoming

Hello,

The issue about multihoming of hosts has caused significant discussion but
no real resolution yet. We still believe that capturing the issues w.r.t
PMIP6 for multihomes hosts and guidelines should be sufficient in the
context of the current draft. A complete solution to the multihoming issue
in the PMIP6 context should be done as a separate specification.

However in the interest of making progress, we are proposing the following
text below describing multihoming. We hope that the following text will be
sufficient for the base protocol specification and allow us to move forward.

-Basavaraj
==============================================

Terminology:

Multihomed MN      
           
      A mobile node (MN) which connects via multiple interfaces to
      access networks simultaneously and has a valid and routable
      IP address assigned to each of the interfaces is defined as
      a multihomed MN.

Sec X.Y Multihomed mobile nodes

  A mobile node with multiple interfaces may connect via these
  interfaces to the access networks  simultaneously. The access
  router to which the MN attaches via an interface may be a MAG in a
  PMIP domain. When the MN attaches to a MAG and completes access
  authentication, the MAG sends a Proxy Binding update (PBU) to the
  appropriate LMA. The LMA creates an entry in the binding cache upon
  successful processing of the PBU and sends a Proxy Binding
  Acknowledgment (PBAck) to the MAG. Several multihoming scenarios in
  the context of PMIP6 are considered below:

  Scenario 1:

  A Mobile Node (MN) with interfaces IFx and IFy attaches to a PMIP6
  domain via MAGx and MAGy. The MN-ID used to identify the MN on each
  of the interfaces is unique. The LMA assigned to the MN on
  interfaces IFx and IFy is the same. The LMA which receives a PBU
  from MAGx and MAGy with unique MN-IDs assigns a unique prefix to
  each of the interfaces and sends this in the PBAck to the respective
  MAGs. The LMA creates separate binding entries for each of the
  prefixes in the binding cache. The MN which receives the prefixes
  via an RA from MAGx and MAGy on interfaces IFx and IFy will configure
  a unique address for each interface and operate as a multihomed host.

  Scenario 2:
  
  A Mobile Node (MN) with interfaces IFx and IFy attaches to a PMIP6
  domain via MAGx and MAGy. The MN-ID used to identify the MN on each
  of these interfaces is the same. If the MN attaches to the network
  via IFx first, the LMA has an entry for the MN in the binding cache
  for MAGx. If the MN attaches via IFy to MAGy, it will send a PBu to
  the LMA. The LMA can determine if the PBU being received which has
  the same MN-ID is from a different interface of the MN via the
  Access network technology type option included in the PBU which is
  defined 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
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |      Type     |   Length      |AccessTech Type|  Prefix Len   |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                                                               |
  +                                                               +
  |                                                               |
  +                    Home Network Prefix                        +
  |                                                               |
  +                                                               +
  |                                                               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    Access Tech Type:
          0          Reserved
          1        802.3
          2          803.11
          3          802.16e
          4          PPP

    Values 1-127 will be allocated by IANA. Values 128-256 are reserved
    for private use.

   The Access technology type option in the PBU provides the LMA with
   additional information via which it can choose the prefix to be
   sent to the MN via the PBAck. The prefix that is sent to the MN is
   based on the LMA policy. If the LMA had assigned prefix Px to the
   MN via MAGx to interface IFx, it can assign the same prefix Px to
   the MN via MAGy to interface IFy when the MN attaches via IFy. The
   LMA can also assign a different prefix to each of the intefaces.
   The decision of which prefix to assign is a policy of the LMA. The
   LMA may take in to account information about the mobile node before
   making a decision.

   In the scenario where the LMA assigns the same prefix (as assigned
   to the MNs interface IFx via MAGx) to the MNs interface IFy via
   MAGy, the LMA will replace the binding cache entry from MAGx to
   MAGy. The address configured by the MN which receives the prefix is
   MN implementation specific. The MN is unaware of MAGx no longer
   being a valid downlink node. It may continue to use IFx for sending
   packets on the uplink. MAGx may forward the packets to the LMA. The
   behavior of the LMA in the case of receiving packets from an MN via
   MAGx which is no longer in the binding cache can vary:
   - It can drop the packets or
   - It can forward them for a brief duration of time (configurable
   value)
   Hence the multihomed MN may be able to send packets via either
   interface for a brief period of time. It is possible in the future
   that the LMA can send a binding revocation notification to MAGx
   when it successfully processes a PBU from MAGy and prior to
   swapping the BCE from MAGx to MAGy for MN which is identified by
   MN-ID. It is possible that an MN which connects via multiple
   interfaces to a PMIP6 domain may have only a single valid interface
   for the transmission of packets. Any ongoing IP session via a previous
   interface may be affected.

   In some scenarios, MAGx and MAGy may keep sending PBUs to the LMA
   as a result of which there is oscillation of the BCE in the LMA
   between the MAGs. In this case, the LMA, when it detects this
   oscillation, starts rejecting the Proxy Binding Updates from one
   of the MAGs.  The mobile node will have connectivity through only
   one MAG. This issue can be mitigated via the use of binding
   revocation mechanism [draft-muhanna], which would help in the LMA
   detecting the oscillation quickly.

_______________________________________________
netlmm mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/netlmm

_______________________________________________
netlmm mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/netlmm