Subject: [mif] Fwd: New Liaison Statement, "Broadband Forum Work on “Hybrid Access for Broadband Networks” (WT-348)"

From: Ted Lemon <[email-masked]>
Date: Tue, 21 Oct 2014 13:10:53 -0400

This is something that might be worth paying attention to.

Begin forwarded message:

> From: Liaison Statement Management Tool <[email-masked]>
> Subject: New Liaison Statement, "Broadband Forum Work on “Hybrid Access for Broadband Networks” (WT-348)"
> Date: October 21, 2014 at 12:06:52 PM GMT-4
> To: The IETF Chair <[email-masked]>
> Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, The IESG <[email-masked]>, David Sinicrope <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
> 
> Title: Broadband Forum Work on “Hybrid Access for Broadband Networks” (WT-348)
> Submission Date: 2014-10-21
> URL of the IETF Web page: http://datatracker.ietf.org/liaison/1355/
> 
> From: Broadband Forum (Christophe Alter <[email-masked]>)
> To: The IETF (The IETF Chair <[email-masked]>)
> Cc: The IESG <[email-masked]>,David Sinicrope <[email-masked]>,[email-masked],[email-masked],[email-masked],[email-masked],[email-masked],[email-masked],[email-masked]
> Response Contact: 
> Technical Contact: 
> Purpose: For information
> 
> Body: Dear IETF and 3GPP colleagues,
> 
> At the Broadband Forum Meeting held recently in Dublin, Ireland, the End to End Architecture
> Working Group has approved and begun work on a new project called “WT-348 Hybrid Access for
> Broadband Networks” defining architectural requirements to allow coordinated and, when
> needed, simultaneous use of fixed broadband access and 3GPP access networks for
> converged operators.
> 
> The business drivers for this work include enabling service providers to offer faster service
> provisioning and fulfillment, higher throughput and increased WAN reliability.
> 
> We will keep you informed of this work as it progresses.
> 
> The Broadband Forum’s Q4 meeting will be held December 8 - 12, 2014 in Taipei, Taiwan.
> 
> Sincerely,
> Christophe Alter,
> Broadband Forum Technical Committee Chair
> Attachments:
> 
>    Broadband Forum Work on “Hybrid Access for Broadband Networks” (WT-348)
>    https://datatracker.ietf.org/documents/LIAISON/liaison-2014-10-21-broadband-forum-the-ietf-broadband-forum-work-on-hybrid-access-for-broadband-networks-wt-348-attachment-1.pdf

---

From: Michael Richardson <[email-masked]>
Date: Tue, 21 Oct 2014 13:28:38 -0400

>> At the Broadband Forum Meeting held recently in Dublin, Ireland, the
    >> End to End Architecture Working Group has approved and begun work on a
    >> new project called “WT-348 Hybrid Access for Broadband Networks”
    >> defining architectural requirements to allow coordinated and, when
    >> needed, simultaneous use of fixed broadband access and 3GPP access
    >> networks for converged operators.

Always a good idea to continue trying to solve layer-3 problems at layer-2.
Sigh.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Xueli <[email-masked]>
Date: Wed, 22 Oct 2014 09:48:25 +0000

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

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-architecture-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:[email-masked]] 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 <[email-masked]> 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

[email-masked]

https://www.ietf.org/mailman/listinfo/homenet

---

From: <[email-masked]>
Date: Wed, 22 Oct 2014 10:05:10 +0000

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:[email-masked]]
Envoyé : mercredi 22 octobre 2014 11:48
À : Ted Lemon; STARK, BARBARA H
Cc : HOMENET Working Group; [email-masked]
Objet : RE: [homenet] Fwd: New Liaison Statement, "Broadband Forum Work on “Hybrid Access for Broadband Networks” (WT-348)"

Hello

Best Regards

-----Original Message-----

To: STARK, BARBARA H

homenet mailing list

[email-masked]<mailto:[email-masked]>

_________________________________________________________________________________________________________________________

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.

---

From: "Hui Deng" <[email-masked]>
Date: Wed, 22 Oct 2014 18:13:44 +0800

I was thinking how it is related to MPvD, binding is really layer 2 matters, but if u are using DMM, then it could be easily related to MPvD.

-Hui

