| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
Dear Chulsik,
Your desire to manage the MSS over the secondary
management connection, as well as my desire to manage it on top of the MAC could
be accommodated together. I don't see any problem with allowing both ways, an
enabling the MSS to declare which way it prefers.
Best Regards,
Yigal Sent: Monday, October 18, 2004 5:09 AM To: yigall@runcom.co.il; yigal.eliaspur@intel.com; STDS-802-16@listserv.ieee.org Cc: ???; ??? Subject: RE: [STDS-802-16] Issues for the usage of the Secondary management connection Dear Yigal Leiba, Yigal Eliaspur, and
All. I think Yigal at Runcom and Yigal at Intel
have different concept of using the Secondary management
connection. In my understanding of your comments, you
mean that ¡°the management function of the mobile device (regardless of what
management function such as DHCP, Mobile IP, or TFTP download) can be done on
top of the MAC rather than inside it.¡± But, the current (draft) standard and the
result of the comment resolution of the last meeting (Comment #580, #581) say
that ¡°Finally, the Secondary Management Connection is may be
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.
These management messages are terminated at the MSS.¡± -- That means the management function of
the mobile device (explicitly for DHCP, TFTP, SNMP) is inside the MAC layer
using the Secondary management connection. -- The result of the comment resolution
means that deleting the text for usage of the secondary management connection
includes the Mobile IP or Router Prefix
Advertisement. Therefore, the result of the last meeting¡¯s
comment resolution (#581) have the meaning of Yigal Eliaspur¡¯s
words: ¡°The current specification (16e/d) provides management
mechanism that was mostly inherited from DOCSIS specification, and was design
for fix SS (RG like) operation. This management framework requires 2 separate IP
IF, one for Data traffic and one for Management traffic. The Management IP-IF is
consider part of the 16 MAC and as a result the standard includes explicit
reference to its layer 3 and above protocols (DHCP,IP,TFTP,SNMP). E.g : IP
connectivity and TFTP stage in the network entry, the definition of the
Secondary Mgmt connection, etc.¡± But I do not agree with both of you because
if we use a transport connection for the data traffic IP management, then the BS
and the MSS will not know what transport connection ID they should use.
Since there is no procedure for allocating
the default Transport CID before they transfer the DHCP or Mobile IP messages
to/from the BS. E. Yigal says ¡°If the
network/BS cannot allocate in advance (before operational stage) a co-located IP
address based on the SS MAC address, the network/BS shell open a default data
CID with a classifiers that is agnostic to a specific IP address (e.g. much all
classifier). Once it has knowledge of the IP address and other higher level
information (like ports) the system, based on needs, can triggered dynamic DSx
with the appropriate information (note that more then one CPE IP address is
possible in RG like environments).¡± But it is not the matter of classifier to
classify the unknown IP address mapping, but the matter of connection identifier
to identify which connection they (both the BS and the MSS) use to transport the
data traffic IP management messages (DHCP, or Mobile IP). There is no step (no
management message and parameter of it) to allocate the default connection CID,
the BS and the MSS should not know on what connection CID their DHCP or Mobile
IP messages be transmitted. That means, it is impossible to transmit the data
traffic IP management messages using the transport connection.
Please let me know what procedure they can
transmit MSS-to-BS and BS-to-MSS DHCP (or Mobile IP) messages using the
transport connection. And, I would like to know that without IP
address for the data traffic, how can it carry out the DSA procedure? We should
set lots of IP address related parameters for the transport connection using the
DSA procedure. In my understanding, the secondary
management connection is used to transmit the IP management messages (M)SS
to/from BS, then they can be allocated the IP address for the data traffic, and
then they can carry out the DSA procedure using the IP address and the QoS
related parameters. If I accept the E. Yigal¡¯s concept, there
should be the step of default transport connection CID allocation provided
during the network entry procedure, and handover
procedure. Anyway, the current specification should be
modified appropriately. I also do not agree with E. Yigal¡¯s
following comment: ¡°An experiment to enhance the Mgmt IP-IF to Mobile
operation by replacing DHCP with MIP was a failure as for the amount of
complexity it brought. The aim of 16g is to define applicable and scale Mgmt
solution for mobile operation, and this might be done using MAC layer Mgmt
singling (not IP/SNMP based).¡± We (ETRI) have successfully implement the
Mobile IP operation using the Secondary management connection without any
complexity problem. I would like to know the details of what¡¯s
your experiment and what¡¯s the problem for not supporting the Mobile IP on the
secondary management connection. And I think that it is not for the matter
of management layer signaling, but it is the matter of MAC
layer. Therefore, I insist that the original text
in the P802.16e/D4 or the comment from the Bob Nelson (Comment #580) says more
appropriate: ¡°Replace
(P802.16e/D4 text) Finally, the Secondary Management
Connection is used by the BS and MSS to transfer delay tolerant, standards-based
[Dynamic Host Configuration Protocol (DHCP), router prefix advertisements,
Mobile IP, Trivial File Transfer Protocol (TFTP), SNMP,
etc.] management messages. These management messages are terminated at the
MSS. with (base text taken from REVd
) Finally, the Secondary Management
Connection is used by the BS and SS to transfer delay tolerant,
standards-based [Dynamic Host Configuration Protocol (DHCP), Trivial File
Transfer Protocol (TFTP), SNMP, etc.] messages. For BS/MSS connections, router
prefix advertisements and Mobile IP management messages may also be carried.
Messages carried on the Secondary Management Connection are terminated at the SS
or MSS.¡± I think that the original text in the
P802.16e/D4 or the comment from the Bob Nelson (Comment #580) says more
appropriate: Best Regards, Chulsik Yoon, Senior Engineer,
ETRI From:
owner-stds-802-16@listserv.ieee.org [mailto:owner-stds-802-16@listserv.ieee.org]
On Behalf Of Yigal
leiba 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 From:
owner-stds-802-16@listserv.ieee.org [mailto:owner-stds-802-16@listserv.ieee.org]
On Behalf Of ??? 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 |