Subject: TCP as Transport

From: Sunil Mahajan <[email-masked]>
Date: Tue, 5 Oct 1999 16:33:02 -0700

Brian,
This might have already been discussed, in that case can you please
point me to the relevant (subject) archived mails.

(REF: draft-ietf-megacop-protocol-04.txt dated 21st Sep 1999)
I have few questions related to using TCP as transport for MG-MGC
communication..

- Section 9 Transport
--------------------------
MG needs to send ServiceChange command to MGC to get registered...

Q1:: Does that mean, MG first needs to establish a TCP connection with
MGC to start the communication?
Q2:: MG can send port number with service change command for MGC to
contact MG and MGC on reply can also send port number to MG for further
communication
---- If none of them sends any port, can we assume they use the same TCP
connection for further communication?
---- If MG sends then, is it the responsibility of MGC to establish TCP
connection with MG?
---- IF MGC only sends, is it the responsibility of MG to establish the
TCP connection?
---- What if both sends port number, is it an error condition or does
that mean MGCs reply overides the MGs request and MG establishes the TCP
connection with MGC?

Q3::The mode of communication between MG-MGC is TCP/UDP, is it
determined by the mode for the first serviceChange command from MG to
MGC or is it a configuration parameter at both MG and MGC for each such
association?

Section 11.3 Failure of an MG (2nd Para)
------------------------------------------
Allowing the MGC to send duplicate messages to both MGs accomodates
pairs of MGs that are capable of redundant failover of one of the
MGs.......

Q4:: How does MGC knows that two (or more) MGs are configured in
redundant configuration (is it part of MGC configuration?)?
--- if it is configuration information, what is the initial MGC-MG
interaction, does both MGs register with this MGC using serviceChange
command or only one of them registers and other one is assumed to be
registered and only needs to establish TCP connection with the MGC.
What happens when MGC fails, both the MGs need to register with the new
MGC returned in serviceChange from MGC (or next in the secondary MGC
list) or we have a different behavior?

Q5:: What does MGC do, if MGs are not configured as mated MGs and it
fails, does it drop all the pending transaction with that MG?

Q6:: How does an MG communicates with an MGC, if it has two IP address
(and interfaces) for communication, does that mean it should register
with MGC as two MGs (in redundant configuration)? and if one interface
fails it is still able to communicate with the MGC on other interface
with MGC maintaining all pending transactions? I mean how do we tell MGC
that these two MGs are in redundant configuration?

Section 11.4 Failure of an MGC
--------------------------------
This section explains how an MGC with two interfaces can ask MG to
switchover to another interface (in MGCIdtotry which is a different
interface Id but on the same MGC) if one interface fails. Can we have
something similar to this for MGs also?

Section 11.3 and Section 11.4
--------------------------------
These section gives an elaborate mechanism for MG and MGC switchover, if
they are able to communicate to other entity before dying. What happens
if one of them fails (may be an interface failure for
communication)......
For MGC it looks easy, as MGs can be configured with multiple MGCIds as
secondary MGC (which actually may belong to same MGC or may be to
different MGCs), but for MGC it is not very clear as how to handle MG
failure (may be interface failure), if MG is not able to communicate the
failure to MGC, the only option given is to have mated MGs, but the
exact mechanism for communication is not very clear.

Can we introduce multiple interfaces (multiple Ids for same entity -
MG/MGC) for both MG/MGC when exchanging serviceChange message, so that
if they specify multiple interface parameters (descriptors), that
implies on communication failure (max reties exceeded or TCP connection
failure indication), the other interface shall be tried before trying to
go to the other entity (in secondary list or redundant configuration).
This will help in building high availability solutions with all failures
backed up by redundant configuration. And if an MG or MGC does not
specify multiple interfaces in serviceChange message, then the behavior
is as specified today.

Regards,
Sunil Mahajan

---

From: Tom-PT Taylor <[email-masked]>
Date: Wed, 6 Oct 1999 10:40:10 -0400

My understanding below.

> -----Original Message-----
> From: Sunil Mahajan [SMTP:[email-masked]]
> Sent: Tuesday, October 05, 1999 7:33 PM
> To:   [email-masked]
> Subject:      TCP as Transport
>
> Brian,
        [[TomT]]  Yes.

> connection for further communication?
        [[TomT]]  Yes.

> ---- If MG sends then, is it the responsibility of MGC to establish TCP
        [[TomT]]  I would like a discussion on whether it makes sense for
