Subject: TDM/SONET & RTP

From: Danny McPherson <[email-masked]>
Date: Fri, 16 May 2003 17:50:39 -0600

The following is an attempt by Stewart and I to generate one final round of
discussions regarding this topic (and another in a following email) and seek
some semblance of consensus from the WG.  If you've got comments,
clarifications or additions to the following issue summary please provide
them to the WG within the next week as we need to move forward ASAP.

And whether we actively engage in any discussion or not, we are listening.

Thanks,

Stewart/Danny

=============

There has been considerable discussion about the design of
the TDM/SONET PWE3 headers, and three candidates solutions
are on the table:

1)   Use the same CW as is used for the packet encapsulations
     and extend this with a second longword that contains any
     necessary pointer information. This leads to the following
     layering:

     MPLS PW Label
     PWE3 Generic CW
     PWE3 CW extension for pointer (if needed)
     RTP (if needed)

2)  Use a specialized CW (the CEP header) rather than the PW
    generic CW, allowing all necessary information to be compressed
    into 4 bytes. It results in the following layering:

    MPLS PW Label
    MPLS PID or convergence layer to discriminate from IP
    RTP (if needed)
    CEP header

    There is some discussion as to whether the PID is a PID or
    a convergence layer. Please can we discuss that issue on the
    thread set up for that purpose.

3)  Used a specialized CW (the CEP header) rather than the PW
    generic CW, allowing all necessary information to be compressed
    into 4 bytes. It results in the following layers:

    MPLS PW Label
    MPLS PID or convergence layer to discriminate from IP
    CEP header
    RTP (if needed)

Method 1 is highly controversial, but conforms to the PWE3
architecture. It has the technical disadvantage that it
extends the minimum packet size in a non-ECMP network.
It has the practical disadvantage that it is not consistent
with any of the systems that are currently deployed / in
the late stages of design.

Method 2 has a smaller minimum packet size than Method 1
in a non-ECMP network, and the RTP/CEP layering is
identical for IP and MPLS networks. It does not
conform to the design of the CW used by most of the other
payloads. In strict architectural terms, the MPLS PID if
present should specify an RTP payload (if present), and
the CEP header should be specified as an RTP payload.
However since most experts in this area expect that the
majority of deployments will not use RTP, we end up with
two MPLS PID values and effectively two parallel
definitions of this PWE3 encapsulation.

Method 3 was the method originally sketched out in the
PWE3 architecture draft. This has the disadvantage
that stack would not look the same on an IP PSN
and does not strictly conform to the RTP layering
model, but does define the payload as PWE3 at an
early stage. If it is assumed that RTP will not normally
be present, then the stack is more compact than
Method 1 on a non-ECMP network.

---

From: "Ron Cohen" <[email-masked]>
Date: Sat, 17 May 2003 18:28:28 +0200

Danny,

My vote is for option 2.

Please see inline

Ron

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Danny McPherson
> Sent: Saturday, May 17, 2003 1:51 AM
> To: [email-masked]
> Subject: [PWE3] TDM/SONET & RTP
> 
> 
> The following is an attempt by Stewart and I to generate one
> final round of discussions regarding this topic (and another 
> in a following email) and seek some semblance of consensus 
> from the WG.  If you've got comments, clarifications or 
> additions to the following issue summary please provide them 
> to the WG within the next week as we need to move forward ASAP.
> 
> There has been considerable discussion about the design of the 
> TDM/SONET PWE3 headers, and three candidates solutions are on the 
> table:
> 
> extends the minimum packet size in a non-ECMP network. It has 
> the practical disadvantage that it is not consistent with any 
> of the systems that are currently deployed / in the late 
> stages of design.
> 

As well as having the RTP layering problem: CW over RTP for IP, RTP over
CW for MPLS.

> payloads. 

CW for Layer-1 and Layer-2 should look different. They have different
requirements.

> In strict architectural terms, the MPLS PID if 
> present should specify an RTP payload (if present), and the 
> CEP header should be specified as an RTP payload. However 
> since most experts in this area expect that the majority of 
> deployments will not use RTP, we end up with two MPLS PID 
> values and effectively two parallel definitions of this PWE3 
> encapsulation.

By nature, a PID value is different depending on the layer above. The
layering definition is identical, the design is identical, and the
packet format is self describing. 

> _______________________________________________
> pwe3 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/pwe3
>

---

From: "Yaakov Stein" <[email-masked]>
Date: Sun, 18 May 2003 08:55:46 +0300

Stewart/Danny

> the late stages of design.

I disagree with the reasoning regarding the disadvantages.

Method 1 does NOT extend the minimum packet size
any more than methods 2 and 3.
When the extension is NOT needed, we have only the
standard generic PWE CW. When it IS needed, we indeed
add an additional 32 bits, but the other two methods add an MPLS PID
of 32 bits as well. Hence, there is NO size disadvantage in relation
to the other two methods.

The practical disadvantage is somewhat more worrying.
However, I believe that ANY change at this point will
require SOME re-engineering to those systems that 
did not reserve the first nibble after the PW label
(something we have been warning about for a long time).

