| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
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 |