Subject: RE: X/MPLS vs X/IP

From: "Yaakov Stein" <[email-masked]>
Date: Thu, 22 May 2003 09:51:45 +0300

> NH has lots of thoughts about why X/MPLS is different
> than X/IP, and perhaps when Neil has time he can
> briefly enumerate them, so leave the general question
> in his hands.

I'd like to step in here before Neil does,
since we don't completely agree on this issue.

PWs have been defined in the IETF to be lower layer agnostic
in order to simplify their encapsulation.

However, there ARE important differences between IP and MPLS networks, 
the most important deriving from the fact that IP is connectionless 
while MPLS is connection-oriented (but see below).

Now it is perfectly legal to layer a connectionless network
on top of a connection-oriented one, or a connection-oriented
one on top of a connectionless one (although in this latter case
the performance may degrade somewhat). 
The problems arise when we want to support real-time streams.

Connectionless networks have problems with QoS in general, 
and QoS for the support of real-time streams in particular.
There is simply somewhat of a contradiction between
expressing disdain for dedicated connections
and emulating them sufficiently well as to be able to give service guarantees.

For example, a TDM link transports not only the user's traffic,
but the accurate clocking information needed for its proper playout.
The recovery of such timing information is already difficult
for connection-oriented networks (this difficulty being
evidenced, e.g. by the plethora of patents for clock recovery over ATM) 
and becomes more so for connectionless one
(this greater difficulty being evidenced by the dearth of patents for 
TDM clock recovery over IP).

Now that I have explained the difficulties essentially
as Neil would, I have to add that these technical difficulties
are not insurmountable, and that accurate timing can be 
recovered over IP networks. 

In addition, service guarantees are just what their name implies, 
promises of a CERTAIN LEVEL of service.
While carriers have pre-defined notions as to what level of service
their customers desire, these notions tend not to take everything
of interest into account.  Cell-phones deliver audio considered to
be below "toll quality", but the added feature of mobility makes
them desirable nonetheless. Similarly, pricing has a major impact
on end-users. People are sometimes willing to suffer lower levels 
of service, if the price is considerably reduced.

So transporting eal-time streams such as TDM over IP and over MPLS
are somewhat different problems. The question is whether they are 
sufficiently different as to merit different protocols.

Were MPLS to have been originally designed as a variable-length-packet
ATM, rather than as "accelerated-IP" then perhaps the answer 
would have been yes. However, MPLS does NOT have a physical layer
clock as ATM has, and does NOT guarantee that no mis-ordering
will take place (being at the mercy of the IP routing), and does NOT
universally promise lower PDV (although TE can help). 

So the differences between pure IP and MPLS
are really a matter of degree, and not of essence,
and the design of a single TDMoIP/MPLS protocol DOES makes sense.

Y(J)S

---

From: Sasha Vainshtein <[email-masked]>
Date: Thu, 22 May 2003 12:13:43 +0200

Yaakov and all,
Please see a brief  comment inline.

With best regards,
                                   Sasha Vainshtein
email:     [email-masked] <mailto:[email-masked]> 
tel:       +972-3-7659993 (office)
           +972-8-9254948 (res.)
           +972-58-674833 (cell.)

> -----Original Message-----
> From: Yaakov Stein [mailto:[email-masked]]
> Sent: Thursday, May 22, 2003 8:52 AM
> To: Mark Seery; [email-masked]
> Cc: [email-masked]
> Subject: RE: [PWE3] X/MPLS vs X/IP
> 
> 
.snipped ...
> in order to simplify their encapsulation.
Exactly. 
... snipped ...
> and the design of a single TDMoIP/MPLS protocol DOES makes sense.
I agree with the last sentence even if I disagree with your reasoning.
If you are interested, we can discuss it off the list.
> 
> Y(J)S
> 
> _______________________________________________
> pwe3 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/pwe3
>

---

From: [email-masked]
Date: Thu, 22 May 2003 11:43:23 +0100

Hi Yaakov,
Yaakov S wrote to Mark S 22 May 2003 07:52

