Subject: RE: [Sigtran] duna for whole network done with RC]

From: "Javier Pastor-Balbas (ECE)" <[email-masked]>
Date: Tue, 16 Apr 2002 14:58:50 +0200

Hi Tolga, 

I think, the reason for that was: NA has to be specified only if you want to refer to a specific network and it is not included into the RC. Otherwise it refers to all the possible network with the strengements of RC definitions (if NA included)

Cheers // Javier.

> -----Original Message-----
> From: Tolga Asveren [mailto:[email-masked]]
> Sent: Tuesday, April 16, 2002 2:53 PM
> To: [email-masked]
> Subject: RE: [Sigtran] duna for whole network done with RC]
> 
> 
> Nahar,
> 
> Probably you are referring to the sentence (On page47 Network 
> Appearence)
> "The absence of the Network Appearence parameter in 
> theRouting Key indicates
> the use of any Network Appearence value"
> I don't know the story behind this sentence, our maybe it is 
> just wrong and
> did somehow manage to survive till now. If it should be 
> interpreted as "as
> all of the NAs defined on SGP", it does not make too much 
> sense to me -at
> least for now-. I would expect something like "if there is 
> traffic carried
> belonging to more than one network, than it is mandatory etc.." Other
> opinions?
> 
>    Tolga
> 
> > -----Original Message-----
> > From: Nahar,virendra [mailto:[email-masked]]
> > Sent: Monday, April 15, 2002 9:14 PM
> > To: Tolga Asveren
> > Cc: [email-masked]
> > Subject: Re: [Sigtran] duna for whole network done with RC]
> >
> >
> > Hi Tolga
> > If ASP registers RK with no NA the draft says no NA means all NA
> > so in this case when a PC is affected thru one interface i.e NA then
> > NA becomes must in DUNA. Correct me if wrong........................
> >
> > Thanks
> > Nahar
> >
> > Tolga Asveren wrote:
> >
> > > Umesh,
> > >
> > > I don't think for any case DUNA with NA is necessary. RC always
> > implies NA.
> > >
> > >  Tolga
> > >
> > > > -----Original Message-----
> > > > From: Vats, Umesh [mailto:[email-masked]]
> > > > Sent: Monday, April 15, 2002 7:58 PM
> > > > To: 'Tolga Asveren'; [email-masked]
> > > > Subject: RE: [Sigtran] duna for whole network done with RC]
> > > >
> > > >
> > > > Hi  Tolga/Nahar
> > > >
> > > > MTP3 RESTART itself may happen just for one of the networks.
> > > > Suppose an MTP3 is operating in ITU and ANSI networks and
> > > > a link in ANSI network comes UP, then MTP3 restart for
> > > > ANSI network happens. In this case, DUNA with specific NA
> > > > is needed.
> > > >
> > > > Umesh
> > > >
> > > > -----Original Message-----
> > > > From: Tolga Asveren [mailto:[email-masked]]
> > > > Sent: Monday, April 15, 2002 2:50 PM
> > > > To: [email-masked]
> > > > Subject: RE: [Sigtran] duna for whole network done with RC]
> > > >
> > > >
> > > > Nahar,
> > > >
> > > > Please note that NA is optional, whereas RC is semi-optional
> > (currently
> > > > draft syas it is optional but it will be corrected in 
> the implementors
> > > > guide)So, sending NA is never mandatory, but if you like you
> > can send it
> > > > whenever you want.
> > > > In the MTP3 Restart scenario, you don't need to fill NA
> > parmaeter to DUNA
> > > > but if there are associations which are serving more than one
> > AS, for them
> > > > you have to put RC parameters.
> > > >
> > > >    Tolga
> > > >
> > > > > -----Original Message-----
> > > > > From: Nahar,virendra [mailto:[email-masked]]
> > > > > Sent: Monday, April 15, 2002 5:30 PM
> > > > > To: Tolga Asveren
> > > > > Cc: [email-masked]
> > > > > Subject: Re: [Sigtran] duna for whole network done with RC]
> > > > >
> > > > >
> > > > > Hi
> > > > >
> > > > > I fully agree with ur view point on simplicity .In 
> case of MTP3
> > > > > RESTART at SG
> > > > > everything would be down right so no NA will be filled in
> > outgoing DUNA
> > > > > (indicating Network appearence is down) to ASP . Am I
> > correct in sending
> > > > > DUNA without NA  in this situation.
> > > > >
> > > > > Thanks
> > > > > Nahar
> > > > >
> > > > >
> > > > > Tolga Asveren wrote:
> > > > >
> > > > > > Nahar,
> > > > > > What if you have ASs belonging to different 
> networks and if you
> > > > > loose your
> > > > > > connectivity only to one network? Then NA should be made
> > > > > mandatory to handle
> > > > > > such a case. All this would just complicate things(different
> > > > > > interpretations, what if scenarios, assumptions 
> etc....). As a
> > > > > big-fan of
> > > > > > simplicity, personally I would prefer to keep RC 
> mandatory for
> > > > > all cases, if
> > > > > > the association serves more than one AS. (last week 
> I thought
> > > > > what you say
> > > > > > might make sense but then was convoinced it will just
> > > > complicate things)
> > > > > >
> > > > > >    Tolga
> > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: [email-masked]
> > > > > [mailto:[email-masked]]On Behalf Of
> > > > > > > Nahar,virendra
> > > > > > > Sent: Monday, April 15, 2002 4:52 PM
> > > > > > > To: Sigtran
> > > > > > > Subject: Re: [Sigtran] duna for whole network 
> done with RC]
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > Hi
> > > > > > > The MASK value in this case will  serves as All RC flag .
> > > > > > > I think  this case should be acceptable .
> > > > > > >
> > > > > > > Thanks
> > > > > > > nahar
> > > > > > >
> > > > > > > Thanks
> > > > > > > Nahar
> > > > > > >
> > > > > > > "Ong, Lyndon" wrote:
> > > > > > >
> > > > > > > > Hi Folks,
> > > > > > > >
> > > > > > > > I believe Tolga is correct, we had some 
> discussion of this
> > > > > > > > a while back but ended up making RC required for SSNM if
> > > > > > > > you are using multiple RCs.  There was some 
> concern expressed
> > > > > > > > about this at the time, we could explore if 
> there are any
> > > > > > > > ways to simplify this (e.g., define some added 
> flag or special
> > > > > > > > value of RC?)
> > > > > > > >
> > > > > > > > Cheers,
> > > > > > > >
> > > > > > > > Lyndon
> > > > > > > >
> > > > > > > > -----Original Message-----
> > > > > > > > From: Tolga Asveren [mailto:[email-masked]]
> > > > > > > > Sent: Monday, April 15, 2002 12:58 PM
> > > > > > > > To: [email-masked]
> > > > > > > > Subject: RE: [Sigtran] duna for whole network 
> done with RC
> > > > > > > >
> > > > > > > > 3.4.1 says
> > > > > > > > "Routing Context.........
> > > > > > > > Where multiple Routing Keys and Routing Contexs are used
> > > > > across a common
> > > > > > > > association, the Routing Context(s) MUST be sent to
> > > > > identify concerned
> > > > > > > > traffic flows...."
> > > > > > > > So, in such a case RC is mandatory.
> > > > > > > >
> > > > > > > >     Tolga
> > > > > > > >
> > > > > > > > > -----Original Message-----
> > > > > > > > > From: Nahar,virendra 
> [mailto:[email-masked]]
> > > > > > > > > Sent: Monday, April 15, 2002 3:39 PM
> > > > > > > > > To: Tolga Asveren
> > > > > > > > > Cc: [email-masked]
> > > > > > > > > Subject: Re: [Sigtran] duna for whole network 
> done with RC
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > Hi
> > > > > > > > > But Since RC is optional feature & since DUNA 
> carries the
> > > > > > > > > required info why
> > > > > > > > > should it be mandated
> > > > > > > > > to put in this case !!
> > > > > > > > >
> > > > > > > > > Thanks
> > > > > > > > > Nahar
> > > > > > > > >
> > > > > > > > > Tolga Asveren wrote:
> > > > > > > > >
> > > > > > > > > > In my opinion, based on the current draft, you
> > have to include
> > > > > > > > > RC for SSNM,
> > > > > > > > > > if the association is used for more than one AS,
> > it does not
> > > > > > > > > matter whether
> > > > > > > > > > DUNA is for the whole network or not.
> > > > > > > > > >
> > > > > > > > > >     Tolga
> > > > > > > > > >
> > > > > > > > > > > -----Original Message-----
> > > > > > > > > > > From: Nahar,virendra 
> [mailto:[email-masked]]
> > > > > > > > > > > Sent: Monday, April 15, 2002 3:29 PM
> > > > > > > > > > > To: Tolga Asveren
> > > > > > > > > > > Cc: [email-masked]
> > > > > > > > > > > Subject: Re: [Sigtran] duna for whole network
> > done with RC
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > Hi
> > > > > > > > > > > What if duna conveys whole network 
> appearence is down
> > > > > & doesn't
> > > > > > > > > > > carries the RC
> > > > > > > > > > > list
> > > > > > > > > > > Thanks
> > > > > > > > > > > Nahar
> > > > > > > > > > >
> > > > > > > > > > > Tolga Asveren wrote:
> > > > > > > > > > >
> > > > > > > > > > > > This was discussed last week. I don't 
> think it is
> > > > correct to
> > > > > > > > > > > ignore RC list.
> > > > > > > > > > > > All of the relevant RCs should be listed in
> > the message.
> > > > > > > > > > > >
> > > > > > > > > > > >    Tolga
> > > > > > > > > > > >
> > > > > > > > > > > > > -----Original Message-----
> > > > > > > > > > > > > From: [email-masked]
> > > > > > > > > > > [mailto:[email-masked]]On Behalf Of
> > > > > > > > > > > > > Nahar,virendra
> > > > > > > > > > > > > Sent: Monday, April 15, 2002 3:12 PM
> > > > > > > > > > > > > To: Sigtran
> > > > > > > > > > > > > Subject: [Sigtran] duna for whole network
> > done with RC
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > Hi All
> > > > > > > > > > > > >   when an ASP gets a masked DUNA which is say
> > > > > equal to l (or
> > > > > > > > > > > > > greater than) the
> > > > > > > > > > > > >    number of bits in the PC  i.e it
> > indicates that the
> > > > > > > > > entire network
> > > > > > > > > > > > >    appearance is affected .But if such a
> > DUNA message
> > > > > > > is received
> > > > > > > > > > > > > with RC list
> > > > > > > > > > > > >    what sould be done .I am currently ignoring
> > > > > the RC list as
> > > > > > > > > > > DUNA conveys
> > > > > > > > > > > > >    entire network appearence is 
> down.Is this OK
> > > > > > > > > > > > >
> > > > > > > > > > > > > Thanks
> > > > > > > > > > > > > Nahar
> > > > > > > > > > > > > --
> > > > > > > > > > > > > Virendra Nahar
> > > > > > > > > > > > > HCL-Technologies Ltd
> > > > > > > > > > > > > Networking Systems Lab
> > > > > > > > > > > > > 51, Jawaharlal Nehru Road
> > > > > > > > > > > > > Guindy Industrial Estate,
> > > > > > > > > > > > > Ekkatuthangal,
> > > > > > > > > > > > > Chennai - 600 097.
> > > > > > > > > > > > > Phone Off : +91 44 233 4174 or +91 44 233
> > > > > 4181(extn:261,218)
> > > > > > > > > > > > > mailto:[email-masked]
> > > > > > > > > > > > >
> > > > > ############################################################
> > > > > > > > > > > > > "He who has a why for life can put 
> with any how."
> > > > > > > > > > > > >                              
> Frederick Nietzsche
> > > > > > > > > > > > >
> > > > > ############################################################
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > 
> _______________________________________________
> > > > > > > > > > > > > Sigtran mailing list
> > > > > > > > > > > > > [email-masked]
> > > > > > > > > > > > > https://www1.ietf.org/mailman/listinfo/sigtran
> > > > > > > > > > > >
> > > > > > > > > > > > _______________________________________________
> > > > > > > > > > > > Sigtran mailing list
> > > > > > > > > > > > [email-masked]
> > > > > > > > > > > > https://www1.ietf.org/mailman/listinfo/sigtran
> > > > > > > > > > >
> > > > > > > > > > > --
> > > > > > > > > > > Virendra Nahar
> > > > > > > > > > > HCL-Technologies Ltd
> > > > > > > > > > > Networking Systems Lab
> > > > > > > > > > > 51, Jawaharlal Nehru Road
> > > > > > > > > > > Guindy Industrial Estate,
> > > > > > > > > > > Ekkatuthangal,
> > > > > > > > > > > Chennai - 600 097.
> > > > > > > > > > > Phone Off : +91 44 233 4174 or +91 44 233
> > 4181(extn:261,218)
> > > > > > > > > > > mailto:[email-masked]
> > > > > > > > > > >
> > ############################################################
> > > > > > > > > > > "He who has a why for life can put with any how."
> > > > > > > > > > >                              Frederick Nietzsche
> > > > > > > > > > >
> > ############################################################
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > _______________________________________________
> > > > > > > > > > Sigtran mailing list
> > > > > > > > > > [email-masked]
> > > > > > > > > > https://www1.ietf.org/mailman/listinfo/sigtran
> > > > > > > > >
> > > > > > > > > --
> > > > > > > > > Virendra Nahar
> > > > > > > > > HCL-Technologies Ltd
> > > > > > > > > Networking Systems Lab
> > > > > > > > > 51, Jawaharlal Nehru Road
> > > > > > > > > Guindy Industrial Estate,
> > > > > > > > > Ekkatuthangal,
> > > > > > > > > Chennai - 600 097.
> > > > > > > > > Phone Off : +91 44 233 4174 or +91 44 233 
> 4181(extn:261,218)
> > > > > > > > > mailto:[email-masked]
> > > > > > > > > 
> ############################################################
> > > > > > > > > "He who has a why for life can put with any how."
> > > > > > > > >                              Frederick Nietzsche
> > > > > > > > > 
> ############################################################
> > > > > > > > >
> > > > > > > >
> > > > > > > > _______________________________________________
> > > > > > > > Sigtran mailing list
> > > > > > > > [email-masked]
> > > > > > > > https://www1.ietf.org/mailman/listinfo/sigtran
> > > > > > > >
> > > > > > > > _______________________________________________
> > > > > > > > Sigtran mailing list
> > > > > > > > [email-masked]
> > > > > > > > https://www1.ietf.org/mailman/listinfo/sigtran
> > > > > > >
> > > > > > > --
> > > > > > > Virendra Nahar
> > > > > > > HCL-Technologies Ltd
> > > > > > > Networking Systems Lab
> > > > > > > 51, Jawaharlal Nehru Road
> > > > > > > Guindy Industrial Estate,
> > > > > > > Ekkatuthangal,
> > > > > > > Chennai - 600 097.
> > > > > > > Phone Off : +91 44 233 4174 or +91 44 233 
> 4181(extn:261,218)
> > > > > > > mailto:[email-masked]
> > > > > > > 
> ############################################################
> > > > > > > "He who has a why for life can put with any how."
> > > > > > >                              Frederick Nietzsche
> > > > > > > 
> ############################################################
> > > > > > >
> > > > > > > _______________________________________________
> > > > > > > Sigtran mailing list
> > > > > > > [email-masked]
> > > > > > > https://www1.ietf.org/mailman/listinfo/sigtran
> > > > > >
> > > > > > _______________________________________________
> > > > > > Sigtran mailing list
> > > > > > [email-masked]
> > > > > > https://www1.ietf.org/mailman/listinfo/sigtran
> > > > >
> > > > > --
> > > > > Virendra Nahar
> > > > > HCL-Technologies Ltd
> > > > > Networking Systems Lab
> > > > > 51, Jawaharlal Nehru Road
> > > > > Guindy Industrial Estate,
> > > > > Ekkatuthangal,
> > > > > Chennai - 600 097.
> > > > > Phone Off : +91 44 233 4174 or +91 44 233 4181(extn:261,218)
> > > > > mailto:[email-masked]
> > > > > ############################################################
> > > > > "He who has a why for life can put with any how."
> > > > >                              Frederick Nietzsche
> > > > > ############################################################
> > > > >
> > > >
> > > >
> > > > _______________________________________________
> > > > Sigtran mailing list
> > > > [email-masked]
> > > > https://www1.ietf.org/mailman/listinfo/sigtran
> > >
> > > _______________________________________________
> > > Sigtran mailing list
> > > [email-masked]
> > > https://www1.ietf.org/mailman/listinfo/sigtran
> >
> > --
> > Virendra Nahar
> > HCL-Technologies Ltd
> > Networking Systems Lab
> > 51, Jawaharlal Nehru Road
> > Guindy Industrial Estate,
> > Ekkatuthangal,
> > Chennai - 600 097.
> > Phone Off : +91 44 233 4174 or +91 44 233 4181(extn:261,218)
> > mailto:[email-masked]
> > ############################################################
> > "He who has a why for life can put with any how."
> >                              Frederick Nietzsche
> > ############################################################
> >
> 
> 
> _______________________________________________
> 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: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 16 Apr 2002 14:54:38 -0500

