Subject: Re: Proposed way to move forward re ATM/MPLS

From: Eric Rosen <[email-masked]>
Date: Tue, 30 Apr 2002 12:19:24 -0400

Some folks seem to think that: 

- what happens in  the real  world (as  indicated by  deployed multi-vendor
  interoperable implementations) should not be considered;

- but the unimplemented and  undeployed output of other standards committees
  is of crucial importance. 

However, I don't believe this is the ethos of the IETF.

---

From: Luca Martini <[email-masked]>
Date: Tue, 30 Apr 2002 16:36:02 -0600

Khalid,

Now that I can speak more freely, I would like to ask you and the PWE3 WG the 
following:

Is there a  requirement that ATM over MPLS transport be more bandwidth 
efficient then ATM itself ?

An ATM network is used ,to me ,  it makes a statement that efficiency is not a 
significant design requirement. In PWE3 we should design a working solution , 
and not strive to perfectly emulate, or improve, the transported protocol, in 
this case ATM.

In this context what is wrong with one encapsulation that accomplishes all this 
  at once ?
This would be the cell mode in the draft-martini-atm-encap-mpls-00.txt.

Having said that, I think that some of the encapsulation modes below have merit 
  because of current hardware implementation constraints.
I think that we should be able to come to an agreement for 2 modes: a cell 
mode, and a packet mode.
I see no use for any more permutations for this encapsulation.

I propose that we use the draft-martini-atm-encap-mpls-00.txt cell mode with 
optional concatenation of cells, and either the AAL5 SDU or PDU mode , but 
without fragmentation.
The OAM cell ordering issue is well covered by the cell transport mode.

If I offer service to my customers there is nothing that they can do in a 
network implementing any  draft-fisher modes that I cannot do with the martini 
cell encapsulation.

Thanks.
Luca

Khalid Ahmad wrote:

