Re: [STDS-802-16] Resolution of comment 332
OK. Then, as it stands today, BS decides to forward those SDUs to SM
connection.
Mechanism of such decisions is [currently] out of the standard's scope.
Note that the whole discussion is about REVd [fixed standard]. For mobile
we probably shall address issues of this type in another document.
Vladimir
-----Original Message-----
From: Iyer, Prakash [mailto:prakash.iyer@intel.com]
Sent: Monday, May 03, 2004 7:29 PM
To: Vladimir Yanover; STDS-802-16@listserv.ieee.org
Subject: RE: [STDS-802-16] Resolution of comment 332
The SS/MSS will be the destination for these messages. For example MIP
agent advertisements precede any control plane exchanges between an MSS
and a home agent (such as a registration / binding update). RFC 3344
gives more details on how router advertisements are used for unsolicited
foreign agent advertisements and ICMP router discovery messages are used
to solicit a response from a FA. With IPv6, you are unlikely to see DHCP
used. An SS/MSS will obtain an IP address based on a prefix advertised
by a router - which may include a normal routable prefix or special
routable prefixes such as 6To4. Bottom line is that many of these IP
datagrams have to be delivered prior to the MSS initiating control plane
traffic to the network.
-Prakash
-----Original Message-----
From: owner-stds-802-16@listserv.ieee.org
[mailto:owner-stds-802-16@listserv.ieee.org] On Behalf Of Vladimir
Yanover
Sent: Monday, May 03, 2004 9:03 AM
To: STDS-802-16@listserv.ieee.org
Subject: Re: [STDS-802-16] Resolution of comment 332
Prakash,
What are supposed destinations for types of traffic you mentioned?
For example, do you want ICMP routing related updates to be received by
IP hosts / routers behind the SS? If yes, they will be delivered over
regular data connection [not over SM connection].
Vladimir
-----Original Message-----
From: Iyer, Prakash [mailto:prakash.iyer@INTEL.COM]
Sent: Monday, May 03, 2004 1:51 PM
To: STDS-802-16@listserv.ieee.org
Subject: Re: [STDS-802-16] Resolution of comment 332
BTW, the .16e draft does not clearly specify how control plane
'broadcasted' IP packets are to be handled. For example, how will MIP
agent advertisements or IPv6 prefix advertisements be handled -
delivered on the secondary management CID or broadcast CID or something
else. ICMP routing related updates are another example. Many of these
affect timing especially in the context of handovers and the ability for
an MSS to transmit/receive data immediately after a handover or in
steady state. If this is described somewhere, can someone send me a
pointer. If not, it needs to be addressed via comments.
-Prakash
-----Original Message-----
From: owner-stds-802-16@LISTSERV.IEEE.ORG
[mailto:owner-stds-802-16@LISTSERV.IEEE.ORG] On Behalf Of Jeff Mandin
Sent: Monday, May 03, 2004 4:26 AM
To: STDS-802-16@LISTSERV.IEEE.ORG
Subject: Re: [STDS-802-16] Resolution of comment 332
> My understanding of Secondary Management connection role is to carry
>traffic from / to the SS itself.
>particularly, this traffic does not pass CS SAP, but rather goes from /
>to Management Entities [Fig. 1]
>
>Vladimir
>
>
>
That's really the crux of the issue! IP is an "internetwork protocol",
and includes the notion of an "IP interface", which is inevitably
associated with a MAC SAP.
So SNMP etc. traffic should really be viewed as application traffic (ie.
which passes the CS SAP).
Indeed, many people's conception is that the management traffic
originates at an NMS external to the BS which is then bridged or routed.
If so, then the traffic certainly passes the CS SAP. For external
traffic to not pass the CS SAP, we would require a management proxy
entity.
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.
************************************************************************
****
********
This mail was sent via 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.
************************************************************************
************
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.
****************************************************************************
********
This mail was sent via 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.
************************************************************************************