Javier,

The reason for permitting NA to be excluded from the REG REQ was for
configurations which are operating soley within a single network.
There is no need to send NA in REG REQ if there is only onw network.
It saves both SGP and ASP assigning some arbitrary default value,
and shortens the message for the typical single-network case.

--brian

Javier Pastor-Balbas (ECE) wrote:                          (Tue, 16 Apr 2002 14:58:50)
> Hi Tolga, 
> 
> I think, the reason for that was: NA has to be specified only if you want to
> refer to a specific network and it is not included into the RC. Otherwise it
> refers to all the possible network with the strengements of RC definitions
> (if NA included)
> 
> Cheers // Javier.
> 
> > Probably you are referring to the sentence (On page47 Network Appearence)
> > "The absence of the Network Appearence parameter in theRouting Key
> > indicates the use of any Network Appearence value" I don't know the story
> > behind this sentence, our maybe it is just wrong and did somehow manage to
> > survive till now. If it should be interpreted as "as all of the NAs
> > defined on SGP", it does not make too much sense to me -at least for now-.
> > I would expect something like "if there is traffic carried belonging to
> > more than one network, than it is mandatory etc.." Other opinions?
> > 
> >    Tolga
> > 

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

---

From: "Nahar,virendra" <[email-masked]>
Date: Wed, 17 Apr 2002 05:05:36 +0530