> Hi Luca and pwe3 colleagues,
> 
> sorry for delay in responding to your point, but I was in ATM Forum 
> meeting in beautiful Prague and just got back !
> 
> Yes Luca, people keep telling me there are many implementations of draft 
> martini encapsulations out there, but surely this is not the issue we 
> are trying to resolve here.
> 
> I think the issue is how do we reconcile the different approaches that 
> have been followed by different bodies and come up with a reasonable and 
> unified solution set that meets the different requirements and design 
> criteria that were adopted.
> 
> I think we all know that it is possible to get 3 or 4 (or more)vendors 
> to implement something they have written up in a draft and it will work 
> fine. These days anything will "work" if one throws enough silicon or 
> software at it.
> 
> But the question is whether this constitutes a generally agreed standard 
> or is an implementation agreement between the interested parties. I dont 
> believe we can make progress on this basis in pwe3, considering the 
> different proposals that are being discussed.
> 
> However, I think we can make progress based on the guidelines we started 
> to discuss in Minneapolis, by splitting up the whole ATM/MPLS 
> interworking problem into the the separate applications that underlie 
> the current proposals and use correct layering principles to design the 
> encapsulation protocols.
> 
> I assume correct layering means that functions pertaining to the "pseudo 
> wire" (interworking LSP) are grouped ahead of the functions belonging to 
> the service being transported, e.g. ATM service specific info such as 
> PTI, CLP, etc.
> 
> Based on these guidelines, I would like to propose the following 
> approach as a way of moving forward to resolve the various applications 
> being addressed in both drafts fischer and brayley, etc., and partition 
> the work for minimising overlaps:
> 
> 1.   For the cell mode interworking we can distinguish:
> 
> 1.1  Basic ATM VCC (or VPC)cell interworking application. 
> 
> This application addresses the basic mapping of VCC or VPC to the 
> interworking LSP (or PW in IETF terminology). Transparency and 
> efficiency are the main requirements here for the ATM service being 
> transported, so there is no need to carry redundant protocol control 
> info (PCI),such as VPI or VCI values, for this network application.
> 
> I propose this application can be met by the basic cell encap mechanism 
> described in the ATM Forums af-aic-0178 specification which was approved 
> last year, and is also described in drafts fischer and koleyni. This 
> mechanism strictly preserves layering principle and provides maximum 
> efficiency for single cell transfer.
> 
> Also backwards compatibility with this spec is preserved, an important 
> consideration if we want to achieve harmonization across all standards 
> bodies working on this topic.
> 
> 1.2  Port interworking application.
> 
> This application transports all ATM cells from one transmission path 
> payload (port) to another without identifying individual ATM VCCs or 
> VPCs in the multiplexed cell stream. Since there is no visibility of 
> individual VCC or VPC in this application this is not an ATM layer 
> service as defined in ITU-T I.series recommendations or ATM Forum 
> specifications.
> 
> However, the port interworking application enables extraction of ATM 
> idle cells from cell stream and hence some level of concentration into 
> an egress transmission path (port).  It may also enable potential for 
> additional level of multiplex, since VPI/VCI values are carried intact. 
> Efficiency is not a consideration in this application since no ATM layer 
> functions are involved.
> 
> I propose this application can be met by the basic encap mechanism 
> described in drafts martini or brayley, which includes the 
> VPI+VCI+PTI+CLP fields as is.
> 
> This also enables backwards compatibility with the existing martini 
> based implementations.
> 
> 2.   For the frame mode interworking we can distinguish the following:
> 
> 2.1  AAL Type 5 interworking
> 
> This application transports entire AAL5 frames (PDU) across the 
> interworking LSP while ensuring transparency of all ATM layer services, 
> such as end-end OAM functions, etc.  It also preserves both message and 
> streaming mode of operation for AAL Type 5 as described in ITU-T 
> recommendation I.363.5.
> 
> The basic rationale for AAL5 interworking is enhanced efficiency over 
> basic cell IW as in 1.1 above for those ATM  services that use AAL5 CPCS.
> 
> I propose this application can be best met by the PDU mode encapsulation 
> mechanism defined by af-aic-0178 spec, which is also described in drafts 
> fischer or brayley.
> 
> This also follows layering guidelines (at least in draft fischer) while 
> achieving backwards compatibility with other forums work.
> 
> 2.2  Frame mode interworking (or SDU mode IW).
> 
> This application supports only the transport of the AAL5 payload for 
> further efficiency and ease of service interworking, but is not 
> transparent to all ATM capabilities such as OAM functions or streaming 
> mode. Its main use could be to facilitate service IW with other payload 
> types such as ethernet or FR to enable any-to-any transport.
> 
> I propose this application can be met by the SDU mode encap mechanism as 
> described in drafts brayley or martini etc., but these may need to be 
> modified to ensure the layering principles are followed.  (Currently I 
> believe this encap places the ATM service specific PCI before the 
> pseudowire related functions such as sequence number and length).
> 
> If we can agree to this simple approach to partitioning the cell and 
> frame interworking applications we will need to work on 4 separate 
> drafts which will describe the application (AS part) and the related 
> encap mechanism optimised for that particular network application.
> 
> I understand Ghassem Koleyni has already submitted an AS draft for the 
> basic cell VCC mode as per 1.1 above, and is working on a PDU draft as 
> in 2.1.  Since much of the material for all the encap protocols is 
> already available in the various drafts, I dont think it will be 
> difficult to put together the 4 AS drafts based on the above.
> 
> I would like to know who would be interested in putting together AS 
> material for the port and SDU applications in collaboration.
> 
> I hope we can progress the ATM/MPLS work based on the above proposed 
> partitioning ?
> 
> Regards,
> Khalid
> 
> 
> 
> 
> 
> 
> -----Original Message-----
> From: Luca Martini [mailto:[email-masked]]
> Sent: Tuesday, April 23, 2002 6:37 PM
> To: Ahmad, Khalid [CAR:CS49:EXCH]
> Cc: [email-masked]; [email-masked]
> Subject: Re: [PWE3] Proposed changes to draft kamapabhava-01
> 
> 
> I would like to point out a little difference here.
> There are several interoperable independent implementations of the
> draft-martini encapsulations ( some of which are currently deployed ). 
> Can we
> say the same about all the other drafts ?
> 
> Luca
> 
> 
> Khalid Ahmad wrote:
> 
>  > Hi Danny,
>  >
>  > thank you for this clarification.
>  >
>  > In that case, I look forward to continued cooperation in the ATM/MPLS
>  > drafts.
>  >
>  > Regards,
>  > Khalid
>  >
>  > -----Original Message-----
>  > From: Danny McPherson [mailto:[email-masked]]
>  > Sent: Friday, April 19, 2002 11:49 AM
>  > To: [email-masked]
>  > Subject: Re: [PWE3] Proposed changes to draft kamapabhava-01
>  >
>  >
>  >
>  >  > Hi Danny,
>  >  >
>  >  > I assume that your point re backwards compatibility applies equally
>  > to all
>  >  > the pwe3 drafts, including the work we are currently doing for ATM
>  > over MPLS
>  >  > &IP.
>  >
>  > Yes Khalid, else we would have simply published the Martini drafts and
>  > been done with it.
>  >
>  > -danny
>  >
>  >
>  > _______________________________________________
>  > pwe3 mailing list
>  > [email-masked]
>  > https://www1.ietf.org/mailman/listinfo/pwe3
>  >
> 
> 
> -- 
> Just say no to summer. Ski all year !
> Luca Martini Senior Network Architect, Level 3 Communications - 
> Broomfield, CO
> [email-masked] | VE2WKR/W0 | Phone 720-888-1225 | pager 
> [email-masked]
> 