From: mif [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Wednesday, October 22, 2014 6:05 PM
To: Xueli; Ted Lemon; STARK, BARBARA H
Cc: HOMENET Working Group; [email-masked]; [email-masked]
Subject: [mif] =?Windows-1252?Q?RE:_[homenet]_Fwd:_New_Liaison_Statement, _"Broadband_For?= um Work on “Hybrid Access for Broadband Networks” (WT-348)"

Hi Li,

BR,

Pierrick  

Hello 

 

Best Regards

 

-----Original Message-----

To: STARK, BARBARA H

homenet mailing list

[email-masked]

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Wed, 22 Oct 2014 10:56:03 +0000

<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: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, October 22, 2014 3:05 AM
To: Xueli <[email-masked]<mailto:[email-masked]>>, Ted Lemon <[email-masked]<mailto:[email-masked]>>, "STARK, BARBARA H" <[email-masked]<mailto:[email-masked]>>
Cc: HOMENET Working Group <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
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,

BR,
Pierrick

Cc : HOMENET Working Group; [email-masked]<mailto:[email-masked]>

Hello

Best Regards

-----Original Message-----

To: STARK, BARBARA H

homenet mailing list

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 22 Oct 2014 18:28:16 +0200

Hello Xueli,

Several people look at this problem as an IP problem.  Instead of 
considering a cellular+dsl combination in a homebox, they considered 
cellular+wifi on a smartphone.   But the goal was the same: augment the 
bandwidth perceived by the end user.

In implementation it is however quite challenging.  The more tempting 
the expectations of augmenting bandwidth by simply adding network 
interfaces (as in adding RAM to a busy computer), the higher the 
desillusion when facing the challenges of implementation.

Some consider it simply as a local computer policy problem (and hence no 
new communicaiton standards needed), but others consider that there is a 
need of a server in the infrastructure to which these interfaces would 
first connect (a sort of an 'anchor').

If such a technology is developped, it will surely be useful for more 
than homenets - it will be useful for multi-interfaced smartphones, 
useful for mobile routers installed in vehicles, and more that I can not 
think of.

Alex
PS: there are a few IETF Internet Drafts about how would smartphones 
would use this, with Mobile IPv4 and Mobile IPv6 extensions, but there 
are no widespread implementations.

Le 22/10/2014 11:48, Xueli a écrit :
> (e.g. DSL + LTE) in order to provide higher bandwidth for the
> customers. The scenario and architecture are shown as follows
>
>
> 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-architecture-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.
>
> Now the authors have invited Orange to join this architecture work.
> We will send out the new version of these drafts soon.
>
> Subject: Re: [homenet] Fwd: New Liaison Statement, "Broadband Forum
> Work on “Hybrid Access for Broadband Networks”(WT-348)"
>
>> 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
> [email-masked] https://www.ietf.org/mailman/listinfo/homenet
>

---

From: Xueli <[email-masked]>
Date: Tue, 28 Oct 2014 03:59:14 +0000

Hello Pierrick

First of all, thanks a lot for agree with the big picture depicture and architecture..
I am fine to split the architecture considerations and solution design in two different documents.
And I updated the architecture draft (No specific solution there) in the new version, I hope it makes sense for you.
http://www.ietf.org/internet-drafts/draft-lhwxz-hybrid-access-network-architecture-01.txt
Do you mind to share more about the solution about DMM proposal.
Which exact issues it is really solving?

Best Regards
Li

From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, October 22, 2014 6:05 PM
To: Xueli; Ted Lemon; STARK, BARBARA H
Cc: HOMENET Working Group; [email-masked]; [email-masked]
Subject: RE: [homenet] Fwd: New Liaison Statement, "Broadband Forum Work on “Hybrid Access for Broadband Networks” (WT-348)"

Hi Li,

BR,
Pierrick

Hello

Best Regards

-----Original Message-----

To: STARK, BARBARA H

homenet mailing list

Thank you.

---

From: Xueli <[email-masked]>
Date: Tue, 28 Oct 2014 04:04:47 +0000

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:[email-masked]]
Sent: Wednesday, October 22, 2014 6:56 PM
To: [email-masked]; Xueli; Ted Lemon; STARK, BARBARA H
Cc: HOMENET Working Group; [email-masked]; [email-masked]
Subject: Re: [DMM] RE: [homenet] Fwd: New Liaison Statement, "Broadband For um Work on ³Hybrid Access for Broadband Networks² (WT-348)"

Hi Li,

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

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,

BR,
Pierrick

Objet : RE: [homenet] Fwd: New Liaison Statement, "Broadband Forum Work on "Hybrid Access for Broadband Networks" (WT-348)"

Hello

Best Regards

-----Original Message-----

To: STARK, BARBARA H

Subject: Re: [homenet] Fwd: New Liaison Statement, "Broadband Forum Work on "Hybrid Access for Broadband Networks" (WT-348)"

homenet mailing list

Thank you.

---

From: Xueli <[email-masked]>
Date: Tue, 28 Oct 2014 04:10:57 +0000

Hello Alex

Thank you for your nice comment.
The scenario here is for the fixed operators rather than the mobile phone for higher bandwidth.
I make this clarification in the new version architecture draft as：
” Hosts in the customer site may connect to the Internet through the
   CPE, the 3G/4G network, or both.  In most cases the majority of the
   hosts connects to the Internet through the CPE only and will
   experience slow Internet access when the bandwidth provided by the
   fixed access network is fully utilized (e.g., the traffic over the
   fixed access network reached its maximum capacity or a pre-specified
   threshold set by the operator).  
So we are considering the scenario with CPE extension with multiple access networks.

I would like to know additional information on the internet drafts you mentioned, do you mind to provide more information on this?

Best Regards
Li

-----Original Message-----
From: Alexandru Petrescu [mailto:[email-masked]] 
Sent: Thursday, October 23, 2014 12:28 AM
To: Xueli; Ted Lemon; STARK, BARBARA H
Cc: HOMENET Working Group; [email-masked]
Subject: Re: “Hybrid Access for Broadband Networks” (WT-348)

