The MPLS WG Archive[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index][Thread Index][Author Index][Subject Index] [AVT] [mpls] Commentsondraft-ash-avt-ecrtp-over-mpls-protocol-01.txt
Lars-Erik, I notice that the -02 draft is available, but that these comments are based on the -01 version. Do the changes in the -02 version address your concerns? Colin On 27 Jan 2005, at 16:03, Lars-Erik Jonsson (LU/EAB) wrote: > 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 > > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www1.ietf.org/mailman/listinfo/avt > _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls
|
|