Subject: [AVT] RE: I-D ACTION:draft-ash-avt-ecrtp-over-mpls-protocol-00.txt

From: "Ash, Gerald R (Jerry), ALABS" <[email-masked]>
Date: Mon, 9 Feb 2004 07:39:42 -0600

All,

Please review and comment on 'Protocol Extensions for ECRTP over MPLS' http://www.ietf.org/internet-drafts/draft-ash-avt-ecrtp-over-mpls-protocol-00.txt.  The protocol extensions enable the use of MPLS to route enhanced compressed RTP (ECRTP) compressed packets over an MPLS LSP without compression/decompression cycles at each router.

The proposed extensions are based on the requirements documented in 'Requirements for ECRTP over MPLS' http://www.ietf.org/internet-drafts/draft-ash-avt-ecrtp-over-mpls-reqs-01.txt.

Thanks,
Jerry

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, February 05, 2004 3:43 PM
Subject: I-D ACTION:draft-ash-avt-ecrtp-over-mpls-protocol-00.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title		: Protocol Extensions for ECRTP over MPLS
	Author(s)	: J. Ash
	Filename	: draft-ash-avt-ecrtp-over-mpls-protocol-00.txt
	Pages		: 0
	Date		: 2004-2-5
	
VoIP typically uses the encapsulation voice/RTP/UDP/IP. When MPLS labels 
are added, this becomes voice/RTP/UDP/IP/MPLS-labels. For an MPLS VPN, 
the packet header is at least 48 bytes, while the voice payload is often 
no more than 30 bytes, for example. VoIP header compression can 
significantly reduce the VoIP overhead through various compression 
mechanisms, such as enhanced compressed RTP (ECRTP). We consider using 
MPLS to route ECRTP compressed packets over an MPLS LSP without 
compression/decompression cycles at each router. Such an ECRTP over MPLS 
capability can increase the bandwidth efficiency as well as processing 
scalability of the maximum number of simultaneous VoIP flows that use 
header compression at each router.  In this draft we propose to use 
RSVP-TE extensions to signal the header compression context and other 
control messages between the ingress and egress LSR.  We re-use the 
methods in ECRTP to determine the context.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ash-avt-ecrtp-over-mpls-protocol-00.txt.

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

---

From: Curtis Villamizar <[email-masked]>
Date: Mon, 09 Feb 2004 11:28:58 -0500

In message <[email-masked]>
, "Ash, Gerald R (Jerry), ALABS" writes:
> All,
> 
> Please review and comment on 'Protocol Extensions for ECRTP over MPLS' http:/
> /www.ietf.org/internet-drafts/draft-ash-avt-ecrtp-over-mpls-protocol-00.txt. 
>  The protocol extensions enable the use of MPLS to route enhanced compressed 
> RTP (ECRTP) compressed packets over an MPLS LSP without compression/decompres
> sion cycles at each router.
> 
> The proposed extensions are based on the requirements documented in 'Requirem
> ents for ECRTP over MPLS' http://www.ietf.org/internet-drafts/draft-ash-avt-e
> crtp-over-mpls-reqs-01.txt.
> 
> Thanks,
> Jerry
> 
> 

Jerry,

This looks to be a very good direction to go in.  I've dropped MPLS
from the Cc and put MPLS on the bcc so people know the discussion is
on the AVT mailing list only.

In your encapsulations you should make sure to avoid any values in the
first byte that could be mistaken as IPv4 or IPv6 or any of the
encapsulations being worked on by those working on VPN and PW.  See
"The PWE3 Control Word", Jonathan Stein, 22-Oct-02,
draft-stein-pwe3-controlword-00.txt, for some early discussion on
that.  Note though that "Payload Type" is something that many
providers require so that multipath can be used on IP traffic which
consitutes the majority of traffic yet reordering is avoided for
traffic which cannot be split based on what appears to be an IP header
and the IP src/dst pair.

It might be best to reserve a single fixed first byte for the "Packet
Type" (and I suggest you make up a name for this shim such as
SCID_Packet_Type) and use the second byte for the packet types that
you have defined.  Just as you have to get numbers for SCID_Request
Object and Header_Compression_Reply Object from IANA, you'll have to
coordinate with others over this number space, though it is less clear
if IANA is the authority on this quite yet.

