Subject: RE: [netlmm] Solution proposal for accommodating multihomed IP nodes inPMIP6

From: "Alper Yegin" <[email-masked]>
Date: Wed, 17 Oct 2007 18:47:47 +0300

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

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 17 Oct 2007 08:56:32 -0700

> problem and associated complexity on the PMIP6 spec goes away... 

FWIW, I think the default mechanism should be for the LMA to manage
the prefixes. The home network prefixes allocated by the LMA are all
aggregated under the LMA. It does not make sense to store the
prefixes associated with all possible LMAs at the AAA home server.

Note that we do support HNP assignment via AAA in the base PMIPv6
specification. But it can't be the default.

Vijay

---

From: "Tsirtsis, George" <[email-masked]>
Date: Wed, 17 Oct 2007 09:10:15 -0700

Alper,

Could you explain why this might be so? Sorry if you have explained that
before.

Thanks
George

-----Original Message-----
From: Alper Yegin [mailto:[email-masked]] 
Sent: Wednesday, October 17, 2007 4:48 PM
To: Narayanan, Vidya; 'Netlmm'
Subject: RE: [netlmm] Solution proposal for accommodating multihomed IP
nodesinPMIP6

Folks,

Alper

---

From: Basavaraj Patil <[email-masked]>
Date: Wed, 17 Oct 2007 11:26:07 -0500

I agree with Vijay that it is the LMA which is responsible for the prefix
that is assigned to an MN. Having the prefixes of an LMA controlled by a AAA
is a deployment option but cannot be specified as "the" mechanism for prefix
assignment in the spec.

-Raj

---

From: "Alper Yegin" <[email-masked]>
Date: Wed, 17 Oct 2007 22:59:30 +0300

HNP belongs to a network.
A given LMA starts defending it on behalf of a MN only when a MAG asks the
LMA to do so (by sending a PBU).

So it is not like a HNP belongs to a LMA.

What's the value of assigning HNP in-band with PMIP? 

Alper

---

From: "Alper Yegin" <[email-masked]>
Date: Wed, 17 Oct 2007 23:05:26 +0300

George,

The issue we are dealing is the HNP assignment to PMIP6 sessions.
If the HNP is assigned via network access AAA procedures, then the PMIP6
protocol does not have to deal with this scheme below at all. The PMIP6 spec
gets simplified.

And it is relatively easier for AAA to deal with that. AAA already knows the
technology type for a given access, it already knows what other networks the
MN is currently connected to, and it has the ability to shut down one or
more of the access sessions.

Alper

> From: Tsirtsis, George [mailto:[email-masked]]
> Sent: Wednesday, October 17, 2007 7:10 PM
> To: Alper Yegin; Narayanan, Vidya; Netlmm

---

From: Basavaraj Patil <[email-masked]>
Date: Wed, 17 Oct 2007 15:25:32 -0500

> HNP belongs to a network.

A prefix is owned by an LMA.

> LMA to do so (by sending a PBU).

The LMA is the one that assigns the prefix. The MAG requests the LMA to
assign a prefix or an MN.

> So it is not like a HNP belongs to a LMA.

IMO, it does.

> What's the value of assigning HNP in-band with PMIP?

Because the prefix is owned by the LMA and hence assigned to an MN as part
of PMIP signaling.

-Raj

---

From: "Sri Gundavelli" <[email-masked]>
Date: Wed, 17 Oct 2007 13:41:00 -0700

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

> Sent: Wednesday, October 17, 2007 8:48 AM
> Subject: RE: [netlmm] Solution proposal for accommodating 
> multihomed IP nodesinPMIP6
> 
> Folks,
>

---

From: Frank Xia <[email-masked]>
Date: Wed, 17 Oct 2007 18:00:50 -0500

Hi Sri

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

> restricting it to one specific way of address assignment.

Frank=>
I think that how LMA allocates prefixes to MN should be in the scope
of the basic protocol. But , how LMA get the prefix from external entities or local prefix pool should
be out the scope of the protocol.

So it is not necessary to do any restriction.
> > multihomed IP

---

From: "Ved Kafle" <[email-masked]>
Date: Thu, 18 Oct 2007 10:43:52 +0900

