headers
Tolga Asveren | 1 Jul 2002 15:15
Favicon

RE: M3UA: IG: ASP IDs & a proposal to solve a network equipment failure scenario

Michael,

Although host redundancy will be provided by ASP/SGP concept, it is also
important to limit message loss during switching from one SCTP association
to another one.
http://www.ietf.org/internet-drafts/draft-bidulock-sigtran-corid-00.txt
explains possible problems in such a case and provides solutions.  Unless
such a mechanism is implemented, I think it is also important to limit cwnd
value, apart from the other parameters you mentioned.

   Tolga

> -----Original Message-----
> From: sigtran-admin <at> ietf.org [mailto:sigtran-admin <at> ietf.org]On Behalf Of
> Michael Tuexen
> Sent: Saturday, June 29, 2002 2:48 PM
> To: Al Varney
> Cc: sigtran <at> ietf.org
> Subject: Re: [Sigtran] M3UA: IG: ASP IDs & a proposal to solve a network
> equipment failure scenario
>
>
> Dear all,
> see my comments below.
> Best regards
> Michael
>
> On Saturday, June 29, 2002, at 01:30 AM, Al Varney wrote:
>
> > At 06:17 PM 6/28/02 -0400, Tolga Asveren wrote:
(Continue reading)

Permalink | Reply | 0 comments |
headers
Tolga Asveren | 1 Jul 2002 15:29
Favicon

sctp-sig-prot

Hi John L.,

I have some initial questions/comments about the new sctp-sig-prot draft, to
be able to better understand its scope:

1-"Current work in the SIGTRAN Working Group [2719] defines architecture
   for backhauling SS7 Signalling Protocols over IP.  However, no
   consideration is given for signaling that is completely terminated in
   IP networks (sometimes called 'all-IP' or 'full-IP' signaling)."
Personally I wouldn't agree that no consideration is given in the WG for
"all-IP" signalling.

2- "The SCTP Handler allows a much lighter protocol stack, optimized for
   the transport of typical application part protocols (ex: RANAP,
   RNSAP, BSSAP) over IP. Optimization is possible by removing the not
   needed and the redundant functionality provided by the signaling
   protocol stacks."
Which functionality of the signalling stacks should be considered as
redundant? For example from a SCCP user point of view, which functionalities
in SUA and SCTP are overlapping?

3- "SS7 protocols have a different addressing model than IP.  Some layers
   are hop-by-hop and do not assume global addressing.  It may be
   reasonable to assume that SS7 addressing will not disappear; however
   overlaying non-global addressing on top of IP is not a reasonable
   long-term assumption. In practice, it may be useful to consider SS7
   addresses as labels, rather than point codes when signaling in an IP
   network."
Are we already not interpreting PC+NA as the label of a logical entity,
whose physical address is one or more IP address+SCTP port?
(Continue reading)

Permalink | Reply | 0 comments |
headers
john.loughney | 1 Jul 2002 15:47
Picon

RE: sctp-sig-prot

Hi Tolga,

> 1-"Current work in the SIGTRAN Working Group [2719] defines architecture
>    for backhauling SS7 Signalling Protocols over IP.  However, no
>    consideration is given for signaling that is completely terminated in
>    IP networks (sometimes called 'all-IP' or 'full-IP' signaling)."
> Personally I wouldn't agree that no consideration is given in 
> the WG for "all-IP" signalling.

The architecture document does not contain anything about this.  M3UA and
SUA discuss it somewhat, but as current discussions regarding M3UA indicate,
there is not universal agreement on the architecture.

> 2- "The SCTP Handler allows a much lighter protocol stack, optimized for
>    the transport of typical application part protocols (ex: RANAP,
>    RNSAP, BSSAP) over IP. Optimization is possible by removing the not
>    needed and the redundant functionality provided by the signaling
>    protocol stacks."
> Which functionality of the signalling stacks should be considered as
> redundant? For example from a SCCP user point of view, which 
> functionalities in SUA and SCTP are overlapping?

Actually, SUA is not being used by any SDOs to transport things like
RANAP, etc.  My opinion is that if there is no interworking with SS7,
much of the procedures in M3UA and SUA are probably not needed.

Both SUA and M3UA are somewhat verbose protocols, with quite a bit
of overhead, so eliminating them might not be so bad, especially in a simple
peer-to-peer case.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Arun Panda | 2 Jul 2002 10:59

