IETF57 PWE3 Workgroup 16July03 draftvainshteincesopsn06'txt: Summary of Discussion - PowerPoint PPT Presentation
Title:
IETF57 PWE3 Workgroup 16July03 draftvainshteincesopsn06'txt: Summary of Discussion
Description:
The CW has been fully aligned with CEP ... is fully aligned with that of CEP ... The common clock can be provided using BITS, GPS etc. (same as with CEP-EPAR) ... – PowerPoint PPT presentation
Number of Views:46
Avg rating:3.0/5.0
Title: IETF57 PWE3 Workgroup 16July03 draftvainshteincesopsn06'txt: Summary of Discussion
1
IETF-57PWE3 Workgroup 16-July-03
draft-vainshtein-cesopsn-06.txtSummary 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 - -----------------------
--------- - 0000RDNPBE 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-complia
nt 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?
Recommended
CrystalGraphics Presentations
