Subject: [i2rs] Discussion of mobile backhaul Use case

From: "Susan Hares" <[email-masked]>
Date: Wed, 5 Mar 2014 06:27:33 -0500

Hi all: 

It appears that we will not be able to have any discussion of the mobile
backhaul use case today during the I2RS meeting: 

https://datatracker.ietf.org/doc/draft-zhang-i2rs-mbb-usecases/

I invite any people at IETF 89 who want to talk about I2RS to join me at the
IETF Registration desk for a BAR BOF.    I'll buy the first beer.

Sue

---

From: "Susan Hares" <[email-masked]>
Date: Thu, 6 Mar 2014 05:01:33 -0500

During the last two weeks, people have indicated interested in mobile
backhaul cases.    We would appreciate input on the following draft:

If you are interested in chatting about this draft would you please contact
me ([email-masked]). For those who are at the IETF and would like to talk
about MBB over beer, join us at the IETF registration desk at 7:30pm
(Thursday 3/6/14). 

Sue Hares

---

From: Dean Bogdanovic <[email-masked]>
Date: Mon, 24 Mar 2014 14:01:13 +0000

Susan,

In chapter 2 Definitions there is a copy/paste error I presume

   PWE3: Pseudo Wire Emulation Edge-to-Edge

   EPC: Pseudo Wire Emulation Edge-to-Edge

Presume that EPC = Evolved Packet Core

Have several comments for the rest of the draft, as it is somewhat  not clearly written. I can't figure out what is the plan for the access and what for the aggregation networks in mobile backhaul.

In Application configuration chapter 3.1,

the draft talks about protecting legacy radio networks, but it doesn't discuss that todays MBH are designs, access (hub and spoke) and aggregation networks (rings with IP/MPLS and IGP, mostly OSPF, overlay).

In same chapter,

The radio architecture evolution will bring out new radio interfaces,
such as the X2 interface in LTE which will not work in hub-spoke
communication mode and needs much more shorter latency.

Introduction of X2 shortens the latency for control and data traffic, as now eNodeBs can communicate directly, not as before via RNC. With X2 interfaces, can create mesh topology in MBH access part, which allows multi path to EPC from each eNodeB.
With introduction of 5G networks, as spectrum allocation will be dynamic, the bandwidth requirements will fluctuate from different areas, depending on the allocated spectrum to the eNodeBs.

2. various radio applications
next gen networks (actually this was definition and requirement for 4G) are IP networks, so real-time applications like voice and video should be IP applications, not really radio applications. The classifications for traffic should be real-time, near-realtime non-real time user traffic and control traffic. As radio should carry only data and signaling, there should be no other differentiation.

3.  various network architectures:

The mobile backhaul network maybe consist of hundreds of nodes
in a small county or thousands of nodes in a populous region.
It will be an integration of different ASNs rather than a
single AS, when EPC is deployed in the Core network with LTE.
The network devices on different points of the network (e.g.
access\aggregation\core) have different routing and protocol
processing capabilities, resulting in an integration of
different IGP routing areas rather than a single large IGP
routing area.  Within various network architectures, different
service modes should be provided, such as SS- PW or MS-PW, E2E
L3VPN or HVPN, Seamless MPLS, and the integration of them.

Can you please clarify this chapter? MBH topologies today are very much geographically created and connected to the core, so for example network operator in Boston will have access and aggregation network connected to the core in Boston and this will be within single AS. The edge device between aggregation and core  is connected to multiple ASNs, but not devices with access and aggregation networks? Do you expect to see devices in access networks to be connected to different ASNs?

In 3.2 are you looking to use BGP as IGP and EGP protocol? Why not run IGP in access networks, as those are mesh topologies with X2 interfaces, especially as X2 has same S1 characteristics for E-UTRAN service continuation. Also eNodeBs will be often connected via wireless connections (microwave), so using an IGP in access part of the mobile backhaul should be considered and how to manipulate certain metrics based on the wireless backhaul portion performance.

Do you presume running pseudo wires all the way through the access portion of MBH or just to the pre-aggregation site?

If you could clarify the network topology in mind, that would be helpful.

