Chronological Thread 

< Chronological >      < Thread >

---

Sundaresan,

On Wed, 02 Jan 2002, Sundaresan M wrote:

> Hi,
>
> In IUA RFC3057, section 3.3.3.2 titles as Status Identification,
> Application Server Down (AS_DOWN) with value as 1.
>
> Meaning, this Notify is sent to inform that all ASP's in the AS are in DOWN
> state. But section 4.3.3.6 of the same RFC contradicts this by saying that
> Notify Messages are only sent to ASP's which are minumum in inactive state
> (or) in other words Notify is not sent to ASP's in Down state.

Correct. IUA missed removal of the NTFY(AS_Down). It is rather useless.

>
> So this explicitly says that
>
> "There is no need for a Application Server state, AS-DOWN"

There is a need for the state AS-DOWN. It is different than AS-INACTIVE and
AS-PENDING. Particularly in the actions that an SG takes towards the network.


>
> If there is any contradicting talk on this statement please pass it on.

I have attached the mail thread from the SIGTRAN archives that occured over
a year ago, that finally led to NTFY(AS_Down) being removed in M3UA-04 in
September 2000. It was agreed that there was no situation in which an SG
could send NTFY(AS_Down) because there was no ASP that one could send it to.

There were some other views...

--brian


>
> Best Regards,
> Sundar.
>
> -----Original Message-----
> From: Brian F. G. Bidulock
> [mailto:bidulock AT openss7.org]
> Sent: Monday, 31 December 2001 11:49 AM
> To: Sundaresan M
> Cc:
> discussion AT sctp.de
> Subject: Re: Another situation on Notify Message Treatment
>
>
> Sundaresan,
>
> On Mon, 31 Dec 2001, Sundaresan M wrote:
>
> > Hi Brian and group,
> >
> > Thanks for the reply. Now I have an entirely different situation.
> >
> > I am working with Version 06 of M3UA. In this version we dont have the
> > concept of ASP Identifier to identify individual ASP's. So how can this be
> > managed (I am designing a conformance suite for M3UA-06 and hence I cannot
> > use latest versions of M3UA, I have to stick to version 06 only).
>
> You would think that 3GPP would have been intelligent enough to not
> reference an IETF draft. Nevertheless, for any version of M3UA draft,
> ASP Identifier is not required in an ASP Up in situations where the the
> SGP can always identify the ASP using exotropic means such as the IP
> address and SCTP port number of the connecting ASP.
>
> >
> > As u have said I too was designing the Notify message so that it is sent
> to
> > every ASP in the AS except for those ones in the Down state. But, imagine
> > this situation.
> >
> > Configuration: Two ASP's and One SG.
> > ASP1: Already in Active State
> > ASP2: Working in Override mode, Comes to Active State.
> >
> > Now once ASP2 comes to Active state SG will send Notify to both the ASP's
> > with an Status Identification "Alternate ASP Active".
> >
> > I understand that now SG will stop sending the traffic to ASP 1 from now
> on.
> >
> > My questions are: If there is no ASP Identifiers existing to identify
> ASP's
> > then how will the ASP1
> > 1) differentiate that he has to stop processing traffic from that SG and
> > will take further steps to either bring itself to Inactive state if is not
> > serving anyother AS.
> > 2)know that it is only ASP2 which took over the traffic. But before this,
> is
> > there a need for ASP1 to know that ASP2 has taken over the traffic for
> that
> > SG.
>
> Well, that was why ASP Identifier was added to M3UA. If you wish to
> used the broken M3UA-06 (and--believe me--it is broken: just see the
> comments on the SIGTRAN mailing list for M3UA-06 to see in just how many
> ways it is broken...) then ASP1 will have to determine from ASP2 using
> an unspecified (and therefore, untestable) ASP to ASP communication
> protocol.
>
> >
> > 3) Since ASP2 also recieves this Notify message what if he thinks that
> some
> > other ASP had taken over the traffic.
>
> Even in the broken M3UA-06, ASP2 should know that it has become active
> because it sent the ASPAC that cause the override. If you are thinking
> that ASP2 might have a race with, say, ASP3, then it falls back to the
> unspecified ASP-to-ASP communication ensure that things are done
> atomically and that there are no races.
>
> In M3UA-10 (extremely close to RFC) even if multiple ASPs race, or get
> partitioned from each other so that ASP-to-ASP communication is not
> possible, each ASP is notified of which ASP has taken over in the
> override group via the ASP Identifier in the NTFY.
>
> If you have any choice whatsoever, I would spend my time lobbying 3GPP
> to update to the RFC version of M3UA and remove references to expired
> internet drafts.
>
> If you are developing test cases for M3UA-06, you might want to take a
> look at the M3UA-05 test spec that is still available on the IETF server
> at:
>
> ftp://ftp.ietf.org/internet-drafts/draft-hss-test-spec-m3ua-00.txt
>
> The author of this draft (Ashok Singh at HSS) might also have a M3UA
> draft 6 version of the document, but you will have to contact Hughes for
> that. The email address is in the draft.
>
> Hope that helps.
>
> --brian
>
> >
> > Best Regards,
> > Sundar.
> >
> >
> >
> > -----Original Message-----
> > From: Brian F. G. Bidulock
> > [mailto:bidulock AT openss7.org]
> > Sent: Sunday, 30 December 2001 6:38 PM
> > To: Sundaresan M
> > Cc:
> > discussion AT sctp.de
> > Subject: Re: [SCTP-Discussion] Notify Message Treatment
> >
> >
> > Sundaresan,
> >
> > On Sat, 29 Dec 2001, Sundaresan M wrote:
> >
> > > Hi,
> > >
> > > I would like to know how the Motify messages are treated in the
> Adaptation
> > > layers like IUA, M3UA etc.
> > >
> > > QUESTION 1
> > > **********
> > > Configuration 1: One ASP and One SG
> > > -------------------------------------
> > > ASP is moving from Inactive state to Active state. Now the AS state
> > changes
> > > from AS_INACTIVE to AS_ACTIVE. Will a Notify message be sent by the SG
> to
> > > this one and only ASP in the Configuration. Will this treatment change
> > > depending on the AS_STATE change also. What I mean is, if the state
> > changes
> > > from Active to Inactive will this ASP(being the last one in the AS)
> > receive
> > > a Notify(AS_PENDING)!!
> >
> > "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
> > appopriate Status Information and any ASP Identifier of the failed
> > ASP." - M3UA-10
> >
> > A Notify("AS-Pending") "MUST" be sent to the ASP.
> >
> > >
> > > QUESTION 2
> > > ***********
> > > Configuration 2: Two ASP's (ASP1 and ASP2) with One SG:
> > > ------------------------------------------------------
> > > ASP 1 : Active
> > > ASP 2 : Inactive
> > >
> > > Now ASP1 moves from Active to Inactive due to LM primitives. Will the
> > > Notify(AS_PENDING) message be sent to Both ASP1 and ASP2 serving the SG?
> > or
> > > will it be sent only to ASP2.
> >
> > "If no other ASPs in the Application Server are in the state
> > ASP-ACTIVE, the SGP MUST send a Notify message ("AS-Pending") to
> > all of the ASPs in the AS which are in the state AS-INACTIVE."
> > - M3UA-10
> >
> > The message "MUST" be sent to both ASP1 and ASP2.
> >
> > >
> > > QUESTION 3
> > > **********
> > > Will the AS_STATE be maintained in the database by the individual ASP's.
> >
> > The ASP will need to know what state it is in for each AS that it serves.
> >
> > >
> > > QUESTION 4
> > > **********
> > > Some Stack implementors say that NOTIFY message treatment is optional.
> > Does
> > > this mean that the usage of the Notify itself is optional. If it is so
> > then
> > > how will the ASP's know the AS_state and will act on AS_State changes?
> >
> > Sending of the Notify message is not optional. The response of the ASP to
> > the
> > Notify message is not proscribed. There is a difference. Notify messages
> > are considered advisory in that it is up to the ASP to consider the
> > information in the Notify message and other information that it has at its
> > disposal (such as a knowledge of the state of other ASPs) before deciding
> > what
> > action to take.
> >
> > Hope that helps.
> >
> > --brian
> >
>
> --
> Brian F. G. Bidulock ¦ The reasonable man adapts himself to the ¦
> bidulock AT openss7.org
> ¦ world; the unreasonable one persists in ¦
> http://www.openss7.org/ ¦ trying to adapt the world to himself. ¦
> ¦ Therefore all progress depends on the ¦
> ¦ unreasonable man. -- George Bernard Shaw ¦
>
> _______________________________________________
> discussion mailing list
> discussion AT sctp.de
> http://www.sctp.de/mailman/listinfo/discussion

