Subject: Question on Martini AAL-5 SDU mode

From: Shahram Davari <[email-masked]>
Date: Mon, 12 Aug 2002 07:46:14 -0700

Hi,

Since in SDU mode the CRC is removed at the ingress PE and added at
the egress PE, it is possible for a bit error in the MPLS network 
not to be detected (MPLS doesn't have CRC) and to get
rubber stamped by the egress PE. Has any remedy been proposed, 
to prevent this from happening?

Note: The errors might not even be detectable by the link layer,
such as errors inside the routers.

Yours,
Shahram Davari
Senior Product Research Engineer
R&D Research Ottawa
PMC-Sierra, Inc. 
Phone: (613) 271-4018
Fax:   (613) 271-6468

---

From: Sasha Vainshtein <[email-masked]>
Date: Mon, 12 Aug 2002 19:28:03 +0200

Shahram and all,
IMHO the possibilty of a bit error within the routers
going undetected by the PW is a common situation in all 
the PWE3 emulations of frame-oriented services - 
be it Ethernet, Frame Relay, HDLC or AAL5-SDU.
Hence it should be treated (or ignored) in the same way
for all these services.  

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: Shahram Davari [mailto:[email-masked]]
> Sent: Monday, August 12, 2002 4:46 PM
> To: [email-masked]'
> Subject: [PWE3] Question on Martini AAL-5 SDU mode
> 
> 
> Hi,
> 
> _______________________________________________
> pwe3 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/pwe3
>

---

From: Shahram Davari <[email-masked]>
Date: Mon, 12 Aug 2002 11:07:16 -0700

Sasha,

Good point. Why don't we add an optional CRC to the
IW header?

Yours,
-Shahram

> From: Sasha Vainshtein [mailto:[email-masked]]
> Sent: Monday, August 12, 2002 1:28 PM
> To: Shahram Davari
> Cc: [email-masked]'
> Subject: RE: [PWE3] Question on Martini AAL-5 SDU mode
> 
> 
> Shahram and all,

---

From: Jim Harford <[email-masked]>
Date: Tue, 13 Aug 2002 02:45:33 -0400

Shahram,
One of the major benefits of AAL-5 PDU mode over SDU mode is the fact that 
AAL-5 CRC is carried end-to-end.  This was one of the reasons that the ATM 
Forum specs use PDU mode.

Jim Harford

---

From: [email-masked]
Date: Tue, 13 Aug 2002 10:48:38 +0100

Hi Stewart.....my views on this are inserted below.  regards, Neil

Stewart Bryant wrote 13 August 2002 08:23
 
> Jim Harford wrote:
> Agreed, but what is the systematic advantage of this?
NH=> IMO the 'systematic advantage' is that its not generally a good idea
architecturally to meddle with the structure of a client layer for the
alleged benefit of some specific server layer.  The benefit seems to be some
minimal BW saving here.....but I can think of many other examples (in the
general networking sense) that arguably cause significant BW wastage.
> 
> Why is ATM special vis a vis the other framing modes that do 
> not do this?
NH=> Nothing.....I would apply the above observation to any client/server
encapsulation relationship.  
> 
> The Internet is built on systems that do not preserve end-to-end CRC
> what is the incidence of problems, and how do they manifest 
> themselves?
NH=> Exactly the opposite is true IMO.  The whole premise of a cnls network
mode, and in the Internet case one based on the Internet Protocol, is that
it provides no assured delivery/integrity.  It is therefore expected that if
some higher layer entity requires assured delivery/integrity then that high
layer entity must provide it.  A CRC is just one form of providing some
assurance of detecting errored data (not 100% of course).
> 
> Little, deployed hardware can run PDU mode. Is this a problem?
> 
> See also below
> 
> Stewart
> 
> 
> 
> 
> > >not to be detected (MPLS doesn't have CRC)
> 
> But the underlying links do, so the only causes of corruption are
> memory error and software error. How much of a problem is this.
NH=> If you can't measure it you can't quantify it.  A different view of
this question is 'does the *benefit* outweigh the potential problem cost?'.
I don't see compelling benefits that persuade me to take such a risk.
> > and to get
> How significant a problem is this compared to error in the 
> end-systems?
> 
> Does anyone have any measured results?
NH=> This is a potentially dangerous line of reasoning.....though I can
understand its logic/attractions.  If (i) no one is looking for it and/or
can't measure it, (ii) if higher layer entities (other types) probably
compensate anyway (eg request a re-transmit, or are so redundant they can
ignore, eg voice), (iii) if there is no large population deployed on which
to base observations anyway.....then how can this question be answered?  So
it comes down to an engineering estimate of alleged benefit vs risk cost of
failure.  As I said, I see no compelling benefits here that encourage me to
support meddling with the higher layer entities.

---

From: Sasha Vainshtein <[email-masked]>
Date: Tue, 13 Aug 2002 15:50:35 +0200

Stewart and all,
IMHO carrying the CRC of an AAL5 SDU (or any other frame)
would not add much value to the PWE3 because bit errors 
created by the router internal problems (the problem
that has been brough up by Shahram) may affect 
demultiplexing and/or encapsulation layer headers 
as well as the payload. The consequences would be 
no less dramatic.

With best regards,
                                   Sasha Vainshtein

> From: Stewart Bryant [mailto:[email-masked]]
> Sent: Tuesday, August 13, 2002 9:23 AM
> Cc: [email-masked]
> Subject: Re: [PWE3] Question on Martini AAL-5 SDU mode
> 
> 
> 
> 
> Jim Harford wrote:
> > 
> > Shahram,

---

From: "David Allan" <[email-masked]>
Date: Tue, 13 Aug 2002 09:55:20 -0400

Sasha:

If additional integrity is more or less free (the oft stated "principle of
minimal intervention") then it's a good idea, otherwise I suspect we are
gilding the lily. ATM PDU looks pretty free to me, and as a result the
majority of such (infrequent) problems would fall into the detectable
category, as opposed to only gross forwarding or packet handling faults
induced by bit errors.

cheers
Dave

> Sent: Tuesday, August 13, 2002 9:51 AM
> To: [email-masked]'
> Cc: [email-masked]

---

From: [email-masked]
Date: Tue, 13 Aug 2002 15:30:57 +0100

Bob....this is an excellent point, and one I nearly made myself in my last
posting to Stewart.  I hinted at this by saying its architecturally not a
good idea to meddle with higher client layer network entities (here this is
a AAL5 trail) just for some minor benefit of a server layer, eg some very
modest BW saving say. However, wearing a traditional operator's hat I would
have put it slightly differently....so bear with me whilst I try and
explain:

There are 3 classes of network and all technologies belong to one of these
classes, ie:
-	CNLS {IP}
-	CO PKT-SW (X.25, FR, ATM, MPLS}
-	CO CCT-SW {nx64k, PDH, SDH, OTN}

All networks have a traffic-plane, control-plane and a management-plane in
some form or other.  CNLS has a common data-plane for carrying
traffic/control/management functions, whilst CO networks (pkt- or cct-sw)
can have disjoint data-planes for carrying traffic and control functions
(and even the data-plane for management functions can be be disjoint if
required). Due to historical reasons we have re-spun common functional
components of networks differently, eg addressing, routing, signalling, OAM,
performance metrics, traffic-descriptors, etc.  So we have ended-up with
several self-similar technologies (of the same network class)....which is OK
whilst they are stand-alone, but this means complications/gateways when we
operators want to functionally converge/evolve networks (for capex/opex
reasons). 

Network level interworking (though I really mean protocol-conversion, which
some call 'service interworking') may not be too bad if we still have a
continous end-end higher level network trail which has not been butchered in
some way.  But now think applications.  For a set of network technologies
belonging to a common class we also want common application interfacing
protocols....else we are looking at gateways here too, eg VoFR, VoATM,
VoMPLS.  AALs are a candidate for such application interfacing
protocols.....but irrespective of what is chosen, the key point is that this
ought to become the standard way to interface a specific application to a
set of technologies belonging to the same network class.

And that's why I am not keen on seeing AALs meddled with at this juncture
just so someone can save a few gates and a bit of BW for some lower network
server layer.

regards, Neil 
> From: Bob Barrett [mailto:[email-masked]]
> Sent: 13 August 2002 11:06
> To: stbryant; pwe3
> Hi Shahram
> Isn't the key point here that the payload in AAL5 format is 
> inter-operable
> with some existing ATM based switch front ends, even though 
> those systems
> may be out of scope for the ietf, and to a degree 
> implementation specific?
> Using an ATM AAL layer two format (cells with the ATM 
> construct) makes the
> adaptation from packet transport of a circuit back to layer two ATM
> transport of a circuit a pretty simple piece of logic.
> 
> Having said that I am in favour of SDU mode as it is simple 
> and effective,
> and I don't have any legacy of ATM expertise to leverage. But I can
> understand and accept that a significant proportion of the 
> PWE3 contributors
> do have that ATM legacy and expertise, and that carriers have 
> an installed
> base of ATM based Class5 front ends that they need to leverage.
> 
> Best regards
> 
> Bob Barrett
> 
> BTW - just rejoined the reflector as I am not travelling for 
> a few weeks,
> apologies if this is re-stating a point already made.
> 
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Stewart Bryant
> Sent: 13 August 2002 08:23
> Cc: [email-masked]

---

From: Shahram Davari <[email-masked]>
Date: Tue, 13 Aug 2002 10:02:13 -0700

Sasha,

1) The Demux/Encapsulation header are a small portion of the
packet. Hopefully most of the packet is payload. And in that
case most errors will be detected by payload CRC.

2) Some demux layers have CRC, such as GRE. 

You can never achieve full proofness. All you can do is reduce
the possibility of errors not being detected.

-Shahram

> From: Sasha Vainshtein [mailto:[email-masked]]

---

From: Shahram Davari <[email-masked]>
Date: Tue, 13 Aug 2002 10:24:13 -0700

Stewart,

If a L2 has a CRC, it is there for a reason. May be, because the
higher layers that it carries don't have any CRC.

-Shahram

> From: Jim Harford [mailto:[email-masked]]
> Sent: Tuesday, August 13, 2002 11:54 AM
> To: [email-masked]
> Cc: [email-masked]
> Stewart,
> Most of the layer-2 technologies I am aware of have a 
> mechanism (e.g. CRC) 
> to protect the data integrity of a delivered message from one 
> end of the 
> link to the other.  If you want to emulate a layer-2 
> technology, then one 
> should strive to preserve as many layer-2 characteristics as 
> possible.  In 
> the area of data integrity, this would mean carrying the 
> original link's 
> protection (e.g. ATM AAL-5 CRC, Ethernet CRC, HDLC CRC, etc) 
> across the 
> pseudo-wire.
> 
> But we keep running into the design tradeoff of emulating a 
> service that 
> people are buying today from their carrier, versus inventing 
> a new service 
> that just happens to run on an installed base of hardware.
> 
> Jim Harford
> 
> 
> At 08:23 AM 8/13/2002 +0100, Stewart Bryant wrote:
> 
> 
> >Jim Harford wrote:
> > >
> > > Shahram,

---

From: "Zheng Wang" <[email-masked]>
Date: Tue, 13 Aug 2002 10:45:36 -0700

> higher layers that it carries don't have any CRC.
 
Error detection is currently done at two levels:

1) L1/L2 error detection hop-by-hop. When a packet goes 
cross a link, there is a CRC at L1/L2 level. When it moves
from a framer to a packet processor, the interface (like SPI4)
has its own CRC. The same goes with switch fabric interface.

