1

IETF-55PWE3 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

21-Nov-02, Atlanta2

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

21-Nov-02, Atlanta3

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

21-Nov-02, Atlanta4

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?)

21-Nov-02, Atlanta5

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

21-Nov-02, Atlanta6

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

21-Nov-02, Atlanta7

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

21-Nov-02, Atlanta8

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

21-Nov-02, Atlanta9

Questions?