> in order to simplify their encapsulation.
NH=> That's an interesting way of putting it, ie 'simplifying'.  I could
easily argue that it 'complicates' the situation.  There is no technical
reason to require that IP and MPLS are the same......they both have
individual properties and both modes are required  However, this is not the
sole reason as you know why the encaps has the functionality it does.  
> while MPLS is connection-oriented (but see below).
NH=> Indeed....the only really significant problems arise from certain
topological constructions when using a co pkt-sw forwarding mode.
> The problems arise when we want to support real-time streams.
NH=> Yes it is 'legal' to do this.  But have you also ever considered how
many times one is allowed to swap modes in some global reference connection,
and whether an abitrary number of such mode swapping instances would allow
timing recovery?  It's an interesting problem.....esp when it comes to
breaking-down an end-end performance metric objective to *fair* subnetwork
(G.805-sense) apportionments.....which is something carriers ought to be
concerned about.
> and QoS for the support of real-time streams in particular.
NH=> Two points here often overlooked:
-	there is a difference in how one needs to treat public and private
traffic;
-	currently pkts only carry an up-state 'urgency' semantic and not an
'importance' semantic.....this is a big difference, eg a mission critical
voice call or one to the emergency services vs 'office gossip'.  A key
observation here for the co pkt-sw mode is that one can't just consider the
pkt level.....it has to be intrinsically associated with its parent trail.
This observation is paraticularly important for private services.
The bottom-line conclusion from this (when you fill-in all the other
details) is that one needs both a cnls mode and a co pkt-sw mode and there
are major differences in what they can/cannot do (I am saying this with a
traditional operator's hat on, not an ISPs).  So we should recognise this
and properly exploit it.  

> TDM clock recovery over IP).
NH=> Precisely so.
> recovered over IP networks.
NH=> I'd generalise that to cnls networks as ethernet access is also a
factor here.  
> of service, if the price is considerably reduced.
NH=> That's true....but recall my observation above wrt end-end performance
objectives and fair allocations to subnetworks (which, to have any
credibility, also implies an ability to measure such metrics/objcetives).
Further, and I can only speak for BT here, we have a relentless drive to
improve the network reliability/performance for our customers......so we are
looking for both stds and vendors who support/share this view.
> are somewhat different problems.
NH=> Correct.

> The question is whether they are 
NH=> There are 2 aspects to this (if I ignore seperating the private/public
services case, which as I noted earlier does actually need to be considered
in practice): (i) the WAN mode and (ii) the application-interfacing
protocol.  Both have to be considered.  And in an ideal case (ie to minimise
capex/opex costs), for technologies belonging to the same WAN mode one wants
service-interworking with consistent application-interfacing protocols.  A
further factor to consider is who are you selling this solution to?  Is if
for (i) the Internet (big 'I') (ii) an ISP or (ii) a traditional operator?
These are all quite different IMO.  I have absolutely no problems at all in
addressing all 3 'customers'.......my problems start when someone tries to
tell me there is only one solution for all cases and no other will be
considered (usually because of political, commercial or religious factors).

> clock as ATM has,
NH=> Not sure what you mean by this......ATM (as indeed every framing format
above the physical/media level) invariably relies on a co cct-sw trail to
convey the timing between nodes (the exception is the case of ethernet and
wireless/radio, but these too have their own phy/media stds for clock
recovery)
> and does NOT guarantee that no mis-ordering
> will take place (being at the mercy of the IP routing),
NH=> I understand your point, but this could apply to any mode where
routes/connections can vary at will....a distributed routing protocol can be
used with a cnls, co pkt-sw and even a co cct-sw mode.  So its a choice
whether this behavior is allowed and has strictly nothing to do with 'IP
routing' whatever that really means.

> and does NOT
NH=> Agreed, this is a function of bit rates and network loading. 
> and the design of a single TDMoIP/MPLS protocol DOES makes sense.
NH=> I understand what you are saying here.....and I am sure you recognise
that you are restricted to the client/server network-interworking case.  I
also just saw Sasha's comment to 'maybe take this off-list'.  That's fine, I
think I understand why this is suggested......but I just ask the question
'who is your target market/customer here?'

