The Routing Over Large Clouds Mailing List Archive by date

Cell Relay Retreat>List Archive>month:1995-Dec> msg00003



[Date Prev][Date Next][Thread Prev][Thread Next]  
  [Date Index][Thread Index][Author Index][Subject Index]

NHRP & media type - a summary

  • From: Paul Koning 1695 <pkoning@chipcom.com>
  • Date: Mon, 04 Dec 95 11:33:00 PST
  • Encoding: 60 TEXT
  • X-Orig-Sender: owner-rolc@nexen.com

>I sat back and contemplated this matter a little further,
>and stumbled across some hidden assumptions that probably
>help explain my view wrt Dave Katz' view (and others). So,
>to perhaps clarify where I'm coming from, here's where
>I think we stand:
>
>Assumption #1:
>        "NHRP is/is-not merely an address mapping protocol."
>
>It appears that Dave (et al) see NHRP as purely a mapping
>protocol, so it makes sense that the only identifiers you
>need are the address type you're mapping FROM, and the
>type you're mapping TO.

I hadn't considered this point, but now that you mention it, the answer
in my case is definitely NO.

There are actually various other examples in protocol  history of
mistakes of this kind, spanning a wide range of protocol capabilities.

The general point, of which the "address type" is a specific example,
is this:

There are two ways to describe X in a protocol (where X may be an
address, a request for a certain QoS, etc.)
1. By a field in the message that says "X"
2. By a field in the message that implies a variety of things, one of
   which is X.

>On the other hand, I've tended to view NHRP as intimately
>tied to link layer connection management, with the address
>mapping merely a part of the role. Consider the expected
>role of NHRP messages in carrying QoS related information
>in the future. I consider that NHRP request/replies will
>carry media-dependent QoS parameters to aid clients in
>their broader task of link connection management. Thus,
>it has made perfect sense to me to have a field that conveyed
>some link media-type semantics in addition to link address
>type semantics. Its only at this early stage of NHRP deployment
>that we can simplify NHRP to just an 'address mapping' mechanism.

It certainly may be that NHRP will convey media dependent QoS
parameters.  It is also likely, and clearly preferable, that it will convey
media INdependent QoS parameters.

Similarly, while NHRP can convey media dependent address
mappings, it is better for it to convey media independent
address mappings.

 -------------
I would like to pose a question that seems to be relevan to the
discussion: if an NHRP node receives a protocol message containing
a media type code it does not recognize, what is it expected to do?
(What does the spec say?)

1. Process the message, effectively ignoring the media type code?
2. Discard the message?

     paul