-- 
Just say no to summer. Ski all year !
Luca Martini Senior Network Architect, Level 3 Communications - Broomfield, CO
[email-masked] | VE2WKR/W0 | Phone 720-888-1225 | pager [email-masked]

---

From: Jim Harford <[email-masked]>
Date: Wed, 01 May 2002 01:03:49 -0400

Luca,
Where did you get the idea that "efficiency is not a significant design 
requirement" for ATM networks?  Consider that one of the major design goals 
of ATM was to be a transport for voice, video, and data.  Operating one 
transport network is much more efficient than operating multiple transport 
networks.  Also consider that the use of some ATM features (e.g. ABR) allow 
significantly higher line utilization than simply running IP over a 
wire.  I imagine you are going to complain about the "cell tax".  It is 
hard for me to take that argument seriously from a community that purposely 
chooses to use an encapsulation from RFC 1483 that causes a TCP 
acknowledgement to overflow a single ATM cell.  In the big picture, 
efficiency is an important design requirement for ATM.

What is curious to me is that some of the PWE3 members insist on using a 
common encapsulation format for very different applications.  The service 
providers that are interested in cell mode and AAL-5 PDU mode tend to be 
incumbent carriers that are using ATM to provide many different services to 
their customers, including leased lines and ATM connections with specific 
QoS requirements.  These incumbents care about transparency of ATM service 
and efficiency.  The service providers that are interested in port trunking 
mode and AAL-5 SDU mode tend to be newer service providers that will offer 
frame service presumed to carry IP traffic.  These alternate carriers don't 
have the burden of supporting all the attributes of ATM, but they want an 
efficient frame transport.

What is the problem with different encapsulations that are optimized for 
different applications?  The main reason I have heard here is that some 
vendors rushed to implement silicon before a standard was in place.  The 
ATM Forum's specification, af-aic-0178.00 was published over 7 months 
ago.  Do these vendors not have enough money in the current economy to 
re-spin their silicon, or are their chip engineers too slow with design 
changes?

Finally, if we take port trunking mode out of the discussion (because it 
has almost nothing to do with ATM), then I can counter your last sentence 
with the following claim:
"If I offer service to my customers there is nothing that they can do in a 
network implementing any martini cell encapsulation that I cannot do with 
draft-fisher modes."

If two competing proposals have the same feature set, doesn't it make sense 
to pick the most efficient one?

Jim Harford

At 04:36 PM 4/30/2002 -0600, Luca Martini wrote,

>Now that I can speak more freely, I would like to ask you and the PWE3 WG 
>the following:
>
>An ATM network is used ,to me ,  it makes a statement that efficiency is 
>not a significant design requirement. In PWE3 we should design a working 
>solution , and not strive to perfectly emulate, or improve, the 
>transported protocol, in this case ATM.
>
>In this context what is wrong with one encapsulation that accomplishes all 
>this  at once ?
>Having said that, I think that some of the encapsulation modes below have 
>merit  because of current hardware implementation constraints.
>I propose that we use the draft-martini-atm-encap-mpls-00.txt cell mode 
>with optional concatenation of cells, and either the AAL5 SDU or PDU mode 
>, but without fragmentation.
>network implementing any  draft-fisher modes that I cannot do with the 
>martini cell encapsulation.
>
>Thanks.
>Luca

---