2) Application level CRC that provides error detection in the
payload itself. 

Adding additional protection for a specific protocol has marginal
benefit when other protocols do not. Applications still need to have
their own protection anyway. 

Cheers
Zheng

---

From: "Rutemiller, John" <[email-masked]>
Date: Tue, 13 Aug 2002 15:32:50 -0400

> their own protection anyway. 

I completely agree that applications need to have their own protection.

But in this case, the "application" is AAL5. SDU mode removes the
protection the application provided for itself.

By saying that the application above AAL5 should provide its own
protection is like saying applications above UDP should provide their
own protection.

John

---

From: "Zheng Wang" <[email-masked]>
Date: Tue, 13 Aug 2002 14:37:18 -0700

> From: Rutemiller, John [mailto:[email-masked]] 
 
I do understand your perspective. You can argue the same for FR, 
Ethernet and HDLC (i.e., FR, Ethernet and HDLC are the "applications"
of PWE circuits).

However, I consider the L1/L2 error protection function specific
to the characteristics of that L1/L2. The L1/L2 error protection 
function is transfered to the new L1/L2 on top of the PSN label, 
once the ATM, FR, Ethernet and HDLC are terminated and become payloads. 

Cheers
Zheng

---

From: Shahram Davari <[email-masked]>
Date: Wed, 14 Aug 2002 07:41:05 -0700

Zheng,

