Subject: SUAv8: ASP Identifier

From: "Gradischnig, Klaus" <[email-masked]>
Date: Tue, 16 Oct 2001 14:08:36 -0500

The ASP identifier concept as described seems somewhat problematic.

In 3.5.1 (ASP UP) it is stated

   Note 1:  ASP Identifier MUST be used where the IPSP/SGP cannot 
            identify the ASP by pre-configured address/port number 
            information (e.g., where an ASP is resident on a Host using 
            dynamic address/port number assignment).   

In 3.9.12 it says

   The "Invalid ASP Identifier" is send by a SGP in response to an ASP 
   Up message with an invalid (i.e., non-unique) ASP Identifier. 
    
and the reason for this parameter seems to be to include it in the NOTIFY to
tell the other ASPs which one of their brethren died.

This raises some questions/comments:

1. There seems to be no reason to include the ASP identifier in the UP ACK
message as the ASP will hopefully know its own identity?

2. If the SG knows the identity of the ASP, this identity is possibly not
included in the NOTIFY -- how do the other ASPs then know who died?

3. The above error cause may also have to be sent in response to a REG
REQUEST or ASP ACTIVE as the membership of an ASP in an AS might only be
determined by these messages?

4. Two ASPs are happily serving two different ASes but use the same ASP id.
Suddenly, one of them wants to go active/register for the other AS. What
happens? Does it depend on the traffic mode?

Proposal:

- No ASP id in UP/UP ACK msgs. 
- ASP IDs -- separately per AS -- defined (if necessary) in ASP ACTIVE or
REG Request. 
- ASP ID mandatory in the appropriate NOTIFY messages. 
- Modify the text in 3.9.12.

Klaus

---
You are currently subscribed to sigtran as: [email-masked]
To unsubscribe send a blank email to [email-masked]

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 16 Oct 2001 21:03:41 -0500

Klaus,

Please see comments below...

Gradischnig, Klaus wrote:                            (Tue, 16 Oct 2001 14:08:36)
> message as the ASP will hopefully know its own identity?

Perhaps the ASP does not know it's identity... If the ASP UP does not
contain an ASP Id why can not the ASP UP Ack. :)  Section 3.5.2 of M3UA
does not, however, show ASP Id as part of the ASP UP where section 3.5.2
of SUA does.  I don't really have a problem with ASP Id being removed from
SUA ASP UP Ack.  At least SUA and M3UA should be consistent here.

> included in the NOTIFY -- how do the other ASPs then know who died?

Common M3UA and SUA sections 4.3.4.6 (Notify Procedures) indicate that the
ASP Id must be provided in the notify when known.  If it is not provided
by the SG when known in the notify, then the SG is broken.

> determined by these messages?

Don't follow you.  There is only cause to send "Invalid ASP Identifier"
as an error response to received messages that contain an invalid
ASP Identifier.  REG REQ does not contain ASP Id.

> happens? Does it depend on the traffic mode?

When the second ASP with the same ASP Id attempted to go ASP UP it should
have recevied ERR("Invalid ASP Identifier") because the ASP Id is non-unique
as in the quoted section 3.9.12 above.  This ASP stays in the DOWN state
and cannot go active or register.

> - No ASP id in UP/UP ACK msgs. 

It can be removed from ASP UP Ack for SUA (to match M3UA) but needs to be
in ASP UP.  ASP Id supports dynamic port assignments and permits the SG
to identify which ASP is connecting.  It must remain in ASP UP.

> - ASP IDs -- separately per AS -- defined (if necessary) in ASP ACTIVE or

No need, the ASP is defined by an SCTP endpoint.  The ASP Id in the ASP UP
identifies which ASP a particular SCTP endpoint corresponds to if the SG
cannot determine this (i.e. dynamic port assignment at the ASP).

> - ASP ID mandatory in the appropriate NOTIFY messages. 

It is when available: see section 4.3.4.6 of either M3UA and SUA.

> - Modify the text in 3.9.12.

3.9.12 works fine as it is.

--brian

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/

---

---

From: [email-masked]
Date: Thu, 18 Oct 2001 00:08:32 +0300

Klaus and Brian,

> contain an ASP Id why can not the ASP UP Ack. :)  Section 
> 3.5.2 of M3UA does not, however, show ASP Id as part of the ASP UP where 
> section 3.5.2 of SUA does.  I don't really have a problem with ASP Id
being 
> removed from SUA ASP UP Ack.  At least SUA and M3UA should be consistent
here.

