Pseudowires: The Building Blocks to Mobile

and Transport Convergence

Featuring Giles Heron, Senior Technology Specialist
Created seven years ago, the pseudowire standard is a building Additional References (on tellabs.com)
block upon which multiple types of traffic can be layered and
Tellabs® IntegratedMobileSM Solution
then converged onto a single, multipurpose packet-switched
www.tellabs.com/solutions/integratedmobile/tlab_integratedmobile.pdf
network. In 2001, the Internet Engineering Task Force (IETF)
established the Pseudowire Emulation Edge-to-Edge (PWE3) Tellabs Emerge Magazine: Winter 2006-07 - Pseudowire.
working group to develop edge-to-edge pseudowire architec- It’s the real deal.
tures and document service-specific encapsulation techniques. www.tellabs.com/news/emerge/06-07_winter/
Giles Heron, Senior Technology Specialist, and co-collaborator emerge_winter06-07_pseudo.pdf
on the original Martini Draft, discusses the PWE3 industry
standards and how this innovative technology will shape the Tellabs Emerge Magazine - The 3G Roadmap: NextGen Now
networks of the future. www.tellabs.com/news/reprints/emerge_spring07_
nextgennow-reprint.pdf
> To download podcasts, visit www.inspirethenewlife.com

Adaptive Timing Recovered from Synchronization Pseudowire

Adaptive timing
used for timing
recovery from Recovered timing
Synchronization synchronization injected to
Pseudowire pseudowire TDM line signal
8600

Asynchronous
PRC
Metro Ethernet
8600 8600

8600 8600

One Tellabs Center • 1415 West Diehl Road • Naperville, IL 60563 • 630 798 8800 • www.tellabs.com
Statements herein may contain projections or other forward-looking statements regarding future events, products, features, technology and resulting commercial or technological benefits and advantages. These statements are for discussion
purposes only, are subject to change and are not to be construed as instructions, product specifications, guarantees or warranties. Actual results may differ materially. The following trademarks and service marks are owned by Tellabs Operations,
Inc., or its affiliates in the United States and/or other countries: TELLABS®, TELLABS and T symbol®, and T symbol®. Any other company or product names may be trademarks of their respective companies. © 2007 Tellabs. All rights reserved.
Pseudowires: The Building Blocks to Mobile
and Transport Convergence (continued)

Additional References (continued)

Tellabs® IntegratedMobileSM Solution: 2G and 3G Mobile Solutions for ETSI Markets
www.tellabs.com/solutions/integratedmobile/tlab_integratedmobile_primer.pdf

Tellabs® 8600 Managed Edge System

www.tellabs.com/products/8000/tellabs8600.shtml

Tellabs® 8800 Multiservice Router Series

www.tellabs.com/products/8000/tellabs8800.shtml

Martini Draft References now are the RFCs (request for comments):
a RFC4447: Pseudowire Control Plane
a RFC4448: Ethernet Pseudowire Encapsulation
a RFC4717: ATM Pseudowire Encapsulation
http://tools.ietf.org/rfc/

The Tellabs® IntegratedMobileSM Solution

Radio Access Network Mobile Core
T-1 Environment

OEM cell-site aggregator

OEM cell-site aggregator LEC/SONET

Ring
5500
8620

Metro Ethernet, Fiber, SONET, PSTN

8605 MPLS, IP/VPN
8600
8800 8800
IP/MPLS Internet
E-1 Environment

IMS
Metro Ethernet, Fiber, SDH,
MPLS, IP/VPN
8620 8600 8600 8800

8605
Metro Ethernet, 
NG-SDH, MPLS, 
8100 6300 Ethernet-over-SDH 6300

Network Management System