> Ethernet and HDLC (i.e., FR, Ethernet and HDLC are the "applications"

There is a big difference. HDLC and FR CRC are link-by-link protections, while
AAL5 CRC is end-to-end. You may replace a link-by-link CRC with another
link-by-link protection, without (almost) any change to the undetected errors,
but you should not touch the end-to-end CRCs, because that may increase the
undetected errors.

Put it in another way, ATM has 2 CRCs, one in the ATM link (HEC) and one in
the AAL5 (CRC). It is OK to replace the ATM link HEC with let's say POS CRC, but
you should not touch the AAL5 CRC, because errors that would otherwise be detected
may get undetected.

In any case I am not against the SDU mode. It is there for using currently available
hardware, but I think the reason that it is there and the consequences of this manipulation must be documented.

Yours,
-Shahram

---

From: [email-masked]
Date: Wed, 14 Aug 2002 09:51:39 -0500

Sharam,
	I agree with you. We need to clearly specify the Caveats associated 
with SDU mode. I have always consider the SDU mode to only be used when 
I know what the application above AAL5 is (e.g. if is Frame Relay or IP 
over ATM then I should be able to safely use SDU mode but if I do not 
know what the application using AAL5 is then I would not use SDU mode).

Robert Dianda

-----Original Message-----
From: Shahram.Davari [mailto:[email-masked]]
Sent: Wednesday, August 14, 2002 9:41 AM
To: zheng; John.Rutemiller; pwe3
Subject: RE: [PWE3] Question on Martini AAL-5 SDU mode

Zheng,

> Ethernet and HDLC (i.e., FR, Ethernet and HDLC are the "applications"

There is a big difference. HDLC and FR CRC are link-by-link protections, 
while
AAL5 CRC is end-to-end. You may replace a link-by-link CRC with another
link-by-link protection, without (almost) any change to the undetected 
errors,
but you should not touch the end-to-end CRCs, because that may increase 
the
undetected errors.

Put it in another way, ATM has 2 CRCs, one in the ATM link (HEC) and one 
in
the AAL5 (CRC). It is OK to replace the ATM link HEC with let's say POS 
CRC, but
you should not touch the AAL5 CRC, because errors that would otherwise 
be detected
may get undetected.

In any case I am not against the SDU mode. It is there for using 
currently available
hardware, but I think the reason that it is there and the consequences 
of this manipulation must be documented.

Yours,
-Shahram

---

From: Eric Rosen <[email-masked]>
Date: Wed, 14 Aug 2002 10:52:56 -0400

John> By  saying that  the application  above  AAL5 should  provide its  own
John> protection is like saying  applications above UDP should provide their
John> own protection. 

It's  a little  bit different  because the  UDP checksum  is  end-to-end.  A
checksum on the AAL5 SDU would only  be end-to-end in the case of ATM to the
desktop. Given that  there's no such thing as ATM to  the desktop, it's hard
to see  AAL5 as  anything but a  data link,  whose checksum would  only have
local significance. 

One  can  argue  plausibly  for  end-to-end checksums,  and  one  can  argue
plausibly  for link  checksums,  but I  don't  really see  the argument  for
additional checksums covering sequences of links.

---

From: [email-masked]
Date: Wed, 14 Aug 2002 16:23:54 +0100

Few small points Shahram....please see below.  regards, Neil

Shahram Davari wrote 14 August 2002 15:41

> AAL5 CRC is end-to-end.
NH=> End-end depends on your perspective.  All trails are end-end from
*their* layer perspective (any co technology you like fits here).  So FR
trails are also end-end between their trail termination points.  

> You may replace a link-by-link CRC 
> with another
NH=> ATM has 2 layers...VP and VC.  The HEC CRC is for the header of the
cell only not the payload.....ATM provides no protection here.  AALs are
application interfacing protocols, and can be used over other server layers
and not just ATM.  They could in theory be networked but are not AFAIK (and
this has some ramifications for correct fault handling as you know when
considering where the trail termination points.....since they vary in the
differnt ATMoverMPLS modes).  
<snipped>

---

From: "Rutemiller, John" <[email-masked]>
Date: Wed, 14 Aug 2002 11:36:03 -0400

I agree that replacing the protection mechanism with another
is a valid approach.  But it must provide equivalent protection.

Ethernet over ATM does this because AAL5 provides a CRC that
goes between two Ethernet/ATM interworking devices.

PWE3 does not do this. The only CRC is on the links between the
LER/LSR devices. There isn't a CRC between two PWE devices.

As you pointed out, this is could be a problem for all PWE3 drafts.
Whether it is a real concern depends on the assumptions being made
about the traffic over the circuit being emulated.

For example, if with Ehternet you are assuming that all traffic is
something like IP or IPX which provide their own CRC, then PWE3
does not need to provide a CRC.

If you can't make that assumption, then PWE3 must provide a CRC or
clearly state the limits of the approach.

In the case of SDU mode, if a CRC is not desired, then the document
simply needs to clearly state this limitation.

John

-----Original Message-----
From: Zheng Wang [mailto:[email-masked]]
Sent: Tuesday, August 13, 2002 5:37 PM
To: Rutemiller, John; [email-masked]
Subject: RE: [PWE3] Question on Martini AAL-5 SDU mode

Cheers
Zheng

---

From: "Rutemiller, John" <[email-masked]>
Date: Wed, 14 Aug 2002 11:38:19 -0400

I agree that this would be equivalent to turning off checksums in UDP.

But in this case, checksums were turned on and a device in the middle
of the network turned of the checksum. It was not an application decision.

John

-----Original Message-----
From: Lloyd Wood [mailto:[email-masked]]
Sent: Wednesday, August 14, 2002 10:21 AM
To: Rutemiller, John
Cc: [email-masked]
Subject: RE: [PWE3] Question on Martini AAL-5 SDU mode

> protection is like saying applications above UDP should provide their

...which in fact they do to some extent, since UDP is unreliable and
does not organise retransmits etc. (UDP checksums being turned off as
an option stems, I believe, from an early BSD stack bug. NFS over UDP
sans checksums - increased speed/performance across LANs - has
famously led to instances of massive file corruption as a result.
(SunOS 4.1.x shipped with checksums off by default.))

SDU mode is analogous to UDP with checksums off. The field's still
there, but the contents don't provide the endtoend integrity check you
want.

http://www.postel.org/pipermail/end2end-interest/2002-March/001887.html

L.

<http://www.ee.surrey.ac.uk/Personal/L.Wood/><[email-masked]>

---

From: "Rutemiller, John" <[email-masked]>
Date: Wed, 14 Aug 2002 11:55:51 -0400

No such thing as ATM to the Desktop?????

Guess again. Those NIC cards several companies sold in the 90s went
somewhere. And even when they went into a server instead of a desktop,
it is the same problem.

If you consider only the case of IP over ATM, then even though AAL5
does provide an end-to-end service (between routers), we can do without
it because we know that IP provides a checksum that will ultimately
catch any errors.

But we can't make that assumption with AAL5 in general.

Which is why I agree with other comments that clearly stating the
limitations of SDU mode and its applicability is a way around the
problem.

If anyone ever wants to use SDU mode generically, then PWE3 will
need to provide a CRC to replace the AAL5 CRC. Or use only PDU mode.

John

---

From: "Rutemiller, John" <[email-masked]>
Date: Wed, 14 Aug 2002 12:43:28 -0400

You're mixing the AAL5 CRC and the ATM HEC.

The ATM HEC protects against improper de-multiplexing.

The AAL5 CRC provides the protection between two interworking
devices. RFC-1483/2684 allows the removal of the Ethernet FCS.
In this case there would not be a redundant CRC function. If
the Ethernet FCS is left on the frame, then I agree that the
AAL5 CRC would be redundant.

Transmission without the Ethernet FCS has been used. For example,
The ATM Forum LAN Emulation specification requires transmission
without the Ethernet FCS.

So if you used SDU mode on traffic containing Bridged Ethernet
traffic, a bit error in the Ethernet header would cause mis-delivery
of the packet on the egress Ethernet.

John

-----Original Message-----
From: Lloyd Wood [mailto:[email-masked]]
Sent: Wednesday, August 14, 2002 12:02 PM
To: Rutemiller, John
Cc: [email-masked]
Subject: RE: [PWE3] Question on Martini AAL-5 SDU mode

> goes between two Ethernet/ATM interworking devices.

But the Ethernet frame is carried containing its own 32-bit CRC, so
the ATM CRC is redundant as far as the Ethernet endpoints are
concerned... all the ATM CRC buys you is additional assurance that you
are multi/demultiplexing correctly and sending to the correct Ethernet
endpoints for them to decode and drop if errored.

http://cell-relay.indiana.edu/mhonarc/ipatm/1995-Oct/msg00095.html

  I'm afraid that somebody will eventually come up with some "clever"
  device playing "ATM network" at both ends and secretly re-computing
  the AAL5 CRC in the middle.

hmmm. that was 1995.

> does not need to provide a CRC.

Ethernet has its own 32-bit CRC.

This is not a problem for PWE3 drafts. We just carry the stuff.
Your legacy protocol screwups remain your legacy protocol screwups.

L.

---

From: "Rutemiller, John" <[email-masked]>
Date: Wed, 14 Aug 2002 12:52:34 -0400

Lloyd,

How do you use SDU mode in an ATM network without PWE3. This mode
is unique to PWE3 and does not exist in an ATM network.

John

-----Original Message-----
From: Lloyd Wood [mailto:[email-masked]]
Sent: Wednesday, August 14, 2002 12:17 PM
To: Rutemiller, John
Cc: [email-masked]
Subject: RE: [PWE3] Question on Martini AAL-5 SDU mode 

On Wed, 14 Aug 2002, Rutemiller, John wrote:

> somewhere.

dumpsters, mostly.

> need to provide a CRC to replace the AAL5 CRC. Or use only PDU mode.

No. PWE3 needs to do nothing, since SDU mode can be used generically
in an ATM network without PWE3, with exactly the same problems.

L.

---

From: "Rutemiller, John" <[email-masked]>
Date: Wed, 14 Aug 2002 13:04:47 -0400

> John> And even when they went into a  server instead of a desktop, it is
the
> John> same problem. 

Eric> No,  you'd  need  to  argue  that  both the  clients  and  the
servers  are
Eric> ATM-attached, and in a way that uses ATM as the network layer rather
than as
Eric> a data link.

I don't have to argue this. I can prove by example that ATM can and has been
used
as a network layer rather than a data link.

ATM attached desktops ATM communicated directly with ATM attached servers,
or
other ATM desktops. Many times, they used IP. But not always. In some cases,
the
application used AAL5/ATM directly.

> John> we know  that IP  provides a checksum  that will ultimately  catch
any
> John> errors. 

Eric> TCP; IP only checksums the IP  header.  Actually, even the TCP
checksum does
Eric> not provide  application level reliability.  If  you really want  to
be sure
Eric> that your file  has transferred correctly, you need a  checksum of the
file,
Eric> not checksums of the TCP segments into which the file has been split.

Agreed. Errored statement on my part.

> John> I agree that replacing the protection mechanism with another
> John> is a valid approach.  But it must provide equivalent protection. 

> John> Ethernet over ATM does this because AAL5 provides a CRC that
> John> goes between two Ethernet/ATM interworking devices.

Eric> If one  regards the purpose  of the ethernet  CRC as demonstrating
that the
Eric> packet  has not  been unintentionally  altered  between the  source
and  the
Eric> destination (as indicated  by the MAC address fields), then  the only
way to
Eric> achieve this purpose  is to carry the original CRC  unchanged from
source to
Eric> destination. If  on the other  hand, one regards  the purpose of the
CRC as
Eric> demonstrating that the packet has  not been unintentionally altered
while on
Eric> the  ethernet medium,  then its  purpose has  been achieved  as soon
as the
Eric> packet leaves  the ethernet medium.   In either case,  I don't see
that the
Eric> existence  of the  ethernet CRC  implies a  requirement for  an AAL5
CRC in
Eric> ethernet/ATM interworking.

If the encapsulation removes the Ethernet CRC, then an AAL5 CRC is required.
But
I would agree that it would be possible to define an encapsulation for ATM
that
does not provide a CRC knowing that Ethernet has a CRC.

But there are other applications that rely on the AAL5 CRC.

Eric> Theoretical considerations aside, we do all  seem to agree that the
SDU mode
Eric> specification should simply but clearly state the facts.

Agreed.

---

From: "Rutemiller, John" <[email-masked]>
Date: Wed, 14 Aug 2002 13:40:10 -0400

> Sent: Wednesday, August 14, 2002 1:08 PM
> To: Rutemiller, John
> Cc: [email-masked]
> What, ATM AAL5 CPCS-SDUs exist and are used only in PWE3?
> I do find that rather hard to believe.

An AAL5 SDU is nothing more than the payload of an AAL5 PDU. It only
exists in concept for describing the AAL5 SAR process. So you will
never see an AAL5 SDU transmitted in an ATM network, only an AAL5 PDU.

John

---

From: "Zheng Wang" <[email-masked]>
Date: Wed, 14 Aug 2002 10:45:10 -0700

> Lloyd,
> In case you have not heard, there's this technology called 
> ADSL that uses 
> ATM.  I think several million lines have been installed in 
> North America 
> and a decent percentage of those are NIC cards that are 
> installed into 
> desktop PCs.

Jim

Nobody is saying that ATM is not being used. The reason we are 
talking about ATM over MPLS is precisely because there is an installed
base of ATM in the network. However, the orginal vision of ATM
to the desktop (and everywhere) is dead. Today, ATM is used mostly
edge-to-edge, therefore the error protection part in ALL5 (an edge-to-edge
CRC) is not that useful anyway. 

CRC in ALL5 is still needed in the ATM portion of the network
because it provides other functions that are necessary for
the cell networks to work (w.g., detecting cell loss, detecting 
cell misordering). 

Cheers
Zheng

---

From: "Rutemiller, John" <[email-masked]>
Date: Wed, 14 Aug 2002 13:48:09 -0400

I had forgotten about 25Mb/s ATM. I was thinking about 155Mbps to the
desk with 155/622Mbps to the servers.

John

-----Original Message-----
From: Lloyd Wood [mailto:[email-masked]]
Sent: Wednesday, August 14, 2002 1:42 PM
To: Jim Harford
Cc: [email-masked]
Subject: RE: [PWE3] Question on Martini AAL-5 SDU mode 

On Wed, 14 Aug 2002, Jim Harford wrote:

> Lloyd,
> In case you have not heard, there's this technology called ADSL that uses
> ATM.  I think several million lines have been installed in North America
> and a decent percentage of those are NIC cards that are installed into
> desktop PCs.

(installed under contract != sold. how many of those lines were
installed in the 90s?)

I was thinking of the failure of 25Mb/s ATM to the desktop, only 20
years after 10Mb/s Ethernet appeared, and just as 100Mb/s Ethernet was
taking off.

L.
>
> At 05:16 PM 8/14/2002 +0100, you wrote:

---

From: Keith Knightson <[email-masked]>
Date: Wed, 14 Aug 2002 17:17:06 -0400

Zeng et al,

IMHO, all this "my layer is better than your layer for protection" 
stuff seems to miss a fundamental point.

A philosophical discussion about the best layer, or layers to put 
CRC(s) has nothing to do with providing an IEEE defined service 
between two CEs. It is, what it is,  and has to be respected, CRC, 
warts and all. Otherwise the service as defined by IEEE is not being 
provided.

So, the real issue here is whether  a psuedo wire carries stuff X 
from one CE, transparently to another CE or not. A CRC generated by a 
CE is end-to-end as far as the CEs are concerned. Just as it would be 
if PWE were not present. Stuffing it inside something that might or 
might not also have a CRC is irrelevant from the preservation of the 
original semantics perspective. As Neil pointed out it is not a case 
of hop-by-hop substitution.

Does insertion of PWE affect the normal operation of X that would 
occur if PWE was not present?

If the CRC would have been  CE-CE without PWE, will it be CE-CE with PWE?

In other words does PWE interfere/tamper with the stuff being 
presented at the ingress?

Can PWE3 generate something at the egress that was not received at the ingress?

This seems to be a fundamental issue for PWE, in general.

IMHO, the precise semantics should be sacrosanct (at least by 
intention, notwithstanding accidental manifestations).

If the decision is, that PWE is not transparent, then I guess any 
"payload" can be tampered with. What criteria can be used to 
know/restrict the degree of the tampering, I am not sure.  This seems 
to me to be a very slippery slope. It might be far better to say that 
the payload is sacrosanct, i.e. no tampering permitted.

Cheers

Keith

---

From: Keith Knightson <[email-masked]>
Date: Wed, 14 Aug 2002 17:19:01 -0400

Zeng et al,

Cheers

Keith Knightson

---

From: "Zheng Wang" <[email-masked]>
Date: Wed, 14 Aug 2002 15:54:47 -0700

> From: Keith Knightson [mailto:[email-masked]]

>From the perspective of two CEs, a PWE circuit is transparent. CE1 sends
out an Ethernet frame, and CE2 should get an identical Ethernet frame 
(unless some error occurs in between). 

If you are talking about completely transparent to the bits, then I would
argue that even including the CRC is not sufficient. We need actually
transport the 8b/10b encoded raw signal on the wire from CE1 to CE2. 

Cheers
Zheng

---

From: Maarten Vissers <[email-masked]>
Date: Thu, 15 Aug 2002 08:13:14 +0200

> transport the 8b/10b encoded raw signal on the wire from CE1 to CE2.

Transparency is always defined for the signal of a particular layer network. The
PWE circuit provides Ethernet MAC layer signal transparency, not Ethernet PHY
layer transparency. As such it also allows that the CE1 is connected via e.g. a
100 Mbit/s PHY and the CE2 is connected via a 1 Gbit/s PHY.

Regards,

Maarten

---

From: Maarten Vissers <[email-masked]>
Date: Thu, 15 Aug 2002 08:39:01 +0200

> occur if PWE was not present?

Should not be the case. Not to forget however that during the definition of X
one should have considered that X could be carried over a server layer Y. 
X=MAC and originally Y=PHY. Later on Y became also ATM VC/AAL5, and recently Y
became SDH VC-n/GFP. Now we add Y is MPLS VC.

> If the CRC would have been  CE-CE without PWE, will it be CE-CE with PWE?

Is the CRC really CE-CE without PWE? Etehrnet over ATM could operate without
forwarding the CRC. Ethernet over SDH (via GFP) allows to drop corrupted MAC
frames (errored CRC) at ingress of SDH network. Do Ethernet bridges/switches
forward MAC frames with corrupted CRC?

If CE-CE would be connected to ethernet LAN with VLANs, then CRC is recomputed
when VLAN tag is added/removed. Only error free MAC frames (correct CRC) will be
forwarded, errored MAC frames will be dropped in this case.

So what function does CRC in the MAC have? 
- If it is restricted to detect if the MAC frame is errored (and then to drop
that frame), then the PWE may drop errored frames at ingress, may replace CRC at
ingress with other protection means and add CRC at egress if frame at that point
is error free (will have same value as CRC at ingress).
- If CRC is used by user (CE-CE) to monitor the performance obtained from the
network (e.g. MPLS/IP (PWE), ATM, SDH) including access links, then the CRC must
be transparently passed through the network and errored MAC frames must pass
through also.

> presented at the ingress?

Depends.

> Can PWE3 generate something at the egress that was not received at the ingress?

It can generate a MAC FCS (CRC) at egress if it is known that MAC frame was
passed through error free and was received error free at ingress... the CRC
value generated at egress will be copy of its value at ingress.

> This seems to be a fundamental issue for PWE, in general.

Not only for PWE.

Regards,

Maarten

---

From: Sasha Vainshtein <[email-masked]>
Date: Thu, 15 Aug 2002 09:36:03 +0200

Eric, John, Andy and all, 

I agree with Eric, and I think that the following example 
strengthens his position:

RFC1490 and its continuation, RFC2427/STD55 both support two modes of
for carrying bridged Ethernet over FR: with and without preserved LAN FCS
(PID = 0x0001 and 0x0007 respectively).
  
I do not have any data on deployment, but I strongly suspect that
the mode that does not carry LAN FCS is quite popular. And,of course, the FR
FCS
is just at the link level: the DLCI field is swapped,and the FCS
recalculated
ar each hop.

BTW, if you put aside the case of Ethernet switches swapping VLAN IDs
(possible, but, AFAIK, not widely deployed), the Ethernet FCS is
effectively "edge-to-edge".

Andy, can you possibly, as one of the authors of RFC2427, comment on that?

Two more points may be worth noting:

1. IMHO there are two ways to look at the the AAL5 CRC:
   a) As an architectural element protecting data integrity edge-to-edge
   b) As a compensation for lack of the link level protection
      of the ATM cells' payload (HEC protectsonly the cell header).
      