Hi
Then The draft should not say no NA means any NA.It should be no NA means a single ss7
context
& both SG  & ASP knows the PC type to be used.Its becoming more confusing for me now.

Thanks
Nahar

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 16 Apr 2002 19:37:47 -0500

Nahar,

The RFC does say:

  Routing Key: A Routing Key describes a set of SS7 parameters and 
  parameter values that uniquely define the range of signalling traffic 
  to be handled by a particular Application Server. Parameters within the 
                                                    ^^^^^^^^^^^^^^^^^^^^^
  Routing Key cannot extend across more than a single Signalling Point 
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  Management Cluster.
  ^^^^^^^^^^^^^^^^^^^

And, 

  Signalling Point Management Cluster (SPMC) - The complete set of 
                                               ^^^^^^^^^^^^^^^^^^^
  Application Servers represented to the SS7 network under a single MTP 
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  entity (Signalling Point) in one specific Network Appearance.  SPMCs 
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  are used to aggregate the availability, congestion, and user part status 
  of an MTP entity (Signalling Point) that is distributed in the IP 
  domain, for the purpose of supporting MTP3 management procedures 
  towards the SS7 network.  In some cases, the SG itself may also be a 
  member of the SPMC.  In this case, the SG availability /congestion 
  /User_Part status should also be taken into account when considering any 
  supporting MTP3 management actions.  

