[STDS-802-16] Fwd: FW: [STDS-802-16] Issues for the usage of the Secondary management connection
Title: Fwd: FW: [STDS-802-16] Issues for the usage of the
Seconda
-----Original Message-----
From: Eliaspur, Yigal
Sent: Tuesday, November 02, 2004 7:46 AM
To: STDS-802-16@listserv.ieee.org
Subject: RE: [STDS-802-16] Issues for the usage of the
Secondary managemen t connection
Dear Chulsik
Yoon,
Although a
new special transport CID for broadcasting seems a useful
solution as glance, it has lots of drawback associated with
it:
1.
Conversion Sublayer definition is per CID. Thus if not using DSX
then Conversion Sublayer type for the BC connection needs to be
defined in another specific/proprietary way.
2. This
mechanism will lock down the operator to use only one broadcasting
Conversion Sublayer for all MSS types. While with DSX more then one
CID can be allocated for broadcast data, one per CS
type.
3. If one
likes BC information to be encrypted as well, special/proprietary
mechanism to assign SAID for the static broadcast CID is
needed.
4. Sleep /
idle mode can be enhanced by splitting the BC transmission to groups
of a common wakeup interval.
With regards
to the drawback of using the DSX procedure:
1. Chulsik
Yoon wrote: "if we use the multicast transport connection
for the L3 signaling broadcast, then the DSA procedure to assign the
MSS to join the multicast connection shall be carried out before the
L3 signaling broadcast."
As for our
origin discussion, DSA signaling should be carried out anyhow
before theL3 unicast signaling, adding signaling for
another broadcast connection won't make much difference to the network
entry procedure (Multiple DSA transaction can be performed
simultaneously). As for HO time, this can be optimized by the standard
unicast/multicast CID switch mechanism without the overhead of the DSA
signaling.
2. Chulsik
Yoon wrote: "E. Yigals approach requires that the joining
process of the multicast connection for L3 signaling broadcast assumed
that the BS MAC layer already know the necessity of that multicast
connection (L2 involvement of L3 signaling, for example, by detecting
the IPv6 support capability)."
As I
mentioned above the DSX procedure will be triggered based on the MSS
Conversion Sublayer capability which is a plus. In the special CID
approach there is no way to define the appropriate Conversion
Sublayer(CS) of the connection and no way to match it to a specific CS
capability of the MSS.
Best
Regards,
-
Yigal
yigal.eliaspur@intel.com
Intel
Corp.
-----Original
Message-----
From: owner-stds-802-16@listserv.ieee.org
[mailto:owner-stds-802-16@listserv.ieee.org] On Behalf Of
csyoon@ETRI.RE.KR
Sent: Monday,
November 01, 2004 3:38 AM
Subject: Re:
[STDS-802-16] Issues for the usage of the Secondary managemen t
connection
In my
thought, Ronny's idea is a very useful one.
As
pointed out from E. Yigal, the proposed scheme of assigning a apecific
multicast/broadcast connection CID for L3 signaling broadcast traffic
need some special treatment.
But,
it is very useful and necessary for IPv6
application.
If we
should support IPv6, then the IP address auto-configuration function
requires a periodic broadcast of IPv6 Advertisement messages for IPv6
address allocation (such as ICMPv6 Router Advertisement and/or
Neighbor Advertisement), it is not appropriate for unicast
transmission. IPv4 Mobile IP is a different matter, so I am not going
to say about that. (It can be transferred to the unicast connection,
and even 3GPP people can take that approach.)
E.
Yigal and DJ said that it is possible and enough by assigning a
multicast connection for the L3 broadcast traffic. But it is not an
efficient way. Because, if we use the multicast transport connection
for the L3 signaling broadcast, then the DSA procedure to assign the
MSS to join the multicast connection shall be carried out before the
L3 signaling broadcast. It gives more delay to the network entry than
Ronny's concept for using the pre-define transport connection CID
for L3 signaling broadcast. And it is problematic for the handover
situation.
Ronny's approach is a good way to transparently
support the L3 signaling. E. Yigals approach requires that the joining
process of the multicast connection for L3 signaling broadcast assumed
that the BS MAC layer already know the necessity of that multicast
connection (L2 involvement of L3 signaling, for example, by detecting
the IPv6 support capability). But, following the Ronny's scheme the
L3 signaling broadcast is periodically broadcasted and the every
MSS's Layer 3 can detect that the IPv6 Advertisement messages for IP
Address Allocation not by involvement of the Layer 2 (MAC). So it is a
transparent way of support the L3 (or higher) layer
signaling.
So, I
think it will be the enhancement of the current specification for
future support to define the special transport CIDs for L3 (or higher)
layer signaling broadcast.
But,
not forcing to use it. Systems supporting the IPv6 will use
it.
Best
Regards,
Chulsik Yoon,
Senior Engineer, ETRI
From: Eliaspur, Yigal [mailto:yigal.eliaspur@intel.com]
Sent: Friday, October 29, 2004 5:36 PM
To: Ronny (Yong-Ho) Kim; yigall@runcom.co.il; Al Dabagh, Baraa;
???; Iyer, Prakash; STDS-802-16@listserv.ieee.org
Subject: RE: [STDS-802-16] Issues for the usage of the
Secondary management connection
Ronny,
Supporting
broadcasting over the data IP interface is possible by assigning
specific multicast connection CID for broadcast traffic (see
6.3.13 Establishment of multicast connections procedure)
This
mechanism allows you:
1. To specify specific parameters
to the broadcast connection: e.g. CS type, QoS parameters, SAID
etc.
2. To define more then one
broadcast "virtual groups"
3. To utilized the broadcast
concept in dot 16 layer.
Defining a
new constant management CID value for broadcasting requires special
treatments for bullet no. 1 above and has no support for bullet no. 2
above.
Regards,
-
Yigal
-----Original
Message-----
From: Ronny (Yong-Ho) Kim [mailto:ronnykim@lge.com]
Sent: Thursday, October 28, 2004 6:48 AM
To: yigall@runcom.co.il; Al Dabagh, Baraa; Eliaspur, Yigal;
'???'; Iyer, Prakash; 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.
1. 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).
2. 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:
1. "un-managed" mode
explicitly define the lack of secondary CID.
2. 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