Subject: Arch sections 5.4.3 and 5.4.4

From: Stewart Bryant <[email-masked]>
Date: Thu, 10 Apr 2003 12:38:04 +0100

I have redrafted sections 5.4.3 and 5.4.4 of the arch draft, and
hopefully the this moves us closer to consensus.

I have removed the SONET text. The SONET team need to resolve whether
they wish to use the bits 0..3 == 0x0 approach, or the payload
type identifier approach, but the arch text is invariant to this
decision.

It is known that I have concerns over the ITU ATM format, but due
to an artifact of the way that length is defined this conforms
to figure 12.

I have renamed the most basic 0x0 nibble CW the generic CW
and the old Martini CW the preferred CW, and introduced
then in that order, as this seems a more logical flow.

There are two current proposals for MPLS payload type, which
the authors are in the process of merging. I will produce a
further update when this has happened.

Comments?

Stewart

5.4.3. PW over MPLS Generic Control Word

    To allow accurate packet inspection in an MPLS PSN, and to operate
    correctly over MPLS PSNs that have deployed equal-cost multiple-path
    load-ballancing a PW packet MUST NOT alias an IP packet.  IP packets
    are carried in MPLS label stacks without any protocol identifier.
    Historic values of the IP version number [RFC791] [RFC1881] are
    therefore used to distinguish between IP and non-IP MPLS payloads.

    To disambiguate the PW from an IP flow the PW SHOULD employ either
    the generic PW control word shown in Figure 12, or an MPLS payload
    type identifier.  Note that an MPLS payload with bits 0..3 = 4 is an
    IPv4 packet and an MPLS payload with bits 0..3 = 6 is an IPv6 packet.

          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 0|          Specified by PW Encapsulation                |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

         Figure 12: Generic PW Control Word

    The PW set-up protocol determines whether a PW uses a control word.
    When a control word is used, it SHOULD have the following preferred
    form:

          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 0| Flags |FRG|  Length   | Sequence Number               |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

         Figure 13: MPLS Preferred Control Word

    The meaning of the fields of the MPLS Preferred Control Word (Figure
    13) is as follows:

        Flags (bits 4 to 7):
            These bits are available for per payload signaling.  Their
            definition is encapsulation specific.

        FRG (bits 8 and 9):
            These bits are used when fragmenting a PW payload.  Their use
            is defined in [FRAG].  When the PW is of a type that will never
            need payload fragmentation, these bits may be used as general
            purpose flags.

        Length (bits 10 to 15):
            The length field is used to determine the size of a PW
            payload that might have been padded to the minimum Ethernet
            MAC frame size during its transit across the PSN.  If the
            MPLS payload (defined as the CW + the PW payload + any
            additional PW headers is less than 46 bytes, the length MUST
            be set to the length of the MPLS payload.  If the MPLS
            payload is between 46 bytes and 63 bytes the implementation
            MAY either set to the length to the length of the MPLS
            payload, or it MAY set it to 0.  If the length of the MPLS
            payload is greater than 63 bytes the length MUST be set to 0.

        Sequence number (Bit 16 to 31):
            If the sequence number is not used, it is set to zero by
            the sender and ignored by the receiver.  Otherwise it
            specifies the sequence number of a packet.  A circular list
            of sequence numbers is used.  A sequence number takes a value
            from 1 to 65535 (2**16-1).  If the payload is an OAM packet
            the sequence number MAY be used to mark the position in the
            sequence, in which case it has the same value as the last
            data PDU sent.  The use of the sequence number is optional
            for OAM payloads.

5.4.4. MPLS Payload Identifier

    NOTE

    There are two proposals, the George Swallow proposal and the David
    Alan Proposal. We are working to merge these proposals and this text
    will then be aligned with that proposal.

    END NOTE

    If technical considerations result in a PW control word that may
    alias an IP packet, the control word SHOULD be preceded by an MPLS
    payload type identifier.

    For reference the MPLS payload type identifier [TBD] is defined as
    follows:

           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             | PPP DLL Protocol Number       |
          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
          |           As defined by PPP DLL protocol definition           |
          |                                                               |
          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

         Figure 14: MPLS Payload Type Identifier

        PPP DLL Protocol Number [16:31]:
            These numbers are assigned by IANA.

    Some PW management messages such as OAM and LSP ping may require IP
    packets to be multiplexed onto the PW. These are carried over the PW
    using the IP MPLS payload type indicator, show in Figure 15:

           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             |  IPv4 = 0x21, or IPv6 = 0x57  |
          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
          |                IP packet and management payload               |
          |                                                               |
          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

         Figure 15: MPLS Payload Type Identifier

---

From: Shahram Davari <[email-masked]>
Date: Thu, 10 Apr 2003 07:06:30 -0700

Hi Stewart,

>    alias an IP packet, the control word SHOULD be preceded by an MPLS

Does this mean that if a PW control word does not alias an IP packet,
it can't be preceded by an MPLS payload identifier? If not why?

Also we need some clarification on what does this mean in the presence of the
signaled L3PID/PW FEC? Would this PID supercede the protocol ID signaled via L3PID/PW FEC?
Also is this MPLS PID applicable only to PW? if so why not make it general for any MPLS LSP?

Yours,
-Shahram

---

From: Sasha Vainshtein <[email-masked]>
Date: Thu, 10 Apr 2003 18:16:47 +0200

Shahram,
Please see a brief comment inline.

With best regards,
                                   Sasha Vainshtein
email:     [email-masked] <mailto:[email-masked]> 
tel:       +972-3-7659993 (office)
           +972-8-9254948 (res.)
           +972-58-674833 (cell.)

> -----Original Message-----
> From: Shahram Davari [mailto:[email-masked]]
> Sent: Thursday, April 10, 2003 4:07 PM
> To: [email-masked]'; [email-masked]
> Subject: RE: [PWE3] Arch sections 5.4.3 and 5.4.4
> 
> 
> Hi Stewart,
... snipped ...
> make it general for any MPLS LSP?
I believe that the answer is in the text posted by Stewart: IPv4/IPv6
packets are carried over MPLS without MPLS PID. 
> 
> Yours,
> -Shahram
> _______________________________________________
> pwe3 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/pwe3
>

---

From: Shahram Davari <[email-masked]>
Date: Thu, 10 Apr 2003 08:22:16 -0700

>packets are carried over MPLS without MPLS PID. 

I meant for non-IP traffic, which one is valid MPLS PID or signaled PW FEC type?

-Shahram

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 10 Apr 2003 17:39:02 +0100

> it can't be preceded by an MPLS payload identifier? If not why?

That was not the intent - I will clarify. My assumption was the reverse
to yours - that any label stack could get followed by an MPLS PL ident,
and that the use of the zero niblle was a dispensation.

> signaled L3PID/PW FEC? Would this PID supercede the protocol ID signaled via L3PID/PW FEC?

Since there are people that want to multiplex IP packets on the PW, ie
to have an parallel stream on the same FEC, I guess so. You could however
argue that the set of allowable protocol types should be signalled.

> Also is this MPLS PID applicable only to PW? 
 >

No.

> if so why not make it general for any MPLS LSP?

Indeed, I am of the view that we are just the first group to have to
produce a solution to the problem rather than the last. This is being
worked in parallel by the MPLS WG.

Stewart

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 10 Apr 2003 17:49:27 +0100

> I meant for non-IP traffic, which one is valid MPLS PID or signaled PW FEC type?

Isn't it an error if they dissagree, or am I missing something?

Stewart

---

From: Shahram Davari <[email-masked]>
Date: Thu, 10 Apr 2003 09:56:09 -0700

>Isn't it an error if they dissagree, or am I missing something?

Correct. That would be an error, but I am wondering what should be
the follow up action. 

-Shahram

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 10 Apr 2003 19:00:17 +0100

Shahram Davari wrote:
>>>I meant for non-IP traffic, which one is valid MPLS PID or 
>>
>>signaled PW FEC type?
>>

I suggest discard the payload, but teardown is possible. Who needs
to specify (if anyone), us or MPLS?

Stewart

---

From: "Yaakov Stein" <[email-masked]>
Date: Tue, 15 Apr 2003 16:36:06 +0300

Stewart, 

I just got back from a few days vacation,
and see that a lot of progress has been made
on the control word issue.

I might have missed it in the torrent of emails,
but what happened regarding the RTP issue?

Was it decided to place the RTP header after the control word,
which, as Shahram pointed out, seems to be most consistent with section 5.4.2 ?

If not, how does one disambiguate when there is RTP ?

Y(J)S

---

From: "Ron Cohen" <[email-masked]>
Date: Tue, 15 Apr 2003 18:24:30 +0200

Yaakov,

My 2cents: The location of RTP header compared to the Control word
should not depend on the PSN encapsulation. Therefore, when RTP is run
over MPLS, the recommendation would be to use the MPLS PID. The MPLS PID
can be suppressed when IP identification is not needed.

Ron

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Yaakov Stein
> Sent: Tuesday, April 15, 2003 3:36 PM
> To: [email-masked]; [email-masked]
> Was it decided to place the RTP header after the control 
> word, which, as Shahram pointed out, seems to be most 
> consistent with section 5.4.2 ?
>

---

From: Sasha Vainshtein <[email-masked]>
Date: Tue, 15 Apr 2003 20:05:50 +0200

Ron, Yaakov, Stewart and all,
I concur with Ron (both with his reasoning and his conclusions).

----------------------------------------------------------------------------
--------
With best regards,
                          Sasha Vainshtein
email:   [email-masked] <mailto:[email-masked]> 
phone:  +972-3-7659993 (office)
            +972-8-9254948 (home)
            +972-58-674833 (cellular)

> From: Ron Cohen [mailto:[email-masked]]
> Sent: Tuesday, April 15, 2003 6:25 PM
> To: 'Yaakov Stein'; [email-masked]; [email-masked]

---

From: "Yaakov Stein" <[email-masked]>
Date: Wed, 16 Apr 2003 12:19:50 +0300

> over MPLS, the recommendation would be to use the MPLS PID. 
> The MPLS PID can be suppressed when IP identification is not needed.

Ron, 

I don't see your point.

We can quite consistently put the RTP 
AFTER the control word, 
whether in MPLS or IP.

Y(J)S

---

From: "Ron Cohen" <[email-masked]>
Date: Wed, 16 Apr 2003 12:44:17 +0200

Yaakov,

My point is that when you run RTP applications over IP, in all cases I'm
aware of you use IP/UDP/RTP/Payload, and you do not put any Control
Words between the UDP and the RTP headers. Any information which is
payload specific is part of the RTP payload. You can use various header
compression techniques to get read of the overhead over slow links, etc.

I'm suggesting that we should use the same layering principles over all
possible PSNs. 

Ron

> From: Yaakov Stein [mailto:[email-masked]] 
> Sent: Wednesday, April 16, 2003 11:20 AM
> To: Ron Cohen; [email-masked]; [email-masked]
> The MPLS 
> > PID can be suppressed when IP identification is not needed.
> 
> Ron, 
> 
> I don't see your point.
>

---

From: Alik Shimelmits <[email-masked]>
Date: Wed, 16 Apr 2003 12:43:47 +0200

Yaakov,

when UDP transport is used it is an advantage to put RTP 
in a place where other system may recognize/track that it is RTP. 

And, IMO, this is the only reasonable position if we want
to re-use RTP as is and not to invent something new.

Regards
	Alik

-----Original Message-----
From: Yaakov Stein [mailto:[email-masked]]
Sent: Wednesday, April 16, 2003 11:20 AM
To: Ron Cohen; [email-masked]; [email-masked]
Subject: RE: [PWE3] Arch sections 5.4.3 and 5.4.4

Ron, 

I don't see your point.

Y(J)S

---

From: Shahram Davari <[email-masked]>
Date: Wed, 16 Apr 2003 06:33:41 -0700

> Therefore, when RTP is run over MPLS, the recommendation would be to use the MPLS PID. 

So are you suggesting the MPLS PID should be set a value that is assigned to RTP?

-Shahram

---

From: "Ron Cohen" <[email-masked]>
Date: Thu, 17 Apr 2003 13:03:51 +0200

Shahram,

> > Therefore, when RTP is run over MPLS, the recommendation 
> would be to 
> > use the MPLS PID.
> 

Yes.

Ron

---

From: Akiva Sadovski <[email-masked]>
Date: Fri, 18 Apr 2003 10:30:00 +0200

Shaharam and Ron,
  Just a naive question: why can't we assign TWO MPLS PIDs:
    -- one value for PW with RTP
    -- and another for PW without RTP ?
Are we limited in the nuber of PIDs to use ?

Regards,
   Akiva Sadovski

-----Original Message-----
From: Ron Cohen
To: 'Shahram Davari'; 'Yaakov Stein'; [email-masked]; [email-masked]
Sent: 17/04/2003 13:03
Subject: RE: [PWE3] Arch sections 5.4.3 and 5.4.4

Shahram,

Yes.

Ron

---

From: "Yaakov Stein" <[email-masked]>
Date: Mon, 21 Apr 2003 18:16:40 +0300

Hi all, 

>From what Alik and Ron have said, 
RTP should ONLY be used with UDP,
and NOT with MPLS.

If this is indeed the case, 
then its use contradicts the goal
of PWs being PSN-agnostic.

As I remember it, the architecture draft
specifically depicts RTP for the MPLS case.

More importantly, if RTP is actually needed 
for the IP case (e.g. for carrying TDM or other RT traffic)
why does the need disappear for MPLS?

Y(J)S

---

From: Alik Shimelmits <[email-masked]>
Date: Mon, 21 Apr 2003 18:23:55 +0200

Yaakov,

>RTP should ONLY be used with UDP,

This is NOT what I said.

Regards
	Alik

Y(J)S

---

From: Shahram Davari <[email-masked]>
Date: Tue, 22 Apr 2003 07:17:41 -0700

I think it should be possible. 

-Shahram

>From: Akiva Sadovski [mailto:[email-masked]]
>Sent: Friday, April 18, 2003 4:30 AM
>To: 'Ron Cohen '; Shahram Davari; ''Yaakov Stein' '; 
>[email-masked] '; [email-masked] '

---

From: "Ron Cohen" <[email-masked]>
Date: Tue, 22 Apr 2003 21:04:55 +0200

Yaakov,

Let me try again.

In order to run RTP over an MPLS core, one can run:

MPLS->VC-label->RTP->CW->Data

And if IP flow identification is required (ECMP and the like) one would
use:

MPLS->VC-label->MPLS PID->RTP->CW->Data.

Hope this helps
Ron

> Sent: Monday, April 21, 2003 5:17 PM
> To: Alik Shimelmits; Ron Cohen; [email-masked]; [email-masked]

---

From: "Yaakov Stein" <[email-masked]>
Date: Thu, 24 Apr 2003 14:27:55 +0300

> And if IP flow identification is required (ECMP and the like) 
> one would use:
> 

It helps clarify what you mean.

I assume by MPLS PID you mean four bytes, 
the first of which contains the PID bits.

Y(J)S

---

From: "Ron Cohen" <[email-masked]>
Date: Thu, 24 Apr 2003 15:20:58 +0200

Yakkov,

Yes.

Ron

---

From: Sasha Vainshtein <[email-masked]>
Date: Tue, 29 Apr 2003 17:03:39 +0200

Stewart,
I think that Ron Cohen has answered this question at least twice on this
mailing list: the RTP header, if used, MUST immediately follow the
demultiplexor (whatever it happens to be) and MUST be immediately followed
by the CW. There are at least two valid reasons for that:
1. This coresponds to the recommendations on the RTP payload formats with
the CW acting as the "payload header" in terms of Section 4.1 of RFC 2736.
And, if IP/UDP is used as the Transport/demultiplexing, it corresponds to
the common usage of RTP (including RTP header compression etc.)
2. This greatly simplifies implementations that allow inclusion and
suppression of RTP header. E.g., the value of the structure pointer (or the
rules of its application) in draft-ietf-pwe3-sonet-01.txt will not depend on
the presence or absense of the RTP header in the encapsulation.

Hopefully this note clarifies the issue.

> From: Stewart Bryant [mailto:[email-masked]]
> Sent: Tuesday, April 29, 2003 1:39 PM
> To: [email-masked]
> Subject: Re: [PWE3] Arch sections 5.4.3 and 5.4.4
> 
> 
> I cut and paste from the wrong version of the base document
> the current version is actually:
> 
> +---------------------+
> |      Payload        |
> /=====================\\
> H Payload Convergence H-----+
> H---------------------H     |
> H       Timing        H------------------------+
> H---------------------H     |                  |
> H     Sequencing      H-----|                  |
> \\=====================/     |                  |
> |  PW Demultiplexer   |---+ |                  v
> +---------------------+   | |  +--------------------------------+
> |  PSN Convergence    |-----|  .                                .
> +---------------------+   | |  .              RTP               .
> |        PSN          |-+ | |  |                                |
> +---------------------+ | | |  +--------------------------------+
> |      Data-link      | | | +->| Flags, Frag, Len, Seq #, etc   |
> +---------------------+ | |    +--------------------------------+
> |       Physical      | | |    |    MPLS Payl'd Type Indent     |
> +---------------------+ | |    +--------------------------------+
>                          | +--->|           PW Label             |
>                          |      +--------------------------------+
>                          +----->| Outer Label or MPLS-in-IP encap|
>                                 +--------------------------------+
> 
> but the question remains, should we swap RTP and the CW?
> 
> Stewart
> 
> 
> 
> 
> Stewart Bryant wrote:
> > 
> > Is the WG concensus:
> > 
> >   +---------------------+
> >   |      Payload        |
> >   /=====================\
> >   H Payload Convergence H-----+
> >   H---------------------H     |
> >   H       Timing        H------------------------+
> >   H---------------------H     |                  |
> >   H     Sequencing      H-----|                  |
> >   \=====================/     |                  |
> >   |  PW Demultiplexer   |---+ |                  v
> >   +---------------------+   | |  +--------------------------------+
> >   |  PSN Convergence    |-----|  .                                .
> >   +---------------------+   | |  .              RTP               .
> >   |        PSN          |-+ | |  |                                |
> >   +---------------------+ | | |  +--------------------------------+
> >   |    MAC/Data-link    | | | +->| Flags, Frag, Len, Seq #, etc   |
> >   +---------------------+ | |    +--------------------------------+
> >   |       Physical      | | +--->|           PW Label             |
> >   +---------------------+ |      +--------------------------------+
> >                           +----->| Outer Label or MPLS-in-IP encap|
> >                                  +--------------------------------+
> > 
> > 
> > 
> > Figure 11: PWE3 over an MPLS PSN using a control word
> > 
> > Which is what the current text says, or is it:
> > 
> >   +---------------------+
> >   |      Payload        |
> >   /=====================\
> >   H Payload Convergence H-----+
> >   H---------------------H     |
> >   H       Timing        H-------+
> >   H---------------------H     | |
> >   H     Sequencing      H-----+ |
> >   \=====================/     | |
> >   |  PW Demultiplexer   |---+ | |
> >   +---------------------+   | | |  
> +--------------------------------+
> >   |  PSN Convergence    |-----+--->| Flags, Frag, Len, Seq 
> #, etc   |
> >   +---------------------+   |   |  
> +--------------------------------+
> >   |        PSN          |-+ |   |  |                        
>         |
> >   +---------------------+ | |   +->.              RTP       
>         .
> >   |    MAC/Data-link    | | |      |                        
>         |
> >   +---------------------+ | |      
> +--------------------------------+
> >   |       Physical      | | +----->|           PW Label     
>         |
> >   +---------------------+ |        
> +--------------------------------+
> >                           +------->| Outer Label or 
> MPLS-in-IP encap|
> >                                    
> +--------------------------------+
> > 
> > Figure 11: PWE3 over an MPLS PSN using a control word
> > 
> > 
> > Which is what this thread seems to conclude?
> > 
> > Thanks
> > 
> > Stewart
> > 
> > 
> > 
> > Ron Cohen wrote:
> > 
> >> Yaakov,
> >>
> >> Let me try again.
> >>
> Behalf Of 
> >>> Yaakov Stein
> >>> If this is indeed the case, then its use contradicts the goal
> >>> More importantly, if RTP is actually needed for the IP 
> case (e.g. for 
> >>> carrying TDM or other RT traffic)

---

From: "Andrew G. Malis" <[email-masked]>
Date: Tue, 29 Apr 2003 13:38:43 -0400

I would like to support Sasha's reply.  RTP should immediately precede, not 
follow, the CW.

Cheers,
Andy

-------

---

From: "Ron Cohen" <[email-masked]>
Date: Tue, 29 Apr 2003 21:37:26 +0200

Stewart,

I'm with Andy and Sasha. 

I do have a remark on the PSN convergence layer location. I view the
MPLS PID as a PSN convergence layer for MPLS. The PW Demultiplexing
layer in MPLS is just another label. Therefore the right layering would
be:

PSN > PW demultiplexing > PSN convergence > RTP > CW > Payload

Which would work nicely with IP PSN:

IP > UDP > RTP > CW > Payload

And with MPLS PSN:

MPLS > VC-label > MPLS PID > RTP > CW > Payload.

Where the RTP and MPLS PID are optional.

Thanks
Ron

> Behalf Of Stewart Bryant
> >>> If this is indeed the case, then its use contradicts the 
> goal of PWs 
> >>> being PSN-agnostic.
> >>>
> >>> More importantly, if RTP is actually needed for the IP case (e.g. 
> >>> for

---

From: Akiva Sadovski <[email-masked]>
Date: Wed, 30 Apr 2003 09:36:36 +0200

Stewart, Ron and all
  ... and i'm with Ron. Can we swap PW Demultiplexer and PSN Convergence
layers in PW layering diagram ? We also can change the PW Demultiplexer
layer name to Demultiplexer layer for those who'd like to deal with PW only
"after" handling all PSN issues. 

Regards,
  Akiva Sadovski

> Sent: Tuesday, April 29, 2003 9:37 PM
> > >> And if IP flow identification is required (ECMP and the 
> like) one 
> > >> would
> > >> use:
> > >>
> case (e.g.

---

From: Alik Shimelmits <[email-masked]>
Date: Wed, 30 Apr 2003 09:57:14 +0200

I support Ron's diagram
	Alik

-----Original Message-----
From: Ron Cohen [mailto:[email-masked]]
Sent: Wednesday, April 30, 2003 9:56 AM
To: [email-masked]; [email-masked]
Cc: 'Yaakov Stein'; Alik Shimelmits
Subject: RE: [PWE3] Arch sections 5.4.3 and 5.4.4

Stewart,

In ASCII Art the layering should look like:

  +---------------------+
  |      Payload        |
  /=====================\
  H Payload Convergence H-------+
  H---------------------H       |
  H       Timing        H---------+
  H---------------------H       | |
  H     Sequencing      H-------+ |
  \=====================/       | |
  |  PSN Convergence    |-----+ | |
  +---------------------+     | | |  +--------------------------------+
  |  PW Demultiplexer   |---+ | +--->| Flags, Frag, Len, Seq #, etc   |
  +---------------------+   | |   |  +--------------------------------+
  |        PSN          |-+ | |   +->|            RTP                 |
  +---------------------+ | | |      +--------------------------------+
  |    MAC/Data-link    | | | +----->|           MPLS PID             |
  +---------------------+ | |        +--------------------------------+
  |       Physical      | | +------->|           PW Label             |
  +---------------------+ |          +--------------------------------+
                          +--------->| Outer Label or MPLS-in-IP encap|
                                     +--------------------------------+

And similar for IP.

Ron

> Sent: Tuesday, April 29, 2003 1:32 PM
> To: [email-masked]
> Cc: Ron Cohen; 'Yaakov Stein'; 'Alik Shimelmits'
>    |  PSN Convergence    |-----+--->| Flags, Frag, Len, Seq #, etc   |
>    +---------------------+ | |   +->.              RTP               .
>    |    MAC/Data-link    | | |      |                                |
>    |       Physical      | | +----->|           PW Label             |
>                            +------->| Outer Label or MPLS-in-IP encap|
> >>From: [email-masked] [mailto:[email-masked]] On Behalf Of 
> >>Yaakov Stein
> >>for the IP case (e.g. for carrying TDM or other RT traffic) why does

> >>the need disappear for MPLS?
> >>
> >>
> >>Y(J)S

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 30 Apr 2003 10:20:52 +0100

OK I will look at moving that text

Stewart

---

From: "Yaakov Stein" <[email-masked]>
Date: Wed, 30 Apr 2003 14:48:41 +0300

Sasha, Ron, Stewart

> I think that Ron Cohen has answered this question at least 
> twice on this mailing list: the RTP header, if used, 
> MUST immediately follow the demultiplexor 
> (whatever it happens to be) and MUST be 
> immediately followed by the CW.

I think that Ron has voiced AN opinion
at least twice on the list, 
and I think that Sasha has as well.

However, I do not believe that this is the BEST
or even the correct solution.

The logical way to do it is
to ALWAYS have the CW first.

> 1. This coresponds to the recommendations on the RTP payload 
> formats with the CW acting as the "payload header" in 
> terms of Section 4.1 of RFC 2736.

As I have already stated in the past,
this in no way contradicts RFC 2736,
it just does not consider PWs to be
a type of RTP, rather RTP to be
a tool that CAN be used with PWs.

By using this method a SINGLE mechanism
which is in common to ALL PWs which 
do not omit the CW can be used.
This mechanism can include the four-bit PID,
if this is the way we decide to go.

All other methods, e.g. Ron's suggestion
that we should add a full 32 bit PID
before the RTP and then a CW after the RTP,
are either BW wasteful, or inconsistent
with the other PW encaps, or both.

Y(J)S

---

From: "Yaakov Stein" <[email-masked]>
Date: Wed, 30 Apr 2003 14:56:37 +0300

> Ron's got it perfect.

Unfortunately,  just as the last time I brought
the CW inconsistencies up, no-one is thinking
of edge devices that have to handle multiple PW types.

Say I have a PWE chip that may receive atm-encap or tdm-encap-with-RTP, 
it would either have to have a very complex algorithm
(which I am not even sure exists) or be informed of an awful lot of 
network state, in order to function.

Let's please keep the architecture consistent.
After the MPLS labels comes the CW.
It can be used for disambiguation if needed.
After it comes all the PW-type related details,
which include RTP (which is simply a submode of the
real-time PW type).

By separating the CW from the labels
you are making the CW part of a OSI layer
which is higher than the RTP,
in addition to implying a client-server relationship
between the PW and RTP
which is exactly the inverse of what should exist.

Y(J)S

---

From: Sasha Vainshtein <[email-masked]>
Date: Wed, 30 Apr 2003 15:05:39 +0200

Yaakov and all,
Please see some comments inline.

With best regards,
                                   Sasha Vainshtein

> Sent: Wednesday, April 30, 2003 1:49 PM
> To: Sasha Vainshtein; [email-masked]
> Cc: [email-masked]; Ron Cohen (E-mail)
... snipped ...
> to ALWAYS have the CW first.
I am not sure I understand your logic. Please see some
details below.
> a tool that CAN be used with PWs.
The PWE3 Charter states that: 

<quote>
  PWE3 will use RTP where necessary to perform clock recovery and
  other real-time signaling functions.  This work will be
  coordinated with the AVT WG and payloads will follow RFC 2736.
<end quote> 

I think that the word "payload" here refers to the PW payload
because the PWE3 WG does not deal with any other 
payload - Stewart/Danny? 

And if the PW payload is required to follow RFC 2736, 
then the only logical place of the CW is to treat it
as "additional header information to be carried in 
addition to that included in the fixed RTP packet
header" (above-mentioned RFC, Section 4.1). FYI, the
next sentence is "The recommended way of conveying 
this information is in the payload section of the 
packet." And this exactly matches Ron's proposal.
> if this is the way we decide to go.
I do not understand what kind of consitency with
"other PW encaps" is missing. The situation when
the CW immediately precedes the payload is preserved
for all kinds of the PE encapsulations. 
And if you think that RTP is BW-wasteful, you MAY omit it
without breaking this consistency.
... snipped to the end ...

---

From: Sasha Vainshtein <[email-masked]>
Date: Wed, 30 Apr 2003 15:35:13 +0200

Yaakov and all:

Just for the reference: Axerra develops, produces and sells an edge device 
that handles multiple PW types. Some of the supported PWs use RTP and 
some don't. And, so far, we have not experienced any problem due to
different
encapsulations. 

I do not see why supporting multiple encapsulations in a "PWE3 chip" 
would be different in any way.  Granted, I am not an ASIC expert. 
But Ron and Tim are. 

IMO,  an attempt to insert a (possibly suppressed)
RTP header between the CW and the payload would
 make such a chip really complicated.

With best regards,
                                   Sasha Vainshtein

> Sent: Wednesday, April 30, 2003 1:57 PM
> To: Andrew G. Malis; [email-masked]
> Cc: [email-masked]; Ron Cohen

---

From: "Andrew G. Malis" <[email-masked]>
Date: Wed, 30 Apr 2003 09:23:12 -0400

I agree with Sasha's points.

In addition, section 4.4 in draft-ietf-pwe3-sonet-01.txt (compare figures 4 
and 5) is a good illustration of why it makes sense to have the CW after 
the RTP header. As it says in the draft, the choice to utilize RTP header 
suppression may be statically configured using [CEM-MIB], or signaled using 
a PW maintenance protocol such as [PWE3-CONTROL].

This is the way it's been since RTP was first introduced into the SONET draft.

Thanks,
Andy

---------