So I vote for method 1 - the generic PWE method.

If this is deemed impractical because of pre-standard
implementations being too hard to rework,
then I  vote for method 3, where the RTP is considered
a higher layer than the PW. 

However, I doubt that for the SONET case anyone cares
about the difference between 2 and 3, since RTP is NOT used.
So we return to the low-rate TDM case.
Returning to the argument about re-engineering,
the dominant low-rate TDM implementation in the marketplace
uses the standard PWE CW, and not the CEP header.
I strenuously argue that this should stay this way.
With multiple interoperable implementations in the field,
any change from the standard CW (even were such a change
to be advisable) would be too costly at this point. 

Y(J)S

---

From: David Zelig <[email-masked]>
Date: Sun, 18 May 2003 11:38:28 +0200

Danny,

I think correct layering in this case should be based on functionality, not
order of fields in the header. RTP and CW are the same layer in the sense
that they start and terminate together.

>From practical point of view, both  methods #1 and #3 require different
pointer interpretation with/without RTP, so CW processing will be dependent
on the RTP in these cases, - while keeping correct "layered" order in fields
ordering, it is wrong layered dependency in practice. 

Method #2 is the most practical, same ordering for IP PSN - we should go
this way. 

Having two MPLS PIDs value for this purpose is not really an issue here - if
the packet needs to be self-describing (and it should), having the CW before
the RTP won't help you here even in option #1 and #3.

David

> From: Danny McPherson [mailto:[email-masked]]

---

From: "Yaakov Stein" <[email-masked]>
Date: Sun, 18 May 2003 13:17:12 +0300

> I think correct layering in this case should be based on 
> functionality, not order of fields in the header. 
> RTP and CW are the same layer 
> in the sense that they start and terminate together.

Good point.

However, from the PWE point of view, 
the CW should be a "lower" layer 
since the PW architecture defines it (as an optional function);
it is not the case that RTP defines PWs as an option of its payloads.
Hence the RTP header should be closer to the payload
and the CW closer to the MPLS labels. 

> 
> From practical point of view, both  methods #1 and #3 require 
> different pointer interpretation with/without RTP, so CW processing 
> will be dependent on the RTP in these cases, - while keeping correct "layered" 
> order in fields ordering, it is wrong layered dependency in practice. 

We can decide on the meaning of the point from which the pointer references 
however we want.

> Method #2 is the most practical, same ordering for IP PSN - 
> we should go this way. 

Method 1 can also be precisely the same for IP and MPLS,
by defining an IP-Type for PWs (or perhaps two - for w/ and w/o RTP).

For IP:                                     For MPLS:
     L2                                       L2
     IP with IP-type=PW              outer label(s)
     UDP                                    inner label
     CW                                     CW
     [RTP]                                  [RTP]
     Payload                               payload

> Having two MPLS PIDs value for this purpose is not really an 
> issue here - if the packet needs to be self-describing (and it should), 
> having the CW before the RTP won't help you here even in option #1 and #3.

See above.

BTW, we never defined a static RTP-type for PWs either;
so the "change in view" doesn't cost anything.

Y(J)S

---

From: Sasha Vainshtein <[email-masked]>
Date: Sun, 18 May 2003 13:28:33 +0200

Danny and all,
I vote for Option 2 below with the following clarification:

Encapsulation over IP looks like following:

   Demultiplexer (e.g., L2TPv3 header or UDP header)
   RTP (if needed)
   CEP header

In other words, there is no need for MPLS PID/convergence layer
for TDM/SONET traffic carried over an IP PSN.

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

> final round of

---

From: Sasha Vainshtein <[email-masked]>
Date: Sun, 18 May 2003 14:28:07 +0200

Yaakov and all,
Please see a brief comment inline.

With best regards,
                                   Sasha Vainshtein

> From: Yaakov Stein [mailto:[email-masked]]
> Sent: Sunday, May 18, 2003 12:17 PM
> To: David Zelig; Danny McPherson; [email-masked]
> Subject: RE: [PWE3] TDM/SONET & RTP
> 
IP Type today defines the type of protocol used for PW demultiplexing,
e.g., L2TPv3 or (in case of TDM/SONET) UDP. Your proposal, if accepted,
would effectively kill this.
... snipped to the end ...

---

From: "Yaakov Stein" <[email-masked]>
Date: Sun, 18 May 2003 16:05:25 +0300

> e.g., L2TPv3 or (in case of TDM/SONET) UDP. Your proposal, if 
> accepted, would effectively kill this.

I agree that this is the messy solution,
which would require many types to be defined.

I would much prefer using an IANA accepted UDP port number
(which, as you now, is what we did for TDMoIP).

Then UDP is clean, but we have a problem for L2TP.

Y(J)S

---

From: [email-masked]
Date: Mon, 19 May 2003 09:47:25 +0100

I'm curious to know why the stack in option 2:

    MPLS PW Label
    RTP 
    CEP header

requires the MPLS PID to discriminate RTP from IP (4 or 6).

