Subject: Addressing For Control

From: Tom-PT Taylor <[email-masked]>
Date: Fri, 1 Sep 2000 14:01:19 -0500

I would like to summarize a number of points around control session
addressing which have come up over the last few months, just to see that
this is how everyone sees the situation.  I am particularly concerned to
make sure I have expressed the correct view of the role of the MId in the
message header, since if I am correct, it would have made more sense to
define it as an arbitrary octet string.

In what follows, question marks denote items which aren't clearly stated in
or obvious inferences from the protocol document.

General
=======

1. All responses go back to the source of the request.  In IP terms, this
means that the response is sent back to the source IP address drawn from the
IP header of the request, and the port drawn from the UDP/TCP/SCTP header of
the request.  For ATM transport presumably the VC over which the request was
received is the VC over which the response is sent.

2. (?) The role of the MId in the message header is to provide
application-level identification of the sender of the message.  In any given
control session, the MId used by a given end will stay the same, even if the
transport connection changes.  MIds for different virtual MGs will differ,
even if they reside at the same IP address.  In fact, virtual MGs may even
share the same port (with demultiplexing being done on the MId).

MG-Originated ServiceChange
===========================

3. The MG chooses where to send its initial ServiceChange according to the
following rules:

   (a) The address given in a ServiceChangeMGCId from an MGC takes
precedence over any provisioned address until the MG determines that there
is no response from the MGC-provided address.

   (b) If either the provisioned address being tried or the address supplied
in a ServiceChangeMGCId lacks a port number, the MG will use the default
port number (2944 for text or 2945 for binary).

4. If the MG issues a ServiceChange on ROOT, the ServiceChangeAddress MAY be
present in the request.  If so, it provides the address to which the MGC is
meant to send all requests that it issues within the current control
session.  Where TCP is in use, this means the following sequence will occur:

   (a) MG sends ServiceChange from TCP addr:port A, containing
ServiceChangeAddress equal to addr:port B (understood to be TCP because the
original contact was via TCP).

   (b) MGC sends its response on the TCP connection to addr:port A.

   (c) MGC opens up a TCP connection to addr:port B and sends all subsequent
requests through that connection.  The MG returns its responses to the MGC's
requests through the same connection.

   (d) Assuming the MGC did not provide an alternative address in the
ServiceChange response, the MG (at its option) MAY continue to use the
original connection from addr:port A for its Notify and ServiceChange
requests.

This is all hypothetical: it seems more likely in practice that the MG will
not send a ServiceChangeAddress in the first place (particularly since it
complicates security arrangements).

5. (?) Where the MG has NOT provided a ServiceChangeAddress, the MGC will
direct its requests to the address:port from which the MG sent its
ServiceChange request.

6. In a ServiceChange response, the MGC may provide a ServiceChangeAddress,
a ServiceChangeMGCId, or neither.

   (a) If it provides a ServiceChangeAddress, the MG is required to send all
subsequent requests to the given address.  The MId in subsequent messages
from the MGC MUST remain unchanged from the value given in the response to
the initial ServiceChange.

   (b) If the MGC provides a ServiceChangeMGCId, it is rejecting the
registration of the MG.  The MG MUST take down any transport connection it
established to the MGC, then try to establish a new session to the address
specified by the ServiceChangeMGCId.

   (c) (?) If the MGC supplied neither a ServiceChangeAddress nor a
ServiceChangeMGCId, the MG MUST send all subsequent requests to the same
addr:port at the MGC to which it sent the initial ServiceChange request.

7. If the MGC is unable to accept a registration request, it has the
following alternatives:

   (a) reject the attempt to connect at the transport level (if
connection-oriented transport such as TCP or SCTP is used), or ignore the
incoming message (if connectionless transport is used)

   (b) reject the ServiceChange request at the application level by
supplying a reply with an error descriptor against the command (e.g. with
error code 502 Not Ready or 510 Insufficient Resources)

   (c) redirect the MG using ServiceChangeMGCId in the response.

The MGC SHOULD use either (b) or (c).

MGC-Originated ServiceChange Request
====================================

8. The MGC may originate a ServiceChange request containing
ServiceChangeMGCId.  This requires the MG to take the following actions:

   (a) respond to the ServiceChange request and to any other outstanding
commands at the addresses from which they were sent

   (b) attempt to establish a new control session at the address indicated
in ServiceChangeMGCId.

Outstanding requests from the MG to the old MGC are discussed in a separate
note.

9. The MGC may originate a ServiceChange request containing
ServiceChangeAddress.  This requires the MG to take the following actions:

    (a) as above

    (b) send all subsequent requests to the indicated ServiceChangeAddress

    (c) if retransmitting outstanding requests to the MGC, use the same
address that the original request went to.

It seems reasonable to require that in this case the ServiceChangeMethod (if
any) should be restricted to GRACEFUL or FORCED.

10. (?) The MGC MAY (pathological case?) issue a ServiceChange request
containing neither ServiceChangeAddress nor ServiceChangeMGCId.  Assuming
the ServiceChangeMethod does not indicate that the MG should not find
another MGC, it seems reasonable in this case to follow these rules:

    (a) as above

    (b) send all subsequent requests to the address from which the
ServiceChange request was issued.

    (c) if retransmitting outstanding requests to the MGC, use the same
address that the original request went to.

Speaking of pathological cases, ServiceChangeMethod does not seem to be a
required field in our syntax.

