Subject: RE: [Sigtran] M3UA IG05 :Response to ASPIA

From: [email-masked]
Date: Thu, 25 Sep 2003 17:22:14 +0530

Javier

Folks,

As a summary of this discussions, after checking the RFC and the IG we can
see the following disalignments:
- Use of wildcard and RC conditional for ASPAC and ASPIA
- Use of wildcard and section 3.9.2 in IG

Then, aligning text with the wildcard option implies the following changes:

IG Section 2.9.2 new text will be updated to:

<newText>

When an ASP wishes to withdraw from receiving traffic within an AS,or the
ASP wants to initiate the process of activation, the ASP sends an ASP
Inactive message to the SGP or IPSP.

<<ANJALI>> A typo, the above text should be process of deactivation rather
than process of activation.

An ASP Inactive message MUST be always responded by the peer (although
other messages may be sent in the middle) in the following way:

- If the ASP Inactive message contains a RC parameter and the corresponding
RK is registered, the peer must respond with an ASP Inactive Ack message.

- If the ASP Inactive message contains a RC parameter that is not
registered, the peer must respond with an ERROR message with Error Code =
"Invalid Routing Context".

- If the ASP Inactive message does not contain a RC parameter and the RK is
registered, the peer must turn the ASP/IPSP to ASP-INACTIVE state in all
the ASes it serves  and must respond with an ASP Inactive Ack message.

- If the ASP Inactive message does not contain a RC parameter and the RK is
not registered, the peer must respond with an ERROR message with Error Code
= "No configured AS for ASP".

</newText>

Also, the RC parameter for ASPIA and ASPAC will turn to optional instead of
conditional and the corresponding changes will be removed from the section
3.5.2 in IG.

Finally it would be good to align 4.3.4.3 and 4.3.4.4 including in the
former the last sentence of the latter: "and move the ASP to the ASP-ACTIVE
state in all Application Servers", as Kamesh suggest.

Hope things get clearer with these changes...

As I final side thought I wonder whether it would be good to include a
detailed outline of the possible responses to ASPAC message as a function
of RC, in the same way as is proposed for  ASPIA answers...

<<ANJALI>>I agree with you .IMO also adding a  section in the IG capturing
the responses to ASPAC message and RC in a manner similar to ASPIA shall
clarify ASPAC procedures too.

Cheers // Javier.