I shall remove ASP ID from the ASP UP ACK.

> > 2. If the SG knows the identity of the ASP, this identity 
> > is possibly not included in the NOTIFY -- how do the other 
> > ASPs then know who died?
> 
> Common M3UA and SUA sections 4.3.4.6 (Notify Procedures) 
> indicate that the ASP Id must be provided in the notify when 
> known.  If it is not provided by the SG when known in the notify, 
> then the SG is broken.

I think the text is sufficient, no changes needed.
 
> > 3. The above error cause may also have to be sent in 
> > response to a REG REQUEST or ASP ACTIVE as the membership of an 
> > ASP in an AS might only be determined by these messages?
> 
> Don't follow you.  There is only cause to send "Invalid ASP 
> Identifier" as an error response to received messages that contain 
> an invalid ASP Identifier.  REG REQ does not contain ASP Id.

I think the text is sufficient, no changes needed.

> > 4. Two ASPs are happily serving two different ASes but use 
> > the same ASP id. Suddenly, one of them wants to go active/register 
> > for the other AS. What happens? Does it depend on the traffic mode?
> 
> When the second ASP with the same ASP Id attempted to go ASP 
> UP it should have recevied ERR("Invalid ASP Identifier") because 
> the ASP Id is non-unique as in the quoted section 3.9.12 above.  
> This ASP stays in the DOWN state and cannot go active or register.

I think this is clear.

> It can be removed from ASP UP Ack for SUA (to match M3UA) but 
> needs to be in ASP UP.  ASP Id supports dynamic port assignments 
> and permits the SG to identify which ASP is connecting.  It must 
> remain in ASP UP.
> 
> > - ASP IDs -- separately per AS -- defined (if necessary) in 
> > ASP ACTIVE or REG Request. 
> 
> No need, the ASP is defined by an SCTP endpoint.  The ASP Id 
> in the ASP UP identifies which ASP a particular SCTP endpoint 
> corresponds to if the SG cannot determine this (i.e. dynamic 
> port assignment at the ASP).
> 

It seems to me that the text is OK as is. Klaus, do you feel that
any changes are needed?

John

---

---

From: "Gradischnig, Klaus" <[email-masked]>
Date: Fri, 19 Oct 2001 09:23:11 -0500

John, Brian,

pls see below...

Klaus

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: October 17, 2001 5:09 PM
> To: sigtran
> Subject: RE: SUAv8: ASP Identifier
> 
> 
> Klaus and Brian,
> 

Sorry, I did and do not see it like this though I can see now how one could.
SUA explicitly states

		ASP Identifier MUST be used where the IPSP/SGP cannot 
            identify the ASP by pre-configured address/port number 
            information (e.g., where an ASP is resident on a Host using 
            dynamic address/port number assignment).

Being able to "identify" does not imply to me that the SG has any knowledge
about any ASP Identifier the ASPs belonging to an AS use (there a many
people I can identify but can't remember their names ;-) So, in order to
clarify could we change the notes to

		ASP Identifier MUST be used where the IPSP/SGP does not
            have the ASP Identifier pre-configured in address/port number 
            information (e.g., where an ASP is resident on a Host using 
            dynamic address/port number assignment).

This, however, introduces for all practical purposes a new name space (ASP
identifiers) which, unless its scope is limited to a single AS, may have be
coordianted accross many/all ASs -- see next comment.

> I think the text is sufficient, no changes needed.

Again, I do not see it this way.
SUA states

	The ASP Identifier field contains a unique value that is locally 
      significant among the ASPs that support an AS.

So, any two ASPs supporting at least one common AS must have different ASP
Identifiers, any two ASPs not supporting any common AS could use an
identical ASP Identifier. Due to the registration procedures the SG may not
know if two ASPs will support a common AS sometime in the future. Thus, when
receiving two ASP-UPs from different ASPs having identical ASP Identifiers
everything can look fine, but later a registration of one ASP for the AS
currently supported only by the other ASP suddenly results in an ASP
Identifier conflict without any ASP UPs or ASP Identifiers being exchanged.
Or, what am I missing here, John?

> It seems to me that the text is OK as is. Klaus, do you feel that

I guess I do see a need for changes. I am of course open to other proposals,
like globally valid ASP Identifiers ;-)