--
Brian F. G. Bidulock ¦ The reasonable man adapts himself to the ¦
bidulock AT openss7.org
¦ world; the unreasonable one persists in ¦
http://www.openss7.org/ ¦ trying to adapt the world to himself. ¦
¦ Therefore all progress depends on the ¦
¦ unreasonable man. -- George Bernard Shaw ¦

--- Begin Message ---

• From: Greg Sidebottom <gregside AT NORTELNETWORKS.COM>
• To: SIGTRAN AT STANDARDS.NORTELNETWORKS.COM
• Subject: Re: NTFY in m2ua/m3ua
• Date: Fri, 1 Sep 2000 12:58:28 -0400

Title: RE: NTFY in m2ua/m3ua

Greetings Klaus and John ...

-----Original Message-----
From: Gradischnig Klaus [mailto:Klaus.Gradischnig AT ICN.SIEMENS.DE]
Sent: Thursday, August 31, 2000 9:29 AM
To: SIGTRAN AT STANDARDS.NORTELNETWORKS.COM
Subject: Re: NTFY in m2ua/m3ua

Hi John,

I can live with either solution though I prefer the simpler model and one which is consistent in all our UAs. Anything more complex should go into RSPOOL.

If we keep a separate Down state, however, we should not send any messages to an ASP in the Down state, otherwise, where's the difference to the Inactive state?