Looking at the RTP header (from RFC 1889):

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |V=2|P|X|  CC   |M|     PT      |       sequence number         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

assuming that TDM PWs will not use either padding (P=0) or header 
extension (X=0), then the first nibble will be 1000. This does not 
conflict with either IPv4 or IPv6. Even if the RTP version incremented, or 
the padding/extensions were used, it could not conflict with IP - at least 
not until we are on IPv8 or higher, which judging by the amount of time 
its taken to establish IPv6 will be a long way ahead.
Is there a reason why that first nibble must be 0000, rather than 1000 (or 
any other value that is not 0100 or 0110)?

Of course, if the RTP was removed, and the underlying control word used 
the CEP format, then there is an issue. Therefore the CW should either use 
the generic format with an extension, or an MPLS PID. The net result is 
the same, a 64 bit header, although at least if the generic CW is used, 
then should the extension not be required, the size can be reduced.

Therefore my vote would be for the order of option 2 (for the reasons 
David Zelig expressed about the pointer processing being dependent on RTP 
presence or not if the CW precedes RTP), but with a generic CW and 
extension for pointer if required (i.e. option 1 CW).

Tim

Danny McPherson <[email-masked]>
Sent by: [email-masked]
17-May-2003 12:50 AM

        To:     <[email-masked]>
        cc: 

The following is an attempt by Stewart and I to generate one final round 
of
discussions regarding this topic (and another in a following email) and 
seek
some semblance of consensus from the WG.  If you've got comments,
clarifications or additions to the following issue summary please provide
them to the WG within the next week as we need to move forward ASAP.

Thanks,

Stewart/Danny

=============

     MPLS PW Label
     PWE3 Generic CW

    MPLS PW Label

    MPLS PW Label

---

From: "Ron Cohen" <[email-masked]>
Date: Mon, 19 May 2003 13:46:31 +0200

Tim,

> requires the MPLS PID to discriminate RTP from IP (4 or 6).

1. Because the 4 bits are used as PID, and RTP would exhaust 1-5 other
values from the non-allocated pool, assuming the version is fixed. Its
not only IPv4/v6 discrimination. 
2. Assumption on the RTP header usage (e.g. P=X=0) are ok only for the
short term, but are not a good idea in the long run. Layers should be
decoupled, to allow someone developing over RTP not to worry to much
over the lower layers restrictions.

Ron  

> final round 
> some semblance of consensus from the WG.  If you've got 
> comments, clarifications or additions to the following issue 
> summary please provide them to the WG within the next week as 
> we need to move forward ASAP.
>

---

From: [email-masked]
Date: Mon, 19 May 2003 12:02:48 +0100

Yaakov, 

Looking at draft-anavi-tdmoip-05 (March '03), the first nibble of your 
control word is actually the FORMID, not 0000.  At present this can take on the following values: 0, 8, 9, 12, 13, 14, 
and 15. 

Based on Stewart's last email therefore, there is a theoretical (albeit 
probably very small) chance that a draft-anavi implementation could be 
mistaken for one of these other IP types, e.g. PIP or TUBA. I agree that 
from a practical point of view, the range of FORMID values may run very 
little chance of causing a conflict, but it is certainly not a standard 
PWE CW (even the sequence number is different). 

Also, draft-anavi places the RTP header before the CW, not after (although 
as you frequently point out you never actually use RTP). Presumably if you 
did use it in an MPLS network, it could not be discriminated from 
FORMID=8.

You conclude your argument for option 1 by referring to the number of 
field deployments. 

> to be advisable) would be too costly at this point. 

So, are you going to change your own implementation to meet the rules you 
are so keen to impose on everyone else?

Tim

"Yaakov Stein" <[email-masked]>
Sent by: [email-masked]
18-May-2003 06:55 AM

        To:     <[email-masked]>
        cc: 

Stewart/Danny

Y(J)S

---

From: "Yaakov Stein" <[email-masked]>
Date: Mon, 19 May 2003 16:30:57 +0300

Tim, 

> Looking at draft-anavi-tdmoip-05 (March '03), the first 
> nibble of your control word is actually the FORMID, not 0000.  At present 
> this can take on the following values: 0, 8, 9, 12, 13, 14, 
> and 15. 
> 
> Based on Stewart's last email therefore, there is a 
> theoretical (albeit probably very small) chance that a draft-anavi implementation 
> could be mistaken for one of these other IP types, e.g. PIP or TUBA. I 
> agree that from a practical point of view, the range of FORMID values 
> may run very little chance of causing a conflict, but it is certainly not 
> a standard PWE CW (even the sequence number is different). 

I hadn't known about PIP and TUBA, and will look into it.

> Also, draft-anavi places the RTP header before the CW, not 
> after (although as you frequently point out you never actually use RTP). 
> Presumably if you did use it in an MPLS network, it could not be discriminated from 
> FORMID=8.
> 
> So, are you going to change your own implementation to meet 
> the rules you are so keen to impose on everyone else?

Absolutely.  I have already made the change in my documentation,
and the next revision of draft-anavi will reflect this, 
unless the WG decides otherwise.

Y(J)S