Hello Xueli,

Several people look at this problem as an IP problem.  Instead of considering a cellular+dsl combination in a homebox, they considered 
cellular+wifi on a smartphone.   But the goal was the same: augment the 
bandwidth perceived by the end user.

In implementation it is however quite challenging.  The more tempting the expectations of augmenting bandwidth by simply adding network interfaces (as in adding RAM to a busy computer), the higher the desillusion when facing the challenges of implementation.

Some consider it simply as a local computer policy problem (and hence no new communicaiton standards needed), but others consider that there is a need of a server in the infrastructure to which these interfaces would first connect (a sort of an 'anchor').

If such a technology is developped, it will surely be useful for more than homenets - it will be useful for multi-interfaced smartphones, useful for mobile routers installed in vehicles, and more that I can not think of.

Alex
PS: there are a few IETF Internet Drafts about how would smartphones would use this, with Mobile IPv4 and Mobile IPv6 extensions, but there are no widespread implementations.

Le 22/10/2014 11:48, Xueli a écrit :
> (http://tools.ietf.org/html/draft-lhwxz-hybrid-access-network-architec
> ture-00  ; ) proposes the architecture and gap analysis.
>
> other candidates, and we would like to have further discussions in the 
> related groups and IETF.
>
>> 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

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Tue, 28 Oct 2014 14:40:58 +0000

*** Trimming the CC list to include only the MIF WG; Removed DMM and homenet lists.

HI Li,

To you question on the Problem Statement that the MIP technologies have addressed, I'd say its the following.

In general, all the Mobile IP class of  protocols have support for access-link bonding. The ability for the anchor and the access gateway (or the anchor and the mobile node) to establish multiple overlay tunnels paths over different access networks, and to negotiate Application-to-Access routing policy is present in those technologies.

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 <[email-masked]<mailto:[email-masked]>>
Date: Monday, October 27, 2014 9:04 PM
To: Sri Gundavelli <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Ted Lemon <[email-masked]<mailto:[email-masked]>>, "STARK, BARBARA H" <[email-masked]<mailto:[email-masked]>>
Cc: HOMENET Working Group <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: [DMM] RE: [homenet] Fwd: New Liaison Statement, "Broadband For um Work on ³Hybrid Access for Broadband Networks² (WT-348)"

Hello Sri

From: Sri Gundavelli (sgundave) [mailto:[email-masked]]
Sent: Wednesday, October 22, 2014 6:56 PM
To: [email-masked]<mailto:[email-masked]>; Xueli; Ted Lemon; STARK, BARBARA H
Cc: HOMENET Working Group; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [DMM] RE: [homenet] Fwd: New Liaison Statement, "Broadband For um Work on ³Hybrid Access for Broadband Networks² (WT-348)"

Hi Li,

Regards
Sri

Hi Li,

BR,
Pierrick

Hello

Best Regards

-----Original Message-----

To: STARK, BARBARA H

homenet mailing list

Thank you.

---

From: "Hui Deng" <[email-masked]>
Date: Tue, 28 Oct 2014 23:10:24 +0800

Hi Sri,

Could you split one session into two different path?

Thanks

-Hui

From: mif [mailto:[email-masked]] On Behalf Of Sri Gundavelli (sgundave)
Sent: Tuesday, October 28, 2014 10:41 PM
To: Xueli; [email-masked]; Ted Lemon; STARK, BARBARA H
Cc: [email-masked]
Subject: Re: [mif] [DMM] RE: [homenet] Fwd: New Liaison Statement, "Broadband For um Work on ³Hybrid Access for Broadband Networks² (WT-348)"

HI Li,

 

   Flow-1
    |
    |Flow-2
    | |
    | |Flow-3              _----_

Regards

Sri

From: Xueli <[email-masked]>
Date: Monday, October 27, 2014 9:04 PM
To: Sri Gundavelli <[email-masked]>, "[email-masked]" <[email-masked]>, Ted Lemon <[email-masked]>, "STARK, BARBARA H" <[email-masked]>
Cc: HOMENET Working Group <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: RE: [DMM] RE: [homenet] Fwd: New Liaison Statement, "Broadband For um Work on ³Hybrid Access for Broadband Networks² (WT-348)"

Hello Sri

Best Regards

Li

Hi Li,

 

Regards

Sri

 

From: "[email-masked]" <[email-masked]>
Date: Wednesday, October 22, 2014 3:05 AM
To: Xueli <[email-masked]>, Ted Lemon <[email-masked]>, "STARK, BARBARA H" <[email-masked]>
Cc: HOMENET Working Group <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
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,

BR,

Pierrick  

Hello 

 

Best Regards

 

-----Original Message-----

To: STARK, BARBARA H

homenet mailing list

[email-masked]

 <https://www.ietf.org/mailman/listinfo/homenet> https://www.ietf.org/mailman/listinfo/homenet

---

From: <[email-masked]>
Date: Tue, 28 Oct 2014 15:19:49 +0000

Hi Hui,