[Greg] I agree

Cheers,

- Klaus

Klaus D. Gradischnig
> SIEMENS
Information and Communication Networks
Wireline Network Communication
Carrier Switching Networks
WN CS SEN 51

Tel:    +49 89 722 63197
Fax:    +49 89 722 48212
E-mail Klaus.Gradischnig AT ICN.Siemens.DE

> -----Original Message-----
> From: john.loughney AT nokia.com [SMTP:john.loughney AT nokia.com]
> Sent: Thursday, August 31, 2000 2:17 PM
> To:   Klaus.Gradischnig AT ICN.SIEMENS.DE; SIGTRAN AT STANDARDS.NORTELNETWORKS.COM
> Subject:      RE: NTFY in m2ua/m3ua
>
> Hi Klaus,
>
> A few comments:
>
> > if the Down state is the same as the Inactive state wrt
> > message handling as you seem to propose, then we do not need
> > it nor the ASPUP/DOWN messages. Whenever the SCTP association
> > is up, so is the ASP and vice-versa. This seems to make
> > sense. For an SCTP association to be established it seems to
> > me that  the ASP has to be up anyway, so...
> >
> > I really like this idea. It would make things a lot simpler.
> > I am all for it.
>

[Greg]  Unfortunately I don't think we should remove the ASP-UP/Down procedures. As I mentioned, I don't think the procedures have anything to do with configuration management, although I can accept that it could be used in this way for some implementations. The ASP-Up/Down protocol was intended to be a "check" that the ASP is now ready/not_ready to receive messages at the M3UA level, independent of the readiness at the SCTP layer. A close analogy would be the Signalling Link Test in SS7 MTP3, where a link may have been configured/enabled but we want to confirm that at the MTP3 peers before proceeding to put any traffic on the link. 

In this context my previous comments about sending (non-Data) traffic to a "Down" ASP is probably incorrect.  As Klaus mentions above, we shouldn't send traffic to a Down ASP.  This makes things pretty simple as well as there would be some difficulty in having the SG determining whether a particular ASP is Inactive/Down or has in fact been removed from the configuration.

> I've always thought that we would keep the application
> seperate from the transport.  You may have an association
> established, but the application may not be ready to
> handle traffic.  Also, if the application crashes, you
> may still have an active association.
>
> Of course, if we go with your suggestion, we create a simpler
> model.  The more I think about this, the more I am in favor
> of creating a simpler model.  I believe that work being done
> elsewhere (RSPOOL) will be applicable to all of the adaptation
> layers, therefore, I think we should adopt a simple model
> and transition to RSPOOL when that work is ready.
>
> comments?
> John

[Greg] I agree that the simpler the better, of course.  The M3UA is already written such that it should be very easy in a future release to pick up the RSPOOL work.  In the current draft, the Routing Key points to an Application Server Name which in turn points to a pool of ASPs.  In the future (i.e., when an RSPOOL protocol is ready), the AS Name could be used to instead tie to the RSPOOL function and let the RSPOOL layer handle the server pool management.  The ASPM part of the M3UA protocol would completely drop out.   In fact I think that the DDP is remarkably consistent with the current M3UA AS/ASP mechanism. (I think that we need to collect the M3UA requirements in this area and submit them to RSPOOL to ensure that this goes smoothly).

