Subject: RE: AAL1/2 transport over IP/MPLS networks

From: "Yaron Raz" <[email-masked]>
Date: Tue, 10 Sep 2002 21:32:37 +0300

We have 3 methods for carrying PDH over PSN, 2 of which are actually building another network on top of the PSN in order to do that.
When considering the options, I think we should look into 2 cases:
1. When at least one of the end-points in the PSN is connected to a SONET or ATM network
2. When there is native PDH on both sides of the PSN

For case 1:
Since SONET is the natural way of carrying TDM, we all identify cases where the PDH actaully arrives at the PSN boundary in the form of a SONET VT. Carrying it as a VT across the PSN makes the SONET connecting side simpler, while complicating the plain PDH side (with respect to the CESoPSN approach), so there is a clear tradeoff here. In addition, there is the end-to-end PM issue raised by Maarten.
The same trade-off holds for ATM networks when working in the AAL1/2 mode. However, ATM is not a natural way of receiving a TDM stream. The only case where this would be seen is when a carrier connects a PSN network to an ATM network, and runs CES from one network to the other. Also, end-to-end PM cannot be carried transprently, and needs IWF in any case.

For case 2:
Obviously, the TDMoPSN way is the natural way of carrying PDH in this case.
I can also find myself explaining to a carrier: "Since we all know SONET is a great transport for TDM, I've built a Pseudo SONET network on top of the PSN for carrying all PDH traffic".
I would not like to find myself saying: "You wanted to transport PDH so I've built you a Pseudo ATM network on top of the PSN just for doing that..."

Bottom line, I think putting the pseudo SONET network and the pseudo ATM network at the same spot for carrying PDH is misleading to say the least. ATM is not a TDM transport technology by its own right.

-----Original Message-----
From: Shahram Davari [mailto:[email-masked]]
Sent: Monday, September 09, 2002 4:38 PM
To: 'tom k. johnson'; Ron Cohen; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]; Yaron Raz
Subject: RE: [PWE3] AAL1/2 transport over IP/MPLS networks

Tom,

SONET-VT and AAL5-PDU are existing accepted modes, which are designed to carry SONET and ATM over PSN. However, they could also be used to carry T1/E1 as following:

1) T1/E1 over VT over PSN using SONET VT mode 
2) T1/E1 over AAL1/2 over PSN using AAL5 PDU mode

There is nothing to stop people from doing so. I think it is incumbent upon CESoPSN authors to show that we need yet a brand new method for carrying T1/E1.

Even assuming that CESoPSN is simpler than the above methods, there are many cases that (1) or (2) are cheaper or easier or more readily available to be used. IETF is not in the habit of telling people what they MUST or MUST not deploy in their network. 

And Ron, simplicity is not always enough. An analogy is RSVP-TE and CR-LDP, although CR-LDP is a simpler protocol, IETF is talking about de-standardizing it.

Yours,
-Shahram  

> -----Original Message-----
> From: tom k. johnson [mailto:[email-masked]]
> Sent: Saturday, September 07, 2002 5:41 PM
> To: Ron Cohen; [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked]; Yaron Raz
> Subject: RE: [PWE3] AAL1/2 transport over IP/MPLS networks
> 
> 
> Ron - 
> 
> > In my mind deployments for high speed TDM transport or where a need
> > support for many TDM emulation ports will naturally pick SONET based
> > emulation while implementations that are targeted towards a 
> lower rate
> > applications or lesser number of ports where SONET OA&M is 
> > not an issue
> > will likely to use the native (CESoPSN) emulation proposal.  
> 
> I agree with you on the cases you've sited, but I wonder 
> about the hybrid case - where one end of the PW is a "lower 
> rate" application and the other end of the PW is a site that 
> needs "support for many TDM emulation ports".  
> 
> How does one decide what to do?  I suspect CPE vendors would 
> say, it's up to the site that needs "support for many TDM 
> emulation ports" to handle native emulation; while the CO 
> equipment vendors would say it's up to the CPE to support VT 
> encapsulation.  
> 
> That seems like a problem to me.  I'm just wondering what the 
> solution is...
> 
> -Tom
> _______________________________________________
> pwe3 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/pwe3
>

---

