1. 1 IETF-55 PWE3 Workgroup 21-Nov-02 Unstructured TDM over PSN draft-vainshtein-pwe3-ucesopsn-00.txt Sasha Vainshtein, Yaakov Stein, Israel Sasson, Akiva Sadovski, Eduard Metz, Tim Frost, Prayson Pate

2. 2 21-Nov-02, Atlanta UCESoPSN – Motivation Many transport applications carry the entire TDM stream transparently It is up to the CEs to detect any structure Suits "Leased Line" applications All the "signaling" is carried transparently E.g., FDL/FEAC An evolution/merge of "unstructured" approaches earlier presented in: draft-vainshtein-cesopsn-03.txt The -04-revision is limited to n*DS0 only draft-anavi-tdmoip-04.txt (in unadapted (raw) mode) Simple enough to overcome most of the differences: No payload mangling in both approaches Minor encapsulation layer differences easy to eliminate Supported by the editors of the all the separate TDM drafts

3. 3 21-Nov-02, Atlanta UCESoPSN – Scope and Alignment In scope: DS1 (a.k.a T1) - explicitly in the charter E1 - not explicitly in the Charter, but as popular out of North America as DS1 is there DS3 - explicitly in the charter E3 - used in Europe and elsewhere. Currently out of scope: "Unstructured" SONET/SDH Fully aligned with: The PWE3 Charter The PWE3 Requirements draft The PWE3 Architecture draft The PWE3 TDM requirements document

4. 4 21-Nov-02, Atlanta UCESoPSN - Encapsulation Basic packet format has been aligned with the SONET/SDH draft(s) RTP header is part of the header: By default is present, MAY be suppressed if both PEs agree One of the PT values from the dynamic range MUST be used - a default value not specified yet (127?) The control word is MANDATORY Flags approximately aligned with SONET/SDH The sequence number provides the sequencing function if the RTP header is suppressed Two modes of timestamp generation: Use the clock recovered from AC - default, MUST be supported Use a common reference clock (if available) - OPTIONAL The clock frequency MUST be a multiple of 8 kHz The default value has not been specified yet (8 kHz?)

5. 5 21-Nov-02, Atlanta UCESoPSN - Procedures Handling of lost packets: Always replace a lost packet with the equivalent amount of "replacement data" The actual choice of "replacement data" is a local issue: "All ones" MAY be used (is it the default action?) Other techniques MAY be used to increase CE resistance to an occasional loss of packets E.g., replay the contents of the last received packet No need to have the same procedure at both ends of the PW Some flags in the control word may require framer-based monitoring Other procedures similar to what you find in SONET/SDH drafts

6. 6 21-Nov-02, Atlanta UCESoPSN - Payload Payload carried as captured As required by the principle of Minimum Intervention Two packet payload size modes defined: A multiple of a 125 microseconds' sample per packet - RECOMMENDED Facilitates usage of local procedures for improving CE resilience to effects of occasional packet loss - an issue that has been actively discussed on the list Limits packetization latency for DS1 to multiples of 1 millisecond (or payload size to multiples of 193 bytes) DS1 payload may be padded to 25 bytes per 125 microseconds sample as defined in ITU-T G.802 to allow other multiples A multiple of 47 bytes per packet - OPTIONAL Facilitates interworking with AAL1-based ACs

7. 7 21-Nov-02, Atlanta UCESoPSN - Issues The default "must-be-implemented" payload size value(s): Not specified yet Looks like the only unresolved issue at the moment The Design Team has been working on that

8. 8 21-Nov-02, Atlanta UCESoPSN - Discussion in the TDM Design Team The TDM Design Team is considering a compromise based upon: Solutions for structured and unstructured TDM emulation being documented in two separate drafts Having a single must-be-implemented mode in each of then Having one or more optional modes for special cases The details are being worked out The unstructured draft seems ready for adoption as the WG document once the default payload size issue is resolved

9. 9 21-Nov-02, Atlanta Questions?