Subject: RE: Packet payload size for unstructured TDM emulation (wa s: Submission of an internet draft for unstructured TDM emulation)

From: Sasha Vainshtein <[email-masked]>
Date: Tue, 29 Oct 2002 15:05:47 +0200

Daniel, Shahram and all,
Several comments which, hopefully, clarify
the intention of the authors:

1. The draft defines a packetization mode with 
   the packet payload containing an integral
   multiple of 125 microseconds samples. 
   * Support of this mode is RECOMMENDED (see note below).
   * The reason behind this recommendation: ability 
     to improve CE resilience to effects of packet 
     loss in the PSN by an appropriate local definition 
     of 'replacement packets'. An ability to use such 
     local definitions has been extensively discussed 
     on the list and is explicitly mentioned as one of 
     the objectives of unstructured TDM emulation.
   * An OPTION to use replacement packets containing 
     "all ones"  is explicitly allowed. 
   * Other options for replacement packets are allowed 
     but left unspecified since anyway the choice 
     is a local matter (in particular, it presumably 
     does not have to be the same at the two ends 
     of the same PW). 
   * One of the options discussed on the list was to 
     use the last received packet as the current 
     'replacement packet'.

2. The draft defines an additional packetization 
   mode with the packet payload containing an integral
   multiple of 47 bytes. 
   * The reason behind this option: interoperability 
     with AAL1-based attachement circuits. 
   * Support of this mode is OPTIONAL (see note below).

3. One of the explicit objectives pursued in the draft is
   to allow trade-off between the encapsulation efficiency
   (in terms of the PSN BW and switching capcity) and 
   fidelity of emulation (in terms of resilience to packet
   loss and, to lesser extent, end-to-end delay). As a 
   consequence, the draft does not limit all the 
   implementations to one single value of the payload
   size.

4. The draft has not yet defined the MANDATORY payload 
   size value to be supported by all the implementations.
   * This issue has been left FFS, and, hopefully, will be 
     resolved in the next revision. 
   * Specification of such a MANDATORY DEFAULT value 
     would facilitate interoperability tests. 
   * Using service-specific default payload size 
     would neither affect interoperability, nor increase 
     complexity of implementation and hence should
     not be precluded. 
   * IMHO the equivalent of 8 frames (i.e., 256 bytes) has
     been explicitly mentioned on the list as a suitable
     default value for emulation of E1 circuits.
   * Additional input regarding selection of default values 
     - or reasons why they should not be defined - is welcome.

5. A requirement to suppport negotiation of the packet 
   payload size makes sense if it is accomanied by a method 
   that guarantees success of such a negotiation. 
   * Specification of mandatory defaults is one such 
     method. 
   * A requirement to support ANY packet payload size 
     within the path MTU limits, while definitely 
     guaranteeing success, would be, IMHO, an 
     exaggeration.
   * Any input regarding othe methods would be welcome.

Note: The draft uses the key words MUST, SHOULD and MAY 
      in strict accordance with RFC 2119. In particular,
      SHOULD is considered equivalent to RECOMMENDED, 
      and MAY - to OPTIONAL.

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

-----Original Message-----
From: Daniel Feldman [mailto:[email-masked]]
Sent: Tuesday, October 29, 2002 9:00 AM
To: Shahram Davari; PWE3 WG (E-mail)
Subject: RE: [PWE3] Submission of an internet draft for unstructured TDM
emulation

    Hello all,
    I agree with Shahram's proposal, to have the payload size negotiated. 
    We can think about stipulating also a default value which all 
    implementations SHALL support.
    This is the only way to ensure interworking.
    Regards,
        Daniel.
-----Original Message-----
From: Shahram Davari [mailto:[email-masked]]
Sent: Friday, October 25, 2002 4:50 PM
To: PWE3 WG (E-mail)
Cc: Daniel Feldman
Subject: RE: [PWE3] Submission of an internet draft for unstructured TDM
emulation

Daniel,
 
