1 / 9

IETF-53 PWE3 Workgroup 21-Mar-02 An Update on CESoPSN draft-vainshtein-cesopsn-02.txt

IETF-53 PWE3 Workgroup 21-Mar-02 An Update on CESoPSN draft-vainshtein-cesopsn-02.txt. Sasha Vainshtein, Israel Sasson, Akiva Sadovski, Eduard Metz, Tim Frost. CESoPSN – A Reminder. A PW encapsulation for E3 emulation of TDM circuits The -01 revision first presented at the SLC meeting

forrest-beck
Download Presentation

IETF-53 PWE3 Workgroup 21-Mar-02 An Update on CESoPSN draft-vainshtein-cesopsn-02.txt

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. IETF-53PWE3 Workgroup21-Mar-02An Update on CESoPSN draft-vainshtein-cesopsn-02.txt Sasha Vainshtein, Israel Sasson, Akiva Sadovski, Eduard Metz, Tim Frost

  2. CESoPSN – A Reminder • A PW encapsulation for E3 emulation of TDM circuits • The -01 revision first presented at the SLC meeting • Supports: • N*DS0 circuits (with or without CE application signaling) • Unstructured E1 and T1 circuits • Unstructured E3 and DS3 circuits • Complies with the Minimal Intervention principle regarding the TDM payload • Uses RTP for: • Timing (synchronization) services • Sequencing services • Differentiation between data and signaling • PSN-invariant Stray Packets detection • Optionally may use a (payload) control word • Carries PE state in both directions

  3. -02 version • Posted before the Minneapolis IETF after a substantial re-write • A special “Thank you” to Stephen Casner for reviewing the draft before posting: • Corrected some serious errors • Provided important inputs for the future releases • Thanks for discussion of the pre-posting version and valuable feedbacks to: • Sim Narasimha • Max Riegel • Yaron Raz

  4. Major Changes from –01 • An explicit “Requirements” section has been added: • Refers to applicable generic PWE3 requirements (draft-ietf-pwe3-requirements-02.txt) • Defines specific requirements for edge-to-edge emulation of TDM circuits • Support for CE application state signaling has been defined • Channel-Associated Signaling (CAS) is a typical example • “Data packets” and “signaling packets” are defined • Data packets format is not affected by the signaling scheme • Signaling packets may use the “slow path” • Wrt to RTP, the signaling packets use their own PT, SSRS ID and sequencing • Egress resynchronizes data and signaling using RTP timestamps • Only application state transitions are signaled • Payload format is signaling scheme-specific • For CAS, the application state encoding is based on RFC 2833 • Protection against loss of signaling packets and state recovery based on RFC 2833

  5. More Changes from -01 • PW (VC) Types and and RTP Payload Types have been decoupled • Dynamic RTP Payload Types used instead • G.826-compatible Performance Monitoring has been defined • Minor: • Text aligned with the latest revisions of the common PWE3 documents • Some non-specific stuff removed • Some descriptive text added on: • Detection of lost packets • Adaptation of the jitter buffer size etc. • In-band loopback commands have been removed • Can be set/released manually or signaled via a common PWE3 maintenance protocol • Loopback PE state still signaled back across the PSN

  6. Open Issues • Improve encapsulation efficiency with minimal loss of functionality. Options: • Skip the control word without loosing functionality? • Optionally use only the control word (use the reserved bits)? • Define a more effective encapsulation for T1? • RTCP usage. Natural possibilities: • Resynchronization of independent SSRCs for data and signaling packets • Retrieval of “far-end” PE state, statistics etc. • Support Common Channel Signaling (CCS) schemes: • Same basic principles as for CAS • Resolve specific encoding issues

  7. Convergence Issues • CESoPSN vs. TDMoIP (draft-anavi) • Almost 100% overlap in functionality • Two meetings have been hold in Tel-Aviv • We seemed to be close, but did not succeed to resolve the differences • CESoPSN vs. CEP (draft-pate) • Some overlap in functionality • Some applications covered only by one of the two documents • No serious attempt to resolve the differences yet • In both cases differences in the payload formats are more difficult to overcome than differences in the header formats • The input from the WG would be helpful • Virtually nothing seen on the list

  8. Questions to the WG and ADs • Requirements for edge-to-edge emulation of TDM circuits: • Is an explicit specification needed? • People use to say that “TDM is something else” both on the list and in private discussions • Being more specific about what this “something else”is could be helpful • If needed, how it should be done: • Within the common PWE3 requirements document? • In a dedicated document? • Within the document that describes a specific solution? • RTP in PWE3: • Is “classic” RTP/UDP/IP admissible in the PWE3 context? • Suits existing infrastructure (e.g., header compression) • How should the definitions of RTP/L2TPv3/IP and RTP/MPLS stacks be pursued? • Can CESoPSN be adopted as a WG Item?

  9. Questions?

More Related