Subject: Comments on the CESoPSN draft

From: Ashwin Moranganti <[email-masked]>
Date: Wed, 9 Oct 2002 11:27:17 -0400

Sasha et al.

I have some clarifications and comments  on the CESOPSN draft.

===================================

Section 5.2.2 Usage and Structure of the Control Word:

"o Bit D - carries Local Idle Code indication. If set, represents the Idle
Code state in the payload of an unstructured T3 circuit. A packet with the I
bit set MAY carry no payload" 
Reference to "I bit" should be "D bit" in the line above. (I believe its a
typo)

"o Bit A - carries Local AIS indication. If set, represents AIS of the AC of
the emulated service. A packet with the A bit set MAY carry no payload" 

This would appear to be redundant information, as the equipment is obligated
to force all one's 
in the payload if a failure is detected.  Is there a scenario that would
clarify the use of this bit,
but NOT force all one's in the payload?

"o Bit X - for N*DS0 circuits MAY carry indication of RAI condition of the
carrying E1 or T1 AC"  
Is there a reason why the use of Bit X is limited to N*DS0?  We recognize a
use for unstructured T1
traffic.

We would like to propose an additional bit, called the "L bit".  It would be
used to command
the PE to perform a terminal loopback (at the E1 or T1 LIU). 

Section 5.3.4.  "T1-in-E1" Mode for Unstructured T1 Circuits

The term "T1-in-E1" is misleading.  T1 traffic is being sent within a 25
octet frame, not a 32 octet frame.
Please consider one of the following as a replacement:
octet-aligned T1
octet-captive T1
octet-oriented T1
octet-arranged T1
octet-assembled T1
octet-aggregated T1
If "T1-in-E1" is the preferred choice, then for the best English style,
remove the quotation marks.
Otherwise "T1-in-E1" looks informal, as if searching for a better word.

"6.2. Encapsulation Layer Parameters 
6.2.1. Usage of Control Word 
TRUE value (default) of this Boolean parameter means that the CESoPSN
control word is used." 
It's not clear what "this Boolean parameter" is referring to.  Does this
refer to a bit in the RTP
payload?

Section 6.5.2. Re-Ordering and Loss of Packets:

"If loss of one or more CESoPSN packets has been detected at the egress of
the CESoPSN PW, its jitter buffer MUST be filled with the appropriate amount
of the AIS (or Idle - depending on the service type) code to be replayed
into the relevant PWES."

The following discussion may fall into the area of implementation
consideration:
Consider the behavior of the traditional slip buffer, where a loss of a
frame causes the
buffer to replay the last frame over again.  If a jitter buffer underflows
due to a loss of
a packet, replay the last frame rather than send AIS.  Sending AIS will
likely generate
a pop at the receiver, compared to replaying the last frame.  Replaying the
last frame
up to four times will improve the transmission quality over sending AIS.
After four 
frames, it is likely the downstream framer will go out of frame anyway, at
which point 
AIS should be sent.  

Thankyou
Ashwin

---

From: Sasha Vainshtein <[email-masked]>
Date: Wed, 9 Oct 2002 20:20:11 +0200

Ashwin and all,
Thank you for sending comments. 
Please see some answers inline.

With best regards,
                                   Sasha Vainshtein
email:     [email-masked] <mailto:[email-masked]> 
tel:       +972-3-7659993 (office)
           +972-8-9254948 (res.)
           +972-58-674833 (cell.)

> -----Original Message-----
> From: Ashwin Moranganti [mailto:[email-masked]]
> Sent: Wednesday, October 09, 2002 5:27 PM
> To: 'Sasha Vainshtein'; [email-masked]; Douglas Stahl
> Subject: Comments on the CESoPSN draft
> 
> 
> Sasha et al.
> 
Oops! It is a typo (remained from one of the previous versions of the
document).
Will fix it in the next release.
> but NOT force all one's in the payload?
Bit A is set at ingress if the a failure of the local AC is detected. 
The egress PE may use this information like following:
1. It MUST skip the check of the packet payload size:
   - normally such a check SHOULD be done in order to 
     detect malformed packets
   - packets with the A bit set MAY carry no payload, just the header
2. In case of n*DS0 it MAY decide to force outgoing AIS on its AC
    (just filling all ones on n*DS0 will not result in any defect of the AC
    being detected by the CE)
3. If packets with the A bit set are received for some time, an appropriate
alarm
    SHOULD be sent to the management station. This would allow fault
isolation
    without the need to access the ingress PE.
