Subject: [netext] Comments on I-D: draft-wolfner-netext-pmip6-connid-00

From: <[email-masked]>
Date: Wed, 15 Jul 2009 23:33:42 +0200

Hello,

A few questions/comments related to the proposal to add a connection
identifier to the PMIP6 signaling and BCE:

1. Each of the PDN bearers will have a unique prefix assigned to it by
   the LMA, right? Even though the MN-ID remains the same the LMA will
   have to create multiple BCEs for the MN. The scenario is equivalent
   to the MN attaching via different interfaces thru the same MAG/LMA
   pair. 
   
2. The I-D says that the mechanism by which the MAG figures out that
   a new bi-directional tunnel is needed to be established (and a new
   prefix obtained) is out of scope. In certain networks you are
   obtaining this information from L2 and is used by the MAG. Current
   RFC5213 lacks the ability by which an MN (which is already attached
   via an interface) can request dynamically a new prefix to be
   assigned to it for the same interface. The connection ID would be
   useful if we were to also specify how the MN can request an
   additional prefix via an interface that is already attached and has
   been assigned a prefix from a MAG/LMA pair.
   It might be useful to explain how L2s can provide such indications in an
appendix.

3. In the case of HO the target MAG will not be aware of the CID
   unless there a context transfer mechanism between the MAGs. Please
   note the I-D draft-ietf-mipshop-pfmipv6-08.txt which proposes
   context transfer capability between MAGs.

4. If each PDN bearer is assigned a unique prefix, can you not use the
   HNP assigned as the CID?

I do agree with the need to support the ability by which multiple
mobility sessions to the same LMA (via the same MAG) from a single
interface is needed. This is applicable in EPC and other networks
which use PMIP6. 

-Raj

---

From: jouni korhonen <[email-masked]>
Date: Thu, 16 Jul 2009 15:49:16 +0300

Hi Raj,

Thanks for the quick review. I got some answer inline.

On Jul 16, 2009, at 12:33 AM, <[email-masked]> <[email-masked] 
 > wrote:

>   the LMA, right? Even though the MN-ID remains the same the LMA will

right.

>   to the MN attaching via different interfaces thru the same MAG/LMA

To some extent it is the same. However, the introductory text the  
draft scopes the work to a single interface. Maybe there is a way to  
express the whole solution independent of the number of interfaces.

>   obtaining this information from L2 and is used by the MAG. Current

Correct.

>   It might be useful to explain how L2s can provide such indications  

Good point. We'll add this.

>   context transfer capability between MAGs.

I'll have a look at this.

> 4. If each PDN bearer is assigned a unique prefix, can you not use the

Actually, this would be the clean solution. The problem is that is the  
MN has multiple mobility sessions to the same service, the target MAG  
(after a handover) does not necessarily know which of those sessions  
the MN wants to use and in which order. Once the MN reattaches to MAG,  
which initiates the PBU/PBA exchange, there is no prefix information  
available from the MN side yet.. however, most probably the L2 has  
some additional information that the MAG and the LMA can use to make  
the distinction. We do not really define what this L2 information is  
and how to retrieve it, but still we need a mechanism to transfer that  
around and take into account when doing BC lookups.

> interface is needed. This is applicable in EPC and other networks

Cheers,
	Jouni

>
> _______________________________________________
> netext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netext

---

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 16 Jul 2009 07:42:38 -0700 (PDT)

Hi Raj,
  It seems to me that you are talking about prefix management. 
This issue of requesting prefixes etc. falls into how LMA should manage prefixes. These issues can be seen as different aspects of what we cover in 
http://tools.ietf.org/id/draft-sarikaya-netext-prefix-delegation-00.txt

  Regards,

Behcet

----- Original Message ----
> From: "[email-masked]" <[email-masked]>
> To: [email-masked]
> Sent: Wednesday, July 15, 2009 4:33:42 PM
> Subject: [netext] Comments on I-D: draft-wolfner-netext-pmip6-connid-00
> 
> 
> 
> Hello,
>

---

From: <[email-masked]>
Date: Thu, 16 Jul 2009 22:17:05 +0200

Inline:

>   It seems to me that you are talking about prefix management.

Not really. 
The concept of a connection identifier is different from prefix management.
The connid I-D is proposing a solution which enables the establishment of
multiple mobility sessions via the same MAG/LMA pair. Each of the mobility
sessions is assigned an HNP. But the concept of connection ID is different
from prefix management.

-Raj

> This issue of requesting prefixes etc. falls into how LMA should manage
> prefixes. These issues can be seen as different aspects of what we cover in

