Subject: [Seamoby] CARD feeding TAR selection issue

From: [email-masked]
Date: Sun, 5 Jan 2003 17:45:52 -0500

Hi all:

In order to proceed with next version of CARD draft, the design team would like to seek WG consensus on the following way of CARD operation, so that it can be used for TAR selection.

TAR selection is defined as selecting a unique AR for handoff from a set of CARs. For this, TAR selection module needs access to CAR identities and their capabilities. TAR selection module resides in the MN.

Base protocol:
--------------

Step 1: MN collects the identities of CARs (after listening to AP beacons from them) and their capabilities using CARD protocol. For this, MN queries either current AR or new AR (depending upon whether is it doing CARD in MN orchestrated or network assisted mode) and receives this information. For a given CAR, its entire capability set is provided to MN.

Step 2: MN runs TAR selection algorithm to choose TAR at the time of handoff.

Optional optimizations to the base protocol:
--------------------------------------------

Capability pre-filtering:

Step 1A: To avoid sending whole capability set of any CAR to MN, especially if MN is not interested in all those capabilities, in the CARD query MN can specify the capabilities that it is interested in receiving (by specifying capability attributes).

Step 1B: Even when capabilities of interest are specified by MN in query, to avoid sending information on CARs that MN is not obviously going to like, MN can also specify in the query to send CAR information if the capability of interest is above a threshold (attribute being greater than some value).

Network policies:

Network policies (in network assisted CARD) can be implemented indirectly by current AR. In other words, current AR may not send information about certain CARs to MN, if network policy in unfavorable to those CARs. In an extreme case, if network sends to MN information about only one CAR, it is tantamount to performing TAR selection on current AR.

Please provide your feedback on this. 

Thanks,

Hemant
_______________________________________________
Seamoby mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/seamoby

---

From: "Hemant Chaskar" <[email-masked]>
Date: Mon, 06 Jan 2003 03:25:01 +0000

Hi Xiaoming:

If MN can query new AR directly, the question of network policy does not 
come into picture at all, I guess! If MN can directly communicate with new 
AR, why should it care if current AR favors it going there or not.

Hemant

>From: "Xiaoming Wang" <[email-masked]>
>To: <[email-masked]>, <[email-masked]>
>Subject: Re: [Seamoby] CARD feeding TAR selection issue
>Date: Mon, 6 Jan 2003 09:13:53 +0900
>
> > Network policies:
> >
> > Network policies (in network assisted CARD) can be implemented 
>indirectly
>by current AR. In other words, current AR may not send information about
>certain CARs to MN, if network policy in unfavorable to those CARs. In an
>extreme case, if network sends to MN information about only one CAR, it is
>tantamount to performing TAR selection on current AR.
> >
>
>This optimization doesn't work when MN queries new ARs directly. Therefore
>these policies should not be depended on by current AR in order to filter
>unfavorable CARs.
>
>

_________________________________________________________________
MSN 8 with e-mail virus protection service: 2 months FREE* 
http://join.msn.com/?page=features/virus

---

From: "Hemant Chaskar" <[email-masked]>
Date: Mon, 06 Jan 2003 03:25:01 +0000

Hi Xiaoming:

Hemant

---

From: [email-masked]
Date: Mon, 6 Jan 2003 09:53:21 -0500

Hi Pat,
In the case that you illustrate, the current AR has to be involved.The MN forwards the 
L2 Id to the current AR. The current AR, then,  maps the beacon 
information to the IP address of the associated AR and forwards the capabilities of the AR to the MN. 

Also, I don't think we should prevent TAR selection at the AR altogether now. I don't think allowing it makes CARD any more complicated. CARD should be allowed to push its output to the TAR module
irrespective of where it resides. For some cases such as load balancing, that is presented in the 
issues draft, this mode of operation may be quite useful.

Regards,
Govind. 

-----Original Message-----
From: ext Pat Calhoun [mailto:[email-masked]]
Sent: Sunday, January 05, 2003 8:36 AM
To: Chaskar Hemant (NRC/Boston)
Cc: [email-masked]
Subject: Re: [Seamoby] CARD feeding TAR selection issue

