Building a Better Road

Page 1 / 2   >   >>
DCITDave 12/5/2012 | 4:53:13 PM
re: Building a Better Road

Let's shoot it again where Stan interviews himself like David Byrne in "Stop Making Sense".

digits 12/5/2012 | 4:53:13 PM
re: Building a Better Road

Psycho Killer?

tmmarvel 12/5/2012 | 4:53:11 PM
re: Building a Better Road

SDH/SONET networks being migrated to MPLS-TP networks?

SDH is a Layer 1 protocol. MPLS-TP is a Layer 2 protocol. L1 and L2 have different roles in networking, and a L2 protocol cannot take care of L1 functionality (or v.v.).

Certainly there is a need for streamlined L2 MPLS switching protocol, such that does not depend on (in practice, proprietary) L3 IP based signaling protocols for its configuration. So MPLS-TP switching will likely become more popular -- in terms of market share %s, at least in part at expense of previous generation of IP-dependent MPLS switching.

And while more sophisticated L2 packet-switched services (e.g. MPLS-TP LSPs, VPNs) can emulate L1 connection based private lines, any L2 protocols will still technically operate above a L1 protocol of one type or another.  As such, though in terms of classes of networking equipment being marketed and deployed, L2 MPLS-TP switches (LSRs) with integrated L1 muxing and transmission capabilities will likely become increasingly popular vs. pure-play L1 muxes etc., no L1 protocols are actually being replaced with MPLS-TP (or any other protocol of L2).

MPLS-TP, as a L2 network manageable through the service provider's management plane (rather than through the IP routers' control plane), thus allows migrating traditional L1 *services* (e.g. SDH VC-n paths) to L2 packet-switched abstractions (LSPs) emulating them, rather than causes migration of networks of any given L1 protocol to MPLS-TP. 

Instead of replacing any L1 protocol, the emergence of L2 MPLS-TP is causing a change in what is needed from L1 protocols: Whereas the essential L1 functionality used to involve (semi-permanently configured) time division multiplexing, it now involves radically more cost efficient physical layer capacity services. The new L1 needs to adapt its capacity allocation according to the realtime bandwidth demands of the packet-switched L2 services, e.g. MPLS-TP LSPs/VPNs. 

paolo.franzoi 12/5/2012 | 4:53:10 PM
re: Building a Better Road

"The new L1 needs to adapt its capacity allocation according to the realtime bandwidth demands of the packet-switched L2 services, e.g. MPLS-TP LSPs/VPNs."

You mean like say....Ethernet?


tmmarvel 12/5/2012 | 4:53:09 PM
re: Building a Better Road

I'm referring to as L1 the layer below packet-switching. ODUflex seems to be going toward the direction I indicated, though a more automated and universal approach will likely be needed eventually. As a *concept*, NSN's Liquid Net seems to incorporate elements of the new approach for carrying rapidly and unpredictably fluctuating packet traffic loads:



paolo.franzoi 12/5/2012 | 4:53:08 PM
re: Building a Better Road

I am referring to Ethernet (say 10Gb or 100 Gb) as a Layer 1 with Layer 2 that allows for statistical multiplexing and dynamic bandwidth assignment.  If the vast bulk of the traffic is IP then tunnel the TDM over Ethernet.

Why get complex?



tmmarvel 12/5/2012 | 4:53:00 PM
re: Building a Better Road

The discussion here started about the notion of "migration to MPLS-TP". MPLS-TP is a low-level (L2) packet-switching protocol, so there isn't any need to carry MPLS-TP traffic over yet another packet-switching protocol, e.g. Ethernet. Rather, to most cost efficiently carry MPLS-TP traffic a true circuit based L1 protocol is needed (avoiding the need for any packet layer processing transit nodes), though this new L1 should be not impose fixed bandwidth connections as the packet based (e.g. MPLS-TP) traffic flows have time-variable bandwidth demands, even if policed to comply to maximum bandwidth specs over longer time periods.

Also, as we move to ever higher transmission bandwidths, packet layer processing based on any protocol (incl. Ethernet, which is actually more complex than MPLS-TP for forwarding) will become increasingly challenging to implement. This is in particular true as there is a need for greater customization of L1-L2 functionality and demand for quick time to revenues, calling for FPGA instead of ASIC based hardware. With actual circuit based L1 based traffic switching, one only needs to deal with timeslot mapping, irrespective of the L2 packet content on the timeslot based channels. The challenge is to make the L1 circuits more bandwidth efficient for packetized client traffic.

paolo.franzoi 12/5/2012 | 4:52:59 PM
re: Building a Better Road


Let's look at the silicon problem. 

If you are going to build MPLS-TP switch devices, you need huge volume to be able to do this.  If there are not multiple switch chip vendors, then the devices will not commoditize.  So, now you need multiple high speed switch fabric vendors to build this stuff (see the problem with Network Processors).  So, let us say for giggles that is PMC and Broadcomm.

Over yonder, somebody keeps building faster and faster Ethernet switches for all the spaces that Ethernet plays in.  Lots of people do this and so the prices on those devices crater. 

Now you a carrier can buy all kinds of things...and your comment about more difficult forwarding decisions are valid.  But unless there is a huge silicon cost around it, then MPLS-TP will become not the next Frame Relay but instead the next ATM.

As geometries move smaller, there are not going to be MORE devices and architectures but FEWER.  To propogate a silicon market for a niche play like MPLS-TP can fail - EVEN if everybody thinks its neato peachy keen.  On the other hand sloppy ole Ethernet chugs along because EVERYBODY invests in Ethernet.



jmunn 12/5/2012 | 4:52:59 PM
re: Building a Better Road

So, are you suggesting some other L1 than OTN or Ethernet?

The other legacy L1 that actually fits your description is some sort of HDLC protocol.

If so, MPLS-TP becomes the new next-gen FRAME-RELAY!  Fine with me, I am actually old enough to remember when Frame Relay started.  Frame Relay came about as a cost/feature reduced alternative to X.25.


Page 1 / 2   >   >>
Sign In