Re: About the Notify message in SUA

Prasanna,

>>  [IPSP mode] So that means receptor of ASPUP/ASPAC
>>  message has to send the Notify in this case also right?

Yes if it changes the state of the AS at the side that sent
the ASPUP or ASPAC. Then it must send NOTIFY after it sends
the ASPUP-Ack or ASPAC-Ack. This is the same as an SG does.

>>  Is it required to exchange 2 Notify message in case of IPSP-SE?

Maybe. In IPSP-SE mode, when you SEND an ASPAC-Ack response,
you mark the remote peer IPSP as ACTIVE. if that means the 
whole remote AS just became ACTIVE, then you must send a
NOTIFY message.

But when you SEND and ASPAC-Ack message it implies that you
are in ACTIVE state yourself (because of IPSP-SE mode). If 
you were not ACTIVE previously, and neither were any of your 
other local IPSPs in the same local AS, then your local AS 
also just became ACTIVE and the remote peer IPSP must send 
a NOTIFY to you (and to any UP/INACTIVE local IPSPs in the 
same local AS as you).

You send a NOTIFY when the state of the remote AS changes.
This doesn't always happen with one exchange of ASPAC and
ASPAC-Ack etc. One or other AS (or neither or both) may
become ACTIVE as a result of the single exchange.

I may not have described this very well (sorry), but it
does all equally apply to M3UA and SUA.

with thanks, from Chris Benson.

On Fri, 13 Nov 2009, Prasanna Kumar wrote:

>>  Date: Fri, 13 Nov 2009 18:27:01 +0530
>>  From: Prasanna Kumar <[email protected]>
>>  To:  <[email protected]>
>>  Subject: Re: [Sigtran] About the Notify message in SUA
>>  
>>  Hi,
>>  
>>  Thanks for your response. Have some doubts in case of IPSP mode. For
>>  IPSP mode, the RFC says that it will work in similar way to AS-SG
>>  mode. So that means receptor of ASPUP/ASPAC message has to send the
>>  Notify in this case also right?
>>  
>>  Is it required to exchange 2 Notify message in case of IPSP-SE? If
>>  not, which one has to send the Notify message (weather receiver/sender
>>  of ASPUP/ASPAC)? The RFC says any one can send so, is this
>>  implementation dependent? Following is the RFC section:
>>  
>>  4.3.4.5.1.  IPSP Considerations (NTFY)
>>  "Notify works in the same manner as in the SG-AS case.  One of the
>>  IPSPs can send this message to any remote IPSP that is not in the
>>  ASP-DOWN state."
>>  
>>  Regards,
>>  Prasanna.
>>  
>>  On Thu, Nov 12, 2009 at 9:31 PM, Rabindra Nath Tiwari
>>  <[email protected]> wrote:
>>  > Hi Prasanna,
>>  >
>>  >
>>  >
>>  >
>>  >
>>  > Following is the second last sentence of the paragraph you have pointed: -
>>  >
>>  > "The Notify message must be sent whether the AS
>>  >
>>  > state change was a result of an ASP failure or reception of an ASP
>>  >
>>  > State management (ASPSM) / ASP Traffic Management (ASPTM) message."
>>  >
>>  >
>>  >
>>  >
>>  >
>>  > Here, at the second part of this sentence RFC talks about transmission of
>>  > NOTIFY on the reception of ASPSM/ASPTM message.
>>  >
>>  >
>>  >
>>  > And following is the last sentence of the paragraph.
>>  >
>>  >
>>  >
>>  > "In
>>  >
>>  > the second case, the Notify message MUST be sent after any ASP State
>>  >
>>  > or Traffic Management related acknowledgement messages  (e.g., ASP Up
>>  >
>>  > Ack, ASP Down Ack, ASP Active Ack, or ASP Inactive Ack)."
>>  >
>>  >
>>  >
>>  >
>>  >
>>  > Here RFC talks about the ordering of the ASPTM/ASPSM-ACK messages and NOTIFY
>>  > messages being transmitted from the receiver of the ASPTM/ASPSM messages.
>>  > And mentions that the NOIIFY message MUST be sent (from the receiver of
>>  > ASPSM/ASPTM message) after sending the respective ASPSM/ASPTM ACK messages.
>>  >
>>  >
>>  >
>>  > To conclude, the transmitter of the ACK message will send the NOTIFY
>>  > message, but only after transmitting the respective ACK message.
>>  >
>>  > This is mandated so that the state machines for peer (ASP) at the receiver
>>  > (of ACK and NOTIFY messages) would already be updated by the time NOTIFY
>>  > message will be received (as then only the NOTIFY message for AS state
>>  > change would make sense).
>>  >
>>  >
>>  >
>>  >
>>  >
>>  > Also, ASP management procedures are same across M3UA and SUA. And the same
>>  > paragraph can be found in the M3UA RFC 4666, at the same section number.
>>  >
>>  >
>>  >
>>  >
>>  >
>>  > Thanks and Regards,
>>  >
>>  > Rabindra Nath Tiwari
>>  >
>>  >
>>  >
>>  > -----Original Message-----
>>  > From: [email protected] [mailto:[email protected]] On Behalf
>>  > Of Prasanna Kumar
>>  > Sent: Thursday, November 12, 2009 3:11 PM
>>  > To: [email protected]
>>  > Subject: [Sigtran] About the Notify message in SUA
>>  >
>>  >
>>  >
>>  > Hi,
>>  >
>>  >
>>  >
>>  > The SUA RFC 3868 say about the notify message as follows.
>>  >
>>  >
>>  >
>>  > 4.3.4.5.  Notify Procedures
>>  >
>>  >    A Notify message reflecting a change in the AS state MUST be sent
>>  >
>>  > to all ASPs in the AS, except those in the ASP-DOWN state, with
>>  >
>>  > appropriate Status Information and any ASP Identifier of the failed
>>  >
>>  > ASP.  At the ASP, Layer Management is informed with an M-NOTIFY
>>  >
>>  > indication primitive.  The Notify message must be sent whether the AS
>>  >
>>  > state change was a result of an ASP failure or reception of an ASP
>>  >
>>  > State management (ASPSM) / ASP Traffic Management (ASPTM) message. "In
>>  >
>>  > the second case, the Notify message MUST be sent after any ASP State
>>  >
>>  > or Traffic Management related acknowledgement messages  (e.g., ASP Up
>>  >
>>  > Ack, ASP Down Ack, ASP Active Ack, or ASP Inactive Ack)."
>>  >
>>  >
>>  >
>>  > Here it refers the second case in last line, which says that the
>>  >
>>  > "Notify message must be sent after the ACK message for the
>>  >
>>  > ASPTM/ASPSM". Here does it mean that the receiver of the ACK (ACK
>>  >
>>  > message for ASPTM/ASPSM) message has to send the Notify message?
>>  >
>>  >
>>  >
>>  > Please clarify and thanks in advance.
>>  >
>>  >
>>  >
>>  > Regards,
>>  >
>>  > Prasanna.
>>  >
>>  > _______________________________________________
>>  >
>>  > Sigtran mailing list
>>  >
>>  > [email protected]
>>  >
>>  > https://www.ietf.org/mailman/listinfo/sigtran
>>  _______________________________________________
>>  Sigtran mailing list
>>  [email protected]
>>  https://www.ietf.org/mailman/listinfo/sigtran
>>