The MPLS WG Archive

[Magnus Westerlund <magnus.westerlund@ericsson.com>]

Hi,

Sorry for the crossposting, however this is something that I think needs
to be generally discussed between all 3 WGs. To me it looks like the
proposed solution for VoIP header compression across an MPLS network
contains a problematic demultiplexing mechanism. I don't think people 
has realized the issues with the proposed mechanism due to lack of 
communication between the header compression and MPLS folks. If it is my 
lack of knowledge please educate me, and the others. I would request 
that people providing input in this discussion is overly explaining as 
education seems necessary.

The current draft is available at:
http://www.watersprings.org/pub/id/draft-ash-avt-ecrtp-over-mpls-protocol-01.txt
it should also be available in the IETF repository if it hasn't expired.

The header compression mechanisms such as CRTP and ROHC to my 
understanding assumes that they have a lower link layer that carries 
their compressed messages between compressor and decompressor. This is 
due to that they are intended to be used with only a single link between 
the compressor and decompressor. In the case of CRTP, it also assumes 
that the link-layer can also provide the with identification of the 
packet types, while ROHC makes this identification internally.

The MPLS network uses one or more labels in the transport between 
ingress and egress from the MPLS network. Due to the possible relabeling 
in the middle of the network, it can't be generally assumed that packets 
arriving with the same label comes from the same ingress point. This 
makes the label not sufficient to identify the ingress for the egress, 
thus not making labels equal to a link.

The proposed solution has thought of the above MPLS problem and proposes 
that one uses the setup signalling to allow the decompressor point to 
select which parts of its context identifier (SCID) space that belongs 
to different ingress points that arrives over the same label. However my 
understanding is that this definitely not without problems for the 
header compression mechanisms. I would like the header compression guy 
to clarify what problems that would arise from such a solution. One 
thing I definitely can see would be an issue, the proposed change would 
prevent MPLS HC to use any standard implementation of the HC mechanism used.

I would also like to point out that the Header Compression mechanism 
needs a return path from the decompressor mechanism. However the draft 
does not seem to discuss this issue at all. Or is a MPLS label path 
automatically reversible?

It would be desirable if the MPLS people could consider if there exist 
other ways of providing for the standard assumption on link layers that 
header compression has? For these assumption please see chapter 2 of RFC 
2508, section 4.1 of RFC 3095, and RFC 3409.

For example, what would be the effects of requiring unique labels 
between ingress and egress and for the reverse path?

What effects would it have to put the multiplexing point in the layer 
two extension?

I would also like to see the draft be more header compression agnostic 
as has been agreed on in the requirements phase. There is no problem 
with using ECRTP as an example how one realize the solution, however the 
necessary hooks and signalling must be in place for any header 
compression mechanism.

So lets get the discussion going and hope that something good results.

Cheers

Magnus Westerlund
AVT Chair



_______________________________________________
mpls mailing list
mpls@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/mpls