Cheers,

    Greg

--- End Message ---

--- Begin Message ---

• From: Gradischnig Klaus <Klaus.Gradischnig AT ICN.SIEMENS.DE>
• To: SIGTRAN AT STANDARDS.NORTELNETWORKS.COM
• Subject: Re: NTFY in m2ua/m3ua
• Date: Thu, 31 Aug 2000 15:28:53 +0200

Hi John,

I can live with either solution though I prefer the simpler model and one
which is consistent in all our UAs. Anything more complex should go into
RSPOOL.

If we keep a separate Down state, however, we should not send any messages to
an ASP in the Down state, otherwise, where's the difference to the Inactive
state?

Cheers,

- Klaus


Klaus D. Gradischnig
> SIEMENS
Information and Communication Networks
Wireline Network Communication
Carrier Switching Networks
WN CS SEN 51

Tel: +49 89 722 63197
Fax: +49 89 722 48212
E-mail
Klaus.Gradischnig AT ICN.Siemens.DE

> -----Original Message-----
> From:
> john.loughney AT nokia.com
>
> [SMTP:john.loughney AT nokia.com]
> Sent: Thursday, August 31, 2000 2:17 PM
> To:
> Klaus.Gradischnig AT ICN.SIEMENS.DE;
>
> SIGTRAN AT STANDARDS.NORTELNETWORKS.COM
> Subject: RE: NTFY in m2ua/m3ua
>
> Hi Klaus,
>
> A few comments:
>
> > if the Down state is the same as the Inactive state wrt
> > message handling as you seem to propose, then we do not need
> > it nor the ASPUP/DOWN messages. Whenever the SCTP association
> > is up, so is the ASP and vice-versa. This seems to make
> > sense. For an SCTP association to be established it seems to
> > me that the ASP has to be up anyway, so...
> >
> > I really like this idea. It would make things a lot simpler.
> > I am all for it.
>
> I've always thought that we would keep the application
> seperate from the transport. You may have an association
> established, but the application may not be ready to
> handle traffic. Also, if the application crashes, you
> may still have an active association.
>
> Of course, if we go with your suggestion, we create a simpler
> model. The more I think about this, the more I am in favor
> of creating a simpler model. I believe that work being done
> elsewhere (RSPOOL) will be applicable to all of the adaptation
> layers, therefore, I think we should adopt a simple model
> and transition to RSPOOL when that work is ready.
>
> comments?
> John

--- End Message ---

--- Begin Message ---

• From: John Loughney <john.loughney AT NOKIA.COM>
• To: SIGTRAN AT STANDARDS.NORTELNETWORKS.COM
• Subject: Re: NTFY in m2ua/m3ua
• Date: Thu, 31 Aug 2000 15:17:12 +0300

Hi Klaus,

A few comments:

> if the Down state is the same as the Inactive state wrt
> message handling as you seem to propose, then we do not need
> it nor the ASPUP/DOWN messages. Whenever the SCTP association
> is up, so is the ASP and vice-versa. This seems to make
> sense. For an SCTP association to be established it seems to
> me that the ASP has to be up anyway, so...
>
> I really like this idea. It would make things a lot simpler.
> I am all for it.

I've always thought that we would keep the application
seperate from the transport. You may have an association
established, but the application may not be ready to
handle traffic. Also, if the application crashes, you
may still have an active association.

Of course, if we go with your suggestion, we create a simpler
model. The more I think about this, the more I am in favor
of creating a simpler model. I believe that work being done
elsewhere (RSPOOL) will be applicable to all of the adaptation
layers, therefore, I think we should adopt a simple model
and transition to RSPOOL when that work is ready.

comments?
John

--- End Message ---

--- Begin Message ---

• From: Gradischnig Klaus <Klaus.Gradischnig AT ICN.SIEMENS.DE>
• To: SIGTRAN AT STANDARDS.NORTELNETWORKS.COM
• Subject: Re: NTFY in m2ua/m3ua
• Date: Wed, 30 Aug 2000 15:00:47 +0200

Greg,

if the Down state is the same as the Inactive state wrt message handling as
you seem to propose, then we do not need it nor the ASPUP/DOWN messages.
Whenever the SCTP association is up, so is the ASP and vice-versa. This seems
to make sense. For an SCTP association to be established it seems to me that
the ASP has to be up anyway, so...

