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

From: Sasha Vainshtein <[email-masked]>
Date: Sun, 31 Jul 2005 09:33:59 +0300

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.

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?

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