Subject: I-D ACTION:draft-rutemiller-pwe3-atm-encaps-00.txt

From: [email-masked]
Date: Tue, 25 Jun 2002 07:02:39 -0400

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title		: PWE3: ATM Cell Encapsulation
	Author(s)	: J. Rutemiller et al.
	Filename	: draft-rutemiller-pwe3-atm-encaps-00.txt
	Pages		: 38
	Date		: 24-Jun-02
	
This draft defines the encapsulation formats and procedures for 
transporting ATM connections over a packet switched network (PSN) or 
packet based interface. This specification supports four levels of 
transport: 1) Transparent cell, 2) Virtual Path, 3) Virtual Channel, 
and 4) AAL5 Payload. Header compressions algorithms are provided for 
the Virtual Path and Virtual Channel transport levels.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-rutemiller-pwe3-atm-encaps-00.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-rutemiller-pwe3-atm-encaps-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-rutemiller-pwe3-atm-encaps-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: "Rutemiller, John" <[email-masked]>
Date: Tue, 25 Jun 2002 13:22:24 -0400

I would like for this draft to be considered as a WG draft candidate
for ATM over PSN encapsulations. I believe it represents a reasonable
compromise between the various drafts proposed for ATM encapsulation.

This draft is based on the draft-martini-atm-encap-mpls-01.txt
encapsulations for transparent port mode, cell relay mode and
AAL5 Payload (SDU) mode.

The difference in encapsulations is the addition of ATM header
compression to the cell relay mode to improve transission efficiency.

One level of compression is defined for VPC cell relay mode. Two levels
of compression are defined for VCC cell relay mode.

This draft does not contain a PDU mode. The equivalent functionality
is provided by the VCC cell relay Mode 2 compression level.

This approach has the advantage over PDU mode in that it does not
define a new mode of operation. It is still a VCC cell relay mode.
Because of this, it is not AAL5 specific. AAL1 and AAL2 can take
advantage of the improved efficiency. The only penalty is loss of
per cell EFCI and CLP information.

The other benefit over PDU mode is "one cell recieved, one frame
transmitted". PDU mode requires the transmission of two frames when
an admin cell arrives. The frame being reassembled and a second
frame containing the admin cell. My VCC cell relay Mode 2 compression
only ever sends one frame in response to an arriving ATM cell.

Other differences with the draft-martini document are:

1) Moved all defect handling procedures to a separate section and
   expanded upon these procedures. This section is fully compatible
   with the draft-martini encapsulations since my draft does not
   add new modes, only header compression.

2) Restructured the document to hopefully improve the flow, and took
   the liberty of rewording some areas (you can decide whether or not
   these were improvements, or should have been left as they were).

3) Made some minor changes to the procedures in draft-martini. For
   example, if an AAL5 reassembly timer is being used, the current PDU
   MUST be discarded upon expiry rather than SHOULD. These are the
   procedures defined by I.363.5.

I believe this draft is a good candidate for achieving a compromise
with regards to ATM encapsulation over the PSN.

This draft retains the basic encapsulation simplicity found in the
draft-martini encapsulation, and supports all of the requests
for improved efficient, but by using the simplest possible mechanisms.

It also addresses most (hopefully all) of the concerns with regards to
defect handling procedures.

There will probably be general agreement that this draft contains
capabilities that people don't believe should be supported. And there
will be disagreement on which capabilities they feel should be removed.
But this is not what is important.

What is important is:

1) Does this draft support the capabilities that you believe are
   important for ATM over PSN interworking?

2) Can you achieve interoperability with any other implementation when
   implementing only the subset of capabilities that are important to
   your target applications?

I believe this draft achieves both of these for everyone concerned.

John

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Tuesday, June 25, 2002 7:03 AM
Cc: [email-masked]
Subject: [PWE3] I-D ACTION:draft-rutemiller-pwe3-atm-encaps-00.txt

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

Send a message to:
	[email-masked].
In the body type:

---

From: [email-masked]
Date: Tue, 25 Jun 2002 15:00:38 -0500

John,
	A comment on the VCC header compression mode 2, which you propose 
to replace the AAL5 PDU mode:

	A disadvantage of including user cells and OAM cells in the same 
MPLS frame is that this MPLS frame will need to get a grade of service 
sufficent to support the OAM cell transport (e.g. EXP=xx0). e.g. in the 
proposed PDU services, 2 frames would have been sent. One with just user 
cells and it could have gotten treatment based on user cells with CLP=1. 
The second, with the OAM cell, could receive treatment for CLP=0.

Robert

> From: John.Rutemiller [mailto:[email-masked]]
> Sent: Tuesday, June 25, 2002 12:22 PM
> To: pwe3
> Subject: RE: [PWE3] I-D ACTION:draft-rutemiller-pwe3-atm-encaps-00.txt
> 
> 

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the 
message.

Internet-Drafts are also available by anonymous FTP. Login with the 
username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-rutemiller-pwe3-atm-encaps-00.txt".

Send a message to:
	[email-masked].
In the body type:
	
	a MIME-compliant mail reader.  Different MIME-compliant mail 
readers

_______________________________________________
pwe3 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pwe3

---

From: "Rutemiller, John" <[email-masked]>
Date: Wed, 26 Jun 2002 14:20:13 -0400

All of the VCC modes allow the OAM cells to be encapsulated with
the user cells.

The martini draft states "The PEs should be able to pass the following
OAM cells transparently:" and then lists the cell types. Nothing about
encapsulating them separately.

The Fischer draft does make a distinction for OAM cells. It adds
"The OAM cell may be encapsulated together with other user data cells
if multiple cell encapsulation is used." So this draft doesn't require
that OAM cells are sent separately in cell mode, but it does indicate
that both options are allowable.

Quick note here. These should all say administrative cells (PTI=1xx)
and not OAM cells (PTI=100 and PTI=101). RM cells (PTI=110) are
not OAM cells.

As far as my VCC Mode 2 encapsulation is concerned, there is nothing
in the encapsulation that would prevent sending the admin cell separately.
The only change required would be to the algorithm. This change would
add one line as the first line in the algorithm that states "If the
arriving cell is an administrative cell, optionally send the current
frame". The rest of the algorithm would remain the same and the newly
arrived admin cell would be processed as the first cell of a new frame,
then immediately sent because it was an admin cell.

Or, this can be handled globally for cell relay services by adding the
statement that for VPC and VCC cell relay modes, including all
compression modes, administrative cells may be concatenated onto the
current frame buffer, or sent as a single cell frame after transmitting
the current frame buffer.

My version (with clarifications) leaves open the option of concatenating
the admin cell or sending it separately for all modes of operation. The
Fischer draft leaves open this option for VPC and VCC mode, but forces
the admin cell to be sent separately in frame mode. The less stringent
service has the more stringent rules. 

John

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]
Sent: Tuesday, June 25, 2002 4:01 PM
To: [email-masked]; [email-masked]
Subject: RE: [PWE3] I-D ACTION:draft-rutemiller-pwe3-atm-encaps-00.txt

John,

Robert

Send a message to:
	[email-masked].
In the body type: