Re: [AVT] RE: I-D ACTION:draft-ash-avt-ecrtp-over-mpls-protocol-00.txt
a a <yourf@yahoo.com> Tue, 10 February 2004 18:17 UTC
Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00921 for <avt-archive@odin.ietf.org>; Tue, 10 Feb 2004 13:17:35 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqcRY-0005GF-2L for avt-archive@odin.ietf.org; Tue, 10 Feb 2004 13:17:08 -0500
Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1AIH83b020204 for avt-archive@odin.ietf.org; Tue, 10 Feb 2004 13:17:08 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqcRR-0005Ey-Be; Tue, 10 Feb 2004 13:17:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqcQY-0005Dv-OL for avt@optimus.ietf.org; Tue, 10 Feb 2004 13:16:06 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00858 for <avt@ietf.org>; Tue, 10 Feb 2004 13:16:02 -0500 (EST)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqcQW-0005YK-00 for avt@ietf.org; Tue, 10 Feb 2004 13:16:04 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqcPb-0005Sf-00 for avt@ietf.org; Tue, 10 Feb 2004 13:15:08 -0500
Received: from web41415.mail.yahoo.com ([66.218.93.81]) by ietf-mx with smtp (Exim 4.12) id 1AqcP7-0005MC-00 for avt@ietf.org; Tue, 10 Feb 2004 13:14:37 -0500
Message-ID: <20040210181406.10680.qmail@web41415.mail.yahoo.com>
Received: from [209.246.224.110] by web41415.mail.yahoo.com via HTTP; Tue, 10 Feb 2004 10:14:06 PST
Date: Tue, 10 Feb 2004 10:14:06 -0800
From: a a <yourf@yahoo.com>
Subject: Re: [AVT] RE: I-D ACTION:draft-ash-avt-ecrtp-over-mpls-protocol-00.txt
To: "Ash, Gerald R (Jerry), ALABS" <gash@att.com>, avt@ietf.org
Cc: "Ash, Gerald R (Jerry), ALABS" <gash@att.com>
In-Reply-To: <9473683187ADC049A855ED2DA739ABCA0201F057@KCCLUST06EVS1.ugd.att.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60
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>
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" <gash@att.com> wrote: > 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: Internet-Drafts@ietf.org > [mailto:Internet-Drafts@ietf.org] > 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 > avt@ietf.org > https://www1.ietf.org/mailman/listinfo/avt __________________________________ Do you Yahoo!? Yahoo! Finance: Get your refund fast by filing online. http://taxes.yahoo.com/filing.html _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt
- [AVT] RE: I-D ACTION:draft-ash-avt-ecrtp-over-mpl… Ash, Gerald R (Jerry), ALABS
- [AVT] Re: I-D ACTION:draft-ash-avt-ecrtp-over-mpl… Curtis Villamizar
- [AVT] RE: I-D ACTION:draft-ash-avt-ecrtp-over-mpl… Ash, Gerald R (Jerry), ALABS
- Re: [AVT] RE: I-D ACTION:draft-ash-avt-ecrtp-over… a a
- Re: [AVT] RE: I-D ACTION:draft-ash-avt-ecrtp-over… a a
- RE: [AVT] RE: I-D ACTION:draft-ash-avt-ecrtp-over… Ash, Gerald R (Jerry), ALABS
- Re: [AVT] RE: I-D ACTION:draft-ash-avt-ecrtp-over… Colin Perkins
- [AVT] Re: I-D ACTION:draft-ash-avt-ecrtp-over-mpl… Stewart Bryant