Subject: RE: [Sigtran] Re: M3UA: Changeback Issue

From: "Garnero, Pierre" <[email-masked]>
Date: Fri, 15 Mar 2002 11:53:30 +0100

Brian,

by using a either :
  . a timer like T3 (as if IP never consider a C-link between SGs) or
  . a mecanism (may be with HEART-HEART/ACK) that ensure that DATA messages 
    have been (at least) received by the SG1 before sending messages to 
    the "recovered" SG2...and may be the addition of a timer smaller than 
    T3 that allow us to think that SG2 has sent messages coming from SG1
    (if any).

It is true that it is not 100% reliable but it seems to be a lot easier to
implement => in the solution you propose, I think that the NIF must be able
to deal with the MTP3 internals (to dictate the MTP3 layer to send a CDB)
and not only with a simple MTP3 application API.
And it seems strange to me to report a pure IP problem on the SS7 side.

/Pierre  

> -----Original Message-----
> From: Brian F. G. Bidulock [mailto:[email-masked]]
> Sent: Friday, March 15, 2002 11:11 AM
> To: Garnero, Pierre
> Cc: Greg Sidebottom; [email-masked]
> Subject: Re: [Sigtran] Re: M3UA: Changeback Issue
> 
> 
> Pierre,
> 
> And how does this "M3UA changeback" avoid missequencing?
> 
> --brian
> 
> Garnero, Pierre wrote:                                   
> (Fri, 15 Mar 2002 10:54:47)
> > Brian,
> > 
> > in my opinion, CBD does not need to be sent on the SS7 network,
> > when there is a "M3UA changeback" in the IP network.
> > 
> > /Pierre
> > 
> > > -----Original Message-----
> > > From: Brian F. G. Bidulock [mailto:[email-masked]]
> > > Sent: Friday, March 15, 2002 9:52 AM
> > > To: Garnero, Pierre
> > > Cc: Greg Sidebottom; [email-masked]
> > > Subject: Re: [Sigtran] Re: M3UA: Changeback Issue
> > > 
> > > 
> > > Garnero,
> > > 
> > > I am speaking to Q.704 6.2.1(b)(i).  The SDLs only describe Q.704
> > > 6.2.1(b)(ii).  Nevertheless, CBD needs to be sent.  How does the
> > > ASP ask an SG acting as STP to send CBD to its mate?
> > > 
> > > --brian
> > > 
> > > Garnero, Pierre wrote:                        (Fri, 15 Mar 
> > > 2002 08:49:25)
> > > > Bidulock,
> > > > 
> > > > some new comments:
> > > > 
> > > > > -----Original Message-----
> > > > > From: Brian F. G. Bidulock [mailto:[email-masked]]
> > > > > Sent: Thursday, March 14, 2002 8:37 PM
> > > > > To: Garnero, Pierre
> > > > > Cc: Greg Sidebottom; [email-masked]
> > > > > Subject: Re: [Sigtran] Re: M3UA: Changeback Issue
> > > > > 
> > > > > 
> > > > > Garnero,,
> > > > > 
> > > > > Garnero, Pierre wrote:                                   
> > > > > (Thu, 14 Mar 2002 13:34:12)
> > > > > > Brian,
> > > > > > 
> > > > > > some comments in your answer.
> > > > > > 
> > > > > > > -----Original Message-----
> > > > > > > From: Brian F. G. Bidulock [mailto:[email-masked]]
> > > > > > > Sent: Thursday, March 14, 2002 10:22 AM
> > > > > > > To: Garnero, Pierre
> > > > > > > Cc: Greg Sidebottom; [email-masked]
> > > > > > > Subject: Re: [Sigtran] Re: M3UA: Changeback Issue
> > > > > > > 
> > > > > > > 
> > > > > > > Pierre,
> > > > > > > 
> > > > > > > Yes, a BEAT mechanism should work when SP is 
> changing traffic
> > > > > > > back from linkset A2 to A1.  So, in the example, 
> linkset A1
> > > > > > > has failed and recovered and SP sends CBD on 
> linkset A2 to SG2
> > > > > > > and SG2 sends BEAT (ordered in the necessary 
> stream) to active
> > > > > > > ASPs possibly with the CBC and some marker in the 
> heartbeat
> > > > > > > info.  When SG2 receives enough BEAT Acks from 
> active ASPs, it
> > > > > > > sends CBA with the necessary CBC back to the SP and the
> > > > > > > changeback can complete correctly.
> > > > > > > 
> > > > > > > However, when the SPMC is restarting traffic on a 
> recovered
> > > > > > > association it is changing back that traffic, 
> say, from SG2
> > > > > > > to SG1.  There is no way for an ASP to ask an SG 
> to send CBA
> > > > > > > to SP on its behalf so that it can perform the coordinated
> > > > > > > changeback.  Because the SPMC is viewed as a SEP 
> in the SS7
> > > > > > > network, it must send CBD when redirecting 
> traffic flows to
> > > > > > > the SS7 network or this "virtual" SPMC will fail 
> SS7 (Q.782)
> > > > > > > conformance.  BEAT/Ack will not do in this case, 
> becase the
> > > > > > > SG cannot know for which BEAT messages to send CBD and for
> > > > > > > which to not send CBD (heartbeat info is opaque to 
> > > the receiver
> > > > > > > of the BEAT).
> > > > > > > 
> > > > > > 
> > > > > > This mecanism seems pretty complicated...
> > > > > > More than that, I think that even the SS7 "normal" 
> changeback 
> > > > > > mecanism does not ensure that the adjacent PC has 
> > > flushed all its 
> > > > > > data messages. 
> > > > > 
> > > > > I think you are confusing changeback with changeover.
> > > > > Although it is true in the case of changeover, in the 
> changeback
> > > > > case there is no probability of missequencing inherent to the
> > > > > procedure.  All messages are indeed flushed on the 
> routeset for
> > > > > the SLS value (traffic flow) being flushed for each 
> traffic flow
> > > > > and for each routeset in the changeback.
> > > > No. I just look at Figure 31/Q.704 (sheet 1 of 2) - 
> > > > Signalling traffic management; changeback control (TCBC)
> > > > => on receipt of CBD, the only action required is: send 
> back a CBA.
> > > > There is no need to verify that messages have been 
> > > forwarded. We could
> > > > always imagine that some messages are still in a transmit 
> > > buffer in the
> > > > machine that send the CBA. In the reality, this is 
> unlikely but...
> > > > > 
> > > > > > It just ensure that the adjacent PC has received all the 
> > > > > messages when
> > > > > > the CBD initiator receives the acknowledge.
> > > > > > Then, I think that most of the cases could be 
> solved either by:
> > > > > >   . a timer (like ITU T3) started on AS side
> > > > > >   . or a simple flushing mecanism (like BEAT-BEAT/ACK), 
> > > > > initiated by the 
> > > > > >     AS in this case...
> > > > > 
> > > > > This would be the equivalent of controlled re-routing in 
> > > SS7.  This
> > > > > would not permit an M3UA attached SEP to meet validation and 
> > > > > compatibility
> > > > > tests in one direction per Q.782 clause 4.
> > > > > 
> > > > > > 
> > > > > > And I have the filling that in the solution you propose 
> > > the CBD is
> > > > > > sent with an OPC equal to the SPMC "point code" (but I 
> > > > > could be wrong). 
> > > > > > As it is possible to have multiple SPMC's behind the SGs, I 
> > > > > cannot figure
> > > > > > out how a SEP (or a legal STP) can handle that if it is not 
> > > > > M3UA aware.
> > > > > > I am quite sure that most of the current SS7 PCs will 
> > > > > discard a CHM MTP3
> > > > > > message coming from a non configured "adjacent", because I 
> > > > > think that
> > > > > > in most of current SS7 implementations, there is only one 
> > > > > adjacent on the
> > > > > > other side of a single linkset... 
> > > > > 
> > > > > On the contrary, STPs are required to pass CBD/CBA as they do 
> > > > > any other
> > > > > SS7 message.  In the quasi-associated mode, CBD/CBA are 
> > > normally only
> > > > > addressed to remote signalling points.  I can't think of 
> > > a situation
> > > > > in which CBD/CBA contains the OPC/DPC of a pure STP.
> > > > It is true true the CBD messages could be forwarded by 
> an STP but 
> > > > look at Figure 31/Q.7604 (sheet 2 of 2) - Signalling 
> > > traffic management;
> > > > changeback control (TCBC)
> > > > => the CBD is sent to an adjacent PC only (comment included 
> > > in the spec:
> > > >  "Is SP at remote end of newly available link accessible 
> > > via alternative
> > > > link ?"
> > > > At the remote end of a link... there is an adjacent right ?
> > > > And it is possible to have the OPC of an STP in a CBD, 
> > > there is no "STP function"
> > > > flag in TCBC....
> > > > 
> > > > 
> > > > 
> > > > 
> > > > > 
> > > > > --brian
> > > > > 
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > > The ASP cannot just flip traffic flows back 
> between SGs when
> > > > > > > associations and RCs become active according to 
> > > simple loadsharing
> > > > > > > rules: it must ensure that the traffic flow is 
> flushed with
> > > > > > > a CBD before restoring traffic to a newly active or 
> > > restored SG.
> > > > > > > 
> > > > > > > Now, you might think that an SG could just send 
> CBDs on the
> > > > > > > ASPs behalf when reactivating traffic; however, 
> the CBA does
> > > > > > > not have to take the same reverse path through 
> the SS7 network
> > > > > > > that the CBD took.   That is, a CBD launched by 
> SG1 could be
> > > > > > > acknowledged by the SP by sending a CBA via SG2.  
> In this case
> > > > > > > SG1 would never see the reply.
> > > > > > > 
> > > > > > > Getting it working in both directions might require the
> > > > > > > addition of a new message type to M3UA/SUA so that the
> > > > > > > ASP can ask an SG to launch CBD and so that it can receive
> > > > > > > the equivalent of CBA from any SG before 
> restarting traffic
> > > > > > > on a new or restored routing context and stream.
> > > > > > > 
> > > > > > > --brian
> > > > > > > 
> > > > > > > > > > 
> > > > > > > > > >                +-------+        - - - - - 
> > > > > > > > > >                |       |       | /-----\ |
> > > > > > > > > >                |  SG1  |---------| ASP1|
> > > > > > > > > >               /| "STP" |\      |/\-----/ |
> > > > > > > > > >           A1 / |       | \     /
> > > > > > > > > >             /  +-------+  \   /|   AS    |
> > > > > > > > > >     /----\ /       |       \ /
> > > > > > > > > >     | SP |/        |        X  |  SPMC   |
> > > > > > > > > >     |    |\        |       / \
> > > > > > > > > >     \----/ \       |      /   \|         |
> > > > > > > > > >             \  +-------+ /     \
> > > > > > > > > >           A2 \ |       |/      |\/-----\ |
> > > > > > > > > >               \|  SG2  |---------| ASP2|
> > > > > > > > > >                | "STP" |       | \-----/ |
> > > > > > > > > >                |       |        - - - - -
> > > > > > > > > >                +-------+
> > > > > > > > > > 
> > > > > > > 
> > > > > > > Garnero, Pierre wrote:                                   
> > > > > > > (Thu, 14 Mar 2002 09:36:38)
> > > > > > > > Brian,
> > > > > > > > 
> > > > > > > > Yes, I think that this problem must be fixed 
> and I suppose 
> > > > > > > that if it
> > > > > > > > is possible to use HEARTBEAT messages on a stream basis 
> > > > > > > (and not only
> > > > > > > > on stream 0), we could implement this mechanism 
> > > with an already
> > > > > > > > existing M3UA (ou SUA) message (on receipt of the 
> > > > > HEARTBEAT_ACK, we
> > > > > > > > could consider that the messages send (before the 
> > > > > HEARTBEAT) on a
> > > > > > > > particular stream have been "flushed" and then 
> received by 
> > > > > > > the ASP). 
> > > > > > > >
> > > > > > > > If I remember well, you have already proposed such a 
> > > > > mechanism...
> > > > > > > > 
> > > > > > > > 
> > > > > > > > Cheers,
> > > > > > > > 
> > > > > > > > Pierre
> > > > > > > > 
> > > > > > > > > -----Original Message-----
> > > > > > > > > From: Brian F. G. Bidulock 
> [mailto:[email-masked]]
> > > > > > > > > Sent: Wednesday, March 13, 2002 9:18 PM
> > > > > > > > > To: Greg Sidebottom; [email-masked]
> > > > > > > > > Subject: [Sigtran] Re: M3UA: Changeback Issue
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > Sigtraners,
> > > > > > > > > 
> > > > > > > > > We never corrected this problem with M3UA/SUA.  M3UA
> > > > > > > > > cannot support interworking with the SS7 network for
> > > > > > > > > multiple SGs and will fail Q.782 conformance tests
> > > > > > > > > pertaining to changeback.
> > > > > > > > > 
> > > > > > > > > Should this be corrected in the implementors guide?
> > > > > > > > > 
> > > > > > > > > --brian
> > > > > > > > > 
> > > > > > > > > On Wed, 11 Jul 2001, Brian F. G. Bidulock wrote:
> > > > > > > > > 
> > > > > > > > > > All,
> > > > > > > > > > 
> > > > > > > > > > M3UA does not provide support for the SS7 
> MTP changeback
> > > > > > > > > > procedure where multiple SG are involved.
> > > > > > > > > > 
> > > > > > > > > > Here is the scenario:
> > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > >                +-------+        - - - - - 
> > > > > > > > > >                |       |       | /-----\ |
> > > > > > > > > >                |  SG1  |---------| ASP1|
> > > > > > > > > >               /| "STP" |\      |/\-----/ |
> > > > > > > > > >           A1 / |       | \     /
> > > > > > > > > >             /  +-------+  \   /|   AS    |
> > > > > > > > > >     /----\ /       |       \ /
> > > > > > > > > >     | SP |/        |        X  |  SPMC   |
> > > > > > > > > >     |    |\        |       / \
> > > > > > > > > >     \----/ \       |      /   \|         |
> > > > > > > > > >             \  +-------+ /     \
> > > > > > > > > >           A2 \ |       |/      |\/-----\ |
> > > > > > > > > >               \|  SG2  |---------| ASP2|
> > > > > > > > > >                | "STP" |       | \-----/ |
> > > > > > > > > >                |       |        - - - - -
> > > > > > > > > >                +-------+
> > > > > > > > > > 
> > > > > > > > > > The SP loses linkset A1.  Traffic is 
> succesfully changed
> > > > > > > > > > over to linkset A2.  Linkset A1 restores.  
> SP peforms
> > > > > > > > > > changeback procedure per Q.704 6.2.1 (b) (i) 
> > > (that is, on
> > > > > > > > > > a per-destination basis).  It sends a CBD 
> for each SLS
> > > > > > > > > > which is being diverted from A2 back to A1 
> with a DPC of
> > > > > > > > > > the SPMC.
> > > > > > > > > > 
> > > > > > > > > > What is SG2 to do with the CBD?  If it responds 
> > > with a CBA
> > > > > > > > > > there may be messages between SG2 and ASP1 
> or ASP2 which
> > > > > > > > > > have not yet arrived at the ASP and might be 
> > > overtaken by
> > > > > > > > > > the diverted traffic.
> > > > > > > > > > 
> > > > > > > > > > The SG must have a message which it can 
> send to the each
> > > > > > > > > > ASP which has the same effect as a 
> > > changeback-declaration
> > > > > > > > > > which will be responded to by the ASP with 
> a changeback-
> > > > > > > > > > acknowledgement so that mis-sequencing can 
> be avoided
> > > > > > > > > > during changeback procedures per Q.704 6.2.1 (b)(i).
> > > > > > > > > > 
> > > > > > > > > > I can put together proposed text if anyone is 
> > > interested.
> > > > > > > > > > 
> > > > > > > > > > -- 
> > > > > > > > > > Brian F. G. Bidulock
> > > > > > > > > > [email-masked]
> > > > > > > > > > http://www.openss7.org/
> > > > > > > > > 
> > > > > > > > > -- 
> > > > > > > > > Brian F. G. Bidulock    ¦ The reasonable man adapts 
> > > > > > > himself to the ¦
> > > > > > > > > [email-masked]    ¦ world; the unreasonable one 
> > > > > > > persists in  ¦
> > > > > > > > > http://www.openss7.org/ ¦ trying  to adapt 
> the  world  to 
> > > > > > > himself. ¦
> > > > > > > > >                         ¦ Therefore  all  progress  
> > > > > > > depends on the ¦
> > > > > > > > >                         ¦ unreasonable man. -- George 
> > > > > > > Bernard Shaw ¦
> > > > > > > > > 
> > > > > > > > > _______________________________________________
> > > > > > > > > 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
> > > > > > > 
> > > > > 
> > > > > -- 
> > > > > Brian F. G. Bidulock
> > > > > [email-masked]
> > > > > http://www.openss7.org/
> > > > > 
> > > 
> > > -- 
> > > Brian F. G. Bidulock
> > > [email-masked]
> > > http://www.openss7.org/
> > > 
> 
> -- 
> Brian F. G. Bidulock
> [email-masked]
> http://www.openss7.org/
> 

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 15 Mar 2002 10:42:16 -0600

Pierre,

Garnero, Pierre wrote:                                   (Fri, 15 Mar 2002 11:53:30)
>     T3 that allow us to think that SG2 has sent messages coming from SG1

The above is already laid out in draft-bidulock-sigtran-corid-00.txt.
The draft also handles the failure (changeover) cases.

--brian

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

---

From: "Tolga Asveren" <[email-masked]>
Date: Fri, 15 Mar 2002 12:23:16 -0500

Brian,

If SCON in ASP->SGP direction (I know you are not a fan of SCON on this
direction, nor am I, but it is in the protocol) is also supposed to be sent
per SG, then when switching to a new association, if the new SGP belongs to
the same SG like the old one, in my opinion SCON might be classified as
divertable (maybe also DAUD?)

Probably other mechanisms on M3UA level (or on LM) will try to resend those
messages -after timeouts etc..- but it could be more elegant, if this was
handled by corid extension draft.

     Tolga

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 15 Mar 2002 11:34:44 -0600

Tolga,

Tolga Asveren wrote:                                        (Fri, 15 Mar 2002 12:23:16)
> handled by corid extension draft.

It could be more elegant, however, that is the way that SS7 works
as well.  If you are sending TFC form an SEP (nodal SCON) then it
is addressed to a remote SEP.  It does not matter which STP it passes
thru.  The same is true for multiple SG.  The SCON relates to a
specific remote signalling point to which TFC indication is being
given.  It does not matter if the SCON goes to SG1 or SG2.  This
is true for all SS7 messages except some link management messages
and changeover messages.

DAUD is the only one that one might not want to divert with the
rest of the messages.  However, (a) when an SG becomes inactive,
the ASP can certainly not be expecting a ressponse, (b) the response
of SG2 to SG1's DAUD is just a reiteration of SSNM previously sent
and will not affect the ASP, and (c) as we dicussed in relation to
MTP Restart, DAUD is a particularly useless message anyway as there
is no requirement on the ASP to maintain this state; also, DAUD
corresponds to no MTP message or user primitive.

Do you still think it is necessary?

--brian

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

---

From: "Tolga Asveren" <[email-masked]>
Date: Fri, 15 Mar 2002 13:22:25 -0500

Brian,

Please see comments below.

  Tolga

> Sent: Friday, March 15, 2002 12:35 PM
> To: Tolga Asveren
> Cc: [email-masked]
> Subject: Re: [Sigtran] corid-00 messages to be resent
>
>
> Tolga,
>
>
[TOLGA] So, you are saying SCON should be diverted in any case(?). O.K.,
that seems fine based on your explanation but in corid Table1 "Divertable
Messages by UA", SCON is not there. That was my point. (In 4.1.1. you leave
some freedom, what might be diverted and what not, but I think that part
should be made more clear.)
> corresponds to no MTP message or user primitive.
[TOLGA] Again on table1 DAUD is not there. If it is never diverted, it is
not wrong, probably M3UA (or LM) will issue a new DAUD.
Although there is no requirement on the ASP to maintain state, this is an
implementation issue. For DAUD, I still think, if the new SGP belongs to the
same SG like the old one, DAUD should be diverted, otherwise not. If it is
diverted to a SGP, belonging to another SG, it is not correct in my opinion.