So, how did you think that an RK could represent more than one NA?

--brian

Nahar,virendra wrote:                              (Wed, 17 Apr 2002 05:05:36)

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

---

From: "Nahar,virendra" <[email-masked]>
Date: Wed, 17 Apr 2002 06:23:59 +0530

Hi Brian
Thanks For making it clear to me one more query.
Say ASP1 registers RK1 with NA1
NA1 & NA2 are two valid ss7 context for SG
If ASP2 now registers RK1 with NA2 its a unique RK  for SG right & new  AS will be created .
Now can ASP1 register RK1 with NA2 also . I think yes it will be allowed
........................
Pls do correct me if my under standing is wrong here

Thanks
Nahar

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 16 Apr 2002 21:06:33 -0500

Nahar,

According to the quoted passages one cannot
register RK1 with both NA1 and NA2 at the
same time.

--brian

Nahar,virendra wrote:                              (Wed, 17 Apr 2002 06:23:59)

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

---

From: "Nahar,virendra" <[email-masked]>
Date: Wed, 17 Apr 2002 07:51:36 +0530

Hi Brian
In such a case Reg Result will carry code INVALID_NA correct me if wrong............
One more doubt ----------------------------------------------------
Can ASP1 register RK1 with NA1 & RK2 with NA2 or an ASP can't
span any of its RK in more then one NA.......... i.e all should have same NA.
Pls send in ur response