2. Let's consider the imaginary case when a frame-oriented PW preserves the
   original FCS. Such a feature would definitely help to drop frames that
   have been damaged while crossing one of the routers in the core (not on
   the router-to-router link,because these are protected by their L2
methods).
   However, IMHO it would be almost useless for locating the rogue
   and fixing the problem. In other words, its usefulness wouldbe quite
limited.
----------------------------------------------------------------------------
--------
With best regards,
                          Sasha Vainshtein
email:   [email-masked] <mailto:[email-masked]> 
phone:  +972-3-7659993 (office)
            +972-8-9254948 (home)
            +972-58-674833 (cellular)

> Sent: Wednesday, August 14, 2002 6:38 PM
> To: Rutemiller, John
> Cc: [email-masked]
> John> Those NIC cards several companies sold in the 90s went 
> somewhere. 
> 
> Next to the FDDI cards, I think. 
> 
> John> And even when they went into a  server instead of a 
> desktop, it is the
> John> same problem. 
> 
> No,  you'd  need  to  argue  that  both the  clients  and  
> the  servers  are
> ATM-attached, and in a way that uses ATM as the network layer 
> rather than as
> a data link.
> 
> John> we know  that IP  provides a checksum  that will 
> ultimately  catch any
> John> errors. 
> 
> TCP; IP only checksums the IP  header.  Actually, even the 
> TCP checksum does
> not provide  application level reliability.  If  you really 
> want  to be sure
> that your file  has transferred correctly, you need a  
> checksum of the file,
> not checksums of the TCP segments into which the file has been split.
> 
> If one  regards the purpose  of the ethernet  CRC as 
> demonstrating  that the
> packet  has not  been unintentionally  altered  between the  
> source and  the
> destination (as indicated  by the MAC address fields), then  
> the only way to
> achieve this purpose  is to carry the original CRC  unchanged 
> from source to
> destination. If  on the other  hand, one regards  the purpose 
> of the  CRC as
> demonstrating that the packet has  not been unintentionally 
> altered while on
> the  ethernet medium,  then its  purpose has  been achieved  
> as soon  as the
> packet leaves  the ethernet medium.   In either case,  I 
> don't see  that the
> existence  of the  ethernet CRC  implies a  requirement for  
> an AAL5  CRC in
> ethernet/ATM interworking.
> 
> Theoretical considerations aside, we do all  seem to agree 
> that the SDU mode
> specification should simply but clearly state the facts.
> 
> 
> 
> 
> 
> 
> 
>

