Subject: �ظ�: (ION) Re: Checking NHRP cache information

From: "Yu Ning" <[email-masked]>
Date: Wed, 14 Jan 1998 10:29:16 +0800

Hi Diane,

>Yu Ning,
>
>See below for my responses.
>
>Diane
....

>> >One has to look at the bigger picture, not just the NBMA subnetwork when
>> >reading this paragraph. S cannot assume that the station it wishes to
>> >reach is reached via the NBMA network. It may be connected to other
>> >subnetworks (e.g. Ethernet) and station D could be reachable via one of
>> >those subnetworks. Once it determines that it should use the NBMA
>> >network as the next hop, then it would check its cache before sending
>> >the NHRP Resolution Request.
>>
>> That's also the first impression of my reading that paragraph, but
further
>> reading
>> confused me. So I think that paragraph should be re-written like this:
>>
>> "Station S should first verify that if it's NBMA direct-attached, if so,
it
>> will further
>> check its local resolution cache for the NBMA address of the dest IP. If
not
>> hit, it will initiate a NHRP resolution query to its
preconfigured(default)
>> NHS.
>> The NHS will further prorogate the request till the end.
>> Otherwise(non-direct-
>> NBMA-attached), the forward the packet in normal routing path. "
>>
>> Why the paragraph should be re-written like that is because: there is
always
>> a routed path between S and D, and that path should be the last
>> consideration.
>> If making routing decision for the next hop(of network layer) first, NBMA
>> short-cut
>> will be neglected in the case of direct-NBMA-attached host. So whether
>> direct
>> or in-direct NBMA-attached should be decide first.The original paragraph
may
>> not really so absurdity, but it lead to confusion.
>>
>
>I think you're making the assumption that S knows nothing about the
>addresses that can be reached through the NBMA network without checking
>cache and/or sending a NHRP resolution request. Routing protocols will
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
I doesn't mean that.  I know the third layer address(e.g. IP address) can be
propagated through the NBMA via routing protocol. But we need NHRP for
NBMA address resolution.

The reason why S check its cache is that it wants to resolve the NBMA addess
of D(IP address). If this fails, it will initiate a standrad NHRP request to
the
NHS, wherher the NHS is by default or by learning.

>be run by the NHS's so that information about all the reachable
>addresses for that internetwork protocol will be understood by
>participating routers (even if they're not NHS's) and hosts that receive
>the routing protocols. The routing protocols run over the "whole"
>network, including the NBMA subnetwork, so destinations on the other
>side of the NBMA subnetwork will be known, just like destinations on the
>other side of a PPP link are known.
>
>Another option for the NBMA-attached hosts is to use a default route to
>an NHS. First they check to see if the destination address is reachable
>via any entries in their routing table. If not, they forward the packet
>on the default route.
>
>Whatever method is used, the knowledge needs to be there in S so that it
                                                    ^^^^^^^^^^^^^^
Yes, it comes to the point! How S obtains this knowledge? In your statemnet
above, you seems to point out two methods: a learned way and a
pre-configured
way. But I think: whether a host is direct NBMA-attached or in-direct is de
priori
to host itself. And the reachibility of NHS through its NBMA interface is
pre-
configured. All S should do is to try to establish cut-through to D with the
support of NHRP.

I want to make our discussion clear:
1) A host can be direct NBMA-attached, or in-direct NBMA-attached. We'd
     better called them DNA, and IDNA
2) The futher data traffice of the host S can be send via cut-through link
    or forwarded by router. Called them Cut-throughed, and Forwarded.

Then, my point is:
Before sending the first bit of data, S should decide whether its DNA or
IDNA.
The knowledge to make the decision above is de priori. Because S can
decide its interface is NBMA or other media without the knowledge from
other network component.

If IDNA, S will give up Cut-throughed link, and undertake a normal routing
decision, .i.e. forward the data to its router(default, or learned)

If DNA, it means S may take the advantage of NHRP to establish a
Cut-throughed
link. First S will look up its cache for former resolution result, if fails,
it will
start a new round of NHRP resolution request.

How do U think of these? :-)

>can determine when a packet should be propagated out the NBMA port as
>opposed to any other port.
>
>> What's more, can't we really do anything if the S is
>> non-direct-NBMA-attached?
>
Sorry , in the sentence above, I mean "can't we really establish a
*cut-through*
path between an upper node of S  and D?". I know routing through 3rd layer
is
the last choice. Your reply below just confirmed me :-).

