-----Original
Message-----
From: Ronny (Yong-Ho) Kim
[mailto:ronnykim@LGE.COM]
Sent: Thursday, October 28, 2004 6:48 AM
To: STDS-802-16@listserv.ieee.org
Subject: Re: [STDS-802-16] Issues
for the usage of the Secondary management connection
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]
Sent: Monday, October 18, 2004 5:52 PM
To: STDS-802-16@listserv.ieee.org
Subject: Re: [STDS-802-16] Issues
for the usage of the Secondary management connection
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.
- MSS uses only one
IP interface (both for data and management). Layer 3 and above protocols
of this interface are used also for MSS manageability.
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).
- MSS uses two IP
interfaces, one for Data and one for Management. MSS has duplicated layer
3 services (for each interface).
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:
- “un-managed”
mode explicitly define the lack of secondary CID.
- DSX transaction can
create default CID between the BS and the MSS without a need for neither
IP/Layer3 information nor connectivity.
BR,
- Yigal
Yigal Eliaspur
Intel Corp.
yigal.eliaspur@intel.com
-----Original Message-----
From: Ronny (Yong-Ho) Kim
[mailto:ronnykim@lge.com]
Sent: Sunday, October 17, 2004 9:32 AM
To: Eliaspur,
Yigal; STDS-802-16@listserv.ieee.org
Subject: RE: [STDS-802-16] Issues
for the usage of the Secondary management connection
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]
Sent: Saturday, October 16, 2004 6:00 PM
To: STDS-802-16@listserv.ieee.org
Subject: Re: [STDS-802-16] Issues
for the usage of the Secondary management connection
Hello Chulsik Yoon
Please find my comments
inline...
Best regards
- Yigal
Yigal Eliaspur
Intel Corp.
yigal.eliaspur@intel.com
-----Original Message-----
From: csyoon@etri.re.kr
[mailto:csyoon@etri.re.kr]
Sent: Friday, October 15, 2004 4:09 AM
To: Eliaspur,
Yigal
Cc: STDS-802-16@listserv.ieee.org
Subject: 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 Seoul, comment #580):
“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:
The Secondary Management Connection can be used only for the management purposes,
not for a user traffic transport, such as the SNMP messages for the SS. The IP
address allocated by using the DHCP is used only for the management for the SS,
not for the user traffic. The IP address for the user service can be allocated
using the “default” Transport Connection. And the parameters for
default Transport Connection is pre-assigned in each Base Station (BS).
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.
In that case the protocol layers for the IP and above should be duplicated in
the user plane and the management plane. But, the SNMP for the SS management
and the Mobile IP for the IP connectivity management for user traffic can be
discriminated in the IP layer by the “protocol” field. So, the two
protocols can be well harmonized using the secondary management connection.
And, it is not required to implement the duplicated protocol layers for the
management plane and the user plane. The SNMP and the Mobile IP can be
distinguished as a different application on the same IP layer. It is the better
approach.
[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.
Because, the procedure is not described in anywhere in the specification, the
BS cannot provide the allocated “default transport CID” to the
user. In what management message? Using what parameter?
[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.
Therefore, even in the case of the Secondary management connection is used for
the external management for the MSS, the Secondary management connection should
also be used as the transfer of the user traffic IP connectivity management and
management (Mobile IP or DHCP).
-- We need to define the concept of MSS clearly. I think that the Mobile Router
(One modem and multiple user equipment in mobile situation) concept is not appropriate
for the current 16e specification.
[E. Yigal] As I specified
above the Secondary Management connection is not applicable for Mobile operation.
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.
[E. Yigal]
Agree, see above – this is why we are looking for another solution for
mobility (e.g. MAC mgmt based) in 16g
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
This mail passed through mail.alvarion.com
************************************************************************************
This footnote confirms that this email message has been scanned by
PineApp Mail-SeCure for the presence of malicious code, vandals & computer
viruses.
************************************************************************************