---

From: <[email-masked]>
Date: Thu, 16 Jul 2009 22:26:28 +0200

Hi Jouni,

Response inline:

> express the whole solution independent of the number of interfaces.

I believe there is no problem in establishing a new mobility session when
the MN attaches via a second interface. However there is currently no way to
establish multiple mobility sessions via a single interface. I think there
is a need to solve this issue. It would be useful to explicitly state the
intent of enabling multiple mobility sessions via a single interface in the
I-D. 

> the MN wants to use and in which order.

So the assumption is that only a selective set of mobility sessions would be
activated when the MN does a HO to a new MAG?

> Once the MN reattaches to MAG,

Okay... Obviously this will require the ability by which the MN can inform
the MAG about which mobility sessions to activate. If it is essentially
information that is being delivered at L2 and used by the MAG to trigger the
mobility sessions, it is still conformant to the PMIP6 protocol design
principle which limits (or actually forbids) signaling between the MN and
MAG.
Based on the Connection ID in the PBU, the LMA would respond with the
approriate HNP which is in the BCE.

I think this extension is something we can discuss at the WG meeting in
Stockholm.

-Raj

---

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 16 Jul 2009 13:51:19 -0700 (PDT)

----- Original Message ----
> To: [email-masked]; [email-masked]
> Sent: Thursday, July 16, 2009 3:17:05 PM
> Subject: Re: [netext] Comments on I-D: draft-wolfner-netext-pmip6-connid-00
> 
> 
> Inline:
> 
> 
> On 7/16/09 9:42 AM, "ext Behcet Sarikaya" wrote:
> 
> > 
> > 
> > Hi Raj,
> sessions is assigned an HNP.

First of all let's clarify this as HNPs.

 But the concept of connection ID is different
> from prefix management.

The way draft-wolfner-netext-pmip6-connid-00 currently presents it, yes. 

But as per your interpretation, this is basically treating as MN like many MNs for which requests will be made to the prefix management at the LMA. 

It makes it more important to have manage prefixes, I think. 

Regards,

Behcet

---

From: Behcet Sarikaya <[email-masked]>
Date: Fri, 17 Jul 2009 08:13:40 -0700 (PDT)

Hi Jouni, Raj,
  After a little bit of reflection I started to question this connid extension.

RFC 5213 clearly makes it possible to assign multiple unique HNPs to each MN (see Sec. 8.3). 

So I think that the base protocol already enables multiple pdp context stuff. It is upto certain MNs to use it. 

I don't think we need a standard to add things like connid into the BCE and complicate things.

What do you think?

Behcet

----- Original Message ----
> From: jouni korhonen <[email-masked]>
> To: "<[email-masked]>" <[email-masked]>
> Cc: [email-masked]
> Sent: Thursday, July 16, 2009 7:49:16 AM
> On Jul 16, 2009, at 12:33 AM, 
> wrote:
> 
> > 
> > 
> > Hello,
> > 
> To some extent it is the same. However, the introductory text the draft scopes 
> the work to a single interface. Maybe there is a way to express the whole 
> solution independent of the number of interfaces.
> 
> > 
> > 2.. The I-D says that the mechanism by which the MAG figures out that
> Actually, this would be the clean solution. The problem is that is the MN has 
> multiple mobility sessions to the same service, the target MAG (after a 
> handover) does not necessarily know which of those sessions the MN wants to use 
> and in which order. Once the MN reattaches to MAG, which initiates the PBU/PBA 
> exchange, there is no prefix information available from the MN side yet.. 
> however, most probably the L2 has some additional information that the MAG and 
> the LMA can use to make the distinction. We do not really define what this L2 
> information is and how to retrieve it, but still we need a mechanism to transfer 
> that around and take into account when doing BC lookups.
> 
> >

---

From: <[email-masked]>
Date: Fri, 17 Jul 2009 17:58:06 +0200

Hi Behcet,

It is possible to assign multiple HNPs to an MN via RFC5213. However it is
not possible to request dynamically (after initial attachment and being
assigned an HNP and a BCE created) a new mobility session.
The LMA would essentially view a new PBU request from the MAG for the MN as
being a renewal request and hence not assign a new HNP. I think it is clear
(at least in the 3GPP EPC context) that it with RFC5213 it is not possible
to establish multiple mobility sessions with the same LMA via a single
interface.

-Raj

---

From: Behcet Sarikaya <[email-masked]>
Date: Fri, 17 Jul 2009 09:17:46 -0700 (PDT)

Hi Raj,