Thus current way to use MIP is to bind an IP flow to one path. However, MIP deals only with path establishment and flow policy negotiations but not on traffic management.  So, once multiple overlay tunnels are established, nothing prevent to split one flow on theses paths. Here, the problem would be on the control of packet distribution: decide how to split traffic, deal with reordering and buffering… which are orthogonal, and tricky, problems to the path establishment, i.e. orthogonal problems to MIP

Pierrick

De : Hui Deng [mailto:[email-masked]]
Envoyé : mardi 28 octobre 2014 16:10
À : 'Sri Gundavelli (sgundave)'; 'Xueli'; SEITE Pierrick IMT/OLN; 'Ted Lemon'; 'STARK, BARBARA H'
Cc : [email-masked]
Objet : RE: [mif] [DMM] RE: [homenet] Fwd: New Liaison Statement, "Broadband For um Work on ³Hybrid Access for Broadband Networks² (WT-348)"

Hi Sri,

Thanks

-Hui

HI Li,

   Flow-1

    |

    |Flow-2

    | |

    | |Flow-3              _----_

    | | |    |           (_      _)          \

    | | |    |             '----'             \

           | |             _----_             /

                         (_      _)

                           '----'

Regards
Sri

Hello Sri

Hi Li,

Regards
Sri

Hi Li,

BR,
Pierrick

Hello

Best Regards

-----Original Message-----

To: STARK, BARBARA H

homenet mailing list

Thank you.

---

From: "Hui Deng" <[email-masked]>
Date: Tue, 28 Oct 2014 23:58:55 +0800

Hi Pierrick,

I agree that IETF might not touch some problems which don’t belong here.

Best regards,

-Hui

From: [email-masked] [mailto:[email-masked]] 
Sent: Tuesday, October 28, 2014 11:20 PM
To: Hui Deng; 'Sri Gundavelli (sgundave)'; 'Xueli'; 'Ted Lemon'; 'STARK, BARBARA H'
Cc: [email-masked]
Subject: RE: [mif] [DMM] RE: [homenet] Fwd: New Liaison Statement, "Broadband For um Work on ³Hybrid Access for Broadband Networks² (WT-348)"

Hi Hui,

Pierrick

Hi Sri,

Thanks

-Hui

HI Li,

 

   Flow-1
    |
    |Flow-2
    | |
    | |Flow-3              _----_

Regards

Sri

Hello Sri

Best Regards

Li

Hi Li,

 

Regards

Sri

 

Hi Li,

BR,

Pierrick  

Hello 

 

Best Regards

 

-----Original Message-----

To: STARK, BARBARA H

homenet mailing list

[email-masked]

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Tue, 28 Oct 2014 16:22:27 +0000

Hi Hui,

Adding to what Pierrick said.

The IP Flow Mobility support in MIP protocols have the traffic flow policy at the granularity of the flow level. The IETF Transport group in general is not in favor of performing per-packet load balancing; If the links in question have different characteristics then it will kill the application performance; will result in requiring large buffer to handle packet re-ordering. But, if need be, we can turn-on such per-packet load balancing capability, but I'm not sure why any would do that. Some text from MIP specs.

   Most IP devices support the two alternative traffic load-balancing
   schemes, Per-flow and Per-packet load balancing.  These load
   balancing schemes allow the forwarding device to evenly distribute
   traffic based on the criteria of per-packet or on a per-flow basis,
   across all the available equal-cost links through which a destination
   can be reached.  The default forwarding behavior of Per-flow load
   balancing will ensure a given flow always takes the same path and
   will eliminate any packet re-ordering issues and that is critical for
   delay sensitive traffic.  Whereas the per-destination load balancing
   scheme leverages all the paths much more affectively, but with the
   potential issue of packet re-ordering on the receiver end.  A host
   can choose to enable any of these approaches.

Regards
Sri

From: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, October 28, 2014 8:19 AM
To: Hui Deng <[email-masked]<mailto:[email-masked]>>, Sri Gundavelli <[email-masked]<mailto:[email-masked]>>, 'Xueli' <[email-masked]<mailto:[email-masked]>>, 'Ted Lemon' <[email-masked]<mailto:[email-masked]>>, "'STARK, BARBARA H'" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: [mif] [DMM] RE: [homenet] Fwd: New Liaison Statement, "Broadband For um Work on ³Hybrid Access for Broadband Networks² (WT-348)"

Hi Hui,

Pierrick

Cc : [email-masked]<mailto:[email-masked]>

Hi Sri,

Thanks

-Hui

From: mif [mailto:[email-masked]] On Behalf Of Sri Gundavelli (sgundave)
Sent: Tuesday, October 28, 2014 10:41 PM
To: Xueli; [email-masked]<mailto:[email-masked]>; Ted Lemon; STARK, BARBARA H
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [mif] [DMM] RE: [homenet] Fwd: New Liaison Statement, "Broadband For um Work on ³Hybrid Access for Broadband Networks² (WT-348)"

HI Li,

   Flow-1

    |

    |Flow-2

    | |

    | |Flow-3              _----_

    | | |    |           (_      _)          \

    | | |    |             '----'             \

           | |             _----_             /

                         (_      _)

                           '----'

Regards
Sri

Hello Sri

Hi Li,

Regards
Sri

Hi Li,

BR,
Pierrick

