RE: [AVT] Agenda for Vienna

"Ash, Gerald R (Jerry), ALABS" <gash@att.com> Mon, 07 July 2003 17:58 UTC

Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05375 for <avt-archive@odin.ietf.org>; Mon, 7 Jul 2003 13:58:29 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZaFV-0000fa-Az for avt-archive@odin.ietf.org; Mon, 07 Jul 2003 13:58:01 -0400
Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h67Hw16W002570 for avt-archive@odin.ietf.org; Mon, 7 Jul 2003 13:58:01 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZaFU-0000et-Ma; Mon, 07 Jul 2003 13:58:00 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZaEi-0000Xi-Mc for avt@optimus.ietf.org; Mon, 07 Jul 2003 13:57:12 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05319 for <avt@ietf.org>; Mon, 7 Jul 2003 13:57:09 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ZaEg-0007bp-00 for avt@ietf.org; Mon, 07 Jul 2003 13:57:10 -0400
Received: from kcmso2.att.com ([192.128.134.71] helo=kcmso2.proxy.att.com) by ietf-mx with esmtp (Exim 4.12) id 19ZaEf-0007b9-00 for avt@ietf.org; Mon, 07 Jul 2003 13:57:09 -0400
Received: from attrh5i.attrh.att.com ([135.38.62.12]) by kcmso2.proxy.att.com (AT&T IPNS/MSO-5.0) with ESMTP id h67HpohL008048 for <avt@ietf.org>; Mon, 7 Jul 2003 12:56:39 -0500
Received: from KCCLUST06EVS1.ugd.att.com (135.38.164.88) by attrh5i.attrh.att.com (6.5.032) id 3EE9217C008AB83E; Mon, 7 Jul 2003 13:56:33 -0400
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0
Subject: RE: [AVT] Agenda for Vienna
Date: Mon, 07 Jul 2003 12:56:38 -0500
Message-ID: <9473683187ADC049A855ED2DA739ABCA0A68A8@KCCLUST06EVS1.ugd.att.com>
Thread-Topic: [AVT] Agenda for Vienna
Thread-Index: AcNCCZ6lSLFfYszIRverkJLLwcV1CQCpupVg
From: "Ash, Gerald R (Jerry), ALABS" <gash@att.com>
To: Colin Perkins <csp@csperkins.org>, avt@ietf.org
Cc: "Ash, Gerald R (Jerry), ALABS" <gash@att.com>, casner@acm.org, magnus.westerlund@ericsson.com
Content-Transfer-Encoding: quoted-printable
Sender: avt-admin@ietf.org
Errors-To: avt-admin@ietf.org
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe>
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: quoted-printable

All,

Here is a brief summary regarding the following agenda item:

> CRTP over MPLS 						(Ash)		20
>	draft-ash-e2e-crtp-hdr-compress-01.txt
>	draft-ash-e2e-vompls-hdr-compress-01.txt
>	draft-ash-e2e-voip-hdr-comp-rqmts-00.txt

Background:

Some service providers (such as AT&T) have plans to migrate large amounts of legacy voice traffic to VoIP, as well as to provide VPN services enabling VoIP.  VoIP over MPLS ('VoMPLS') typically uses the encapsulation voice/RTP/UDP/IP/MPLS.  For an MPLS VPN, the packet header is at least 48 bytes, while the voice payload is typically no more than 30 bytes.  VoIP over MPLS header compression can significantly reduce the VoIP overhead through various compression mechanisms.  This is important on access links where bandwidth is scarce, and can be important on backbone facilities, especially where costs are high (e.g., some global cross-sections).
  
VoIP over MPLS header compression methods have been proposed earlier (March, 2000) in the MPLS working group, however the relevant drafts have expired.  In particular, George Swallow and Lou Berger proposed a 'simple' end-to-end compression scheme in which all first-order differences in the RTP/UDP/IP headers were transmitted, and in which the header compression context was established through RSVP signaling.  The work was accepted into the MPLS WG pending an addition to the MPLS WG charter.

In the I-D's we propose 3 approaches to VoMPLS header compression: a) re-use the methods in cRTP to determine the context and MPLS to route packets, b) re-use the methods in Swallow's and Berger's 'simple' approach to determine the context and MPLS to route packets, and c) re-use the methods in cRTP to determine the context and the SCID (session context ID) to route packets.

The work was presented at the IETF-56 MPLS WG meeting (slides and an excellent set of meetings notes are available at http://ietf.org/proceedings/03mar/index.html.

Issues to discuss:

1. WG charter -- The VoMPLS header compression work is not within the current charter of the AVT WG, so a charter extension is needed.  A discussion among the Transport Area Directors and Sub-IP Area Directors suggested that the work fits most closely within the Transport Area/AVT WG.

2. Protocol extensions -- As detailed in the I-Ds, extensions are proposed to [cRTP] and [cRTP-ENHANCE], which involve a new packet type field to identify FULL_HEADER, CONTEXT_STATE, etc. packets.  New objects are defined for [RSVP-TE].  Extensions are also proposed to RFC2547 VPNs, which create 'SCID routing tables' to allow routing based on the session context ID (SCID).  These extensions need coordination with other WGs (e.g., MPLS).

3. Resynchronization -- E2E VoMPLS using cRTP header compression might not perform well with frequent resynchronizations.  [cRTP-ENHANCE] seems appropriate in this context.  The 'simple' header compression approach would avoid the need for resynchronization, but achieves less efficiency than cRTP.

4. Scalability -- E2E VoMPLS applied between CE-CE would perhaps require a large number of LSPs to be created.  There is concern for CE ability to do the necessary processing and the scalability of the architecture.

4. LDP application -- It would be desirable to signal the VoMPLS tunnels with LDP, since many RFC2547 VPN implementations use LDP as the underlying LSP signaling mechanism.
Please review the documents and raise any issues/comments to the list.

Please review the documents and raise any issues/comments to the list.

Thanks,
Jerry Ash

_______________________________________________
Audio/Video Transport Working Group
avt@ietf.org
https://www1.ietf.org/mailman/listinfo/avt