----- Original Message ----
> To: [email-masked]; [email-masked]
> Cc: [email-masked]
> Sent: Friday, July 17, 2009 10:58:06 AM

Yes, I think it is clear. The question is do we want to change it? 
I think sending a non-renewal PBU is a big semantic change to the base protocol.
I was thinking that such a thing could happen below PMIP level possibly using the other prefix. I don't know what would you say to that?

Regards,

Behcet

---

From: <[email-masked]>
Date: Fri, 17 Jul 2009 18:36:02 +0200

> Yes, I think it is clear. The question is do we want to change it?

Yes. Extend the capability by which the LMA is aware that the PBU is a
request for establishing a new mobility session.

> I think sending a non-renewal PBU is a big semantic change to the base

Not really. A PBU can indicate already whether it is a result of a HO or a
renewal or the result of a new attachment via a different interface.

> I was thinking that such a thing could happen below PMIP level possibly using
> the other prefix. I don't know what would you say to that?

Not sure what you mean by "below PMIP level". Maybe you have some other
ideas of how to achieve the same functionality. Also I don't understand what
you mean by "the other prefix". What other prefix are you refering to? When
the MN requests an additional mobility session, there is no prefix assigned
to it yet.

-Raj

---

From: Behcet Sarikaya <[email-masked]>
Date: Fri, 17 Jul 2009 11:36:09 -0700 (PDT)

----- Original Message ----
> Sent: Friday, July 17, 2009 11:36:02 AM
> On 7/17/09 11:17 AM, "ext Behcet Sarikaya" wrote:
> 
> > 
> > 
> > Hi Raj,
> > 
> > 
> > 
> >> From: "[email-masked]" 

That's what I was referring to as a big semantic change to PBU/PBA.

> the MN requests an additional mobility session, there is no prefix assigned

PBA sends more than one prefixes to MAG and MAG advertizes them. What does MN do?

I think hosts create addresses for each prefix they receive.

So my suggestion was to use a different address for each PDP connection. In fact you need a single address to access the Internet. More than one addresses create problems that MIF WG is trying to address.

Regards,

Behcet

---

From: jouni <[email-masked]>
Date: Sun, 19 Jul 2009 23:36:46 +0300

Hi Behcet,

On Jul 17, 2009, at 9:36 PM, Behcet Sarikaya wrote:

[snip]

> That's what I was referring to as a big semantic change to PBU/PBA.

It is a change but I would not call it semantic change. Similar type  
of extensions what you already have e.g. with RFC5149. What the I-D  
adds here is more detail and a new key to help with lookups to binding  
cache (obviously adds more data to binding cache entries as well) when  
you want to identify exactly one of several mobility sessions without  
really knowing its assigned HNP.

>>
>>> I think sending a non-renewal PBU is a big semantic change to the  
>>> base
>>> protocol.
>>

If it is a case that PBA contains more than one HNP. This is, however,  
always not the case.

> So my suggestion was to use a different address for each PDP  
> connection. In fact you need a single address to

Eh? In this particular example, each PDN connection already has a  
different HNP. The issue is that the HNP information is not enough, or  
merely not available, when a link gets set up after a handover.

> access the Internet. More than one addresses create problems that  
> MIF WG is trying to address.

This is a completely different discussion imho.

Cheers,
	Jouni

---

From: jouni korhonen <[email-masked]>
Date: Mon, 20 Jul 2009 10:36:41 +0300

Hi Raj,

On Jul 16, 2009, at 11:26 PM, <[email-masked]> <[email-masked] 

[snip]

> I think this extension is something we can discuss at the WG meeting  

Is there a presentation slot for this in the agenda? I did not spot it.

Cheers,
	Jouni

---

From: Xiangsong Cui <[email-masked]>
Date: Tue, 21 Jul 2009 12:11:44 +0800

Hi Jouni,

I also wonder at the motivation.

> Similar type  

Yes, RFC5149 introduces some extensions, we can accept the 
extension because there are many use cases.
Can you give us some use case too?

>From the draft, it says:
"  However, in a case of multiple PDN
   connections to the same APN, and assuming that Home Network Prefixes
   (HNP) are not always available in a Mobile Access Gateway (MAG) after
   a handover and that the "APN name" in the Service Selection mobility
   option cannot be decorated (i.e. making each APN unique), there is a
   need for a new identifier to uniquely identify PDN connections to the
   same APN. "

I am confused by the case, could you please figure it more clearly?

Thanks in advance.

Xiangsong

---

From: jouni korhonen <[email-masked]>
Date: Tue, 21 Jul 2009 11:18:34 +0300