---

From: "Bob Barrett" <[email-masked]>
Date: Thu, 15 Aug 2002 09:38:54 +0100

The issue is that when re-calculating the CRC at the PWE3 egress. An
Ethernet frame with erroneous data would have a correct CRC. There is a very
small chance of this happening on a p2p Ethernet link. (You would have to
ask a dot3 expert for the odds.)

If the PWE3 protects the Ethernet frame in transit within the same limits as
a p2p wire then this would be acceptable imho, as it is no worse than 'real
Ethernet'.

Progressing that thought process, the PWE3 payload should be protected by a
CRC of equal performance per bit to an Ethernet CRC. This would be inherent
if the transport was MPLS over Ethernet. However, the PWE3 specifications
are transport agnostic and therefore should have error protection at the
PWE3 layer, or carry the protection mechanism inherent in the payload.

What I think PWE3 should avoid is allowing multiple options that are
negotiated at PWE3 set up, which would further complicate an already quite
complex OAM mechanism. i.e. a combination of minimum intervention and 'keep
it simple'.

Best regards

Bob

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
Maarten Vissers
Sent: 15 August 2002 07:39
To: Keith Knightson
Cc: [email-masked]
Subject: Re: [PWE3] Question on Martini AAL-5 SDU mode

> occur if PWE was not present?

Should not be the case. Not to forget however that during the definition of
X
one should have considered that X could be carried over a server layer Y.
X=MAC and originally Y=PHY. Later on Y became also ATM VC/AAL5, and recently
Y
became SDH VC-n/GFP. Now we add Y is MPLS VC.

If CE-CE would be connected to ethernet LAN with VLANs, then CRC is
recomputed
when VLAN tag is added/removed. Only error free MAC frames (correct CRC)
will be
forwarded, errored MAC frames will be dropped in this case.

So what function does CRC in the MAC have?
- If it is restricted to detect if the MAC frame is errored (and then to
drop
that frame), then the PWE may drop errored frames at ingress, may replace
CRC at
ingress with other protection means and add CRC at egress if frame at that
point
is error free (will have same value as CRC at ingress).
- If CRC is used by user (CE-CE) to monitor the performance obtained from
the
network (e.g. MPLS/IP (PWE), ATM, SDH) including access links, then the CRC
must
be transparently passed through the network and errored MAC frames must pass
through also.

Depends.

Not only for PWE.

Regards,

Maarten

---

From: "Bob Barrett" <[email-masked]>
Date: Thu, 15 Aug 2002 09:38:52 +0100

But only in the boundary case where minimum asymptotically approaches zero
:-).

The payload has to be tampered with to adapt it to PWE3, even if the
tampering is limited to segmentation and reassembly. That would be the limit
of minimal intervention in PWE3 imho. Doing more than that e.g. putting T1
CAS signalling channels in RTP packet payloads, is a step to far as far as I
am concerned. However, the justification for doing that, and stripping and
re-inserting CRCs etc. is to save bandwidth on the uplink. This may be out
of scope for PWE3 but there are some applications that envisage PWE3 over
Ethernet over low bandwidth copper first mile / last mile networks, where
bandwidth saving is perceived as a factor.

Personally I am in the keep it simple (Minimum Intervention) camp and run it
over a fat pipe e.g. optical 1GE.

Best regards

Bob

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of Lloyd
Wood
Sent: 14 August 2002 22:22
To: Keith Knightson
Cc: [email-masked]
Subject: RE: [PWE3] Question on Martini AAL-5 SDU mode

> the payload is sacrosanct, i.e. no tampering permitted.

ah, you mean The Principle of Minimum Intervention.

L.

---

From: Sasha Vainshtein <[email-masked]>
Date: Thu, 15 Aug 2002 12:28:00 +0200

Bob and all,
Please see a comment inline.

With best regards,
                                   Sasha Vainshtein

> Sent: Thursday, August 15, 2002 10:39 AM
> To: Maarten Vissers; Keith Knightson
> Cc: [email-masked]
>.snipped ...
> CRC of equal performance per bit to an Ethernet CRC. This 
> would be inherent if the transport was MPLS over Ethernet.
>
AFAIK, MPLS over Ethernet would NOT provide any inherent
protection of the PWE3 payload unless you assume that the
"transport" LSP crosses just one Ethernet hop.
... snipped ...
> negotiated at PWE3 set up, which would further complicate an 
> already quite complex OAM mechanism. i.e. a combination of minimum 
> intervention and 'keep it simple'.
> 
As I have mentioned in my previous message on the subject, RFC2427 
supports two modes for carrying bridged Ethernet frames over FR - with 
and without the LAN FCS. (BTW, the same two modes are deffined for
bridged Ethernet over AAL5). Hopefully we could learn something from
the actual deployment of these modes.
> > Can PWE3 generate something at the egress that was not 
> received at the
> ingress?
>

---

From: [email-masked]
Date: Thu, 15 Aug 2002 12:15:01 +0100

