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

From: cuixiangsong 00111037 <[email-masked]>
Date: Sun, 02 Aug 2009 10:08:51 +0800

Hi jouni,

Sorry for the late response. I'm glad to try this approach.

I have this idea base on the statment from 
"draft-ietf-netlmm-grekey-option-09.txt",
(I will call it grekey-draft in this context)

The draft says, in section 1:
 " The negotiated downlink and uplink GRE keys can
   be used for marking the downlink and uplink traffic for a specific
   mobility session."

This is the key: we can use the GRE keys to marking the traffic.

I think this is equal to say we can identify the flow use GRE keys
and we of course may take the connections as the traffic flows. So
I wish we can re-use the GRE key with only a little overloading.

Now let's consider how can we use GRE key to achieve this requirement.

I assume the MAG and the LMA both support GRE key option and
connection feature.

Firstly, when MAG sends PBU message to LMA, the MAG creats a down
link GRE key and maps the down link GRE key to the connection 
originated from MN. The MAG includes the GRE key option in the PBU
as specified in grekey-draft, and also includes a Service Selection
Mobility Option as speified in RFC5149.

Secondly, when the LMA receives the PBU message from the MAG, 
the LMA deals the message and the options as specified in existing
documents. After the LMA creats BCE and a uplink GRE key, the LMA
caches the MN-id, Service Selection, downlink GRE key and uplink
GRE key in the BCE and also associates both the downlink GRE key
and the uplink GRE key with the PDN connection. The LMA responds
PBA message to the MAG, with the uplink GRE key option included.

Thirdly, when the MAG receives the PBA from the LMA, the MAG caches
the uplink GRE key and associates both the downlink GRE key and
uplink GRE key with the connection to MN. The MN also knows well
the MN id and the Service Selection.

By now, the registration has been finished and both the LMA and
the MAG have cached a mapping, between GRE key pair(i.e. downlink
GRE key and uplink GRE key) and the connection (i.e. the conncetion
from multiple PDN connections to a same APN).

In the Data Packets Processing procedure, section 7.3.1 and 7.4.1
from grekey-draft show the rule and additionally, section 3.1 from
grekey-draft says:

 " once the GRE keys have been exchanged between the mobile
   access gateway and the local mobility anchor as per this
   specification, the mobile access gateway will use the uplink GRE key
   that is assigned by the local mobility anchor in the GRE header of
   the uplink payload packet.  Similarly, the local mobility anchor will
   use the downlink GRE key as negotiated with the mobile access gateway
   in the GRE header of the downlink payload packet."

That means, both the LMA and the MAG can use the GRE keys included in
the GRE header to identify the data packet, or identify the traffic flow.

So, the connection is iedntified by the combination of "MN id + GRE key
+ Service Selection(i.e. APN)". In fact, the connection is fractionized,
the direction from LMA to MAG is identified by "MN id + downlink GRE key
+ APN" while the direction from MAG to LMA is identified by "MN id + 
uplink GRE key + APN". Each connection may be identified exactly.

As to the handover, grekey-draft says, in section 3.3.2,
 " In this case, the new mobile access gateway may
   either pick a new downlink GRE key or use the downlink GRE key that
   was used by the previous mobile access gateway for the same binding.
   For the new mobile access gateway to know the downlink GRE key used
   by the previous mobile access gateway, it may require transfer of
   context from the previous mobile access gateway to the new mobile
   access gateway during a handoff.  Such mechanisms are out-of-scope
   for this specification."

This is for the downlink GRE key, and for the uplink GRE key, the
grekey draft says:

 " If the local mobility anchor successfully processes a handoff-
   triggered Binding Lifetime Extension Proxy Binding Update message
   which contains a GRE key option with a downlink GRE key included, the
   local mobility anchor MUST return the same uplink GRE key that was
   exchanged with the previous mobile access gateway for the same
   mobility session in the GRE key option in a successful Proxy Binding
   Acknowledgement."

Above all, I think we can use the GRE key option to achieve the 
requirement of "multiple PDN connections to the same APN".

Is it right or usable?

Regards

Xiangsong

===============================================================
----- 原邮件 -----
发件人: jouni korhonen <[email-masked]>
日期: 星期五, 七月 31日, 2009 下午9:39
主题: Re: [netext] Comments on I-D: draft-wolfner-netext-pmip6-connid-00
收件人: Xiangsong Cui <[email-masked]>
抄送: [email-masked], [email-masked]

> 
> 
> 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.
> 
> On Jul 31, 2009, at 1:00 PM, Xiangsong Cui wrote:
> 
> > 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
> >
> >
> >> Hi,
> >> On Jul 31, 2009, at 7:11 AM, Xiangsong Cui wrote:
> >>> 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
> >> Uh.. so you would use combination of both keys simultaneously?
> >
> > 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]
> 
> >>>>
> >>>> 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
> >> 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.
> >>> If it works well, why not take it as the solution?
> >> 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.
> 
> 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
> 
> 
> >
> >> I'll skip the rest as I don't see how they relate to this 
> discussion.>> Cheers,
> >> Jouni
> > [snip]
> >
> 
> 
> >
> 
> _______________________________________________
> netext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netext
>

---

From: jouni korhonen <[email-masked]>
Date: Mon, 3 Aug 2009 10:00:21 +0300

