x
<<   <   Page 3 / 14   >   >>
^Eagle^ 12/5/2012 | 3:39:28 AM
re: BT Rethinks 21CN Core Strategy folks, it seems to me that the posts here are missing a key fundamental point. As someone who's Ethernet experience goes back to the BEGINNING of Ethernet (back when it was an uncertain thing that Ethernet would win out over Token Ring or ArcNet or FDDI) and who has traveled with the industry as it has evolved from a small LAN networking protocol into switched ethernet up to now 1GigE and 10GigE over both LAN, campus, MAN, Metro, and Long haul networks; I want to point out something that SHOULD be obvious to networkers on this post.

BOTH MPLS and PBT are transported over Ethernet! Ethernet is a transport layer interface encompassing framing, timing, deals with collisions, etc. Ethernet itself can transport MANY kinds of data or packets if you will. MPLS and PBT are both protocols that run over Ethernet (or in case of MPLS, it can run OVER Ethernet or over SDH / Sonet or over wireless if you want to go that way. MPLS is a protocol (along with diffserv, etc.)

So the arguments on this board are getting lost in the forest so to speak.

The reason for all multiplexing services is scarcity of bandwidth. The reason Ethernet keeps winning is that as more bandwidth is deployed, the need for expensive routing solutions or other solutions to maximize utilization of scarce bandwidth.

ATM did this in the WAN. Before that Stat muxes did this in the WAN.

If you look at the history of Ethernet, routers were born for 2 primary reasons: you had to segment your ethernet in the lan as you had more and more users contending for same bandwidth, and you were trying to carry many different protocols across that bandwidth.

The reason ethernet switches came to dominate the LAN is it is cheaper to switch ethernet packets than to route them. Routers have a LOT of processing overhead and associated over engineering to deal with buffering packet streams and to deal with having to examine and PROCESS every packet.

Ethernet switches started to eat into router sales and hence Cisco bought Crescendo and several others to gain access to SWITCHING of packets instead of routing them.

PBT was not invented (or proposed is a better way to say it... the idea has been around for several years!) sooner because of scarcity of transport bandwidth. (oh yes, the telco's would sell you more bandwidth, but at a cost that made scarcity a virtual reality). In a scarce bandwidth scenario, you need ways to prioritize, re-use, and re allowcate traffic based on certain flags or bits or labels. MPLS does this and also adds OAM, quality, monitoring, etc.

However with fat pipes in the core and with the advent of 10GigE, the datacom world and telecom world finally have a bit rate or bit speed that is the same: OC192 and 10GigE are both 10g services.

In the same way a flatter architecture, with out all the need for ROUTING (which means processing every packet) and without the need for routers to use bandwidth for updating routing tables (routers use a significant % of available bandwidth for self discovery of link status, routing table updates, etc.) and routers are expensive for this very reason.

With sufficient bandwidth, you can do in transport nets what was done in the enterprise: use switches in most locations and reduce the number of high cost, high latency, complex routers.

Complexity reduction and ease of use and robust transport all are features of PBT.

BOTH PBT and MPLS will have place in networks going forward. PBT offers some advantages that are significant to carriers in teh core. Afterall, when Bank of America, or Dell or some other large data customer buys a link from the RBOC / LEC / IXC, do you really think they are putting up and tearing down the link? No, that link stays up and operates as a virtual point to point link. IF that is so, why do all the processing in the core an add the overhead costs of routing and processing every packet. Also note that MPLS core networks will be inherently less reliable (more complexity means more possible failure nodes or failure mechanisms). Simple point to point links across the core helps this situation. Routing where needed, but despite the marketing from Cisco, do you really need them at every single transport node and link.

Again, ETHERNET is transport layer. PBT or MPLS or both can run OVER this transport layer.

switches cost less than routers. Simple equation. And this is especially true in the core where you have to use the most expensive big box routers.

Even for next generation services, do you think that Verizon wants to route every packet carrying IPTV to your home? Since you are not moving your home around and the physical link is fixed over PON or DSL or other, and since you and they both know the TV channels will largely be the same channels you currently get on cable or satellite, why add all the overhead processing where it is not needed? at the edge, where services and service levels are determinid... or in the case of the link for the data services that you get when you surf the web, routers make sense to manage and process the packets. But for steady state links, or links that are fairly predictable, why use the cost of MPLS when a simple ethernet switch will do? Of course companies have to build carrier grade switches and add the requisite qualit of service (OAMP) to the links, and PBT does this. As there is really only one protocol (IP) running, you don't need to have protocol processing and if the links are predictable, you don't need to route them, and if there is sufficient bandwidth, a simple flat topology wins.

Ethernet 101.

sailboat
Say_Yes_2_MPLS 12/5/2012 | 3:39:28 AM
re: BT Rethinks 21CN Core Strategy Sailboat,

Your experience of Ethernet may go back to the GǣBEGINNING of EthernetGǥ but it appears that this experience does not extended to PBT.

PBT is not transported over Ethernet. PBT uses the Ethernet frame structure and switching, i.e. PBT is Ethernet with minimal modifications but used in a connection orientated mode.

When considering PBT it is not a case of switching versus routing. Ethernet in its connectionless mode of operation uses broadcasts and source based learning to forward frames onto the correct destination. Ethernet used in a connection orientated mode requires the path/route from a source to the destination to be calculated before a connection can be established, i.e. PBT requires routing.

Bandwidth availability has no bearing on the decision to use PBT either. Whether you have PBT switches or IP/MPLS routers at the end of your pipes the available bandwidth will be the same. It is the queuing and policing architecture along with the amount of traffic that requires guaranteed delivery will determine how efficiently the bandwidth gets used.

With regards to GǣIn the same way a flatter architecture, with out all the need for ROUTING (which means processing every packet) and without the need for routers to use bandwidth for updating routing tables (routers use a significant % of available bandwidth for self discovery of link status, routing table updates, etc.) and routers are expensive for this very reason.Gǥ this is not correct. Routers today can switch IP and MPLS packets in hardware, which means that every packet does not get processed by the CPU. Also, PBT switches will still need to exchange routing, OAM, and signalling information.

With regards to the assumption that because Gǣswitches cost less than routersGǥ PBT boxes will be cheaper, this isnGt necessarily true. They should be a bit cheaper as they donGt need to support as many protocols/functions, however, they still need to support switching, routing, signalling, OAM as well as carrier class redundancy/reliability.

On the other hand, I do agree with you that GǣComplexity reduction and ease of use and robust transport all are features of PBT.Gǥ As people begin to understand exactly what PBT is (and what it isnGt) I think more people will start to recognise its benefits (i.e. simplicity and reduced opex) and it will start to feature (along side IP/MPLS) in the next generation network plans of more providers.

SY2M.
Say_Yes_2_MPLS 12/5/2012 | 3:39:28 AM
re: BT Rethinks 21CN Core Strategy Gigeguy,

Suggesting that BT Gǣgot roped inGǥ to considering PBT because they think they can reduce capex is incorrect. Capex is a contributing factor but do you really think that capex is the biggest cost consideration for BT or any provider?

From a purely functional perspective, IP+MPLS can do everything that PBT can. However, is IP/MPLS the most cost effective and efficient solution for all services? The connectionless nature of technologies such as LDP and RFC2547 makes troubleshooting and QoS (i.e. guaranteed delivery) extremely complex. Any provider with a large IP/MPLS network will tell you that opex is extremely high compared to that of technologies such as SONET, which essentially provide OAM and guaranteed delivery for free. In the IP/MPLS case the capability to provide OAM and guaranteed delivery (i.e. connections) has to be added in which costs money and increases complexity. In turn, this complexity increases opex, which is the main cost consideration for providers.

As you point out, PBT requires a control plane. However, it doesnGt need to support things like L2TP, IPSEC, MP-BGP, etc. which is what the IP/MPLS control plane supports that you get on a P/PE router. For a distributed PBT control plane solution all thatGs really needed is a routing protocol (e.g. OSPF/IS-IS) and signalling protocol (e.g. RSVP-TE). Reducing the number of functions/protocols required/supported reduces complexity and costs. An alternative to a distributed control plane would be to use a centralised control plane like the one used for SONET networks.

As with MPLS, Ethernet doesnGt have OAM so this needs to be added in which costs money. However, because the Ethernet OAM for PBT only needs to support connections, and because of the way in which the MAC address is used as the connection ID, OAM for PBT can be much simpler than that for MPLS. Again, this reduces complexity and costs.

Using the Ethernet frame structure and switching architecture with minimal changes helps to reduce interface/switching costs due to the economies of scale in the enterprise. However, PBT boxes are not going to be cheap switches because they need processors for routing/signalling (unless a centralised control plane is used), they require OAM support and also need carrier class reliability and redundancy.

In a nutshell, I view PBT as a technology for providing reliable connection orientated transport that offers potential opex savings over more complex technologies such as IP/MPLS due to the simplicity of its control plane and OAM. I see PBT being used in conjunction with IP/MPLS to offer a full range of services with each being use for what its best for (e.g. PBT for P2P guaranteed transport, IP/MPLS for large any-to-any VPNs).

SY2M
Say_Yes_2_MPLS 12/5/2012 | 3:39:28 AM
re: BT Rethinks 21CN Core Strategy Yhza,

You are incorrect.

PBT may solve the same problem that SDH does (i.e. provide connection based transport) but it is not GǣSDH in disguiseGǥ and does not use GǣSDH-like-framingGǥ. SDH uses synchronous transmission and a fixed length frame structure. Ethernet/PBT uses asynchronous transmission and variable length frames.

PBT uses fixed circuits (i.e. connections) but so does MPLS based on RSVP-TE and ATM, so following your argument, are you suggesting that these are also SDH in disguise?

No auto-oversubscription? This comment by itself does not make sense; I assume that you are actually referring to the statistical multiplexing capability of connectionless network technologies. If so you are missing the whole point of PBT G to provide secure, reliable, connections for mission/business critical data. In these scenarios you wouldnGt want to use oversubscription as you want guaranteed delivery. Nonetheless, if an operator wants to use oversubscription at the PBT layer then they can do so by configuring the queues and traffic policies (e.g. based on 802.1p, VLAN ID, MAC address) at the edge/core appropriately.

It would be helpful if you could provide substantiated valid arguments for/against PBT rather list a number of incorrect assumptions to support a simplistic throw away comment. Actually learning about PBT before offering your opinion might help you to achieve this.

SY2M
Say_Yes_2_MPLS 12/5/2012 | 3:39:28 AM
re: BT Rethinks 21CN Core Strategy SolitonWave, PBT was selected as a potential component in BTs next generation network plans based on its technical and potential cost saving merits alone. The guys that first recognised the potential of PBT in BT are the same guys that were instrumental in the development of technologies such as SDH and RFC2547.

To suggest that a carrier investing billions in its next generation network is likely to select and openly support a technology based on a vendors marketing material suggests that you are either not very intelligent or that you work for a competitor.
runnyme 12/5/2012 | 3:39:27 AM
re: BT Rethinks 21CN Core Strategy Exactly. Sailboat seems much younger than he boasted.

I found most of his statements are not correct.
davallan 12/5/2012 | 3:39:26 AM
re: BT Rethinks 21CN Core Strategy Hi Sailboat

Ummm... the transport layer of the OSI model more or less corresponds with TCP/UDP, I do not hink that is quite what you meant.

The 7 layer model in some ways does not work here, as ethernet specifications cover both network, link and PHY, which is where PBT operates. PBT can also be carried over L1 via GFP or other encap.

MPLS fits at about layer 2.5 so needs L3 (OAM etc.) and L1 link to complete itself.

So given where PBT plays in the stack, it does fit the "transport network" function in the sense of being able to assume the role of being a packet version of existing L1 networks, it does not fit the "transport layer" function of the OSI model (per packet reliability/retransmission etc.), nor would it likely be an application of another network....

Different contexts...

Hope that helps
D
^Eagle^ 12/5/2012 | 3:39:26 AM
re: BT Rethinks 21CN Core Strategy in reading my last post, I realize it was not as clear as I had intendend. forgive me for making a rambling post in the wee hours of the morning.

my point was the there is confusion about what layer in the 7 layer stack we are talking about.

Both PBT and MPLS can be transported over several physical layer transport mechanisms. Ethernet is ONE of those. SDH/SONET is one of those. There are others.

There needs to be some more clarity about what exactly is happening here with regards to what layer(s) of the stack we are talking about.

MPLS and PBT BOTH ride on top of the transport layer of the 7 layer stack. Both help determine connection, routing, link, path, etc. But neither of them are a transport layer, they are both protocols running on top of the transport of choice. Both use IP for part of the 7 layer stack.

sailboat
gigeguy 12/5/2012 | 3:39:25 AM
re: BT Rethinks 21CN Core Strategy SY2M,

Generally, you had a series of really good messages. I would just like to address one point in your messages, and answer a question posed by Mark.

1. "In a nutshell, I view PBT as a technology for providing reliable connection orientated transport that offers potential opex savings over more complex technologies such as IP/MPLS due to the simplicity of its control plane and OAM."

Regarding the relative simplicity of PBT OAM, do you really see the combination of 802.1ag and 802.3ah to be simpler than either Y.1711 or MPLS ping and traceroute? I know that simplicity is often in the eye of the beholder, but I don't agree on this point.

2. To answer Mark's question on Ethernet silicon, the problem is that PBT requires a new combination of turning off spanning tree, turning off mac learning, adding manually provisioned switching based on both MAC address and VID, discarding rather than flooding frames with unknown VID+MAC combinations, and supporting 802.1ag and 802.3ah for OAM. Only a small set of current chipsets can support all of these requirements. If people can identify silicon that fits these requirements, please speak up, because the vendors I've asked for the most part say "we're investigating future support."

davallan 12/5/2012 | 3:39:25 AM
re: BT Rethinks 21CN Core Strategy Hi Gigaguy

Have you ever read RFC4379 (MPLS LSP-PING), a true icon of simplicity.

As for PBT, I'll point you at the dot1D static subtree of RFC 4188 (Managed objects for Bridges), it all largely exists....

cheers
D
<<   <   Page 3 / 14   >   >>
HOME
Sign In
SEARCH
CLOSE
MORE
CLOSE