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 at ietf.org [mailto:avt-bounces at ietf.org]
Sent: den 22 december 2004 22:30
To: IETF AVT WG; rohc at ietf.org; mpls at 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
_______________________________________________
Audio/Video Transport Working Group
avt at ietf.org
https://www1.ietf.org/mailman/listinfo/avt