Subject: re: Proposed way to move forward for ATM/MPLS in pwe3

From: "Khalid Ahmad" <[email-masked]>
Date: Mon, 27 May 2002 10:54:39 -0400

Hi pwe3 Colleagues,

Its been a while now since any further discussion on this topic occurred so
it would be of value to see if we have made progress as a result of the last
round of emails that resulted from my initial proposal (of April 30). So I
try to summarize the main points of the discussion and see how this may
modify the initial 4 point proposal I made based on the guidelines given to
us by WG chairs and ADs in the Minneapolis meeting.

1. A significant point that resulted in a lot of discussion was the need for
transport efficiency. It seems there were two distinct   perspectives as
regards efficiency. Some people believe efficiency is an important
requirement for their network applications. Others argued efficiency need
not be a determining factor in view of declining bandwidth costs etc.
  
The debate around efficiency delineate two distinct network applications for
ATM/MPLS interworking for the cell mode:

   a) An "efficient" encap mechanism that transfers the minimum amount of
protocol information necessary to ensure
      transparency of the service.

   b) A general encap mechanism that enables either single or multiplexed
cell transfer (as well as port mode which may be 
      viewed  as special case of multiplexed (i.e. many-to-one)
encapsulation).

2. There was also some discussion around applications which require the need
for AAL 5 PDU as well as SDU frame modes, although here the underlying
issues seemed somewhat unclear. Some people did not see the need for both
PDU and SDU modes, but others argued that these addressed different
applications in respect to the transparency of service requirement 
and therefore both options should be available to service providers.

3. The issue of relative implementation complexity was touched on in respect
to the various options above. Since the differences between the
encapsulation formats are relatively minor, most people felt the complexity
would be negligible in relation to the complexity of implementing overall
interworking functionality required in control and management planes.

In effect, from implementation perspective, case a) may be viewed as a
subset of case b) above, and SDU mode as a subset of the PDU format case.
Consequently, both options for cell and frame modes can be accomodated
readily.

4. The email exchanges seemed to provide opportunities for some colleagues
to vent their spleen on ATM in general, with some dark mutterings about
"other" standard bodies conspiring to subvert the IETF process!   While no
doubt entertaining, these issues seem somewhat orthogonal to the central
technical issues we are trying to solve here, so this hardly needs to be
considered further.

5. A significant point regarding the architecture implications of the OAM
interworking between ATM and MPLS was raised(by Neil Harrison of course),
but this has so far not been addressed in any detail in pwe3, although some
discussion has been initiated in the ITU-T on this point. In general I would
agree with Neil that the requirements for OAM interworking resulting from
correct application of architecture principles should be factored in our
solutions, but this needs further discussion. However, at this stage I am
not sure this will necessarily impact the encap mechanism being considered,
but may affect the applicability 
statements.

To conclude, the email discussions indicated that there are various
applications being considered for ATM/MPLS network interworking which result
in distinct requirements for each. The various solutions proposed to date
meet these requirements based on the simple classification identified
earlier, namely:

    1) A general cell encap mechanism for multiplex cell or port mode, such
as described in drafts martini or brayley, for applications that to not
require optimum efficiency or those for port based service (as distinct from
ATM Layer based services).

    2) An efficient (or basic) encap mechanism for applications requiring
this capability, coupled with maximum transparency for ATM Layer based
services, such as described in drafts fischer or in the recent AS draft
submitted by Ghassem Koleyni.

    3) For AAL 5 frame mode both PDU and SDU based encapsulations address
different requirements. Here it is not so much an issue of efficiency as
service transparency if frame mode is used. Also there is no essential
conflict in encapsulation mechanisms since PDU encap format is the same in
drafts brayley and fischer, whereas SDU is essentially defined in draft
brayley or martini. Consequently both options can be accomodated to satisfy
these requirements.

The applicability statement draft for the AAL 5 PDU mode has been submitted
by Matthew Bocci recently and would meet these requirements.

One issue that did not elicit much discussion concerns the layering
guidelines as described in draft bryant, which we were encouraged to follow.
Correct layering needs to be factored into the encapsulation mechanisms
being considered, and would impact the SDU mode encap proposal, which
currently violates ordered layering of protocol control infomation.