> 
> John
> 
> 
> ---
> You are currently subscribed to sigtran as: 
> [email-masked]
> To unsubscribe send a blank email to 
> [email-masked]
> 

---

---

From: Verwimp Gery <[email-masked]>
Date: Fri, 19 Oct 2001 17:14:40 +0200

Hi Klaus (and others),

I'm not entirely sure of what the purpose(s) of the ASP Identifier might be,
so correct me if I'm wrong. As far as I can see, there's 2 different
situations :

1. The ASP might want to use different port numbers (for splitting traffic
that way, or whatever) and this is not possible within a single SCTP
association. So it may have to setup several ones to the same SG. And to
enable the SG to accept/refuse such an approach, the ASP includes an
Identifier for the SG to know it's actually the same physical ASP (otherwise
the SG simply "sees" two ASPs).

Anyway, in this respect I think the ASP Identifier should be unique across
the family of ASPs connecting to this SG in this fashion, regardless of what
AS they will register for. The SG could also cross-check on the IP addresses
used (even in a dynamic IP addressing environment) when the ASP is good
enough to use the same set of IP addresses for each association. It has to
be courteous anyway to provide the same ASP Identifier ;)

2. To be used in Notify messages so that the alternative ASPs (of a specific
AS) immediately know which one of them has "left the building". In this
context, it is sufficient for the ASP Identifier to be unique across the AS,
but then it rather applies to the ASPTM messages ...

3. Other uses or am I totally missing the point ???

____________________________

Gery Verwimp
> SIEMENS ATEA
> ICN D CS D5
> Tel. : +32 14 25 3424
Fax : +32 14 25 3212
mailto:[email-masked]
____________________________________

-----Original Message-----
From: Gradischnig, Klaus [mailto:[email-masked]]
Sent: vrijdag 19 oktober 2001 16:23
To: sigtran
Subject: RE: SUAv8: ASP Identifier

John, Brian,

pls see below...

Klaus

> [email-masked]

---
You are currently subscribed to sigtran as: [email-masked]
To unsubscribe send a blank email to
[email-masked]

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 19 Oct 2001 14:39:29 -0500

Klaus,

If the SG does not like the uniqueness of the ASP Id it can always
return the ERR message designated for that purpose.

If two ASPs with the same numbering attempt to connect to an SG
and the SG cannot otherwise distinguish between them then it may
refuse wtih the ERR message designated for that purpose.

There is no need to place additional restrictions on numbering.
These numbers have to be agreed between SG and ASP anyway.

No text change is required.

--brian

Gradischnig, Klaus wrote:                            (Fri, 19 Oct 2001 09:23:11)
> You are currently subscribed to sigtran as: [email-masked]

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/

---

---

From: Verwimp Gery <[email-masked]>
Date: Mon, 22 Oct 2001 16:36:13 +0200

Brian,

I'm not sure if I can follow you here : do you suggest (1) as "definition of
uniqueness" for the ASP identifier ? I.e. unique across all ASPs connecting
to the SG ?

Apart from this, I find the documentation in the M3UA draft still very
insufficient. You have a few lines in 3.5.1 :

"The optional ASP Identifier parameter contains a unique value that is
locally significant among the ASPs that support an AS. The SGP should save
the ASP Identifier to be used, if necessary, with the Notify message (see
section 3.8.2)."

And in section 3.8.2 one finds another few cryptic lines :

"The format and description of the optional ASP Identifier, ... is the same
as for the ASP Active message." Wrong message and wrong reference (3.5.1
instead of 3.5.5).

No mention of it's use in 4.3.4.6 Notify Procedures.

So unless I'm looking at the wrong M3UA draft 09 version ... And in SUA v8,
there's another definition (no mention of AS, just dynamic addressing) and
it's used in both the ASP UP and ASP UP ACK message for some reason.

=============End of draft-bashing============

In short, I think Klaus has some very valid concerns and we should add (and
keep it identical in both M3UA and SUA) :

- a clear definition of ASP Identifier (scope of uniqueness ?)
- some explanatory text of it's usage in the resp. management messages (ASP
UP, ASP UP ACK, Notify)

Note : in my opinion, in the IPSP case, the ASP UP ACK contains the
acknowledging IPSP's identity, not the one reflected from the ASP
UP-originating IPSP.

- when does the SG refuse an ASP UP ? This depends on the definition/use of
ASP ID at the moment. I can imagine a few :