Thanks
Nahar

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 16 Apr 2002 22:23:28 -0500

Nahar,

  If the SGP determines that a unique Routing Key cannot be created, the 
  SGP returns a Registration Response message to the ASP, with a 
  Registration Status of "Error - "Cannot Support Unique Routing"  An 
  incoming signalling message received at an SGP should not match against 
  more than one Routing Key.

--brian

Nahar,virendra wrote:                              (Wed, 17 Apr 2002 07:51:36)

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

---

From: "Tolga Asveren" <[email-masked]>
Date: Wed, 17 Apr 2002 13:41:29 -0400

Hi,

While I am typing and putting everything in a nice format, I thought it
might be a good idea to share in general what was agreed (well, of course
there are still some disagreements, so it is better to add "from my point of
view") in IPSP discussion group, with the whole SIGTRAN group, to get some
feedback,opinions etc....

It seems an approach where we have to extension drafts, one for SG-SG
communication and one for IPSP mode (probably it will be more appropriate to
call it inter-IP communication), is more aprropriate.

In that message I will try to give a brief overview of the proposed SG-SG
communication.
Also for IPSP mode I will send a similar message soon.

   Tolga

SG-SG Communication
===================

1. Overview
The purpose of SG-SG communication is to increase inter-IP communication
capabilities of M3UA peers and to allow SS7 signalling backhauling between
SS7 nodes over IP. (to define SG-SG communication initially only for M3UA is
my personal opinion).

     -----              -----
   //     \\          //     \\
  |  ASP    |        |  ASP    |
  |  Cloud 1|        |  Cloud 2|
   \\     //          \\     //
     --+--              --+--
       |                  |
       |                  |
    +--+--+            +--+--+
    | SG1 +------------+ SG2 |
    +--+--+            +--+--+
       |                  |
       |                  |
       |                  |
       |     +-----+      |
       +-----+ SG3 +------+
             +--+--+
                |
                |
              --+--
            //     \\
           |  ASP    |
           |  Cloud 2|
            \\     //
              -----
Figure1: Inter-IP communication using SG-SG communication.

Inter-IP communication using SG-SG protocol will be explained in detail in
draft[..]

 +---------+              +---------+
 |   SG1   +--------------+   SG2   |
 +----+----+              +----+----+
      |                        |
      |                        |
 +----+----+              +----+----+
 |SS7 node1|              |SS7 node2|
 +---------+              +---------+
Figure2: SS7 backhauling with SG-SG protocol

SG-SG protocol management is based mainly on SSNM as defined in M3UA
RFC[...], with some additional messages to handle changeover and congestion
handling cases as defined in Q.704.

Communication of peers using SG-SG protocol is on PC granularity. (I even
think this as something like M3PA, again personal opinion )

2. Functional Areas
2.1 Signalling Point Code Representation
SGs SHOULD control SPMCs as a whole. When a SPMC becomes unavailable SG will
broadcast DUNA to all SGs, it has an association with. Similarly when a SPMC
becomes available DAVA and when a SPMC becomes restricted DRST will be sent.
(For a full list of those transitions, references to appropriate sections of
Q.704 will be added)

2.2 Routing Context and Routing Keys
Unlike M3UA, there is no Routing Context/Routing Key concept present in
SG-SG protocol.

2.3 Network Appearence
To make an easy transition to a SG-SG protocol, which might be used also for
SUA peers, possible, NA is not used in SG-SG protocol messages. So, one SCTP
association should carry traffic belonging to one network only and this
should be coordinated among peers by configuration.

2.4 SCTP Association Establishment
There is no client/server relationship between peers in SG-SG communication.
SCTP associations might be initiated from any side.
After a SCTP association is established, SGs will exchange SSNM to update
the remote peer about the status of th PCs, whihc are by configuration
declared as reachable via them. Unless a corresponding message is received,
all PCs are assumed as accessible via the remote peer. Each SG will send
DUNA for not reachable PCs and DRST for restricted PCs after the
establishment of association.

3.Protocol Messages
SG-SG protocol uses DATA and SSNM messages from M3UA messages defined in
RFC[...]. RC and NA fields in messages are not used, i.e. they MUST NOT be
filled.

3.1. DUPU
A new filed is introduced to DUPU:
ConcernedPC : Destination PC, which has caused DUPU to be generated.

(Messages corresponding to RCT and changeover mechanism related messages
will be added)

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 18 Apr 2002 08:48:38 -0500

Tolga,

Looks good to me.

--brian

Tolga Asveren wrote:                                        (Wed, 17 Apr 2002 13:41:29)
> ConcernedPC: Destination PC, which has caused DUPU to be generated.
> 

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