From: Luca Martini <[email-masked]>
Date: Wed, 01 May 2002 09:22:00 -0600

Jim Harford wrote:

> requirement" for ATM networks?  Consider that one of the major design 
> goals of ATM was to be a transport for voice, video, and data.  
> Operating one transport network is much more efficient than operating 
> multiple transport networks.  Also consider that the use of some ATM 
> features (e.g. ABR) allow significantly higher line utilization than 

except that ABR never worked.

> simply running IP over a wire.  I imagine you are going to complain 
> about the "cell tax".  It is hard for me to take that argument seriously 
> from a community that purposely chooses to use an encapsulation from RFC 
> 1483 that causes a TCP acknowledgement to overflow a single ATM cell.  
> In the big picture, efficiency is an important design requirement for ATM.
> 

So what you are saing is that we should try to improve ATM efficiency ?

I agree that we should try to be as efficient as ATM native networks, but given 
the current bandwidth market I'm not sure that we need to improve on ATM 
efficiency.
Today , a significant part of the service cost is in the edge device. The 
bandwidth in the core is relatively cheap. For this service to be viable it has 
to be cheaper then a leased sonet line, otherwise there is no point to even go 
further.
One of my major design parameters is to be able to implement this protocol in 
as many devices as possible , and for the lowest cost possible. Hence, having 
many different encapsulations, to perfectly tune efficiency , is not as 
important as keeping development cost down.

> common encapsulation format for very different applications.  The 
> service providers that are interested in cell mode and AAL-5 PDU mode 
> tend to be incumbent carriers that are using ATM to provide many 
> different services to their customers, including leased lines and ATM 
> connections with specific QoS requirements.  These incumbents care about 
> transparency of ATM service and efficiency.  The service providers that 
> are interested in port trunking mode and AAL-5 SDU mode tend to be newer 
> service providers that will offer frame service presumed to carry IP 
> traffic.  These alternate carriers don't have the burden of supporting 
> all the attributes of ATM, but they want an efficient frame transport.
> 

no, they probably won't listen to the ATM forum. After all ATM is a legacy 
protocol.
This is an IP world.

> has almost nothing to do with ATM), then I can counter your last 
> sentence with the following claim:
> "If I offer service to my customers there is nothing that they can do in 
> a network implementing any martini cell encapsulation that I cannot do 
> with draft-fisher modes."
> 
> If two competing proposals have the same feature set, doesn't it make 
> sense to pick the most efficient one?
> 

So would you pay more for an efficient protocol , when the savings in bandwidth 
give you a marginal return ?

>> Now that I can speak more freely, I would like to ask you and the PWE3 
>> WG the following:
>>
>> An ATM network is used ,to me ,  it makes a statement that efficiency 
>> is not a significant design requirement. In PWE3 we should design a 
>> working solution , and not strive to perfectly emulate, or improve, 
>> the transported protocol, in this case ATM.
>>
>> In this context what is wrong with one encapsulation that accomplishes 
>> all this  at once ?
>> Having said that, I think that some of the encapsulation modes below 
>> have merit  because of current hardware implementation constraints.
>> I think that we should be able to come to an agreement for 2 modes: a 
>> cell mode, and a packet mode.
>> I propose that we use the draft-martini-atm-encap-mpls-00.txt cell 
>> mode with optional concatenation of cells, and either the AAL5 SDU or 
>> PDU mode , but without fragmentation.
>> If I offer service to my customers there is nothing that they can do 
>> in a network implementing any  draft-fisher modes that I cannot do 
>> with the martini cell encapsulation.
>>
>> Thanks.
>> Luca
> 
>

---

From: Eric Rosen <[email-masked]>
Date: Wed, 01 May 2002 12:12:04 -0400

Jim> I imagine you  are going to complain about the "cell  tax".  It is hard
Jim> for me to take that  argument seriously from a community that purposely
Jim> chooses  to  use an  encapsulation  from RFC  1483  that  causes a  TCP
Jim> acknowledgement to overflow a single ATM cell. 

Some would  say that  it is  difficult to take  seriously a  community which
designed cells that are too small to hold a properly encapsulated TCP ack. 

Jim> Consider  that one  of  the  major design  goals  of ATM  was  to be  a
Jim> transport for voice, video, and data. 