Alper,

Don't we think that LMA advertises the agregated prefix, not the
individual prefix assigned to each mobile node?
If so, the prefix assignment/selection/approval decision should rest in
the LMA, although the AAA may suggest one.

Ved

> Sent: Thursday, October 18, 2007 5:00 AM
> To: 'Basavaraj Patil'; 'Vijay Devarapalli'
> Cc: 'Netlmm'
> A given LMA starts defending it on behalf of a MN only when a 
> MAG asks the LMA to do so (by sending a PBU).
> 
> > I agree with Vijay that it is the LMA which is responsible for the 
> > prefix that is assigned to an MN. Having the prefixes of an LMA 
> > controlled by a AAA is a deployment option but cannot be 
> specified as 
> > "the" mechanism for prefix
> > assignment in the spec.
> > 
> > -Raj
> > 
> > 
> > >> 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...
> > >
> > >>> multihomed
> > IP
> > >>> Do we still have to deal with a "logic" like this if we perform 
> > >>> HNP assignment only via AAA?
> > >>>
> > >>> Alper
> > >>>
> > >>>> Subject: [netlmm] Solution proposal for accommodating 
> multihomed 
> > >>>> IP
> > >>> nodes
> > >>>> inPMIP6
> > >>>>
> > >>>>
> > >>>> All,
> > >>>> After discussion, we have settled on a solution that all the 
> > >>>> people
> > on
> > >>>> 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
> > >>>>
> > >>>> 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
> > >>>> - 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.
> > >>>> using which the MN connects to the MAG (e.g., Ethernet, WLAN, 
> > >>>> IPsec, PPP, LTE, etc.).  This is a mandatory field.
> > >>>> 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
> > >>>> 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
> > >>>> ID stored for a given BCE (for a given MN ID), it MUST update 
> > >>>> that
> > BCE
> > >>>> 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
> > >>>> given MN ID and the HI field is set to "no 
> information", the LMA
> > SHOULD
> > >>>> 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.
> > >>>> 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
> > >>>>
> > >>>> interface ID value, the LMA MUST assign a new HNP 
> corresponding 
> > >>>> to
> > the
> > >>>> incoming PBU
> > >>>> 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
> > >>>> and the HI field is set to "no handoff", the LMA MUST assign a 
> > >>>> new
> > HNP
> > >>>> 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.
> > >>>>
> > >>>> "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.
> > >>>>
> > >>>>
> > >>>> [email-masked] https://www1.ietf.org/mailman/listinfo/netlmm
> > >>
> > >>
> > >>
> > >> [email-masked] https://www1.ietf.org/mailman/listinfo/netlmm
> > >
> > >
> > >
> > > [email-masked] https://www1.ietf.org/mailman/listinfo/netlmm
> 
> 
> 
>

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Thu, 18 Oct 2007 07:50:20 -0500

Hi Frank,

> of the basic protocol. But , how LMA get the prefix from 
> external entities or local prefix pool should

[Ahmad]
I do not understand what you mean here, could you please elaborate a
little more? 
Also, how your comment is related to the discussion.

> > > documenting this in the
> > > document once there
> > > situation, the same
> interface ID and a
> > > received PBU.
> > > SHOULD wait for a
> > > accepting the new PBU
> > > parameters with an

---

From: "Alper Yegin" <[email-masked]>
Date: Thu, 18 Oct 2007 22:27:25 +0300

I presume people would agree that we cannot assume there is a single LMA for
a whole domain. It is likely that multiple LMAs would be serving a PMIP6
domain.

And I presume people also agree that we are talking about identity-based HNP
assignment. Not random assignment. 

Let's go with the assumption that each HNP is pre-assigned to exactly one
LMA... like folks are claiming.

So, when the MAG needs to send the PBU, how does it know which one of the
LMAs it shall send it to? Well, the AAA tells MAG the target LMA. The AAA
cannot be telling the id of the LMA without knowing the HNP to be assigned
and which LMA that HNP is currently pre-assigned to. 

See, it comes back to AAA knowing the HNP.

So, why not the AAA tell the MAG the HNP as well?

