Subject: [PWE3] Demultiplexing of VCCV packets in SAToP and CESoPSN (was: RE: [PW E3] RE: draft-ietf-pwe3-cesopsn-03.txt and draft-ietf-pwe3 -satop-02.t xt )

From: Sasha Vainshtein <[email-masked]>
Date: Wed, 27 Jul 2005 22:28:55 +0300

Skip and all,
I think that I now understand your problem. 
Allow me to re-state it in my own words first, and then I shall propose a
solution for your consideration:

1. There is a well-understood need to use VCCV with SAToP and CESoPSN 
    regardless of the PSN type. There is no problem with MPLS, but both
UDP/IP
    and L2TPv3/IP seem problematic.

2. Any solution for L2TPv3 requires modification of the current VCCV draft
because
    neither SAToP not CESoPSN use the default L2-specific sublayer currently
required.

3. The solution should not look beyond the first nibble after the PSN header
and demultiplexor 
    (whatever these happen to be) to avoid unncessary complications for some
HW architectures.

4. MPLS-like identification of VCCV packets based on '0001'in the first
nibble after the seems acceptable.

5. There is no need to carry RTP headers in the VCCV packets even if the
data packets carry them.

6. Whatever numbering scheme (if any)is used for the VCCV packets, it MUST
NOT interfere with
    that used for the SAToP/CESoPSN data packets (because TDM PWs must
compencate  the exact
    number of lost data).

7. A solution that equally suits L2TPv3/IPand UDP/IP is strongly preferable.

If you agree with this re-definition of the problem and assumptions, a
solution can be really simple:

1. VCCV packets for SAToP/CESoPSN:
   - do NOT include RTP header even if the data packets use it
   - are ALWAYS identified by carrying '0001' in the first nibble after the
PSN header and
     demultiplexor
2. The SATop and CESoPSN data packets are identified by carrying the
following value 
    in the first nibble after the PSN header and  demultiplexor:
    - '0000' in the case of MPLS PSN (with and without the RTP header)
    -  '0000' also in the case of IP PSN without RTP header
    -  '0100' in the same nibble in the case of IP PSN with RTP header.

Did I miss something substantial?

Your feedback is more than welcome. 

One more note (not related to VCCV, but related to CW/RTP order): 
SAToP and CESoPSN sequencing mechanisms do not depend on 
usage/non-usage of RTP header and on its postion wrt the CW since 
a valid sequence number shall always be found in the same position 
relative to the PSN header and demultiplexor. This is guaranteed by 
the requirement to keep to sequence numbers - in the CW and in the 
RTP header - equal if the RTP header is used.

Hopefully this also helps.

Regards,
				Sasha

