content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [AVT] Agenda for Vienna
Date: Mon, 7 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
Precedence: bulk
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).
 =20
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