The MPLS WG Archive

["Lars-Erik Jonsson (LU/EAB)" <lars-erik.jonsson@ericsson.com>]

MPLS-HC folks,

I've now looked into the MPLS-HC solution draft as well as the
mail exchanges between Magnus and Jerry. The problems I see with 
the draft are very similar to those pointed out by Magnus. However,
in an attempt to avoid getting too influenced by Magnus comments
I will make my points purely based on my own reflections from the
draft, and then from that refer to the discussion between Magnus
and Jerry.

Overall document structure and purpose
--------------------------------------
On a high level, I think this MPLS-HC document should be about
three things:
1) Negotiation of use, i.e. setup signalling
2) Encapsulation, i.e. how to send HC-packets over MPLS
3) Operation, i.e. considerations for the actual compression scheme(s),
  e.g. how to implement the scheme(s) to be able to handle reordering

1-2 are addressed in the draft, while 3) is not, although it is
essential as an ordinary implementation of the existing HC schemes
would e.g. not necessarily work well enough in case of reordering.

I also strongly believe this MPLS-HC mapping solution should cover
the currently available HC schemes, IP-HC, CRTP, eCRTP, and ROHC.
I would not say we have to make it totally generic for *any* HC
scheme, as I do not think we can cover up for future solutions. 
RFC 3544 (i.e. RFC 2509bis), which provides 1) and 2) for IP-HC,
CRTP, and eCRTP, as well as RFC 3409, which do the same for ROHC,
could be used as a basis for this work. The similarities in how to
solve 1), 2), and 3) for existing HC schemes should be dominating
rather than the differences. 

By the way, could we please avoid the terminology "control/data plane".


Context multiplexing within an LSP, why signalling?
---------------------------------------------------
The second main concern I have is the same one as Magnus expressed,
about the multiplexing, which seems to require signalling that I
can not see the point of. As I know nothing about the details
of MPLS, my question from reading the draft was simply why there
would have to be any signalling for picking a CID value, existing
HC schemes assume the compressor does this without any signalling.
The draft just talks about "...to signal the SCIDs...", without
explaining the meaning of this.

I do not exactly understand the underlying MPLS problem that Magnus
talked about that might be the motivation for having to do CID tricks,
but I agree with his concerns about this approach, which seems to
require signalling for each new packet stream, and also contradicts
the way existing HC schemes handle CID assignment. In any case, the
draft should explain better the motivations behind solutions like
this.

For the negotiation & encapsulation I would strongly recommend using
RFC 3544 and RFC 3409 as a basis, and clearly highlight potential 
deviations from the solutions used in these RFC's, that would help
to get more constructive involvement from the HC folks in this work.

On the CID handling question, I also noticed the text about how to
free up CID. I am not sure what the purpose of that is, but this also
represents a deviation from how existing HC schemes are defined.
Looking at packets not belonging to the flow (e.g. SIP messages)
also seems like a not very desirable approach, in my mind.


What creates a feedback channel?
--------------------------------
Is the LSP per definition bidirectional, or are LSP's always set up
as pairs, one in each direction? If we talk about multiple LSP's,
there must be an exact 1-1 mapping, or there must be a way to create
that binding between them.


eCRTP packet type identification
--------------------------------
Inconsistency, first paragraph of 2.2 talks about a 4-bit packet type,
while the second paragraph says a one-octet PT ID is used. In the
figure, I wonder what the first octet of zeros is, not really 
explained. "Defined by PPP Data Link Layer Protocol" means?


HC object formats
-----------------
This section was very confusing to me. First, the text talks about
intermediates that do not understand HC and could drop the object.
My question is, should not the solution be transparent to intermediates,
i.e. compression should be possible between ingress and egress without
any knowledge in the notes in between? Why should it at all concern
intermediates?

Further, I have a hard time commenting on the content as the fields
in these objects are not described. There should be explanations
after the figures.


Operations
----------
For the operations part, the draft currently says nothing, while we
know there are at least concerns related to reordering. The ROHC over
reordering draft can be a useful source for information in that area,
as well as the eCRTP evaluation I made the list aware of earlier today.
http://www.ietf.org/internet-drafts/draft-ietf-rohc-over-reordering-01.txt
http://epubl.luth.se/1402-1617/2004/286/LTU-EX-04286-SE.pdf


Summary
-------
I thus suggest that the overall purpose of this document (to be adopted
as a WG document) should be to create a HC mapping for MPLS, covering
the HC schemes we currently have, similar to RFC 3544 and 3409. It
should address negotiation (setup), encapsulation, and potential issues
with operation of each HC scheme. 


I'll do my best to support this work from an HC perspective.

Cheers,
/L-E


> -----Original Message-----
> From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org]
> Sent: den 22 december 2004 22:30
> To: IETF AVT WG; rohc@ietf.org; mpls@ietf.org
> Subject: [AVT] [mpls] Comments
> ondraft-ash-avt-ecrtp-over-mpls-protocol-01.txt
> 
> 
> 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-mp
> ls-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