Subject: [AVT] HC over multihop / MPLS

From: "Lars-Erik Jonsson (LU/EAB)" <[email-masked]>
Date: Wed, 12 Nov 2003 20:45:12 +0100

As I promised in the WG session, I'll try to share my thoughts on
the HC over multihop/MPLS issue.

The AVT charter states the following as a WG task: 
"to review the applicability of Compressed RTP operation on
  MPLS networks, developing extensions as necessary"

With the following milestones:
Nov 03    Initial draft requirements for ECRTP over MPLS; discuss with MPLS WG
Nov 03    Initial draft requirements for ECRTP over MPLS; discuss with MPLS WG

However, the current draft refers to "VoIP Header Compression over Multi-Hop
Paths", which is not the same thing. The draft clearly shows that compression
over multihop paths is one thing, and compression over MPLS another. Further,
the draft takes a wider scope, and talks about header compression generally,
not only ECRTP as the charter says.

The following observations can be made:
* If work is to done for header compression over multihop and/or MPLS, it
  might make sense to not only address ECRTP.
* The only work in this that naturally could belong in the AVT WG would be
  to make sure ECRTP would work in these scenarios. In my understanding,
  this should already be the case with ECRTP (as well as some ROHC profiles),
  which is also indicated by the multihop req draft.
* Header compression over multihop paths [ described by the multihop req
  draft as where one wants to avoid decompression/compression steps at
  intermediate routers if the same compression scheme is supported at both
  incoming and outgoing interfaces ] is fully possible also without any new
  standards, as it would only be an implementation issue for each intermediate
  router to bind an incoming compressed stream to its corresponding outgoing
  compressed stream. In a path A->B->C, where B is the intermediate router
  negotiating use of e.g. CRTP with both A and C, it is fully up to the
  implementation of B to avoid unnecessary decompression/compression and
  just forward compressed packets as-is ("CID routing").
* The only significant standardization work I can see is to define how to
  do header compression (e.g. IPHC, CRTP/ECRTP, ROHC) over MPLS, which is
  probably a work that would require some coordination with AVT and ROHC
  individuals, but the core of that work does not naturally belong to
  ROHC or AVT. Would not the MPLS WG be a more proper place?

Just a few thoughts, let's get discussions going!
/L-E 

-----------------------------------
Lars-Erik Jonsson, M.Sc
Wireless IP Optimizations
AWARE - Advanced Wireless Algorithm Research
Ericsson Research, Corporate Unit
Ericsson AB
Box 920, S-971 28 Luleå, Sweden
E-mail: [email-masked]
Phone: +46 920 20 21 07
Fax: +46 920 20 20 99
Home: +46 920 999 57

My opinions are my personal opinions and should not be considered
as the opinions of my employer, if not explicitly stated. 

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

---

From: Colin Perkins <[email-masked]>
Date: Fri, 21 Nov 2003 10:33:40 +0000

On Wednesday, Nov 12, 2003, at 19:45 Europe/London, Lars-Erik Jonsson 
> the HC over multihop/MPLS issue.
...
>   might make sense to not only address ECRTP.

Certainly a header compression draft for MPLS should allow the 
negotiation of ROHC as an alternative to ECRTP.

>   which is also indicated by the multihop req draft.

I believe ECRTP would work, but one of the main purposes of the 
requirements capture process is to confirm this by getting MPLS and 
ECRTP folks in the same room and comparing the environments and 
assumptions.

>   just forward compressed packets as-is ("CID routing").

Agreed, but it may be worthwhile writing a brief draft explaining the 
process, perhaps targeted at BCP or Informational?

>   ROHC or AVT. Would not the MPLS WG be a more proper place?

Probably. The purpose of the requirements work is to understand the 
issues, and to decide if this is the right approach, or if we need to 
do something more.

Cheers,
-- 
Colin Perkins
http://csperkins.org/