Subject: ATM over MPLS (comments on draft-martini-l2circuit-encap-mpls-00.txt)

From: Robin Park <[email-masked]>
Date: Fri, 08 Dec 2000 16:54:53 -0500

Hi,

I would like to propose the following modifications to
draft-martini-l2circuit-encap-mpls-00.txt, for transporting cell relay
traffic over MPLS networks.  The first three simplify the proposal for
cell relay, and the last makes the cell encapsulation more bandwidth
efficient.

1) Remove the "Transport Type (T)" bit in the generic control word.  A
VC would either use cell encapsulation mode, or AAL5 encapsulation
mode.  The type of encapsulation used would be determined from the VC
label context.  It seems that the main reason for allowing both modes is

to support OAM traffic in an AAL5 encapsulation mode.  If OAM traffic is

desired, cell encapsulation would be used instead.  Cell encapsulation,
as currently proposed, is much less efficient, but this can be partly
remedied (see note 4).
2) For cell relay transport, always set the length field to 0.  When
transporting cell relay across MPLS, the ingress LSR would always set
the length field to 0, and the egress LSR would always ignore it.  The
length would always be inferred from the received MPLS packet length.
For cell relay transport, Ethernet's minimum frame size will not cause
the MPLS packet to be padded.  When using cell encapsulation, the cell
length (48 bytes) is already greater than the Ethernet's minimum frame
size.  When using AAL5 encapsulation, the full AAL5 CPCS-PDU is used,
which is also greater than the minimum frame size.
3) For cell relay, allow a LSR to always set the sequence number to 0,
and allow it to ignore the received sequence number.  A sequence number
of 0 then has special meaning.  If a LSR does check the sequence number,

it would always assume that packets received with a 0 sequence number
would be in order.  Many MPLS networks will not consistently re-order
MPLS packets.  In these networks, edge LSR would not need to generate or

interpret sequence numbers.  One could argue that sequence numbers
belong
in a higher protocol lever anyway.
4) In cell encapsulation mode, allow more than one cell to be
encapsulated into an MPLS packet.  Cell encapsulation, as currently
stated, is fairly inefficient.  There are 8 bytes of ATM/MPLS header + 4

bytes VC label + 4 bytes tunnel label + L2 specific overhead (PPP,
Ethernet header, ...), all for one cell of 48 bytes.  Allowing multiple
cells in one MPLS packet could greatly reduce this overhead.
MPLS packets could have any numbers of cells, limited by the MTU of the
LSP.

Robin.

---

From: Luca Martini <[email-masked]>
Date: Mon, 18 Dec 2000 17:05:50 -0700

Robin,

A few of the problems mentioned in this e-mail and another one have been
addresses 
while in San Diego. a new version of the draft will be published
shortly.

I'll try to briefly reply here.

> as currently proposed, is much less efficient, but this can be partly
It is not possible to distinguish between a OAM cell , and a hole ALL5 
PDU traveling on a
 particular LSP without the T bit. One solution would be to simply spoof
the oam cells and use the LDP signaling to send a label withdraw and
cause the remote LSR to do the right spoofing. This is however not
acceptable for some networks using special OAM cells. This also does not
get the fast response that a network would obtain using OAM cells.

For this reason we need to keep the T bit functionality ( Optional ),
and also implement the spoofing method.
As for note 4 , oam cells are not bunched together so it would take to
long to implement this for OAM.

> which is also greater than the minimum frame size.

How about half duplex gigabit ethernet ?  I don't think anybody I know
implemented it , but I thought the minimum was 256 ?
We will check and fix this problem.

> interpret sequence numbers.

I have considered this option, epecially because it seems to be costly
to implement the sequence number.
I will discuss this with the aother authors.

  One could argue that sequence numbers
> in a higher protocol lever anyway.

Yes, but we are transporting Layer 2, not the higher layer.

> MPLS packets could have any numbers of cells, limited by the MTU of the
yes, we have already made this change to the design. We are going to use
4 bytes cell headers ( ATM headers without HEC ) , and allow one or more
such cells per MPLS frame.

> Robin.
Thanks for the comments.

Luca

-- 
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: Robin Park <[email-masked]>
Date: Wed, 20 Dec 2000 10:14:06 -0500

Luca,

See comments below.

Robin.

> long to implement this for OAM.

I think you misunderstand me.  I'm saying that when using AAL5 CPCS-PDU
encapsulation, OAM is not supported and there is no need for a T bit.  The
fact that the connection is using PDU encapsulation is determined from the
VC label.  If OAM is desired, then the connection uses cell encapsulation.
Again, the VC label determines which encapsulation mode is being used.

I guess I see cell encapsulation as the main encapsulation mode, with full
ATM functionality.  I see the AAL5 encapsulation as an alternate
encapsulation which gives a bit of bandwidth savings.

I can understand the need for the T bit if a LSR does not support cell
encapsulation.  In this case, cell encapsulation is not an option.  If you
want OAM on your AAL5 connections, you must use the T bit.  Is it valid for a
LSR to support one encapsulation method but not the other?

> We will check and fix this problem.

I'll look into this again.

> Yes, but we are transporting Layer 2, not the higher layer.

True.