---

From: Mark Seery <[email-masked]>
Date: Thu, 22 May 2003 06:07:28 -0700 (PDT)

Hi Yaakov,

Thanks for response. 

I didn't quite get the bottom line. Where you arguing
that IP and MPLS are not so different that they can
both use PWE as just an encapsulation without making
PWE a new layer?

Mark

---

From: Mark Seery <[email-masked]>
Date: Thu, 22 May 2003 08:52:53 -0700 (PDT)

Yaakov,

--- Yaakov Stein <[email-masked]> wrote:

[SNIP]
> I wasn't arguing the layering issue here,
> but you are quite right that it is relevant.
> If MPLS is now a connection oriented layer in its
> own right, then we don't need the PW to be

And when we talk of MPLS in this context, do we assume
that all MPLS control planes result in the same
network mode? I know you have stated that MPLS is not
quite CO yet, but I was wondering whether you think
all forms of MPLS are the same degree of separation
from CO? And if not, how does that impact your
comments?

Additionally, as I re-read the PWE foundation
documents, it is clear that it is the intention that a
PSN is in fact a layer. What is not clear is whether a
PSN is an abstract notion for either the IP or MPLS
layers, or whether a PSN is IP or MPLS+ some other
glue. If someone could fill me in on the intention,
that would be helpful, thanks.

thanks,
Mark

---

From: [email-masked]
Date: Thu, 22 May 2003 16:55:13 +0100

Hi Yakov.....few small points.  regards, Neil

<snip>  
> > there is a difference in how one needs to treat public and 
> private traffic;
> > currently pkts only carry an up-state 'urgency' semantic and not an
> > voice call or one to the emergency services vs 'office gossip'. 
> 
> As you know Neil, I think that this issue can be properly handled
> by using my "paying for quality of service" paradigm.
> For those not familiar I will give the distilled version.
> 
> People can get free telephone service over the Internet using 
> "Free World Dialup", but are willing to pay premium price for 
> full "toll-quality" service. They are probably also willing to pay 
> intermediate amounts for intermediate service levels. 
> So why not give the user the choice? 
> By allowing the user to select a quality/price level
> on a call-to-call basis (e.g. by pressing a digit from 1 to 5)
> one can select the bandwidth and network parameters
> that match the user's desires, and the importance
> rather than the real-time constraint is the dominant factor.
NH=> Understood.  This makes sense when there is a clear understanding of
service between operator and user and across all users.  A general public
service is the obvious case here.  This is not true however in the private
case, ie a VPN.  It's far less clear how 'importance' can be attached to a
pkt which only carries 'urgency' semantics both in an operator-user
relationship and *between* different (VPN) users.
<snip>

> I agree that big-I Internet is a different case,
> especially with the special mechanisms implemented
> for TCP flows. However, once again, I believe it is a valid
> offering for low-cost / low-performance services.
> 
> You will probably agree with me that private overprovisioned 
> well engineered IP networks are more like the MPLS case
> from the raw performance (PDV, packet loss) point of view.
NH=> Which flavour of MPLS?  If you are referring to mp2p I'd say the IP
network is a better proposaition because it does any-any as a natural
behaviour and does not have the same defect problems.

<snip>
However, MPLS does NOT have a physical layer
> > wireless/radio, but these too have their own phy/media stds 
> for clock recovery)
> 
> I was hinting at mechanisms such as SRTS whereby the clock to 
> be transfered is referenced to the physical layer clock.
NH=> OK thanks, I understand what you meant now, but that is not ATM....that
is AAL1 which is an application-interfacing protocol that can sit above any
co pkt-sw trechnology in principle.

<snip>
> In my opinion TDM services over PWs are most attractive
> to enterprises and specific cases such as long-distance 
> toll-bypass operators.
> I am not expecting major operators to dump their SDH/SONET
> networks overnight
NH=> Established technologies have a lifetime of order 25 years.  I had a
large hand in designing the structure/behaviour of the E1 G.704/706 frame
about 20 years ago.....still plenty of E1 about.  So anyone who discounts
the large deployed base of SDH (and ATM) is making a mistake if they intend
to deal with large operators.