Hello

Best Regards

-----Original Message-----

To: STARK, BARBARA H

homenet mailing list

Thank you.

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 29 Oct 2014 10:51:24 +0100

Hello Hui,

Please allow me to comment here.  The flow management concept used in 
Mobile IP protocol extensions would bind one flow per one IP address, or 
to one interface in some circumstances.  For example: do web browsing on 
wifi and a VoIP call on cellular.  This has clear advantages in terms of 
bandwidth utilization.  It may also be highly appreciated by 
inter-operator deals.

Is the BF considering same context?  Or is BF needing fine-grained 
per-packet(?) load balancing between interfaces to brutely augment 
bandwidth independent of application kind?

A policy to specify per-packet load-balancing is not really a 
communication protocol, but rather an algorithm executed within one 
single computer.

On another hand, setting up simultaneously several IP tunnels between an 
end node and a server in the infrastructure, exchanging tunnel 
parameters such as multiple local and remote addresses, tunnel types, in 
a single Mobile IP Registration Request or Binding Update, is something 
that could be worked on to render servers and end nodes inter-operable. 
  It would go beyond the traditional Mobile IP concepts of flow 
management and multiple CoA.

Alex

Le 28/10/2014 16:10, Hui Deng a écrit :
> *From:*mif [mailto:[email-masked]] *On Behalf Of *Sri
> Gundavelli (sgundave) *Sent:* Tuesday, October 28, 2014 10:41 PM
> *To:* Xueli; [email-masked]; Ted Lemon; STARK, BARBARA H
> *Cc:* [email-masked] *Subject:* Re: [mif] [DMM] RE: [homenet] Fwd: New
> Liaison Statement, "Broadband For um Work on ³Hybrid Access for
> Broadband Networks² (WT-348)"
>
> To you question on the Problem Statement that the MIP technologies
> have addressed, I'd say its the following.
>
> In general, all the Mobile IP class of  protocols have support for
> access-link bonding. The ability for the anchor and the access
> gateway (or the anchor and the mobile node) to establish multiple
> overlay tunnels paths over different access networks, and to
> negotiate Application-to-Access routing policy is present in those
> technologies.
>
> *From: *Xueli <[email-masked] <mailto:[email-masked]>> *Date:
> *Monday, October 27, 2014 9:04 PM *To: *Sri Gundavelli
> <[email-masked] <mailto:[email-masked]>>,
> "[email-masked] <mailto:[email-masked]>"
> <[email-masked] <mailto:[email-masked]>>, Ted
> Lemon <[email-masked] <mailto:[email-masked]>>, "STARK,
>  BARBARA H" <[email-masked] <mailto:[email-masked]>> *Cc: *HOMENET
> Working Group <[email-masked] <mailto:[email-masked]>>,
> "[email-masked] <mailto:[email-masked]>" <[email-masked]
> <mailto:[email-masked]>>, "[email-masked] <mailto:[email-masked]>"
> <[email-masked] <mailto:[email-masked]>> *Subject: *RE: [DMM] RE:
> [homenet] Fwd: New Liaison Statement, "Broadband For um Work on
> ³Hybrid Access for Broadband Networks² (WT-348)"
>
> Hello Sri
>
>  There are some new  requirements about the hybrid access topic, such
> as bonding, traffic policy distribution etc.
>
> 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:[email-masked]] *Sent:*
> Wednesday, October 22, 2014 6:56 PM *To:* [email-masked]
> <mailto:[email-masked]>; Xueli; Ted Lemon; STARK, BARBARA
> H *Cc:* HOMENET Working Group; [email-masked] <mailto:[email-masked]>;
> [email-masked] <mailto:[email-masked]> *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: *"[email-masked]
> <mailto:[email-masked]>" <[email-masked]
> <mailto:[email-masked]>> *Date: *Wednesday, October 22,
> 2014 3:05 AM *To: *Xueli <[email-masked]
> <mailto:[email-masked]>>, Ted Lemon <[email-masked]
> <mailto:[email-masked]>>, "STARK, BARBARA H" <[email-masked]
> <mailto:[email-masked]>> *Cc: *HOMENET Working Group
> <[email-masked] <mailto:[email-masked]>>, "[email-masked]
> <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>,
> "[email-masked] <mailto:[email-masked]>" <[email-masked]
> <mailto:[email-masked]>> *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:[email-masked]] *Envoyé :* mercredi 22 octobre
> 2014 11:48 *À :* Ted Lemon; STARK, BARBARA H *Cc :* HOMENET Working
> Group; [email-masked] <mailto:[email-masked]> *Objet :* RE: [homenet]
> Fwd: New Liaison Statement, "Broadband Forum Work on “Hybrid Access
> for Broadband Networks” (WT-348)"
>
> Hello
>
>> of multiple interfaces that are under the control of a single
>> service provider. I don't see this in mif or homenet.
>
> [email-masked] <mailto:[email-masked]>
>
> 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,
>
> This message and its attachments may contain confidential or
> privileged information that may be protected by law;
>
> If you have received this email in error, please notify the sender
> and delete this message and its attachments.
>
> _______________________________________________ mif mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/mif
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 29 Oct 2014 10:59:38 +0100