That way LMAs and HNPs are not coupled via pre-assignment, which is less
efficient and less manageable.  And I'm also under the impression that a lot
of problems associated with in-band HNP assignment go away (the problem that
currently requires a multi-dimensional ID representation).

Alper

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Thu, 18 Oct 2007 12:50:37 -0700

Hi Alper,
There is no requirement on even having a AAA infrastructure in place to
deploy PMIP.  So, tying address assignment to AAA is not in the scope of
the base spec.  It is certainly possible that a given deployment may
choose to use the AAA for this purpose, but, this cannot be a
requirement on the protocol. 

Regards,
Vidya 

> Sent: Thursday, October 18, 2007 12:27 PM
> To: 'Netlmm'
> I presume people would agree that we cannot assume there is a 
> single LMA for a whole domain. It is likely that multiple 
> LMAs would be serving a PMIP6 domain.
> 
> And I presume people also agree that we are talking about 
> identity-based HNP assignment. Not random assignment. 
> 
> Let's go with the assumption that each HNP is pre-assigned to 
> exactly one LMA... like folks are claiming.
> 
> So, when the MAG needs to send the PBU, how does it know 
> which one of the LMAs it shall send it to? Well, the AAA 
> tells MAG the target LMA. The AAA cannot be telling the id of 
> the LMA without knowing the HNP to be assigned and which LMA 
> that HNP is currently pre-assigned to. 
> 
> That way LMAs and HNPs are not coupled via pre-assignment, 
> which is less efficient and less manageable.  And I'm also 
> under the impression that a lot of problems associated with 
> in-band HNP assignment go away (the problem that currently 
> requires a multi-dimensional ID representation).
> 
> 
> Alper
> 
> 
> 
>

---

From: Jari Arkko <[email-masked]>
Date: Thu, 18 Oct 2007 16:17:55 +0300

> individual prefix assigned to each mobile node?

Indeed it must do this. It would be a non-starter to ask for the LMAs to
advertise prefixes for each individual mobile node in a routing
protocol, and I would advise the WG to not go there. It might work under
some circumstances within a domain, but definitely not in roaming
situations.

Jari

---

From: Jari Arkko <[email-masked]>
Date: Thu, 18 Oct 2007 16:47:07 +0300

> more of the access sessions.

Does it matter if the MN is connected to other netlmm domains? It would
seem not.

But what's more important is that AAA would appear to be even further
away from the handover processes that would enable it to know whether
the mobile node is truly moving or not. It could certainly perform the
same disconnect operations, but its not clear that they are preferred
over what is done in the netlmm domain itself.

AAA might be blissfully unaware of Netlmm, what would happen then? And,
AAA is not any wiser about the hardware and software configuration of a
host than netlmm domain is, perhaps less so.

Jari

---

From: "Alper Yegin" <[email-masked]>
Date: Fri, 19 Oct 2007 12:00:39 +0300

Vidya,

Actually we don't have to name AAA. We can say that HNP is assigned out-of
band. 

There are already few things happening out-of band.
For example, how does MAG discover the LMA for the given MN?
How does the LMA authorize the MAG for sending a (P)BU on behalf of the
given MN?

I'd say these are taken care of by the AAA. But if you want to be more
open-minded in the base spec, you can classify this as the "out-of band"
mechanism, and not lock-in to AAA.

So, what I'm saying is, if the out-of band mechanism is doing those things,
it can also perform HNP assignment.

Alper

> Sent: Thursday, October 18, 2007 10:51 PM
> To: Alper Yegin; Netlmm

---

From: "Alper Yegin" <[email-masked]>
Date: Fri, 19 Oct 2007 12:06:46 +0300

Jari,

> over what is done in the netlmm domain itself.

What is the entity doing the disconnects in the Netlmm domain? 

In my proposal, as the HNP is assigned by the AAA, when the AAA assigns the
same HNP to another interface of the MN, it shall also generate the
disconnect towards the previous interface attachment.

> host than netlmm domain is, perhaps less so.

Again you are referring to "netlmm domain" but not sure I understand what
that entity (who knows about host configuration) is. 

Alper