> and run to TDMoMPLS. 
> which is the reason I deal exclusively with low-rate TDM
> and do not consider the SONET/SDHoMPLS case to be important.
NH=> You are a wise man Yaakov......but I realised that when I met you.

---

From: [email-masked]
Date: Thu, 22 May 2003 17:51:02 +0100

Thanks Yaakov....yes, I agree, in case of *carrying* timing for far-end
recovery then you need a decent physical layer.

regards, Neil

> Sent: 22 May 2003 17:40
> To: Harrison,N,Neil,IKL2 R
> Cc: [email-masked]
> Neil, 
> Just one small point.
> > NH=> OK thanks, I understand what you meant now, but that is 
> > not ATM....that is AAL1 which is an application-interfacing 
> protocol that can 
> > sit above any co pkt-sw trechnology in principle.
> 
> Unfortunately it can't.
> 
> The SRTS and similar methods rely on the physical layer. 
> Since ATM has well defined physical timing,
> SRTS can encode the offset of the TDM clock from the
> ATM clock.
> 
> So although most of AAL1 is able to work over any layer 2+, 
> the special clock mechanisms are only for the cases 
> where the physical layer carries clock.
> 
> Y(J)S
>

---

From: "Yaakov Stein" <[email-masked]>
Date: Thu, 22 May 2003 17:38:37 +0300

Mark and Neil
(I'll try catching Sasha off-line to see what point he wants to make), 

> [Mark] I didn't quite get the bottom line. Were you arguing

I was arguing that were MPLS to have been properly designed,
or when and if we finish its design to make it truly "carrier class"
then perhaps some simplification could be made for MPLS,
and it would make sense to keep the two cases separate.

I wasn't arguing the layering issue here,
but you are quite right that it is relevant.
If MPLS is now a connection oriented layer in its own right,
then we don't need the PW to be, but then with IP something
might be missing. You might have noticed that in earlier
versions of draft-anavi I had my own diagnostics and performance
measurement mechanisms (based on ICMP packets),
which is what we use for the IP case. I removed it from the draft
when the MPLS mechanisms improved sufficiently,
but we still use them for IP.
 
> there is a difference in how one needs to treat public and private traffic;

> timing recovery?  It's an interesting problem...

I haven't ever tried measuring the performance as a function of 
the number of mode swaps, but arbitrary numbers of swaps are not expected.
We've done clock recovery for TCP/IP POS, 
UDP/IP/Ethernet/optical, UDP/IP/Ethernet/cable-modem,
UDP/IP/ATM/DSL, and similar cases, 
and conform to the standard TDM jitter and wander requirements.

> NH=> There are 2 aspects to this <SNIP>

We will probably have a lot to argue about for the intermediate cases,
e.g. using RSVP for IP networks, MPLS networks without TE, etc.

> wireless/radio, but these too have their own phy/media stds for clock recovery)

I was hinting at mechanisms such as SRTS whereby the clock to 
be transfered is referenced to the physical layer clock. Since ATM
defines the lower layers, this can be done. It also MAY be possible
for some single hop MPLS cases, but this depends on the lower layer.
In general this feature is lost for multi-hop MPLS or IP connections.

> NH: <SNIP> but I just ask the question

In my opinion TDM services over PWs are most attractive
to enterprises and specific cases such as long-distance toll-bypass operators.
I am not expecting major operators to dump their SDH/SONET
networks overnight and run to TDMoMPLS. 
which is the reason I deal exclusively with low-rate TDM
and do not consider the SONET/SDHoMPLS case to be important.

Y(J)S

---

From: "Yaakov Stein" <[email-masked]>
Date: Thu, 22 May 2003 19:39:55 +0300

Neil, 

Just one small point.

Y(J)S

> not ATM....that is AAL1 which is an application-interfacing protocol that can 

Unfortunately it can't.

Y(J)S