Another point is, because RC is per ASP/SGP pair, it might be good to
mention that for messages to be diverted, it might be necessary to update RC
fields.

And finally a small proposal, again in 4.1.1.:
"SSNM messages do not qualify as divertable because they can apply to more
than one Application Server". One might add that they already should have
been sent to the new ASP, for the ASs it is active.

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 15 Mar 2002 13:26:57 -0600

Tolga,

Plesae see comments below...

Tolga Asveren wrote:                                        (Fri, 15 Mar 2002 13:22:25)
> should be made more clear.)

Sorry, I completely missed your point.  Yes, is should be in the
list.  I will add it.

> not wrong, probably M3UA (or LM) will issue a new DAUD.

Again, I apologize, I completely missed your point.  Would you agree that
DAUD should be divertable between SGP but not necessarily between SG.

> implementation issue.

I would disagree that it is an implementation issue: is is a compatibility
issue.  The ASP should never maintain destination state unless it is operating
in multiple "SG" mode, and then only to contrast between SGs.  The SG is the
master of the destination state.  This is the only way to meet MTP-User
expectations.  Many MTP-Users are implemented so as to never maintain
destination state within the User.  They send messages and rely upon the
interface semantics (ITU is different than ANSI in this regard) and those
semantics are only available at the SG because they are part of the MTP
implementation.  Supporting DAUD at the SG should even be optional because
the MTP/MTP-User interface has no such primitive.