Hi Xiangsong,

On Aug 2, 2009, at 5:08 AM, cuixiangsong 00111037 wrote:

[snip]

> Now let's consider how can we use GRE key to achieve this requirement.

I already said that uplink key could be an usable connection id as a  
*value*, if other conditions match.

> I assume the MAG and the LMA both support GRE key option and

Point one, we don't want to mandate GRE keys.. even if those in  
practice would be there. From draft-wolfner-* point of view, GRE keys  
are/can be "lower layer" information. However, specifically saying the  
connection id is *the* GRE key, is not what we want. There is  
absolutely no need to bind this draft to grekey-draft.

> Mobility Option as speified in RFC5149.

As said, a PBU can only have the downlink key as per grekey-draft and  
downlink key as-is is not enough.

> PBA message to the MAG, with the uplink GRE key option included.

As said, for signaling uplink GRE key in a PBU you would need  
something beyond grekey-draft.

> the MN id and the Service Selection.

See above.

[snip]

> requirement of "multiple PDN connections to the same APN".

I think you are still missing the point here. You would still need a  
new option in a PBU, and document the behavior in the LMA and the MAG,  
even if the GRE uplink key were used as the connection id value. This  
is what draft-wolfner is aiming to..

Cheers,
	Jouni

> <c00111037.vcf>

---

From: Xiangsong Cui <[email-masked]>
Date: Mon, 03 Aug 2009 15:38:46 +0800

Hi Jouni,

> downlink key as-is is not enough.
[...snip...]
> As said, for signaling uplink GRE key in a PBU you would need  something 
> beyond grekey-draft.

Why do you exclude PBA message?
The MAG and the LMA can learn both the downlink key and the uplink key
by PBU/PBA exchange.

> I think you are still missing the point here. You would still need a  new 
> option in a PBU, and document the behavior in the LMA and the MAG,  even 
> if the GRE uplink key were used as the connection id value. This  is what 
> draft-wolfner is aiming to..

I don't think so.

As I said in the previous mail, GRE key option can already meet the
protocol requirement, we don't need any more option for this feature.

As to the behavior in the MAG and the LMA, it is mainly about the
mapping management, I don't think it is in the protocol scope.
I also think you would agree me on this point, because in the draft
"draft-wolfner-netext-pmip6-connid-00.txt", it says:

"  How the MAG maps connections originated from the
   MN to connection identifiers is out of scope of this specification."

Regards

Xiangsong

----- Original Message ----- 
From: "jouni korhonen" <[email-masked]>
To: "cuixiangsong 00111037" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Monday, August 03, 2009 3:00 PM
Subject: Re: [netext] Comments on I-D: draft-wolfner-netext-pmip6-connid-00

Hi Xiangsong,

[snip]

See above.

[snip]

Cheers,
Jouni

> 主题: Re: [netext] Comments on I-D: draft-wolfner-netext-pmip6- connid-00

---

From: jouni korhonen <[email-masked]>
Date: Mon, 3 Aug 2009 11:47:37 +0300

On Aug 3, 2009, at 10:38 AM, Xiangsong Cui wrote:

> Hi Jouni,
>
>> As said, a PBU can only have the downlink key as per grekey-draft  
>> and downlink key as-is is not enough.
> [...snip...]

In grekey-draft scope because, the LMA needs to know the connection id  
already when receiving the PBU. The MAG needs to include a connection  
id in the PBU. Downlink key is not really good for this purpose.

>> I think you are still missing the point here. You would still need  
>> a  new option in a PBU, and document the behavior in the LMA and  
>> the MAG,  even if the GRE uplink key were used as the connection id  
>> value. This  is what draft-wolfner is aiming to..
>
> I don't think so.
>

You impact BCE lookup. That is one main reason why to bring this stuff  
to IETF in the first place. If it were completely protocol agnostic,  
we would have kept it inside 3GPP.

>  MN to connection identifiers is out of scope of this specification."

And? I don't see the point as I wrote that text in the draft ;) I  
should probably clarify that the quoted text means mapping of e.g.  
some radio level "bearer" to some identity value used as connection id.

Jouni

>
>
> Regards
>
> Xiangsong
>
>
> ----- Original Message ----- From: "jouni korhonen" <[email-masked] 
> >

---

From: Xiangsong Cui <[email-masked]>
Date: Mon, 03 Aug 2009 17:55:05 +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: Monday, August 03, 2009 4:47 PM
Subject: Re: [netext] Comments on I-D: draft-wolfner-netext-pmip6-connid-00

[Xiangsong] Where do you get the requirement of "know the connection id
already when receiving the PBU"? Is it base on your solution?
In my understanding, the requirement should be
"can identify the connection among multiple PDN connections"
and GRE key option can meet the requirement well.

[Xiangsong] Comparing to simple PMIP, the GRE key option do impact BCE
lookup, but if the LMA support GRE key option, all work well, what is
the trouble? Your connection id option do also impact BCE lookup,
they are same essentially.

[Xiangsong] This more and more like a game.

In general, do you mean when we have already had a RFC, which says
"GRE keys can be used for marking the downlink and uplink traffic ",
we additionally need another document, which says
"define a new option to be used for identifying conncetion" ?

Xiangsong

Jouni