Lloyd Wood wrote 14 August 2002 22:22
> ah, you mean The Principle of Minimum Intervention.
NH=> This is not specific enough.  I'd put it more like this (data-plane
only):
-	true client/server relationships have no tampering with the client;
-	protocol-conversion relationships between 2 server layer trails have
no tampering with the payload but map the server trail functionality (as
best as they can).
In the former the client layer trail passes transparently through the
server, in the latter the payload/client of both server layers does likewise
but the actual 2 server layer trails (which are peers) terminate at some
interworking point.  There are very different fault handling requirements in
these 2 cases, but they can be defined *if* we respect trail entities
correctly.  When people start butchering layer network trails for some
expedient need (usually some miniscule BW saving) then clean fault
handling/performance relationships are no longer possible....so we get more
expedient kludges.
regards, Neil

---

From: [email-masked]
Date: Thu, 15 Aug 2002 12:14:58 +0100

Sasha Vainshtein wrote 15 August 2002 08:36
 
> is just at the link level: the DLCI field is swapped,and the FCS
NH=> Because FR assumes there is something higher checking its own
intergrity.
>    a) As an architectural element protecting data integrity 
NH=> Correct, but strictly between AAL5 trail termination points.  I don't
like the term edge-edge, because architecturally it's end-end from the AAL5
perspective.....and there are many layer networks recursively nested and
they all have trails end-end between their termination points.  Edge-edge
seems a woolly descriptor to me........bit like calling things
'path-oriented' when what is really meant is connection-oriented, but the
words seem hard to form ;-)

>       of the ATM cells' payload (HEC protectsonly the cell header).
NH=> Is this not simply a consequence of a) above, ie if a) is true then why
require b)? Further, it seems it only gets applied to AALs which are deemed
to need it, ie AAL1 does not have a similar CRC (not saying this is
right/wrong, just making the observation).  BTW - HEC CRC is there to help
stop misconnectivity defects......VPI/VCI labels are not network-wide unique
addresses....as this is considered a more serious form of error effect, and
obviously has to be done on a per-link-connection level.   
>    and fixing the problem. In other words, its usefulness 
NH=> You could just as easily argue the opposite.  If such events are rare
*and* their consequences are not severe (cf misconnectivity wrt HEC which is
potentially severe defect), then continuous calculation per hop is not
needed.  However, one still needs to have some network integrity check (done
once) in order to alert you to go and look for the problem.  Then one uses
ad hoc OAM tools and other methods if needed (like OOS testing if required)
to diagnose where the problem is in the network(s).
One further important observation.....consider what you have stated above
wrt defect resolution when there are several layer networks all nested.  At
the top level we have a single link-connection (aka hop) between 2 nodes at
layer N say. In turn, this link-connection at layer N is formed by a trail
at layer N-1.  Each link connection in the layer N-1 trail is also formed by
trails at layer N-2.....this recurses to the duct, and this is how we
construct network topologies from the duct upwards.  So whilst you might see
problams flagged by the pair of nodes at layer N the real problem could be
in one of many nodes at lower network layers.....so the resolution argument
is not that valid IMO.  The bottom line is that each trail requires to
manage its own affairs.....noting in particular that the trails may be in
different commercial domains.  And this reinforces my earlier point about
end-end being a property of the perspective of the trail in question (and
who owns it).

regards, Neil

---

From: "Rutemiller, John" <[email-masked]>
Date: Thu, 15 Aug 2002 10:06:57 -0400

Sasha,

You make the statement:

<start quote>
<end quote>

So if I understand your second point, you are trying to say that the
only reason we need a CRC in AAL5 is because ATM does not provide
link level protection. Correct?

Well, this is 100% wrong.

And based purely bias against ATM and not on any logic.

Following your argument, it would imply that if every link in the
Internet provided link level protection (which is probably true),
we could get rid of the CRC in TCP and probably even IP.

I don't believe anyone would make this argument, but this is what you
effectively just did.

John

---

From: Sasha Vainshtein <[email-masked]>
Date: Thu, 15 Aug 2002 17:45:38 +0200

John,
Please see some comments inline.

With best regards,
                                   Sasha Vainshtein

> Sent: Thursday, August 15, 2002 4:07 PM
> To: [email-masked]
No, that is not what I have meant. Lack of the link level protection
in ATM is not the *only* reason for the AAL5 CRC. However, I believe 
that lack of the link level protection *increases* the need in the 
AAL5 CRC.
IMHO the example with two Ethernet over FR modes illustrates
this point - there are enough customers that assume that FR switches
do not introduce errors while links between them do. Or, at least,
the probability of an error resulting from the link problem is much
higher than that resulting from the switch internal problem.
There are others that prefer "to be on the safe side". I think that
the option to carry Ethernet over FR without LAN FCS would never be 
considered if FR would not provide link level protection.

BTW, Ethernet over AAL5 supports the same two modes. As you have noticed
before, the AAL5 CRC can be used to replace the Ethernet CRC, but,
presumably,
some people prefer both.
 
> we could get rid of the CRC in TCP and probably even IP.
IPv4 indeed does not provide any payload checksums, only header checksums.
And even these are absent in IPv6.
> I don't believe anyone would make this argument, but this is what you
The argument I have tried to make is that carrying the FCS of the
original frame-oriented service over a PW should be an option, not a must.
I regret if anything else was perceived.

---

From: "Yaron Raz" <[email-masked]>
Date: Thu, 15 Aug 2002 18:34:41 +0300

If I remember correctly from my ATM days a SAR device does not hand out the CRC of the AAL5 to its upper layer, just like it does not request it from the upper layer. It calculates it on the segmentation path.
Assuming people use of-the-shelve SAR devices, you cannot do reassembly at the ATM side and still have the CRC for adding on the PW side.
Asuming you recalculate it at the ingress PE (which breaks the end-to-end argument), you will not be able to force the SAR at the egress PE to put it in.
So the technical feasibility of transporting the CRC inside the PW is very questionable in my view.

---

From: Jim Harford <[email-masked]>
Date: Thu, 15 Aug 2002 15:35:36 -0400

Yaron,
You are correct, it would be difficult to transport CRC with off-the-shelf 
components for AAL-5 SDU mode.  We are back to the same design tradeoff: 
transparent carriage of an existing service (i.e. ATM), versus inventing a 
new service that can be used with the existing hardware.

Jim Harford

At 06:34 PM 8/15/2002 +0300, Yaron Raz wrote:
>If I remember correctly from my ATM days a SAR device does not hand out 
>the CRC of the AAL5 to its upper layer, just like it does not request it 
>from the upper layer. It calculates it on the segmentation path.
>Assuming people use of-the-shelve SAR devices, you cannot do reassembly at 
>the ATM side and still have the CRC for adding on the PW side.
>Asuming you recalculate it at the ingress PE (which breaks the end-to-end 
>argument), you will not be able to force the SAR at the egress PE to put it in.

---

From: "Bob Barrett" <[email-masked]>
Date: Fri, 16 Aug 2002 10:08:10 +0100

Jim at al

Do you ever wonder if there might be an ASIC out there that can do this
(transport AAL5 CRC). I guess if I had an ASIC that could do clever stuff
like that I might want to leverage it into a standard, pardon the cynicism
:-).

I am in the keep it simple and waste a byte camp. I can't see the logic of
making the protocol handling significantly more complex just to save 1 or 2
percent of bandwidth. I thinking in terms of saving DS0s here, not just the
FCS questions. My other opinions on the market are too political for this
forum, and I can do anything about it, so I'll shut up about that.

I can see the logic and benefit in carrying an Ethernet FCS end to end
within a tunnel, and that is relatively easy to do, even if the FCS is
terminated at the edge and re-calculated by the PE interface facing the
tunnel. The mechanism is still the same as the Blue Book from 20 years ago
i.e. not a lot of gates required. Checking the (Ethernet payload) FCS at the
egress PE is a simple a reliable way of ensuring that only correct 'frames',
to use the 802.3 nomenclature, are transmitted without having to rely on
tunnel specific error monitoring / error correction functions. Striping the
FCS at ingress and simply re-calculating the FCS at egress places a heavy
burden on the integrity of the tunnel  transport. Sure the FR transport was
reliable enough, and MPLS transports are likely to be also, but I guess I
see a benefit in 'reliable squared' (belt and braces to my U.K. brethren).

Defining a standard that allows the transmitting of corrupted payload data
in Ethernet frames with a good Ethernet FCS is a bad idea. This is what you
can easily get if the Ethernet FCS is re-calculated at the egress on a
corrupted payload.

