Re: question about M2PA and M2UA

_______________________________________________
Sigtran mailing list
Sigtran <at> ietf.org
https://www1.ietf.org/mailman/listinfo/sigtran

RE: question about M2PA and M2UA

_______________________________________________
Sigtran mailing list
Sigtran <at> ietf.org
https://www1.ietf.org/mailman/listinfo/sigtran

I-D ACTION:draft-ietf-sigtran-rfc3332bis-01.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Signaling Transport Working Group of the IETF.

	Title		: Signaling System 7 (SS7) Message Transfer Part 3 
			  (MTP3) - User Adaptation Layer (M3UA)
	Author(s)	: K. Morneault, J. Pastor-Balbas
	Filename	: draft-ietf-sigtran-rfc3332bis-01.txt
	Pages		: 114
	Date		: 2004-10-1
	
This memo defines a protocol for supporting the transport of any SS7
   MTP3-User signalling (e.g., ISUP and SCCP messages) over IP using the
   services of the Stream Control Transmission Protocol.  Also,
   provision is made for protocol elements that enable a seamless
   operation of the MTP3-User peers in the SS7 and IP domains. This
   protocol would be used between a Signalling Gateway (SG) and a Media
   Gateway Controller (MGC) or  IP-resident Database, or between two
   IP-based applications.  It is assumed that the SG receives SS7
   signalling over a standard SS7 interface using the SS7 Message
   Transfer Part (MTP) to provide transport.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sigtran-rfc3332bis-01.txt

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request <at> ietf.org with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-sigtran-rfc3332bis-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv <at> ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-sigtran-rfc3332bis-01.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

_______________________________________________
Sigtran mailing list
Sigtran <at> ietf.org
https://www1.ietf.org/mailman/listinfo/sigtran

M3UA 2nd Last Call

Hi Folks,

