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

From: "Ash, Gerald R (Jerry), ALABS" <[email-masked]>
Date: Tue, 10 Feb 2004 08:27:54 -0600

Curtis,

> > 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

> Jerry,
> 
> This looks to be a very good direction to go in.

Thanks Curtis!

> 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
> constitutes 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.

All good suggestions, will incorporate in the next Rev.

Thanks a lot for your careful review,
Jerry

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

---

From: "Ash, Gerald R (Jerry), ALABS" <[email-masked]>
Date: Wed, 11 Feb 2004 06:03:52 -0600

Dear a a,

> It looks pretty good. 

Thanks.

> 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).

This is a good comment.  I think a generic name is appropriate such that the protocol is applicable to any real-time ECRTP flow over MPLS.  We'll generalize that in the next Rev.

> 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 accommodate that as well.

Good point.  Needs to be generalized.
 
> 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 pictorial representation would be useful.

OK.
 
> * 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 sequence
> 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.).

As you suggest, I think a separate draft (or perhaps an Appendix) would be appropriate for detailed message flows.

Thanks a lot for your review, comments, and suggestions.
Jerry

> --- "Ash, Gerald R (Jerry), ALABS" <[email-masked]>
> wrote:
> > All,
> > 
> > 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
> > The proposed extensions are based on the
> > requirements documented in 'Requirements for ECRTP over MPLS'

---

From: Stewart Bryant <[email-masked]>
Date: Mon, 16 Feb 2004 12:00:27 +0000

There are some operations that need to be able to distinguish
between IP and non-IP MPLS payloads. For example a router
performing ECMP based on the IP addresses or other information
in the IP header, or an IPFIX/PSAMP packet sampling system
that needs to analyse the payload contents.

We identified this need in PWE3 and proposed a solution. This
is described in sections 5.4.3 and 5.4.4 of the PWE3 Architecture
draft:

http://www.ietf.org/internet-drafts/draft-ietf-pwe3-arch-06.txt

In essence we proposed that the nibble that immediately follows
the MPLS bottom label has the following semantics:

Value Meaning
0     PWE3 payload*
1     Identified payload type (see below)
4     IPv4
6     IPv6

* It might be argued that this should be changed to mean
"unidentified payload type"

The identified payload type above is the first nibble
in a longword with the following definition:

       0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |0 0 0 1| reserved = 0  |  PA   |          Protocol ID          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |           As defined by PPP DLL protocol definition           |
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       Figure 14: PWE3 PID

    The meaning of the fields of the PWE3 PID (Figure 14) is as follows:

       PA    protocol authority for the user plane or the control plane
             protocol ID
                 0       = PPP DLL
                 1-15    = Reserved

       Protocol ID
             Protocol ID following the format defined by the protocol
             authority identified in PA.

    Bits 4 to 11 inclusive are reserved for future use and must be zero.

PWE3 currently describes this in terms of historic IP version numbers,
but IESG feedback is that we need to use a new registry.

The proposal is that there is a new "nibble that follows the MPLS
label" registry. This will still have the values and semantics described
above. A new draft describing this will be submitted when the IETF
embargo on new drafts lifts, and the PWE3 architecture draft modified 
accordingly. Note that this does not change the existing PWE3 protocol
or headers, just the way that we describe the protocol.

If this proposal gains approval, the implication for ecrtp-over-mpls
would be that it should either:

1) Run under first nibble 0
2) Run under first nibble 1 with an ecrtp-over-mpls as the PPP-DLL value
3) Request a first nibble value from the new registry

- Stewart

Curtis Villamizar wrote:

> ------- Blind-Carbon-Copy
> 
> To: "Ash, Gerald R (Jerry), ALABS" <[email-masked]>
> cc: [email-masked]
> Reply-To: [email-masked]
> Subject: Re: I-D ACTION:draft-ash-avt-ecrtp-over-mpls-protocol-00.txt 
> In-reply-to: Your message of "Mon, 09 Feb 2004 07:39:42 CST."
>              <[email-masked]> 
> Date: Mon, 09 Feb 2004 11:28:58 -0500
> From: Curtis Villamizar <[email-masked]>
> 
> 
> 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. 
>>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
>>
>>
>>	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
> 
> 
> 
> 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.
> 
> consitutes the majority of traffic yet reordering is avoided for
> Curtis
> ------- End of Blind-Carbon-Copy
> 
> 
>