Re: [mif] [DMM] RE: [homenet] Fwd: New Liaison Statement, "Broadband For um Work on ³Hybrid Access for Broadband Networks² (WT-348)"

[Xueli <[e-mail]>]

Hello Alex

The control plane I mean, is some signal exchange between the CPE and HA. It should contain at least following functions:

1 Setup multiple tunnels simultaneously 
2 Bonding them 
3 traffic distribution scheme selection via distribution/negotiation (Per-packet or per-flow)
4 The traffic distribution policy between RG and HA (per-flow case, for example, flow A go to 3G/4G, flow B go to DSL, etc.)
5 Enable dynamic traffic distribution policy adjustment .
 
Both IPv4 and IPv6 should be considered in this case. 

Best Regards
Li


-----Original Message-----
From: Alexandru Petrescu [mailto:[e-mail]] 
Sent: Wednesday, October 29, 2014 10:44 PM
To: Xueli; Sri Gundavelli (sgundave); [e-mail]; Ted Lemon; STARK, BARBARA H
Cc: [e-mail]
Subject: Re: [mif] [DMM] RE: [homenet] Fwd: New Liaison Statement, "Broadband For um Work on ³Hybrid Access for Broadband Networks² (WT-348)"

(sorry for interferring)

Le 29/10/2014 11:02, Xueli a écrit :
[...]
> From this point of view, each tunnels (L2TP, GRE, IPinIP (MIP) ).
> with a extended flexible control plane can apply for hybrid access.

The Mobile IP protocol can set up several kinds of tunnels: IP-in-IP, IP-in-UDP, GRE.

L2TP is not a kind of tunnel I believe.

> If we consider this like a distribution way based on the control plane 
> between the CPE and HA( as shown in your figure.)
>
> We also can consider some centralized control function/entity, which 
> can distribute the signal to CPE and HA so as to resolve the control 
> plane requirement of hybrid access.
>
> My question is why we don't extend L2TP control plane or GRE control  
> plane, as extend MIP control plane, for distribution control way.

Well...

Not sure what you mean by control plane in this context.

The only protocol to set up a GRE tunnel is Mobile IP.  I doubt there is any other.

L2TP is not a tunnel, but a protocol.  L2TP control messages are not IP messages.  As such they can not be used between a homebox and an arbitrary IP server in the infrastructure.  Or, one needs to reach such a server whenever one talks hybrid access (or heterogeneous access).

> So the main issue is to investigate which control plane we add to the  
> tunnel's data plane, all can be fixed (L2TP, GRE, IPInIP,MIP).

This could be investigated.

Another aspect that would need clarification from BBF is the IP version of the protocol considered.  Because, Mobile IP and tunnels themselves are very different with respect to that version.

Alex