the MG to send a port number.  I think the spirit of our decision on
transport (that the MG selects it) suggests that it is always the
responsibility of the MG to establish the connection.

> ---- IF MGC only sends, is it the responsibility of MG to establish the
        [[TomT]]  Yes, based on the view I've just expressed.  It seems to
me that the MG brings up the alternate connection with another
ServiceChange, with a reason along the lines of "MGC requested change of
port".

> that mean MGCs reply overides the MGs request and MG establishes the TCP
        [[TomT]]  Shouldn't happen according to my view of our intent, but
let's see if opinions differ.

> MGC or is it a configuration parameter at both MG and MGC for each such
        [[TomT]]  From the point of view of our protocol, it is determined
by the mode for the first ServiceChange command from MG to MGC.  How the MG
selects that mode is out of scope, but could be either by design or by
configuration.

> Section 11.3 Failure of an MG (2nd Para)
        [[TomT]]  This is certainly possible.  Are you suggesting as an
alternative that we need protocol support to indicate redundancy?  It may be
that we do need something, if only to say that both MGs share the same
termination name space.  Maybe we could define redundancy as a root property
conveyed by a specific package.

> registered and only needs to establish TCP connection with the MGC.
        [[TomT]]  My first thought is that this is implementation dependent,
but if we do not have both MGs registering the solution is purely
proprietary.

> list) or we have a different behavior?
        [[TomT]]  Again, in a non-proprietary system both MGs would have to
register.

> fails, does it drop all the pending transaction with that MG?
        [[TomT]]  Not clear whether you mean MG or MGC failure.  If it is
the MGC, I would assume that by the fact of failure that pending
transactions would be lost unless an alternate MGC was available in hot
standby configuration.  If it is the MG which fails and the MGC is unaware
of the mated relationship it would treat the failure the same as that of a
single unmated MG.  If our protocol had allowed the MGs to signal that they
shared termination name space, the MGC could audit the alternate MG to see
if it knew the current status of each termination.  This doesn't strike me
as very satisfactory -- it still doesn't indicate whether the surviving mate
knows about outstanding transactions.  I return to the suggestion that this
could be a ROOT property conveyed by a redundancy package.

> that these two MGs are in redundant configuration?
        [[TomT]]  As you phrase it this is this the same as Q. 4.  Fact is,
I would recommend using SIGTRAN SCTP in this case instead of TCP.

> Section 11.4 Failure of an MGC
        [[TomT]]  Use SCTP instead?  Leaving that aside, could rename
MGCIdtotry to AlternateId and allow it to be sent by the MG.

> Section 11.3 and Section 11.4
        [[TomT]]  If TCP is running, eventually the MGC becomes aware of
transmission failure.

> specify multiple interfaces in serviceChange message, then the behavior
        [[TomT]]  Again, maybe such behaviour could be indicated by property
values in a redundancy package supported by ROOT.  If you work quickly to
define such a package it could be added to the the basic package I-D.

---

From: Sunil Mahajan <[email-masked]>
Date: Wed, 6 Oct 1999 14:38:20 -0700

Tom,
Thanx for your response and clarifications.
Few more queries/comments below.. (marked with **sunil** )

> responsibility of the MG to establish the connection.

