1 / 11

Sasha Vainshtein

Method for emulating NxDS0 services over PSN, supporting basic NxDS0 and trunk-specific NxDS0 with CAS. Resolves issues on packet latencies and sequencing methods. Addresses TDM trunk RDI propagation.

rodneye
Download Presentation

Sasha Vainshtein

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 60PWE3 Workgroup San Diego, 02-Aug-04 draft-ietf-pwe3-cesopsn-00/01.txt:WG Last Call: Issues and Resolutions Sasha Vainshtein

  2. CESoPSN- A Reminder • A method for structure-aware emulation of NxDS0 services over PSN • Supports: • Basic NxDS0 • NxDS0 with CE application signaling in separate signaling packets • Trunk-specific NxDS0 with CAS • TDM structures are locked to the packet payload boundaries • MANDATORY ECMP-safe CW and OPTIONAL RTP • The flags field in the CW carry: • Forward TDM trunk condition indications • Backward PW packet loss indication • Signaling vs.data packets discriminator • Went to the WG Last Call as draft-ietf-pwe3-cesopsn-00 • Issues raised will be discussed below

  3. WG Last Call Issues (1) • Default packet latencies MUST be power of 2 multiples of 1 ms • Reasoning: simplifies HW implementations • Resolution in CESoPSN-01: • For N >=5 default latency is 1 ms • For N = 2, 3, 4 default latency is 4 ms • For N = 1 default latency is 8 ms • Note: • A single default for all service rate is not practical since the packet payload would be too small in case of slow services

  4. WG Last Call Issues (2) • Signaling and data packets in the same PW are two independent sequenced sub-flows • Reasoning: • Complicates the implementation • Not compliant with the PWE3 architecture • Counter-reasoning: • The PWE3 architecture speaks about multiple channels • Setup/teardown of a pair of lifespan-sharing PWs is not covered by the existing control protocol • Resolution: • SHOULD carry TDM data and CE application signaling in two separate PWs • MAY still carry them in the same PW • Coupling of the data and signaling PWs for the same service will be considered separately (next presentation)

  5. WG Last Call Issues (3) • The sequencing method differs from the method used in Layer 2 encapsulations (does not skip zero) • Reasoning: obvious • Counter-reasoning: • If RTP is used, the same sequence number in the RTP header and the CW is an advantage • With TDM PWs, sequence numbers are used in computation of the number of lost bytes • Common for ALL the TDM drafts (CEP, SAToP, CESoPSN and TDMoIP) • Resolution: no change • Note: aligned with ITU-T Recommendation Y.1413

  6. WG Last Call Issues (4) • Propagation and handling of the TDM trunk RDI contradicts the principles of the layered networks architecture as per G.805/G.809 • Reasoning: • RDI MUST NOT be propagated from the server trail to the client trail • Instead, each client trail SHOULD have its own RDI • Counter-reasoning: • The "client trail" in question is NxDS0 that does not possess its own AIS or RDI (being massively deployed somewhat before G.805/G.809) • Resolution: • A PE implementing CESoPSN SHOULD be capable of extending the TDM trunk trail (e.g., by mapping OAM indications carried across the PSN to appropriate NSP commands)

  7. Reference PE Architecture E1/T1 trunk Trunk OAM indications and Framer commands E1/T1 trunk PE PE F R A M E R F R A M E R IWF IWF CE CE CESoPSN PW A PE with a simple NSP (Framer) NxDS0 TDM Data Extends the trunk OAM indications

  8. WG Last Call Issues (5) • The ingress PE MUST apply trunk conditioning: • Downstream upon detection of AIS or RDI of the TDM trunk • Both upstream and downstream on packet loss • Reasoning: Similarity with ATM-CES • Counter-reasoning: • Purely TDM operations should be left to the appropriate NSP • ATM-CES lacks the means to carry trunk condition indications across the network • Resolution: • A PE implementing CESoPSN MAY be capable of applying downstream trunk conditioning as handling of extended TDM indications • Capability enabled by local configuration at egress • Notes: • The CESoPSN PE architecture with an extended NSP is shown in the next slide

  9. Simple vs. Enhanced NSP E1/T1 trunk E1/T1 trunk PE PE F R A M E R F R A M E R IWF CE IWF CE DXC CESoPSN PW A PE with an extended NSP Part of the extended NSP. Applies downstream trunk conditioning Internal TDM trunk

  10. What Else? • A few typos corrected • (Some probably added:-) • References updated • Reference to a now non-existing section of the Architecture draft still remains • Will be replaced the reference to the CW draft • draft-ietf-pwe3-cesopsn-01 posted and last call announced

  11. Questions?

More Related