Bob

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of Jim
Harford
Sent: 15 August 2002 20:36
To: Yaron Raz; [email-masked]; [email-masked];
[email-masked]
Cc: [email-masked]
Subject: RE: [PWE3] Question on Martini AAL-5 SDU mode

Yaron,

Jim Harford

---

From: David Sinicrope <[email-masked]>
Date: Mon, 19 Aug 2002 15:59:51 -0400

Sasha,
Please see my comment RE: RFC 2427 inline below.
David Sinicrope

>is just at the link level: the DLCI field is swapped,and the FCS

The 2427 mode that carries the LAN FCS is rare.  The LAN FCS is typically 
checked (generated) by hardware as the packet is received and not given to 
(or passed from) the upper layer.  This makes it difficult to encapsulate 
it into FR without regenerating it or having "special" hardware to pass the 
FCS to the upper layer.  Same applies to the decapsulation.  A special LAN 
FCS check must be done after the link level check which requires a software 
check or special hardware.  The software check is typically too 
slow.   Because of this, the mode that does not carry the LAN FCS is what 
is used most often.  This is similar to the issue raised on the list 
regarding the passing of the AAL5 CRC to the upper layer using "off the 
shelf" hardware.  Typically, the FCS/CRC is generated and checked as the 
frame is passed through the hardware, and is not seen by the upper layer.

>    and fixing the problem. In other words, its usefulness wouldbe quite

IMHO, something should be provided to guard against corruption while 
crossing the routers in the core. If not the original FCS, then perhaps a 
TCP-like checksum or something similar passed edge2edge should be provided 
to help ensure the edge2edge integrity.  I agree that it would be useless 
for finding the rogue.  However, I don't agree that dropping frames 
corrupted in a core router has limited usefulness.  I think it is 
mandatory.  The PW provider doesn't know what the Ethernet, or FR or ATM is 
carrying in its payload.  It may be protected by the upper layer or not, 
but the expectation is that it was protected as though it had been passed 
on the original layer 2,  or better.

============================================================
David Sinicrope   +1-919-472-9967  [email-masked]
Ericsson IP Infrastructure               Fax:+1-919-472-9999

---

From: Shahram Davari <[email-masked]>
Date: Mon, 19 Aug 2002 13:36:00 -0700

Sahsa,

>    and fixing the problem. In other words, its usefulness 

Localization of the problem is another issue. The main issue is passing
corrupted data to the user and rubber stamping it by generating a valid CRC after
corruption.

-Shahram

---

From: [email-masked]
Date: Tue, 20 Aug 2002 08:31:12 +0100

Shahram wrote to Sahsa, 19 August 2002 21:36
> generating a valid CRC after

NH=> The rougue node location notion problem is indeed something else.
End-end integrity for a given trail at layer N (or edge-edge if some prefer
that) needs checking.  Note that the link-connections of the layer N trail
are themselves trails at layer N+1.  In turn, each of these layer N+1 trails
are composed of link-connections which are formed by trails at layer
N+2...and so it recurses to the duct.  It is therefore apparent that end-end
is a *different* span entity in each case, and all of these trails need an
independent end-end integrity check.  Therefore, even having per
link-connection integrity checking at layer N does not necessarily locate
the problems if it resides in a lower layer network. Now, besides the
obvious technical truth of this observation, a commercial reason why one
needs independent end-end integrity checks per layer trail is when diffent
layer networks are owned by different organisations.

regards, Neil

---

From: "Bob Barrett" <[email-masked]>
Date: Tue, 20 Aug 2002 11:11:19 +0100

Neil wrote:

> Now, besides the

With the wholesale business models that operate in the service provider
market place today, an edge to edge link may traverse different layer
networks that are owned by many different organisations, each with their own
SLAs, each with their own NOCs and OAM&P needs.

Neil raises the issue of commercial acceptability of the PWE3 work. I would
like to raise another commercially related issue.

This point concerns using "off the shelf" hardware. There appears to be a
latent feeling in PWE3 (and a firm belief in 802.3ah EFM) that PE will be
'low cost' if it can leverage current off the shelf volume silicon. I would
make the observation that it doesn't matter how low cost the PE is if the
specification and performance that it can provide does not meet the needs of
the service provider customers.

As an example, accomodating within the PWE3 specifications, the limitations
of using commercial Ethernet and ATM ICs that calculate and terminate CRC
etc. at the edge, may result in limiting the capabilities of the PWE3
standard such that it is not possible to build commercially viable products
that conform to PWE3 and that are acceptable to the market place /
customers. It's not that hard nor expensive to implement the Ethernet and
ATM interfaces required for PEs in commercial PLDs without having to bend
the standard to fit the chips. I can understand why this view may not fit
some of the chip makers business models. However, if the systems vendors
build PE products that don't meet the market needs then they don't sell, and
if they don't then sell chip vendors don't sell chips either. That's a bit
of a statement of the obvious, but so was the fact that most NASDAQ telco
stocks and tech stocks were grossly overvalued in 2000 ;-).

Best regards

Bob

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
[email-masked]
Sent: 20 August 2002 08:31
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [PWE3] Question on Martini AAL-5 SDU mode

regards, Neil

---

From: Eric Rosen <[email-masked]>
Date: Tue, 20 Aug 2002 10:52:03 -0400

Bob> it is not  possible to build commercially viable  products that conform
Bob> to PWE3 and that are acceptable to the market place 

There's only one way to determine the commercial viability of a product, and
debate on an IETF mailing list is not the way.

---

From: Jim Harford <[email-masked]>
Date: Thu, 22 Aug 2002 19:07:26 -0400

David Sinicrope asked, "Is it ATM AAL5 or not?".  The answer is NO, it's not.

SDU mode allows the carrier to provide a variable-length frame transport 
service with the following characteristics:
   1. The delivery of frames cannot be guaranteed.
   2. If a frame is delivered, it will be in sequence order (assuming that 
sequence numbers are used across the PW or some other guarantee of FIFO 
delivery is present).
   3. The correctness of delivered frames cannot be detected or guaranteed.
   4. Maximum frame size is 64K bytes.
   5. The service is accessed via ATM virtual circuits with AAL type 5, 
subject to these restrictions:
       a). The least significant bit of the AAL-5 UU field is 
transported.  The other bits of the UU field are discarded.
       b). Cell encryption (via ATM Security) is not supported.

IF the AAL-5 CRC was carried across the PW, then property # 3 would change 
to, "The correctness of delivered frames can be detected."

My question continues to be, do carriers really want to offer such a 
service?  I think if they spell out all of these warts in the SLA, then 
customers will choose a better service with characteristics familiar to 
them (e.g. ATM, FR, Ethernet).

Jim Harford