Now that the M3UA updated text is out, I would like to run a
shorter, 1 week Last Call on the document.  Comments should
be limited to errors or to changes made due to the comments
in the previous Last Call (let's not open this up completely
or we'll never get it done!)

The document details are below.  Last Call should start now,
going until Monday, October 11th.  Please use "M3UA Last Call
Comment" in the subject line.  If possible, identify if this
is a new error found or refers to a change from a previous
comment, and what the original comment was.

Note: the draft was held up slightly due to some changes in
the boilerplate requested by the IETF editor.

Cheers,

L. Ong

-----Original Message-----
From: Internet-Drafts <at> ietf.org [mailto:Internet-Drafts <at> ietf.org]
Sent: Friday, October 01, 2004 12:52 PM
To: i-d-announce <at> ietf.org
Cc: sigtran <at> ietf.org
Subject: [Sigtran] I-D ACTION:draft-ietf-sigtran-rfc3332bis-01.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Signaling Transport Working Group of the IETF.

	Title		: Signaling System 7 (SS7) Message Transfer Part 3 
			  (MTP3) - User Adaptation Layer (M3UA)
	Author(s)	: K. Morneault, J. Pastor-Balbas
	Filename	: draft-ietf-sigtran-rfc3332bis-01.txt
	Pages		: 114
	Date		: 2004-10-1
	
This memo defines a protocol for supporting the transport of any SS7
   MTP3-User signalling (e.g., ISUP and SCCP messages) over IP using the
   services of the Stream Control Transmission Protocol.  Also,
   provision is made for protocol elements that enable a seamless
   operation of the MTP3-User peers in the SS7 and IP domains. This
   protocol would be used between a Signalling Gateway (SG) and a Media
   Gateway Controller (MGC) or  IP-resident Database, or between two
   IP-based applications.  It is assumed that the SG receives SS7
   signalling over a standard SS7 interface using the SS7 Message
   Transfer Part (MTP) to provide transport.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sigtran-rfc3332bis-01.txt

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request <at> ietf.org with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-sigtran-rfc3332bis-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv <at> ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-sigtran-rfc3332bis-01.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

SUA Network Management messages

SUA Network management messages ( DUNA, DAVA, DAUD, SCON, DRST and DUPU)
have Routing Context has a optional parameter.   If an ASP is registered in
multiple routing keys (routing context being different for each routing
key), then when a nework management message is to be sent on the ASP, do we
need to fill  in the message  with all routing contexts the  ASP is
registered for in the concerned point code's network.  Or can we only send
one routing context that matches with the concerned point code's network.

Also since the above messages are talking about a point code status, and
since network apperance relates directly to the point codeI, it would make
more sense to use Network appearance in these messages instead of Routing
Context.  Why is network apperance is not there in the messages has
optional parameter instead of routing context?

Re: SUA Network Management messages

sherry.karl,

I think your confusing SUA with M3UA.

--brian

sherry.karl <at> tekelec.com wrote:                                                 (Mon, 04 Oct 2004 09:54:24)
> SUA Network management messages ( DUNA, DAVA, DAUD, SCON, DRST and DUPU)
> have Routing Context has a optional parameter.   If an ASP is registered in
> multiple routing keys (routing context being different for each routing
> key), then when a nework management message is to be sent on the ASP, do we
> need to fill  in the message  with all routing contexts the  ASP is
> registered for in the concerned point code's network.  Or can we only send
> one routing context that matches with the concerned point code's network.
> 
> Also since the above messages are talking about a point code status, and
> since network apperance relates directly to the point codeI, it would make
> more sense to use Network appearance in these messages instead of Routing
> Context.  Why is network apperance is not there in the messages has
> optional parameter instead of routing context?
> 
> 
> 
> _______________________________________________
> Sigtran mailing list
> Sigtran <at> ietf.org
> https://www1.ietf.org/mailman/listinfo/sigtran

--

-- 
Brian F. G. Bidulock
bidulock <at> openss7.org
http://www.openss7.org/

Re: SUA Network Management messages

Brian,

I am definitely talking about SUA, and I am not confused.  Can you
elloborate on your answer why you think I am confused?

Section 4.5 in Version 16 SUA Draft

4.5 Availability and/or Congestion Status of SS7 Destination Support

4.5.1 At an SGP

   On receiving a N-STATE, N-PCSTATE and N-INFORM indication primitive
   from the nodal inter-working function at an SGP, the SGP SUA layer
   will send a corresponding SS7 Signalling Network Management (SNM)
   DUNA, DAVA, SCON, or DUPU message (see Section 3.4) to the SUA peers
   at concerned ASPs.  The SUA layer must fill in various fields of the
   SNM messages consistently with the information received in the
   primitives.

   The SGP SUA layer determines the set of concerned ASPs to be informed
   based on the specific SS7 network for which the primitive indication
   is relevant. In this way, all ASPs configured to send/receive traffic
   within a particular network appearance are informed.  If the SGP
   operates within a single SS7 network appearance, then all ASPs are
   informed.

   DUNA, DAVA, SCON, and DRST messages are sent sequentially and
   processed at the receiver in the order sent.  SCTP stream 0 SHOULD
   NOT be used. The Unordered bit in the SCTP DATA chunk MAY be used for
   the SCON message.

   Sequencing is not required for the DUPU or DAUD messages, which MAY
   be sent un-sequenced.  SCTP stream 0 is used, with optional use of
   the Unordered bit in the SCTP DATA chunk.

The question again is
Network management messages are talking about a point code status, and
since network apperance relates directly to the point codeI, it would make
more sense to use Network appearance in these messages instead of Routing
Context.  Why is network apperance is not there in the messages has
optional parameter instead of routing context?  Also, since the
determination of concerned ASPs is based the network apperance, why not put
Network Apperance in the network management messages?

----- Forwarded by Sherry Karl/Raleigh/TEKELEC on 10/04/04 04:17 PM -----

                      "Brian F. G.                                                                                                
                      Bidulock"                To:      sherry.karl <at> tekelec.com                                                   
                      <bidulock <at> openss         cc:      sigtran <at> ietf.org                                                          
                      7.org>                   Subject: Re: [Sigtran] SUA Network Management messages                             

                      10/04/04 04:08                                                                                              
                      PM                                                                                                          
                      Please respond                                                                                              
                      to bidulock                                                                                                 

sherry.karl,

I think your confusing SUA with M3UA.

--brian

sherry.karl <at> tekelec.com wrote:
(Mon, 04 Oct 2004 09:54:24)
> SUA Network management messages ( DUNA, DAVA, DAUD, SCON, DRST and DUPU)
> have Routing Context has a optional parameter.   If an ASP is registered
in
> multiple routing keys (routing context being different for each routing
> key), then when a nework management message is to be sent on the ASP, do
we
> need to fill  in the message  with all routing contexts the  ASP is
> registered for in the concerned point code's network.  Or can we only
send
> one routing context that matches with the concerned point code's network.
>
> Also since the above messages are talking about a point code status, and
> since network apperance relates directly to the point codeI, it would
make
> more sense to use Network appearance in these messages instead of Routing
> Context.  Why is network apperance is not there in the messages has
> optional parameter instead of routing context?
>
>
>
> _______________________________________________
> Sigtran mailing list
> Sigtran <at> ietf.org
> https://www1.ietf.org/mailman/listinfo/sigtran

--
Brian F. G. Bidulock
bidulock <at> openss7.org
 http://www.openss7.org/

Re: SUA Network Management messages

sherry.karl,

Because, Sherry, the Routing Context does not refer to the affected
Point Code of an N-PCSTATE, it refers to the concerned AS.  Also, RC
implies both the affected and concerned NA, so including NA would be
redundant at best.

--brian

sherry.karl <at> tekelec.com wrote:                                                 (Tue, 05 Oct 2004 10:07:58)
> Brian,
> 
> I am definitely talking about SUA, and I am not confused.  Can you
> elloborate on your answer why you think I am confused?
> 
> Section 4.5 in Version 16 SUA Draft
> 
> 4.5 Availability and/or Congestion Status of SS7 Destination Support
> 
> 4.5.1 At an SGP
> 
>    On receiving a N-STATE, N-PCSTATE and N-INFORM indication primitive
>    from the nodal inter-working function at an SGP, the SGP SUA layer
>    will send a corresponding SS7 Signalling Network Management (SNM)
>    DUNA, DAVA, SCON, or DUPU message (see Section 3.4) to the SUA peers
>    at concerned ASPs.  The SUA layer must fill in various fields of the
>    SNM messages consistently with the information received in the
>    primitives.
> 
>    The SGP SUA layer determines the set of concerned ASPs to be informed
>    based on the specific SS7 network for which the primitive indication
>    is relevant. In this way, all ASPs configured to send/receive traffic
>    within a particular network appearance are informed.  If the SGP
>    operates within a single SS7 network appearance, then all ASPs are
>    informed.
> 
>    DUNA, DAVA, SCON, and DRST messages are sent sequentially and
>    processed at the receiver in the order sent.  SCTP stream 0 SHOULD
>    NOT be used. The Unordered bit in the SCTP DATA chunk MAY be used for
>    the SCON message.
> 
>    Sequencing is not required for the DUPU or DAUD messages, which MAY
>    be sent un-sequenced.  SCTP stream 0 is used, with optional use of
>    the Unordered bit in the SCTP DATA chunk.
> 
> 
> The question again is
> Network management messages are talking about a point code status, and
> since network apperance relates directly to the point codeI, it would make
> more sense to use Network appearance in these messages instead of Routing
> Context.  Why is network apperance is not there in the messages has
> optional parameter instead of routing context?  Also, since the
> determination of concerned ASPs is based the network apperance, why not put
> Network Apperance in the network management messages?
> 
> 
> 
> 
> 
> 
>                                                                                                                                   
>                                                                                                                                   
>                                                                                                                                   
> 
> 
> 
> 
> ----- Forwarded by Sherry Karl/Raleigh/TEKELEC on 10/04/04 04:17 PM -----
>                                                                                                                                   
>                       "Brian F. G.                                                                                                
>                       Bidulock"                To:      sherry.karl <at> tekelec.com                                                   
>                       <bidulock <at> openss         cc:      sigtran <at> ietf.org                                                          
>                       7.org>                   Subject: Re: [Sigtran] SUA Network Management messages                             
>                                                                                                                                   
>                       10/04/04 04:08                                                                                              
>                       PM                                                                                                          
>                       Please respond                                                                                              
>                       to bidulock                                                                                                 
>                                                                                                                                   
>                                                                                                                                   
> 
> 
> 
> 
> sherry.karl,
> 
> I think your confusing SUA with M3UA.
> 
> --brian
> 
> sherry.karl <at> tekelec.com wrote:
> (Mon, 04 Oct 2004 09:54:24)
> > SUA Network management messages ( DUNA, DAVA, DAUD, SCON, DRST and DUPU)
> > have Routing Context has a optional parameter.   If an ASP is registered
> in
> > multiple routing keys (routing context being different for each routing
> > key), then when a nework management message is to be sent on the ASP, do
> we
> > need to fill  in the message  with all routing contexts the  ASP is
> > registered for in the concerned point code's network.  Or can we only
> send
> > one routing context that matches with the concerned point code's network.
> >
> > Also since the above messages are talking about a point code status, and
> > since network apperance relates directly to the point codeI, it would
> make
> > more sense to use Network appearance in these messages instead of Routing
> > Context.  Why is network apperance is not there in the messages has
> > optional parameter instead of routing context?
> >
> >
> >
> > _______________________________________________
> > Sigtran mailing list
> > Sigtran <at> ietf.org
> > https://www1.ietf.org/mailman/listinfo/sigtran
> 
> --
> Brian F. G. Bidulock
> bidulock <at> openss7.org
>  http://www.openss7.org/
> 
> 
> 
> 
> 
> 
> _______________________________________________
> Sigtran mailing list
> Sigtran <at> ietf.org
> https://www1.ietf.org/mailman/listinfo/sigtran

--

-- 
Brian F. G. Bidulock
bidulock <at> openss7.org
http://www.openss7.org/

Re: SUA Network Management messages

Brian,

I see that you agree that NA can also provide same information as RC.  Why
not replace Routing Context in the SNM messages with Network apperance? I
am not asking to add NA and keeping RC also.  What I am asking is why not
replace routing context with Network Apperance?  This way, the software can
be reused between M3UA and SUA.

Also, please answer my other question:
If an ASP is registered in multiple routing keys (routing context being
different for each routing
key), then when a nework management message is to be sent on the ASP, do we
need to fill  in the message  with all routing contexts the  ASP is
registered for in the concerned point code's network.  Or can we only send
one routing context that matches with the concerned point code's network.

Thanks,
Raman Khadri

----- Forwarded by Sherry Karl/Raleigh/TEKELEC on 10/05/04 03:19 PM -----

                      "Brian F. G.                                                                                                
                      Bidulock"                To:      sherry.karl <at> tekelec.com                                                   
                      <bidulock <at> openss         cc:      sigtran <at> ietf.org                                                          
                      7.org>                   Subject: Re: [Sigtran] SUA Network Management messages                             

                      10/05/04 01:55                                                                                              
                      PM                                                                                                          
                      Please respond                                                                                              
                      to bidulock                                                                                                 

sherry.karl,

Because, Sherry, the Routing Context does not refer to the affected
Point Code of an N-PCSTATE, it refers to the concerned AS.  Also, RC
implies both the affected and concerned NA, so including NA would be
redundant at best.

--brian

sherry.karl <at> tekelec.com wrote:
(Tue, 05 Oct 2004 10:07:58)
> Brian,
>
> I am definitely talking about SUA, and I am not confused.  Can you
> elloborate on your answer why you think I am confused?
>
> Section 4.5 in Version 16 SUA Draft
>
> 4.5 Availability and/or Congestion Status of SS7 Destination Support
>
> 4.5.1 At an SGP
>
>    On receiving a N-STATE, N-PCSTATE and N-INFORM indication primitive
>    from the nodal inter-working function at an SGP, the SGP SUA layer
>    will send a corresponding SS7 Signalling Network Management (SNM)
>    DUNA, DAVA, SCON, or DUPU message (see Section 3.4) to the SUA peers
>    at concerned ASPs.  The SUA layer must fill in various fields of the
>    SNM messages consistently with the information received in the
>    primitives.
>
>    The SGP SUA layer determines the set of concerned ASPs to be informed
>    based on the specific SS7 network for which the primitive indication
>    is relevant. In this way, all ASPs configured to send/receive traffic
>    within a particular network appearance are informed.  If the SGP
>    operates within a single SS7 network appearance, then all ASPs are
>    informed.
>
>    DUNA, DAVA, SCON, and DRST messages are sent sequentially and
>    processed at the receiver in the order sent.  SCTP stream 0 SHOULD
>    NOT be used. The Unordered bit in the SCTP DATA chunk MAY be used for
>    the SCON message.
>
>    Sequencing is not required for the DUPU or DAUD messages, which MAY
>    be sent un-sequenced.  SCTP stream 0 is used, with optional use of
>    the Unordered bit in the SCTP DATA chunk.
>
>
> The question again is
> Network management messages are talking about a point code status, and
> since network apperance relates directly to the point codeI, it would
make
> more sense to use Network appearance in these messages instead of Routing
> Context.  Why is network apperance is not there in the messages has
> optional parameter instead of routing context?  Also, since the
> determination of concerned ASPs is based the network apperance, why not
put
> Network Apperance in the network management messages?
>
>
>
>
>
>
>
>
>
>
>
>
>
> ----- Forwarded by Sherry Karl/Raleigh/TEKELEC on 10/04/04 04:17 PM -----
>
>                       "Brian F. G.
>                       Bidulock"                To:
sherry.karl <at> tekelec.com
>                       <bidulock <at> openss         cc:      sigtran <at> ietf.org
>                       7.org>                   Subject: Re: [Sigtran] SUA
Network Management messages
>
>                       10/04/04 04:08
>                       PM
>                       Please respond
>                       to bidulock
>
>
>
>
>
>
> sherry.karl,
>
> I think your confusing SUA with M3UA.
>
> --brian
>
> sherry.karl <at> tekelec.com wrote:
> (Mon, 04 Oct 2004 09:54:24)
> > SUA Network management messages ( DUNA, DAVA, DAUD, SCON, DRST and
DUPU)
> > have Routing Context has a optional parameter.   If an ASP is
registered
> in
> > multiple routing keys (routing context being different for each routing
> > key), then when a nework management message is to be sent on the ASP,
do
> we
> > need to fill  in the message  with all routing contexts the  ASP is
> > registered for in the concerned point code's network.  Or can we only
> send
> > one routing context that matches with the concerned point code's
network.
> >
> > Also since the above messages are talking about a point code status,
and
> > since network apperance relates directly to the point codeI, it would
> make
> > more sense to use Network appearance in these messages instead of
Routing
> > Context.  Why is network apperance is not there in the messages has
> > optional parameter instead of routing context?
> >
> >
> >
> > _______________________________________________
> > Sigtran mailing list
> > Sigtran <at> ietf.org
> > https://www1.ietf.org/mailman/listinfo/sigtran
>
> --
> Brian F. G. Bidulock
> bidulock <at> openss7.org
>  http://www.openss7.org/
>
>
>
>
>
>
> _______________________________________________
> Sigtran mailing list
> Sigtran <at> ietf.org
> https://www1.ietf.org/mailman/listinfo/sigtran

--
Brian F. G. Bidulock
bidulock <at> openss7.org
 http://www.openss7.org/

RC/NA conditional?

Hi Javier/Ken,

I just realized that in the M3UAbis document for DATA/SSNM both RC and NA
are listed as "conditional". IMHO, this might be misleading because the
requiremanets, when to include NA and RC are not the same -although this is
explained in the text-. NA is never really required , whereas RC is required
for cases, where there is no 1:1 relationship between AS and SCTP
association. Maybe NA "optional" and RC "conditional"?

   Thanks,
   Tolga