in (1), the SG could check the IP addresses used to know it's the same ASP
(allowed-refused, depending on policy), or another one picking the same ASP
ID (refused).

in (2), if the scope is only AS, it's not clear what to do. Take approach
(1) ? Or wait until registration/activation time and refuse the REG REQ or
ASPAC messages ?

- what happens in a mixed (ASPs using Identifier, others who don't)
environment ?

At least some agreements must be made to have some hope of interoperability
...

Gery Verwimp
Fax : +32 14 25 3212

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]]
Sent: vrijdag 19 oktober 2001 21:47
To: Verwimp Gery
Cc: sigtran
Subject: Re: SUAv8: ASP Identifier

Gery,

Your on the money here.  However, it is only necessary that the ASP Id
be made unique in (2) (over the AS) because in (1) the SGP has the right
of refusing the ASP UP due to a non-unique ASP Id.  The only way to
ensure uniqueness in (2) over dynamic reconfigurations of ASPs over AS
is to provide the uniqueness of (1).

The text still doesn't need to be changed from a requirements view.
Perhaps Klaus can propose some explanatory text.

--brian

Verwimp Gery wrote:                                       (Fri, 19 Oct 2001
17:14:40)
> situations:
> Fax: +32 14 25 3212
> You are currently subscribed to sigtran as: [email-masked]

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/

---

---

From: [email-masked]
Date: Tue, 23 Oct 2001 09:19:37 +0300

Brian,

> Please use the text from M2UA-10 with regard to ASP Identifier.

From M2UA-10

3.3.2.1

Note:  The ASP Identifier MUST be used where the SGP cannot 
          identify the ASP by pre-configured address/port number 
          information (e.g., where an ASP is resident on a Host using 
          dynamic address/port number assignment).   

-> looks like SUA-8

[M2UA]
The optional ASP Identifier parameter would contain a unique value 
that is locally significant among the ASPs that support an AS.  The 
SGP should save the ASP Identifier to be used, if necessary, with the 
Notify message (see Section 3.3.3.2).

[SUA 3.9.17]
The ASP Identifier field contains a unique value that is locally significant
amoung the ASPs that support an AS.  The SGP should save the ASP Identifier
to be used, if necessary, with the Notify message (see Section 3.7.2).  

--> not much difference.

[m2ua 3.3.2.2] has ASP ID in the ASP UP ACK message, but I have removed it
from SUA per the email exchange between Brian & Klaus.

M2UA text:
	If the ASPUP message contains an ASP Identifer, the ASPUP Ack will 
	reflect the ASP Identifier back to the ASP.

[M2UA error codes:]
     Error - ASP Identifier Required        0xe 
     Error - Invalid ASP Identifier         0xf  
     Refused - ASP Identifier Required      0x10 

[SUA error codes:]
	ASP Identifier Required                         0x0e  
	Invalid ASP Identifier                          0x0f 

-> what do you prefer Brian?

M2UA & SUA 4.3.4.1 have the same text.

M2UA & SUA 4.3.4.6 have the same text.

So, my question is, what do you want us to do?

John

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 23 Oct 2001 01:38:58 -0500

John,

Sorry, John... must have been a late night.  The current text
is fine.  I was looing at M2UA-09 and a half anyways.

--brian

John Loughney wrote:                                         (Tue, 23 Oct 2001 09:19:37)

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/

---

---

From: [email-masked]
Date: Tue, 23 Oct 2001 10:37:57 +0300

Hi Brian,

> Sorry, John... must have been a late night.  

It still must be a late night, there are still a
few discrepancies, see below:

> [m2ua 3.3.2.2] has ASP ID in the ASP UP ACK message, but I 
> have removed it from SUA per the email exchange between Brian & Klaus.

Just double checking that this is OK.

> > -> what do you prefer Brian?

Which do you prefer, 3 error codes vs 2 error codes?

John

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 23 Oct 2001 03:25:25 -0500

John,

John Loughney wrote:                    (Tue, 23 Oct 2001 10:37:57)
> Just double checking that this is OK.

I was waiting for Ken to step in here.  Ken likes things like TMT in
the ASPAC Ack.  It seems OK to leave ASP Id as optional in the ASPUP Ack.

I can see one use:

-   The ASP sends ASP UP without an ASP Id and the SGP can still
    identify the ASP from IP/address port number.  The SGP
    returns the ASP Id that it will use in Notify in the ASP UP
    Ack.