Hi Pierrick, I agree fully.   Just one comment:

Le 28/10/2014 16:19, [email-masked] a écrit :
> Hi Hui,
>
> Thus current way to use MIP is to bind an IP flow to one path.
> However, MIP deals only with path establishment

MIP deals with single path establishments, and not simultaneous paths
establishments.

MIP sets up a tunnel on the MR and HA that has a single HoA and may have
multiple CoA.  MIP can not set multiple tunnels, each with its own HoA
and CoA, and can not set more than 2 addresses per one tunnel.

Probably most importantly, when using MIP one still uses one single
default route towards one single of these tunnel interfaces at a time.
Application-independent bandwidth augmentation would need a default
route to be used towards multiple tunnels, maybe in a round-robin
fashion for each outgoing IP packet (independent of application).

> and flow policy negotiations but not on traffic management.

I agree.

> So, once multiple overlay tunnels are established, nothing prevent
> to split one flow on theses paths.

I agree, but currently MIP does not tell how to establish multiple
tunnels.  It does not even tell to which of these tunnels to set the
default route.

> Here, the problem would be on the control of packet distribution:
> decide how to split traffic, deal with reordering and buffering…
> which are orthogonal, and tricky, problems to the path establishment,
> i.e. orthogonal problems to MIP

I fully agree.

Alex

>
> Pierrick
>
> *De :*Hui Deng [mailto:[email-masked]] *Envoyé :* mardi 28
> octobre 2014 16:10 *À :* 'Sri Gundavelli (sgundave)'; 'Xueli'; SEITE
> Pierrick IMT/OLN; 'Ted Lemon'; 'STARK, BARBARA H' *Cc :* [email-masked]
> *Objet :* RE: [mif] [DMM] RE: [homenet] Fwd: New Liaison Statement,
> "Broadband For um Work on ³Hybrid Access for Broadband Networks²
> (WT-348)"
>
> Hi Sri,
>
> Lemon <[email-masked] <mailto:[email-masked]>>,
> "STARK, BARBARA H" <[email-masked] <mailto:[email-masked]>> *Cc:
> *HOMENET Working Group <[email-masked] <mailto:[email-masked]>>,
> [email-masked] <mailto:[email-masked]> *Subject:* Re: [DMM] RE:
> 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
> 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
>
> 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
>
> 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.
>
>> 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.
>
> As emails may be altered, Orange is not liable for messages that
> have been modified, changed or falsified.
>
> Thank you.
>
> 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.
>
> 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.
>
>
>

---

From: Xueli <[email-masked]>
Date: Wed, 29 Oct 2014 10:02:16 +0000

Hello Sri

Thanks for your information.
Please see my reply in line.

Best Regards
Li

HI Li,

To you question on the Problem Statement that the MIP technologies have addressed, I'd say its the following.
[xueli] I assume that you agree with the hybrid architecture and requirements, right?
If yes, then let’s discuss the potential solutions.
There are still some gaps in MIP. Please see my next response.

In general, all the Mobile IP class of  protocols have support for access-link bonding. The ability for the anchor and the access gateway (or the anchor and the mobile node) to establish multiple overlay tunnels paths over different access networks, and to negotiate Application-to-Access routing policy is present in those technologies.
[xueli] First of all, right now, hybrid access scenario is for CPE multihoming or multiple heterogeneous access networks rather than the Mobile node.
The CPE is fixed device, we don't consider CPE mobility scenario.

On the other side, what we need may an overlay tunnel technologies on the data plane.
From the data plane point of view, there are many potential solutions, such as L2TP, GRE, IPinIP (MIP)

The hybrid access gaps are the control plane for traffic management (*This is already mentioned in another discussion email ).
The control issue is the main gap in Hybrid access.
For example, negotiation about the traffic distributions, different access network switch, etc… (mentioned in the architecture draft)
The control plane is missing, also in MIP.

“negotiate Application-to-Access routing policy is present in those technologies. “ Is it the new item just started?

From this point of view, each tunnels (L2TP, GRE, IPinIP (MIP) ). with a extended flexible control plane can apply for hybrid access.
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.
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).

Without distribute control plane, centralized control function can resolve the issue as well.
What do you think?

   Flow-1

    |

    |Flow-2

    | |

    | |Flow-3              _----_

    | | |    |           (_      _)          \

    | | |    |             '----'             \

           | |             _----_             /

                         (_      _)

                           '----'

Regards
Sri

Hello Sri

Hi Li,

Regards
Sri

Hi Li,

BR,
Pierrick

Hello

Best Regards

-----Original Message-----

To: STARK, BARBARA H

homenet mailing list

Thank you.

---

From: "Hui Deng" <[email-masked]>
Date: Wed, 29 Oct 2014 18:18:11 +0800

Hi Alex,

There are two types of argumentation of the bandwidth, one is just adding bandwidth, the other could do policy based traffic steering if the congestion happened.
One traffic flow sometime consume less, other time more. It might need to be offloaded to another connection.

I am not representing the BBF here, Hope Xue Li can help to explain what BBF really wants here.

Best regards,

-Hui

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