> -----Original Message-----
> From: Skip Booth [mailto:[email-masked]]
> Sent: Wednesday, July 27, 2005 6:38 PM
> To: Sasha Vainshtein
> Cc: Bill Storer (bstorer); [email-masked]; Yaakov Stein
> Subject: Re: [PWE3] RE: draft-ietf-pwe3-cesopsn-03.txt and 
> draft-ietf-pwe3 -satop-02.t xt
> 
> 
> Sasha, thanks for your response.  See inline...
> 
> Sasha Vainshtein wrote:
> > Skip and all,
> > Please note that SAToP and CESoPSN do NOT use the L2TPv3-specific
> > L2-sublayer
> > when operated over L2TPv3. Instead, they use the same 
> MPLS-compatible
> > control
> > word. 
> > 
> > draft-ietf-pwe3-vccv-05 explicit states in Section 7 that:
> > 
> > <quote>
> >     In order to carry VCCV messages within an L2TPv3 session data 
> >     packet, the default L2-Specific Sublayer MUST be present. 
> > <end quote>
> 
> I've spoken with Tom about this and we agree the text needs 
> to be modified.  It
> should state something along the following lines:
> 
> "In order to carry VCCV messages within an L2TPv3 session 
> data packet, either
> the default L2-specific Sublayer must be present *OR* the 
> non-default L2
> sublayer MUST define a demultiplexing VCCV bit."
> 
> The point is VCCV is a general PWE3 requirement for both MPLS 
> and L2TPv3
> pseudowires and should not be precluded by using the 
> non-default L2 sublayer.
> 
> > 
> > On the other hand, it is always possible to use '0001' in 
> the first nibble
> > of
> > the CW to distinguish VCCV packets from the SAToP/CESoPSN 
> data packets.
> 
> Sure - and that's what I would expect to happen here.  L2TPv3 
> can handle this
> just fine.  I'd rather not have to look past the RTP header 
> to glean this though
> as that at a minimum could be inefficient and maybe 
> impossible depending on how
> the HW is built.
> 
> Also, I'm not sure what format the RTP header should look for 
> VCCV packets in
> the L2TPv3 mode.  Given that VCCV is locally 
> generated/destined packet, I don't
> think they should sequenced/timestamped with the rest of the 
> circuit data.
> 
> The other issue here is whether a raw UDP mode needs to 
> support VCCV and if so,
> then both L2TPv3 and UDP modes have the same problem.
> 
> > 
> > Hence I think that the issue of order between RTP and CW 
> for L2TPv3 is
> > orthogonal to usage of VCCV with SAToP/CESoPSN.
> 
> Clearly I don't see these as orthogonal issues, but maybe I'm 
> still missing
> something ;)
> 
> Cheers,
> -Skip
> 
> > 
> > With best regards,
> > 				Sasha
> > 
> > 
> > 
> > 
> > 
> > 
> >>-----Original Message-----
> >>From: Skip Booth [mailto:[email-masked]]
> >>Sent: Wednesday, July 27, 2005 4:55 PM
> >>To: Yaakov Stein
> >>Cc: Sasha Vainshtein; Bill Storer (bstorer); [email-masked]
> >>Subject: Re: [PWE3] RE: draft-ietf-pwe3-cesopsn-03.txt 
> >>anddraft-ietf-pwe3-satop-02.t xt
> >>
> >>
> >>
> >>
> >>Yaakov Stein wrote:
> >>
> >>>Sasha and Bill, 
> >>>
> >>>I would like to add another reason for this strange situation. 
> >>>
> >>>>From a layering point of view the PWE CW is the 
> >>>belongs right after the MPLS label stack,'
> >>>and under it there can be further service specific
> >>>headers that modify the PW charactersitics, e.g. RTP.
> >>>
> >>>As Sasha said the CW being immediately after
> >>>the MPLS stack also has specific consequences,
> >>>but this is also the correct place for it.
> >>>
> >>>However, for the UDP/IP case,
> >>>there is a long history of RTP being the way it is
> >>>and we should not try to change this.
> >>
> >>That's certainly true for the UDP/IP case but not for the 
> >>L2TPv3 case.  The
> >>control word should immediately follow the L2TPv3 session 
> >>ID/cookie header and
> >>the RTP header should follow the CW.  Note only will this 
> >>allow for consistent
> >>PW encapsulation processing for L2TPv3 and MPLS (as well as 
> >>the actual CEM
> >>processing), but it will also allow for the use of VCCV over 
> >>L2TPv3 in CEM
> >>applications.  We need to ensure that VCCV packets can be 
> >>demultiplexed from
> >>data-packets as part of the PW decapsulation processing.  
> >>Either that or we need
> >>to define what the RTP header format should look like for 
> >>VCCV packets which
> >>AFAIK hasn't been done.
> >>
> >>Cheers,
> >>-Skip
> >>
> >>
> >>>Y(J)S
> >>>
> >>>_______________________________________________
> >>>pwe3 mailing list
> >>>[email-masked]
> >>>https://www1.ietf.org/mailman/listinfo/pwe3
> >>
> 

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

---

From: Skip Booth <[email-masked]>
Date: Wed, 27 Jul 2005 16:16:54 -0400

See inline....

> 7. A solution that equally suits L2TPv3/IPand UDP/IP is strongly preferable.

Fantastic summary!!! Thanks Sasha.

> Did I miss something substantial?

I don't think so and I agree that this is certainly one way to solve this
problem.  If I understand what you are proposing, the underlying assumption is
that a value of 0001 in the first nibble is mutually exclusive with the fixed
RTP header.  Is the first nibble of the RTP header always guarenteed to not be
0001?  Given the fixed header format defined in RFC 3550 it would appear so, i.e:

>From RFC3550:
-----------------
 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         |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

version (V): 2 bits
      This field identifies the version of RTP.  The version defined by
      this specification is two (2).  (The value 1 is used by the first
      draft version of RTP and the value 0 is used by the protocol
      initially implemented in the "vat" audio tool.)

padding (P): 1 bit
      If the padding bit is set, the packet contains one or more
      additional padding octets at the end which are not part of the
      payload.  The last octet of the padding contains a count of how
      many padding octets should be ignored, including itself.  Padding
      may be needed by some encryption algorithms with fixed block sizes
      or for carrying several RTP packets in a lower-layer protocol data
      unit.

extension (X): 1 bit
      If the extension bit is set, the fixed header MUST be followed by
      exactly one header extension, with a format defined in Section
      5.3.1.
------------------

Since the SATOP/CEMoP drafts call for RTP header as defined in RFC3550, then the
version will be 2 and this is mutually exclusive with 0001.  This solution would
certainly work for me, although I personally prefer for L2TPv3 to order things
more naturally, i.e CW followed by RTP header.  As we (the PWE3 WG) own the
control word format, moving forward it seems to me that it provides more value
including this first as we can perform the PW specific processing before the RTP
header processing which is clearly linked to the raw CEM data packets.  I think
this allows us to better future-proof MPLS and L2TPv3 pseudowire services.

Note, I haven't completely thought through this yet, but there maybe similar
issues with the FRG bits.  Would each fragment contain an RTP header?  If not,
and the PW encap/decapsulation layer is responsible for the
fragmentation/reassembly per the PWE3-FRAG draft, then I believe there are
complications here as well.

Cheers,
-Skip