Subject: Re: Supplying only a port on a ServiceChangeAddress

From: "Rosen, Brian" <[email-masked]>
Date: Tue, 5 Sep 2000 15:22:31 -0400

Yeah, the mId started life as the thing in the header that let an
MGC know which entity it was talking to.  It's always been an
address though - desirable as an FQDN and acceptable to be a hard
address.

The intention of ServiceChangeMid was to be the referral address for an
association that was not acceptable to the MGC.  ServiceChangeAddress used
to be port, and it was just for changing port numbers, not addresses.  We
went downhill (IMO) from there.

I'm with Flemming, one thing is all we need, but we are stuck with 2 for
now.

Brian

> -----Original Message-----
> From: Tom-PT Taylor [mailto:[email-masked]]
> Sent: Tuesday, September 05, 2000 3:16 PM
> To: [email-masked]
> Subject: Re: Supplying only a port on a ServiceChangeAddress
>
>
> I think we agree that MId is just an identifier of a peer in a control
> session.  I still ask myself why we defined it to be an
> address rather than
> an arbitrary string.  I suspect we changed intentions since
> it first showed
> up.
>
> > -----Original Message-----
> > From: Flemming Andreasen [mailto:[email-masked]]
> > Sent: Tuesday, September 05, 2000 3:12 PM
> > To: [email-masked]
> > Subject: Re: Supplying only a port on a ServiceChangeAddress
> >
> >
> > Bharat Kaul wrote:
> >
> > > Hi Flemming, Brian and List,
> > >
> > >   ServiceChangeMGCId should be kept for contacting a new
> > MGC or rather
> > > establishing new control Session.
> > >
> > > ServiceChangeAddress is for redirection within a MGC e.g.
> > MG contacts MGC at
> > > a default port and based on some policy MGC wants to assign
> > MG to a specific
> > > port, it should send ServiceChangeAddress specifying the
> > port.These two
> > > semantics seem clear and fair enough.
> >
> > I quite frankly don't understand the need for having port as
> > an identifier and
> > then being able to specify another port to override it, while
> > keeping the
> > identifier port the same.
> >
> >
> > >
> > >
> > > Port in MID should be just a tool to identify an entity
> > uniquely, with one
> > > requirement that MID for a control session is consistent
> between two
> > > entities.
> >
> > In that case it should be called something different than a
> > port, or at least be
> > treated as something different.
> >
> > -- Flemming
> >
> >
> > >
> > >
> > > - Bharat
> > >
> > > -----Original Message-----
> > > From: Flemming Andreasen [mailto:[email-masked]]
> > > Sent: Tuesday, September 05, 2000 8: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
> >
> > --
> > Flemming Andreasen
> > Cisco Systems
> >
>

---

From: Flemming Andreasen <[email-masked]>
Date: Wed, 6 Sep 2000 10:38:45 -0400

So do we have any consensus resolution on this issue ?

-- Flemming

--
Flemming Andreasen
Cisco Systems