Hello Hui,

Please allow me to comment here.  The flow management concept used in Mobile IP protocol extensions would bind one flow per one IP address, or to one interface in some circumstances.  For example: do web browsing on wifi and a VoIP call on cellular.  This has clear advantages in terms of bandwidth utilization.  It may also be highly appreciated by inter-operator deals.

Is the BF considering same context?  Or is BF needing fine-grained
per-packet(?) load balancing between interfaces to brutely augment bandwidth independent of application kind?

A policy to specify per-packet load-balancing is not really a communication protocol, but rather an algorithm executed within one single computer.

On another hand, setting up simultaneously several IP tunnels between an end node and a server in the infrastructure, exchanging tunnel parameters such as multiple local and remote addresses, tunnel types, in a single Mobile IP Registration Request or Binding Update, is something that could be worked on to render servers and end nodes inter-operable. 
  It would go beyond the traditional Mobile IP concepts of flow management and multiple CoA.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 29 Oct 2014 15:23:22 +0100

Le 28/10/2014 05:10, Xueli a écrit :
> Hello Alex
>
> Thank you for your nice comment. The scenario here is for the fixed
> operators rather than the mobile phone for higher bandwidth. I make
> this clarification in the new version architecture draft as： ” Hosts
> in the customer site may connect to the Internet through the CPE, the
> 3G/4G network, or both.  In most cases the majority of the hosts
> connects to the Internet through the CPE only and will experience
> slow Internet access when the bandwidth provided by the fixed access
> network is fully utilized (e.g., the traffic over the fixed access
> network reached its maximum capacity or a pre-specified threshold set
> by the operator). So we are considering the scenario with CPE
> extension with multiple access networks.
>
> I would like to know additional information on the internet drafts
> you mentioned, do you mind to provide more information on this?

Sure, it is about these documents;

Flow Binding Support for Mobile IP
draft-ietf-mip4-multiple-tunnel-support-08.txt

Flow Bindings in Mobile IPv6 and Network Mobility (NEMO) Basic Support
RFC 6089

and this post:
https://www.ietf.org/mail-archive/web/mip4/current/msg03728.html

>
> Best Regards Li
>
>
> -----Original Message----- From: Alexandru Petrescu
> [mailto:[email-masked]] Sent: Thursday, October 23,
> 2014 12:28 AM To: Xueli; Ted Lemon; STARK, BARBARA H Cc: HOMENET
> Working Group; [email-masked] Subject: Re: “Hybrid Access for Broadband
> Networks” (WT-348)
>
> Hello Xueli,
>
> cellular+wifi on a smartphone.   But the goal was the same: augment
> the bandwidth perceived by the end user.
>
> Some consider it simply as a local computer policy problem (and hence
> no new communicaiton standards needed), but others consider that
> there is a need of a server in the infrastructure to which these
> interfaces would first connect (a sort of an 'anchor').
>
> useful for mobile routers installed in vehicles, and more that I can
> not think of.
>
> Alex PS: there are a few IETF Internet Drafts about how would
> smartphones would use this, with Mobile IPv4 and Mobile IPv6
> extensions, but there are no widespread implementations.
>
>> Now the authors have invited Orange to join this architecture
>> work. We will send out the new version of these drafts soon.
>>
>> Subject: Re: [homenet] Fwd: New Liaison Statement, "Broadband
>> Forum Work on “Hybrid Access for Broadband Networks”(WT-348)"
>>
>>> 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.
>>
>> _______________________________________________ homenet mailing
>> list [email-masked]

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 29 Oct 2014 15:43:57 +0100

