Subject: Re: Supplying only a port on a ServiceChangeAddress

From: "Rosen, Brian" <[email-masked]>
Date: Mon, 4 Sep 2000 19:51:35 -0400

It depends on what you want to have happen.

If you want the MG, on receipt of a reply with a ServiceChangeAddress,
to tear down it's current transport connection, create a new one,
and stand by for messages from the MGC, then I suppose you would be
correct.

If it was TCP (and I guess SCTP), this is pretty weird, because the
MG established a full duplex connection, but the next message is
almost certainly from the MGC.  The MGC is going to have to watch for
this carefully, and not send messages until the new channel is up.

Or, the MGC can just use ServiceChangeMid.  The MG will respond by
tearing down the transport, establishing a new one, and sending
a new ServiceChange.  The MGC "fires and forgets" -- the new
ServiceChange, at the "new" address, looks like a complete new start.

Brian

-----Original Message-----
From: Christian Groves
To: [email-masked]
Sent: 9/3/00 7:38 PM
Subject: Re: Supplying only a port on a ServiceChangeAddress

G'Day Brian and Flemming,

I saw that the difference between when you use ServiceChangeAddress and
ServiceChangeMid was that the ServiceChangeAddress was used when talking
to an already contacted physical MGC. The ServiceChangeMid was used to
contact a physically seperate MGC. So I don't see the need of
disallowing anything but the port in IP as the MGC may have a range of
addresses.

Cheers, Christian

"Rosen, Brian" wrote:
>
> I thought you might say that, I've been thinking about it
> since I sent the message.
>
> Posing the question slightly differently, if the ServiceChangeAddress
> can do what ServiceChangeMid can do, so why have two mechanisms?
> The only difference would be the MGs actions.  If you used
> ServiceChangeAddress,
> the MG would not send a new ServiceChange command to the new address.
> If you used ServiceChangeMid, it would.  The end result would be the
same.
>
> We can:
>         Explicitly disallow ServiceChangeAddress from being used to
>                 change anything but IP Port when used with IP
>         Get rid of one of the two of them
>
> I favor the former, as that is easiest, is most consistent with
> history, and makes the most sense to me.  I'll note that what
> we call ServiceChangeAddress used to be "port".  It got
> changed when we realized "port" wouldn't make sense if it was
> not an IP transport.
>
> Brian
>
> > -----Original Message-----
> > From: Flemming Andreasen [mailto:[email-masked]]
> > Sent: Tuesday, August 29, 2000 7:37 PM
> > To: Rosen, Brian
> > Cc: [email-masked]
> > Subject: Re: Supplying only a port on a ServiceChangeAddress
> >
> >
> >
> >
> > "Rosen, Brian" wrote:
> >
> > > I think the issue is that you can have the same MGC have multiple
> > > IP addresses.  You accept the association, but change the address.
> > > Say, a pool of servers appearing to be one MGC.
> >
> > I'm not sure I fully understand what an association is then.
> > What's the
> > difference/relationship between the association address and the
> > ServiceChangeMgcId (which may itself contain an address or
indirectly
> > refer to a number of addresses through DNS) ?
> >
> > -- Flemming
> >
> >
> > >
> > >
> > > Brian
> > >
> > > > -----Original Message-----
> > > > From: Flemming Andreasen [mailto:[email-masked]]
> > > > Sent: Tuesday, August 29, 2000 6:38 PM
> > > > To: Rosen, Brian
> > > > Cc: [email-masked]
> > > > Subject: Re: Supplying only a port on a ServiceChangeAddress
> > > >
> > > >
> > > >
> > > >
> > > > "Rosen, Brian" wrote:
> > > >
> > > > > Suppose all you want to specify in a ServiceChangeAddress
> > > > is a port number
> > > > > that is, the IP address doesn't change, but the port does.
> > > > >
> > > > > The ABNF sez:
> > > > > serviceChangeAddress = ServiceChangeAddressToken EQUAL VALUE
> > > > >
> > > > > This is because it could be IP, ATM, FR, MPLS....
> > > > >
> > > > > The example shows just a port number.
> > > >
> > > > Actually, I thought that's all that would be allowed in the
> > > > case of IP. If
> > > > not, how can it be within the "context of the association
> > > > currently being
> > > > negotiated", and how would it then relate to ServiceChangeMgcId
?
> > > >
> > > > -- Flemming
> > > >
> > > > >
> > > > >
> > > > > Should that be legal?  Should you have to specify the IP
address
> > > > > as x.x.x.x:p?
> > > > > Brian
> > > > --
> > > > Flemming Andreasen
> > > > Cisco Systems
> > --
> > Flemming Andreasen
> > Cisco Systems

---

From: Flemming Andreasen <[email-masked]>
Date: Tue, 5 Sep 2000 11:28:49 -0400

Let's take a step back here and ask ourselves what we are trying to achieve:

1. We have a need to identify the entity we wish to communicate with
2. We have a need to communicate with that entity.

This is a classical naming issue that doesn't need to become overly
complicated. In order to get from the name in 1 to the address (or route) in
2, you need to perform name resolution in the cases where the name itself is
not an address. For domain names, this name resolution is achieved by DNS,
for IP-addresses, it should normally be a NOP. By having both
ServiceChangeMGGId and ServiceChangeAddress, you are effectively providing
an alternate name resolution mechanism which overrides DNS and allows one
IP-address to map to another. We should not be doing that, and I also note
that this was probably not the authors' intent, since ServiceChangeAddress
and ServiceChangeMGCId are not both allowed in a single command.

That still leaves open the question of exactly what ServiceChangeAddress
then is, and I believe Brian answered that earlier with his two proposals.
In a perfect world, I would prefer getting rid of ServiceChangeAddress, but
we may be beyond that. Does it make sense to allow just a port number then ?
Considering that we already allow for port in mId, port is part of the name
and for the same reasons as we shouldn't map one IP-address to another, we
shouldn't map one port to another either IMO. If the MGC (or MG) wants the
other party to talk to it on another port, it simply sends back another
ServiceChangeMGCId with that port number in it.

-- Flemming

--
Flemming Andreasen
Cisco Systems