From: Shahram Davari <[email-masked]>
Date: Tue, 10 Sep 2002 11:48:18 -0700

Yaron,

> From: Yaron Raz [mailto:[email-masked]]
> Sent: Tuesday, September 10, 2002 2:33 PM
> To: Shahram Davari; tom k. johnson; Ron Cohen; [email-masked];
> [email-masked]
> Cc: [email-masked]; [email-masked]
> We have 3 methods for carrying PDH over PSN, 2 of which are 
> actually building another network on top of the PSN in order 
> to do that.
> Since SONET is the natural way of carrying TDM, we all 
> identify cases where the PDH actaully arrives at the PSN 
> boundary in the form of a SONET VT. Carrying it as a VT 
> across the PSN makes the SONET connecting side simpler, while 
> complicating the plain PDH side (with respect to the CESoPSN 
> approach), so there is a clear tradeoff here. In addition, 
> there is the end-to-end PM issue raised by Maarten.
> The same trade-off holds for ATM networks when working in the 
> AAL1/2 mode. However, ATM is not a natural way of receiving a 
> TDM stream. The only case where this would be seen is when a 
> carrier connects a PSN network to an ATM network, and runs 
> CES from one network to the other. Also, end-to-end PM cannot 
> be carried transprently, and needs IWF in any case.

Actually the end-to-end PM can be carried transparently in TDMoIP.

> I can also find myself explaining to a carrier: "Since we all 
> know SONET is a great transport for TDM, I've built a Pseudo 
> SONET network on top of the PSN for carrying all PDH traffic".
> I would not like to find myself saying: "You wanted to 
> transport PDH so I've built you a Pseudo ATM network on top 
> of the PSN just for doing that..."

These are internal to the device. As long as the service can be
provided reliably, it makes no difference for a 
provider. An analogy is using a cell switch fabric in a router.
How do you explain to a provider that you are converting
IP packets to ATM cells just to get it across the switch fabric?

These are all related to marketing, and non technical. 

> 
> Bottom line, I think putting the pseudo SONET network and the 
> pseudo ATM network at the same spot for carrying PDH is 
> misleading to say the least. ATM is not a TDM transport 
> technology by its own right.

Like it or not, AAL1/2 are designed to carry TDM.

-Shahram 

> SONET-VT and AAL5-PDU are existing accepted modes, which are 
> designed to carry SONET and ATM over PSN. However, they could 
> also be used to carry T1/E1 as following:
> 
> There is nothing to stop people from doing so. I think it is 
> incumbent upon CESoPSN authors to show that we need yet a 
> brand new method for carrying T1/E1.
> 
> Even assuming that CESoPSN is simpler than the above methods, 
> there are many cases that (1) or (2) are cheaper or easier or 
> more readily available to be used. IETF is not in the habit 
> of telling people what they MUST or MUST not deploy in their network. 
> 
> And Ron, simplicity is not always enough. An analogy is 
> RSVP-TE and CR-LDP, although CR-LDP is a simpler protocol, 
> IETF is talking about de-standardizing it.
> 
> 
> Yours,
> -Shahram  
>

---

From: "Yaron Raz" <[email-masked]>
Date: Tue, 10 Sep 2002 22:09:11 +0300

> IP packets to ATM cells just to get it across the switch fabric?
What you do inside your device is your own business. However, in the AAL1/2 case you see this on the packets themselves.
If you look at a packet you will see chunks of 53 bytes out-of-which 5 are irrelevant, and the other 48 are somehow related (once you have taken out the overhead that seems to repeat every now and then). You are actually running an ATM network on the PSN. The cells just happen to be glued together in one packet. I can understand this if you are really trying to transport ATM cells, and I agree your draft may make sense for carrying AAL1 cells in addition to AAL5 if this is what you are getting.
Taking a perfectly healthy TDM stream and putting it through this process is anything but "minimum intervension".
Taking the same approach as the AAL1/2 for TDM, maybe we could offer the ATM's LAN emulation "glued cells" as an additional way of doing VPLS.

---

From: Shahram Davari <[email-masked]>
Date: Tue, 10 Sep 2002 12:24:32 -0700

> What you do inside your device is your own business. However, 
> in the AAL1/2 case you see this on the packets themselves.
> If you look at a packet you will see chunks of 53 bytes 
> out-of-which 5 are irrelevant, and the other 48 are somehow 
> related (once you have taken out the overhead that seems to 
> repeat every now and then).

