Subject: (ION) NHRP Queries

From: Archana Nehru <[email-masked]>
Date: Thu, 01 Oct 1998 15:26:34 -0700

Hi, 

I need a few clarifications about NHRP.I appreciate any help on this.

1.Under what practical situations would an NHS(no colocated NHC)
  be required to accept shortcuts and handle data?Is it required at all?

2.When an NHC refreshes its "registration" with an NHS, does it need
  to use the same "requestID" consistently with the NHS?.If NHC doesnot
  use a same "request Id" then how would an NHS distinguish between a
  "refresh of a registration" and a duplicate registration?
  E.g: if an NHC registers a protocol address 1.2.3.4 with "U" bit set,
  then an NHS should reject any further registration for the same
  protocol address, with the "U" bit set.Now to refresh its registration 
  request with the NHS, if the NHC uses a different "requestID", the NHS
  will find an existing entry for the protocol address and reject it?
  
3.Why is authentication in NHRP "source based" and not "destination
  based"? Doesnot it mean that an NHS can never have a one to one
  authentication relation with its neighboring NHS/NHC(s).

Regards
Archana

________________________________________________________________________
ARCHANA NEHRU                     :  Trillium Digital Systems, Inc 
E-mail: [email-masked]       :  Los Angeles, California     
Phone: +1 310 442 9222     
________________________________________________________________________

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

---

From: Diane Schuster <[email-masked]>
Date: Mon, 05 Oct 1998 06:57:19 -0400

Archana,

>   be required to accept shortcuts and handle data?Is it required at all?

I can't think of any reason why a pure NHS would need to accept or set
up a shortcut. That does not, however, mean that it will not need to be
able to accept incoming SVCs (e.g. from other NHS's and rom it's NHCs)
for the exchange of control data. 

>   will find an existing entry for the protocol address and reject it?

I think the requestID needs to be incremented or, at least, get higher
with every refresh. The NHS distinguishes between a refresh and a
duplicate by looking at other fields in the registration such as the
Source NBMA Address and the Source NBMA Subaddress and, possibly, the
VCC on which the message was received. I agree that the description of
the use of the "U" bit in the NHRP Registration Request section is not
completely clear about this.

-- 
Diane Schuster
Lucent Technologies
919-831-9019
[email-masked]

---

From: Archana Nehru <[email-masked]>
Date: Mon, 05 Oct 1998 10:35:55 -0700

Hi,
Thanx for the response.Please see my comments below:

> for the exchange of control data.

The NHRP specs seems to suggest this wherever it talks about finding an
"egress NHS", especially if the "destination" is not directly connected
to an ATM network.

For e.g: in section 2.2, last para, it says "
   The Route Record extensions are the NHRP Forward Transit NHS Record
   Extension and the NHRP Reverse Transit NHS Record Extension.  They
   contain the internetwork (and subnetwork layer) addresses of all
   intermediate NHSs between source and destination and between
   destination and source respectively.  When a source station is unable
   to communicate with the responder (e.g., an attempt to open an SVC
   fails), it may attempt to do so successively with other subnetwork
   layer addresses in the NHRP Forward Transit NHS Record Extension
   until it succeeds (if authentication policy permits such action).

Also in sec 5.3.2, it says"
In addition, NHSs that are willing to act as egress routers for
   packets from the source to the destination SHALL include information
   about their NBMA Address".

Please note that the word"NHS" is used throughout and there is no
mention of a co-existing NHC. Though my personal belief is that
an "egress NHS" should always be one having both NHS and NHC and not
just an NHS, I would like to confirm this assumption.

Regards
-archana

---

From: Archana Nehru <[email-masked]>
Date: Mon, 05 Oct 1998 14:14:10 -0700

Diane,
Please find my comments  below:

- Archana

> 
> Archana Nehru wrote:
> Note that it says that the source station may "attempt" to open an SVC
> with other subnetwork layer addresses in the NHRP Forward Transit NHS
> Record Extension. I would interpret this to mean that the attempt could
> fail. And an attempt could fail if the NHS did not have a co-resident
> NHC.

I agree to this..so we are concluding that an "egress NHS" is not
mandated by the protocol to implement the "shortcut part".It is optional
and completely implementation dependent.This means that if such an  NHS
is on a "egress ATM router" and there is no colocated NHC , data to the
non-ATM destinations behind the router, travels hop to hop.

> It really boils down to how you define the functions associated with the
> NHS and with the NHC. Is the ability to forward packets on a path other
> than the routed path a function of the NHC 

In my opinion, any forwarding related to pure IP data is an NHC's
function..and any control data forwarding would be done by an NHS.The
NHRP model looks exactly similar to the CIP client/server.Just that in
NHRP's case the CIP server can resolve addresses out of the LIS and that
is it(no shortcuts to the server)

> I agree, but I realize there is probably another way to do it as I
> mention above. You could include the ability to forward packets along a
> path other than the routed path in the NHS implementation as well as in
> the NHC implementation.
If you do it this way, you don't get the excess
> baggage of including all the unnecessary NHC functionality in the NHS
> router (which probably isn't all that much). In this way, you
> automatically support the situation where the source couldn't open an
> SVC to the egress NHC and attempts to open an SVC to the NHS.

I believe you are saying that we can optionally implement an NHS to
accept incoming shortcuts, but not initiate outgoing shortcuts if a
colocated NHC doesnot exist.
If that is true, then my question will be why would
a "non-ATM destination" be concerned about receiving an ATM VCC, but not
initiating one? In other words, if an egress router with an NHS is
accepting shortcuts for some "destination" that is non -ATM, wont it be
make more sense to also have an NHC colocated with the NHS on the edge
router,so that connections can also be initiated in the reverse
direction from the non -ATM host to a ATM host?(unless the NHS here is
also implmenting a full NHC and initiating "resolution requests" etc)If
yes, then an NHS accepting shortcuts, becomes redundant and an egress
router can simply configure the NHC to accept and initiate shortcuts and
allow the NHS to just do "address resolution".

-regards
archana

--

---

From: Diane Schuster <[email-masked]>
Date: Mon, 05 Oct 1998 15:35:50 -0400

Archana,

My comments are below.

Diane
--

I suspect that most routers supporting the NHS function would also
support the NHC function because they provide reachability to other
destinations outside the NBMA network or they want to support the case
described above. It's certainly possible for a pure NHS to exist, in
which case it would only provide connectivity between LIS's or LAG's
within the logical NBMA network (and in which case an attempt to open an
SVC to it could fail).

It really boils down to how you define the functions associated with the
NHS and with the NHC. Is the ability to forward packets on a path other
than the routed path a function of the NHC or is it a function of both
the NHC and the NHS? It works to have this function only as part of the
NHC and just co-locate the NHC with any NHS you want to perform this
function. There's some amount of unnecessary function that you get by
including the NHC with the NHS; you have to decide if it is too much.

the NHC implementation. If you do it this way, you don't get the excess

---

From: Diane Schuster <[email-masked]>
Date: Tue, 06 Oct 1998 09:26:22 -0400

Archana,

> allow the NHS to just do "address resolution".

Actually, I was just referring to any processing that is unnecessary
because the NHC and NHS are co-located. I never meant that the NHS
should be able to accept shortcuts but not initiate shortcuts. I was
thinking of things like running the NHRP Registration protocol from an
NHC's perspective, but that is probably insignificant.