I really like this idea. It would make things a lot simpler. I am all for it.

- Klaus


Klaus D. Gradischnig
> SIEMENS
Information and Communication Networks
Wireline Network Communication
Carrier Switching Networks
WN CS SEN 51

Tel: +49 89 722 63197
Fax: +49 89 722 48212
E-mail
Klaus.Gradischnig AT ICN.Siemens.DE

> -----Original Message-----
> From: Greg Sidebottom
> [SMTP:gregside AT NORTELNETWORKS.COM]
> Sent: Tuesday, August 29, 2000 8:59 PM
> To:
> SIGTRAN AT STANDARDS.NORTELNETWORKS.COM
> Subject: Re: NTFY in m2ua/m3ua
>
> Greetings Klaus and Naoto,
>
> Responses in-line...
>
> -----Original Message-----
> From: Naoto MAKINAE [
> <mailto:makinae.naoto AT LAB.NTT.CO.JP>]
> Sent: Tuesday, August 29, 2000 7:48 AM
> To:
> SIGTRAN AT STANDARDS.NORTELNETWORKS.COM
> Subject: Re: NTFY in m2ua/m3ua
>
>
> Klaus and All,
>
> > If these questions/comments have already been answered, my appologies,
> > but...
> >
> > 1. To whom would one send a NTFY AS_Down? Seems somewhat difficult to
> > find
> > any ASP in this situation ;-)
>
> You can find an example of NTFY(AS-Down) in 5.2.1. I believe, however, this
> should be
> changed to NTFY(AS-Pending). So, I share the same question with you.
>
> [Greg] Good point - it should be NTFY (AS_Pending) as you say. As a
> follow-on question - do we want also to send a NTFY (AS_Down) if the AS
> later transitions from AS_Pending to AS_Down?
>
> As for the transition to AS_Down, Klaus has a point - is there is really
> somebody to talk to? I think that generally speaking it is possible you
> could have ASP(s) configured in an AS that have either 1) never come "Up",
> or 2) were "Up" previously but are now "Down". So the more general
> question is: Should the SG (or IPSP) send any non-Data M3UA messages to
> these nodes. I suggest "yes" but I'd be interested to hear what people
> think.
>
> I think those that would view ASP-Up and ASP-Down as an ASP explicitly
> entering/exiting an AS configuration would probably say "no". But I've
> always held that this is not necessarily the case as you could have ASPs
> configured into an AS by other means (pre-configured, use SNMP, future
> RSPOOL protocol, ...). They may be able to process some M3UA messages
> (i.e., non-Data messages such as SSNM, ASP State maintenance, ...). We
> agreed in Pittsburgh with the suggestion that an ASP that is "Inactive"
> could process SSNM messages. We could allow it to receive any non-Data
> message. In the 'Down" state we could allow it as well.
>
>
>
> > 2. I propose to rename the state AS_Up to AS_Inactive. If the AS is not
> > down it
> > must be up, but what seems interesting
> > then is the particular flavor of upness.
>
> Either would be fine with me.
>
> [Greg] I agree - let's change it to AS_Inactive. This has caused confusion
> a couple of times now and this proposal would make it clearer.
>
> Thanks and Cheers,
>
> Greg
>
> - AS_Down is the state where no ASPs in the AS are up.
> - AS_Up, or AS_Inactive in your terminology, is the state where at least
> one ASP in the AS is up,
> but all of them are inactiive.
> - AS_Active is the state where at least one ASP in the AS is active.
>
> naoto
>

--- End Message ---

--- Begin Message ---

• From: Greg Sidebottom <gregside AT NORTELNETWORKS.COM>
• To: SIGTRAN AT STANDARDS.NORTELNETWORKS.COM
• Subject: Re: NTFY in m2ua/m3ua
• Date: Tue, 29 Aug 2000 14:58:57 -0400

Title: RE: NTFY in m2ua/m3ua

Greetings Klaus and Naoto,

Responses in-line...

-----Original Message-----
From: Naoto MAKINAE [mailto:makinae.naoto AT LAB.NTT.CO.JP]
Sent: Tuesday, August 29, 2000 7:48 AM
To: SIGTRAN AT STANDARDS.NORTELNETWORKS.COM
Subject: Re: NTFY in m2ua/m3ua

Klaus and All,

> If these questions/comments have already been answered, my appologies, but...
>
> 1. To whom would one send a NTFY AS_Down? Seems somewhat difficult  to find
> any ASP in this situation ;-)