I think you need to read the TDMoIP and draft-davari again. The payload
does not have the 5 bytes that you worry about.

>You are actually running an ATM 
> network on the PSN. The cells just happen to be glued 
> together in one packet.

Wrong. Just using AAL1/2 method for emulating TDM doesn't mean we
are running an ATM network on the PSN. Only the edge devices
need to know this. This is obvious from the fact that there are
many many ATM functions not needed such as ATM OAM/RM.

> I can understand this if you are 
> really trying to transport ATM cells, and I agree your draft 
> may make sense for carrying AAL1 cells in addition to AAL5 if 
> this is what you are getting.

This is one application of it.

> Taking a perfectly healthy TDM stream and putting it through 
> this process is anything but "minimum intervention".

1) We are not reducing the health of the TDM stream. We are just
emulating it. You need an emulation if you want to convert TDM
to packet.

2) I think another principle is missing from that draft and that
is principle of "minimum new protocol" or "reuse of existing protocols"

> Taking the same approach as the AAL1/2 for TDM, maybe we 
> could offer the ATM's LAN emulation "glued cells" as an 
> additional way of doing VPLS. 

You could, but it is not advisable, because as I mentioned in
another email to Sasha, emulation is much more complicated than simple
encapsulation. For Ethernet you could easily encapsulate the Ethernet
frame completely in an IP packet. For TDM you can't do that so easily,
rather you need to invent new methods.

-Shahram

---

From: [email-masked] (Amnon Ilan)
Date: Wed, 11 Sep 2002 11:17:56 +0200

Hi all,

I would like to support Shahram's arguments in this debate.

1. The Voice-Over-Packet market knows, currently, two protocols for TDM over
packet networks: VoIP and VoATM.
    VoIP is not designed to support circuit emulation and efficient voice
trunking. VoATM is designed for that. That
    is what makes it suitable for PWE (no relation to native ATM at all, and
indeed ATM cells should not be used, only
    AAL1/2 packets).
2. Market knowledge means that there are many vendors and operators who
knows it.
    There are many existing, working, stable products supporting AAL1/2. For
these vendors the most natural way is
    to encapsulate AAL1/2 packets in IP. Same goes for the operators who
will see this as an "evolution" and not a
    "revolution". To prove this concept of "evolution" you may look at what
SG13 of the ITU is suggesting for VoMPLS:
    although the MPLS Forum is also trying to reinvent VoATM, SG13 had
include in their proposal another method
    for direct encapsulation of AAL2 packets in MPLS.
3. Introducing a new protocol will cause: a need to reeducate the market,
long time-to-market for first mature products,
    smaller number of vendors supporting it (at least during the first 3-5
years).
4. There is some influence on future markets and future standards as well
(3G, VoMPLS, VoDSL etc. who base their
    solutions on VoATM).
5. At least on the lower speeds (E1/T1) the VoP features are required
(including AAL2 features that are not supported
    by CESoPSN). This means that one will be forced to do some VoP protocol
and then use CESoPSN or SONET-VT
    for this levels, and that extra protocol in the middle does not add any
functionality.
6. Choosing AAL1/2 approach releases PWE3 from the need to get into the
voice details, without the price of
    reduced functionality.

My bottom line is: at least for the E1/T1 level there should be only a
single standard and the most natural protocol
for that is TDMoIP (has all the required functionally as well as a better
market-acceptance chances). For higher PDH
and SONET speeds SONET-VT is a good solution.

