The MPLS WG Archive

[Luca Martini <luca@level3.net>]

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.

Robin Park wrote:
> 
> 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).
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.


> 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.

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.

> 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.

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
> belong
> in a higher protocol lever anyway.

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


> 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.
> 
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
luca@level3.net | VE2WKR/W0 | Phone 720-888-1225 | pager
page-luca@level3.net