One Tellabs Center • 1415 West Diehl Road • Naperville, IL 60563 • 630 798 8800 • www.tellabs.com
Statements herein may contain projections or other forward-looking statements regarding future events, products, features, technology and resulting commercial or technological benefits and advantages. These statements are for discussion
purposes only, are subject to change and are not to be construed as instructions, product specifications, guarantees or warranties. Actual results may differ materially. The following trademarks and service marks are owned by Tellabs Operations,
Inc., or its affiliates in the United States and/or other countries: TELLABS®, TELLABS and T symbol®, and T symbol®. Any other company or product names may be trademarks of their respective companies. © 2007 Tellabs. All rights reserved.
Podcast Transcript
Pseudowires: The Building Blocks to Mobile and Transport Convergence
Featuring Giles Heron, Senior Technology Specialist
Monsho: What’s up? It’s Monsho here
with today’s session of Get Schooled.
Are you ready for today’s pop quiz?
Okay, here we go.
Are pseudowires: (a) wires used to
monitor your brain activity, (b) a new
TV movie starring Rosie O’Donnell and
Donald Trump, or (c) virtual wires used
to carry different types of traffic?
Don’t know the answer? You’re fired. Sit
up straight and pay attention. It’s time to
get schooled.
Dave Morfas: Hi, I’m Dave Morfas, and
I’m here today with Giles Heron to talk
about pseudowires.
Giles, the first thing we need to cover, I
think, is at the highest level, how do we
describe pseudowires? What exactly are
they?
Giles Heron: Well, Dave, a pseudowire is
really a way of carrying sort of Layer 1 or
Layer 2 information over an MPLS net-
work; so taking stuff that is fundamen-
tally connection-orientated in nature,
whether that’s TDM or ATM or frame
relay or Ethernet, and carrying it over a
packet switched network; so an IP/MPLS
network.
Really, the thing to remember with
pseudowires is that you’re using all the
capabilities of that IP network in terms of
how to get from one end of the net-
work to the other edge of the network.
And then on top of that, you have the
pseudowire technology, which lets you
adapt these different Layer 1 or Layer 2
technologies onto that IP/MPLS network,
and it lets you multiplex multiple services
between two points on the network.
Dave Morfas: Giles, you were one of the
original people who came up with the
pseudowire concept. At that time, what
was the gap that needed to be filled or
what were the applications that you saw
where we needed to come up with the
concept of pseudowires?
Giles Heron: Well, Dave, at the time I
was working for Level 3 Communications
and working there with a guy called Luka
Martini, and he was really the original
author of the pseudowire concept.
The issue we had at Level 3 was that we
were building an IP/MPLS network and
yet we wanted to be able to carry Layer 2
services over that network without hav-
ing to build separate parallel networks
for those different services. So really the
original concept, if you look back to it,
was very much around carrying ATM
and frame relay traffic over an IP network
using MPLS.
So there initially we’d thought of
pseudowires very much around ATM and
frame relay. Of course, what we realized
very quickly was that it was applicable to
really any form of Layer 2 traffic, and in
fact to Layer 1 as well. And so we extend-
ed the pseudowire draft to include things
like PPP, HTLC and Ethernet. And it was
really with Ethernet that we saw the
first major deployments of pseudowires.
What we’ve seen is pseudowires being
used, not just in the core, but out into the
metro Ethernet networks, so being used
very much as a way of scaling metro
Ethernet deployments, so overcoming
all the inherent limitation of Ethernet
switching in terms of limited number of
VLANs, Spanning Tree and its issues,
limited number of MAC addresses, and
attacking those issues using MPLS, using
pseudowires themselves, and also using
the VPLS technology.
VPLS is interesting because in fact it is
layered on top of pseudowires. So just as
with pseudowires, we adopted an evolu-
tionary approach of saying, “Here, we’ve
got this MPLS thing, and we can extend
it to these pseudowires. We can use
an additional MPLS label on the MPLS
label stack as a pseudowire label, and
equally we can reuse MPLS signaling for
pseudowires.” So in the same way, with
VPLS, we took the signaling we’d already
defined for pseudowires and we took the
encapsulations we’d already defined for
Ethernet pseudowires, and we reused
those to enable us to do multipoint Eth-
ernet services over IP/MPLS networks.
So in fact after Level 3, I deployed prob-
ably the world’s first carrier Ethernet
network to use pseudowires. And what
we were doing there was, we were
building a pan-European network using
pseudowires to offer Ethernet services to
customers across the wide area.
Dave Morfas: Giles, obviously Tellabs is
playing in the pseudowire arena. What
types of customers, what types of net-
works specifically are we seeing and that
we’re deploying to?
Giles Heron: There are probably two
areas there I’d want to address.
Perhaps first I could talk about the
Ethernet space, where we have carriers
who are using pseudowires as a way of
providing scalable Ethernet services,
both in the metropolitan area and in the
wide area. And they’re also using that on
an IP/MPLS platform that is more multi-
service, and this gives them the capabil-
ity to have Ethernet either coming on a
physical Ethernet interface as 100-meg
or gigabit Ethernet, or to have Ethernet
coming in on TDM interfaces and then
interworking that into the IP/MPLS
network and again using pseudowires for
the transport through the network. So it
enables that carrier to provide a global,
very scalable Ethernet network that’s
pretty agnostic in terms of the actual
access technology used to bring the
Ethernet traffic in.
So that’s one space. But in fact, strangely,
we’re seeing quite a move back towards
ATM in networks in terms of where our
focus is for migrating people’s ATM
networks. I’m another of these engineers
who perhaps five years ago thought that,
“Hey, I left ATM behind and I wouldn’t
have to think about it again,” but really
some really interesting work now that
we’re doing in the PNNI space.
One carrier in particular I can men-
tion who are using PNNI running on
a Tellabs 8800 platform, but running
along with pseudowires, so that to the
outside world, to the ATM network, the
Tellabs equipment appears to be just
another ATM switch, but within the IP/
MPLS network, we’re using pseudowires
to carry that ATM traffic, including the
PNNI routing and signaling traffic. So
we provide very much a way to migrate
an existing ATM network that’s in many
ways reaching the end of its life, but to
move that forwards into IP/MPLS while
still maintaining existing ATM services.
And in fact what’s great in that case is
the carrier can then take that network
and then again, using pseudowires, start
to add Ethernet services to the same
network and start to add IP services on
the network as well.
But then to look at the mobile space.
There’s really been some very interesting
stuff going on in the mobile space over
the last couple of years. Had one very
large deployment where a carrier was us-
ing pseudowires on the Tellabs 8600 and
8800 platforms, and what they’re doing
is they’re using a metro Ethernet network
that’s already in place in the ground and
using pseudowires as a way of layering
their 3G backhaul traffic on top of that
existing metro Ethernet network. So this
is all very much ATM pseudowires. So,
again, here we are in 2007 doing a lot of
work with ATM.
But the great benefit here for the car-
rier is they can start to take their ATM
services, their ATM traffic, move it onto a
next-generation IP-enabled, Ethernet-en-
abled platform and move away from the
legacy ATM platforms and get very good
grooming characteristics in this case for
the 3G traffic, where, particularly with
HSDPA, what you see is the traffic char-
acteristics are very bursty. We’re finding
some mobile traffic moving away from
being very much a voice-centric thing to
being more data centric, more bursty in
nature. And so by terminating the TDM
circuits further out in the network and
then using pseudowires to backhaul the
traffic over Ethernet, they get two great
advantages.
One is that the statistical bursty nature
of the traffic is very well taken care of on
that Ethernet network. But secondly, the
price points of the Ethernet network are
much better than they would get nor-
mally from a TDM network. And I think
that’s a model that we’re going to see
replicated in many, many carriers over
the next year or two.
Dave Morfas: Giles, you talked about ini-
tially creating pseudowires. How was it,
then, that you took the concept and got it
into the industry and gained acceptance
within the industry?
Giles Heron: Well, really, the decision
that we came to, having thought of this
technology, was to effectively push that
through the IETF, this established body
that really owns the IP and MPLS stan-
dards, and so take pseudowires to that
body and get agreement within that body
that this was the way to go. And so both
informally, by meeting with different ven-
dors and different carriers, either in the
IETF meetings or in separate meetings,
but also formally at the IETF meetings,
getting a working group set up to work
on pseudowires.
In fact, pseudowires wasn’t the original
name for the technology. Pseudowires
was something that the IETF adopted as
the name for this technology. And so a
working group was established then to
work on that technology, taking the initial
draft we’d written on pseudowires, tak-
ing that into a working group, and then
working on a much broader basis with
different vendors and different carriers,
or even just different individuals giving
their own input to it.
But I think one thing to say is that quite
deliberately the design of pseudowires
was based on MPLS and was based on
the incremental for the MPLS technology.
So we weren’t coming to the industry
and saying, “Okay, we’ve got this brand
new idea completely out of left field; can
you please implement it for us?” Rather,
we were going to different vendors and
saying, “Okay, here’s a technology; it’s
really just MPLS. We’re taking existing
MPLS LSP, we’re then just adding an
additional MPLS label that identifies the
pseudowire as the traffic reaches the
edge of the network.” So the router at the
ingress can put that label on, send the
traffic on an LSP across the network, the
router at the other end will see that label,
and has that to identify the pseudowire.
But of course the second question, hav-
ing dealt with how you forward the traffic,
is how you establish these pseudowires.
And, again, the solution was to say,
“Well, MPLS already has a couple of
label distribution protocols. There’s RSVP
and there’s LDP.” Well, in this case, LDP
seemed to be the obvious choice for
this. So we used the LDP protocol and
we added incrementally some things
to enable the LDP protocol to signal
pseudowires instead of just LSPs.
So really the technology has been borne
out by its success in the market. Perhaps
the time that people first came up with
the concept of pseudowires it was like,
“Well, this might be a niche.” But what
we’ve seen is really mass deployments of
pseudowires in networks.
Dave Morfas: Obviously, Giles,
pseudowires has been an evolutionary
approach, from its inception way back
when ‘til now. What are the next steps?
What are the things that we see coming?
What are the building blocks upon which
we’re going to build for the future?
Giles Heron: Well, I think one of the
interesting things with pseudowire
evolution up to now is, a lot of it has been
based on using the pseudowire technol-
ogy and adding more services using that
technology.
So, for example, initially pseudowires
were very much about Layer 2, and then ogy, using the same labels, the same sig- So having talked about customers and
the issue came along of how do you carry naling techniques, and then adding MAC their desire to take the pseudowire
Layer 1 traffic over a packet network? learning to enable a multipoint solution. technology and push it out more into
Which, in some ways seems a little the access part of the network, one
So looking at those technologies, by
strange, that you take TDM traffic and way that we in Tellabs are addressing
and large we were taking pseudowires
put it over an IP network. And in order that is by producing a broader range
as they were and then using them as
to do that, the pseudowires themselves of pseudowire-enabled platforms; so,
building blocks to add more capabilities.
really didn’t have to change much. It was for example, taking our 8600 platform
What we’re seeing now, though, is areas
just a question of having slightly differ- that’s used in mobile networks, using
where perhaps we have to extend the
ent encapsulations to carry that Layer 1 pseudowires to backhaul mobile traf-
pseudowire architecture itself to get to
traffic. fic, and producing, for example, smaller
where we want to go.
versions of that platform that are more
What you did see, of course, is work that
So one classic example of that is, if you suitable for deployments at cell site loca-
had to be done in the areas like synchro-
really want to scale a network to very tions. So they have the same flexibility as
nization, which, for packet network guys
large sizes with pseudowires, or if you the larger platforms, they’re on the same
like me, is really something we don’t tend
want to extend pseudowire services from software, so we still have the capability
to understand very well. And some of
one network into another network, then on one platform to run 2G traffic, 3G traf-
the approaches around synchronization
you have to look at some extensions fic today with ATM, and then migrating
that we’re seeing now actually involve
there. So there we’re really looking at towards IP- and Ethernet-based mobile.
extending the pseudowire technology.
things like pseudowire switching, where
So there’s been some discussion, for ex- Monsho: That wasn’t too hard, was it?
a pseudowire can ride one LSP perhaps
ample, of the specific synchronization of The correct answer was (c) virtual wires
across one service provider’s network
pseudowires as a way of achieving syn- used to carry different types of traffic.
and then interconnect to another service
chronization through a packet network.
provider’s network and be on another If you’re ready to move to the head of the
Other areas, like I mentioned before, in LSP across that network, or, again, within class, remember, you can always down-
terms of using pseudowires as a way of one very large service provider network. load the cheat sheet at inspirethenewlife.
migrating ATM networks by integrating com.
Another area is protection. So the initial
ATM control planes on an IP/MPLS de-
pseudowire architecture really assumes Come back tomorrow for another quiz.
vice. That was very much an evolutionary
that you have two routers, one either side And remember, getting schooled never
technique using pseudowires to migrate
of your network, with an MPLS LSP be- felt so good.
ATM and frame relay traffic and extend-
tween them. But what if you want to be
ing the pseudowire technology, but
able to be protected against one of those
still fundamentally using pseudowires
routers failing? And in that case you
between the routers.
have to look at some redundancy tech-
And then, of course, we saw VPLS, which niques, some ways of having redundant
is a way of taking the pseudowire tech- pseudowires. And so that’s something
nology and extending it through multi- we’ve implemented. And, again, it’s more
point services. So instead of just point- standards work in that area as well, like
to-point Ethernet, now do multipoint interoperable ways of doing redundant
Ethernet using the pseudowire technol- pseudowires.

One Tellabs Center • 1415 West Diehl Road • Naperville, IL 60563 • 630 798 8800 • www.tellabs.com
Statements herein may contain projections or other forward-looking statements regarding future events, products, features, technology and resulting commercial or technological benefits and advantages. These statements are for discussion
purposes only, are subject to change and are not to be construed as instructions, product specifications, guarantees or warranties. Actual results may differ materially. The following trademarks and service marks are owned by Tellabs Operations,
Inc., or its affiliates in the United States and/or other countries: TELLABS®, TELLABS and T symbol®, and T symbol®. Any other company or product names may be trademarks of their respective companies. © 2008 Tellabs. All rights reserved.