**sunil** in case using UDP probably it makes sense (may be MG sends the
same port number which it is using for initial communication or can send
a different port for further communication, but for TCP as MG
establishes the connection with MGC so MG sending a port parameter with
serviceChange may not be required.

> ServiceChange, with a reason along the lines of "MGC requested change of

**sunil** if MGC sends an alternate TCP port to MG, does it require to
send serviceChange again to this MGC or it needs to establish only the
TCP connection and assumes that registration is done.

> let's see if opinions differ.

**sunil** For TCP, i guess MG should never send the port, but can be
used for UDP.

> conveyed by a specific package.

**sunil** i think we need some kind of protocol support for redundancy
control, otherwise we will have proprietary implementations for this and
will have problems for MG-MGC interoperability.
Can we consider this alternative....

We can assume that any switchover from MGC to MGC or from MG to MG is
initiated by MG only (using serviceChange command).
So for any MG failing or MG switchover, MGC starts a timer to see if
another MG registers with it with a reason as failover, even if MG sends
a serviceChange command to MGC telling it that it has failed, MGC needs
to wait for another MG to connect to it with failover reason for this
MG. If timer at MGC expires MGC clears all the pending transactions and
calls for the failing MG (the reason for failure could be interface
failure, communication failure or actual node failure).

Configuration requirements:
MGs needs to be configured with alternate MGCs for its primary MGC, or
this information can be exchanged between MG and MGC in serviceChange
parameters.

MGs needs to be configured for all its mated MGs for redundancy data
exchange.

MGCs need not be be configured for any alternate MGs (so the
responsibility of updates between mated MGs is with MGs itself)

We need serviceChange command to support additional parameters

Procedures at MG side:
-----------------------
When reason for failover at MG is MGC failure (either indicated by MGC
in serviceChange command or detected by MG for interface failure etc.)
MG can connect to another MGC (may be as indicated by MGCIDtotry in
serviceChange from MGC) with reason as MGC_Switch_over and another
optional parameter as MGCIdSwitchedFrom. On looking at this parameter
new MGC can can either accept the reason or reject it by sending a
parameter as siwtchover_accepted or switchover_rejected. On receiving
this response from MGC, MG can either continue previous transactions (if
returned accepted), ignore previous transactions (if rejected) or can
connect to another MGC in the list.

When an MG fails (either notified to MGC or not), another MG needs to
takeover. This new MG may already be registered with the MGC. So on
switchover the MG sends a service change command with reason as
MG_Switch_Over and sends a parameter in serviceChange as
MGIdswitchedfrom. On receiving this command, MGC can either accept the
command or can reject it by siwtchover_accepted or switchover_rejected.
The behavior of MG is same as specified in previous para.

Procedures at MGC
--------------------
When MGC fails, another MGC takesover and waits for a comand from MGs
with reason as MGC_Switch_Over, if MGC receives the command within
SWITCH_TIME, MGC continues the transaction else it deletes all the
transactions for those MGs for which it didn't receive this command.
On receiving serviceChange command from MG with reason as
MGC_Switch_Over, if MGC contains transaction for the specified MG it
accepts the command or rejects it.

When MG fails, MGC again waits for comand from another MG with reason as
MG_Switch_Over and MGIdswitchedfrom of the failing MG, if MGC receives
the command within SWITCH_TIME, MGC continues the transaction with their
MGids siwtched to new MG else it deletes all the transactions for this
MG.

MGC may sends a list of alternateMGC ids in response to any registration
request from MG (new registration or registration at switchover), on
receiving an alternateMGC list MG may delete the previous list or may
append the list to the current list.

> but if we do not have both MGs registering the solution is purely

**sunil** we should try to avoid any proprietary implementations for
interOp reasons.

> could be a ROOT property conveyed by a redundancy package.

**sunil** my qs was for MG failure.
I am not very clear about, how to support redundancy properties with
packages, packages specifiy the properties and behavior but not the
procedures, i guess we need support in protocol for redundancy (which is
there in the protocol to some extent, but not very clearly specified).

> I would recommend using SIGTRAN SCTP in this case instead of TCP.

**sunil** SIGTRAN SCTP is not part of MEGACOP definition today and i
guess even later we would need to support TCP/UDP at MGC for
compatibility reasons.

> define such a package it could be added to the the basic package I-D.

I am not very clear about, how to support redundancy properties with
packages. Can you please explain me what do you mean by putting
redundancy properties in packages.

> > Sunil Mahajan

Thanx
Regards,
Sunil Mahajan

---

From: Brian Rosen <[email-masked]>
Date: Wed, 6 Oct 1999 21:37:03 -0400

My understanding is basically the same as Tom's

Specifically, I think the MG always starts conversations.
If the MGC specifies a port, the MG should resend a ServiceChange to
the new port, and we will have to have an appropriate reason.

I do not believe we need any protocol support for redundancy beyond the
possibility of a properties, defined in a package, on root.

I don't think we have really thought through all the issues around
two IP addresses for the protocol.  We have thought through multiple IP
addresses for bearers.  I hesitate to make statements about how this would
work at this time.  I think we should defer such discussions to some future
time beyond the initial release of the protocol.

With regard to MGCs discovering failure of MGs, you will recall that a
package was to be defined with a heartbeat event.  That should be one of the
"standard" packages.

Brian

> From: Tom-PT Taylor [mailto:[email-masked]]
> Sent: Wednesday, October 06, 1999 10:40 AM
> To: [email-masked]
> Subject: Re: TCP as Transport
>
>
> My understanding below.
>