| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
Hello Chulsik Yoon Please find my comments inline... Best regards - Yigal Yigal EliaspurIntel 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 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:
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).
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).
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. 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 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 |