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

From: "Ash, Gerald R \(Jerry\), ALABS" <[email-masked]>
Date: Tue, 4 Jan 2005 09:53:29 -0600

Comments are in line.

Thanks,
Jerry 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Magnus Westerlund
> Sent: Wednesday, December 22, 2004 4:30 PM
> To: IETF AVT WG; [email-masked]; [email-masked]
> 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.

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 18 Jan 2005 09:25:28 +0100

Hi Jerry,

Sorry for the delay in responding. Also I would still like to hear some 
response from the header compression people about the SCID issues.

In regards to rechartering I will send out a message to AVT with a 
proposed new charter for the WG members to comment on.

See comments inline.

> I think this is quite clear.

No, it is not clear. This text seems more a statement of intention, than 
an actual solution. This is important part of the solution and effects 
the signalling and multiplexing mechanism. Can I assume that the same 
need to be able to multiplex multiple peers onto the same LSP exist also 
in the return path?

> http://www.watersprings.org/pub/id/draft-swallow-mpls-simple-hdr-compres

Okay, but you haven't answered my question. What would be the effect of 
putting the multiplexing that you propose using a split SCID space into 
the layer 2 extension?

> taken on within the ROHC WG) seems like a reasonable approach.

To my understanding this solution consists of three parts.

1. Setup signalling
2. MPLS transport and multiplexing of header compression messages
3. Any potential extensions or adaptation to make the header compression 
work over the MPLS generated properties.

To my understanding the setup signalling must be generic and allow the 
setup of any header compression mechanism. So this part in my view needs 
to be HC mechanism agnostic.

The MPLS transport of compressed messages may not be agnostic but are 
probably similar.

If a header compression mechanism needs special extension or 
clarifications, like ROHC over re-ordering channels, fine. However we 
must ensure that the common requirements that the available HC 
mechanisms put, is supported by the MPLS HC solution.

Cheers

Magnus Westerlund

Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 18 Jan 2005 09:25:28 +0100

Hi Jerry,

See comments inline.

1. Setup signalling

Cheers

Magnus Westerlund

_______________________________________________
mpls mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mpls

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 18 Jan 2005 09:25:28 +0100

Hi Jerry,

See comments inline.

1. Setup signalling

Cheers

Magnus Westerlund