Curtis

---

From: a a <[email-masked]>
Date: Tue, 10 Feb 2004 10:14:06 -0800 (PST)

Hi,

It looks pretty good. I have a question rather than a
comment:

In this draft we are trying to add some new objects to
the base RSVP-TE. RSVP or RSVP-TE so far have been
kept immune from the applications that could make use
of it. So, why are we planning to add something like
"VoIP-CallIds" instead of some generic name or
identifier that could be used by different
applications in different contexts? The L3PID anyway
would define the kind of the payload being carried and
applications would be free to interpret that "generic
identifier" in the fashion they want. (Pls. excuse me
if I'm not privy to some information or earlier
discussions).

Today we have SIP (in VoIP networks) and that's why
usage of VoIP-CallIds may be justified in some sense
but tomorrow there could be some other protocol (that
may use some other identifier instead of callId) and
hence we may have to accomodate that as well.

The other minor comments that I have are:
* Though the draft states that packet type field would
be prepended to the "packet formats" defined in ECRTP
(RFC3545), a pictoral representation would be useful.

* Most of the SIP RFCs and SIP drafts have associated
example "Call Flows" with DETAILED message contents -
either in separate drafts/RFCs or in Appendix sections
to the main RFC/drafts. Can we do something similar
for this draft as well? (It has some message seuqence
shown but it's not that detailed). It would be useful
to see the data plane encodings as well (with label
stacks, packet types and compressed payloads etc.).

Thanks.

--- "Ash, Gerald R (Jerry), ALABS" <[email-masked]>
wrote:
> All,
> 
> Please review and comment on 'Protocol Extensions
> for ECRTP over MPLS'
>
>  The protocol extensions enable the use of MPLS to
> route enhanced compressed RTP (ECRTP) compressed
> packets over an MPLS LSP without
> compression/decompression cycles at each router.
> 
> The proposed extensions are based on the
> requirements documented in 'Requirements for ECRTP
> over MPLS'
>
http://www.ietf.org/internet-drafts/draft-ash-avt-ecrtp-over-mpls-reqs-01.txt.
> Subject: I-D
> ACTION:draft-ash-avt-ecrtp-over-mpls-protocol-00.txt
> 
> 	Filename	:
> draft-ash-avt-ecrtp-over-mpls-protocol-00.txt
> 	Pages		: 0
> 	Date		: 2004-2-5
> 	
> are added, this becomes
> voice/RTP/UDP/IP/MPLS-labels. For an MPLS VPN, 

__________________________________
Do you Yahoo!?
Yahoo! Finance: Get your refund fast by filing online.
http://taxes.yahoo.com/filing.html

---

From: a a <[email-masked]>
Date: Tue, 10 Feb 2004 12:01:41 -0800 (PST)

> > mechanisms, such as enhanced compressed RTP
> (ECRTP).
> > We consider using 
> > MPLS to route ECRTP compressed packets over an
> MPLS
> > LSP without 
> > Such an ECRTP over MPLS 
> > capability can increase the bandwidth efficiency
> as
> > well as processing 
> > header compression at each router.  In this draft
> we
> > propose to use 
> > RSVP-TE extensions to signal the header
> compression
> > context and other 
> > control messages between the ingress and egress
> LSR.
> >  We re-use the

---

From: Colin Perkins <[email-masked]>
Date: Wed, 11 Feb 2004 13:45:03 +0000

Folks,

I'm happy that there is interest in this protocol, however I would like to
remind folks that we have not yet agreed on the requirements documents, or
decided the appropriate home for this work. At the risk of delaying this
work for a few weeks, could we first make sure there is consensus that the
requirements are appropriate, before trying to build a protocol that
addresses them?

Colin

--> "Ash, Gerald R (Jerry), ALABS" <[email-masked]> writes:
> All,
> 
> Please review and comment on 'Protocol Extensions for ECRTP over MPLS'
>  The protocol extensions enable the use of MPLS to route enhanced
>  compressed RTP (ECRTP) compressed packets over an MPLS LSP without
> The proposed extensions are based on the requirements documented in
> 'Requirements for ECRTP over MPLS'

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