There has been extensive and useful technical discussion of many aspects of
ATM/MPLS network interworking in the past months and I believe we now have
sufficient material in pwe3 to move forward, assuming people want to. The
guidelines specifying the applicability statements and layering of protocols
agreed in Minneapolis provide the means to do this on a reasonable basis.

The applications I outline above appear to be the basic set emerging from
the discussion, so I propose we move forward using them in conjunction with
the solutions indicated. So far two of the AS drafts have already been
submitted by Matthew and Ghassem, and I understand Luca is in the process of
preparing the other two. This should provide us with the necessary documents
to arrive at a common solution set.

I propose we adopt this approach as a way to move forward at this stage.  A
good first step would be to adopt the AS drafts which have been sent as
working group drafts so that the discussion can converge rapidly.  Danny,
how do we make this happen ?

Regards,

Khalid

---

From: Danny McPherson <[email-masked]>
Date: Tue, 28 May 2002 09:10:19 -0600

> not be a determining factor in view of declining bandwidth costs etc.

I think it was more so that efficiency was indeed considerable, 
but associated efficiency complexity must be factored as well.

> and therefore both options should be available to service providers.

Hence the [continued] chair/AD requirements for individual mode 
drafts that contain associated applicability statements.   

> interworking functionality required in control and management planes.

I'm not sure I saw consensus either way on this.

> technical issues we are trying to solve here, so this hardly needs to be

Then disregard it and let's continue with the tasks at hand...

> but may affect the applicability statements.

If you feel it's relative to PWE3 submit I-Ds, we'll continue discussions
from there.

>     1) 
>     2) 
>     3) 

An updated version is to be submitted as a WG document.  We can discuss
and revise as necessary.

> agreed in Minneapolis provide the means to do this on a reasonable basis.

And we're still awaiting many of them...

> how do we make this happen ?

As suggested already, the AS notes should accompany the individual modes
with which there associated.  Once this occurs, the individual authors 
should request that the ID be adopted by the WG AND become a WG item.
If there are no _substantial objections, so shall it be!  :-)

-danny

---

From: "Rutemiller, John" <[email-masked]>
Date: Tue, 28 May 2002 11:53:49 -0400

Khalid,

The way to move forward is to simplify. Not to expand.

I've been looking at PDU mode and trying to figure out if there
is an easier way to provide the same functionality. What I've
come up with (thanks to input from others) follows at the end of
this message.

There are some important characteristics to note with what I
propose compared to PDU mode:

1) It is a variation of Cell Mode
2) Works for all AAL types (not AAL5 specific)
   - When a frame is sent can be triggered by max_delay (any AAL)
     or by max_MTU (for AAL5 if desired), or by the PTI bit value
3) The arrival of an ATM cell causes the transmission of at
   most one frame
   - Admin/OAM cells are sent as the last cell of a frame
   - PDU mode will send two frames in response to the arrival
     of an admin/OAM cell
4) Transmission is at least as efficient as PDU mode
5) Like PDU mode, is not transparent to user cell EFCI and CLP

As a way to move forward, I would like to replace PDU mode with
what I propose. It is simpler than PDU mode, provides equivalent
functionality and is not AAL specific.

John

-----------------------------------------------------------------

==> Procedures at the Ingress Side

The procedures for processing arriving cells preserves the value of the ATM
user-to-user bit located in PTI bit position 3 and all PTI bits for
administrative cells. Processing is based on the following rules:

1)	All cells, except the last cell of a frame, MUST be a user cell with
the PTI bit value PTI=0x0.

2)	The last cell in a frame may be either a user cell with any PTI
value (PTI=0xx), or an administrative cell (PTI=1xx).

3)	Administrative cells MUST be transmitted only as the last cell in a
frame.

4)	User cells with PTI=0x1 MUST be transmitted only as the last cell in
a frame.

The pseudo code for processing an arriving cell is as follows:

If starting a new frame
		Initialize the A-PTI/C and U-PTI/C fields to zero

Append arriving cell payload to frame buffer