> -----Original Message-----
> From: Brian F. G. Bidulock [mailto:[email-masked]]
> Sent: martes, 23 de septiembre de 2003 19:41
> To: J.Javier Pastor (TS/EEM)
> Cc: [email-masked]; [email-masked]'
> Subject: Re: [Sigtran] M3UA IG05 :Response to ASPIA
>
>
> J.Javier,
>
> A few moons ago now.  Perhaps Tolga can recall the name of
> the thread...
>
> The point was that the RFC permits an SG implementation to decide what
> "configured" means and refuse any ASPAC/ASPIA without an RC
> value with "No
> Configured AS for ASP".  The wildcard behavior is not
> guaranteed by the RFC.
> The ASP must include RC in DATA and SNMM if there is more
> than a single AS and
> must therefore know the values if there is more than one AS and an SG
> implementation is fully within its rights to refuse any
> ASPAC/ASPIA where
> there is more than one AS.
>
> Note that the error message say "No Configured AS for ASP",
> not "No Configured
> AS(s) for ASP".
>
> The situation was meant to accomodate the case where the ASP
> thought that it
> was not necessary to include RC in any message, but there is
> not a single AS
> configured for the ASP.
>
> If the wildcard behavior is necessary, it needs to be stated
> under which
> conditions the SG should not (or must not) respond with "No
> Configured AS for
> ASP".  But that is rather pointless for M3UA, as the ASPs
> need to know the RC
> values in any case.  For SUA, the matter is a little
> different.  SUA can have
> many thousands of RC values representing GTT entries.
> Wildcarding in this
> fashion is a short-hand for long SUA messages.  M2UA gets
> around this by
> activating IIDs rather than AS, and providing its own
> shorthand and rules for
> specifying ranges of IIDs that make up a single AS.
>
> Somehow I don't think that we can get away without making
> some statement
> in the IG.
>
> Perhaps the advocates of the "wildcard" behavior can propose text.
>
> --brian
>
> J.Javier Pastor (TS/EEM) wrote:
>                     (Tue, 23 Sep 2003 15:43:01)
> > Brian,
> >
> > Could you please refer where that decission was agreed? I
> didn't find it...
> >
> > Thanks // Javier.
> >
> > > -----Original Message-----
> > > From: [email-masked] [mailto:[email-masked]]
> > > Sent: martes, 23 de septiembre de 2003 12:34
> > > To: [email-masked]
> > > Cc: [email-masked]
> > > Subject: Re: [Sigtran] M3UA IG05 :Response to ASPIA
> > >
> > >
> > >
> > >
> > >
> > >
> > > Brian,
> > >              It is not there in current IG.
> > >
> > >
> > >
> > >
> > > "Brian F. G. Bidulock" <[email-masked]> on 09/23/2003
> > > 03:56:25 PM
> > >
> > > Please respond to [email-masked]
> > >
> > > To:    Kamesh Kaul/HSS@HSS
> > > cc:    [email-masked]
> > >
> > > Subject:    Re: [Sigtran] M3UA IG05 :Response to ASPIA
> > >
> > >
> > > kakaul,
> > >
> > > We already agreed to drop the 's' (plural) from
> Application Server's'
> > > in these passages.
> > >
> > > --brian
> > >
> > > [email-masked] wrote:
> > > (Tue, 23 Sep 2003 15:33:15)
> > > >
> > > >
> > > >
> > > >
> > > > Hi,
> > > >          Referring to section 4.3.4.3 ASP Active Procedures
> > > >
> > > >    "In the case where an ASP Active message does not
> > > contain a Routing
> > > > Context
> > > >    parameter, the receiver must know, via configuration
> data, which
> > > >        Application Server(s) the ASP is a member."
> > > >
> > > >      Referring to section 4.3.4.4 ASP Inactive Procedures
> > > >
> > > >         "In the case where an ASP Inactive message does not
> > > >    contain a Routing Context parameter, the receiver
> must know, via
> > > >    configuration data, which Application Servers the ASP is
> > > a member and
> > > >        move the ASP to the ASP-INACTIVE state in all Application
> > > Servers."
> > > >
> > > > These lines imply that if ASPAC/IA messages is received
> without RC
> > > receiver
> > > > should activate/inactivate all the application servers
> > > served by ASP.
> > > > If that is not implied then some clearification should be
> > > added in IG to
> > > > make RC conditional in ASPAC and ASPIA messages aswell
> to avoid any
> > > further
> > > > confusions. Current IG does not address this problem
> > > >
> > > > Kamesh Kaul
> > > > www.hssworld.com
> > > > Hughes Software Systems
> > >
> > > --
> > > Brian F. G. Bidulock
> > > [email-masked]
> > >  http://www.openss7.org/
> > >
> > >
> > >
> > >
> > >
> > >
> > > _______________________________________________
> > > Sigtran mailing list
> > > [email-masked]
> > > https://www1.ietf.org/mailman/listinfo/sigtran
> > >
>
> --
> Brian F. G. Bidulock
> [email-masked]
> http://www.openss7.org/
>

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

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

---

From: "Vivek Toky" <[email-masked]>
Date: Thu, 25 Sep 2003 10:53:04 -0700

Hi All,
  What should M3UA do if it receives an invalid version in common message
Header of messages other than ASP UP.

1. Ignore it ?
2. Send an error back with error code "invalid version" ?

Following statement is mentioned in RFC section 4.3.4.1.1

 "If an ASP Up message with an unsupported version is received, the
  receiving end responds with an Error message, indicating the version
  the receiving node supports and notifies Layer Management."

regards,
Vivek