Subject: [PWE3] RE: Demultiplexing of VCCV packets in SAToP and CESoPSN

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

Stewart and all,
A very nice summary.
Please see a brief comment inline.

See you in Paris,
				Sasha			

> -----Original Message-----
> From: Stewart Bryant [mailto:[email-masked]]
> Sent: Friday, July 29, 2005 2:30 PM
> To: Sasha Vainshtein
> Cc: 'Skip Booth'; 'Bill Storer (bstorer) '; [email-masked] '; 
> 'Yaakov Stein '; 'Tnadeau (E-mail) '; Alik Shimelmits
> Subject: Re: Demultiplexing of VCCV packets in SAToP and CESoPSN 
> 
> 
> 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).
>
[Sasha[ I believe it has been mentioned in one of the early 
versions of the draft but was later removed. Adding such a note
is OK with me.
> 
> 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