Hi Xiangsong,

See inline.

On Jul 21, 2009, at 7:11 AM, Xiangsong Cui wrote:

>> Similar type  of extensions what you already have e.g. with  
>> RFC5149. What the I-D  adds here is more detail and a new key to  
>> help with lookups to binding
>
> Yes, RFC5149 introduces some extensions, we can accept the extension  
> because there are many use cases.

Right. Assume MN establishes three connections through the same radio  
to the MAG. Connection 1 gets HNP1 and is identified with Service  
Selection (SS) ="foo". Connection 2 gets HNP2 and is again identified  
by SS="foo". Connection 3 gets HNP3 and is also identified by  
SS="foo". This is possible by some popular access technologies already  
today. MN and MAG also know these connections by some lower layer  
identifier/radio level thing.

When a handover takes place the MN re-attaches to a new MAG and starts  
setting up connections to the new MAG. Now the MAG knows which  
connection the MN sets up based on the SS and the "lower layer thing"  
but does not necessarily know the associated HNP yet. So the PBU sent  
to the LMA needs more info. Otherwise the LMA is not able to return  
the correct HNP to the MAG. If the LMA were to return HNP1 for the  
connection 2 after a handover that would break the IP connectivity in  
the MN. That's why we propose to add "yet another" identifier to all  
PBU/PBA messages. Using MN-LL would look tempting but the solution  
must also work with one interface and cases where interfaces do not  
have real identifiers (would mean overloading the existing meaning of  
the MN-LL).

Cheers,
	Jouni

>
> Thanks in advance.
>
> Xiangsong
>
> ----- Original Message ----- From: "jouni" <[email-masked]>
>> It is a change but I would not call it semantic change. Similar  
>> type  of extensions what you already have e.g. with RFC5149. What  
>> the I-D  adds here is more detail and a new key to help with  
>> lookups to binding  cache (obviously adds more data to binding  
>> cache entries as well) when  you want to identify exactly one of  
>> several mobility sessions without  really knowing its assigned HNP.
>>>>
>>>>> I think sending a non-renewal PBU is a big semantic change to  
>>>>> the  base
>>>>> protocol.
>>>>
>> If it is a case that PBA contains more than one HNP. This is,  
>> however,  always not the case.
>> different HNP. The issue is that the HNP information is not enough,  
>> or  merely not available, when a link gets set up after a handover.

---

From: Xiangsong Cui <[email-masked]>
Date: Tue, 21 Jul 2009 16:40:41 +0800

Hi Jouni,

> to the MAG. Connection 1 gets HNP1 and is identified with Service  

Do you mean a  MN has three 3GPP interface connection, or three 
WLAN connection?
I don't understand the case, IMO, a MN may has a 3GPP interface + a
WLAN interface + a Wimax interface, but I can't image a MN with three
WLAN interfaces, do the interfaces use the same link layer address?

Even in Nextext2, there is only inter RAT handover.
If there is only one RAT, in my mind, there is only one connection,
to previous AR before handover and to new AR after handover.

Xiangsong

---

From: jouni korhonen <[email-masked]>
Date: Wed, 22 Jul 2009 10:36:06 +0300

Hi Xiangsong,

On Jul 21, 2009, at 11:40 AM, Xiangsong Cui wrote:

> Hi Jouni,
>
>> Right. Assume MN establishes three connections through the same  
>> radio  to the MAG. Connection 1 gets HNP1 and is identified with  
>> Service
>
> Do you mean a  MN has three 3GPP interface connection, or three WLAN  
> connection?

So far we have been discussing about a single interface.

> Even in Nextext2, there is only inter RAT handover.

Imho this is a separate topic.

> to previous AR before handover and to new AR after handover.

What type of connection you are talking about here. The draft  
discusses about PDN Connections.

Cheers,
	Jouni