Yeah, but I knew there was trouble  back in 1995 when I started to hear from
voice guys that ATM was optimized for  data, and from data guys that ATM was
optimized for voice ;-)

Jim> Also  consider that  the  use of  some  ATM features  (e.g. ABR)  allow
Jim> significantly  higher line utilization  than simply  running IP  over a
Jim> wire

I believe that ABR is generally  regarded as, shall we say, not having lived
up to expectations.

Jim> What is  the problem with  different encapsulations that  are optimized
Jim> for different applications? 

Nothing, but it's  always worth considering whether the  extra optimality is
really worth the extra complexity.   And once something is already deployed,
adding additional variations that  don't provide significant new value isn't
usually worthwhile. 

Jim> The  ATM Forum's  specification,  af-aic-0178.00 was  published over  7
Jim> months ago. 

I guess  not enough vendors and  customers care, since that  doesn't seem to
have made much of an impact on the industry.

---

From: Jim Harford <[email-masked]>
Date: Thu, 02 May 2002 15:19:39 -0400

Luca,
Please see my comments interspersed below:

>except that ABR never worked.

Please see my note to Eric Rosen.  The market failure of ABR has nothing to 
do with the intention of ATM protocol designers to be efficient.

>>simply running IP over a wire.  I imagine you are going to complain about 
>>the "cell tax".  It is hard for me to take that argument seriously from a 
>>community that purposely chooses to use an encapsulation from RFC 1483 
>>that causes a TCP acknowledgement to overflow a single ATM cell.
>I agree that we should try to be as efficient as ATM native networks, but 
>given the current bandwidth market I'm not sure that we need to improve on 
>ATM efficiency.
>bandwidth in the core is relatively cheap. For this service to be viable 
>it has to be cheaper then a leased sonet line, otherwise there is no point 
>to even go further.
>One of my major design parameters is to be able to implement this protocol 
>in as many devices as possible , and for the lowest cost possible. Hence, 
>having many different encapsulations, to perfectly tune efficiency , is 
>not as important as keeping development cost down.

I have seen various studies concluding that the capitol expense of network 
elements is small compared to the recurring costs of bandwidth.  The 
vendors' development cost is even further removed from expenses that a 
carrier sees.  I think you are trying to optimize the wrong end of the 
problem.  BTW, what aspect of the ATM Forum's cell mode precludes 
implementation on a platform that can support Martini's cell mode?

>>incumbent carriers that are using ATM to provide many different services 
>>to their customers, including leased lines and ATM connections with 
>>specific QoS requirements.  These incumbents care about transparency of 
>>ATM service and efficiency.  The service providers that are interested in 
>>port trunking mode and AAL-5 SDU mode tend to be newer service providers 
>>that will offer frame service presumed to carry IP traffic.  These 
>>alternate carriers don't have the burden of supporting all the attributes 
>>of ATM, but they want an efficient frame transport.

Actually, if I use revenue as the metric, this is a voice world.  After 
that, it's a leased line world.  We have major carriers that come to the 
ATM Forum to evolve the protocols that carry the traffic that keeps them in 
business.  Is it your position that IETF participants are content to ignore 
the market opportunity and requirements of incumbent carriers?

>So would you pay more for an efficient protocol , when the savings in 
>bandwidth give you a marginal return ?

Does one protocol cost more than the other?  How would we determine 
this?  Do you want to start counting gates?

Jim Harford

>>>with optional concatenation of cells, and either the AAL5 SDU or PDU 
>>>mode , but without fragmentation.
>>>If I offer service to my customers there is nothing that they can do in 
>>>a network implementing any  draft-fisher modes that I cannot do with the

---

From: Jim Harford <[email-masked]>
Date: Thu, 02 May 2002 13:43:50 -0400

Eric,

>designed cells that are too small to hold a properly encapsulated TCP ack.

I'm not sure there is agreement on what constitutes "properly 
encapsulated".  In fact, a TCP ack does fit inside a single ATM cell when 
VC-based multiplexing for routed frames is used (section 5.1 of RFC 
1483).  My point was that many in the IP community instead prefer the 
LLC/SNAP encapsulation of 1483 to carry an unneeded protocol ID specifying 
that the payload is IP.  The additional LLC/SNAP header breaks the budget 
of a single ATM cell for the TCP ack.

>voice guys that ATM was optimized for  data, and from data guys that ATM was

