Subject: RE: [SPAM] - Re: [PWE3] [Fwd: Proposed text for SAToP congestionsection] - Email found in subject

From: "Ron Cohen" <[email-masked]>
Date: Wed, 28 Dec 2005 18:25:38 +0200

Joe,

I agree with you 100%.

Since we have to provide text for this section, could you please comment on the proposed text I sent in previous email?

Thanks
Ron 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Joe Merritt
Sent: Wednesday, December 28, 2005 6:01 PM
To: Stewart Bryant
Cc: pwe3
Subject: RE: [SPAM] - Re: [PWE3] [Fwd: Proposed text for SAToP congestionsection] - Email found in subject

Stewart,

A service provider who plans to use SAToP PW over a PSN (UDP/IP, MPLS, or L2TP) to deliver DS1/E1 transport services, will ensure that the underlying PSN is well behaved (e.g. Bell South architecture for Ethernet services) because the service operates under a tariff. The service provider will integrate the SAToP into their management systems (provisioning, fault management, etc.) and operations staff. The service must be consistent throughout otherwise it will not be adopted or deployed.

DS1/E1 transport services do not have the concept of congestion but rather errors, defects, and faults whenever there are problems in the network (failing repeaters, cable problems, etc.). OAM methodology specifies that these events will trigger alarms and the associated corrective actions.

SAToP PW (CBR) service should have the highest priority in a packet network. The underlying core PSN should never be allowed to over-provision CBR flows and when experiencing congestion all UBR and VBR flows should be discarded as required to achieve an uncongested state. 

My concern is that the SAToP PW should not be adversely affected by congestion in the PSN. The architecture of the PSN should be able to support the requirements associated with SAToP PW otherwise it should not be allowed to be provisioned. 

Terminating the SAToP PW will not prevent a poorly designed PSN from collapsing; it will only delay the event. 

Regards,
Joe

-----Original Message-----
From: Stewart Bryant [mailto:[email-masked]]
Sent: Wednesday, December 28, 2005 10:03 AM
To: Joe Merritt
Cc: pwe3
Subject: [SPAM] - Re: [PWE3] [Fwd: Proposed text for SAToP congestion section] - Email found in subject

Joe Merritt wrote:

>Stewart,
>
>IMHO the proposed text appears to run counter to OAM methodology used 
>in the TDM networks. SAToP is about transport versus services. The 
>transport of the network has well established OAM methodology even when

>using packet transport (i.e. reference ITU-T I.610) which is harmonized

>with the way TDM equipment works and established Fault Management 
>systems.
>
>Perhaps, I am not fully appreciating the proposed text however I am 
>concerned about the approach being discussed based on 15 years 
>experience with DS1/E1 and packet switched access equipment.
>
>  
>
Joe

Please could you elaborate your concerns.

The text was written to address the concern that a SAToP PW MUST NOT drive the underlying IP network into congestion collape.
Therefore when it is detected that the such a collapse is incipient the PW must stop sending packets. In a well engineered network this mechanism will not be invoked, but it is needed as a backstop.

Stewart

>Regards,
>Joe
>
>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On Behalf Of

>Stewart Bryant
>Sent: Tuesday, December 27, 2005 5:14 AM
>To: pwe3
>Subject: [PWE3] [Fwd: Proposed text for SAToP congestion section]
>
>Following discussion with the transport ADs, we propose that text of 
>the following form be added to the TDM drafts.
>
>I think that we need to add similar text to our other drafts to cover 
>the case where they are used to carry non-TCP friendly streams.
>
>The obvious cases is where this is needed is ATM cell mode.
>
>- Stewart
>
>
>8.  Congestion Control
> 
>As explained in [PWE3-ARCH], the PSN carrying the PW may be subject to 
>congestion, with congestion characteristics depending on PSN type, 
>network architecture, configuration, and loading. During congestion the

>PSN may exhibit packet loss and PDV that will impact the timing and 
>data integrity of the SAToP PW.
>During intervals of accute congestion SAToP will not be able to 
>maintain service.
>In addition, since SAToP PWs carry constant bit rate (CBR) services 
>across the PSN, they cannot behave in a TCP-friendly manner prescribed 
>by [RFC2914].
>In the presence of services that reduce transmission rate, SAToP PWs 
>will thus consume more than their fair share (although being CBR, the 
>percentage of total bandwidth they consume remains constant) and SHOULD

>be halted.
> 
>Whenever possible, SAToP PWs should be run over traffic-engineered PSNs

>providing bandwidth allocation and admission control mechanisms.
>IntServ-enabled domains providing the Guaranteed Service (GS) or 
>DiffServ-enabled domains using EF (expedited forwarding) are examples 
>of traffic-engineered PSNs. Such PSNs will minimize loss and delay 
>while providing some degree of isolation of the SAToP PW's effects from

>neighboring streams.
> 
>The PEs SHOULD monitor for congestion (by using explicit congestion 
>notification, VCCV, or by measuring packet loss) in order to ensure 
>that the SAToP service may be maintained. Note that SAToP packet loss 
>rate may always be measured unintrusively since the expected packet 
>arrival rate is known and fixed.
>When significant congestion is detected the SAToP service SHOULD be 
>terminated. Because PWs are inherently birectional, the detecting PE 
>can terminate the SAToP service without explicitly communicating with 
>the remote PE. The PE initiating termination simply ceases transmission

>of SAToP packets. The other PE, even if previously unaware of a 
>problem, will of necessity detect that packets are not arriving and 
>MUST similarly cease packet transmission.
>If the PW has been set up using the PWE control protocol, then 
>procedures specified in [PWE3-CONTROL] for label Withdrawal MAY be used

>as well. The PW may be restarted by manual intervention, or by 
>automatic means after an appropriate waiting time.
>
>_______________________________________________
>pwe3 mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/pwe3
>
>
>  
>

_______________________________________________
pwe3 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pwe3

--
This message has been scanned for viruses and dangerous content by OpenProtect(http://www.openprotect.com), and is believed to be clean.

_______________________________________________
pwe3 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pwe3