> For DAUD, I still think, if the new SGP belongs to the

Ok.  That's what I though above too.

> mention that for messages to be diverted, it might be necessary to update RC

Well, I thought there was a requirement to coordinate RC values between SGP
belonging to the same SG.  We had that in M3UA at one point, isn't it still
there?  I agree that RC (and even NA) values may need to be changed between SG.
I will add a note.

> been sent to the new ASP, for the ASs it is active.

Sounds right to me.  I will add a note as well.

Here are the changes:

	897,901c897,899
	<    duplication or mis-sequencing.  All SSNM messages SHALL be classified
	<    as divertable, with the exception of DAUD which SHOULD be classified
	<    divertable between ASPs or SGPs belonging to the same SG, and SHOULD
	<    be classified as non-divertable between SGs.  UA-User messages that
	<    qualify as divertable messages in addition to SSNM are listed in
	---
	>    duplication or mis-sequencing.  SNMM messages do not quality as
	>    divertable because they can apply to more than on Application Server.
	>    UA-User messages that qualify as divertable messages are listed in
	943a942,943
	1209c1209
	<           diversion buffer, to the alternate SPP.[9]
	---
	>           diversion buffer, to the alternate SPP.
	1718,1726c1718
	<    [9]  IMPLEMENTATION NOTE:-  When restarting traffic with the contents
	<         of the diversion buffer, it might be necessary to reassign RC
	<         values within the messages if the RC values were assigned before
	<         buffering, and if the RC values associated with the AS traffic
	<         for the alternate SPP are different that the RC values
	<         associated with the same AS traffic for the failed SPP.
	< 
	< 
	<    [10] IMPLEMENTATION NOTE:-  Although the unique identifier placed in
	---
	>    [9]  IMPLEMENTATION NOTE:-  Although the unique identifier placed in

--brian

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

---

From: "Tolga Asveren" <[email-masked]>
Date: Fri, 15 Mar 2002 15:35:32 -0500

Brian,

In my opinion the changes are fine: SCON will be in the divertable list for
ASP->SGP direction, DAUD is divertable between SGPs -but not between SGs-,
RC should be updated if necessary (even if we assume that RC values are the
same among SGPs of the same SG, it might be the case that traffic is
diverted to a SGP belonging to another SG) and adding some small clarifying
sentences.

   Tolga

> Sent: Friday, March 15, 2002 2:27 PM
> To: Tolga Asveren
> Cc: [email-masked]