| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
This has come up before. I don't think changes the to
spec are required.
This is based on the basic notion that the job of the CS is
to map between the MAC CS service and the MAC CPS service.
In case of the Packet CS, then all options (802[1q/3]
& IP) have broadcast and unicast addressing for data. The MAC_CPS
service does not. It only has multicast groups for transport data. Therefore it
is the job of the CS to map 802 or IP broadcast data onto multicast groups set
aside for the purpose when appropriate. Having the CS attempt to identify IP
management traffic and route it onto the SMC seems like a recipe for problems.
It would bypasses the QoS commitements to the data transport and the packet
classification task would change over time as above-the-LLC-802-protocols and IP
protocols changed.
So the logical thing for an 802 or IP CS to do at the BS
end is to create a conventional multicast group for broadcast traffic. All
attached SSs join the multicast group and it is through this that they
receive broadcast L3 traffic.
Uplink L3 broadcast traffic is not a problem, it is carried
unicast at L2 to the BS and L3 is responsible for rebroadcasting (just as in
802.11).
It would be equaly valid for a CS to unicast L3 broadcast
packets to all SSs, and just like DSL, this is going to be the expected
mechansism where users are not necessarily sharing the same network, but instead
being piped through to an external ISP.
The only issue is whether or not we need anything in the
spec to make this interoperable. I don't think so right now (I used to think
otherwise). Nothing special needs to be done in the SS, so the BS L3 broadcast
behaviour is an implementation option. An SS should be prepared to receive L3 or
802 broadcast traffic on either unicast or multicast connections. Either could
happen, depending on the nature of the service.
I don't see any need to make L2 aware of L3 management
traffic. The necessary delivery behaviour for L3 traffic can be determined by
the L3 address , or 802 address if that we we have.
The SMC is an orthogonal problem. It is to carry the
traffic of a parallel IP network, oriented to managing the SS. The behaviour,
encapsulation, packet delivery and pretty much any other aspect of what goes on
over the SMC is undefined at this time. I have my opinions about how we should
standardize it, but I'll save it for 802.16g.
DJ
From: owner-stds-802-16@LISTSERV.IEEE.ORG [mailto:owner-stds-802-16@LISTSERV.IEEE.ORG] On Behalf Of Ronny (Yong-Ho) Kim Sent: Wednesday, October 27, 2004 9:48 PM 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]
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 |