> Is there a reason why the use of Bit X is limited to N*DS0?  
We did not recognize such  a case but intended to allow this bit
for unstructured E1/T1 in any case.
I would be grateful for details.
> the PE to perform a terminal loopback (at the E1 or T1 LIU). 
We considered such an option in one of the earlier versions of the draft.
However, we decided to drop it for the following reasons:
1. We recognized the need to align the structure of the CW with that of
the SONET emulation drafts (as much as possible)
2. Loopback commands presumably should be sent via the PWE3 maintenance
protocol: there seems to be no real-time requirements.  
> Otherwise "T1-in-E1" looks informal, as if searching for a 
We shall consider a replacement. "Octet-aligned T1" looks 
like a good option.
> It's not clear what "this Boolean parameter" is referring to. 
>  Does this refer to a bit in the RTP payload?
The intention (probably poorly expressed) was that the two PEs must
agree upon usage of the control word, and "Usage of Control Word" is
the name of a Boolean parameter to be exchanged between the PEs
during the PW setup.
We consider making usage of the control word mandatory
in the next revision of the draft.
> frames, it is likely the downstream framer will go out of 
There are pros and cons in sending AIS vs. repeating the last packet
for unstructured services.
The idea of keeping the packet payload size aligned with the native
frame size means that you may prevent the receiver from going out of frame
either
(e.g. for unstructured E1 it would be enough to use packets that contain 8
frames).
On the other hand, I agree that handling of packet loss is a local matter,
so that
MUST is definitely inappropriate.
We will modify the text accordingly in the next revision.

---

From: Ashwin Moranganti <[email-masked]>
Date: Wed, 9 Oct 2002 15:44:48 -0400

Sasha, 

Thankyou for the prompt reply!

Here is an example of he X bit application to unstructured T1/E1 circutis

Consider a scenario where we have an unstructured T1 circuit.
A PE determines an incoming failure has occurred on a GigE 
fiber link between the PSN and the PE.  In response, the PE 
overwrites the payload with all ones and sends it downstream
to the CE.  The CE will send an RAI encoded in the payload in 
response to the AIS. This passes transparently through the 
PE in the other direction to the TDM device in the central office.
The equipment at the central office will detect the RAI and 
declare an alarm.  Without the extra information provided by 
the X bit, we won't know if the failure was caused by a T1 
line failure, or by the GigE link failure.  Of course, we have
the PWE3 maintenance protocol to alert and discover the 
problem, but a faster detection method might be useful, 
particularly if a redundant GigE link is available

Ashwin

-----Original Message-----
From: Sasha Vainshtein [mailto:[email-masked]]
Sent: Wednesday, October 09, 2002 2:20 PM
To: 'Ashwin Moranganti'
Cc: Alik Shimelmits; Akiva Sadovski; Israel Sasson; [email-masked];
Douglas Stahl
Subject: RE: Comments on the CESoPSN draft

Ashwin and all,

With best regards,
                                   Sasha Vainshtein

---

From: Akiva Sadovski <[email-masked]>
Date: Thu, 10 Oct 2002 14:39:25 +0200

Hi, Ashwin,

  see inline:

> Sent: Wednesday, October 09, 2002 9:45 PM
> To: 'Sasha Vainshtein'
> Cc: Alik Shimelmits; Akiva Sadovski; Israel Sasson; 
> [email-masked]; Douglas Stahl
> fiber link between the PSN and the PE. 

  Then, PE detects Loss Of Packets (see 6.5.2 for details)
and packets with bit R set  (Remote Loss Of Packets) will be sent
in the other detection and will provide us with the indication that the
problem is in the PSN, not in TDM.

 In response, the PE

---

From: Ashwin Moranganti <[email-masked]>
Date: Thu, 10 Oct 2002 10:20:41 -0400

Akiva

You make a good point.  We misunderstood the use
of bit R.  We thought its use was more of a running 
status of defects similar to reporting bit error rate 
rather than a declaration of a failure.  If it indeed
is a running status, then the failure determination
and notification must be done independently in two
different spots: the PE itself, and the equipment
at the PSN that terminates the control word.  Unless
extra care is taken, these two pieces of equipment 
may have different criteria for judging a failure. 

Ashwin 

-----Original Message-----
From: Akiva Sadovski [mailto:[email-masked]]
Sent: Thursday, October 10, 2002 8:39 AM
To: 'Ashwin Moranganti'; Sasha Vainshtein
Cc: [email-masked]; Douglas Stahl
Subject: [PWE3] RE: Comments on the CESoPSN draft

Hi, Ashwin,

 In response, the PE 
> We will modify the text accordingly in the next revision.
_______________________________________________
pwe3 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pwe3

---

From: Akiva Sadovski <[email-masked]>
Date: Tue, 15 Oct 2002 12:47:35 +0200

Ashwin,
  sorry for the delay;
  please see inline:

> Sent: Thursday, October 10, 2002 4:21 PM
> To: 'Akiva Sadovski'; Sasha Vainshtein
> Subject: RE: [PWE3] RE: Comments on the CESoPSN draft
> 
> 
> Akiva
> 
> rather than a declaration of a failure.  

  Good point. As i comprehend it, the R bit is a "running status" : each
time the PE detects packet loss at CESoPSN PW egress it plays out 
packet filled with AIS or Idle code and sets R bit ON in the opposite 
direction of the PW. See 6.5.2 for details.

If it indeed
> at the PSN that terminates the control word.  

  Now there may be two problems:

1) To produce failure indicator that may be propagated to the management
station. IMHO such indicator 
may be produced by some kind of "fault integration" or "stabilization"
algorithm (well known in TDM
systems) that checks the R bit value for persistency during given time
interval.

2) PE does not deal with the control word. Although CESoPSN draft doesn't
prescribe any specific PE architecture,
it is assumed (see 6.4) that control word monitorig/generation and
packetization/depacketization are performed by 
the same device - PE.

Unless