I believe there are different requirements for access and aggregation part of the mobile backhaul for i2rs and that your draft is more applicable to the aggregation part of mobile backhaul.

Regards,

Dean

On Mar 6, 2014, at 5:01 AM, Susan Hares <[email-masked]<mailto:[email-masked]>> wrote:

During the last two weeks, people have indicated interested in mobile backhaul cases.    We would appreciate input on the following draft:

If you are interested in chatting about this draft would you please contact me ([email-masked]<mailto:[email-masked]>). For those who are at the IETF and would like to talk about MBB over beer, join us at the IETF registration desk at 7:30pm (Thursday 3/6/14).

Sue Hares

<Untitled attachment 00301.txt>_______________________________________________
i2rs mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/i2rs

---

From: "Susan Hares" <[email-masked]>
Date: Mon, 24 Mar 2014 11:08:18 -0400

Dean:

Thank you for the review.  I Let me consider this comments for a day. 

Sue 

From: i2rs [mailto:[email-masked]] On Behalf Of Dean Bogdanovic
Sent: Monday, March 24, 2014 10:01 AM
To: Susan Hares
Cc: <[email-masked]>
Subject: Re: [i2rs] Discussion of mobile backhaul Use case

Susan, 

Have several comments for the rest of the draft, as it is somewhat  not
clearly written. I can't figure out what is the plan for the access and what
for the aggregation networks in mobile backhaul. 

the draft talks about protecting legacy radio networks, but it doesn't
discuss that todays MBH are designs, access (hub and spoke) and aggregation
networks (rings with IP/MPLS and IGP, mostly OSPF, overlay).

In same chapter, 

Introduction of X2 shortens the latency for control and data traffic, as now
eNodeBs can communicate directly, not as before via RNC. With X2 interfaces,
can create mesh topology in MBH access part, which allows multi path to EPC
from each eNodeB.

With introduction of 5G networks, as spectrum allocation will be dynamic,
the bandwidth requirements will fluctuate from different areas, depending on
the allocated spectrum to the eNodeBs.

next gen networks (actually this was definition and requirement for 4G) are
IP networks, so real-time applications like voice and video should be IP
applications, not really radio applications. The classifications for traffic
should be real-time, near-realtime non-real time user traffic and control
traffic. As radio should carry only data and signaling, there should be no
other differentiation.

Can you please clarify this chapter? MBH topologies today are very much
geographically created and connected to the core, so for example network
operator in Boston will have access and aggregation network connected to the
core in Boston and this will be within single AS. The edge device between
aggregation and core  is connected to multiple ASNs, but not devices with
access and aggregation networks? Do you expect to see devices in access
networks to be connected to different ASNs?

In 3.2 are you looking to use BGP as IGP and EGP protocol? Why not run IGP
in access networks, as those are mesh topologies with X2 interfaces,
especially as X2 has same S1 characteristics for E-UTRAN service
continuation. Also eNodeBs will be often connected via wireless connections
(microwave), so using an IGP in access part of the mobile backhaul should be
considered and how to manipulate certain metrics based on the wireless
backhaul portion performance.

Do you presume running pseudo wires all the way through the access portion
of MBH or just to the pre-aggregation site?

I believe there are different requirements for access and aggregation part
of the mobile backhaul for i2rs and that your draft is more applicable to
the aggregation part of mobile backhaul.

Regards,

Dean

On Mar 6, 2014, at 5:01 AM, Susan Hares <[email-masked]> wrote:

 <https://datatracker.ietf.org/doc/draft-zhang-i2rs-mbb-usecases/>
https://datatracker.ietf.org/doc/draft-zhang-i2rs-mbb-usecases/

If you are interested in chatting about this draft would you please contact
me ( <mailto:[email-masked]> [email-masked]). For those who are at the
IETF and would like to talk about MBB over beer, join us at the IETF
registration desk at 7:30pm (Thursday 3/6/14).

Sue Hares

<Untitled attachment
00301.txt>_______________________________________________
i2rs mailing list
[email-masked]
 <https://www.ietf.org/mailman/listinfo/i2rs>
https://www.ietf.org/mailman/listinfo/i2rs