Thread Links | Date Links | ||||
---|---|---|---|---|---|
Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
Dear Chulsik,
I think our disagreement results from a very
fundamental fact. This fact is that I believe that the management function of
the mobile device can be done on top of the MAC rather than inside it. What this
means is that it is not necessary for the MAC to define DHCP or Mobile-IP or
TFTP download or any of these things. It is sufficient to define a management
interface (like a MIB), and then after the MSS is connected to the
network, open a management connection (which is a normal transport
connection from the MAC point of view, but used for management from the system
point of view) and manage the MSS to your heart's desire. This approach
simplifies things, since in the MAC level there is no special treatment to this
connection (not to mention that it does not need an IP stack now, HO is faster,
etc.).
I hope this clarifies what I said in the
meeting.
BR,
Yigal Sent: Friday, October 15, 2004 4:09 AM To: STDS-802-16@listserv.ieee.org Subject: [STDS-802-16] Issues for the usage of the Secondary management connection Hello Yigal, I would like to discuss the usage of the Secondary
Management Connection. In the current draft standard, the usage of the
secondary management connection is described like this (it is the result of the
last meeting in ¡°Finally, the Secondary Management Connection is used by
the BS and MSS to transfer delay tolerant, standards-based [Dynamic Host
Configuration Protocol (DHCP), Trivial File Transfer Protocol (TFTP), SNMP,
etc.] management messages.¡± -- The text having the meaning that Mobile IP messages
and router prefix advertisement are not transferred through the secondary
management connection. We have talked about the issues in the meeting, but we
have found out some differences in our understanding, and the problems in the
current specification. You said: But, these ideas have some
problems: 1)
You mean that the
protocol layer for the SS management (i.e., SNMP) is within the layer 2 (MAC) of
the SS, and the path to that is on the Secondary Management Connection. And the
user traffic (even in the case of DHCP or Mobile IP message for the IP address
allocation for the user traffic) cannot use the secondary management
connection. 2)
If we shall use
the default transport connection for the IP connectivity management for the user
traffic, then the DSA procedure should be proceeded before the allocation of the
¡°default transport CID¡± for the user. But, generally DSA procedure requires the
IP address for the transport connection, and even if it is not required, the
¡°default transport connection¡± allocation is not possible. If we use the
transport connection for the transfer of the Mobile IP and/or DHCP messages for
the IP connectivity for the user traffic, then the IP address related parameters
for the DSA procedure cannot be set. That means the parameters required should
already be known to the SSs and the BSs. The default parameters should be used.
3)
If we should use
the (default) Transport CID for IP connectivity management for the user traffic,
then every terminal shall maintain the Basic CID, Primary Management CID,
Secondary Management CID, and default Transport CID for signaling/control. That
means SS should have minimum 4 CIDs , but the specification say that the minimum
required CIDs each SS should have shall be not four but three. So, the usage of
default Transport CID violates the specification.
4)
If we use
Transport CID instead of Secondary Management CID for the IP connectivity
management for the user traffic, then the additional DSA-REQ/RSP procedures
should be included in the network entry process. The DSA (connection
establishment) procedure must be preceded for the transaction of the IP
connectivity management procedures (DHCP or Mobile IP), because we should use
the connection established before the transaction. But, if we use the Secondary
management CID for that transaction, then the connection establishment procedure
is not required. That means, the usage of the (default) Transport connection
have more signaling overhead and causes more delay during the network entry
process. 5)
In the fixed
environment, a subscriber station (SS) can be separated with equipment for the
user traffic (such as multiple TEs) and the equipment for the air interface
(such as MT), so that the Secondary management connection for the IP-based
external management for the SS is feasible. But, generally in the mobile
environment, the two equipment (TE and MT) should be integrated and used by only
one user, so the separation of the path for the user traffic IP connectivity
management (default transport CID) and for the external management for the
MSS (Secondary Management CID) is not a good approach. 6)
If we use the
Secondary management connection only for the IP-based management of the SS
externally, then the IP address for the SS management and the IP address for the
user traffic (you mean, using the default transport connection) should be
different. But, the IP address for the user traffic and the SS management can be
shared, and has no problem. So, the separate IP address allocation procedure is
duplicated and cause wasting up the IP address resources, especially in the case
of MSS. 7)
If we use the
transport connection for the user traffic IP connectivity management, then the
CID resources should be thrown away unnecessarily. If we can reuse the Secondary
management connection, then we can save the CID resources. 8)
If we should
proceed the handover process in the mobile environment over the subnets, then
the transport connection for the user traffic IP connectivity management should
be preceded before the transfer of the Mobile IP messages, that gives us a large
unwanted delay for the handover process, and the system performance shall be
greatly degraded. In summary, I would like to say my understanding and
concept, and the specification should be reflected to support
that: 1)
Secondary
management connection can be used as a user traffic IP connectivity management
(DHCP or Mobile IP). 2)
The IP address
allocated by the DHCP procedure using the Secondary management connection, can
be shared for the user traffic and the external management for the SS. So, there
is no need to separate the path to the SS management and the user traffic by
secondary management connection and the transport connection.
3)
Mobile IP should
be supported for the seamless HO across the subnets, and for the swift handover
process, the Secondary management connection should also be used for the Mobile
IP message transfer and the external management for the MSS for the managed
MSS. Best Regards, Chulsik Yoon Senior Engineer, ETRI |