At 12:30 PM 8/20/2002 -0400, David Sinicrope wrote:
>At 10:50 AM 8/20/2002, Eric Rosen wrote:
>>David> The  PW provider  doesn't know  what the  Ethernet, or  FR or  ATM is
>>David> carrying in its  payload.  It may be protected by  the upper layer or
>>David> not, but  the expectation is that  it was protected as  though it had
>>David> been passed on the original layer 2,
>>
>>Eric> I  think by "upper  layer" here  you mean  the 
>>endsystem  application.  That
>>Eric> application cannot have  any expectations of the data  link layer, 
>>unless it
>>Eric> knows that  the two ends  of the application  are attached by 
>>a  single data
>>Eric> link. There  are a  few such  applications: DEC's old  LAT 
>>protocol  is one,
>>Eric> NETBEUI is  another.  Happily  these have largely  been 
>>replaced  by TCP/IP.
>
>IBM's SNA is another and that too has probably been replaced by TCP/IP or 
>runs on top
>of TCP/IP (i.e., Data Link Switching).  However, there are still folks 
>that run it over LAN
>protocols that are bridged over FR or ATM because the service definitions 
>of these protocols
>guarantee integrity across the VC.  So the expectation is still that the 
>data link
>provides the integrity even though the expectation shouldn't be there.
>
>The FR or ATM PW provider can't know whether it is transporting these 
>types of protocols or not.
>As you mention below, the provider can only define the service as 
>"perfect" or "imperfect"
>emulation and state the limitations.  So it comes down to the user having 
>to read the fine
>print of their ATM or FR PW service descriptions and know the subtle 
>characteristics of the application protocols
>they are running.  (I wonder how many providers would define their service 
>as "imperfect". :-)
>
>
>>Eric> However, it is fair to say  that running these applications over an 
>>ethernet
>>Eric> pseudowire  provides reduced integrity  when compared  to 
>>running  them over
>>Eric> real ethernet.   Whether this matters in  practice depends on  how 
>>many more
>>Eric> errors go undetected.
>
>It also depends on how the application protocol handles undetected 
>errors.  If it assumes
>integrity is provided,  it probably doesn't handle them too well.
>
>>Eric> Generally applications  that don't provide  their own integrity 
>>get  it from
>>Eric> the  transport layer.   In  connectionless networking,  the 
>>transport  layer
>>Eric> provides  integrity, but  in connection-oriented  networking,  the 
>>transport
>>Eric> layer may get integrity from the  network layer.  If, for example, 
>>there are
>>Eric> applications which  are designed to run directly  over a 
>>connection-oriented
>>Eric> network  layer, or applications  which run  over a  transport 
>>layer  that is
>>Eric> designed  to  run  over  a  connection-oriented 
>>network  layer,  then  these
>>Eric> applications cannot be assured the integrity  they expect.  So I 
>>think it is
>>Eric> fair to say that the AAL5  emulation, e.g., is sufficient to 
>>emulate AAL5 as
>>Eric> a data link  but not as a  network layer. whether this is  a 
>>practical issue
>>Eric> depends on how much use there is of ATM as a true network layer, 
>>rather than
>>Eric> as a data link.
>
>
>I guess I'm looking at this from the bottom up.  Since the PW provider 
>doesn't know how someone will
>use the AAL5 emulation, data link or network layer, all they can do is 
>state the service characteristics and
>let the user decide.  I think this could get pretty confusing for the 
>user.  "Is it ATM AAL5 or not?"
>
>>Eric> 
>>Anyway,  this  seems   to  all  be  in  the   area  of  "perfect  emulation"
>>Eric> 
>>vs.  "imperfect  emulation  with  applicability  statements  expressing  the
>>Eric> limitations", which we are not going to debate again, I hope.
>
>I hope I didn't start this debate again.  I can see that imperfect 
>emulation has a place.  I'm not sure integrity
>is one of the things that should be optional.
>
>
>
>
>
>>
>
>
>

---

From: "Andrew G. Malis" <[email-masked]>
Date: Thu, 22 Aug 2002 21:12:02 -0400

Jim,

There are three ATM Forum specifications, FUNI (Frame-based UNI for you 
non-ATM Forum folks out there), FATE (Frame-based ATM Transport over 
Ethernet), and FAST (Frame Based ATM over SONET/SDH Transport) mode 0 that 
cannot support the AAL5 checksum end-to-end, and the Forum certainly didn't 
see that to be a problem when they were specified.  You also can't use ATM 
security or performance cells with FUNI, FATE, or FAST mode 0.  The only 
real difference between these and SDU mode is that they carry the entire UU 
octet, other than that they have similar service characteristics to SDU mode.

Cheers,
Andy

-------

At 8/22/2002 04:07 PM -0700, Jim Harford wrote:

>>they are running.  (I wonder how many providers would define their 
>>service as "imperfect". :-)
>>
>>
>>>Eric> However, it is fair to say  that running these applications over 
>>>an ethernet

---

From: "Rutemiller, John" <[email-masked]>
Date: Fri, 23 Aug 2002 09:28:43 -0400

Jim,

The answer will depend on the carrier and how then intend to use this
service.

If they are a carrier that sells native ATM service to customer, the answer
will probably be they will not use SDU mode. The carrier does not know how
the customer is using the ATM service. The customer could be using AAL5 to
connect together routers, in which case it would be OK. Or the customer
could
be doing video directly over AAL5, relying on the AAL5 CRC to detect errors,
in which case it would be not OK.

So in this case, I agree with you.

But on the other hand, a carrier may have an existing ATM network being used
for connecting together their routers. They are introducing an MPLS core,
but
don't want to re-home all of their ATM attached routers. This may be due to
the significant capex and time involved, or they don't need faster
interfaces
on these routers (different from what is needed in the core), or the are
still
using ATM for QoS, or someother reason.

In this case, the carrier knows that their AAL5 traffic is IP and that the
loss of positive end-to-end verification of the AAL5 CRC does not represent
a problem.

This problem, and similar problems, are what SDU mode is designed to solve.

It is a different service with different requirements. And as a result, it
may
be exactly what some carriers want and may not provide any benefit to other
carriers.

This is why FAST had two modes. Because there were two distinct applications
that required different approaches.

And it is why the ATM Forum and the IETF came up with two different
approaches.
They were solving two different problems, both of which are relevant.

John

-----Original Message-----
From: Jim Harford [mailto:[email-masked]]
Sent: Thursday, August 22, 2002 7:07 PM
To: [email-masked]
Cc: David Sinicrope
Subject: Re: [PWE3] Question on Martini AAL-5 SDU mode 

David Sinicrope asked, "Is it ATM AAL5 or not?".  The answer is NO, it's
not.

      a). The least significant bit of the AAL-5 UU field is transported.
The other bits of the UU field are discarded.

My question continues to be, do carriers really want to offer such a
service?  I think if they spell out all of these warts in the SLA, then
customers will choose a better service with characteristics familiar to them
(e.g. ATM, FR, Ethernet).

Jim Harford

Eric> I  think by "upper  layer" here  you mean  the endsystem  application.
That
Eric> application cannot have  any expectations of the data  link layer,
unless it
Eric> knows that  the two ends  of the application  are attached by a
single data
Eric> link. There  are a  few such  applications: DEC's old  LAT protocol
is one,
Eric> NETBEUI is  another.  Happily  these have largely  been replaced  by
TCP/IP.

IBM's SNA is another and that too has probably been replaced by TCP/IP or
runs on top
of TCP/IP (i.e., Data Link Switching).  However, there are still folks that
run it over LAN 
protocols that are bridged over FR or ATM because the service definitions of
these protocols
guarantee integrity across the VC.  So the expectation is still that the
data link
provides the integrity even though the expectation shouldn't be there.  

The FR or ATM PW provider can't know whether it is transporting these types
of protocols or not.  
As you mention below, the provider can only define the service as "perfect"
or "imperfect" 
emulation and state the limitations.  So it comes down to the user having to
read the fine 
print of their ATM or FR PW service descriptions and know the subtle
characteristics of the application protocols 
they are running.  (I wonder how many providers would define their service
as "imperfect". :-)

Eric> However, it is fair to say  that running these applications over an
ethernet
Eric> pseudowire  provides reduced integrity  when compared  to running
them over
Eric> real ethernet.   Whether this matters in  practice depends on  how
many more
Eric> errors go undetected.  

It also depends on how the application protocol handles undetected errors.
If it assumes 
integrity is provided,  it probably doesn't handle them too well.

Eric> Generally applications  that don't provide  their own integrity get
it from
Eric> the  transport layer.   In  connectionless networking,  the transport
layer
Eric> provides  integrity, but  in connection-oriented  networking,  the
transport
Eric> layer may get integrity from the  network layer.  If, for example,
there are
Eric> applications which  are designed to run directly  over a
connection-oriented
Eric> network  layer, or applications  which run  over a  transport layer
that is
Eric> designed  to  run  over  a  connection-oriented network  layer,  then
these
Eric> applications cannot be assured the integrity  they expect.  So I think
it is
Eric> fair to say that the AAL5  emulation, e.g., is sufficient to emulate
AAL5 as
Eric> a data link  but not as a  network layer. whether this is  a practical
issue
Eric> depends on how much use there is of ATM as a true network layer,
rather than
Eric> as a data link. 

I guess I'm looking at this from the bottom up.  Since the PW provider
doesn't know how someone will 
use the AAL5 emulation, data link or network layer, all they can do is state
the service characteristics and
let the user decide.  I think this could get pretty confusing for the user.
"Is it ATM AAL5 or not?"

Eric> Anyway,  this  seems   to  all  be  in  the   area  of  "perfect
emulation"
Eric> vs.  "imperfect  emulation  with  applicability  statements
expressing  the
Eric> limitations", which we are not going to debate again, I hope. 

I hope I didn't start this debate again.  I can see that imperfect emulation
has a place.  I'm not sure integrity 
is one of the things that should be optional.