1 / 8

IETF-57 PWE3 Workgroup 16-July-03 draft-vainshtein-cesopsn-06.txt: Summary of Discussion

IETF-57 PWE3 Workgroup 16-July-03 draft-vainshtein-cesopsn-06.txt: Summary of Discussion. Sasha Vainshtein, Tim Frost, Prayson Pate. CESoPSN-06 Status (1). The CESoPSN draft : First presented at the 52th IETF meeting Evolved: To cover additional functionality

fshaunna
Download Presentation

IETF-57 PWE3 Workgroup 16-July-03 draft-vainshtein-cesopsn-06.txt: Summary of Discussion

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-57PWE3 Workgroup16-July-03draft-vainshtein-cesopsn-06.txt:Summary of Discussion Sasha Vainshtein, Tim Frost, Prayson Pate

  2. CESoPSN-06 Status (1) • The CESoPSN draft: • First presented at the 52th IETF meeting • Evolved: • To cover additional functionality • To remove unnecessary restrictions • Fully aligned with the following basic documents: • The WG Charter • The PWE3 Requirements draft - all the relevant requirements covered, non-goals not pursued • The PWE3 Architecture draft (payload types, partitioning between NSP and PW IWF, the principle of minimum intervention) • The TDM PW requirements draft (all the mandatory requirements covered) • RFC 2736 (explicitly referenced in the WG Charter) • The SONET Emulation (CEP) draft

  3. CESoPSN-06 Status (2) • The -06 revision of the CESoPSN draft: • A few updates from the -05 version: • Support of trunk-specific Nx64 kbit/s with CAS has been defined • The CW has been fully aligned with CEP • Request to adopt as a WG item as the basis for further WG work posted 06/10/03 • 4 successful interoperability tests have been publicly announced • Prove simplicity and robustness of the proposed solution • Multiple silicon implementations are now available, including a high-density solution • Danny has asked for the WG opinion 06/12/03 • A lively discussion has been maintained on the WG mailing list • A few TECHNICAL issues have been raised by both the supporters and the opponents • Suggested resolutions to these issues are presented here

  4. Unstructured Services • No conceptual objections raised to the CESoPSN for emulation of UNSTRUCTURED services • A new proposal for unstructured service (draft-stein-pwe3-stpp-00): • Conceptually identical to unstructured mode in CESoPSN-06 • See also draft-vainshtein-pwe3-ucesopsn-00.txt (presented in Atlanta and incorporated into CESoPSN-05/06) • The following minor differences found: • No option to use RTP • Different control word format • Different default payload length/latency for E1 • No showstoppers!

  5. Specific Technical Issues - 1 • Issue: Non-ECMP-compliant CW • The CESoPSN CW is fully aligned with that of CEP • It is technically possible to use a standard CW: • Sufficient Flags space (4 flags needed) • Sufficient Sequence Number space • Use Fragmentation bits for splitting basic structures of trunk-specific Nx64 kbit/s with CAS (as per draft-ietf-pwe3-fragmentation-02) • Alignment with CEP has certain advantages • Suggested resolution: follow the WG input 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|0|0|0|R|D|N|P|B|E| Reserved | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ An ECMP-compliant CESoPSN CW

  6. Specific Technical Issues - 2 • Issue: Usage of RTP header • Claims made on the PWE3 list: • RTP does not provide any advantages for clock recovery with emulated TDM • G.823 / G.824-compliant clock recovery is impossible with TDM emulated over PSN, because IP and MPLS do not provide clock at their physical layer • Contention: RTP can facilitate G.823/G.824-compliant clock recovery when a common clock source is available at both PEs terminating the TDM PW • The common clock can be provided using BITS, GPS etc. (same as with CEP-EPAR) • The timestamps are generated in accordance with this clock (differential mode) • Suggested resolution: • Preserve the OPTION to use RTP header • Follow the WG input regarding the default mode

  7. Specific Technical Issues - 3 • Issue: Default packet latency for unstructured E1 • The draft proposes 1 ms • An alternative proposal: 0.5 ms • Suggested resolution: follow the WG input • Issue: Frame alignment for unstructured services • The draft does NOT require or imply that • Suggested resolution: editorial (explicitly state in the text) • Issue: T1-SF Nx64 kbit/s w/CAS • Basic structure for trunk-specific Nx64 kbit/s with CAS defined as the trunk multiframe • De-facto basic structure used with T1-SF: a pair of consecutive multiframes • Suggested resolution: editorial (update the corresponding portions of the text)

  8. Questions?

More Related