>
> Xiangsong
>
>
> ----- Original Message ----- From: "jouni korhonen" <[email-masked] 
> >
>> Right. Assume MN establishes three connections through the same  
>> radio  to the MAG. Connection 1 gets HNP1 and is identified with  
>> Service  Selection (SS) ="foo". Connection 2 gets HNP2 and is again  
>> identified  by SS="foo". Connection 3 gets HNP3 and is also  
>> identified by  SS="foo". This is possible by some popular access  
>> technologies already  today. MN and MAG also know these connections  
>> by some lower layer  identifier/radio level thing.
>> When a handover takes place the MN re-attaches to a new MAG and  
>> starts  setting up connections to the new MAG. Now the MAG knows  
>> which  connection the MN sets up based on the SS and the "lower  
>> layer thing"  but does not necessarily know the associated HNP yet.  
>> So the PBU sent  to the LMA needs more info. Otherwise the LMA is  
>> not able to return  the correct HNP to the MAG. If the LMA were to  
>> return HNP1 for the  connection 2 after a handover that would break  
>> the IP connectivity in  the MN. That's why we propose to add "yet  
>> another" identifier to all  PBU/PBA messages. Using MN-LL would  
>> look tempting but the solution  must also work with one interface  
>> and cases where interfaces do not  have real identifiers (would  
>> mean overloading the existing meaning of  the MN-LL).
>> Cheers,
>> Jouni
>>>
>>> Thanks in advance.
>>>
>>> Xiangsong
>>>
>>>> type  of extensions what you already have e.g. with RFC5149.  
>>>> What  the I-D  adds here is more detail and a new key to help  
>>>> with  lookups to binding  cache (obviously adds more data to  
>>>> binding  cache entries as well) when  you want to identify  
>>>> exactly one of  several mobility sessions without  really knowing  
>>>> its assigned HNP.
>>>>>>
>>>> Eh? In this particular example, each PDN connection already has  
>>>> a   different HNP. The issue is that the HNP information is not  
>>>> enough,  or  merely not available, when a link gets set up after  
>>>> a handover.
>>>>> access the Internet. More than one addresses create problems  
>>>>> that   MIF WG is trying to address.

---

From: Xiangsong Cui <[email-masked]>
Date: Wed, 22 Jul 2009 17:42:00 +0800

Yes, I know the draft is discussing PDN connections.
But I  don't know, in what a scenario, a MN can establish
multiple connections to one PDN?

Xiangsong

----- Original Message ----- 
From: "jouni korhonen" <[email-masked]>
To: "Xiangsong Cui" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Wednesday, July 22, 2009 3:36 PM
Subject: Re: [netext] Comments on I-D: draft-wolfner-netext-pmip6-connid-00

> What type of connection you are talking about here. The draft  discusses 
> about PDN Connections.
>
> Cheers,
> Jouni
>
>
>>
>> Xiangsong
>>
>>
>>>>> Similar type  of extensions what you already have e.g. with   RFC5149. 
>>>>> What the I-D  adds here is more detail and a new key to   help with 
>>>>> lookups to binding
>>>>
>>>>>> That's what I was referring to as a big semantic change to PBU/ PBA.
>>>>> adds here is more detail and a new key to help  with  lookups to 
>>>>> binding  cache (obviously adds more data to  binding  cache entries as 
>>>>> well) when  you want to identify  exactly one of  several mobility 
>>>>> sessions without  really knowing  its assigned HNP.
>>>>>>>

---

From: jouni korhonen <[email-masked]>
Date: Wed, 22 Jul 2009 13:11:07 +0300

> multiple connections to one PDN?

Multiple PDN Connections to the same Service (i.e. APN). Not the other  
way around.

Cheers,
	Jouni

>>>>>> RFC5149. What the I-D  adds here is more detail and a new key  
>>>>>> to   help with lookups to binding
>>>>>
>>>> Service Selection (SS) ="foo". Connection 2 gets HNP2 and is  
>>>> again  identified by SS="foo". Connection 3 gets HNP3 and is  
>>>> also  identified by SS="foo". This is possible by some popular  
>>>> access  technologies already today. MN and MAG also know these  
>>>> connections  by some lower layer identifier/radio level thing.
>>>> layer thing" but does not necessarily know the associated HNP  
>>>> yet.  So the PBU sent to the LMA needs more info. Otherwise the  
>>>> LMA is  not able to return the correct HNP to the MAG. If the LMA  
>>>> were to  return HNP1 for the connection 2 after a handover that  
>>>> would break  the IP connectivity in the MN. That's why we propose  
>>>> to add "yet  another" identifier to all PBU/PBA messages. Using  
>>>> MN-LL would  look tempting but the solution must also work with  
>>>> one interface  and cases where interfaces do not have real  
>>>> identifiers (would  mean overloading the existing meaning of the  
>>>> MN-LL).
>>>> Cheers,
>>>> Jouni
>>>>>
>>>>> Thanks in advance.
>>>>>
>>>>> Xiangsong
>>>>>
>>>>> Subject: Re: [netext] Comments on I-D: draft-wolfner-netext- 
>>>>> pmip6- connid-00
>>>>>
>>>>>
>>>>>> Hi Behcet,
>>>>>> It is a change but I would not call it semantic change.  
>>>>>> RFC5149.  What  the I-D adds here is more detail and a new key  
>>>>>> to help  with  lookups to binding  cache (obviously adds more  
>>>>>> data to  binding  cache entries as well) when  you want to  
>>>>>> identify  exactly one of  several mobility sessions without   
>>>>>>>>> I think sending a non-renewal PBU is a big semantic change  
>>>>>>>>> to   the base
>>>>>>>>> protocol.
>>>>>>>>
>>>>>> Eh? In this particular example, each PDN connection already  
>>>>>> has  a different HNP. The issue is that the HNP information is  
>>>>>> not  enough, or  merely not available, when a link gets set up  
>>>>>> after  a handover.