ATM is not optimized for either data or voice.  ATM provides base transport 
functionality to support diverse service requirements.  AAL-5 adapts ATM's 
offered service to meet data requirements.  AAL-1 and AAL-2 adapt ATM's 
offered service to meet voice requirements.

>I believe that ABR is generally  regarded as, shall we say, not having lived

ABR's strength was that it provided end-to-end flow control with much 
faster feedback than TCP's sliding window.  ABR was never widely deployed 
because ATM failed to gain market traction as an end-to-end 
protocol.  However, my point was that one of the motivating factors behind 
the design of ABR was efficient use of links.  The ATM community is very 
concerned about efficiency.  The market failure of ABR has nothing to do 
with the goal of efficiency within the ATM community.

>adding additional variations that  don't provide significant new value isn't

Your premise is that Martini is already deployed and af-aic-0178.00 is 
not.  I am not sure if that is fact.  Even if we were to agree on that 
premise, it makes no sense to standardize Martini for cell mode (and AAL-5 
PDU mode) if the ATM Forum's version is better and does not impose an 
unreasonable burden to implement.

But there is a more fundamental question to ask the Martini draft authors: 
are you willing to make **any** changes?  Most standards bodies make 
modifications to input submitted by members.  They do this because the 
original authors don't have a monopoly on good ideas and the process of 
compromise makes the specification acceptable to more parties.  It seems 
that some of the Martini advocates are so far into the development cycle 
that compromise is impossible.  In this case, the only value-add of the 
IETF standards track is an RFC number.

Is this what the PWE3 group has devolved to?  Are we simply a rubber stamp 
to obtain RFC numbers?

>have made much of an impact on the industry.

And how do we determine what constitutes "enough vendors and customers"?  I 
know of at least two major equipment vendors that are building equipment 
conforming to af-aic-0178.00.  I know of several major carriers that have 
expressed much interest in af-aic-0178.00.

What is your metric to gauge "impact on the industry"?  I can tell you that 
I receive lots of requests to speak at MPLS conferences because someone out 
there cares what the ATM Forum is doing in this area.

Jim Harford

---

From: Eric Rosen <[email-masked]>
Date: Thu, 02 May 2002 15:51:52 -0400

Jim> In fact,  a TCP  ack does fit  inside a  single ATM cell  when VC-based
Jim> multiplexing for routed frames is used (section 5.1 of RFC 1483) 

VC-based multiplexing is  not generally used because it  requires extra VCs,
which is a management/provisioning cost,  a complexity cost (if multiple VCs
have to  be used to constitute  a single routing adjacency),  and a monetary
cost (if SPs  charge by the VC).  In practice, there's  little choice but to
go with the LLC/SNAP encapsulation, the VC-based multiplexing isn't really a
practical alternative.  It's too bad the  cell size was not chosen with more
of a focus on how ATM might be used to carry TCP/IP. 

But of course this history makes no difference in the present situation.

---

From: Jim Harford <[email-masked]>
Date: Thu, 02 May 2002 16:10:04 -0400

Eric,
How does VC-based multiplexing require extra VCs if the only layer 3 
protocol being widely used is IP?

Jim Harford

---

From: Luca Martini <[email-masked]>
Date: Thu, 02 May 2002 17:57:28 -0600

> premise, it makes no sense to standardize Martini for cell mode (and 
> AAL-5 PDU mode) if the ATM Forum's version is better and does not impose 
> an unreasonable burden to implement.
> 
> But there is a more fundamental question to ask the Martini draft 
> authors: are you willing to make **any** changes?  Most standards bodies 
> make modifications to input submitted by members.  They do this because 
> the original authors don't have a monopoly on good ideas and the process 
> of compromise makes the specification acceptable to more parties.  It 
> seems that some of the Martini advocates are so far into the development 
> cycle that compromise is impossible.  In this case, the only value-add 
> of the IETF standards track is an RFC number.
> 
> Is this what the PWE3 group has devolved to?  Are we simply a rubber 
> stamp to obtain RFC numbers?
> 

no, but I would classify improvement as in the Frame-Relay header bits being 
encapsulated in the right order, or a new mode of operation for ATM to reduce 
implementation complexity, or enable a new application.

The issue I see here is that VC , and VP modes are quite efficient using cell 
concatenation, and a single encapsulation saves significant development cost.
( Of course SPs care , but some vendors would like the protocol to be different 
so they can catch up in their development cycle ).