Comments?

Tom Taylor

---

From: Naren Tulpule <[email-masked]>
Date: Fri, 1 Sep 2000 12:21:10 -0700

Hi Tom, list,
  please see comments below.
-----Original Message-----
From: Tom-PT Taylor [mailto:[email-masked]]

[NAREN] Virtual MGs cannot share the same (IP address+port) combination for
RECEIVING messages from an MGC which is controlling two or more virtual MGs
in the physical MG. The MId in the message will be that of the MGC, and not
useful for demultiplexing. And since responses from MGC are sent back to the
source port, the MGs cannot share a port for SENDING commands either.

---

From: Tom-PT Taylor <[email-masked]>
Date: Fri, 1 Sep 2000 15:02:32 -0500

You're right.  I knew that statement was risky.

> From: Naren Tulpule [mailto:[email-masked]]
> Sent: Friday, September 01, 2000 3:21 PM
> To: Taylor, Tom-PT [NORSE:B901:EXCH];
> [email-masked]
> Subject: RE: Addressing For Control
>
>
> Hi Tom, list,

---

From: Bharat Kaul <[email-masked]>
Date: Fri, 1 Sep 2000 16:19:42 -0700

Hi Tom,

  My comments are below

-----Original Message-----
From: Tom-PT Taylor [mailto:[email-masked]]
Sent: Friday, September 01, 2000 12:01 PM
To: [email-masked]
Subject: Addressing For Control

[[ BHARAT ]]

We should have a simple statement which says MID is unique for a control
session for a megaco component. This should cover MGCs, MGs and virtual MGs.

[[[[ BHARAT  ]]]]]]

I don't think (c) should be an option. First because of security
arrangements, secondly because MGs already have a capability of initiating
connections and let them keep on
doing so. This need not be part of MGCs. Also, I can't see why MG would want
to specify
a ServiceChange Address for TCP. It might as well initiate the connection
using that source transport address where it wants to communicate. I am
inclined towards not having (c) as an option for TCP.(c) however is a valid
option for UDP.

[[[[ BHARAT ]]]]]

I hope you mean ServiceChangeAddress OR ServiceChangeMGCID not both.

    (a) as above

[[[[[ BHARAT ]]]]]]

I am not sure I understand what MGC is trying to tell MG while using these
methods. Specifying ServiceChangeAddress after things are up and running
(i.e. registration has
completed long back) might be tricky with TCP as transport. It would be
interesting to see what people have to say on this. Till now, I thought only
"handoff" is the allowed method from MGC to MG.

- Bharat

---

From: Mukesh Goel <[email-masked]>
Date: Tue, 5 Sep 2000 10:23:21 -0700

Hi Tom, List,

Please find my comments below.

Regards,
Mukesh Goel

>Sent: Monday, September 04, 2000 5:52 PM
>To: [email-masked]
>Subject: Re: Addressing For Control
>[PTT] (a), (b), and (c) are not alternatives -- they must all
>happen IF the
>MG sends a ServiceChangeAddress on a TCP connection.  If one
>doesn't want to
>support that sort of behaviour then one's MG should be designed not to
>initiate it.  I suppose that as a stack provider you may find
>yourself in an
>awkward position on this, but you'll have to work it out with your
>customers.

[MUKESH]
The MGC initiated TCP connection issue has been discussed on the list
quite a few times and always the conclusion was that MG does not maintain
TCP servers (only MGC does), so the responsibility to initiate a connection
setup is of MG.

Are we allowing MGC to setup a TCP connection towards MG?

I think we need to come up with explanation of what is our stand w.r.t
TCP as a transport. A "text" regarding this in an implementation guide would
help.

---

From: Tom-PT Taylor <[email-masked]>
Date: Tue, 5 Sep 2000 14:26:47 -0400

Comments below.

> From: Shalini Philip [mailto:[email-masked]]
> Sent: Tuesday, September 05, 2000 4:08 AM
> Hello Tom, list,
>     Please find my comments to point 9 below.
>
> >
> > [PTT] I invite further comments.
> >
>
> In case of TCP and UDP, if after successful registration, the
> MGC wants to
> change the port on which
> communication happens with MG, it can always send a Service
> Change command
> Request with service
> change method as "Handoff" and a ServiceChangeMgcId as the
> new MgcId (with the
> new port information).

[PTT] I think we should agree that providing a ServiceChangeMgcId forces the
MG to initiate a new control session.  If the MGC just wants to change
addresses, it should provide ServiceChangeAddress instead.

>
> Another point that I would like to make is that even FORCED
> or GRACEFUL on ROOT
> can be possible service change methods from MGC -> MG,
> in case there is no backup MGCId to which handoff can happen.
> In such a
> situation, the MG should try registration with any
> other MGC in its provisioned list of primary and secondary MGCs.
>
[PTT] Agreed.
>
> --
> Regards,
>
> Shalini Philip
> Globespan Inc.
> E-Mail : mailto:[email-masked]
> Web    : http://www.globespan.net
>

---

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

We have agreed that MGC-initiated control sessions are not part of H.248v1.
I am pointing out that this does not prevent the MG from requesting the MGC
to set up a TCP connection to the MG.  It does not particularly make sense
for the MG to do so, but it is a possibility within the existing procedures.

> From: Mukesh Goel [mailto:[email-masked]]
> Sent: Tuesday, September 05, 2000 1:23 PM