>Again, if routing protocols are running then S can have the knowledge
>required to route a packet to a router which IS directly attached to the
>NBMA network.
>
>> Can S ROUTED(not using pre-configured PVC) the NHRP request to a NHS,
>> then the NHS is responsible for establishing a cut-through between itself
>> and
>> the dest NHS. So through the data path, only the src NHS-> dest NHS is
cut-
>> through, while the S->src NHS, dest NHS->D is routed? It seems in the
MPOA
>> 1.0
>> model (which can be seen as a NHRP realization), the edge device can
>> create a cut-through for its sub-attached hosts. And the hosts are not
>> nessicarily
>> direct-NBMA-attached.
>
>Yes, this works with NHRP.
>
>> Thanks for your response.
>>
>> Sincerely, Yu Ning
>> ATM R&D Center of BUPT
>> Beijing, P.R.C.
>> email: [email-masked]
>>
>
>--
>Schuster Consulting
>[email-masked]
>(919) 831-9019
>
>

X-Info: To unsubscribe, email [email-masked]' with
X-Info: 'unsubscribe ion' in the body of the message.

---

From: Diane Schuster <[email-masked]>
Date: Wed, 14 Jan 1998 06:41:37 -0500

Yu Ning:

> >cache and/or sending a NHRP resolution request. Routing protocols will

Actually, S makes the decision of which port to use in the
internetworking layer. The packet is passed down to the subnetwork
layer. At the layer, there is awareness of the medium to be used to
transport the packet. If the medium is an Ethernet, an ARP packet may
need to be sent first to resolve the IP address to the MAC layer address
of the next hop. If the medium is NBMA, and if this device is an NHC or
NHS, the procedures defined in NHRP should be used to resolve the next
hop and the NBMA address associated with the next hop. 

> decision, .i.e. forward the data to its router(default, or learned)

Yes, since there is no concept of a cut-through link on an Ethernet (or
whatever BMA subnetwork), the packet will take the next hop to some
router. If this router is NBMA attached, it had better be an NHC or an
NHS. It will perform the proper procedures to resolve the next hop &
address toward D. If it wishes, it can forward the packet along the
routed path through the NBMA while it waits for the resolution to take
place. In fact, it could choose to always use the routed path through
the NBMA instead of the using the shortcut or it could use the routed
path until it detects a flow (like in MPOA). NHRP does not define this
behavior...it just provides the means for finding the shortcut through
the NBMA subnetwork.

> start a new round of NHRP resolution request.

Yes, S should do as you describe. Which is the same thing that is done
by a router on the routed path in the IDNA example above. 

> How do U think of these? :-)

I think you know what should happen. You just want the behavior of the
NHC's to be described in detail in the NHRP internet-draft and it's not.
And the reason its not is because it's not required. The internet draft
describes the tools required to accomplish the shortcut and its up to
the individual vendors to utilize these tools in a way that will result
in products that perform the way customers expect.

> the last choice. Your reply below just confirmed me :-).

A cut-through between upper layers (layer 3) is something that can be
accomplish using MPLS-like mechanisms. NHRP runs at the subnetwork layer
and so only deals with the specific medium.

-- 
Schuster Consulting	
[email-masked]
(919) 831-9019

---

From: Albert Manfredi <[email-masked]>
Date: Wed, 14 Jan 1998 10:01:45 -0500

Yu Ning wrote:

[ ... ]

> configured. All S should do is to try to establish cut-through to D with the

Yu,

The source host S knows nothing but the IP destination address of
host D and, perhaps, the NBMA address of its NHS. I say "perhaps"
because S could find the NHS also with an anycast address or it
could simply be its default router or an alternative router (e.g.
ICMP redirect).

S does _not_ need to know a priori that D is an NBMA (ATM) host, nor
does S need to know whether the ATM net of host D is contiguous with
the ATM net of host S. They might be two, isolated, ATM islands.

NHRP assumes the least possible amount of a priori knowledge on the
part of S. You seem to want to assume more knowledge than necessary.

As we already discussed, _once_ S has found the NBMA address, and
_once_ the intervening NHSs have processed the NHRP Request and
Response messages, all these players can cache the info and use the
cached IP-ATM address mapping to speed up the process. But use of
cached info is labeled "unauthoritative."

> Before sending the first bit of data, S should decide whether its DNA or

Read NHRP again. It permits S to either wait until the shortcut is
set up or to begin by sending data along the routed path. MPOA does
exactly the same thing.

> decide its interface is NBMA or other media without the knowledge from

The knowledge might or might not be available a priori. Both cases
are feasible. And the short-cut path might go all the way to D or it
might only go part-way to D, if the two ATM nets are not contiguous,
if D is not an ATM host, or if D's NHS is dead.

You seem to want to constrain NHRP more than it needs to be, I
think.

Bert
[email-masked]
X-Info: To unsubscribe, email [email-masked]' with
X-Info: 'unsubscribe ion' in the body of the message.