| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
Dear All We are discussing managing IP
interfaces either for Data or for Management in mobile environment. For IP interfaces, somehow Layer
3 signaling from the network should be transferred to the MSS in order to
manage connection and we have discussed how it can be conveyed. We haven¡¯t
quite agreed which way is the best way. Here, I would like to raise
little different issue. If an MSS decides to use Mobile IP or IPv6 for Data or
Management, not only unicast layer 3 control signal but also broadcast control signal
from the network should be delivered to the MSS for IP interface management. However
there is only unicast way to deliver this layer 3 broadcast signal through
802.16 air interface. If the layer 3 broadcast signal is transferred through default
connection or secondary management connection, it will be a waste of resources.
Someone might say it is not necessary for a BS to deliver layer 3 broadcast control
signal to MSSs, however if the broadcast messages are not delivered, each and
every MSSs, which are supposed to receive broadcast layer 3 control messages
periodically, will generate unicast layer 3 signal, e.g, Agent Solicitation, or
Router Solicitation through default or secondary management connection and
unicast reply from the router or Agent to MSSs will be generated. This is even worse
waste of bandwidth. If we define
a new management CID to deliver broadcast layer 3 management signal to the
specific MSSs in a multicast way, then we can make IP interface management more
efficiently. This management CID is only for certain MSSs that use MIP or IPv6.
I would like to hear your
opinion on this. Thanks, Ronny From:
owner-stds-802-16@listserv.ieee.org
[mailto:owner-stds-802-16@listserv.ieee.org] Dear
Chulsik, Ronny, All, I
would like to summarize the different options raised in this email thread with
regards to Management Connection. Please
let me know your preferred option (of the below) so we can all know the
baseline that each one of us starts from. Also let me know if I missed some
options.
Implementation options: 1.1. MSS chooses ¡°un-managed¡± SS
capability mode, open default data connection using static DSA (with much all
classifier) to carry all default data traffic (including MIP/DHCP, TFTP, SNMP).
Implementation options: 2.1 MSS chooses ¡°managed¡± SS capability
mode, use the secondary CID to carry DHCP,TFTP,SNMP of the management IP
interface. Open a default data connection using static DSA (with much all
classifier) to carry all default data traffic of the data IP interface
(including MIP/DHCP, TFTP, SNMP). 2.2 MSS chooses ¡°managed¡± SS capability mode, use
the secondary CID to carry DHCP,TFTP,SNMP of the management IP interface and
MIP/DHCP,TFTP,SNMP of the data IP interface. Open a default data connection
using static DSA (with much all classifier) to carry all default data traffic
of the data IP interface (excluding MIP/DHCP, TFTP, SNMP). 2.3 Same as 2.1 but with MIP capability
on the Management connection IP IF. 2.4 Same as 2.2 but with MIP capability
on the Management connection IP IF. Currently
the standard supports only option 1.1 and 2.1 above. The
disadvantages I see for 2.2. 2.3 and 2,4 above are as follows: 2.2
– If both IF shared the secondary CID, then how can the Network/BS conclude
which of the IP allocation requests (MIP/DHCP) is for the data IF and which is
for management IF. As for my understanding this was the aim of the Secondary
CID connection. 2.3
– This solution can be applicable, however it requires the BS/Network to
allocate two sets of colocated/home IP addresses and to maintain two mobile IP
sessions in parallel, one for the Management connection and one for the Data
one. IMO, it raises unnecessary complexity and usage of system expensive
resources. In addition it can have high impact on the HO performance requiring
to maintain two separate MIP HO procedures. 2.4
– Sheared disadvantages of 2.2 and 2.3. Notes:
BR, -
Yigal Yigal Eliaspur
Intel Corp.
yigal.eliaspur@intel.com
-----Original
Message----- Dear Yigal and
Chulsik, Basically, I agree
with Chulsik on the SMC issue. I have comment and
question on Yigal¡¯s opinion, please refer to my
comments inline. B.R, Ronny LG Electronics,
Inc. From: owner-stds-802-16@listserv.ieee.org [mailto:owner-stds-802-16@listserv.ieee.org]
Hello Chulsik Yoon Please find my comments inline... Best regards - Yigal Yigal
Eliaspur
Intel
Corp.
yigal.eliaspur@intel.com
-----Original
Message----- 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. [E. Yigal] 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. 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). [Ronny] My question here is what kind of problem
is caused if Secondary management connection is used for MIP? You mentioned
replacing DHCP with MIP causes a lot of complexity but I disagree. Acquiring
management IP address using MIP is very similar to DHCP if we consider MSS
solicits Agent Discovery. If HO with MIP causes problem, DHCP causes same
problem. However, as you know, MIP provides better IP management scheme than
DHCP for mobiles. Of course 16g can provide scalable Mgmt solution
for mobile operation, but mobile management should be handled with IP address.
Therefore, we can just have simple solution by
using Secondary management connection for MIP and if there is any problem then
we can fix it in either 16e or 16g. 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. [E. Yigal] 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). [Ronny] I can not see the case when the network/BS
can allocate a co-located IP address based on the SS MAC address. The function
of default data CID looks pretty much like Secondary management connection to
me. Why do we need to define a new default transport CID instead of SMC? 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. [E. Yigal] This is a network/operator decision if
to provide the MSS data connectivity or not by allocating default data CID. [Ronny] If default data CID is given to the MSS by
a network/operator then it is required for MSS to manage this connection. 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. [E. Yigal] As I specified above the default data
CID can be agnostic to the IP layer an above addressing, in addition static DSx
operation is part of 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. [E. Yigal] As I specified above the Secondary
Management connection is not applicable for 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. [E. Yigal] There are cons and pros for shearing
or splitting IP based Management addressing with the data addressing. The
standard does not prevent you to share the two addressing and to use the data
only address. You can do that by choosing the ¡°un-managed mode¡± capability –
which means it¡¯s out of the standard scope to deal with/define it. 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 |