The MPLS WG Archive

Cell Relay Retreat>MPLS WG Archive>month:2005-Feb> msg00070



[Date Prev][Date Next][Thread Prev][Thread Next]  
  [Date Index][Thread Index][Author Index][Subject Index]

[AVT] [mpls] Comments ondraft-ash-avt-ecrtp-over-mpls-protocol-02.txt

  • From: Magnus Westerlund <magnus.westerlund@ericsson.com>
  • Date: Wed, 23 Feb 2005 16:39:07 +0100
  • Cc: mpls@ietf.org, rohc@ietf.org, IETF AVT WG <avt@ietf.org>
  • User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
  • X-OriginalArrivalTime: 23 Feb 2005 15:39:48.0342 (UTC)FILETIME=[E8196960:01C519BD]
  • X-Sybari-Trust: b5add203 b8ec86c7 a29e4f76 00000139

Hi Jerry,

A few comments.

1. I think you are focus area in the CID debate is on solving the wrong 
problem. I think you should take one step back, and focus on what is 
need to solve the real problem. The real problem is in my eyes: The 
header compression mechanism is designed to be used over a point to 
point link. Where there can only be one compressor per decompressor. 
After an initial setup signalling, the compressor knows what it can do, 
like creating compression state IDs (CID). So instead of focusing and 
discussing the CID creation and removal, please look at how one can make 
the MPLS label path between compressor and decompressor look like a 
point to point link.

Trying to use a reduction of the CID space for a compressor will result in:
- Changed compressor implementations instead of simply the transport 
format of compressed frames.
- Limitation on the capacity of the compressor
- Extra signalling overhead, not normally existing over the link.

Putting the compressor identify for a specific MPLS label into the layer 
2.5 header that still goes above the MPLS header would not be more 
complex signalling wise, and avoids modifying the header compression 
implementations.

2. We do not need to define a complete solution for all the existing 
header compression mechanism, however should make it possible. And I 
would make it: "The MPLS HC framework must be able to use ECRTP and ROHC".

And a correction on your RTP SSRC handling summary:

Ash, Gerald R (Jerry), ALABS wrote:

> Section 6.2.1 of RFC 3550 (RTP) discusses freeing up SSRCs after an RTCP
> 'BYE' packet is received, which ends the RTP session.  Section 6.3.5
> discusses how to free up SSRCs after a time-out period.  This might work
> for RTP flows, but how to do it for IPHC?  

Sending an RTCP BYE does not end the RTP session, it tells the other 
participants that this SSRC has left the session. That is a big difference.

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: magnus.westerlund@ericsson.com

_______________________________________________
mpls mailing list
mpls@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/mpls