---

From: Xiangsong Cui <[email-masked]>
Date: Thu, 23 Jul 2009 09:25:20 +0800

Hi Jouni,

I ever read 3GPP 23.402 of Rel 8, there is explicitly statement
"PDN is indicated with APN" in the specification,
so I am strange at the draft.

But now, I do find the function of "Multiple PDN connections
to the same APN" in the 3GPP document of Rel 9.

So I will read the 3GPP document first.

Thank you and regards

Xiangsong

----- Original Message ----- 
From: "jouni korhonen" <[email-masked]>
To: "Xiangsong Cui" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Wednesday, July 22, 2009 6:11 PM
Subject: Re: [netext] Comments on I-D: draft-wolfner-netext-pmip6-connid-00

>>>>> which connection the MN sets up based on the SS and the "lower   layer 
>>>>> thing" but does not necessarily know the associated HNP  yet.  So the 
>>>>> PBU sent to the LMA needs more info. Otherwise the  LMA is  not able 
>>>>> to return the correct HNP to the MAG. If the LMA  were to  return HNP1 
>>>>> for the connection 2 after a handover that  would break  the IP 
>>>>> connectivity in the MN. That's why we propose  to add "yet  another" 
>>>>> identifier to all PBU/PBA messages. Using  MN-LL would  look tempting 
>>>>> but the solution must also work with  one interface  and cases where 
>>>>> interfaces do not have real  identifiers (would  mean overloading the 
>>>>> existing meaning of the  MN-LL).
>>>>> Cheers,
>>>>> Jouni
>>>>>>
>>>>>> Thanks in advance.
>>>>>>
>>>>>> Xiangsong
>>>>>>
>>>>>> Subject: Re: [netext] Comments on I-D: draft-wolfner-netext- pmip6- 
>>>>>> connid-00
>>>>>>
>>>>>>
>>>>>>> Hi Behcet,
>>>>>>> different HNP. The issue is that the HNP information is  not 
>>>>>>> enough, or  merely not available, when a link gets set up  after  a 
>>>>>>> handover.

---

From: Xiangsong Cui <[email-masked]>
Date: Thu, 30 Jul 2009 17:58:00 +0800

Hello Raj and Jouni,

I have a question about the draft.

Firstly, I agree the requirement of multiple PDN connections
to the same APN.

IMO, the major idea of this draft is as mentioned in the draft:

  The combination of MN-Identifier + Service Selection +
  Connection Identifier can uniquely identify mobility sessions even if
  the selected service on each mobility session for the same MN-
  Identifier are the same.

It recall me to another draft, "draft-ietf-netlmm-grekey-option-09.txt".
In the GREKEY draft, it says:
   This specification defines the GRE Key option to be used for the
   negotiation of GRE encapsulation mode and exchange of the uplink and
   downlink GRE keys.  The negotiated downlink and uplink GRE keys can
   be used for marking the downlink and uplink traffic for a specific
   mobility session.

The connid draft is used to identify a certain session among
multiple sessions, while the grekey draft is used to identify a
certain link/flow in the tunnel between the MAG and the LMA.

When I look at figure 1 in the grekey draft, it seems similar for the
both cases, because we just need to identify a connection, and the
connection may be a session or a flow.

So I have the question:
if we expand the meaning of GRE Key option, without protocol expansion,
can we use the combination "MN-Identifier + Service Selection + GRE key"
to identify the connections to the same APN?

Regards

Xiangsong

---

From: jouni korhonen <[email-masked]>
Date: Thu, 30 Jul 2009 18:49:56 +0300

Hi Xiangsong,

> to identify the connections to the same APN?

There are few reasons. First, which GRE key to use? Uplink or  
downlink? Obviously, the MAG does not know the uplink GRE key when  
sending a PBU during the initial attach or after a handover.. so you  
would lack the "identifier" in the MAG in some situations. If we were  
to use the downlink key, according to the GRE key draft it is not  
guaranteed that the downlink remains the same between inter-MAG  
handover.