Padding in IUA Parameters

Hello,

Section 3.1.5 of RFC 3057 says that "The total length of a parameter
(including Tag, Parameter Length and Value fields) MUST be a multiple of 4
bytes"
Does this hold good for all the parameters. In case of M3UA padding is done
only if the parameter is the last one in the message(e.g Info String). In
case of IUA Asp Active , if the IID is text formatted, then do we have to
pad the parameter with 0s.
Please clarify
Thanks and Rgds
Arun

Vision without action is a daydream. 
Action without vision is a nightmare
Permalink | Reply | 1 comment |
headers
Internet-Drafts | 2 Jul 2002 12:35
Picon
Favicon

I-D ACTION:draft-ietf-sigtran-m3ua-implementors-guide-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		: M3UA ImplementorÆs Guide
	Author(s)	: J. Pastor, K. Morneault
	Filename	: draft-ietf-sigtran-m3ua-implementors-guide-01.txt
	Pages		: 32
	Date		: 01-Jul-02
	
This document contains a compilation of all defects found up until
March 2002 for the M3UA [RFCxxx]. These defects may be of an
editorial or technical nature. This document may be thought of as a
companion document to be used in the implementation of M3UA to
clarify errors in the original M3UA document. This document updates
RFCxxxx and text within this document supersedes the text found in
RFCxxxx

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

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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-m3ua-implementors-guide-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
(Continue reading)

Permalink | Reply | 0 comments |
headers
Tolga Asveren | 2 Jul 2002 15:05
Favicon

m3ua IG-v01: OPC list

Javier,

Why is multiple OPC values valid only in case of alias point code
configuration? I commented before that this explanation in my view should be
applicable for DPC, there was no reply so assumed it was agreed to change
OPC to DPC. Is this a typo that it is still OPC in the IG or not?

   Tolga
Permalink | Reply | 1 comment |
headers
Tolga Asveren | 2 Jul 2002 16:12
Favicon

m3ua IG-v01: NIF unavailable

Javier,

Although I still think it is by far too restrictive to use "MUST" to
describe what should be done in case NIF is unavailable -if this really
should be described at all- there are also other problems with the behavior
described in IG.

I think, it is appropriate to think that while routing between two ASPs, SGP
does not make use of NIF. In such a case sending ASPIA-ACK to all ASPs won't
be the right choice, when SGP is isolated from NIF.  So, although I also
thought before that ASPIA-ACK is better than sending DUNA, now I think this
sentence should be changed to handle the case I mentioned above. So, DUNA
should be sent for the destinations in SS7 domain (and of course better not
to explain about what to do in case of NIF isolation)

    Tolga
Permalink | Reply | 0 comments |
headers
Tolga Asveren | 2 Jul 2002 16:16
Favicon

m3ua IG-v01: Position of RC in the message

Javier,

It is said int he draft that NA should be the first parameter, if it is
present. This applies also for RC -for the same reason why NA should be the
first parameter- and it is better to mention about this in the draft.

   Tolga
Permalink | Reply | 3 comments |
headers
Tolga Asveren | 2 Jul 2002 16:22
Favicon

m3ua IG-v01: REGREQ 3.7.2

Javier,

The text for 3.7.2 in IG says:
"If the SG determines that the..." . 3.7.2 in the m3ua draft explains only
about what SGP does for a received REGREQ. Is "SG" in this sentence a typo
and should be in fact "SGP" or not?

   Tolga
Permalink | Reply | 0 comments |
headers
Wung, Joseph | 2 Jul 2002 16:18
Favicon

RE: m3ua IG-v01: Position of RC in the message

Tolga,

I wonder why NA is needed in a message that has RC in it.
Isn't NA implied by RC after a successful key registration?

Joe

-----Original Message-----
From: Tolga Asveren [mailto:tolga.asveren <at> ss8.com]
Sent: Tuesday, July 02, 2002 10:17 AM
To: sigtran <at> ietf.org
Subject: [Sigtran] m3ua IG-v01: Position of RC in the message

Javier,

It is said int he draft that NA should be the first parameter, if it is
present. This applies also for RC -for the same reason why NA should be the
first parameter- and it is better to mention about this in the draft.

   Tolga

_______________________________________________
Sigtran mailing list
Sigtran <at> ietf.org
https://www1.ietf.org/mailman/listinfo/sigtran
Permalink | Reply | 1 comment |

Gmane