Subject: Re: [netlmm] Solution proposal for accommodating multihomed IP nodesinPMIP6

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 18 Oct 2007 09:22:36 -0700 (PDT)

Hello Sri,
  Overall I agree with your comments 
However, if you go into the details, as you know the devil is in the details.
You said:
the general Mobile IP concept of HA managing the address assignment 
which is correct but as you know RFC 3775 (Base MIPv6) does not assign HoA's to MNs. Bootstrapping extensions to the base spec had to be developed to deal with this problem.

If we are going to deal with HNP assignment in such a detail as proposed in the solution text then why not add AAA assignment, and many other ways of dealing with it? 

So OK to LMA assigning HNPs as currently we have in the draft version 6. 

Regards,

Behcet

----- Original Message ----
From: Sri Gundavelli <[email-masked]>
To: Alper Yegin <[email-masked]>; Netlmm <[email-masked]>
Sent: Wednesday, October 17, 2007 3:41:00 PM
Subject: RE: [netlmm] Solution proposal for accommodating multihomed IP nodesinPMIP6

Hi Alper,

LMA is the topological anchor point for the mobile node
prefixes and it is logical that it manages the prefix
assignment function. When we are looking at LMA to scale
to millions of sessions, it is important we allow it to use
what ever backend schemes, including DHCP PD as per 3633,
or other means. This is one way of address management. 
The spec certainly allows the prefix assignment through
MN's policy profile or a AAA based approach could also be
plugged in as well. This also aligns with the general
Mobile IP concept of HA managing the address assignment and
is inline with specs such as Mobile Network Prefix Delegation
drafts in NEMO WG. I do not know, if there is any value in
restricting it to one specific way of address assignment.

Regards
Sri

