[rohc] RE: [AVT] Comments on draft-ash-avt-ecrtp-over-mpls-protocol-01.txt

["Ash, Gerald R \(Jerry\), ALABS" <gash at att.com>]

Comments are in line.

Thanks,
Jerry 

> -----Original Message-----
> From: avt-bounces at ietf.org [mailto:avt-bounces at ietf.org] On 
> Behalf Of Magnus Westerlund
> Sent: Wednesday, December 22, 2004 4:30 PM
> To: IETF AVT WG; rohc at ietf.org; mpls at ietf.org
> Subject: [AVT] Comments on 
> draft-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-mpls-protoco
l-01.txt
> it should also be available in the IETF repository if it hasn't
expired.

Jerry>> The latest draft is available at
http://www.ietf.org/internet-drafts/draft-ash-avt-ecrtp-over-mpls-protoc
ol-02.txt.

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

Jerry>> It is the CONTEXT_STATE packets that travel on the reverse path,
as stated in the ID.  Here is the relevant passage in the ID:

"4. Compressed packets and header compression control packets
(FULL_HEADER and CONTEXT_STATE packets) are routed on a separate LSP,
set up by RSVP-TE, from non-compressed packets; FULL-HEADER packets are
routed on the same R1/HC --> R4/HD LSP as the R1/HC to R4/HD compressed
packets for the ECRTP flow; CONTEXT-STATE packets are routed on the same
R4/HD --> R1/HC LSP as the R4/HD to R1/HC compressed packets for the 
ECRTP flow.
5. compressed packets, FULL_HEADER packets, and CONTEXT_STATE packets
are routed with MPLS labels.
6. R4/HD uses the incoming MPLS label and the SCID to locate the proper
decompression context."

I think this is quite clear.

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

Jerry>> FYI, the proposed protocol extensions in the current draft are
much the same as originally proposed by George Swallow (almost 5 years
ago) to the MPLS WG for the 'Simple Header Compression' protocol
http://www.watersprings.org/pub/id/draft-swallow-mpls-simple-hdr-compres
s-00.txt.

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

Jerry>> It isn't obvious how to make this 'header compression agnostic'
for 'any header compression mechanism', given the differences in HC
protocol specifics, etc.  Also, it's not clear whether that would really
buy a lot:  ROHC is the only other proposed protocol to be accommodated
within HC over MPLS, and one more protocol extensions draft (perhaps
taken on within the ROHC WG) seems like a reasonable approach.



_______________________________________________
Rohc mailing list
Rohc at ietf.org
https://www1.ietf.org/mailman/listinfo/rohc