Subject: Re: [PWE3] Re: Demultiplexing of VCCV packets in SAToP and CESoPS N

From: Skip Booth <[email-masked]>
Date: Mon, 01 Aug 2005 10:05:02 -0400

Sasha Vainshtein wrote:
> Skip and all,
> Stitching between MPLS and L2TP PWs is surely an important goal.
> However, I think that the existing situation makes it near impossible - 
> and the TDM PWs are the least complicated part of it!
> 
> When it come to Layer 2 PWs (FR, ATM, HDLC, Ethernet), the L2TP and
> MPLS sequencing schemes differ substantially:
> - L2TP uses a 24-bit no-gap sequence number space
> - MPLS uses a 16-bit, skipped-zero one.

Sure - but there's ways to perform the 16-24 bit conversion, albiet not that
pretty, you can still do it.  In environments where sequencing is not required,
the interworking is pretty straightforward.

For TDM applications, since we are using the PWE3 MPLS CW for both L2TPv3 and
MPLS pseudowires, the interworking is very straightforward assuming we have a
consistent CW/RTP ordering.

> 
> IMHO handling this difference at the stitching point would be much more
> complicated than handling the difference in the CW and RTP order for
> TDM PWs.
> 
> Did I miss something?

Assuming we use the same CW (which I believe we are in agreement on), then the
interworking is very straightforward.

-Skip