> Which do you prefer, 3 error codes vs 2 error codes?

Let's ask Ken why there are three in M2UA.  I don't know what
the difference was between Error and Refused.

--brian

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/

---

---

From: Ken Morneault <[email-masked]>
Date: Tue, 23 Oct 2001 07:52:20 -0400

Brian, John,

I have already updated M2UA to be consistent with M3UA and SUA
(the two error codes are sufficient).

Note:  There will have to be a M2UA v11 before IESG last call because
of changes desired by Scott Bradner.  I'm also updating the error values
in this version to make them consistent with M3UA/SUA.

Ken

At 03:25 AM 10/23/01 -0500, you wrote:
>You are currently subscribed to sigtran as: [email-masked]

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 23 Oct 2001 07:11:14 -0500

Ken,

Ken Morneault wrote:                        (Tue, 23 Oct 2001 07:52:20)
> of changes desired by Scott Bradner.

Now, what changes might those be?

--brian

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/

---

---

From: Ken Morneault <[email-masked]>
Date: Tue, 23 Oct 2001 01:34:26 -0700

Brian,

Here are the current set of comments.  There will be more.

Ken

--------------------------------------------comments------------------------------

the introduction should actually say what the protocol does
rather than just starting out with the scope and terminology

-------------
need references the 1st time (other than the abstract) that
a technology (e.g. SCN and MTP - in sec 1.1, SS7 in sec 1.3.1)

-------------
sec 1.3.2 - as an example - there are a number of others
  The M2UA layer MAY be instructed by local management to establish an
  SCTP association to a peer M2UA node.  This can be achieved using the
  M-SCTP_ESTABLISH primitive to request, indicate and confirm the
  establishment of an SCTP association with a peer M2UA node. 

should say where M-SCTP_ESTABLISH is defined (sec x.x.x)

-------------
sec 1.3.3 - what is a linkset?
(i.e. "linkset" should be in the termonology section)

----------------
sec 1.3.3
  For carrier grade networks, Operators SHOULD ensure that under failure
  or isolation of a particular ASP, stable calls or transactions are not
  lost.  This implies that ASPs need, in some cases, to share the call/-
  transaction state or be able to pass the call/transaction state between
  each other.

does this mean that they would have to share SCTP state?
if so, that should be mentioned and also said to be out of scope

-------------
there are a lot of operational recommendations here - would it be better
to befine the protocol first then put the operational considerations into
an appendix - and is it reasonable for this type of document to be
making specific operational recommendations like is done in sec 1.3.4?

-------------
sec 7 should be called "Security Considerations"

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 23 Oct 2001 16:35:53 -0500

Ken,

The comments sound reasonable; however, whatever changes are
made should be discussed.

As even IESG reviews are conducted on the WG reflector, would it
not be a bad idea for Mr. Bradner to make his comments known to
the WG?  Or, do Mr. Bradner's views allow changes to be made to
the draft in a way that takes precedence over WG concensus?

--brian

Ken Morneault wrote:                                          (Tue, 23 Oct 2001 01:34:26)

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/

---

---

From: Ken Morneault <[email-masked]>
Date: Tue, 23 Oct 2001 18:08:29 -0700

Brian,

There will be an opportunity for discussion.  I was waiting to
send his comments and proposed draft adjustments because 
Scott indicated he would be sending more comments. 

All of his comments are editorial in nature and are targeted at
getting the draft in better shape for a technical review.   

Regards,

Ken

---

---

From: "Ong, Lyndon" <[email-masked]>
Date: Wed, 24 Oct 2001 11:31:42 -0700

Hi Brian,

As our A-D, Scott (and Allison) is responsible for reviewing
our documents and making sure that they satisfy the IETF's
requirements for documentation, I think his comments are directed
towards this, rather than towards the technical points.

This will require issuing another draft of M2UA, at that time
we can also put out a list of the changes and get any feedback
on them before going again to Scott and IESG for approval.

(Why is this on an SUA thread?)

Cheers,

Lyndon

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]]
Sent: Tuesday, October 23, 2001 2:36 PM
To: sigtran
Subject: Re: SUAv8: ASP Identifier

Ken,

--brian

Ken Morneault wrote:                                          (Tue, 23 Oct
2001 01:34:26)
--------------------------------------------comments------------------------
------

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/

---