If PTI=0xx then
	U-PTI = arriving-PTI
		U-CLP = U-CLP | arriving-CLP
Else If PTI=1xx then
	A-PTI = arriving-PTI
		A-CLP = arriving-CLP
Endif

If PTI != 0x0 or (FrameSize => MaxFrameSsize)
		Send Frame
	Endif

The value of the user cell EFCI is always the value of the last arriving
cell.

The value of the user cell UU bit is always set to zero when the PTI=0x0. If
the PTI=0x1, the UU bit is set to one and the frame will be sent. Only the
last cell in a frame can set the PTI=0x1 value.

The value of the admin cell PTI bits are always preserved separately and the
frame is always sent immediately after appending the admin cell payload.

==> Procedures at the Egress Side

The procedures for processing arriving frames generates ATM cells from using
the PTI/CLP values carried in the first byte of the frame.

The pseudo code for processing an arriving frame is as follows:

While (not last cell payload)
		PTI = U-PTI & 010
		CLP = U-CLP
		Prepend VPI/VCI
		Send cell
	End

	If A-PTI/CLP != 0000 then
		PTI = U-PTI
		CLP = U-CLP
		Prepend VPI/VCI
		Send cell
	Else
		PTI = A-PTI
		CLP = A-CLP
		Prepend VPI/VCI
		Send cell
	Endif

---

From: [email-masked]
Date: Thu, 30 May 2002 10:43:52 +0100

John,

Of all the ATMoverMPLS encapsulation variations I have seen to date yours
(ie the one you recently submitted to ATMF) is by far the clearest/best IMO.
However, it is not sufficient just to carry the client layer (in this case
ATM) fault management information transparently in a failure-free case, we
must have correct defect handling behaviour under dynamic failure
conditions...and this area has still to be addressed correctly in all the
drafts (though I do recognise that you at least are aware of this).

regards, Neil

> -----Original Message-----
> From: Rutemiller, John [mailto:[email-masked]]
> Sent: 28 May 2002 16:54
> To: [email-masked]
> Subject: RE: [PWE3] re: Proposed way to move forward for ATM/MPLS in
> pwe3
> 
> 
> Khalid,
> 
> _______________________________________________
> pwe3 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/pwe3
>

---

From: [email-masked]
Date: Thu, 30 May 2002 10:43:50 +0100

Danny,  please see 1 remark below.  regards, Neil

Danny McPherson wrote 28 May 2002 16:10

<snipped>
> If you feel it's relative to PWE3 submit I-Ds, we'll continue 
NH=> If we are going to carry trails of various technologies over some
server layer technology (like MPLS) then we simply have to ensure correct
dynamic defect handling behaviour.  This is not something that is 'optional'
for consideration, it's essential.  So far the authors of all the drafts
have not got this aspect sorted, and I have already pointed out that some of
the expedient ideas to address this in specific cases (like ATMoverMPLS in
port-mode) are seriously flawed.  One key reason they can't sort it for MPLS
is that it has a pre-cursor requirment that MPLS has its own automatic
defect detection/handling and so far IETF have no solutions for this.
Having got no traction in IETF on this topic after trying for over a year,
and noting ITU/SG13 do have a work item on this topic, those who have
concerns in this rea like myself have tried to get solutions in place in
ITU.....see Y.1710 (requirements) and Y.1711 (mechanisms).  We are going to
need something like these if PWE3 work on XoverMPLS is going to be treated
seriously by the larger operator community IMO.  Currently I see this area
as a major hole in this work that is not 'optional' for consideration.....it
simply has to be addressed.

---

From: [email-masked]
Date: Fri, 31 May 2002 10:30:22 +0100

Lloyd,
You wrote 30 May 2002 16:48
> > dynamic defect handling behaviour.
> 
> I'd be more comfortable with your assertions if I understood their
> ramifications.
NH=>Simple.....My operational people need networks that make their life
easier by automated fault-handling and they don't wants alarms being raised
at every layer trail termination across multiple networks.  My management
wants to drive down opex costs by automated fault handling.  My customers
want better service by automatic fault handling (its not very good when they
ring up and tell you your network is broken).  Does that help you
understand?