I was about to make the same comment. Fixing the size of the payload to some
specific values seems implementation dependent. In theory, the unstructured
mode should work with any payload size, because no frame or structure
boundary is required to be recognized. 
 
My suggestion is to not determine the payload size in the draft and just
mention that both sides must agree (or be configured) on the payload size to
be used.
 
Yours,
-Shahram
-----Original Message-----
From: Daniel Feldman [mailto:[email-masked]]
Sent: Thursday, October 24, 2002 3:06 PM
To: Sasha Vainshtein; PWE3 WG (E-mail)
Cc: Danny McPherson (E-mail); Ron Cohen (E-mail); Sim Narasimha (E-mail);
Stephen Casner (E-mail); Stewart Bryant (E-mail); Tom K. Johnson (E-mail);
'Riegel Maximilian' (E-mail 2); Yaron Raz (E-mail); Ashwin Moranganti
(E-mail); Mark Townsley (E-mail); Andrew G. Malis (E-mail); Shahram Davari;
Alex Trigub; Alex Feldman
Subject: RE: [PWE3] Submission of an internet draft for unstructured TDM
emulation

        Gentleman: well done! 
        This is indeed a breakthrough. My only question is the following: 
In section 4.3.1 you say: 
"Payload of a single UCESoPSN packet SHOULD contain one or more native 
circuit frames" 
and later: 
"In addition to the "native circuit frame" mode, the packet payload size 
MAY be an integer multiple of 47, without regard to the native circuit 
frame." 
        Since there is no SHALL written, what happens if an implementation
(for example, an Axerra one) decides to go for natives frames, while another
(for example, a RAD one) decides to go for multiple of 47 bytes. What
happens to interworking!?!?!
        Thanks in advance, 
                Daniel Feldman 

-----Original Message----- 
From: Sasha Vainshtein [mailto:[email-masked]] 
Sent: Thursday, October 24, 2002 8:09 PM 
To: PWE3 WG (E-mail) 
Cc: Danny McPherson (E-mail); Ron Cohen (E-mail); Sim Narasimha 
(E-mail); Stephen Casner (E-mail); Stewart Bryant (E-mail); Tom K. 
Johnson (E-mail); 'Riegel Maximilian' (E-mail 2); Yaron Raz (E-mail); 
Ashwin Moranganti (E-mail); Mark Townsley (E-mail); Andrew G. Malis 
(E-mail); Shahram Davari (E-mail) 
Subject: [PWE3] Sumbission of an internet draft for unstructured TDM 
emulation 

Dear colleagues, 
Discussions on emulation of TDM circuits that took 
place during and after the Yokohama meeting have 
shown that emulation of unstructured circuits 
is by far a less contentious issue when compared 
to that of "structured" ones (n*DS0) while 
being of sufficient interest to many of the WG 
participants. 
This understanding triggered an effort to provide 
a (hopefully!) non-controversial specification  
for encapsulating unstructured E1, T1, E3 and T3 
circuits as pseudo-wires. The resulting document, 
edited by Yaakov Stein (RAD) and myself, has been just 
sent for posting at the IETF Web site as a NEW draft. 
While it is  processed by the Internet Drafts Editor, 
you can access it at the following location: 
ftp://ftp.axerra.com/sasha/draft-vainshtein-pwe3-ucesopsn-00.txt 
Your feedback will be highly appreciated. 
  
With best regards, 
                                   Sasha Vainshtein 
email:     [email-masked] 
tel:       +972-3-7659993 (office) 
           +972-8-9254948 (res.) 
           +972-58-674833 (cell.) 
_______________________________________________ 
pwe3 mailing list 
[email-masked] 
https://www1.ietf.org/mailman/listinfo/pwe3 
--- 
Incoming mail is certified Virus Free. 
Checked by AVG anti-virus system (http://www.grisoft.com). 
Version: 6.0.406 / Virus Database: 229 - Release Date: 10/21/2002 

---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.406 / Virus Database: 229 - Release Date: 10/21/2002