In level3's network we have  on average 12 bytes of overhead , and if we 
concatenate 12 cells , we are as efficient as ATM in the first place. I plan to 
concatenate 100 cells, that would make it much more efficient.

It might come down to the fact that requirements are different between IETF and 
other bodies , and we need different standards. Then I wonder which one will be 
prevalent. >:)

Luca

---

From: Jim Harford <[email-masked]>
Date: Thu, 02 May 2002 22:42:37 -0400

Luca,
There is a desire within the industry for one standard.  I agree with you 
that if different standards bodies have different requirements, then the 
result may well be different solutions.  The key task right now is to get 
agreement on the applicability statements for the different 
applications.  Then we can analyze the amount of overlap in requirements 
with the ATM Forum's work.

There is a decent chance we will wind up with multiple encapsulations 
across the industry.  So I have a question for you as a service 
provider.  If vendor A and vendor B approach you with boxes that have the 
same price tag and are identical in every respect, except vendor A supports 
only Martini and vendor B supports both Martini & the ATM Forum's 
encapsulation.  Which one will you pick?  The answer is easy: you pick 
vendor B because it is more flexible and you reduce the risk of making the 
wrong decision on the encapsulation protocol.  Competition will force most 
vendors to implement multiple encapsulation formats.  Thus, your efforts at 
reducing the vendors' development costs can't succeed.

My own personal example:  the ADSL drivers my company develops support 8 
different encapsulation formats, all from the IETF.

Jim Harford

At 05:57 PM 5/2/2002 -0600, Luca Martini wrote:

>>cycle that compromise is impossible.  In this case, the only value-add of 
>>the IETF standards track is an RFC number.
>no, but I would classify improvement as in the Frame-Relay header bits 
>being encapsulated in the right order, or a new mode of operation for ATM 
>to reduce implementation complexity, or enable a new application.
>
>The issue I see here is that VC , and VP modes are quite efficient using 
>cell concatenation, and a single encapsulation saves significant 
>development cost.
>( Of course SPs care , but some vendors would like the protocol to be 
>different so they can catch up in their development cycle ).
>
>concatenate 12 cells , we are as efficient as ATM in the first place. I 
>plan to concatenate 100 cells, that would make it much more efficient.
>
>It might come down to the fact that requirements are different between 
>IETF and other bodies , and we need different standards. Then I wonder 
>which one will be prevalent. >:)
>
>Luca
>
>
>
>

---

From: Giles Heron <[email-masked]>
Date: 03 May 2002 11:14:07 +0000

> At 09:22 AM 5/1/2002 -0600, Luca Martini wrote:
[snip]
> implementation on a platform that can support Martini's cell mode?
[rest snipped]

how recent were these studies?

at the bandwidth prices I see in the market today I'm not so sure this
is true (in fact I am pretty sure that is isn't...)

Giles

-- 
=================================================================
Giles Heron    Principal Network Architect    PacketExchange Ltd.
ph: +44 7880 506185              "if you build it they will yawn"
=================================================================

---

From: Jim Harford <[email-masked]>
Date: Fri, 03 May 2002 08:00:20 -0400

Giles,
I saw the studies about a year ago.  I was helping a startup equipment 
vendor put together a business plan for investors.  We were looking at 
operational costs for CLECs and ISPs.  The conclusion was that the 
recurring bandwidth and other operational expenses were so great, that this 
proposed business had lots of room to charge big bucks for their box and 
make healthy margins.  Sorry, but I can't remember the source and I no 
longer have access to the material.

Jim Harford

---

From: Giles Heron <[email-masked]>
Date: 03 May 2002 14:25:23 +0000

Hi Jim,

> longer have access to the material.

I can well believe that if the studies were a year or more ago that they
might have reached that conclusion.

Since then bandwidth prices have been in freefall...

Also bear in mind that many SP backbones are heavily underused today. 
So in adding new services using new edge boxes there may well be no
bandwidth expense until the service takes off (at which point there will
presumably be revenue to pay for any additional bandwidth).  In today's
capital-constrained environment the cost of the edge boxes is likely to
be the major factor in determining whether new services are launched at
all :(

Again, this is one of the benefits of SDU mode - many existing boxes
will be able to support it with existing line-cards...

Giles