Second, the use of GRE keys and GRE tunneling is optional in PMIP6.  
Well, so is Service Selection too but I would avoid building  
additional dependencies between different documents if just possible.

Third, overloading the function of the GRE key option does not sound a  
good idea in general, even if it were possible.

Cheers,
	Jouni

>
> Regards
>
> Xiangsong
>
> ----- Original Message ----- From: <[email-masked]>
> To: <[email-masked]>

---

From: Xiangsong Cui <[email-masked]>
Date: Fri, 31 Jul 2009 12:11:14 +0800

Hi Jouni,

Thank you for your response.

> There are few reasons. First, which GRE key to use? Uplink or  downlink?
I think Uplink and downlink may be used to identify the connection
for different direction. MAG and LMA know well both uplink and
downlink after the registration.

> Obviously, the MAG does not know the uplink GRE key when  sending a PBU 
> during the initial attach or after a handover.. so you  would lack the 
> "identifier" in the MAG in some situations.
I don't know in which situation the identifier would be lacking.
If you refer to handover, I think the GRE Key may also be a part
of the context, as connection-id does.

> If we were  to use the downlink key, according to the GRE key draft it is 
> not  guaranteed that the downlink remains the same between inter-MAG 
> handover.
The same problem with connection-id, if you use connection-id, can
you guarantee that the connection-id is always same?
Inter-MAG handover is the common issue for all identifiers.

>
> Second, the use of GRE keys and GRE tunneling is optional in PMIP6.  Well, 
> so is Service Selection too but I would avoid building  additional 
> dependencies between different documents if just possible.
Yes, GRE Key is an optional option. I think an optional option is used
for a optional feature is reasonable

> good idea in general, even if it were possible.
If it works well, why not take it as the solution?

I see many messages recently on the issue of expansion to protocol.

For example (Suresh and Vijay, I supposed you permit me to cite your words),

http://www.ietf.org/proceedings/75/slides/mext-0.ppt, slide 7,
Suresh says:
"There have been several extensions to CMIPv6;
.
But, there is no cohesive mobility architecture that holds these extensions 
together;
.
This causes a lot of confusion and incompatible implementations"

http://www.ietf.org/mail-archive/web/netext/current/msg00729.html,
Vijay says:
"One option would be to re-use the HA
Switch Message from RFC 5142 and carry the redirect mobility option in this
message. This would avoid defining a new message."

http://www.ietf.org/mail-archive/web/netext/current/msg00739.html,
Vijay also says:
It would be a bad idea to have two different sets of
mechanisms.

I'm also in the position, if we can re-use some mechanisms,
we need NO expansion, so the protocols may be more simple.

Regards

Xiangsong

----- Original Message ----- 
From: "jouni korhonen" <[email-masked]>
To: "Xiangsong Cui" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Thursday, July 30, 2009 11:49 PM
Subject: Re: [netext] Comments on I-D: draft-wolfner-netext-pmip6-connid-00

>> It recall me to another draft, "draft-ietf-netlmm-grekey- option-09.txt".
> There are few reasons. First, which GRE key to use? Uplink or  downlink? 
> Obviously, the MAG does not know the uplink GRE key when  sending a PBU 
> during the initial attach or after a handover.. so you  would lack the 
> "identifier" in the MAG in some situations. If we were  to use the 
> downlink key, according to the GRE key draft it is not  guaranteed that 
> the downlink remains the same between inter-MAG  handover.
>
> Second, the use of GRE keys and GRE tunneling is optional in PMIP6.  Well, 
> so is Service Selection too but I would avoid building  additional 
> dependencies between different documents if just possible.
>
>> Subject: [netext] Comments on I-D: draft-wolfner-netext-pmip6- connid-00
>>
>>
>>>
>>>
>>> Hello,
>>>

---

From: jouni korhonen <[email-masked]>
Date: Fri, 31 Jul 2009 12:16:20 +0300

Hi,

On Jul 31, 2009, at 7:11 AM, Xiangsong Cui wrote:

>> downlink?

Uh.. so you would use combination of both keys simultaneously?

>> Obviously, the MAG does not know the uplink GRE key when  sending a  
>> PBU during the initial attach or after a handover.. so you  would  
>> lack the "identifier" in the MAG in some situations.

Few things. Now you are making context transfer between MAGs mandatory  
as otherwise there is no guarantee GRE keys are present. I do not want  
to mandate context transfer. It can be used, if available, but  
mandating it is not good.