> To do that, I first need to be sure I understand the
> terminology...
> 
> have I got the following ietfspeak translations right?
> client layer => transported payload
NH=> sort of.....as long as one recognises there is no such thing as *the*
network layer (there are loads of them).  The ISO 7-layer model does not
refect reality by a long way....but surely you know that I assume?

> server layer technology => network
NH=> No. This is a reference to a network based specific technology like IP,
ATM or SDH as three fines examples of cnls, co pkt-sw and co cct-sw networks
respectively. They sure exist and they are all important.  And they are all
networks.

> trail => soft flow state pertaining to a packet path for 
> management etc.
NH=> I personally don't like the word trail....but there are limited number
of appropriate words for path/connection/etc.  A trail is defined more
precisely in G.805 but in essence it is the entity that is managed (as you
rightly deduce) in co technologies.  It has no meaning in cnls technologies
like IP.  It has a fixed source/sink, between which relatively addressed
pkts/ccts (like labelled LSPs) are directed/switched along a given/chosen
route.  Such frames/pkts have no meaning outside their parent trail (I
think/hope obvious).  It has specific overhead/payload areas and the trail
entity itself carries semantics relating to survivability....the pkts only
carry QoS semantics (this is a key observation).  Various functions are
expected from the overhead....such as the checking of trail integrity, eg
that source X is correctly terminated on sink Y and that there are no errors
on the trails transport frames/pkts.  All obvious/important stuff if you are
trying to run/maintain a network.

> defect => any change in the network whatsoever.
NH=> No.  A (data-plane) defect is failure to behave as normally expected
and affects traffic.  Defects are specified (like in Y.1711 for MPLS) in
terms of entry/exit criteria and consequent actions.  If a defect persists
from longer than a specified period than the trail becomes unavailable.
Availability is a metric of fundamental importnance for both operators and
customers as it is usually the key metric in SLAs....further, since QoS
metrics are only meaningful (in SLAs) when the trail is in the available
state it is clearly important to be able to first identify
available/unavailable state changes.  

> defect handling => telling anybody who might care about the change.
NH=> Defect handling is all about taking the correct consequent actions on
failures.  This is clearly dependent on the generic type of network
considered (ie cnls vs co pkt-sw vs co cct-sw) but some general
considerations are:
-	do I have information on what-and-where the defect is?
-	do I apply an alarm here or not?
-	have higher level alarms (ie in any clinet layers) been suppressed?
-	should I suppress traffic if they is a potential customer traffic
integrity compromise?
-	at what point do I consider the trail (if co) unavailable?
-	at what point is prot-sw relevant (if this capabilty is available)?
-	when do I need to suppress any QoS metric aggregation?
-	have I broken customer SLAs?
-	does anyone need to tell the customers affected at this point that
their service is down?
-	what is the impact on billing at this point?
-	etc
We care about all this stuff a great deal.
> 
> all I know about Y.1710 I got from reading comments on it at
> http://nbvpn.francetelecom.com/Archives/200205/msg01336.html
> and that claims a service layer technology is layer 2 and that MPLS
> isn't a service technology, which is presumably distinct from a
> server technology...
NH=> Well why not read Y.1710 yourself and form your own view?  However,
even George Swallow said this about Y.1710 :
"1710 is a reasonable document.  Mostly great stuff that any vendor
wanting to sell to carriers should take very seriously.  As do I."
(George Swallow to CCAMPs list 6 March 2002)

> 
> thanks,
> 
> L.
> 
> "in general defining OAM prior to the standardization of a
>  service appears to be the wrong order of doing things"
NH=> I don't agree with this.  One should not fault-manage a network for a
specific service/application.  Networks needs to support multiple
applications/services, some of which may not even have been envisaged yet.
So fault-management of a network is an instrinsic function of the network
and is not simply dedicated to just 1 application/service.  Further, any
stds body that releases networking stds for which fault management had not
been considered is acting irresponsibly IMO.
<snipped to end NH>

---

From: "Khalid Ahmad" <[email-masked]>
Date: Fri, 31 May 2002 16:11:07 -0400

