Subject: Re: Supplying only a port on a ServiceChangeAddress

From: Tom-PT Taylor <[email-masked]>
Date: Tue, 5 Sep 2000 13:38:11 -0500

As I noted in one or two previous messages, ServiceChangeMgcId has higher
overhead than ServiceChangeAddress in that it implies a new control session.
That is, the MG has to send a ServiceChange to the new address before it can
send anything else.

> -----Original Message-----
> From: Flemming Andreasen [mailto:[email-masked]]
> Sent: Tuesday, September 05, 2000 11:29 AM
> To: [email-masked]
> Subject: Re: Supplying only a port on a ServiceChangeAddress
>
>
> 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
>
>
>
> "Rosen, Brian" wrote:
>
> > 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
> > > >
> > > >
>
> --
> Flemming Andreasen
> Cisco Systems
>

---

From: Flemming Andreasen <[email-masked]>
Date: Tue, 5 Sep 2000 15:09:37 -0400

Tom-PT Taylor wrote:

>
>
> As I noted in one or two previous messages, ServiceChangeMgcId has
> higher overhead than ServiceChangeAddress in that it implies a new
> control session.  That is, the MG has to send a ServiceChange to the
> new address before it can send anything else.

Right, but is that really a problem worth all the trouble and potential
inconsistency we are seeing here ?

-- Flemming

--
Flemming Andreasen
Cisco Systems