There are also cases (specific to certain architectures and  
deployments), where a MN is first using access mechanism that does not  
use GRE but still supports the Service Selection/APNs. Now when you do  
a handover from such to PMIP6, the MAG just don't have GRE key  
information as they do not exist yet. The common anchor (LMA/HA)  
already has the bindings for multiple services with the same name. It  
is safer to rely on something else than GRE keys.

>
>> If we were  to use the downlink key, according to the GRE key draft  
>> it is not  guaranteed that the downlink remains the same between  
>> inter-MAG handover.

The draft says the connection identifier potentially comes from lower  
layers or other mechanisms than context transfer. If I can really  
assume context transfer is always in place, then I would be just find  
with using HNP/IP4-HoA + MN-ID + Service Selection. As said before,  
currently I cannot rely on either HNP/IP4-HoA or GRE information to be  
available at the MAG when the MN first camps there.

>
>>
>> Second, the use of GRE keys and GRE tunneling is optional in  
>> PMIP6.  Well, so is Service Selection too but I would avoid  
>> building  additional dependencies between different documents if  
>> just possible.

The less the better. I.e. if I can choose between two optional  
features versus three optional features, I would go for two.

>
>>
>> Third, overloading the function of the GRE key option does not  
>> sound a good idea in general, even if it were possible.

Overloading existing semantics is always a bad practice.

I'll skip the rest as I don't see how they relate to this discussion.

Cheers,
	Jouni

> But, there is no cohesive mobility architecture that holds these  
> extensions together;
> .

[snip]

---

From: Xiangsong Cui <[email-masked]>
Date: Fri, 31 Jul 2009 18:00:31 +0800

Hi Jouni, 

Please see inline.

Regards/Xiangsong

----- Original Message ----- 
From: "jouni korhonen" <[email-masked]>
To: "Xiangsong Cui" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Friday, July 31, 2009 5:16 PM
Subject: Re: [netext] Comments on I-D: draft-wolfner-netext-pmip6-connid-00

> Uh.. so you would use combination of both keys simultaneously?

Yes, I think GRE Key is designed for this manner.

> is safer to rely on something else than GRE keys.

In your draft, section 5.3, it says
"  How the MAG knows/learns the connection identifiers after a handover
   between MAGs is out of scope of this specification.  However,
   mechanisms such as context transfer between MAGs may be used. **
   Editor's note: these assumptions are subject to changes ** "

I don't know which mechanism do you use to keep the connection-id
during the handover procedure.

> available at the MAG when the MN first camps there.
You do mention the "lower layers" in section 1, but it is for connection-id
creation. If you want to use this mechanism in handover, I don't know how
can you keep the connection-id, because the MAGs are using different
lower layers.

> Overloading existing semantics is always a bad practice.
Yes, I agree it is a trouble.
But if the overloading is in the acceptable scope, IMO, we need 
balance the impact of  overloading and introducing a new expansion.
It is the motivation behind my original question.

[snip]

---

From: jouni korhonen <[email-masked]>
Date: Fri, 31 Jul 2009 16:37:21 +0300

Lets first resolve whether the GRE keys are usable in the first place.  
Then we can return to the rest of the discussion. Some more stuff  
inline.

> Yes, I think GRE Key is designed for this manner.

I am a bit confused. Do you mean using 64-bit identifier made of both  
uplink & downlink GRE keys?

Anyway, downlink GRE keys are no good in general as they may change  
during handovers. If there is context transfer between MAGs it still  
does not solve the downlink key issue. One would need to start  
coordinating downlink key space between MAGs, which is a new  
requirement.

The Uplink GRE key would be an usable connection Id, assuming MAGs can  
do a context transfer, the exception mentioned in Section 3.3.2 of  
draft-ietf-netlmm-grekey-option does not happen and that GRE is used  
in the first place. However, the GRE key option in a PBU contains only  
the downlink key. This means, you need something beyond draft-ietf- 
netlmm-grekey-option to send the uplink GRE key in the PBU (if the  
uplink GRE key were used as the connection Id).

[snap]

> It is the motivation behind my original question.

You would still need a document that describes how the GRE keys are  
used to extend the BCE lookup, how they are used with RFC5149, and how  
to indicate to the LMA that the GRE keys are used in this special  
overloaded way etc. If you go down this road, what is the benefit of  
it over defining a new option specifically made for connection  
identifier purpose? At the end, the connection identifier content can  
be anything that is a stable identifier within the system where this  
extension is being used.. be that a GRE key or not.

Cheers,
	Jouni