(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

> of multiple interfaces that are under the control of a single service
>  provider. I don't see this in mif or homenet.
>

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Wed, 29 Oct 2014 15:36:59 +0000

Hi Li,

> The CPE is fixed device, we don't consider CPE mobility scenario.

It does not matter if the device is a fixed device or a mobile device. There is a general misconception that Mobile IP/PMIP  technology is exclusively for a device roaming in the network. We have many large scale deployments of the technology where the devices are fixed in a given location (devices are bolted), but the key properties of the technology, such as overlay tunnel access, multi-path support, traffic aggregation, multi-tenancy, signaling capability for service property negotiation etc are used.

In this case a Residential gateway with LTE and Wi-Fi interface, or a Mobile Router in rail with Satellite and Cellular access interfaces are used for supporting the exact same requirement. The ability to request a set of  network prefixes for the ingress network from a central anchor, the ability to define access path selection on application basis, or supporting some QoS capabilities are exact the same.

> “negotiate Application-to-Access routing policy is present in those technologies. “ Is it the new item just started?

Its already supported in NEMO/DSMIPv6. Some missing gaps in other other protocol variants can be fixed with some trivial changes.

Sure. We can extend any protocol. But, we have to invest in technologies designed for supporting such use-cases and in technologies which are already supporting such deployments.  If MIP WG's have spent years in designing IP Flow Mobility solutions, it may not sound logical for  Homnet or some other WG to re-publishes the same work with a different title. I'm absolutely not in favor of defining a new GRE Control Protocol either. We will end up defining a new signaling protocol with all semantics borrowed from MIP protocol.

> On the other side, what we need may an overlay tunnel technologies on the data plane.

Ack. MIP gives you just that.

Regards
Sri

Date: Wednesday, October 29, 2014 3:02 AM

Hello Sri

Best Regards
Li

HI Li,

   Flow-1

    |

    |Flow-2

    | |

    | |Flow-3              _----_

    | | |    |           (_      _)          \

    | | |    |             '----'             \

           | |             _----_             /

                         (_      _)

                           '----'

Regards
Sri

Hello Sri

Hi Li,

Regards
Sri

Hi Li,

BR,
Pierrick

Hello

Best Regards

-----Original Message-----

To: STARK, BARBARA H

homenet mailing list

Thank you.

---

From: Xueli <[email-masked]>
Date: Thu, 30 Oct 2014 08:34:04 +0000

Hello Alex and Hui

Both per-flow and per-packet distribution are considered in BBF.

Per-flow is a easy way to distribute the traffic into different access network.
In per-flow management the traffic from the host can be distributed to two
Or more accesses (Fixed and 3g/4g). It is a easy way to achieve. On the other side
flow-based is an approximate way to utilize both bandwidth, it is depends on the 
balance between the bandwidth each of flows requested and the quantities of flows
There should be big flow in the network. it may introduce the congestion.

However, per-packet distribution allows to use in the best way the bandwidth 
available across multiple paths. Reorder is needed. The per-packet is only 
applied to jitter insensitive traffic, such as Internet traffic or low priority traffic service.

Per-packet and per-flow can be applied together at the same time, use per-flow for high priority
 flows, and per-packet for high bandwidth and jitter insensitive applications.

Best Regards
Li

>From: Hui Deng [mailto:[email-masked]]
>Sent: Wednesday, October 29, 2014 6:18 PM
>To: 'Alexandru Petrescu'; 'Sri Gundavelli (sgundave)'; Xueli;
>[email-masked]; 'Ted Lemon'; 'STARK, BARBARA H'
>Cc: [email-masked]
>Subject: RE: [mif] [DMM] RE: [homenet] Fwd: New Liaison Statement,
>There are two types of argumentation of the bandwidth, one is just adding
>bandwidth, the other could do policy based traffic steering if the
>congestion happened.
>Subject: Re: [mif] [DMM] RE: [homenet] Fwd: New Liaison Statement,
>bandwidth utilization.  It may also be highly appreciated by inter-operator
>deals.
>
>A policy to specify per-packet load-balancing is not really a communication
>protocol, but rather an algorithm executed within one single computer.
>
>end node and a server in the infrastructure, exchanging tunnel parameters
>such as multiple local and remote addresses, tunnel types, in a single
>Mobile IP Registration Request or Binding Update, is something that could
>be worked on to render servers and end nodes inter-operable.
>[homenet]
>_______________________________________________________________
>__________________________________________________________
>>
>>
>>
>>

---

From: Xueli <[email-masked]>
Date: Thu, 30 Oct 2014 08:46:27 +0000

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:[email-masked]] 
Sent: Wednesday, October 29, 2014 10:44 PM
To: Xueli; Sri Gundavelli (sgundave); [email-masked]; Ted Lemon; STARK, BARBARA H
Cc: [email-masked]
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)

> 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.

> If we consider this like a distribution way based on the control plane 
> between the CPE and HA( as shown in your figure.)
>
> My question is why we don't extend L2TP control plane or GRE control  

Well...

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).

> tunnel's data plane, all can be fixed (L2TP, GRE, IPInIP,MIP).

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

> <mailto:[email-masked]>; Xueli; Ted Lemon; STARK, BARBARA H 
> *Cc:* HOMENET Working Group; [email-masked] <mailto:[email-masked]>; 
> <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.
> 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.
>
> 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.
> 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
>
> 2014 3:05 AM *To: *Xueli <[email-masked] <mailto:[email-masked]>>, 
> Ted Lemon <[email-masked] <mailto:[email-masked]>>, 
> <[email-masked] <mailto:[email-masked]>> *Subject: *[DMM] 
> _"Broadband_For?= um Work on "Hybrid Access for Broadband Networks"
> (WT-348)"
>
> Hi Li,
>
> Fwd: New Liaison Statement, "Broadband Forum Work on "Hybrid Access 
> for Broadband Networks" (WT-348)"
>
> Hello
>
> Work on "Hybrid Access for Broadband Networks"(WT-348)"
>
> ______________________________________________________________________
> ___________________________________________________
>
>
>
>
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez 
> recu ce message par erreur, veuillez le signaler
>

---

From: "Hui Deng" <[email-masked]>
Date: Fri, 31 Oct 2014 20:50:12 +0800

Hi everybody

I am recommending that Xue Li could help to put down the slide for the problem statement from BBF. 

And MIP/NEMO proponents (Pierrick, Alex, Sri) and Xue Li could kindly to meet together during IETF meeting

to discuss by adding s thelide about how today solutions meet the requirement or there are some gap still, and whether that problem should be solvable in IETF.

Chairs will talk with AD whether MIF or somewhere else will consider to discuss those issues during the f2f session.

Best regards,

-Hui