Subject: [PWE3] Need clarification on Extended NxDS0 with CAS - RFC 5086

From: "Mahesh Singh C" <[email-masked]>
Date: Thu, 12 Jun 2008 18:12:08 +0530

Hi All,

 I have some doubts on Extended NxDS0 CAS mode setup. I have listed them
below.

a.       Does the packet latency specified for Basic NxDS0 holds good
for Extended NxDS0 mode with CAS. Because, when we say CAS, are we not
trunk-specific.

b.       When ever we need CAS, the TDM interface should be in multi
frame mode. It can be 16 frames or 24 frames based on E1 or T1
interface. But if we configure for 1 ms packet latency then we are
required to send data for each 8 frames as payload. But CAS retrieval
aligns to SF number of frames (16 or 24). Does this mean, do we need to
send previously stored CAS state.

c.       My second doubt is on two pseudowires. One for CAS and one for
data. How does the user see this. For example, Does single configuration
to enable two pseudowires is required or separate configuration for two
pseudowires is recommended. In the later case, though they are
configured in sequence for CAS pseudowire and data pseudowire, do we
need to enable them at same time. Can signaling PW become active first
and data PW after some time.

Regards,

Mahesh

DISCLAIMER:
-----------------------------------------------------------------------------------------------------------------------

The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only.
It shall not attach any liability on the originator or HCL or its affiliates. Any views or opinions presented in 
this email are solely those of the author and may not necessarily reflect the opinions of HCL or its affiliates.
Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of 
this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have 
received this email in error please delete it and notify the sender immediately. Before opening any mail and 
attachments please check them for viruses and defect.

-----------------------------------------------------------------------------------------------------------------------

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

---

From: Alexander Vainshtein <[email-masked]>
Date: Fri, 13 Jun 2008 00:03:39 +0300

Hi Mahesh,
The packet latency specified for basic NxDS0 CESoPSN PWs is not related to the latency of the signaling packets carrying CAS when this service is extended to carry CAS. In fact, the notion of packet latency is not applicable to these packets, since they are not transmitted periodically.

Extension of the Basic NxDS0 CESoPSN service with CAS is based on the reference PE architecture described in Appendix B of RFC 5086. It assumes that the Framer identifies the changes in the CE Application state (specifically, change in the CAS bits associated with any of the DS0 channels comprising the basic NxDS0 service) and triggers transmission of the signaling packet carrying the new state. A more detailed description of the transmission logic of the signaling packets is given in Appendix A. This logic provides for resilience against occasional loss of the signaling packets and deterministic recovery of the CE application state upon recovery from the packet loss state. In particular, this logic includes transmission of the signaling packet when the (basic) CESoPSN PW has been set up. In order to meet this requirement while using separate PWs for carrying TDM PW and CE application signaling, the PW carrying the signaling packets must be set up before the PW that carries TDM data.

Hopefully these notes address your concerns.

Regards,
          Sasha

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Mahesh Singh C
Sent: Thursday, June 12, 2008 3:42 PM
To: [email-masked]
Subject: [PWE3] Need clarification on Extended NxDS0 with CAS - RFC 5086

Hi All,

 I have some doubts on Extended NxDS0 CAS mode setup. I have listed them below.

a.       Does the packet latency specified for Basic NxDS0 holds good for Extended NxDS0 mode with CAS. Because, when we say CAS, are we not trunk-specific.
b.       When ever we need CAS, the TDM interface should be in multi frame mode. It can be 16 frames or 24 frames based on E1 or T1 interface. But if we configure for 1 ms packet latency then we are required to send data for each 8 frames as payload. But CAS retrieval aligns to SF number of frames (16 or 24). Does this mean, do we need to send previously stored CAS state.
c.       My second doubt is on two pseudowires. One for CAS and one for data. How does the user see this. For example, Does single configuration to enable two pseudowires is required or separate configuration for two pseudowires is recommended. In the later case, though they are configured in sequence for CAS pseudowire and data pseudowire, do we need to enable them at same time. Can signaling PW become active first and data PW after some time.

Regards,
Mahesh

DISCLAIMER:

---

From: "Mahesh Singh C" <[email-masked]>
Date: Fri, 13 Jun 2008 14:11:16 +0530

Hi Alex,

 Thanks for the reply. It is addressing my concerns.

Thanks & Regards,

Mahesh

From: Alexander Vainshtein [mailto:[email-masked]] 
Sent: Friday, June 13, 2008 2:34 AM
To: Mahesh Singh C
Cc: [email-masked]
Subject: RE: Need clarification on Extended NxDS0 with CAS - RFC 5086

Hi Mahesh,

The packet latency specified for basic NxDS0 CESoPSN PWs is not related
to the latency of the signaling packets carrying CAS when this service
is extended to carry CAS. In fact, the notion of packet latency is not
applicable to these packets, since they are not transmitted
periodically.

Extension of the Basic NxDS0 CESoPSN service with CAS is based on the
reference PE architecture described in Appendix B of RFC 5086. It
assumes that the Framer identifies the changes in the CE Application
state (specifically, change in the CAS bits associated with any of the
DS0 channels comprising the basic NxDS0 service) and triggers
transmission of the signaling packet carrying the new state. A more
detailed description of the transmission logic of the signaling packets
is given in Appendix A. This logic provides for resilience against
occasional loss of the signaling packets and deterministic recovery of
the CE application state upon recovery from the packet loss state. In
particular, this logic includes transmission of the signaling packet
when the (basic) CESoPSN PW has been set up. In order to meet this
requirement while using separate PWs for carrying TDM PW and CE
application signaling, the PW carrying the signaling packets must be set
up before the PW that carries TDM data.

Regards,

          Sasha

	

	From: [email-masked] [mailto:[email-masked]] On
Behalf Of Mahesh Singh C
	Sent: Thursday, June 12, 2008 3:42 PM
	To: [email-masked]
	Subject: [PWE3] Need clarification on Extended NxDS0 with CAS -
RFC 5086

	Hi All,

	 I have some doubts on Extended NxDS0 CAS mode setup. I have
listed them below.

	a.       Does the packet latency specified for Basic NxDS0 holds
good for Extended NxDS0 mode with CAS. Because, when we say CAS, are we
not trunk-specific.

	b.       When ever we need CAS, the TDM interface should be in
multi frame mode. It can be 16 frames or 24 frames based on E1 or T1
interface. But if we configure for 1 ms packet latency then we are
required to send data for each 8 frames as payload. But CAS retrieval
aligns to SF number of frames (16 or 24). Does this mean, do we need to
send previously stored CAS state.

	c.       My second doubt is on two pseudowires. One for CAS and
one for data. How does the user see this. For example, Does single
configuration to enable two pseudowires is required or separate
configuration for two pseudowires is recommended. In the later case,
though they are configured in sequence for CAS pseudowire and data
pseudowire, do we need to enable them at same time. Can signaling PW
become active first and data PW after some time.

	Regards,

	Mahesh

DISCLAIMER:
------------------------------------------------------------------------
-----------------------------------------------

The contents of this e-mail and any attachment(s) are confidential and
intended for the named recipient(s) only.
It shall not attach any liability on the originator or HCL or its
affiliates. Any views or opinions presented in 
this email are solely those of the author and may not necessarily
reflect the opinions of HCL or its affiliates.
Any form of reproduction, dissemination, copying, disclosure,
modification, distribution and / or publication of 
this message without the prior written consent of the author of this
e-mail is strictly prohibited. If you have 
received this email in error please delete it and notify the sender
immediately. Before opening any mail and 
attachments please check them for viruses and defect.

------------------------------------------------------------------------
-----------------------------------------------