> Without distribute control plane, centralized control function can 
> resolve the issue as well.
>
> What do you think?
>
> Let me know if you believe this does not meet the requirement.
>
> Flow-1
>
> |
>
> |Flow-2
>
> | |
>
> | |Flow-3              _----_
>
> | | |         CoA-1  _(      )_   Tunnel-1
>
> | | |    .---=======(   Wi-Fi  )========\ Flow-1
>
> | | |    |           (_      _)          \
>
> | | |    |             '----'             \
>
> | | | +=====+          _----_              \  +=====+    _----_
>
> | | '-|     | CoA-2  _(      )_ Tunnel-2    \ |     |  _(      )_ --
>
> | '---| MN  |---====(   LTE    )=========-----| HA  |-( Internet )--
>
> '-----|     |        (_      _)      Flow-3 / |     |  (_      _) --
>
> +=====+          '----'              /  +=====+    '----'
>
> | |             _----_             /
>
> HoA-1--' |    CoA-3  _(      )_ Tunnel-3 /
>
> .------====(   CDMA   )========/ Flow-2
>
> (_      _)
>
> '----'
>
> Regards
>
> Sri
>
> *From: *Xueli <[e-mail] <mailto:[e-mail]>> *Date:
> *Monday, October 27, 2014 9:04 PM *To: *Sri Gundavelli 
> <[e-mail] <mailto:[e-mail]>>, 
> "[e-mail] <mailto:[e-mail]>"
> <[e-mail] <mailto:[e-mail]>>, Ted 
> Lemon <[e-mail] <mailto:[e-mail]>>, "STARK,  
> BARBARA H" <[e-mail] <mailto:[e-mail]>> *Cc: *HOMENET 
> Working Group <[e-mail] <mailto:[e-mail]>>, 
> "[e-mail] <mailto:[e-mail]>" <[e-mail] 
> <mailto:[e-mail]>>, "[e-mail] <mailto:[e-mail]>"
> <[e-mail] <mailto:[e-mail]>> *Subject: *RE: [DMM] RE:
> [homenet] Fwd: New Liaison Statement, "Broadband For um Work on 
> ³Hybrid Access for Broadband Networks² (WT-348)"
>
> Hello Sri
>
> Thanks for the comments.  Just some clarification for the cross email.
>
> A new version about the architecture is uploaded..
>
> http://www.ietf.org/internet-drafts/draft-lhwxz-hybrid-access-network-
> architecture-01.txt
>
>  There are some new  requirements about the hybrid access topic, such 
> as bonding, traffic policy distribution etc.
>
> Do you mind to share more additional technologies about the existing  
> protocols solution for hybrid access.
>
> Which exact issues it is really solving, in order to evaluate if the  
> existing solutions properly solve this use case?
>
> Best Regards
>
> Li
>
>
> *From:*Sri Gundavelli (sgundave) [mailto:[e-mail]] *Sent:* 
> Wednesday, October 22, 2014 6:56 PM *To:* [e-mail] 
> <mailto:[e-mail]>; Xueli; Ted Lemon; STARK, BARBARA H 
> *Cc:* HOMENET Working Group; [e-mail] <mailto:[e-mail]>; 
> [e-mail] <mailto:[e-mail]> *Subject:* Re: [DMM] RE: [homenet]
> Fwd: New Liaison Statement, "Broadband For um Work on ³Hybrid Access 
> for Broadband Networks² (WT-348)"
>
> <We probably should not be cross posting the mail to three WG mailers, 
> but I will respond to this one last email>
>
> Hi Li,
>
> While the term "hybrid-access" sounds fresh and new, but its important 
> to understand that this is largely a use-case around mobile networks. 
> Per my comments in the last HOMENET meeting, mobility working groups 
> have defined solutions for this multi-access use-case.
> There are clearly mechanisms that allow network entities to negotiate 
> flow policies and switch traffic on application basis. The access can 
> be LTE, WLAN, SatRAN, Fixed line ..etc, but the negotiated policies 
> allow the peers to agree on binding a flow to a given access.
> Wearing cisco vendor hat, we have deployed solutions for this use-case 
> for the last decade. So, I agree with the BBF use-case and I think we 
> should probably draft a BCP-type solution document, explaining BBF on 
> the tools that are available for addressing this issue. If there are 
> minor gaps, we should certainly propose extensions to the protocols.
>
> As pierrick, I'm also not in favor of defining a control protocol for  
> GRE as its not needed. GRE is a use-plane protocol and the semantics  
> that are present in the header are only designed to be used for adding 
> meta-data related to the IP flows in that tunnel header. There are no 
> semantics for defining a new signaling layer in a user-plane protocol. 
> GRE was always used in conjunction with a signaling protocol and that 
> signaling protocol is IPsec, MIP, PMIP ..and so on.
> However, you design that control protocol, it will exactly smell and 
> feel like existing protocols. The aspect around subscriber identity, 
> authorization, access policy, Traffic flow template definition .all of 
> this has to be modeled and in the process we will end up reinventing 
> every thing that we defined over the last many years, but it will have 
> a new title, "GRE-CP".
>
> Regards
>
> Sri
>
> *From: *"[e-mail]
> <mailto:[e-mail]>" <[e-mail] 
> <mailto:[e-mail]>> *Date: *Wednesday, October 22,
> 2014 3:05 AM *To: *Xueli <[e-mail] <mailto:[e-mail]>>, 
> Ted Lemon <[e-mail] <mailto:[e-mail]>>, 
> "STARK, BARBARA H" <[e-mail] <mailto:[e-mail]>> *Cc: 
> *HOMENET Working Group <[e-mail] <mailto:[e-mail]>>, 
> "[e-mail] <mailto:[e-mail]>" <[e-mail] 
> <mailto:[e-mail]>>, "[e-mail] <mailto:[e-mail]>" 
> <[e-mail] <mailto:[e-mail]>> *Subject: *[DMM] 
> =?Windows-1252?Q?RE:_[homenet]_Fwd:_New_Liaison_Statement,
> _"Broadband_For?= um Work on "Hybrid Access for Broadband Networks"
> (WT-348)"
>
> Hi Li,
>
> Architecture considerations and solution design are two different 
> things, which should not be addressed in the same I-D. People may 
> agree with the big picture depicture and architecture but not agree 
> with going on extensions to the GRE protocol to address the issue.
> BTW, I think that going for extensions to GRE header to address the 
> hybrid access use-case is not the right way. Actually, IETF solutions 
> already exist (RFC  4908 ) and, moreover, there is ongoing effort in 
> DMM to update RFC 4908 to meet hybrid access requirements.
>
> BR,
>
> Pierrick
>
> *De :*Xueli [mailto:[e-mail]] *Envoyé :* mercredi 22 octobre
> 2014 11:48 *À :* Ted Lemon; STARK, BARBARA H *Cc :* HOMENET Working 
> Group; [e-mail] <mailto:[e-mail]> *Objet :* RE: [homenet]
> Fwd: New Liaison Statement, "Broadband Forum Work on "Hybrid Access 
> for Broadband Networks" (WT-348)"
>
> Hello
>
> Thanks Barbara to send this liaison out.
>
> Hybrid Access network is that Residential gateway (RG, or CPE) is 
> extended with more than two access lines
>
> (e.g. DSL + LTE) in order to provide higher bandwidth for the 
> customers. The scenario and architecture are shown as follows
>
> cid:[e-mail]8CD480
>
> Right now, we have two individual drafts, one for architecture and 
> requirements, and the other one is for an optional solution.
>
> The draft
> (http://tools.ietf.org/html/draft-lhwxz-hybrid-access-network-architec
> ture-00  ; ) proposes the architecture and gap analysis.
>
> The solution draft proposes one option for the solutions, 
> http://tools.ietf.org/html/draft-heileyli-gre-notifications-00
>
> We did not combine them as one draft, because we believe there may be  
> other candidates, and we would like to have further discussions in the 
> related groups and IETF.
>
> We used to present it in Homenet in Toronto.
>
> Now the authors have invited Orange to join this architecture work.
> We will send out the new version of these drafts soon.
>
> We are glad to invite the experts for comments.
>
> Best Regards
>
> Li Xue on the co-authors behalf
>
> -----Original Message-----
>
> From: homenet [mailto:[e-mail]] On Behalf Of Ted Lemon
>
> Sent: Wednesday, October 22, 2014 3:05 AM
>
> To: STARK, BARBARA H
>
> Cc: HOMENET Working Group
>
> Subject: Re: [homenet] Fwd: New Liaison Statement, "Broadband Forum 
> Work on "Hybrid Access for Broadband Networks"(WT-348)"
>
> On Oct 21, 2014, at 2:55 PM, STARK, BARBARA H <[e-mail] 
> <mailto:[e-mail]>> wrote:
>
>> FYI. I made sure they were aware of IETF mif and homenet activities 
>> in this area. I intend to try to prevent having to track efforts that 
>> try to do the same thing in two different ways. But some  of the BBF 
>> effort may be focused on what can be done around "bonding"
>>
> of multiple interfaces that are under the control of a single service  
> provider. I don't see this in mif or homenet.
>
> Thanks.   I couldn't really tell what was being proposed from the
> Liaison statement, so this information is helpful.
>
> _______________________________________________
>
> homenet mailing list
>
> [e-mail] <mailto:[e-mail]>
>
> https://www.ietf.org/mailman/listinfo/homenet
>
> ______________________________________________________________________
> ___________________________________________________
>
>
>
>
> Ce message et ses pieces jointes peuvent contenir des informations 
> confidentielles ou privilegiees et ne doivent donc
>
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez 
> recu ce message par erreur, veuillez le signaler
>
> a l'expediteur et le detruire ainsi que les pieces jointes. Les 
> messages electroniques etant susceptibles d'alteration,
>
> Orange decline toute responsabilite si ce message a ete altere, 
> deforme ou falsifie. Merci.
>
>
>
> This message and its attachments may contain confidential or 
> privileged information that may be protected by law;
>
> they should not be distributed, used or copied without authorisation.
>
> If you have received this email in error, please notify the sender and 
> delete this message and its attachments.
>
> As emails may be altered, Orange is not liable for messages that have 
> been modified, changed or falsified.
>
> Thank you.
>
>
>
> _______________________________________________ mif mailing list 
> [e-mail] https://www.ietf.org/mailman/listinfo/mif
>