> Step 1: MN collects the identities of CARs (after listening to AP beacons from them) and their capabilities using CARD protocol. For this, MN queries either current AR or new AR (depending upon whe…

There are link layers that do not allow more than one link layer
connection at any given time, and although the beacons could be
received, as they are on a special channel. In these conditions, how
would the mobile receive CARD packets?

PatC

---

From: [email-masked]
Date: Mon, 6 Jan 2003 10:52:56 -0500

Hi Pat:

One possible application scenario for MN-Orchestrated CARD is for MN having multiple NICs (say cellular and WLAN). In this case, with active cellular connection, it would be possible to collect CARD packets over WLAN interface.

However, if more than one link layer connection is not allowed (either because both current and new AR use the same radio technology or because MN front end radio is software programmable) then MN needs to take help of current AR, i.e., it has to perform network-assisted CARD.

Regards,
Hemant

-----Original Message-----
From: ext Pat Calhoun [mailto:[email-masked]]
Sent: Sunday, January 05, 2003 8:36 AM
To: Chaskar Hemant (NRC/Boston)
Cc: [email-masked]
Subject: Re: [Seamoby] CARD feeding TAR selection issue

PatC

---

From: "Shaheen, Kamel M." <[email-masked]>
Date: Mon, 6 Jan 2003 12:11:00 -0500

Hi Pat and Hemant,

I have a question regarding the way the MIP would apply to the case of MN
with multiple NICs of different technologies.  To be more specific, if the
MN has two NICs one is UMTS and the other is WLAN.  If the MN has a session
running on top of WLAN and would like to continue this session on the UMTS
side.  How MIP will be triggered in this case?

Best Regards,

Kamel

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Mon, January 06, 2003 10:53 AM
To: [email-masked]
Cc: [email-masked]
Subject: RE: [Seamoby] CARD feeding TAR selection issue

Hi Pat:

One possible application scenario for MN-Orchestrated CARD is for MN having
multiple NICs (say cellular and WLAN). In this case, with active cellular
connection, it would be possible to collect CARD packets over WLAN
interface.

However, if more than one link layer connection is not allowed (either
because both current and new AR use the same radio technology or because MN
front end radio is software programmable) then MN needs to take help of
current AR, i.e., it has to perform network-assisted CARD.

Regards,
Hemant

-----Original Message-----
From: ext Pat Calhoun [mailto:[email-masked]]
Sent: Sunday, January 05, 2003 8:36 AM
To: Chaskar Hemant (NRC/Boston)
Cc: [email-masked]
Subject: Re: [Seamoby] CARD feeding TAR selection issue

> Step 1: MN collects the identities of CARs (after listening to AP beacons
from them) and their capabilities using CARD protocol. For this, MN queries
either current AR or new AR (depending upon whether is it doing CARD in MN
orchestrated or network assisted mode) and receives this information. For a
given CAR, its entire capability set is provided to MN.

PatC

---

From: "Shaheen, Kamel M." <[email-masked]>
Date: Mon, 6 Jan 2003 12:11:00 -0500

Hi Pat and Hemant,

Best Regards,

Kamel

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Mon, January 06, 2003 10:53 AM
To: [email-masked]
Cc: [email-masked]
Subject: RE: [Seamoby] CARD feeding TAR selection issue

Hi Pat:

Regards,
Hemant

-----Original Message-----
From: ext Pat Calhoun [mailto:[email-masked]]
Sent: Sunday, January 05, 2003 8:36 AM
To: Chaskar Hemant (NRC/Boston)
Cc: [email-masked]
Subject: Re: [Seamoby] CARD feeding TAR selection issue

PatC

---

From: [email-masked]
Date: Mon, 6 Jan 2003 12:22:40 -0500

Hi Kamel:

One can think of number of scenarios. For cellular to WLAN handoff, if MN can simultaneously maintain two IP-level connections, I think MIP can be used in most basic form (without fast HO/CT etc.). In the reverse direction, due to time constraint (WLAN coverage disappearing as you move out of hot-spot) as well as to save cellular bandwidth, it may be efficient to use fast HO and CT signaling along with mobile IP.  

Hemant
-----Original Message-----
From: ext Shaheen, Kamel M. [mailto:[email-masked]]
Sent: Monday, January 06, 2003 12:11 PM
To: Chaskar Hemant (NRC/Boston); [email-masked]
Cc: [email-masked]
Subject: RE: [Seamoby] CARD feeding TAR selection issue

Hi Pat and Hemant,

Best Regards,

Kamel

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Mon, January 06, 2003 10:53 AM
To: [email-masked]
Cc: [email-masked]
Subject: RE: [Seamoby] CARD feeding TAR selection issue

Hi Pat:

Regards,
Hemant

-----Original Message-----
From: ext Pat Calhoun [mailto:[email-masked]]
Sent: Sunday, January 05, 2003 8:36 AM
To: Chaskar Hemant (NRC/Boston)
Cc: [email-masked]
Subject: Re: [Seamoby] CARD feeding TAR selection issue

PatC

---

From: [email-masked]
Date: Mon, 6 Jan 2003 12:22:40 -0500

Hi Kamel:

Hemant
-----Original Message-----
From: ext Shaheen, Kamel M. [mailto:[email-masked]]
Sent: Monday, January 06, 2003 12:11 PM
To: Chaskar Hemant (NRC/Boston); [email-masked]
Cc: [email-masked]
Subject: RE: [Seamoby] CARD feeding TAR selection issue

Hi Pat and Hemant,

Best Regards,

Kamel

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Mon, January 06, 2003 10:53 AM
To: [email-masked]
Cc: [email-masked]
Subject: RE: [Seamoby] CARD feeding TAR selection issue

Hi Pat:

Regards,
Hemant

-----Original Message-----
From: ext Pat Calhoun [mailto:[email-masked]]
Sent: Sunday, January 05, 2003 8:36 AM
To: Chaskar Hemant (NRC/Boston)
Cc: [email-masked]
Subject: Re: [Seamoby] CARD feeding TAR selection issue

PatC

---

From: "Shaheen, Kamel M." <[email-masked]>
Date: Mon, 6 Jan 2003 12:39:39 -0500

Hi Hemant,

I see your point of view, however, how the target system be identified to
the source system in either case specially with two IP connections.

I would think that if the mobility factor were taken off the picture, the
same issue would still persist.

Kamel

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Mon, January 06, 2003 12:23 PM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [Seamoby] CARD feeding TAR selection issue

Hi Kamel:

One can think of number of scenarios. For cellular to WLAN handoff, if MN
can simultaneously maintain two IP-level connections, I think MIP can be
used in most basic form (without fast HO/CT etc.). In the reverse direction,
due to time constraint (WLAN coverage disappearing as you move out of
hot-spot) as well as to save cellular bandwidth, it may be efficient to use
fast HO and CT signaling along with mobile IP.  

Hemant
-----Original Message-----
From: ext Shaheen, Kamel M. [mailto:[email-masked]]
Sent: Monday, January 06, 2003 12:11 PM
To: Chaskar Hemant (NRC/Boston); [email-masked]
Cc: [email-masked]
Subject: RE: [Seamoby] CARD feeding TAR selection issue

Hi Pat and Hemant,

Best Regards,

Kamel

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Mon, January 06, 2003 10:53 AM
To: [email-masked]
Cc: [email-masked]
Subject: RE: [Seamoby] CARD feeding TAR selection issue

Hi Pat:

Regards,
Hemant

-----Original Message-----
From: ext Pat Calhoun [mailto:[email-masked]]
Sent: Sunday, January 05, 2003 8:36 AM
To: Chaskar Hemant (NRC/Boston)
Cc: [email-masked]
Subject: Re: [Seamoby] CARD feeding TAR selection issue

PatC

---

From: "Shaheen, Kamel M." <[email-masked]>
Date: Mon, 6 Jan 2003 12:39:39 -0500

Hi Hemant,

Kamel

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Mon, January 06, 2003 12:23 PM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [Seamoby] CARD feeding TAR selection issue

Hi Kamel:

Hemant
-----Original Message-----
From: ext Shaheen, Kamel M. [mailto:[email-masked]]
Sent: Monday, January 06, 2003 12:11 PM
To: Chaskar Hemant (NRC/Boston); [email-masked]
Cc: [email-masked]
Subject: RE: [Seamoby] CARD feeding TAR selection issue

Hi Pat and Hemant,

Best Regards,

Kamel

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Mon, January 06, 2003 10:53 AM
To: [email-masked]
Cc: [email-masked]
Subject: RE: [Seamoby] CARD feeding TAR selection issue

Hi Pat:

Regards,
Hemant

-----Original Message-----
From: ext Pat Calhoun [mailto:[email-masked]]
Sent: Sunday, January 05, 2003 8:36 AM
To: Chaskar Hemant (NRC/Boston)
Cc: [email-masked]
Subject: Re: [Seamoby] CARD feeding TAR selection issue

PatC

---

From: [email-masked]
Date: Mon, 6 Jan 2003 12:59:20 -0500

Hi Kamel:

In the first (simple) case, there is no need to identify target system to source system. There are two connections pivoted at MN. MN can send binding update over new connection and upon receiving BACK can switch to new connection and let go the old one. This is make before break case.

In the second case, CARD will enable the mapping using AP ID of new system as the identifier sent to current AR.

Hemant

-----Original Message-----
From: ext Shaheen, Kamel M. [mailto:[email-masked]]
Sent: Monday, January 06, 2003 12:40 PM
To: Chaskar Hemant (NRC/Boston); Shaheen, Kamel M.;
[email-masked]
Cc: [email-masked]
Subject: RE: [Seamoby] CARD feeding TAR selection issue

Hi Hemant,

Kamel

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Mon, January 06, 2003 12:23 PM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [Seamoby] CARD feeding TAR selection issue

Hi Kamel:

Hemant
-----Original Message-----
From: ext Shaheen, Kamel M. [mailto:[email-masked]]
Sent: Monday, January 06, 2003 12:11 PM
To: Chaskar Hemant (NRC/Boston); [email-masked]
Cc: [email-masked]
Subject: RE: [Seamoby] CARD feeding TAR selection issue

Hi Pat and Hemant,

Best Regards,

Kamel

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Mon, January 06, 2003 10:53 AM
To: [email-masked]
Cc: [email-masked]
Subject: RE: [Seamoby] CARD feeding TAR selection issue

Hi Pat:

Regards,
Hemant

-----Original Message-----
From: ext Pat Calhoun [mailto:[email-masked]]
Sent: Sunday, January 05, 2003 8:36 AM
To: Chaskar Hemant (NRC/Boston)
Cc: [email-masked]
Subject: Re: [Seamoby] CARD feeding TAR selection issue

PatC

---

From: [email-masked]
Date: Mon, 6 Jan 2003 12:59:20 -0500

Hi Kamel:

Hemant

-----Original Message-----
From: ext Shaheen, Kamel M. [mailto:[email-masked]]
Sent: Monday, January 06, 2003 12:40 PM
To: Chaskar Hemant (NRC/Boston); Shaheen, Kamel M.;

Hi Hemant,

Kamel

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Mon, January 06, 2003 12:23 PM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [Seamoby] CARD feeding TAR selection issue

Hi Kamel:

Hemant
-----Original Message-----
From: ext Shaheen, Kamel M. [mailto:[email-masked]]
Sent: Monday, January 06, 2003 12:11 PM
To: Chaskar Hemant (NRC/Boston); [email-masked]
Cc: [email-masked]
Subject: RE: [Seamoby] CARD feeding TAR selection issue

Hi Pat and Hemant,

Best Regards,

Kamel

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Mon, January 06, 2003 10:53 AM
To: [email-masked]
Cc: [email-masked]
Subject: RE: [Seamoby] CARD feeding TAR selection issue

Hi Pat:

Regards,
Hemant

-----Original Message-----
From: ext Pat Calhoun [mailto:[email-masked]]
Sent: Sunday, January 05, 2003 8:36 AM
To: Chaskar Hemant (NRC/Boston)
Cc: [email-masked]
Subject: Re: [Seamoby] CARD feeding TAR selection issue

PatC

---

From: [email-masked]
Date: Mon, 6 Jan 2003 15:29:28 -0500

Hi James:

-------------------------------------clip--------------------------------------
> Network policies (in network assisted CARD) can be implemented indirectly by
current AR. In other words, current AR may not send information about certain
CARs to MN, if network policy in unfavorable to those CARs. In an extreme case,
if network sends to MN information about only one CAR, it is tantamount to
performing TAR selection on current AR.

Hmm, I'm not sure I understand the motivation for this requirement. Could you
clarify?
 
            jak

[Hemant] Consider a scenario where MN hears two AP beacons, one from a domain favorable (due to business relationship, say) to current AR and another unfavorable to current AR. MN asks current AR to provide AR addresses and capabilities corresponding to both AP IDs. The issue is, do we want to provide an option to current AR to influence TAR selection in this case. For example, one of the two target AP IDs may be of OWLAN operated by the same operator and another one by different operator. Then, current AR may prefer (or sometimes require) MN handing over to the first OWLAN.

Hemant

---

From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
Date: Mon, 13 Jan 2003 13:52:36 -0600

Hi Hemant,

Sorry for being a bit late in the discussion.
I think we need to be careful in ruling one versus the other approach.
As I recall, interdomain was a secondary concern for CARD, so why
the most control is in the hand of the MN (network control is only
optional?)

I have a few concerns:

1-Air bandwidth: it is either very scarce, or tightly controlled.
Sending a lot of gathered information in either direction is either not very
economic, or needs prior QoS mechanism support.
Sometimes the MN hears a lot of beacons (specially in an inter-domain/
access tech case)
sometimes the network has most of the information (I think this is more
often).
Either we need to allow both cases (selection at either MN or network,
depending
on where it is collected) or send only parts of the data (say: one side
makes a 
partial decision and offers a few options to selecting party).

2-Network management: Networks that have tight (central and distributed) 
management approach, are more paranoid about their resources and don't want
to have the MN make such decision (not to mention the denial of service
issues
this may have), would want to do the selection themselves.
On the other for inter-domain cases, MN involvement maybe inevitable.

It seems to me that a network based selection should be the base approach??

Regards,

Madjid

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Sunday, January 05, 2003 4:46 PM
To: [email-masked]
Subject: [Seamoby] CARD feeding TAR selection issue

Hi all:

In order to proceed with next version of CARD draft, the design team would
like to seek WG consensus on the following way of CARD operation, so that it
can be used for TAR selection.

TAR selection is defined as selecting a unique AR for handoff from a set of
CARs. For this, TAR selection module needs access to CAR identities and
their capabilities. TAR selection module resides in the MN.

Base protocol:
--------------

Step 2: MN runs TAR selection algorithm to choose TAR at the time of
handoff.

Step 1A: To avoid sending whole capability set of any CAR to MN, especially
if MN is not interested in all those capabilities, in the CARD query MN can
specify the capabilities that it is interested in receiving (by specifying
capability attributes).

Step 1B: Even when capabilities of interest are specified by MN in query, to
avoid sending information on CARs that MN is not obviously going to like, MN
can also specify in the query to send CAR information if the capability of
interest is above a threshold (attribute being greater than some value).

Network policies:

current AR. In other words, current AR may not send information about

Thanks,

Hemant

---

From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
Date: Mon, 13 Jan 2003 13:52:36 -0600

Hi Hemant,

I have a few concerns:

Regards,

Madjid

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Sunday, January 05, 2003 4:46 PM
To: [email-masked]
Subject: [Seamoby] CARD feeding TAR selection issue

Hi all:

Base protocol:
--------------

Network policies:

Thanks,

Hemant

---

From: [email-masked]
Date: Mon, 13 Jan 2003 15:31:02 -0500

Hi Madjid:

Some comments:

-----Original Message-----
From: ext Nakhjiri Madjid-MNAKHJI1 [mailto:[email-masked]]
Sent: Monday, January 13, 2003 2:53 PM
To: Chaskar Hemant (NRC/Boston); [email-masked]
Cc: Nakhjiri Madjid-MNAKHJI1
Subject: RE: [Seamoby] CARD feeding TAR selection issue

Hi Hemant,

I have a few concerns:

[Hemant]In consideration to air bandwidth and MN processing power, I think we should at least have step 1A. That will curtail some overhead on link bandwidth and MN processing power. It also enables to define a large set of possible capability parameters.

[Hemant] For network to be able to make decision, we need to provide it with the information on MN requirements. This was the intent of step 1B. But, there was some complexity concern on mailing list as regards this step.

Regards,

Madjid

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Sunday, January 05, 2003 4:46 PM
To: [email-masked]
Subject: [Seamoby] CARD feeding TAR selection issue

Hi all:

Base protocol:
--------------

Network policies:

Thanks,

Hemant

---

From: [email-masked]
Date: Mon, 13 Jan 2003 15:31:02 -0500

Hi Madjid:

Some comments:

-----Original Message-----
From: ext Nakhjiri Madjid-MNAKHJI1 [mailto:[email-masked]]
Sent: Monday, January 13, 2003 2:53 PM
To: Chaskar Hemant (NRC/Boston); [email-masked]
Cc: Nakhjiri Madjid-MNAKHJI1
Subject: RE: [Seamoby] CARD feeding TAR selection issue

Hi Hemant,

I have a few concerns:

Regards,

Madjid

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Sunday, January 05, 2003 4:46 PM
To: [email-masked]
Subject: [Seamoby] CARD feeding TAR selection issue

Hi all:

Base protocol:
--------------

Network policies:

Thanks,

Hemant

---

From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
Date: Mon, 13 Jan 2003 14:36:31 -0600

Hi Hemant,

Seems like we are in agreement. 
My reaction was to the word "optional"
in

"Optional optimizations to the base protocol"

If optional means, you include it in your design but provide
a switch for it, then I am fine. But if the procedure is not
considered at all, then the protocol may be of limited use.
Seems like it is former case, right? then I am fine, if the 
working group considers it too complex.

Regards,

Madjid

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Monday, January 13, 2003 2:31 PM
To: Madjid Nakhjiri; [email-masked]
Subject: RE: [Seamoby] CARD feeding TAR selection issue

Hi Madjid:

Some comments:

-----Original Message-----
From: ext Nakhjiri Madjid-MNAKHJI1 [mailto:[email-masked]]
Sent: Monday, January 13, 2003 2:53 PM
To: Chaskar Hemant (NRC/Boston); [email-masked]
Cc: Nakhjiri Madjid-MNAKHJI1
Subject: RE: [Seamoby] CARD feeding TAR selection issue

Hi Hemant,

I have a few concerns:

[Hemant]In consideration to air bandwidth and MN processing power, I think
we should at least have step 1A. That will curtail some overhead on link
bandwidth and MN processing power. It also enables to define a large set of
possible capability parameters.

[Hemant] For network to be able to make decision, we need to provide it with
the information on MN requirements. This was the intent of step 1B. But,
there was some complexity concern on mailing list as regards this step.

Regards,

Madjid

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Sunday, January 05, 2003 4:46 PM
To: [email-masked]
Subject: [Seamoby] CARD feeding TAR selection issue

Hi all:

Base protocol:
--------------

Network policies:

Thanks,

Hemant

---

From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
Date: Mon, 13 Jan 2003 14:36:31 -0600

Hi Hemant,

Regards,

Madjid

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Monday, January 13, 2003 2:31 PM
To: Madjid Nakhjiri; [email-masked]
Subject: RE: [Seamoby] CARD feeding TAR selection issue

Hi Madjid:

Some comments:

-----Original Message-----
From: ext Nakhjiri Madjid-MNAKHJI1 [mailto:[email-masked]]
Sent: Monday, January 13, 2003 2:53 PM
To: Chaskar Hemant (NRC/Boston); [email-masked]
Cc: Nakhjiri Madjid-MNAKHJI1
Subject: RE: [Seamoby] CARD feeding TAR selection issue

Hi Hemant,

I have a few concerns:

Regards,

Madjid

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Sunday, January 05, 2003 4:46 PM
To: [email-masked]
Subject: [Seamoby] CARD feeding TAR selection issue

Hi all:

Base protocol:
--------------

Network policies:

Thanks,

Hemant