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

[cuixiangsong 00111037 <[e-mail]>]

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 <[e-mail]>
日期: 星期五, 七月 31日, 2009 下午9:39
主题: Re: [netext] Comments on I-D: draft-wolfner-netext-pmip6-connid-00
收件人: Xiangsong Cui <[e-mail]>
抄送: [e-mail], [e-mail]

> 
> 
> 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" 
> <[e-mail] 
> > >
> > To: "Xiangsong Cui" <[e-mail]>
> > Cc: <[e-mail]>; <[e-mail]>
> > 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netext
>