Amnon.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of Shahram
Davari
Sent: Tue 10 September 2002 21:25
To: 'Yaron Raz'; tom k. johnson; Ron Cohen; [email-masked];
[email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: [PWE3] AAL1/2 transport over IP/MPLS networks

-Shahram

---

From: [email-masked]
Date: Wed, 11 Sep 2002 19:40:00 +0100

One observation on all this as an operator.  We need a consistent way to
interface the same application, for example voice, to all pkt-sw
technologies....else gateways loom => further unecessary costs and perf
hits.

This suggests to me that operators should support Shahram's view on this,
which Amnon also supports below.

regards, Neil  

> From: [email-masked] [mailto:[email-masked]]
> Sent: 11 September 2002 10:18
> To: 'Shahram Davari'; 'Yaron Raz'; 'tom k. johnson'; 'Ron Cohen';
> Tim.Frost; pwe3
> Cc: bob.barrett; danny

---

From: "Bob Barrett" <[email-masked]>
Date: Fri, 13 Sep 2002 17:56:24 +0100

Tom

If only it were that easy.

A possible compromise could be one draft that specifies how T1/E1 and T3 are
carried over a PSN (as trunks, payload agnostic (clear channel effectively),
and another that deals with OC-3/STM-1 and OC-12 over a PSN, (as trunks,
payload agnostic).

All the fancy sub-rate DS0 stuff for T1/E1, and all the VT stuff for
OC-3/SDH are then NSP issues, and the standards for those mappings exist, as
does much silicon.

The only other piece of new technology (if we ignore the fact that one of
the ATM specs partially addresses it and could be bent to fit) is the
protection / ruggedisation of CAS/CCS signalling mechanisms over an
imperfect transport. This is effectively an error handling / spoofing
protocol and nothing to do with transport over PSN per se.

So we get three new documents, that can be put together by implementers with
specs. from existing documents, to build new systems. I think a few of the
guys are working along these lines already.

I thought that was how the standards process is meant to work. So long as
the externally observable behaviour of the system conforms, then so does the
box. What happens on the inside (e.g. mapping T1/E1s received over PSN to
Sonet VTs), and how it is done is irrelevant as far as the standards process
is concerned, so long as they come out right at the ports.

Best regards

Bob

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of tom
k. johnson
Sent: 05 September 2002 22:34
To: [email-masked]; [email-masked];
[email-masked]; [email-masked]
Cc: [email-masked]; Yaron Raz
Subject: RE: [PWE3] AAL1/2 transport over IP/MPLS networks

Bob/Maarten -

Excellent points.

All of which (I assume) support the idea that whichever way we go
(Vainshtein, Pate, Anavi, Davari, or some compromise between them), we
should just go that one way.  Otherwise, things are going to be a real mess.

Agreed?

-Tom

> From: Bob Barrett [mailto:[email-masked]]
> Sent: Thursday, September 05, 2002 8:24 AM
> To: [email-masked]; [email-masked]; [email-masked]
> Cc: [email-masked]; tom k. johnson; Yaron Raz
> Tim
> My view is that the complication sets in when the 'gusinta'
> interface at the
> PE facing the customer is not the same as the 'gusouta'
> interface at the PE
> facing the core e.g. T1 at the customer edge and T3 facing the core /
> switch. I guess you will be on-side with this view, but it
> does not bed down
> well with the other drafts.
>
> Aggregation in the context of PWE3 is an important issue, but
> is it within
> scope for PWE3? There are existing documents that define ATM and Sonet
> aggregation, so my view is that it does not need to be in
> scope for PWE3.
>
> There are two ways at looking at aggregation outside of PWE3:
>
> either:
>
> it happens at the edge, and then the resulting aggregated
> circuit is carried
> over the PSN (gusinta=gusouta)
>
> or:
>
> it happens at the other side of the PSN, with individual
> circuits being
> carried over the PSN.
>
> All other cases e.g. aggregation at a POP can be looked at as
> termination of
> the CES, and exit from the PSN at the POP, then aggregation logically
> outside of the PSN (using current ATM or Sonet methods, whatever the
> implementation and the application require), and then
> re-entry to the PSN of
> the aggregated circuit.
>
> We obviously want to avoid the need to go back to copper T1 and cable
> interconnects for aggregation. That is why I use the phrase 'logically
> outside of the PSN'. The aggregating systems can be an
> integrated box, with
> separate logical blocks of functionality based on _current_
> ATM and Sonet
> rfcs, silicon etc. It can even go all in one ASIC that
> supports multiple rfc
> protocols. Just because we want to integrate the silicon
> doesn't mean that
> the PWE3 standard needs to re-invent and re-write all the
> existing standards
> and functions that are required for the aggregation
> functions. That would
> not look like minimal intervention to me, and I think wedding
> PWE3 to ATM or
> Sonet legacy limits the future potential. I think PWE3 should
> be compatible
> with ATM and Sonet aggregation but PWE3 does not need to (and
> should not)
> re-define how ATM and Sonet aggregation work.
>
> Having read Maarten Vissers [[email-masked]] email on
> the issue of
> adequate monitoring, I would conceed that implementing a
> complete end to end
> OAM mechanism is simpler if the circuit stays within one ecapsulation
> protocol end to end.
>
> This is probably a re-run of the architectural discussion at
> the start of
> PWE3, but I get the feeling that the architectural picture has evolved
> considerably since the start a.k.a. creeping featurism.
>
> Best regards
>
> Bob
>
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> [email-masked]
> Sent: 05 September 2002 11:17
> To: [email-masked]
> Cc: [email-masked]; [email-masked]; tom k.
> johnson; Yaron
> Raz
> So how do we resolve the impasse?
>
> My suggestion would be to use the simplest solution that
> meets the basic
> requirements. Features such as inter-working with other services (e.g.
> SONET, ATM) can then be handled in an NSP if required. That
> way we don't
> force people who don't want these features to implement them in the
> system, since they will not be part of the basic PWE3 standard.
>
> This promotes maximum inter-operability and simplicity of the
> equipment..
> For instance it doesn't force people who want to
> inter-operate with SONET
> to do a double conversion to basic TDM and then into AAL1/2, or vice
> versa.
>
> Of course, this seems to nicely favour CESoPSN, of which I am
> a co-author
> - but this is why I am a co-author of that draft!
>
> The next question is: what are the basic requirements? This
> is what Max
> Riegel was trying to answer with his Requirement draft. Perhaps if we
> concentrated on this we would be able to come to a more
> objective opinion
> on which drafts actually meet the requirements.
>
> Regards,
> Tim
>
>
>
>
>
> "Yaron Raz" <[email-masked]>
> Sent by: [email-masked]
> 05-Sep-2002 09:26 AM
>
>
>         To:     "tom k. johnson" <[email-masked]>,
> <[email-masked]>, <[email-masked]>, <[email-masked]>
>         cc:
> I would like to back up Tom's view here.
> Even when we identify 3 different scenarios, a single CES
> equipment may be
> required to support more than one standard depending on the
> Interface type
> on the other end.
> For example: a T1 CES equipment may be required to support
> CESoPSN if the
> other side is also T1, SONET-VT if the other side is OC-3 and
> AAL1/2 if
> the other side is ATM based. Of course in many cases the
> customer wants to
> buy a T1 interface without specifying and commiting to the
> interface on
> the other side at the time he buys the equipment.
> Having a single device support all modes makes it complex and
> expensive.
>
> So, although we can justify each method by specific application it is
> optimized for, at the end of the day we are not promoting
> interoperability
> of CES, which is what we are here for.
>
>
> Sent: Friday, August 30, 2002 1:46 AM
> To: [email-masked]; [email-masked]; [email-masked]
> Bob -
> > I have no problem with three methods, as there are three
> > scenarios in the market.
>
> I agree that there are different scenarios in the market, but
> I'm not sure
> that three solutions to the same basic problem is warranted.
>
> However, there is no doubt that each of the proposed
> solutions shines best
> in certain applications.
>
> - vainshtein appears to be the most easily implementable with software
> (and a little bit of hardware), is optimized for native T1/E1
> emulation,
> and seems to be most in line with the PWE3 charter as I understand it.
>
> - anavi re-uses off the shelf AAL1/AAL2 specifications and technology
> which is useful in it's own right, and opens the door for service
> interworking between ATM circuit emulation and PWE3 circuit emulation.
>
> - pate is optimized for high capacity optical hand-offs, and
> utilizes the
> exact same encapsulation as the STS-1 and above circuit
> emulation draft.
>
> I just wonder if multiple application-optimized but non-interoperable
> protocols that accomplish the exact same function from an end-user
> perspective (i.e. carriage of a T1 circuit through a PSN) is
> the best path
> forward.  Perhaps the answer is yes, but I just wanted to pose the
> question.
>
> It seems to me that having one standard protocol for carrying T1s over
> PSNs has a lot of benefits, even if that protocol is not perfectly
> optimized for each deployment scenario.  But I'm certainly
> open to other
> views.
>
> Thanks!
>
> -Tom