You can find an example of NTFY(AS-Down) in 5.2.1. I believe, however, this should be
changed to NTFY(AS-Pending). So, I share the same question with you.

[Greg] Good point - it should be NTFY (AS_Pending) as you say.    As a follow-on question - do we want also to send a NTFY (AS_Down) if the AS later transitions from AS_Pending to AS_Down?

As for the transition to AS_Down, Klaus has a point - is there is really somebody to talk to?   I think that generally speaking it is possible you could have ASP(s) configured in an AS that have either 1) never come "Up", or 2) were "Up" previously but are now "Down".   So the more general question is:  Should the SG (or IPSP) send any non-Data M3UA messages to these nodes.  I suggest "yes" but I'd be interested to hear what people think.

I think those that would view ASP-Up and ASP-Down as an ASP explicitly entering/exiting an AS configuration would probably say "no".   But I've always held that this is not necessarily the case as you could have ASPs configured into an AS by other means (pre-configured, use SNMP, future RSPOOL protocol, ...).  They may be able to process some M3UA messages (i.e., non-Data messages such as SSNM, ASP State maintenance, ...).    We  agreed in Pittsburgh with the suggestion that an ASP that is "Inactive" could process SSNM messages.  We could allow it to receive any non-Data message.  In the 'Down" state we could allow it as well.  

> 2. I propose to rename the state AS_Up to AS_Inactive. If the AS is not down it
> must be up, but what seems interesting
> then is the particular flavor of upness.

Either would be fine with me.

[Greg] I agree - let's change it to AS_Inactive.  This has caused confusion a couple of times now and this proposal would make it clearer.

Thanks and Cheers,

        Greg

 - AS_Down is the state where no ASPs in the AS are up.
 - AS_Up, or AS_Inactive in your terminology, is the state where at least one ASP in the AS is up,
   but all of them are inactiive.
 - AS_Active is the state where at least one ASP in the AS is active.

naoto

--- End Message ---

--- Begin Message ---

• From: Naoto MAKINAE <makinae.naoto AT lab.ntt.co.jp>
• To: SIGTRAN AT STANDARDS.NORTELNETWORKS.COM
• Subject: Re: NTFY in m2ua/m3ua
• Date: Tue, 29 Aug 2000 20:48:25 +0900
• Importance: Normal

Klaus and All,

> If these questions/comments have already been answered, my appologies,
> but...
>
> 1. To whom would one send a NTFY AS_Down? Seems somewhat difficult to find
> any ASP in this situation ;-)

You can find an example of NTFY(AS-Down) in 5.2.1. I believe, however, this
should be
changed to NTFY(AS-Pending). So, I share the same question with you.

> 2. I propose to rename the state AS_Up to AS_Inactive. If the AS is not
> down it
> must be up, but what seems interesting
> then is the particular flavor of upness.

Either would be fine with me.

- AS_Down is the state where no ASPs in the AS are up.
- AS_Up, or AS_Inactive in your terminology, is the state where at least one
ASP in the AS is up,
but all of them are inactiive.
- AS_Active is the state where at least one ASP in the AS is active.

naoto

--- End Message ---

--- Begin Message ---

• From: Gradischnig Klaus <Klaus.Gradischnig AT ICN.SIEMENS.DE>
• To: SIGTRAN AT STANDARDS.NORTELNETWORKS.COM
• Subject: NTFY in m2ua/m3ua
• Date: Tue, 29 Aug 2000 10:19:34 +0200

If these questions/comments have already been answered, my appologies, but...

1. To whom would one send a NTFY AS_Down? Seems somewhat difficult to find
any ASP in this situation ;-)

2. I propose to rename the state AS_Up to AS_Inactive. If the AS is not down
it must be up, but what seems interesting then is the particular flavor of
upness.

- Klaus

Klaus D. Gradischnig
> SIEMENS
Information and Communication Networks
Wireline Network Communication
Carrier Switching Networks
WN CS SEN 51

Tel: +49 89 722 63197
Fax: +49 89 722 48212
E-mail
Klaus.Gradischnig AT ICN.Siemens.DE

--- End Message ---

---

• [SCTP-Discussion] Why Notify(AS-DOWN) is required, Sundaresan M, 01/02/2002
  • Re: [SCTP-Discussion] Why Notify(AS-DOWN) is required, Brian F. G. Bidulock, 01/02/2002

---

Archive powered by MHonArc 2.6.19+.