> -----Original Message-----
> From: Alper Yegin [mailto:[email-masked]] 
> Sent: Wednesday, October 17, 2007 8:48 AM
> To: 'Narayanan, Vidya'; 'Netlmm'
> Subject: RE: [netlmm] Solution proposal for accommodating 
> multihomed IP nodesinPMIP6
> 
> Folks,
> 
> If we always assign the HNP via AAA, I'm under the impression 
> that this
> problem and associated complexity on the PMIP6 spec goes away... 
> 
> Is that not so? Am I missing something?
> 
> 
> Alper
> 
> > -----Original Message-----
> > From: Alper Yegin [mailto:[email-masked]]
> > Sent: Tuesday, October 16, 2007 11:50 AM
> > To: 'Narayanan, Vidya'; 'Netlmm'
> > Subject: RE: [netlmm] Solution proposal for accommodating 
> multihomed IP
> > nodes inPMIP6
> > 
> > 
> > Do we still have to deal with a "logic" like this if we perform HNP
> > assignment only via AAA?
> > 
> > Alper
> > 
> > > -----Original Message-----
> > > From: Narayanan, Vidya [mailto:[email-masked]]
> > > Sent: Tuesday, October 16, 2007 12:12 AM
> > > To: Netlmm
> > > Subject: [netlmm] Solution proposal for accommodating 
> multihomed IP
> > nodes
> > > inPMIP6
> > >
> > >
> > > All,
> > > Jonne, Jari and myself had a call with some of the key 
> people involved
> > > in the two solution proposals to see if common ground can 
> be achieved.
> > > After discussion, we have settled on a solution that all 
> the people on
> > > the call could agree upon.  The following write-up captures that
> > > discussion.  Please review and comment on it.
> > >
> > > If there is consensus, we will move forward with 
> documenting this in the
> > > base spec.  Please note that this write-up only captures 
> the concept in
> > > reasonable detail for discussion purposes and the authors 
> will work on
> > > the exact wording and details to be captured in the 
> document once there
> > > is agreement.
> > >
> > > Thanks,
> > > Vidya
> > >
> > > -------------------------------------------------------
> > >
> > > The goal is to limit the assignment of a given prefix to 
> one interface
> > > of an MN at a time.  In other words, when multiple interfaces are
> > > simultaneously in use on an MN, different prefixes should 
> be assigned to
> > > each of those interfaces.  However, in a handoff 
> situation, the same
> > > prefix may be assigned to a different interface (with the 
> understanding
> > > that the other interface is either shut down or not using 
> this prefix).
> > >
> > >
> > > - The MAG carries the following pieces of information in 
> the PBU to the
> > > LMA - the MN ID, the access technology type, an interface ID and a
> > > Handoff Indicator (HI) field.
> > >     - The MN ID may be the NAI or anything else that identifies the
> > > MN uniquely in the PMIP domain (as currently specified in 
> the document).
> > > This is a mandatory field.
> > >     - The access technology type indicates the access technology
> > > using which the MN connects to the MAG (e.g., Ethernet, 
> WLAN, IPsec,
> > > PPP, LTE, etc.).  This is a mandatory field.
> > >     - The interface ID uniquely identifies the interface of the MN
> > > and is typically an L2 identifier (e.g., MAC address, 
> Link ID, etc.).
> > > When no interface ID is available for a given access 
> technology, this
> > > field is set to 0 (or omitted, if defined as an option).  When an
> > > interface ID is available, it MUST be present in the PBU.
> > >
> > > - The Handoff Indicator (HI) field** in the PBU indicates 
> if the PBU is
> > > meant for an interface that is a handoff from a different 
> interface
> > > corresponding to an existing BCE
> > >     - When the new MAG is aware of the handover, it sets this field
> > > to indicate a "handoff"; when the new MAG knows that this PBU is
> > > unrelated to other interfaces of the MN, it sets it to 
> "no handoff" or
> > > "distinct interface"; when the new MAG has no 
> information, it sets it to
> > > "no information"
> > >     - When this field is set to "no information" and the situation
> > > is actually a handoff case, the old MAG should send a 
> deregistration PBU
> > > with this field set to "handoff" for the LMA to accept 
> the PBU from the
> > > new MAG with the same HNP assignment; if not, a new HNP 
> must be assigned
> > > for that PBU
> > >
> > > - The LMA, upon receiving a PBU, does the following:
> > >
> > > Case 1: Interface ID is present in the PBU:
> > >
> > >     - If the interface ID contained in the PBU matches the interface
> > > ID stored for a given BCE (for a given MN ID), it MUST 
> update that BCE
> > > with the new PBU and keep the HNP associated with that BCE
> > >     - If the interface ID is different from an existing BCE for a
> > > given MN ID and the HI field is set to "no handoff", it 
> MUST assign a
> > > new HNP for the interface and create a new BCE for the HNP
> > >     - If the interface ID is different from an existing BCE for a
> > > given MN ID and the HI field is set to "no information", 
> the LMA SHOULD
> > > wait for a deregistration message for an existing BCE 
> before accepting
> > > the new PBU with the same HNP; if no deregistration is 
> received within a
> > > given time, the LMA SHOULD assign a new prefix for the 
> received PBU.
> > > The LMA MAY assign a new HNP and accept the PBU without 
> waiting for a
> > > deregistration message.
> > >     - If the interface ID is different from an existing BCE for a
> > > given MN ID and the HI field is set to "handoff", the LMA 
> MUST assign
> > > the same HNP associated with the BCE corresponding to the 
> old interface
> > > and update the BCE
> > >
> > > Case 2: No interface ID is present in the PBU:
> > >
> > >     - If there is no corresponding BCE for that MN ID with a NULL
> > > interface ID value, the LMA MUST assign a new HNP 
> corresponding to the
> > > incoming PBU
> > >     - If there is a BCE with NULL interface ID value for that MN ID
> > > and the HI field is set to "handoff", the LMA MUST assign 
> the same HNP
> > > associated with the BCE corresponding to the old 
> interface and update
> > > the BCE
> > >     - If there is a BCE with NULL interface ID value for that MN ID
> > > and the HI field is set to "no handoff", the LMA MUST 
> assign a new HNP
> > > corresponding to the incoming PBU
> > >     - If there is a BCE with NULL interface ID value for that MN ID
> > > and the HI field is set to "no information", the LMA 
> SHOULD wait for a
> > > deregistration message for an existing BCE before 
> accepting the new PBU
> > > with the same HNP; if no deregistration is received 
> within a given time,
> > > the LMA SHOULD assign a new prefix for the received PBU.  
> The LMA MAY
> > > assign a new HNP and accept the PBU without waiting for a 
> deregistration
> > > message.
> > >
> > > How the LMA is notified about a handoff situation for 
> address continuity
> > > is out of scope of the specification.  This may be based 
> on L2 triggers
> > > or other means that may be defined by the appropriate SDO 
> or deployment.
> > > With such information, the LMA must treat it an interface as a
> > > "distinct" one, unless there is an exact match of 
> parameters with an
> > > existing BCE.
> > >
> > > One other point to note here is that a given PMIP session 
> is now tied to
> > > the tuple {MN-ID, Interface ID, Access technology type} 
> and not just to
> > > the MN-ID; there may be only one HNP associated with any 
> unique value of
> > > the tuple, but, multiple HNPs (and hence, BCEs) 
> corresponding to the
> > > same MN-ID itself.
> > >
> > >
> > > _______________________________________________
> > > netlmm mailing list
> > > [email-masked]
> > > https://www1.ietf.org/mailman/listinfo/netlmm
> 
> 
> 
> _______________________________________________
> netlmm mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/netlmm

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

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

---

From: Sri Gundavelli <[email-masked]>
Date: Thu, 18 Oct 2007 09:32:32 -0700 (PDT)

Hi Behcet/Frank,

> So OK to LMA assigning HNPs as currently we have in the draft version 6.

Yes. What ever is currently specified in the draft. The draft
does not specify the semantics or the interface to a prefix
database ,local pools, ODAP, DHCP PD .., or what ever. It
just requires the LMA to be able to allocate a prefix. How it
manages that aspect, is not our business for now. So, this
is not stepping on any of your related work on that part. So,
no worries !

Thanks
Sri