> 
> Regards,
> 			Sasha
> 
>>-----Original Message-----
>>From: Skip Booth [mailto:[email-masked]]
>>Sent: Friday, July 29, 2005 4:56 PM
>>To: Stewart Bryant
>>Cc: 'Tnadeau (E-mail) '; 'Yaakov Stein '; [email-masked] '; 
>>Alik Shimelmits; Sasha Vainshtein
>>Subject: [PWE3] Re: Demultiplexing of VCCV packets in SAToP 
>>and CESoPSN
>>
>>
>>One additional note to consider during our discussion on this 
>>next week is PW
>>stitching between MPLS pseudowires and L2TP pseudowires.  It 
>>sure as heck would
>>make this a lot more feasible if both L2TP and MPLS pseudowires used a
>>consistent RTP/CW ordering.  After talking about this 
>>internally with some of my
>>peers, I'm convinced that the right way to do this is to keep 
>>the CW defined as
>>is in the draft, but change the RTP/CW ordering for L2TPv3 to 
>>match the same
>>ordering defined for MPLS pseudowires.  There's lot's of 
>>upside to this change
>>IMO and the only downside to this approach that has been 
>>noted is point #2
>>below.  I'm certainly sensitive to that and we can spend some 
>>more time with
>>Sasha on this next week.
>>
>>-Skip
>>
>>Stewart Bryant wrote:
>>
>>>Let me see if I can sumarise this:
>>>
>>>1) SAToP and CESoPSN use IP/UDP/TRP in that order because
>>>there are well known algorithms for header compression.
>>>(aside I have never noticed that stated in the drafts -
>>>a note should be added).
>>>
>>>2) SAToP and CESoPSN has been implemented over L2TPv3
>>>using the same format as UDP, using the same PWE3 format
>>>as UDP.
>>>
>>>3) There is no definition of how to multiplex VCCV into
>>>a SAToP and CESoPSN PW when running over UDP or L2TP
>>>
>>>4) We need a method of easily demultiplexing VCCV packets
>>>from the SAToP and CESoPSN packets carrying TDM traffic.
>>>
>>>5) We are looking for a demux method with the following
>>>properties:
>>>
>>>a) VCCV pkts can be efficiently picked out before pkts
>>>go to specialist TDM processing sub-system
>>>
>>>b) VCCV pkts should not disrupt TDM pkt sequence numbering
>>>
>>>c) Mechanism should be backwards compatible with existing
>>>implementations.
>>>
>>>- Stewart
>>>
>>>
>>>
>>>
>>>Sasha Vainshtein wrote:
>>>
>>>
>>>
>>>>Skip and all,	
>>>>FYI, Axerra has implemented SAToP and CESoPSN over L2TPv3 already.
>>>>This is one reason (for me) not to be very happy with the 
>>
>>idea of any
>>
>>>>changes.
>>>>
>>>>In particular, alignment with the L2TPv3 default layer 2 
>>
>>sub-layer is highly
>>
>>>>problematic because it uses a different sequencing scheme (24-bit 
>>>>sequence number). Since sequencing for TDM services is much more
>>>>complicated that sequencing for layer 2 services (you MUST 
>>
>>compensate
>>
>>>>for each lost packet, you SHOULD re-order misordered packets and not
>>>>just drop tehm since dropped packets mean errors at the TDM 
>>
>>level etc.)
>>
>>>>and since this processing is TDM-specific, having a single 
>>
>>sequencing 
>>
>>>>solution for MPLS, L2TPv3 and UDP is, IMO, much more important 
>>>>for TDM PWs than having a common L2TPv3 processing with non-TDM
>>>>services, since, being TDM-specific, it happens in the same 
>>
>>line cards.
>>
>>>>The bottom line:
>>>>- Alignment with the L2TPv3 default layer 2 sub-layer looks 
>>
>>like a no-go to
>>
>>>>me.
>>>>- I am not sure that reversal of the header order for 
>>
>>L2TPv3 is justified
>>
>>>>since,
>>>> in my case, I have to compare the general consideration 
>>
>>of alignment with
>>
>>>> quite a specific effort to change the exiting 
>>
>>implementation, maintain
>>
>>>>backward
>>>> compatibility etc.
>>>>
>>>>I hope that we shall be able to discuss these issues 
>>
>>farther in Paris.
>>
>>>>
>>>>With best regards,
>>>>				Sasha
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>-----Original Message-----
>>>>>From: Skip Booth [mailto:[email-masked]]
>>>>>Sent: Thursday, July 28, 2005 4:35 PM
>>>>>To: Sasha Vainshtein
>>>>>Cc: 'Bill Storer (bstorer) '; [email-masked] '; 'Yaakov Stein 
>>>>>'; 'Tnadeau (E-mail) '; 'Stewart Bryant (E-mail) '
>>>>>Subject: Re: 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 )
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>Sasha Vainshtein wrote:
>>>>>
>>>>>
>>>>>
>>>>>>Skip,
>>>>>>Lots of thanks for the prompt response!
>>>>>>
>>>>>>Just to assure you, not only do SAToP and CESoPSN use the
>>>>>>RTP header as per RFC 3550, (thus guaranteeing that the first
>>>>>>two bits are always '01') bu they also NEVER use padding and/or
>>>>>>RTP header extensions (this is explicitly stated in both drafts).
>>>>>>
>>>>>>As for the fragmentation bits with RTP:
>>>>>>
>>>>>>Please note that these are used ONLY in one of the OPTIONAL 
>>>>>
>>>>>CESoPSN modes
>>>>>
>>>>>
>>>>>
>>>>>>(never in SAToP!) and are only used to fragment the E1 or 
>>>>>
>>>>>T1 multiframes
>>>>>
>>>>>
>>>>>
>>>>>>into shorter packets to reduce packetization latency. In 
>>>>>
>>>>>other words,
>>>>>
>>>>>
>>>>>
>>>>>>frequency RTP headers in the fragments would always bear different
>>>>>>timestamps. What's more, there is no actual 
>>>>>
>>>>>de-fragmentation: the TDM
>>>>>
>>>>>
>>>>>
>>>>>>payload of each fragment is played out independently, and the only
>>>>>>ptrocessing required in the receiver being extraction of 
>>>>>
>>>>>the signaling
>>>>>
>>>>>
>>>>>
>>>>>>substructures  which are only appended to the LAST 
>>
>>fragment of each
>>
>>>>>>multiframe. So I do not see any issue here.
>>>>>>
>>>>>>Hopefully this clarifies the situation.
>>>>>
>>>>>It definitely does Sasha.  I would agree that we at least 
>>>>>have a working model
>>>>>for overcoming the VCCV/CW concern we raised.  That being 
>>>>>said, within the
>>>>>context of L2TPv3, what are the valid reasons for not doing 
>>>>>the following:
>>>>>
>>>>>1) Having the order of the packet format as IP/L2TPv3/CW/RTP. 
>>>>>I still maintain
>>>>>that from a future-proofing perspective, placing the CW prior 
>>>>>to the RTP header
>>>>>is the correct way to model L2TPv3.  There's no reason why 
>>>>>L2TPv3 should be
>>>>>modeled after the IP/UDP mode.  Processing wise it's much 
>>>>>more closely aligned
>>>>>with the MPLS pseudowires.
>>>>>
>>>>>2) Aligning the SAToP/CEM CW for L2TPv3 modes more closely 
>>>>>with the default
>>>>>L2-specific sublayer defined in the L2TPv3 RFC?  From a pure 
>>>>>packet efficiency
>>>>>perspective, having the CW more closely match the L2TPv3 
>>>>>default CW is better as
>>>>>it will require less checks in the data-path.
>>>>>
>>>>>AFAIK, there are no implementations at this point for 
>>>>>SAToP/CEM over L2TPv3, so
>>>>>I'd rather get this right from the get-go if possible.  We 
>>>>>would certainly be
>>>>>willing to supply some text for the SAToP/CEMoP drafts for 
>>>>>the L2TPv3 packet
>>>>>format and control word format if we agree to go in this direction.
>>>>>
>>>>>Cheers,
>>>>>-Skip
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>Regards,
>>>>>>                        Sasha
>>>>>>
>>>>>>-----Original Message-----
>>>>>>From: Skip Booth
>>>>>>To: Sasha Vainshtein
>>>>>>Cc: Bill Storer (bstorer); [email-masked]; Yaakov Stein; 
>>>>>
>>>>>Tnadeau (E-mail);
>>>>>
>>>>>
>>>>>
>>>>>>Stewart Bryant (E-mail)
>>>>>>Sent: 7/27/2005 10:16 PM
>>>>>>Subject: Re: 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	)
>>>>>>
>>>>>>See inline....
>>>>>>
>>>>>>Sasha Vainshtein wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>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.
>>>>>>
>>>>>>Fantastic summary!!! Thanks Sasha.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>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?
>>>>>>
>>>>>>
>>>>>>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
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>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
>>

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

---

From: Sasha Vainshtein <[email-masked]>
Date: Tue, 2 Aug 2005 09:54:43 +0300

Skip and all,
Please see a bit more inline.

Regards,
		Sasha

> Sent: Monday, August 01, 2005 3:05 PM
> To: Sasha Vainshtein
> Alik Shimelmits; Stewart Bryant
> Subject: Re: [PWE3] Re: Demultiplexing of VCCV packets in 
> SAToP and CESoPS N
> 
> 
> 
> 
> Sasha Vainshtein wrote:
> > Skip and all,