Hi Danny,

thanks for your comments, I sense we are in general agreement as to the main
aspects to move forward. As you indicate in your last para, I hope now the
authors of the various AS drafts already submitted, or in preparation, will
propose to submit these as wg drafts so we can try to converge on the
specific discussion points.

As to your comment re the complexity issue, I am not sure we can ever get
concensus on it since it seems to me this is more of a subjective assesment
of what constitutes complexity rather than any well defined and clear cut
objective analysis. 

In any case, in my view this is not really a sticking point, since we are
talking different applications. My understanding is the technology can well
handle this.

I would rather we find the political will to progress the work, than get
hung up on whether it takes 10 gates or 20 to do something, if you know what
I mean.

Regards,
Khalid

-----Original Message-----
From: Danny McPherson [mailto:[email-masked]]
Sent: Tuesday, May 28, 2002 11:10 AM
To: [email-masked]
Subject: [PWE3] Re: Proposed way to move forward for ATM/MPLS in pwe3

-danny

---

From: "Khalid Ahmad" <[email-masked]>
Date: Fri, 31 May 2002 16:48:26 -0400

Hi John,

yes I am trying to simplify, not expand, despite appearances to the
contrary.

I am not so sure whether your proposal is "simpler" than PDU mode or not,
but it sure is different, and so seems to introduce a new mode, which as you
put it, is a variation of cell mode.  

In any case, people always told me AAL5 reassembly is "simple", it used to
be called "SEAL" remember, for Simple and Effective Adaptation Layer.  (I
was there when all the big fights happened,AAL3 vs SEAL, how that dates me
!)

I thought the point about the frame mode application (whether PDU or SDU)
was that AAL5 reassembly was a given, and the "service" essentially
constituted the transfer of that frame over the pw (or interworking LSP).
Otherwise we an do everything in cell mode anyway.

Its not that I am averse to considering your proposal as well, but perhaps
we need to be first clear what then is the reason for SDU and PDU
applications in this context.

Regards,
Khalid

P.S. I am going to take some much needed vacation over the next couple of
weeks, so if my responses are a bit sparse, please bear with me. 

-----Original Message-----
From: Rutemiller, John [mailto:[email-masked]]
Sent: Tuesday, May 28, 2002 11:54 AM
To: [email-masked]
Subject: RE: [PWE3] re: Proposed way to move forward for ATM/MPLS in
pwe3

Khalid,

John

If starting a new frame

If PTI=0xx then
	U-PTI = arriving-PTI

---

From: [email-masked]
Date: Sat, 1 Jun 2002 01:28:04 +0100

Khalid Ahmad wrote 31 May 2002 21:48
<snip>
I am not so sure whether your proposal is "simpler" than PDU mode or not,
but it sure is different, and so seems to introduce a new mode, which as you
put it, is a variation of cell mode.
NH=> Not sure how closely you have looked at what John proposed Khalid.  I
have looked carefully at all the various encaps drafts and John's is by far
the best IMO.  Not only does it treat the varying encaps modes in a logical
and easy to follow (in increasing compression-ordering) manner, but its got
a smart way of avoiding fragmentation by using a form of suspend/resume that
triggers frame-sending on an incoming ATM OAM/RM cell when in frame-mode.
I'd like to think people will consider it seriously for adoption.
regards Neil
<snipped to end NH>

---

From: "Andrew G. Malis" <[email-masked]>
Date: Sat, 01 Jun 2002 07:06:20 -0400

Neil,

I also like it very much.  It's also a nice example of "thinking out of the 
box" (to use an over-used phrase) to come up with an innovative and 
straightforward solution to the problem.

Cheers,
Andy

-------

---

From: [email-masked]
Date: Mon, 3 Jun 2002 09:05:54 +0100

Thanks Andy....

John, why not post a draft of your work in PWE3?  Clearly both Andy/I
recognise it's merit.

regartds, Neil

> From: Andrew G. Malis [mailto:[email-masked]]
> Sent: 01 June 2002 12:06
> To: [email-masked]
> Cc: [email-masked]; [email-masked]; 
> [email-masked]